How to be as safe as possible with Java

Here we go again, there is yet another critical security problem with Java. For whatever reason, the latest bug seems to have gotten much more publicity than the many equally serious Java flaws the preceded it. Details of the problem are available from many other sources, here, I will put it in context and concentrate on using Java as safely as possible.

UPDATE: On Jan. 13, 2013 Oracle released Java 7 Update 11 to fix the latest security flaw. Java 6 was not updated as the latest problem was limited to Java 7. Windows, OS X and Linux users can get the latest edition of Java 7 at

To begin in the beginning, Java is available on Windows, OS X and Linux. The latest flaw has been shown to exist in all three systems.

Java is not available at all on iOS (iPhone, iPad) and although it plays a big part in Android, the current issue is with Java from Oracle which does not run on Android. The safest operating system, in my opinion, is Google's Chrome OS which also does not support Java. 

Java and Javascript are totally different. Nothing said here about Java applies to Javascript. 

The current Java flaw boils down to this: view a web page, get infected with a virus. 

On Windows, it may be worse than that. US-CERT warns that "applications that use the Internet Explorer web content rendering components, such as Microsoft Office or Windows Desktop Search, may also be used as an attack vector for this vulnerability". The security section of Microsoft's website has nothing about the latest Java flaw. I tried to contact Microsoft about this. If I hear back, I'll update this topic.  

This points up an interesting point that's often overlooked - Java is used both online and offline. Much of this article, and what you'll find elsewhere online, focuses on disabling Java in web browsers, the online half of the equation. There is, as far as I know, no way to restrict the offline use of Java, that is, Java used by installed applications. Offline use is either all-on or all-off and the only way to get to all-off is to uninstall Java. 


Windows users can easily see if Java is installed in the Control Panel. In XP look in Add or Remove Programs, on Windows 7 look in Programs and Features. On both systems look for an entry starting with Java 6 or Java 7. Most Windows systems with Java installed will also have a Java entry in the Control Panel, but this is buggy and not reliable.  

OS X Snow Leopard (10.6) shipped with Java 6 pre-installed and Java 7 is not available. To verify that Java is installed, go to Applications -> Utilities and run the Java Preferences program. 

OS X Lion (10.7) and Mountain Lion (10.8) shipped without Java. These systems can have either Java 6, Java 7 or both installed. To detect Java 6, use the procuedure just described for Snow Leopard. You can also enter "java -version" at a Terminal prompt. To see if Java 7 is installed, check the Other category in System Preferences. If there is a Java icon there, then Java 7 is installed. 

From a Defensive Computing perspective, un-installing Java is the safest approach. This may, however, break something, there is no easy to way to know without doing it. A partial list of software that depends on Java is available on the home page of my site. 

