Analysis I have nothing but the greatest respect for Jon Udell. His "Strategic Developer" column is the first thing I read when my copy of InfoWorld magazine arrives in the mail, and his blog is one of the best if you're interested in the technical aspects of web development, standards, and practices. If blogging is enjoyable because it allows us to watch an interesting mind at work, then Jon Udell's blog is definitely among the most enjoyable.

That doesn't mean I agree with everything he writes, however, and I definitely found myself scratching my head at his perspective in a recent InfoWorld column he wrote: "Greasemonkey in crisis". Before I go any further, though, let's take a brief detour and see just what the heck a Greasemonkey is.

I've been a huge fan of Firefox and its security track record for some time (I've even wrote a book about it!). One of the best things about the browser is the wonderful plethora of extensions that have sprung up for it which enable users to take the browser in some unbelievably useful directions. For instance, when I put Firefox on a new machine, I immediately install some extensions that I consider absolutely essential, including Adblock, CustomizeGoogle, Flashblock, Nuke Anything, Resizeable Textarea, SessionSaver, undoclosetab, and WebmailCompose . If you're interested, you can take a look at the full list of extensions I use with Firefox). One of the most interesting and most powerful extensions around today, though, is known as Greasemonkey.

To understand Greasemonkey, think about Gmail for a moment. Gmail is great, but the guys at Google just don't want you to delete your email; they want you to save it instead. With that goal in mind, they make it easy in the UI to move your email out of your Inbox and into a repository by pressing that always-available Archive button; deleting email, requires that users select a dropdown menu and choose Move to Trash. Not a huge deal, but enough of a UI hurdle that many people won't bother... or won't find it. Sometimes, there is mail that you simple don't want to have archived, indexed, and stored forever.

I find this annoying. I don't want to save every email. Much of it needs to go into the bit bucket, but I grew tired of having to use that dropdown option. Wouldn't it be better if I could somehow magically insert a Delete button next to the Archive button? Well, with Greasemonkey, I can. Here's how.

First I install the Greasemonkey extension, available at their website. I restart Firefox, and then I head over to the Gmail Smart-Delete Button JavaScript. Once the script appears as text in Firefox, I go to the Tools menu and choose Install This User Script. A window appears, asking for confirmation to install this script.

The confirmation window indicates that this script will apply to pages found at this URL: http*://*mail.google.com/*mail/*. Yup. That's where Gmail is. I press OK, and I'm informed that the script is now installed. When I go back to Gmail now, there's a Delete button next to Archive. Cool! (For more technical details about how Greasemonkey works, see the article in Wikipedia, or visit the Greasemonkey site at mozdev.org.)

There are hundreds of Greasemonkey scripts available now, with most of them at the GreaseMonkeyUserScripts wiki page. In general, the scripts are divided into three sets: those that affect all sites (currently 132 scripts), those for specific sites (currently 259 web sites, with several sites, like Google, having well over 50 scripts), and those that modify other Firefox extensions (just one, that changes how the Sage RSS reader behaves). As Aaron Boodman, the "Head Greasemonkey" puts it, Greasemonkey allows you to do four things:

1. Extension - add new features to a page
2. Restriction - remove features from a page
3. Repair - fix a page that is broken or sub-optimal
4. Integrate - add data from other websites to a page

Needless to say, this is very powerful stuff. I know that some of you right now are reading this and starting to get the heebie-jeebies, as well you should. Greasemonkey makes it possible to totally screw up the visuals of the web sites you visit (though of course the sites themselves remain untouched). Further, since you're installing JavaScript scripts, the various security vulnerabilities associated with that technology are front and center. There are other issues as well, which Boodman covers on the 12th slide of his recent presentation at OSCON 2005.

Back in November 2004, Boodman's attitude about possible security issues with Greasemonkey was a bit... oh, shall we say, blasé? "User scripts run in content's security context. I don't see any possible problems..." Oops. Then things really hit the fan on 18 July of this year, when noted developer Mark Pilgrim, an early adopter and evangelist of Greasemonkey, posted a message to the extension's mailing list that was not the kind of news that Boodman and others wanted to hear:

Last week I showed that the complete text of every single one of your locally-installed user scripts could be leaked to remote sites (http://diveintogreasemonkey.org/experiments/script-leak.html), and the reaction from the GM developers was (paraphrasing) 'Yeah, we know about that, but we haven't fixed it yet because it's hard.' I would now like to point out that every single piece of data stored locally with GM_setValue can be leaked to remote sites. Working exploit here: http://diveintogreasemonkey.org/experiments/function-leak.html I feel I've accumulated a fair amount of karma in this fledgling community, and I'm going to burn some of it now by suggesting that this is a BIG F***ING DEAL ...[profanity removed courtesy of SecurityFocus]

Ouch! Sometimes it takes someone smacking you on the side of the head to realize the danger into which you're walking, and Mark Pilgrim's message was a roundhouse. The media picked up on it, Slashdot ran with it, and it became a big deal. Users were advised to either uninstall Greasemonkey, or downgrade to version 0.3.5, which fixed the security problem by neutering the extension's APIs to the point that many, if not most, scripts ceased to function. Finally, on 30 July, a new version of Greasemonkey was released, 0.5.0 beta, that fixed the holes. All in all, though, the whole painful process was a major embarassment for Aaron Boodman and Greasemonkey. Security in any application should never be underestimated.

In the midst of all the excitement, Jon Udell's column, "Greasemonkey in crisis," appeared. Jon Udell is a sharp guy, but I didn't get where he was coming from in some of his statements. For example:

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. 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.

I read a lot of articles in late July covering Greasemonkey's problems, and I don't recall any that turned around and blamed Firefox for an extension's problems. After all, the problem wasn't in the design and engineering of the browser itself, it was with an extension that exposed way too much on users' computers via poorly-implemented APIs.

However, Udell is correct that it was the Greasemonkey developers who shot themselves in the feet. Hubris plus inexperience, plus the lack of a much-needed swat on the skull, meant that Greasemonkey was a major security vulnerability waiting to happen. Happen it did, though, and that's where Udell and I really start to differ.

Yes, Greasemonkey should have worked a lot sooner to make sure that it was "reducing the attack surface area." Agreed. And Microsoft definitely claims that it is working on just that approach to security, which is great - though they've still mulled-over attempts to purchase spyware companies and weaken their own anti-spyware nonetheless.

Why is it that a discussion of open versus closed source source software comes up every time an application vulnerability is found? After all, anything made by humans will contain bugs and problems. The real power of any software model is in its ability to deal with the aftermath of discovered vulnerabilities, not with how it was developed in the first place. In other words, Udell focused on the wrong end of the process. Yes, "reducing the attack surface area" is vitally important, but so is the method in which security problems are dealt with after the surface area gets attacked. The tradeoff between new features and new security holes is in front of us every day.

The discussion about the Greasemonkey hole was on a public mailing list. As soon as the problem was elucidated by Mark Pilgrim, developers sprung into action. The Greasemonkey web page was changed, Aaron Boodman's Greaseblog confronted the issue head on, and the extension's web page at the main Mozilla extension site was updated with warnings for users. All discussions about the best way to fix security problems with Greasemonkey were also conducted openly on the mailing list, and Boodman made sure that he solicited the advice and participation of anyone interested in helping (in fact, Boodman conducted himself in this high-pressure situation with calm and good will, and for that he should be commended). It's all about full disclosure and open discussion! Work continues on Greasemonkey, and that too is available for anyone to check out.

If we must continue the discussion to encompass the model of open source, then I have to say that the approach Greasemonkey took shows what makes open source great: openness. Throughout the whole painful process, information was available to those who needed it: developers, IT folks, users, and security pros. No one was kept in the dark, and all the details - code, communications, thought processes, and so on - were always available so that interested parties could make decisions based on facts instead of promises and conjecture.

Which would you rather have? An open process like that practiced by Greasemonkey, or a closed process like that chosen too often by major vendors like Microsoft (and Cisco, but don't get me started on that debacle)? I know which one I prefer, and which one is ultimately better for all computer and internet users. So it's not Greasemonkey that's in crisis - it's all of us, when closed security practices are the order of the day.

Copyright © 2004,

Scott Granneman is a senior consultant for Bryan Consulting Inc. in St. Louis. He specializes in Internet Services and developing Web applications for corporate, educational, and institutional clients.

Related stories

Mozilla postpones next Firefox release
Firefox update fixes stability glitches
Firefox's Greasemonkey slippery on security