More ActiveX Restrictions

By Larry Seltzer  |  Posted 2006-02-02 Print this article Print

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.

For advice on how to secure your network and applications, as well as the latest security news, visit Ziff Davis Internets 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; 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. Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at Security Center Editor Larry Seltzers Weblog. More from Larry Seltzer

Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel