First posted to MSDN on Aug, 12 2014
The push to get modern continues, and one big piece of news last week was our announcement that we are adding functionality to block really old versions of specific ActiveX controls, particularly Java.
http://blogs.msdn.com/b/ie/archive/2014/08/06/internet-explorer-begins-blocking-out-of-date-act...
Now, this isn’t completely revolutionary. In fact, we’re not even the first ones to do it – Java itself currently tells you when it’s out of date. What it can’t do is tell you if it’s out of date on versions before they added this feature…
http://java.com/en/download/faq/expire_date.xml
And, even if you don’t get a warning, the Java site spells out in no uncertain terms that running old versions is a terrible idea, much like getting involved in a land war in Asia, or going in against a Sicilian when death is on the line.
http://www.java.com/en/download/faq/remove_olderversions.xml
As one of my friends likes to say (I’m pretty sure it’s
Aaron
who says this, but not positive – what I am certain of is that I totally stole it): if you don’t want to consider your organization a fully owned subsidiary of either the Russian Mafia or the Chinese Government, then don’t run anything other than the latest version of Java,
if you have to run Java at all
. Not that there’s some magic evil-attractant there, but because just about every organization in the world (by which I mean every organization I have ever spoken to, ever, in any medium) locks in on a specific version of Java and then doesn’t update it. And the bad guys know this, so when a new version comes out with security fixes, they figure out what was broken, build exploits, and then they work, nearly everywhere, for a really long time. Which makes exploiting those vulnerabilities for fun and profit entirely too easy.
So, naturally, when we announced that we want to help people avoid doing one of the most risky things they could possibly do, people immediately began demanding to know how we could stop helping them avoid that. By golly, they want their crusty old Java. Not because of some bizarre emotional baggage and separation anxiety, mind you, but because of app compat. They have stuff that still depends on the old versions of Java.
Which is, itself, a fascinating concept – allowing a software vendor to demand that, to get their support, you have to run unsupported on a framework component that puts you in one of the most vulnerable positions in all of computing. Rather like buying a new car radio that demands to be installed in a 1988 Yugo in order to prevent voiding the warranty, and oh, by the way, that Yugo has a bear in the back. A bear holding a shark.
But in the end, customers have to make a difficult choice, because no good one is left to them. They can have the software that actually helps them make or sell products, keep people alive, pay employees, etc. land in a supported state, or they can just have the platform supported but not have software that actually does what they need to do. And choosing to not go out of business is really a good choice, it’s just a shame that folks have to make the decision to risk catastrophically going out of business with a well-publicized exploit to avoid going out of business in a far less spectacular way. I don’t envy the folks who are put in this position. Particularly as most of the time, this choice is forced by nothing more than a version check – an app refusing to run on an unfamiliar platform like a petulant child, with no technical basis for that demand.
So, my inbox was of course flooded with requests for the KB number of the update so folks could block it from going out, and they could continue to run legacy versions of Java successfully.
Here’s the thing – this is designed as a consumer feature. It’s designed to help people like my mom, who is never, ever going to check for new versions of Java. Like, ever. And, for the enterprise, it’s designed to make it safer when surfing the big bad Internet.
For the enterprise, focus in on this particular part of the article:
“…but not the Local Intranet Zone and the Trusted Sites Zone…”
It bears repeating:
We don’t believe that blocking old versions of ActiveX controls will impact the enterprise because we’re excluding the two zones that enterprise apps live in: Local Intranet and Trusted Sites.
I phrase it as “we don’t believe” very deliberately, because it happens all the time that we have reasoned our way to some conclusion, and we haven’t seen a side of the problem that invalidates our conclusion. So, if you believe you have a reason why this impacts you, and you are an enterprise, then we’re curious to understand the scenario. But otherwise, our expectation is that we’ve built a feature that protects your users when you’re surfing the big bad internet, blocking potentially malicious sites from instantiating a vulnerable control on your users’ devices, while continuing to allow it for internal sites. This feature should make you safer without having a significant compatibility impact.
