We beg to differ

Op-Ed: Replacing legacy Java applets can’t happen overnight

Elliot Bentley

Security columnist Roger Grimes has declared war on client-side Java, but his suggestions are far from realistic.

“The facts are too
startling to ignore. It’s time to get rid of Java on clients.”
That’s the advice of Roger Grimes,
InfoWorld security columnist
, in response to news that
91% of all web exploits in 2013 used Java

“It’s time for computer security to win out,” rallies
Grimes. “I’m not naïve. I realize this will result in all kinds of
pushback from those who say it’s too difficult to retire Java
applications or rewrite or replace them. But it must be done.”

Grimes’ attitude is a bad stereotype of internal IT
security – like the Dilbert
who declares that “security is more important than
usability; in a perfect world no one would be able to use

The world is, for better or worse, still heavily
dependent on Java applets, a fact which came to light in a dramatic
fashion when headstrong Firefox developers
decided to block it by default

Thanks to a poorly-designed UI, thousands of Firefox
users found themselves unable to activate Java applets – not just
old internal systems either, but essential services such as
Denmark’s national login, which still relies on Java. Overwhelmed
by angry messages, they
quickly changed it back

As Grimes correctly points out, the biggest security
issue is that many companies are afraid to upgrade Java on their
systems, scared of incompatibilities between their ancient software
and the latest patches (which, despite being more secure, are

not without their problems
). But his proposed solution – to
replace the offending Java applications, whatever the cost – is
hardly a realistic option.

Nobody will deny that applets are a dead or at least
dying technology, with HTML5 and JavaScript-based web apps becoming
the new norm (for good reason). Yet the reason maintaining these
legacy systems is defensible is because redesigning these things
costs money. A lot of money. And if the companies using them had
the budget to redevelop them with modern web technologies, they
would likely have done so already.

If these security risks are likely to cause financial
harm, only then is it likely that a portion of an organisation’s
recession-squeezed budget will be allocated to the redevelopment.
And even then, your new, expensive project is
likely to fail
. No wonder organisations are loathe to replacing
these exploit-assisting legacy systems.

Limiting the damage: a quick guide

So if replacing your out-of-date, Java 6-based application is
out of the question, what’s the solution? Well, assuming that
admins have control over employee’s computers, Java should be
blacklisted on every site apart from those internal systems that
need it. This is even possible with Internet
Explorer 6 on Windows XP
, so there’s no excuse not to.

Another method is to simply ensure that all employees are
running a modern browser. The latest versions of Chrome and Firefox
(and presumably most other browsers) automatically block all
versions of Java without user interaction, preventing drive-by
attacks. Combined with a whitelist, this could be very effective at
keeping users safe.

The weak link is where users’ browsers are beyond the
control of admins, such as in the case of Denmark’s national login.
Only in this situation is there an ethical imperative replace Java
– but hey, we all know how
government IT projects
tend to go.

As always, JAXenter’s recommendation for users and companies
with no need for Java applets is to disable
Java in the browser
or uninstall it altogether.

comments powered by Disqus