I just finished reading The Value of Nothing, which provides a fascinating counterpoint to all of this. Its author, Raj Patel, doesn’t hate markets—he just wants to pluck from them “the overriding hunger for expansion and profit that has brought us to the brink of ecological catastrophe”. He also believes that what needs to be plucked from us is “the belief that markets are the only way to value our world”.

This last quote is something that resonates with me. Some of today’s most prolific companies rely on what I find to be odd business models: they make the money they need to survive as a fortuitous “side effect” that is relatively independent of their utility to the vast majority of their constituents. Firefox, for instance, relies on a sharing economy—open-source, community-driven development—to build a product that is mostly financed through something that few people are even aware of: the ads that a tiny percentage of users click on after performing Google searches at the upper-right hand corner of their browser.

These sorts of tactics strike me as clever “hacks” to capitalism. Obviously creating a browser like Firefox and making the Web a better place is something a lot of people value—yet this value isn’t really captured by the market.

The Value of Nothing is an exploration of alternative ways of valuing ourselves and our world, from Free Software to Food Sovereignty. Coincidentally or not, many characteristics of these alternatives—they are all transparent, participatory, and de-centralized—happen to share a lot in common with what makes the Web better.

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.

I thought it’d be useful for both folks on the periphery and on the inside to use images as a way of understanding what’s going on at Mozilla—sort of like about:mozilla, but using pictures instead of words.

Here’s what I’ve got so far:

This prototype is a showcase of what happened in the Mozilla community during the month of November 2009. It includes community-created artwork, photography, screenshots, logos, and UX sketches and mock-ups. Mousing over each thumbnail displays a high-resolution version of the image on the lower half of the screen, dynamically fetched to take advantage of the viewer’s screen resolution without wasting network bandwidth.

The mini-gallery is stored using an ad-hoc sort of HTML microformat. Feel free to take a look at the source code and reuse or remix it for your own purposes.

(A word of warning: I’ve only tried out this prototype on Firefox 3.5 and Safari 4.)

1. It was slow.
2. It showed the entire Firefox JS heap, which included lots of objects internal to Firefox that weren’t of much use to web developers.
3. It was a bit of a hassle to set up, as it involved freezing Firefox and accessing a local web server from a different browser.

I’ve spent some time trying to resolve these issues, and have a usable prototype for Firefox 3.5 that you can try out. The new tool has an entirely different front-end from the last one and runs in Firefox itself—no need to launch a separate browser. It also runs a lot faster, and allows you to profile the JavaScript memory use of individual browser tabs.

Here’s a screenshot. You can also click on it to read some annotations I’ve added through Flickr:

The above profile was taken while this page was open in a tab. Feel free to look at the page’s source code and compare it with the profiling output.

One of the first things you’ll notice is that there’s no information about actual bytes used. This is partly because we need to add more instrumentation to Firefox in order to get you really accurate information about that—something that’s currently being done with the advent of about:memory. But it’s also because raw byte counts aren’t necessarily helpful in debugging memory leaks in web applications: what’s really useful is information about what kinds of objects are staying in the page, which this new iteration of the memory tool tries to provide.

If you’re interested in learning how the tool works or hacking on the code, check out the wiki page and my Fun with SpiderMonkey blog post.

What I’m really interested in knowing is: do web developers find this useful? What could be added to it to make it more useful in diagnosing the memory use of a web application? If you’re a web developer, please download the addon, choose “Memory Profiler” from the “Tools” menu in Firefox, and let us know what you think!

Another factor to consider is how you define what “your data” is. For example, if you look at it as just exporting your photos out of Picasa and importing them to flickr, I’d posit that’s a rather simplistic view. A large part of what makes your data useful and valuable is all the relationships associated with it. I share my photos with my friends and family, I license some under Creative Commons, I group them, I tag them – all of these make my data very context rich. How do you liberate this context? And if you do, what does it mean to import them elsewhere?

On a public forum I used to frequent, one user used to immediately delete all his posts whenever he lost an argument. In the context of Data Liberation, this could be considered a good thing: his posts were his data, not the property of the company (or rather, the volunteer community member) hosting the data. But on the other hand, his behavior also made entire conversations completely inscrutable to everyone else in the community. What used to be an interesting public dialogue between two people suddenly became one person talking at a wall.

It’s very easy to assume that the things we create are ours, and not some corporation’s: but what happens when you give what you created to someone, or to a community, or to the public? Does the ownership of that information become theirs to any extent?

If you take a photograph and give it to your grandma, what kind of rights should you have to take it back? Should grandma have the freedom to copy the photo you gave her—by posting it to your photo stream on Flickr—to her computer’s hard drive before you delete it from Flickr? Or should you have the freedom to be able to magically zap your data from her hard drive?

Who actually owns the data?