If you find that an application (such as Crashplan Pro on OS X or Wuala on Windows) or website (, needs Java, only you can weigh the benefit of that service vs. the risk.  At the moment though, Java is very risky. Oracle, the company behind Java, has not said when a fix might be available.  


Windows users that need Java can take a huge step to towards safety by using Java 6 rather than Java 7. I first suggested this back in June and then repeated myself in August. The reasons offered then still stand, but there is now another reason: the current Java flaw only exists in Java 7. 

The latest edition of Java 6 for Windows, Update 38, can be downloaded at All Windows users should opt for the 32 bit edition, even if their copy of Windows is 64 bit.  

This may not be a long term solution though, Oracle is schedule to put Java 6 out to pasture next month. 

Mac users running Snow Leopard (10.6) also benefit from Java 6. In fact, that's all they can run, Java 7 is not supported on Snow Leopard.

Mac users running Lion and Mountain Lion can also opt for Java 6 with one proviso, Apple no longer supports the use of Java 6 in web browsers on these systems. But, if the need for Java is only to run an installed application (such as Crashplan Pro), Java 6 should work fine. 


The latest edition of Java, version 7 Update 10, introduced a new security feature. With one checkbox, the online usage of Java (applets in web pages) can be disabled system-wide (all installed web browsers). As a rule, the security problems with Java are only seen on web pages, I have not yet read about a security issue with Java used by an installed application. 

For more on this see  How do I disable Java in my web browser? from Oracle and Java 7 update 10 introduces important new security controls from Sophos.    


There are two additional defensive approaches available for advanced Windows users. 

The Firefox extension NoScript and the Chrome extension NotScripts offer fine grain control over which websites can run Java applets. 

My personal favorite approach is sandboxing; separating a running Windows application from the rest of the system. Sandboxing works with all web browsers, in addition to email programs and any other Windows application. Whenever I visit a website that I am the least bit suspicious of, I do so in a sandboxed web browser. This offers protection from all sorts of security issues, not just Java. 

For sandboxing, I highly recommend Sandboxie. I have used it a long time with no gripes at all (and I can gripe about anything). Sandboxie is available in both free and paid editions. The paid version is, in my opinion, very reasonably priced considering it lets you run Sandboxie forever, on all computers that you own. 


Windows users have an option to upgrade Java that I suggest avoiding. My preference is to uninstall the old version, in the standard way from the Control Panel, then download the offline installer for the new version of Java. I say this because I prefer to see the old version cleanly removed first, because it makes the installation of the new version logically simpler and because Oracle has suggested this approach for dealing with some problems. 

If you need Java only for installed applications, then it goes without saying that the safest way to live with Java is to disabled online use system-wide using the magic checkbox introduced in Java 7 Update 10 and also available in Update 11. 

However, if you need Java for a website, then the best approach is to disable Java in the browser you normally use and leave it enabled in a second browser that you only use on the site(s) that need Java. Oracle's How do I disable Java in my web browser? includes instructions for disabling Java in assorted browsers. 

One interesting point here is Internet Explorer. Oracle says that it is not possible to completely disable Java in Internet Explorer while leaving it enabled in another browser. Thus, Windows users that need Java for a web site, should never use Internet Explorer. Of course, this is just one of many reasons to avoid Microsoft's browser

Another interesting wrinkle is Google's Chrome browser on OS X. Lion and Mountain Lion users with Java 7 installed can be sure that Chrome will never run Java, checkbox or no checkbox. That's because Chrome on OS X is a 32 bit application and Java 7 on OS X is exclusively 64 bit. 

And speaking of browsers that can never run Java, the version of Internet Explorer 10 for the tile world half of Windows 8  does not support Java because it does not support any plug-ins. The copy of IE 10 that runs in the desktop/legacy half of Windows 8 however, does support Java.  

If juggling two browsers is too much, then I like Google's Chrome browser because it always warns before running Java (on both Windows and Snow Leopard with Java 6), thus offering protection from drive-by infections. 

OS X users running Lion (10.7) and Mountain Lion (10.8) can have only Java 6 installed, only Java 7, or both. For more on this, see my site. If Java 6 is the only installed edition, then no web browser will run Java applets. This change was introduced by Apple in an update released in October 2012. Note too, that this is very different from Snow Leopard (10.6) where Java 6 is allowed to run applets. 


Windows users will want to configure Java to check for updates to itself as often as possible (currently daily). The default update schedule defies explanation. As best as I can figure, it checks for updates once a week and warns you about new versions once a month. Modifying the schedule requires administrator privileges. 

Windows users also need to be aware of a bug where changes to the self-update schedule don't take hold. In addition, there is another bug where the Java Control Panel (which is where the update schedule is configured) doesn't display at all. For suggestions on dealing with that, see Vulnerability Note VU#625617 from US-CERT.

Updates to Java 6 on OS X are provided by Apple as part of their standard software update feature. 

Java 7 on OS X has no set schedule for checking for updates. According to Oracle

Every time you launch a Java applet or a Java Web Start application, the system first launches your program and then, in the background ... determines if it has checked in the last 7 days for a Java update. If an update is available, a Software Update screen appears. 

You can also manually check for Java 7 updates on OS X with System Preferences -> Java -> Update tab. 


In perhaps the most interesting wrinkle here, both Apple and Mozilla have taken pro-active steps to disable Java in their browsers. 

Apple has disabled Java 7 in Safari on their own. That is, no action was needed by the end user and no messages about the change were issued. Thus, users needing Java were caught by surprise. I have been unable to find anything from Apple stating that they did this, but it is widely documented online that they used a security feature called Xprotect.    

Note that this only applies to Java 7 on Lion and Mountain Lion. Java 6 continues to hum along just fine on Snow Leopard and Java 6 on the newer systems was disabled from running applets back in October. It also should not affect installed applications. 

Mozilla restricted Java in Firefox 17 and 18 using a different approach. For one thing, they restricted both Java 7 and Java 6. Although the latest flaw is exclusive to Java 7, they preferred to be overly cautious.   

Unlike Safari, the blocking in Firefox is easily bypassed. It was implemented using an existing Firefox feature called click-to-play, which prevents plugins from running automatically, but they can be manually invoked just by clicking. Thus, anyone who doesn't read the warning or understand the situation can still get infected. Think of it as a soft block rather than a hard one. 

Where's my Chromebook?  

Updated January 15, 2013 with some minor changes. 

Updated January 16, 2013 to add the paragraph on Internet Exploer 10 on Windows 8. 

Updated January 18, 2013 to add that Java is not Javascript. 


Copyright © 2013 IDG Communications, Inc.

It’s time to break the ChatGPT habit
Shop Tech Products at Amazon