New Java applet whitelist add-on

[Uncle Asad]

If you do not use Java applets or if the "Enable Java" preference in the Web Features pane of Camino’s preferences is unchecked or greyed out, you can skip this post

As many of you are aware, there have recently been a number of attacks that use unpatched holes in Java to load malware on computers, including Macs. While Apple has released updated versions of Java for Mac OS X 10.6 and 10.7 to close the current set of holes, there are no Java updates available for users on Mac OS X 10.4 or 10.5, and there may be future holes in Java that can be exploited before Oracle and Apple discover and close them on 10.6 and 10.7.

Although Camino 2.1 ships with Java off, some users may still need to use Java applets on one or more sites. Rather than remembering to switch Java on and off every day after using these sites (and remaining vulnerable to potential Java-based attacks on any other sites you visit while using the sites where you normally use Java), I've written a small JavaScript XPCOM component that uses Gecko's content policies to create a whitelist of sites that are allowed to run Java applets. This will allow you to keep Java enabled all the time but only allow “trusted” sites where you need to run Java applets to actually run Java applets.

Details of installation and usage/configuration found in the Readme inside the download.

aoJavaPolicy (v1.0.1, 14 June 2012)

If you use Java in Camino, I strongly encourage you to download and install this component. I'm hoping to get a better version included in a future version of Camino.

[haleakalari]

tried it. followed instructions exactly (moved aoJavaPolicy.js to the components folder in ~/Library/Application Support/Camino etc...). after doing so and restarting camino, i checked in about:config for the policy to add some sites to the white list. policy didn't show up in about:config. even tried manually adding the line to my user.js file and camino still did not recognize it (doesn't show up in about:config and java applets will still run on any site). not sure what's going on with it. using camino 2.1.2 on the latest update of os x 10.4.11 on an early macbook pro.

now i actually got camino to recognize the preference (i added the 'ao_java_policy.allowed_sites' to prefs.js with a few addresses in quotes after adding the aojavapolicy.js to the components folder). it shows up in about:config now, but the whitelist doesn't seem to have any effect. sites that have not been added to the whitelist still load java applets.

[Uncle Asad]

Hrm. The pref is supposed to be created automatically the first time the component is loaded, so something is definitely amiss.

Can you 1) either install ChimericalConsole or set the "log errors to console" hidden pref (both require a restart), and
2) Delete the "ao_java_policy.allowed_sites" pref entry you added in prefs.js
3) Restart Camino and look for any log messages that mention aoJavaPolicy.js

Doing that should hopefully explain why you saw the first problem, which will also hopefully lead to the solution for the second problem.

[haleakalari]

Hrm. The pref is supposed to be created automatically the first time the component is loaded, so something is definitely amiss.

Can you 1) either install ChimericalConsole or set the "log errors to console" hidden pref (both require a restart), and
2) Delete the "ao_java_policy.allowed_sites" pref entry you added in prefs.js
3) Restart Camino and look for any log messages that mention aoJavaPolicy.js

Doing that should hopefully explain why you saw the first problem, which will also hopefully lead to the solution for the second problem.

will do and get back to you. have to run out now, so might not be able to until later tonight or tomorrow though.

[phiw13]

So, I didn't get it to to work, so far. Not on 10.7 - doesn't really matter as Java is broken anyway, and not on 10.6 (I went as far as installing the Java embed plugin…). The white-list pref never showed up in about:config. I don't see any errors in Chimerical Console (or Console.app).

Thinking there might be conflict with other installed components, I removed those, but that didn't help anything (ga-optout and do-not-track).

[Uncle Asad]

Hrm. It definitely works here locally in my daily-use profile, and it worked in my test profile the other day before uploading, but it wasn't working in my test profile just now. Strange.

Hmm. If you move/rename xpti.dat in the profile (or update to a new nightly), does it work now? That got my test profile working, but I know Camino picked up the new component as soon as I added it originally, no xpti-deleting required… Puzzling :/

[Uncle Asad]

Hrm, when I turn debugging on, I'm seeing all sorts of crazy behavior tonight that I didn't see immediately before uploading. I'll have to investigate further.

[phiw13]

Deleting xpti.dat didn't fix it; and unfortunately I got interrupted before i could upgrade to the latest nightly; I'll try that tomorrow.

[Uncle Asad]

