X
Tech

Microsoft blocking of old ActiveX not enough

It's a good thing that IE will warn you before running outdated versions of important ActiveX controls, but it's such a small thing compared to what Microsoft could do.
Written by Larry Seltzer, Contributor

For about the last 12 years Microsoft has been cleaning up security messes in Windows that the company created in prior years. Next Tuesday — Patch Tuesday — the company will be adding another feature to clean up old messes, i.e. the ability to block old versions of ActiveX controls, a very common exploit vector on Windows.

My colleague Ed Bott calls this change "monumental," and it is important, especially as it focuses initially on the single greatest problem in this area, Oracle's Java. But it's not monumental enough for me. Microsoft could take a true giant step towards solving the update problem with third-party Windows programs by allowing third parties to plug into the Windows Update mechanism. It's clear that Microsoft is not going to do this, which limits it to comparatively small changes such as the one in the news now. This new change is certainly a good thing, but it leaves me wanting. It is an improvement on some of Microsoft's other hack solutions, such as delivering ActiveX kill bits through Windows Update.

What if Microsoft could make it really, really easy for the vast majority of users to keep key third party programs up to date? To do this it would need to leverage one of its greatest assets, the Windows Update infrastructure. It should allow third parties to deliver their updates using Windows Update, a process which is automatic by default on all Windows systems for many years, and which users have learned to trust.

If this sounds familiar, it may be because I've been making this arguement for almost 10 years, most recently last fall. I've never gotten a straight answer on it, but it's clear to me that Microsoft doesn't want to be responsible for delivering other people's code. That seems like a perfectly reasonable argument until you consider that the Windows Store model for Windows 8+ and Windows Phone (and, to a lesser extent, Xbox) is built around being the sole source for delivering everyone else's code, including the latest updates. At the same time, Microsoft integrates Adobe Flash into Internet Explorer 10 and later.

App development rules for these environments are strict and the developers must pay Microsoft for the privilege of being a developer and of testing and hosting their apps. But the problems are far from insurmountable. For one thing, I see no reason why Microsoft would need to host anyone else's code. For another, Microsoft could set terms for allowing third parties into the system.

One option would be for the Windows Update servers to serve code hosted on other vendors' servers. Or Microsoft could license Windows Update server software to the third parties to run on their own servers, and their installation process could configure the Windows Update client to look for updates on those servers as well. Or Microsoft could host the third party code

Would Oracle, Adobe and others want to have Microsoft deliver their code rather than do it themselves? There are good reasons why they would want it: First, their update infrastructures cost money to run. Many vendors would still need to serve updates to Mac and Linux users, so they still would need an infrastructure, but the demand on it and the bandwidth consumed would be greatly lessened.

Second, it would likely give their customers a better experience, especially medium-size organizations which could easily use WSUS to manage the updates. Think of it as just another operating system service, and all ISVs use lots of operating system services. If I were Microsoft I would price the service to break even so as to encourage adoption as much as possible, but there's nothing wrong with making money on it.

But it's not going to happen. If it were going to happen, it would have happened already. I would feel better about it all if I saw the new Modern UI apps taking over the market, but signs of that are scarce. As Windows desktop programs persist, so will the problem of old versions.

Editorial standards