Python, at its heart, is a platform that’s built to be extended. The evidence for this is plentiful: there’s modules and packages out there that offer practically any functionality you want, from web servers to 3D game engines to natural language processing toolkits and more, all instantly accessible through a simple command or an installer download. Yet one of the costs of all this generativity has been the fact that Python doesn’t really have much of a security model to speak of: any Python program has as much access to the underlying system as the current user does, which, compared to the Web, is basically omnipotence. Creating programs that obey the principle of least privilege is pretty hard.

JavaScript, on the other hand, has many of the opposite problems. For one thing, it’s really built for embedding: until the very recent advent of CommonJS and Narwhal, for instance, the language has always lacked a general-purpose platform and standard library. A Pythonic way of saying this is that the language doesn’t come with “batteries included”, but this can actually be a good thing from a security standpoint: because the simplest possible embedding has no privileges and needs to be explicitly given all its capabilities by its embedder, it’s very easy to follow the principle of least privilege. Recent work on membranes and capability models puts JavaScript way ahead of many other languages in the security realm, yet the lack of a mature general-purpose platform has meant that anyone who’s wanted to leverage these strengths has always had to muck around in C/C++ to create the kind of embedding they wanted.

Well, to an extent. One of the many aspects of Java that I’ve frequently been envious of has been Rhino, a JavaScript engine written entirely in Java, which allows anyone who knows Java to create their own embedding solution that leverages Java’s strengths. But I prefer Python to Java, and moreover, the engine itself isn’t worked on with as much intensity as the JS engines that power real-world consumer products like V8 and SpiderMonkey—so new language features are slow to be implemented and performance isn’t great.

I’d briefly tried resurrecting John J. Lee’s Python-Spidermonkey last year but I soon discovered that it wasn’t really what I wanted. For instance, JS objects were copied into Python approximations as they crossed the language boundary, which resulted in a “lossy” transfer and prevented features like identity perseverance. It was essentially a high-level wrapper created to solve a specific problem, rather than a low-level tool intended to enable any kind of wrapping based on context (e.g., how trusted the JS code is).

Introductions

In part because of all this, and in part because I’d always wanted to write a Python C extension from scratch, I’ve decided to create a new Python-Spidermonkey bridge: Pydermonkey.

Pydermonkey’s mission is pretty simple and straightforward: it’s just meant to wrap Spidermonkey’s C API as faithfully as possible—including its debugging API—while enforcing the memory safety that Python is known for. This makes it awfully low-level for casual programmers, but thanks to Python’s awesome support for magic methods, it’s not hard to create high-level wrappers that provide much more convenient bridging between JavaScript and Python code.

Where It’s At

Pydermonkey is currently at version 0.0.6; its API supports a decent subset of the Spidermonkey C API, but it’s still quite lacking in places: operation callbacks will allow you to run untrusted code that runs in infinite loops, throw hooks allow for full Python-esque stack tracebacks of JS code, yet property catchalls haven’t yet been implemented, which means that security is constrained to conventional sandboxing (membranes and object capabilities aren’t currently possible). There’s also the nasty problem of not being able to detect reference cycles that cross language boundaries, which means that such cycles need to be broken manually for now.

Getting It

Pydermonkey is available at the Python Package Index in source form, and as a precompiled binary for the few platforms that I happen to have access to at the moment.

You should be able to type easy_install pydermonkey at the command line and everything should “just work”: I’ve set up the Paver build script such that the Spidermonkey source code is automatically downloaded and built before the C extension if you’ve got the compiler toolchain on your system, though there are a few snags on Windows to circumnavigate. For more information, read the Pydermonkey documentation. And please feel free to file a bug if you run into one!

Where To Go From Here

If you’d like to see an example of a high-level wrapper, check out my Pydertron experiment. It provides a simple interface to expose untrusted JS functionality to Python code and also contains a CommonJS-compliant implementation of the SecurableModule standard. I’m also playing around with creating a Pydermonkey engine for Narwhal on github; contributions to any of these codebases are more than welcome, and there’s some low-hanging fruit in Pydermonkey that would be perfect for students or first-time contributors.

Finally, if you do anything interesting with Pydermonkey, I’d love to know about it.

My favorite technical book as a child was Creating Adventure Games On Your Computer, which contained plain BASIC code for games that you could play, augment, and make your own. A column in one of my favorite magazines, 3-2-1 Contact, featured the same kind of content.

All of this was easy enough for a child to grasp—often far easier, as Jef Raskin observed in The Humane Interface, than today’s development tools. But being able to use a tool that provided an incredibly low barrier to generativity is something that I value a lot about my childhood. It’s in part where a lot of the real passion and excitement for open source and the Open Web come from: people like me see in them the qualities that made them truly excited about computers as a kid. Qualities that we’re constantly in danger of losing today as the field becomes more professionalized and controlled.