Deleting xpti.dat didn't fix it; and unfortunately I got interrupted before i could upgrade to the latest nightly; I'll try that tomorrow.

I think that only worked for me because I'm seeing a lot of indeterminate behavior now, and that particular indeterminate behavior happened to work.

[Uncle Asad]

OK, I think I've figured out what's going wrong (and also why I missed it in my testing; I forgot to do my final test with a profile where the pref didn't already exist ) and have hopefully fixed things to make sure the "ao_java_policy.allowed_sites" pref will always be created successfully on first run.

Can you try the following version: http://hg.mozilla.org/users/alqahira_ar ... aPolicy.js (just Cmd-S and replace the old aoJavaPolicy.js file in your profile's components folder)?

If it seems to work, I'll package things up again for v1.0.1

[phiw13]

Ok, with this version, once I upgraded to a next nightly, then the pref show up in about:config. However, despite whitelisting java.com and opera.com (with and without www.), I cannot load the respective applets (opera.com/developer/tools/mini/ and java.com/en/download/testjava.jsp). JEP is installed, Java enabled in the Camino prefs. This is with OS X 10.6. And a couple of restarts on the way.
No logspam anywhere.
(I verified that both applets load without this component installed).

[Uncle Asad]

However, despite whitelisting java.com and opera.com (with and without www.), I cannot load the respective applets (opera.com/developer/tools/mini/ and java.com/en/download/testjava.jsp).

Reloading the pages doesn't help? I'll take a look at the Opera applet, but I've been testing with the java.com applet. This is so bizarre…

No logspam anywhere.

Can you set gDebugLog to true and pastebin the logging you get visiting the site when you relaunch Camino? (Startup logging should appear in the Console; runtime logging should appear in whichever place you have enabled, ChimericalConsole or chimera.log_js_to_console.)

[Uncle Asad]

Hrm. I can reproduce the Opera mini demo case; at least here, the reason it doesn't work is because opera.com loads an <object data="http://demo.opera-mini.net/public/index.html" type="text/html"> to host the applet; thus the applet source and the applet's loading page are opera-mini.net, not opera.com

If lots of sites do that, that really sucks, because there's no way for the user to know the applet source (outside of inspecting the page source in great detail, and for some pages that's not always clear even then) nor to know that the applet's loading page is not the page displayed in the location bar (and Gecko only gives us those two URLs, not the URL we see in the location bar)

When I add opera-mini.net (or just opera), that starts working for me on the next load.

[phiw13]

1. Nice catch on the opera mini domain. That didn't use to be the case . I hadn't used that applet for quite a while (Opera Mini installed on the iPod Touch is a much more realistic testing bed - that and the whole Opera mobile emulator, stellar piece of software; Google/Android I'm looking at you ).

2. I found the problem! I first had:

Code: Select all

user_pref("ao_java_policy.allowed_sites", "opera-mini.net, java.com");

note the space after the comma… Removing that space made it magically work.
(yes it is kinda automatic here, I always add a space after a comma in a comma-separated list; readability and all that jazz)

Story in log format:
http://dev.l-c-n.com/camino/aoJavaPolicy-log.txt

3. still a bit puzzled as to why I to 'upgrade' to a newer build (not really a newer build, just 'another' build) to make the hidden pref appear in about config.

[Uncle Asad]

2. I found the problem! I first had:

Code: Select all

user_pref("ao_java_policy.allowed_sites", "opera-mini.net, java.com");

note the space after the comma… Removing that space made it magically work.
(yes it is kinda automatic here, I always add a space after a comma in a comma-separated list; readability and all that jazz)

Ah, nice find; I guess I need to add some code to strip spaces when processing the pref. I'll have to think about how to do that, since I use " " as a dummy value in a couple places. And maybe make it more clear in the Readme that there are no spaces

3. still a bit puzzled as to why I to 'upgrade' to a newer build (not really a newer build, just 'another' build) to make the hidden pref appear in about config.

It wasn't the upgrade to a newer build of Camino; it was the upgrade to the newer version of aoJavaPolicy; I found and fixed a bug that really did prevent the pref from being created on first run (I had missed said bug in my final testing because I had forgotten to test the no-pref-exists case after making one change ).

Thanks for testing (and finding the space bug)!

haleakalari, please let me know if the new version (from this post) works for you.