> Until then, we recommend uninstalling Java if you don’t need it
This advice feels very rash to me. This vulnerability (and most Java vulnerabilities in its class) affects ONLY the Java browser plugin. Many users won't know if they need Java on their computer, and common services like GotoMeeting and others use it transparently. Telling them to uninstall it will cause support headaches for companies that have coached the user through Java installation in the past and now suddenly it's gone. The result will be that after wasted time on everybody's part, they'll end up reinstalling Java and will be vulnerable all over again.
It would be much better to include proper instructions for how to disable it (or set it in click-to-play mode) in the browser than telling people to uninstall it carte blanche.
Yes this has shot us. Your approach is much better. Half of our outsourcers use Firefox with a screenshot tool which is a java applet. This just stopped working. So Monday is going to be a days work for our operations guys to sort out the mess.
I don't expect the browser to police the internet - it's not its job.
I'm actually gaining respect for IE these days - it doesn't pull shit like this and we have more control over it in a corporate environment.
I do expect the browser to police the internet though tab isolation, incognito modes, and plugin policies. These plugin vendors are a persistent source of exploitable security bugs.
An analogy, if my butler allows you into my home and he notices you opening the door to criminals, then he's going to demand that you leave. If he doesn't, I'm going to fire him. (Disclosure: I don't have a butler.)
That would be great except as far as know it's impossible to install without the plugin. There's no download option that doesn't install the plugin as well and even if you disable it it will get re-enabled next time it upgrades (maybe they've fixed that?)
You are correct. As far as I know, there is no way to not install Java browser plugin files as part of the Java installation process.
You can only disable, rename, delete or block (in the browser configuration) after installation. As of Java 7 Update 10 (12 Nov 2012), there is also a Java Windows Control Panel option to control the security configuration of browser plugin, including preventing it running. I do not know if changes to these settings still apply if further updates or other Java versions are installed.
However, all of these actions are non-trivial for typical users and besides Java is unlikely to be used on the desktop for most users.
Disabling plugins, or even just Flash, would break many websites. Users would blame Mozilla for "breaking the web".
The popup is necessary because many plugin elements are too small for a usable "click to play" message and button. Some websites use Flash content without any visible UI (elements that are just 1x1 or 0x0 pixels). For example, Gmail uses Flash for attachment uploading and audio chat. GitHub uses Flash for copying repo URLs to the user's clipboard.
> Disabling plugins, or even just Flash, would break many websites. Users would blame Mozilla for "breaking the web".
Why not make it easier than going into about:config, then? In Chrome it's available in the settings.
> The popup is necessary because many plugin elements are too small...
How about a whitelist then, so that the main Flash applets on YouTube and other prominent sites with large, easy to locate Flash applets have a non-popup click-to-enable dialog (as is used by extensions like Flashblock)? That would cover 90% of use cases.
Also, how about an option to have click-to-play settings controlled on a per-plugin basis? I wanted click-to-play enabled for Java, but now I'm getting the same crap for Flash when I already have an extension (Flashblock) for that.
And even otherwise the popup doesn't have to protrude over the browser window. It could just be something in the chrome.
Firefox's click-to-play is still enabled by an about:config pref because its initial implementation is not a user-facing feature; it's targeted at disabling plugins for security vulnerabilities (like Java).
I believe a per-plugin setting is planned.
I like your suggestion for a basic whitelist for popular websites like YouTube and Facebook.
I don't know if Firefox has the "badge" setup that Chrome has, but in Chrome there is a plugin (puzzle) icon shown on pages that may have inaccessible flash elements. Normally if a page isn't working, my first attempt is to click the puzzle and say "Run plugins" or "Always allow on this site".
It can be annoying to remember to do it, the first few times you may curse the site for being broken before you realize what's going on.
There isn't any visual indicator that there are hidden plugins, but there is a button on the toolbar for activating a plugin (activates all the elements using the plugin on the page).
I use click to play, and once in a while it does break a page. If a site uses a Flash uploader, or tries to show a video (<video> ain't there yet), then it will break and people won't know why. I still wish it would happen to really push against using plugins on the web, but I understand why they haven't done this yet.
In Opera: opera:config#UserPrefs|EnableOnDemandPlugin
To enable all blocked plugins on page click the "lego" icon in the address bar. Plugins on demand can be enabled/disabled per-site in the site preferences (F12->Edit Site preferences) under the content tab.
I wish Mozilla (and other browsers) also blocked plugins that don't behave while updating. I want to have java installed so I can decide to run java programs, but I don't want to have a browser plugin, so I disable it. Every single time java updates itself it enables the browser plugin again. Users should not have to put up with every installer under the sky silently installing browser plugins, or worse, updaters enabling them again.
Not sure about re-enabling, but Firefox does alert you if another program installs an addon on your behalf, and asks you to confirm. IIRC, it was about FF15 that this happened, and it also asked for ones that were installed previously.
Not necessarily. I'm sure there will be discussion at our next consulting meeting with at least one of our business clients on whether or not they should bother re-enabling Java after this; given that DHS also published a somewhat rare recommendation to completely disable Java, I could see a number of other corporations having the same conversation.
And sometimes that's all it takes to cripple adoption of a platform.
About a year and a half ago, I started disabling Java on new or newly reimaged computers for my users. I got quite a few complaints. It had many more uses than I expected.
This keeps happening, so maybe it should be. I don't want to discover that this has happened yet again, the hard way, before there is another noisy public disclosure. Not interested.
Apple disabled the Java plugin via the XProtect plist, which now means that I am totally unable to log in to online banking in Denmark on any Mac. It's a bit of a disaster.
Bad news for us norwegians. The national online authentication system, BankID, commonly used in online banks and government services, uses a Java applet.
I say this is great news for us Norwegians. With enough of these incidents, we may finally get a BankID system which does not rely on Java.
Banks are feeling pressured already, with agressive customers telling them off on facebook when they try to tone this down. And I can't see Mozilla blocking BankID helping them any further.
There is light at the end of the tunnel - or at least I hope. A few major private sector banks have moved away, I hope the public sector banks follow suite.
Firefox is already shipping with pdf.js[1], which for me has obviated the need to have a PDF reader installed at all. And they're working on Shumway[2] for the ability to emulate Flash in Javascript.
This advice feels very rash to me. This vulnerability (and most Java vulnerabilities in its class) affects ONLY the Java browser plugin. Many users won't know if they need Java on their computer, and common services like GotoMeeting and others use it transparently. Telling them to uninstall it will cause support headaches for companies that have coached the user through Java installation in the past and now suddenly it's gone. The result will be that after wasted time on everybody's part, they'll end up reinstalling Java and will be vulnerable all over again.
It would be much better to include proper instructions for how to disable it (or set it in click-to-play mode) in the browser than telling people to uninstall it carte blanche.