So that got me thinking about Drumbeat again: what if promotional materials for the Open Web focused on how it makes lives better for children who are budding hackers? Lots of adults aren’t tech savvy, but they know that their kids are, and if we can prove that the Open Web is better for their kids, and that they can make their kids’ lives better by choosing a standards-compliant browser, maybe they will.

After playing around with this idea for a bit, I came up with this:

The photo on the page is taken from Flickr user .sick sad little world.’s The Taste of Ink. Feel free to get the source and remix!

Transparency Chic discusses a Firefox addon called RECAP which helps make U.S. Judicial Records as freely-searchable as everything in Google by taking any of the free information browsed through PACER, the Federal court system’s clunky web-based database that charges eight cents per page, and submits it automatically to a free Internet archive.

One of the foundational principles of the Internet RECAP reminds me of is Jonathan Zittrain’s notion, explained in The Future of the Internet, that the endpoint matters. Cell phones, console gaming systems, and PCs are some of the destinations of the information and functionality that the Internet is built to transmit. Yet only the PC unilaterally provides its user with an extraordinary amount of control to alter any aspect of its behavior through third-party software. If it weren’t for this fact, and if it weren’t for the generativity enabled by Firefox exposing its internals to addon developers—that “freedom at the endpoint”—a subversive-yet-legal tool like RECAP simply couldn’t exist and be so accessible to so many people at once.

Of course, this isn’t to say that freedom at the endpoint doesn’t carry with it a slew of safety concerns, like viruses and malware—but these are problems we want to be able to solve without losing the freedom that makes our endpoints as innovative as they are. Drumbeat should raise awareness about this notion because it’s a freedom most of us take for granted, and it’s one that could easily disappear if stewards aren’t there to protect it.

This issue is quite subtle, and fully explaining it is beyond the scope of this blog post. If you know JavaScript, I recommend checking out the Caja Specification, which nicely lays out the problems inherent in running code with different trust levels in the same environment.

Firefox has to deal with this issue because much of it is actually written in JavaScript. Developers call the JS that powers Firefox chrome JavaScript: it has the ability to write to the filesystem, launch other programs on your computer, and pretty much anything that Firefox itself can do. The code that runs in web pages, on the other hand, is called content JavaScript. Chrome and content JS can interact with each other securely thanks to XPConnect wrappers: little layers of code that “wrap” objects and mediate access between them and the outside world. The self-proclaimed WrapMaster and implementer of most of these wrappers is Blake Kaplan, known in some circles as “Mr. B-Kap” (mrbkap).

Google Caja’s team also has a need for the same kind of functionality, but at a different level: they need to make it possible for web pages themselves able to run code that they don’t trust, which is useful when creating plug-in frameworks for web applications. The Caja team calls wrappers membranes—a word which I find more intuitive than “wrappers” because it’s not an overloaded term in computer science and because its biological definition closely matches that of its CS counterpart.

As I wrote in Jetpack: Summer 2009 State of Security, Part 1, the boundary between trusted and untrusted code has been of some concern to the Jetpack project. Unfortunately, all the XPConnect wrappers currently in Firefox have very specific purposes: for instance, most of them are made expressly to prevent omnipotent chrome code from being exploited by impotent content code. Jetpack’s needs are unique in that a Jetpack feature should be neither as omnipotent as Firefox, nor as impotent as a web page: ideally, we should follow the principle of least privilege and give it the minimum set of capabilities it needs to do its task, and no more.

After talking with the Firefox JS and Google Caja teams, we decided that wrappers were the right kind of solution to Jetpack’s security challenges. The problem was, though, that all of Firefox’s wrappers are in C++, which made them hard to experiment with. Jetpack is, after all, a Labs project, and as such, we needed a sort of “flexible membrane” whose security characteristics we could easily change as the platform evolved. So we decided to expose some functionality to chrome JavaScript that’s traditionally only available to C/C++ code.

One nice aspect of the flexible membranes we’ve created is that they’re useful for more than just prototyping membranes: they effectively allow chrome JS to create objects with characteristics that the JavaScript language doesn’t traditionally make room for, like catch-alls for object properties. Python programmers know of these by names like __getattr__ and __setattr__, and many other dynamic languages have them, but JavaScript doesn’t—yet something like them is needed to implement basic Web APIs like HTML5 localStorage. In other words, these flexible membranes should make it easy for us to develop nicer APIs for Jetpack.

If you’re interested in digging into these flexible membranes, check out our Binary Components documentation on the wiki. And feel free to take the pre-compiled component from our HG repository and use it in your own Firefox extensions.

I don’t really expect many people to read it, but at least it’s out there for anyone who wants to learn more. Mozilla gives us a “budget” of 250 cards to order, so I’ve only ordered 75 of these; I’ll come up with something more visual and fun for the other cards.