Just Browsing

The Future of Firefox Extensions: Make Them More Like Web Apps

A few years ago, having just started work on a very ambitious (and now defunct) Firefox extension, my business partner and I met with some of the Mozilla top brass to pick their brains. One of the most interesting tidbits that we walked away with was the rough estimate that only 5% of Firefox users install even one extension. This figure was based, I believe, on an approximation of the total size of the Firefox user base combined with figures from Mozilla’s add-on site, which tracks “update pings” (which the browser uses to check whether new versions of any extensions are available). I don’t know how much that percentage has changed in the interim, but it’s probably safe to say that it is still a pretty small number.

This is striking because extensions are Firefox’s killer app. Opera has widgets. Safari has web clips. These overlap somewhat with extension functionality but fall far short in power and scope. Internet Explorer comes closest with its add-ons, but despite heroic efforts on the part of Microsoft (and a very flexible component-based architecture) they remain a rather staid affair compared with the vibrant Firefox ecosystem. Reducing footprint, boosting performance, improving standards support and adding cool new features are all great, but the limitness possibilities offered by extensions are what truly sets Firefox apart from the pack.

It is in this spirit, perhaps, that Dave Townsend asks what’s next for add-ons (which include themes and plugins as well as extensions) once Firefox 3 is out the door.

Looking at this question first from the supply-side: what can Mozilla do to make it easier for developers to create extensions? I’ve developed quite a few extensions in my day, but I still grit my teeth whenever I have to write a new one. One problem is the plethora of languages that can (and often must) be used. Any web developer worth their salt has mastered HTML and JavaScript. But do they also have a handle on XUL, XPCOM, XPIDL, XBL and a smattering of RDF?

If extensions could be written purely in HTML and JavaScript (both of which are evolving in ways that make this more feasible), this would flatten the learning curve considerably. FUEL is a big step in the right direction, replacing strange-looking (in a scripting environment) XPCOM APIs with more natural JavaScript equivalents, but it could go much much further. Proper tool support would have a truly revolutionary effect. Templates in XCode and Visual Studio generate boilerplate automatically for iPhone apps, ActiveX controls and the like, removing much of the tedious busy work from the process. How about providing the same (in these and other environments like Eclipse) for Firefox extensions?

This would help to build on the already impressive library of available add-ons, but it wouldn’t in itself entice more users to give them a try. My favorite improvement tops Dave’s list as well: allowing add-on install without requiring a browser restart. This is famously tricky, and would require modifications to existing extensions, but it would be well worth the effort. People will be more willing to experiment if they can install an extension and play with it (and remove it if it doesn’t catch their fancy) without having to shutdown Firefox every time.

But by far the biggest benefit would come from a more robust sandboxing model. Extensions are an all-or-nothing affair; install one and you give it complete control over your computer. If it decides to scan your disk for deviant porn and post an exhaustive list (with handy thumbnails) to your Facebook account, there isn’t a thing you can do about it. Except, of course, to avoid downloading it in the first place, which is why add-ons throw up a host of security roadblocks: a domain whitelist, an intentionally annoying nag screen and the new digitally signed update manifests.

But most extensions don’t rely on any dangerous capabilities to do their job. The need to access the local disk is greatly tempered by new offline storage capabilites. They rarely use more than a tiny subset of available XPCOM interfaces. And while any extension can include binary components that give it carte blanche to do with your computer as it will, only a handful take advantage of this unbridled power. The vast majority don’t need to since all they do, for the most part, is modify your browser chrome (adding toolbars, sidebars and/or status bar panels), tweak the contents of web pages and provide more immediate access to specific links or data.

This isn’t to say that we should remove the heavy artillery entirely. When you need it, you really need it, and some of the coolest extensions take advantage of Firefox’s exceptional flexibility. The answer is to have a two-tiered platform. Most extensions can explicitly forgo the scary stuff and benefit, in exchange, from reduced security requirements. This would give users the confidence to try out extensions from untrusted sites in the same way that we don’t hesitate to visit an unknown website, firm in the knowledge that it can’t do anything too terrible. Extensions that need unfettered access would still require the same signatures, nag screens and other security roadblocks.

As a result, most extensions would be like normal web apps that happen to be able to hook into the browser chrome and stick around when you surf away from the website where you got them. Ease-of-installation and airtight sandboxing have served web apps so well that they may eventually take over almost the entire application space. The best way to take the Firefox extension ecosystem to the next level is to follow their example.