Hi! My name is Brian Warner. Welcome to my blog!<\/p>\n
I’ve been working at Mozilla for about a year and a half. Before Mozilla I was at a startup (now gone) named AllMyData.com, which ran an online backup service aimed at home users and small businesses. For the backend, we developed an open-source encrypted distributed filesystem named Tahoe-LAFS<\/a> (still thriving), with the relatively-unique feature of “provider-independent security”: the servers hold ciphertext, and only your client (and anyone you choose to share them with) holds the decryption key. By relying upon the servers for availability but not<\/strong> security, you can use servers that you wouldn’t trust otherwise. The system is designed with “POLA” in mind, the Principle Of Least Authority, which improves safety by giving each component as little power as possible; just enough to do its one job.<\/p>\n Mozilla’s Sync<\/a> system, which helps keep your bookmarks and other browser data synchronized between multiple browsers, uses the same principle. The data is encrypted before it leaves your computer, and our servers don’t get to see the key. The similarity in philosophy between Sync and Tahoe was a big part of the reason I joined Mozilla: I had found a bunch of like-minded people with whom I could promote these ideas, with a wider audience (400 million users and counting!) than anything our tiny startup could reach. Shortly after joining, I helped build the credential-exchange protocol that Sync uses to add a new computer to your account (the “copy this code” J-PAKE-based dialog panel).<\/p>\n But most of what I’ve been doing for the last 18 months is Jetpack<\/a>, now better known as the Add-On SDK<\/strong>. It’s a new way to tackle the admittedly painful process of writing add-ons for Firefox (and eventually other XUL-based programs, like Thunderbird).<\/p>\n Add-ons in Firefox have always been a bit.. organic. There’s an awful lot of internal interfaces, and add-ons authors have had to dig through a lot of that to find a useful point to attach or override some code. It’s messy, and fragile: it’s difficult for the Firefox developers to keep those internals stable while making large-scale improvements to the browser, so add-on authors are fighting an uphill battle to maintain compatibility with newer releases. With our new faster release cadence (every couple months!), the problem becomes even more challenging.<\/p>\n Jetpack was intended to make the simple things simple. It has a library of interface modules for doing common add-on tasks, like creating a UI, and modifying web pages. We, the SDK authors, will keep updating these modules to match the Firefox internals, so add-on authors won’t have to. One of the promises of Jetpack is that the high-level add-on code doesn’t need to change much at all to keep up with newer browsers.<\/p>\n The SDK has two parts: this library of modules, and a program that assembles your code with the right set of modules and produces the XPI file, ready for installation or upload to AMO<\/a>. If you think about it in terms of gcc and other compilers, this program is a linker: it figures out which modules are required and combines them into an executable bundle.<\/p>\n The linker is written in Python, and since that’s been my dominant language for the last ten years, most of my Jetpack work has been on the linker side. I’ve also been heavily involved in developing the security model, to make Jetpack-based addons safer in the face of bugs and compromises. I’ll be explaining a lot more about the security model in this blog over the coming months.<\/p>\n