Single Point of Failure

When I was working in the day job, on Friday afternoons I used to cruise home with pervasive relief that the working week was over.

One Friday this was spoiled when I called in to my local filling station, only to find that they were unable to sell any fuel because the computer controlling their pumps was down.

Once home, I received an email from our older daughter complaining that all Java access from her Mac had ceased, and asking me how to fix it; as she relies on Java to study remotely, she could no longer access important tutorial work. Like many other Mac users around the world, her Mac had suddenly been told to block Java because of its threat.

At the end of January 2013, Apple’s security group put Java 1.6.0_37 on its blacklist. OS X’s XProtect tool, which each day checks that list, then automatically blocked Java.

Some ingenious users discovered that you could, if prepared to take the risk, nullify this blacklisting by manually editing the XProtect.meta.plist file, but the next time that your Mac updated its list, within 24 hours, the block would be reapplied.

The cure was an update to Java 1.6.0_39, but Apple did not release that until early on 2 February (UK time), when it appeared as Java for Mac OS X v10.6 Update 12.

Undoubtedly Apple would have wanted you to know that it was only doing what had to be done: a serious vulnerability had been discovered in Java 1.6.0_37 which was being exploited by malware.

However Oracle, Java’s owner since it bought Sun in 2009-10, whilst assuring us that it has a “relentless commitment to fostering a community of participation and transparency”, showed startling relent in the face of this communal catastrophe. Given that security and robustness against this type of problem was one of Java’s big selling points, we should be more than a little troubled.

A generation ago, when said daughter first started school, filling your car up and studying remotely were slightly more ponderous, but not prone to single points of failure.

When a shop’s (or bank’s) card authorisation system went down, you could always pay by cheque. Most systems in everyday life had readily accessible fallbacks that you could rely on when the system of first choice was not available. Maybe it was because we were used to things failing: just as my grandmother did, I still keep candles and torches in the house in case there is a power outage, and tins of food that we could eat unheated, for when our microwave and gas supply fail simultaneously.

It appears that the larger the organisation, the less importance it places on such contingency planning.

Although it was commendable from a security viewpoint that OS X should automatically disable vulnerable releases of Java, nowhere did Apple warn users that had happened – or if they did, it was hidden away in obscurity.

And like it or not, there are a plethora of systems, businesses, and other organisations that have come to rely on Java. Apple did not appear to consider what their alternative was, as it was a day or two later that a suitably patched and permitted update became available, leaving those reliant on Java paralysed by this single point of failure.

Since then, the Java situation has only worsened. Now Apple washes its hands of Java updates altogether, leaving those to Oracle and to individual users. But its XProtect tool periodically continues to disable old versions of Java when new security flaws are found.

Perhaps the message from back in our recent long, cold, hard winters was that you should seek out and address your single points of vulnerability. I was able to go back to the same filling station the following day and top up my tank, having kept plenty of fuel in reserve.

If you are still relying on Java, then now may be the time to switch.

Updated from the original, which was first published in MacUser volume 29 issue 05, 2013.