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.

12 Replies to “Evolving Firefox Extensions”

  1. The XPI self-contained is an incredible important news.

    Is it possible to import more scripts present into XPI instead of having a long long unique jetpack script?

    Something like


  2. @dafi: Yep, we’re using the CommonJS module standard. 🙂

    @Fabrice: Sorry for that confusion; we’ll have to update the link on the labs post. I’ll post a comment to your bug so we can continue working on that in the reboot—thanks for contributing!

  3. Does the fact that jetpacks are now XPIs mean that the “no restart after install” feature will be implemented for traditionnal add-ons ?

  4. @Fabrice: That’s correct! We don’t have a bug filed for it yet, still need to do that, but the idea is that if an extension includes certain metadata in its install.rdf that essentially tells Firefox “look, I know how to unload all my resources reliably”, then Firefox will trust it and call a certain function whenever the extension needs to unload itself.

    That said, actually making an extension capable of unloading all its resources on demand isn’t easy, though, but Jetpack itself is being designed from the ground-up with this in mind. Nonetheless, we’d like to leave the ‘hook’ in there for traditional extensions to take advantage of, if extension authors are willing to put the effort in to add resource unloading functionality to their code.

  5. @Fabrice: I’ll just elaborate a little. Plans are naturally in flux right now but the idea is to allow XPI packages to install without restarts if they wish, however there will be constraints. They will be responsible for doing everything themselves, which means (at least in my head right now) we won’t automatically load chrome or components from these extensions. Instead we will just do startup and shutdown calls into the extension and allow it to register/unregister what it needs by itself. This means that just marking an existing extension to work without restarts wouldn’t get you anywhere, you still need to do the extra work to handle the startup/shutdown parts.

  6. Yarr, what Mossop said. Right now the XPIs generated by the Jetpack reboot don’t even have a chrome.manifest, and while they currently have an XPCOM component to “bootstrap” themselves, this will be converted into a separate “bootstrap.js” script once support for loading such a script is added to the Extension Manager.

  7. Hello Atul – re security issues (see Generative/Principal Least Auth posts) in JetPack: we use XBL binding and anonymous content markup to insert a glorified textbox (we call it a ‘slide’) on a webpage. Using this anonymous-markup widget users can communicate with each other using some backend XHR communications. We have no fear of a malicious webpage trying to scrape the text of the messages people send to each other using our widget (before we have a chance to encrypt it) because the anonymous bits make it invisible to the web page.

    Will JetPack retain/offer some kind of ‘anonymous’ content methodology? Will it use/allow XBL bindings?

Comments are closed.