Greasemonkey in crisis

Aaron Boodman hopes that he will never live through a July 18 worse than this past one. Boodman is a co-developer of the popular Greasemonkey extension for Firefox which, on that day, was found to have a severe security flaw that could enable a rogue script on a Web page to read local files and send them over the Internet.

The next few days were a blur. Developers debated alternate solutions on the Greasemonkey mailing list. Slashdot ran Boodman’s nightmare headline. A provisional fix was created that closed the security hole but also neutered one of Greasemonkey’s most powerful AJAXian (Asynchronous JavaScript and XML) features: the capability of its user scripts to send and receive data using the XMLHttpRequest object. A solution was expected that would restore this capability to the user scripts while denying it to the Web pages into which those scripts are injected. By midweek, however, that solution was not yet available.

As the dust began to settle, a debate began, refracted through the lens of ideology. This time there was no Microsoft to blame. The open source underdogs had done this to themselves. And while some would argue it wasn’t Firefox’s fault -- since Greasemonkey is a user-installed extension -- Firefox took its share of the blame, just as Internet Explorer does when its add-ins cause trouble.

Two familiar threads wove through the ensuing discussion. First, there was the perennial complaint that AJAX-style scripting is inherently dangerous and should always be disallowed. This objection has merit, but it applies equally to other forms of browser augmentation, including ActiveX, Java, and .Net. A thicket of thorny issues surrounds this scenario. How, for example, can users evaluate the trustworthiness of plug-ins or the developers who create them? How can sandboxed environments sufficiently empower developers while preserving meaningful isolation of risk?

There are no perfect answers to these questions. At the moment, we don’t even have good ones. If you, therefore, decide to reject all rich Internet application scenarios that add risk, I won’t try to talk you out of it. Extreme conservatism is a valid stance. If, however, you believe the benefits ultimately outweigh risks, and that we can work through the issues, then let’s consider the second thread woven through last week’s discussion: the techniques and mindsets that open source developers and Microsoft developers bring to matters of security.

Some say that open source software is inherently secure because the “open source process” makes it so. Wrong. Open source software, and the collaborative culture that surrounds it, have surely enhanced Firefox’s security. But also necessary is a disciplined approach to reducing the attack surface area. And one of the most vocal and visible proponents of that discipline today is ... Microsoft.

The recent turnaround of the company’s IIS (Internet Information Services) Web server was remarkable. Version 6 is rock-solid and arguably safer than Apache. If the long-delayed refresh of Internet Explorer has been rethought along similar lines, it could prove to be an excellent platform on which to safely tap into the power of AJAX -- which, after all, Microsoft invented.

The open source and Microsoft cultures can complement one another. I hope they will. If we’re going to safely enjoy the benefits of AJAX-style computing, we’ll need all the help we can get.