Apple's Java sabotage is bad IT business

Apple's handling of the Java vulnerability provides a textbook example of what not to do in a production environment

They may not be your customers, but that doesn't mean you should treat them like dirt -- or like idiots, miscreants, dolts, or any other variant of the dreaded "they."

Put it differently: The concept of "internal customer" may not have a place in most modern businesses, but IT shouldn't treat its business collaborators the way Apple treats its actual, external paying customers.

[ Also on InfoWorld: Java security comes down to "war of attrition" | Find out how to block the viruses, worms, and other malware that threaten your business, with hands-on advice from expert contributors in InfoWorld's "Malware Deep Dive" PDF guide. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]

In case you weren't paying attention, last week Apple decided to disable all but the most recent Java browser plug-ins on just about every Macintosh everywhere, without telling anyone. The Java vulnerability that led to the decision is very real. It was coupled, though, with the assumption that its customers -- forgive me, its licensees -- lack the judgment necessary to make this decision for themselves.

To be fair, many of Apple's consumer licensees probably lack the expertise needed to make an informed decision. For many, that's why they bought Macs instead of some form of Windows PC in the first place.

But its enterprise licensees? That's a different matter altogether.

The cost of change by fiat

Let's go back a step. There's this tiresome phrase "best practice" that's been bandied about for the past 10 or 20 years. It should be banned, because while it sounds like it refers to the best way there is to do something, what it usually means is "the minimum standard of basic professionalism."

When it comes to IT, the minimum standard of basic professionalism is that you don't change a production environment without first testing the change to make sure (1) it does what it's supposed to do; and (2) it doesn't break something else that currently works.

Imagine this didn't come from Apple. Imagine the information security department got wind of the Java plug-in's worrisome security holes. (By the way: Codgers who remember, as I do, Java's introduction and the downright gushing plaudits it received for its unbreakable security model -- I hereby give you permission to say, "Pthhhhlpth!" Under Oracle's enlightened product management we're now treated to "hack once, intrude everywhere" security. Brilliant!)

Where was I? Oh, yes -- information security, incensed at Oracle's ongoing unwillingness to fix Java, instructs IT operations to immediately and without warning disable Java in all browsers throughout the enterprise.

What's the proper response? It depends, of course. If information security declares this to be a crisis -- a code-red threat that could sink the company without a trace -- the proper response is to disable Java browser plug-ins everywhere in the enterprise as fast as possible. Afterward, the head of information security should be unceremoniously booted out the door or, better, out an upper-story window or, even better, installed as the head of information security at your fiercest competitor.

Whatever the identified threats, they aren't crisis-level problems, which means IT operations should respond as it does for every other proposed change to production: Prepare an impact analysis. In this case, the impact analysis would reveal whether any business activities would immediately grind to a halt from the change that might cost the company many multiples of any Java-delivered intrusion -- or it might not. That's why change control is what it is.

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform