January 11, 2010

Evolving Firefox Extensions

Firefox’s extension platform is incredibly powerful and generative, but when I created my first extension in early 2008, I found a number of barriers to entry—difficulties echoed by a number of other newcomers I talked to.

For one thing, extensions were difficult to get started with. Perhaps the best indicator of this is Myk Melez’s video tutorial titled Extensions Bootcamp: Zero to “Hello World” in 45 Minutes, which actually ended up being 90 minutes long.

In May of 2009, we tried to resolve a number of issues for newcomers with our original Jetpack Prototype. The complex (but powerful) Gecko API was hidden behind a much simpler facade; no tedious setup was required to get up and running, and the effect of changing any part of your code was nearly instantaneous, obviating the need for restarts when developing or even installing a new Jetpack. Familiar, well-documented technologies like HTML and CSS were used to build interfaces.

Yet there were a lot of things lacking in this prototype. For one, Jetpacks created by developers required the Jetpack extension to be installed in order to use them. There was no mechanism for code sharing and reuse—not even any kind of packaging system, which made building on another person’s work or creating more complex Jetpacks very cumbersome. It also had no security model, which meant that Jetpack developers were effectively playing with a loaded gun: a single mistake in a Jetpack’s code could actually blow a security hole in Firefox that might expose the user’s computer to all kinds of threats from the web.

We wanted to fix all of these problems, but the one that presented the most challenge to us was that of solving what Jonathan Zittrain calls The Generative Dilemma: is it possible to make Firefox Extensions safer without compromising generativity? The sheer inventiveness of the Add-on Community—NoScript, Adblock Plus, Greasemonkey, and the tens of thousands of other add-ons out there—never would’ve been possible if Firefox’s extension platform wasn’t as powerful as it is. Enforcing some kind of “top-down” security model on Jetpack that told developers what they could and couldn’t do simply didn’t feel right.

Instead, it felt like a better solution would be to create the conditions for a secure platform and allow anyone to create capabilities that securely expose privileged functionality to it. Such capabilities, or superpowers as we sometimes call them, can expose any part of the Mozilla platform—which means that it’s theoretically possible for a Jetpack to do anything that a normal extension can do, while still obeying the Principle of Least Authority.

There’s a number of other features present in the latest in-progress iteration of Jetpack, which we’re calling the “reboot” because rebuilding it from the ground-up with the new goals in mind was much easier than continuing to hack on prototype code. We’re now using the CommonJS standard to make it easier to reuse code between Jetpack and other JavaScript-based platforms like the Web and narwhal, for example; Jetpacks are also now fully self-contained XPIs that require nothing but a Mozilla-powered application to run.

There’s a lot more to the reboot, but it’s all a little overwhelming to write up in one blog post. This is an indicator that I should’ve started blogging about this a lot earlier than today, and I apologize for that.

While the reboot is still in-progress and won’t be ready for “prime time” for quite a while, you’re welcome to check out the in-progress Reboot Quickstart and the various JEPs it links to. Please feel free to leave comments on this blog or post them directly to the Jetpack Google Group.

© Atul Varma 2017