eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The Microsoft of recent decades has been much more willing than in the past to cast its own bright ideas aside and do what its customers want instead. Every few weeks we see another example of this in Internet Explorer 7.
The more I see of IE 7 the more I think its going to make a big splash when it hits the scenes. Even though its a better browser on Windows Vista than on earlier versions of the operating system, its got some impressive features on Windows XP as well. Many of them come from Microsofts willingness to adopt a Firefox feature or abandon something thats been in IE for years. Consider the way IE 7 starts what I think is a long-term shift away from ActiveX.
Ive always thought ActiveX got a bum rap, all things considered. From Day 1 it has been the subject of dire predictions and warnings, and a conventional wisdom has emerged among some that its a major source of vulnerability and an object of attack. None of this is true, but truth isnt the only thing that matters.
My interest in all this was piqued by Microsofts announcement (typically, for these days, through a blog) that IE7 will have a native XMLHTTPRequest object as opposed to one implemented in an ActiveX control, as is the case with IE 6.
XMLHTTPRequest, which allows Web-based scripts to themselves perform HTTP transactions, is one of the main enabling features of AJAX, a new generation of Web applications with rich (for a browser) user interfaces. Microsoft really is the pioneer of such things starting with their Outlook Web Access.
The fact that XMLHTTPRequest in IE 7 will be a native control will matter very little to programmers who will simply need to include a few lines of script to test for the native control and use it, or the ActiveX version of it isnt. This is something that needs to be done only once, and so can be done once in a central include file or a global.asa, and the bulk of the software will remain unmodified. Actually, they dont even really need to do make that change. If your program uses the ActiveX version it will continue to work, but you will have new possibilities.
Next page: More ActiveX restrictions.
More ActiveX Restrictions
So whats the advantage of the native control? It means you can block all ActiveX controls and still do AJAX. Why would Microsoft do this? Do they think the XMLHTTPRequest object is unsafe? I dont think so. Im more inclined to believe that customers asked for it, and the company wants their customers to be happy and stick with IE, especially now that Firefox presents a credible alternative. But whatever the merits of their desire to do so, it means that some customers, important ones, want to avoid ActiveX, and Microsoft is willing to help them out.
IE 7 goes further in the move away from ActiveX: A new feature (really more of a design mandate) called “ActiveX Opt-in” dictates that only a few, very popular and well-vetted controls (like Flash) will work at all in the default IE7 setup. All others will be disabled by default, even if they have been previously installed on the system. Pages that invoke these disabled controls will cause IE7 to show one of the now-familiar “information bars” at the top of the browser window, and the user will have to explicitly approve execution of the control.
Opt-In is something that will affect many users, causing them to have to make security decisions and, no matter how hard Microsoft tries, roughing up the user experience. Put another way, it will discourage the use of ActiveX by developers and corporate IT; thats how I would see it if I were a developer or in IT.
Ive already said that Microsoft has gone down this road because customers asked for it, and Im sure thats true, but there might be another reason: the Eolas patent. After losing rulings in a patent suit Microsoft was forced to make the process of invoking embedded content, such as ActiveX controls, more difficult. (The patent itself is famous nonsense, among the most obviously flawed youll ever see, but lawyers, it seems, can make up the rules as they go along.)
Put another way, these changes will discourage the use of ActiveX by developers and corporate IT; thats how I would see them if I were a developer or in IT.
What are the options? Obviously ActiveX served many legitimate, as well as illegitimate, purposes all these years. I see a series of answers, mostly resolving down to two approaches: AJAX-type interfaces will mitigate the need to resort to native code on the client, especially when combined with richer server-side code.
Also, if enough of the few approved controls provide programming interfaces themselves, then developers who might have gone through ActiveX can use them as alternatives. The obvious ones are Java and Flash (and Sparkle?). Of course, this puts the security onus on the developers of those systems. Neither of them is perfect, and the same corporate types who are nudging Microsoft away from ActiveX probably frown on Java and Flash as well.
This slow march away from ActiveX will probably tend to increase security generally because it will tend to make it harder for developers to get their code running on users systems, especially for native code on the client. This wont be as big a blow for security as some will think, but its a step forward, and its a further admission that default settings for Internet-facing programs should be restrictive. Thats the long-term destination for Windows.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer