Opinion: For many reasons the writing is on the blog for the much-maligned programming interface.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 it's going to make a big splash when it hits the scenes. Even though it's a better browser on Windows Vista than on earlier versions of the operating system, it's got some impressive features on Windows XP as well. Many of them come from Microsoft's willingness to adopt a Firefox feature or abandon something that's been in IE for years. Consider the way IE 7 starts what I think is a long-term shift away from ActiveX.
I've 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 it's a major source of vulnerability and an object of attack. None of this is true, but truth isn't the only thing that matters.
My interest in all this was piqued by Microsoft's 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.
Click here to read about how support for AJAX development is rising.
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 isn't. 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 don't 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.
So what's 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 don't think so. I'm 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.
For advice on how to secure your network and applications, as well as the latest security news, visit Ziff Davis Internet's Security IT Hub.
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; that's how I would see it if I were a developer or in IT.
I've already said that Microsoft has gone down this road because customers asked for it, and I'm sure that's 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 you'll 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; that's 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 won't be as big a blow for security as some will think, but it's a step forward, and it's a further admission that default settings for Internet-facing programs should be restrictive. That's the long-term destination for Windows.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Check out eWEEK.com's for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's Weblog.
More from Larry Seltzer
Web Design 
