Apple’s browser goes to version 6.0.4 on OS X 10.7 and 10.8 (Lion and Mountain Lion), and to 5.1.19 on Macs that are still running 10.6 (Snow Leopard).
The key change that the new version brings to the party is finer-grained control over Java applets in the browser.
At this point, you’re probably asking yourself, “Why?”
We even recorded a dedicated Techknow podcast entitled All about Java to help you make up your own mind on how to manage the risks.
Listen to the podcast, duration 16’19”.
We weren’t alone in proposing such a blunt-edged tool to deal with the threat from browser-based Java exploits.
But our advice hasn’t been universally popular.
Some readers and listeners hit back at us for being unworldly, pointing out that an all-or-nothing approach to Java in the browser just isn’t practical in their world.
→ One reader, a contractor to an aerospace company that relies on website Java for outsiders to upload their work, pointed out that for him it was a choice between getting paid and following our advice. Other readers told us that their financial institutions insist on browser-based Java for internet banking. And some sysadmins noted that they were required to support in-house applets that wouldn’t work with the latest Java versions, forcing them not only to enable Java but also to leave it unpatched.
Even users who were keen to take our advice were stuck at the thorny question, “How do I know whether I need Java or not?”
So Apple has headed towards a middle ground in which Safari allows you to authorise some applets, blocks others outright, and asks you what you want to do with all the rest.
The feature appears in the Security tab in Safari’s Preferences pane:
The Allow Java tick-box isn’t an all-or-nothing option any more, sporting as it does a shiny new Manage Website Settings... button next to it.
When you first enable Java, all applets on all sites are in an “ask me” state, provoking a question like this when you come across them:
Annoying though this may seem, it’s actually a good way of helping you answer that question, “What do I need Java for, if anything?”
Once you’ve encountered an applet-serving web page, you can click into the Manage Website Settings... window and choose one of four options for the future:
There’s a subtle difference between Allow and Allow Always, and it’s important to understand it.
The former option will run the relevant applet next time you visit the page, provided that you’ve kept your Java installation up-to-date; if you haven’t, you’ll get a handy warning:
The latter option, Allow Always, overrides the version check, and is obviously intended for use only in stubborn cases, such as legacy applets that require an older, insecure Java version.
As Apple advises:
This setting is only recommended for trusted websites that require the Java web plug-in, such as websites that are only accessible on your company's intranet.
For sysadmins who support OS X users on a corporate network, or for contractors like our aerospace worker above, this feature is a good starting point for a “have your cake and eat it” approach to Java in the browser.
But it is far from perfect, not least because there’s no easy way to pre-populate the allowlist, and no way to lock down the blocklist.
So, even in an environment where users are keen to do the right thing, mistakes are not only possible, but likely, especially when it comes to the free-for-all Allow Always option.
Intrepid sysadmins, however, might be willing to knit their own scripts for pre-configuring the allowlist (for example, to pre-authorise a set of intranet applets) after taking a look Safari’s plist file.
Use the plutil (property list utility) command to dump your Safari configuration in human-readable form:
If you’ve added any applets to the control list via Safari’s warning dialogs, you’ll see how they are recorded near the end of the XML data:
The four possible values of the Manage Website Settings options shown above are encoded into the PluginPolicy key as one of four strings:
The plist is usually in binary format, but if you convert it to XML and edit it, Safari itself will happily load the XML version next time you start it.
With that, a determined sysadmin should have enough information to write a script that automatically populates users’ WhitelistedBlockedPlugins settings with an appropriate applet list.
And that, in a nutshell, is the new “control Java in your browser” feature in Safari, at least on OS X.
Windows users of Safari, assuming there are any left, are out of luck: as far as we can tell, Safari for Windows is still back on version 5.1.7, which came out last year.