ActiveX controls control users as well as applications
While ASP took over server-side scripting, Web developers had been, since 1995, building client-server applications using Sun's powerful and free Java language, in the form of Java applets that ran right in a browser window. Java applets gave users the look and feel of traditional Windows client applications, with the advantage of cross-server and cross-client portability. Java applets were locked out of most direct OS access by a runtime container called the Java sandbox, to help mitigate potential Java-based security threats.
IE initially supported Java, and users had no problems accessing Java-enabled sites, or using Java-based utilities, from their desktop computers.
But shortly after releasing ASP in late 1996, Microsoft bundled some back-shelf technology -- Object Linking and Embedding -- and renamed it ActiveX. ActiveX gave users a useful, but proprietary, alternative to Sun's open and portable Java applets. Programs written in ActiveX, called ActiveX controls, were automatically downloaded and installed on the user's computer by the IE 3.0 browser. Owing to the proprietary nature of Microsoft's ActiveX runtime support, no other browser could execute ActiveX controls. But ActiveX controls provided more access to internal Windows functionality -- something Java blocked with its sandbox security model. This flexibility made ActiveX easy for Microsoft-oriented application developers to use, leading to its rapid proliferation.
ActiveX's looser security stance made it a favorite vector for so-called drive-by viruses, which infected users simply visiting contaminated Web sites. Microsoft eventually beefed up ActiveX security as part of its User Account Protection (UAP) feature in Vista. But Microsoft also added a kill-bit feature to ActiveX that lets it unilaterally shut down any vendor's rogue ActiveX controls across the Internet. Microsoft promises it would never use its kill-bit power maliciously, but the kill-bit technology has opened at least one new vulnerability already exploited by hackers.
The availability of free ActiveX controls for Windows often supplanted more portable Java-based third-party applications, a problem that persists to this day. It's still possible to encounter Web sites that require ActiveX controls, locking out non-Windows users (and non-IE browsers on Windows as well), particularly for sites that have rich content, such as streaming video or audio. Eventually Microsoft booted Java out of the Windows installer, although users can still download Java runtime support directly from Sun (which is the process of being acquired by Oracle).
Microsoft's ActiveX and abandonment of Java undoubtedly limited Java's success as a client-side Web application enabler.
Microsoft dispatches AutoPatcher with a dispatch
At the dawn of the new millennium, Microsoft was not treating security as seriously as it does today. As a result, Windows desktop users suffered an embarrassing series of Internet-borne maladies, resulting in increasingly frequent security patches from Microsoft.
Microsoft only distributed patches through online downloads via IE, directly into each computer, often releasing patches on the second Tuesday of each month -- a day known both then and today as Patch Tuesday. Some Patch Tuesday patches were quite large, and the effect of dozens or hundreds of computers in a network all trying to download on the same day created administrative headaches.
In 2003, after a particularly vicious malware infection called the Blaster worm resulted in a litany of patches, system administrator Jason Kelley released a free batch script he called AutoPatcher. AutoPatcher bundled sets of Microsoft updates into an easily distributed file that could be installed on multiple computers without Internet access, circumventing Microsoft Update's download storm.
AutoPatcher gave system administrators a much faster update process, but also let administrators apply cumulative patches to new computers without exposing them to the network and possible malware infection. Over the next four years, AutoPatcher became a staple utility for network administrators.
Then, on Aug. 29, 2007, Microsoft sent AutoPatcher's authors a cease-and-desist notice demanding an immediate end to AutoPatcher distribution. Intimidated by Microsoft's threat of imminent legal action and lacking financial resources to fight back, the authors complied. AutoPatcher's Web site went dark in a single day.