Open from the start

The Boot 2 Gecko project, which is today known as Firefox OS, started on July 25, 2011 with an email to Mozilla’s dev-platform mailing list by Chris Jones, Brendan Eich, Mike Shaver and myself. In that email we expressed our opinion that as an open-source Mozilla community we should build a web-based smartphone. As a rallying cry and gathering point, we created an empty github repository and Chris and I started filing the first bugzilla bugs for Firefox OS, and started hacking on the first lines of code for Firefox OS.

Firefox OS was completely open from day 1, including the design process as well as the implementation. As we are building Firefox OS today, you can follow along live and jump in and help. You can see the same source live as our device and carrier partners. You don’t have to work for Mozilla (many Firefox OS contributors do not) and you don’t have to ask for permission to help. Just join our IRC channels and mailing lists, and get involved in the design or the code.

Community

Mozilla’s large and diverse base of contributors always included organizations and not just individual contributors. With Firefox OS, the direct engagement of large organizations in the design and implementation of our products has increased tremendously. Qualcomm, Telefonica, Deutsche Telekom, and many others have large product and engineering teams committed to the project, building Firefox OS alongside with us. They are able to do so because of the openness of our processes, and they are motivated to do so, because Firefox OS is the only truly open smartphone platform where everyone who is willing to help can have an equal stake in. Mozilla doesn’t own Firefox OS. We merely care for it.

Last week we wrapped up a major Firefox OS engineering milestone. Leading up to that milestone, Deutsche Telekom Innovation Labs hosted a work week for the project. More than 140 engineers from Mozilla and our key partners attended. We use these work weeks to get engineers into one room who are usually distributed all over the world. Mozilla has offices on every continent, and so do most of our partners.

Below you can see a picture of the team. In the background is our milestone dashboard, showing the total number of bugs remaining, as well as the number of bugs between the frontend team (Gaia, 26) and platform team (Gecko, 50). The frontend and platform teams raced each other for the whole week. On Friday the Gecko team was almost able to catch up, with only 8 bugs remaining by the time the Gaia team hit 0 bugs. Those 8 remaining bugs landed over the weekend after the work week in Berlin.

What can the Web NOT do? And if so, WHY NOT?

We identified a couple of use cases where the Web is intentionally not used today. We are both platform engineers at heart. We wrestle with bits and bytes and CPU and GPU cycles for a living and we understand the Web platform and the implementation thereof (in Mozilla’s case: Gecko) pretty well. For the life of us, we couldn’t figure out why in a few key areas the Web hasn’t progressed as much as elsewhere. Two particular areas we homed in on were plugins and mobile.

Plugins

If you ever had to work on a rendering engine, you probably hate plugins just as much as we do. Plugins are like a thorn in the Web’s side. They are difficult to render efficiently, binary compatibility requirements make the browser-side support code super ugly and hard to maintain, plugins leak memory, plugins can cause all sorts of security issues, and they generally hold back the development of the Web’s native capabilities. A good example of this is Flash: because the Web relied for over a decade on Flash to play back video, the VIDEO element didn’t really take off until pretty recently and some essential capabilities such as adaptive streaming are still missing from the Web stack. Chris and I both worked on the plugin support code in the Firefox, and we agreed that for the better of the Web, we really would like to DELETE that code. There is a large number of plugins out there, but realistically, only a handful matter, including Flash, Acrobat Reader (PDF), and maybe Silverlight (we included Silverlight back then, but by now Microsoft has totally given up on it, so I guess we can as well drop Silverlight from the list). We wondered why Flash and Acrobat Reader are implemented as native code plugins, instead of building the same functionality with HTML5/CSS and JavaScript, and since we didn’t have an answer for that question, we decided we should just build it and see what happens. We started with PDF first, because it seemed like less code to write until we can see whether performance and quality are comparable. A year later, Firefox is about to ship with the JavaScript-based PDF reader we started, so I think it’s safe to say that we found the answer to the question: the Web is ready to render PDF. We didn’t forget about Flash either. A few month later we started the Shumway project, which is still evolving, but might at least partially replace the role of Adobe’s native Flash player in Firefox eventually.

On Canvas and Dashed Lines

A lesser known part of the PDF.js project’s history is that the Web was actually NOT ready to render PDF when we started. We are using the CANVAS element to render PDF documents. We ran across a few loose ends and missing features. Infamously, we pretty quickly discovered that the CANVAS element couldn’t render dashed lines. It seems the spec authors just forgot to include this feature. We ran into this problem 4 days into implementing PDF.js because the first document we chose to render had some dashed lines in it. As it happens, Chris and I are both committers to the Mozilla code base, so Chris whipped up a prototype implementation in Firefox and we posted a proposed spec to the W3C mailing list. Two weeks later Firefox trunk (Nightly) could display dashed lines in the CANVAS element, and pretty soon thereafter a bug was filed for WebKit to add support as well (WebKit is used by Safari and Chrome, amongst others). This approach is the third part of the research group’s mission: Find out what the web can’t do, figure out why not, and FIX IT.

Standards vs Prototypes

The Web is so powerful because it’s not governed by committees and standards bodies. Instead, standards bodies like W3C merely help the Web avoid fragmentation by giving browser vendors a forum to coordinate and collaborate on jointly developed technology. To add dashed lines support, we didn’t have to convince a standards body. Instead, we added a prefixed prototype implementation to Firefox, and within a few months hundreds of millions of Firefox users could start using this feature. This was also the reason WebKit quickly decided to implement dashed lines support: competitive pressure. Firefox could do something WebKit-based browsers couldn’t. This is how the Web evolves. Someone finds a missing feature and implements a prototype for it, and if it’s a good feature, the rest of the browser vendors have little choice than to add support as well. The W3C’s role is to help browser vendors implement the feature in a compatible fashion across the different browser engines. The result is a pace of innovation that is unparalleled in technology history. Hundreds of millions of users had access to a feature after a few months of two engineers realizing that it was missing, and the rest of the Web adopted the same feature another few months later. Compare this to traditional governance by committee approaches such as the Java Community Process and the C++ standards committee where the pace of progress is measured in decades.

Beyond the Desktop

The second area we were interested in was Mobile. How come the Web is so ubiquitous on the desktop, but Mobile content (Apps) is implemented with proprietary native technology such as Java/Dalvik (Android) and ObjectiveC/Cocoa (iOS)? As with plugins, we didn’t have a technical explanation, and as with plugins, we did the same thing to find an answer: build it.

At the time of our first post about Boot 2 Gecko, which later became Firefox OS, Mozilla already had a Mobile product: Firefox for Android. It wasn’t particularly popular because it was pretty slow and memory hungry. We proposed a couple architectural changes to Firefox for Android, in particular abandoning our established XUL frontend toolkit in favor of a native Android UI. Mozilla’s mobile team did a heroic effort to turn the prototype we created into a full product within 6 months. Today, Firefox for Android is one of the most popular third party browsers for Android, and is faster and uses less memory than the native browser on most devices. In contrast to the often crappy browsing experience with the built-in browser, Firefox for Android is actually a pretty decent way to surf the Web on mobile. Yet most people still spend most of their time in native Apps. Why?

Mobile, the neglected red-headed stepchild

If you want to understand why the Web isn’t as popular on Mobile as on Desktop, just surf the Web on a phone: The Web totally blows on Mobile! Almost none of the device capabilities of a modern smartphone were available to the Web around the time we started talking about Boot 2 Gecko: making a phone call, SMS, bluetooth, NFC, proximity sensors, streaming camera access, etc. Name a device capability, and the Web didn’t support it back then. Browser vendors neglected to evolve the Web on Mobile with the same vigor as we did on the Desktop. No wonder content authors choose powerful native APIs instead of writing applications in HTML5!

The solution is pretty trivial and obvious: fix it. Mozilla started the WebAPI campaign as one of the first steps of the Boot 2 Gecko project. We have added dozens of new APIs to HTML5 to support mobile device capabilities, and many of these APIs have already been proposed as new W3C standards in various stages of progress, ranging from prototype specs all the way to final specs implemented across multiple browsers.

Why Mozilla matters

Our existing user-base of hundreds of millions of users gives Mozilla a tremendous amount of influence over Web technology, and this user-base is what enables us to push out new APIs and technologies. Any new device capability we add, we tend to add across all implementations of our browsers, ranging from Firefox OS devices (which are not in market yet), to Firefox Android (which has a ton of users) and Firefox Desktop (which a third of Internet-connected humans use). This gives us a loud voice in standards bodies, and we use that voice to aggressively push the boundaries of what can be done with the Web. Today, HTML5 is as powerful as native APIs, and within a year we have essentially closed the gap between the Web and native APIs when it comes to device capabilities.

Mozilla’s role in helping the Web succeed on Mobile is so critical, because we are driven by very different motives as the other three large browser vendors: Google, Apple and Microsoft. Mozilla is a public benefit non-profit foundation. Our goal is to promote innovation and choice on the Internet. We have no profit motive, and no services or products to sell. We want users to use our products, because they are better than the competition’s. And we want this choice to drive other vendors to advance their products to compete with us. This keeps us honest, and constantly pushes the envelope on Web technology.

Why the Web is going to win Mobile

Today, Firefox on Android is a powerful Web Browser and Web Runtime for Mobile applications. The Firefox Marketplace on Android offers a way for content authors to package HTML5 applications in an easily accessible marketplace that users can download applications from.

In 2013, jointly with our partners we will bring the first Firefox OS devices to market. These devices are completely built with the Web, and as Chris and I suspected a year and a half ago: there is really no technical reason why native technology should prevail on Mobile. In fact, Firefox OS and HTML5 apps are actually often much more CPU and memory efficient than proprietary alternatives such as Android and iOS. We are capitalizing on this fact and we are targeting in particular emerging markets such as Brazil with the first set of Firefox OS devices. The Web will bring smartphones to parts of the world where people can’t afford the expensive high-end smartphones Google, Apple and Microsoft like to compete over.

Only one question remains at this point: Is the Web really going to take off on Mobile? I think the best way to answer this is as follows: picture yourself being an executive at a company such as Facebook and someone pitches a new product to you: Facebook for Windows–a product designed for users to access Facebook from Windows desktops. In all likelihood, you would laugh that person out of the room. Obviously the Web is the way users access content such as Facebook on Desktop. Just the thought of using a native application for this purpose seems surreal and nonsensical. Now replace the word “Windows” with “iOS”, and suddenly everything is different. Obviously there is native Facebook for iOS.

In reality, in a world where the Mobile Web is as powerful as the Desktop Web, Facebook for iOS is just as surreal and nonsensical as Facebook for Windows is for the Desktop. Mozilla has been working tirelessly to create that world, and I think we are getting pretty close. Once we are there, native Mobile apps will be all but forgotten, just as Win32 applications are headed for extinction today.

Why?

While traveling to the Firefox 4 launch parties in Seoul and Taipei all the way from California, we killed a lot of time by brainstorming cool things to do with the web platform. Like many before us, we were wondering why nobody had implemented a PDF reader in HTML5/JavaScript. The kinds of operations a PDF reader needs to be fast at –render text, draw lines, blit images– need to be fast in browsers too, so browsers are already highly optimized for them.

Building an HTML5-based PDF renderer would also answer the question of whether the web platform and in particular canvas and SVG APIs are complete enough to efficiently and faithfully render PDFs.

Displaying PDFs directly in the browser would definitely improve the user’s experience. There are literally millions (billions?) of PDFs floating around the web, and on many devices loading PDFs switches to a different application (e.g. Preview on OS X and PDF View on Android). Also, external PDF readers and many plugins don’t support important PDF features well, including content links and fetch-as-you-go (HTTP range requests).

External readers and plugins are also forced to reinvent their own user interaction paradigms, meaning for example that users might scroll HTML pages in one way with one set of heuristics in the browser, but a totally different way in an external PDF reader.

It’s important to note that we’re not trying to promote PDF to a first-class web citizen like HTML5 is. Instead we hope that a browser-native PDF renderer written on the web platform allows web technologies to subsume PDF.

Benefits

The traditional approach to rendering PDFs in a browser is to use a native-code plugin, either Adobe’s own PDF Reader or other commercial renderers, or some open source alternative (e.g. poppler). From a security perspective, this enlarges the trusted code base, and because of that Google’s Chrome browser goes through quite some pain to sandbox the PDF renderer to avoid code injection attacks. An HTML5-based implementation is completely immune to this class of problems.

Project Status

We have been developing pdf.js in the open (on github.com), albeit quietly, for about a month now. We were waiting on the completion of some major features (Type1 fonts, gradients, etc.) before communicating pdf.js more broadly. We’ve been taken by surprise by the early and intense interest in our work, so we decided to blog and talk about our project earlier than we initially planned.

As part of our project plan, we are initially focused on achieveing pixel-perfect rendering of a single PDF paper, a 2009 paper on Trace Compilation we submitted to the ACM SIGPLAN PLDI conference. As the Tracemonkey work described in the paper led the way for JavaScript JITs, so we hope pdf.js opens the door to implementing legacy formats on top of the web platform.

If you want to see a demo of pdf.js, click on this link. There are still glitches and rendering artifacts, but you will get the picture. We are still missing Type1 PostScript fonts, which Vivien Nicolas is working on.

Along the way, we had to add some new interfaces to the HTML5 canvas element, and figure out how to implement some difficult features of the PDF spec in JavaScript. See Chris’s post for a general technological overview, and Shaon’s post for details on rendering “shading patterns”.

Whats next?

We intend to use pdf.js to render PDFs “natively”, within Firefox itself. Our most immediate goal is to implement the most commonly used PDF features so we can render a large majority of the PDFs found on the web. We believe we can reach that point in less than 3 months (the entire code so far is less than one month old, and it already renders a large set of PDF features).

Initially we will make a Firefox extension available to interested users that enables inline PDF rendering using pdf.js, but our ultimate goal is of course shipping pdf.js with Firefox. This will result in a substantial usability but also security improvement for our users. pdf.js uses only safe web languages and doesn’t contain any native code pieces attackers could exploit.

Open Source

We want pdf.js to be a community driven and governed open-source project. We’ll use it for Firefox, but we think there are many cool applications for it. We would love to see it embedded in other browsers or web applications; because it’s written only in standards-compliant web technologies, the code will run in any compliant browser. We are licensing pdf.js under a very liberal 3-clause BSD license and we welcome external contributors. We are looking forward to your ideas or code to make pdf.js better! Take a look at our github and our wiki, or talk to us on IRC in #pdfjs.

Chris Jones and Andreas Gal (and the pdf.js team)

Whats user data?

User data is any piece of identifiable data about a user. It can be all sorts of obvious stuff like your name, address, birth date, passwords (all of these Sony managed to lose), but also less obvious data such as usage history, communications, and what not. Whether Sony lost the latter is not clear. Some of the information Sony lost clearly should never have been stored in the first place. I understand why Sony asked me for my birth date when I signed up for PSN. Some jurisdictions want you to be a certain age before you can engage in virtual mayhem and violence that is modern video gaming. But why the hell did Sony store this information in a database? Why not just flag my account as “remembers the first techno song being played on the radio, definitely old enough”?

Risks

Storing data is always risky. If you store any data in the cloud, eventually someone will break into it. Investing a lot of money (expensive equipment, expensive practices, expensive staff) helps delaying that day of reconning, but only within limits. There are a lot of financial incentives to steal this kinda of data. Personal information of 70 million people is a fantastic starting point for all sorts of phishing attacks. And even if only one out of 10,000 people getting that Nigerian email falls for it, that’s still plenty of people to take advantage of. Sony took a risk storing user data. Unfortunately, it was not a well calculated risk. They could have easily reduces the fallout from a breach by storing less information, i.e. by not storing the birth date, or maybe even not storing personal information at all! Shocking proposition, I know.

Not knowing is bliss

Why does Sony need the names of its PSN subscribers in the PSN user database to begin with? Let people choose a handle and a password. If you want to personal the experience, let users chose their name. Dear PSN, you may call me Tracemonkey now. You really don’t need to know my real name and address. As for payment information, I think its ok if PSN asks me once a year to re-enter my credit card info, which is then briefly processed but never stored. Had they followed this simple principle of touching (and storing) as little user data as possible, they would have saved themselves a lot of legal trouble and liability.

Browsers

I am not ranting about this topic out of thin air. Web browsers handle a lot of personal information, and its tempting for browser vendors to get in on the whole social networks online transactions online identity game. A number of people at Mozilla don’t seem too comfortable with hosting on our infrastructure any user data ever. Its really scary and risky after all (just ask Sony). I think that’s wrong. We absolutely should get into the key areas of social and identity. Why? Because the state of the art is crappy, and we can do better.

Microsoft Passport anyone?

Web identity is a total mess. I have at least 30 accounts in various places with different account names and passwords (well at least I try). Various organizations and services have tried to established a single login. Microsoft Passport was one of the earlier ones. I am really glad that didn’t work out. Can you imagine the evil empire owning all your personal data and online identity? Microsoft has a lot of incentives to use and abuse such a powerful position, and it certainly does. I still get emails from Microsoft about my Passport account on a regular basis, almost a decade later. Its usually an invitation to try this new Microsoft feature Y or maybe try chatting with my passport account or … well whatever. Microsoft sits on a lot of data, and its tempting to monetize it. And of course its not just them. Everyone else is just as bad. Ever noticed how Google and Facebook customize ads for you based on the data they have about you? Creepy. This is why I think Mozilla can do a lot better. We don’t have any hidden agenda. We don’t have any extra services we want to sell you. We don’t have to monetize data we store to turn a profit and make shareholders happy. We simply don’t have any shareholders. We are a company owned by a non-profit foundation that wants to make the web a better place. This puts us in a much better position to do whats best for our users, instead of whats best for our quarterly statement (we don’t publish any of those in case you didn’t notice.)

Playing it safe

We are currently in the process of figuring out how exactly Mozilla should handle user data. I have exactly zero authority when it comes to these kind of decisions, but Mozilla is a pretty open and democratic place and we tend to discuss this stuff pretty openly, giving anyone a voice who wants to speak up. I think its imperative that we follow a couple guiding principles as we explore ways to better serve our users using services such as identity or social:

1. Always keep the users’ best interest in mind (and only the users’ best interests). I don’t care if we can ship a feature faster or cheaper if we store more user data (or maybe store it not encrypted instead of encrypted). Our new Sync service is a great example for this. Its a total pain in the butt to encrypt the browser history on the client before it is uploaded to our services, but its the right thing to do. It means that in case of Sync we can never see any of your browser history, even if we tried, and your data is safe by default.
2. Always store as little data as possible in the cloud. If there is a way to implement a feature completely in the client without us ever having to see user data, that’s always the right approach, even if its harder. This is exactly the issue we are facing with our new F1 social browsing feature. It allows you to share websites on Facebook/Twitter/etc as you visit them. Its a really cool feature–I use it all the time. Unfortunately, the protocol Facebook/Twitter/etc offer to authenticate and access their APIs (oauth) is totally broken, and conceptually doesn’t really work for client applications. oauth requires the client (Firefox/F1) and Facebook/Twitter/etc to negotiate a shared secret (called the consumer key). With a pure client solution this secret can never be kept (someone could peek into Firefox/F1 and extract the key). It seems Facebook has blacklisted consumer keys before because people checked them into open-source repositories. The only alternative to this is to put the key behind a service Mozilla runs and then let Firefox/F1 post via that service, but that means we would be able to see (in theory, not intentionally of course) all the Facebook/Twitter/etc status updates of millions of people every day. That’s wrong. As tempting and quick as it would be to setup a Mozilla service that keeps the key hidden and posts for users, we should never put ourselves in a position where we handle user data without an overwhelming need for it. In this particular instance we should simply negotiate with Facebook/Twitter/etc to not enforce the shared secret rule (Twitter already doesn’t it seems, since there are so many Twitter client apps out there), and maybe in parallel we should work on better protocols than oauth.

Going fast

As we were discussing these various architectural aspects of how to handle user data (or how not to handle it) the last few weeks, some people were tempted to go the easy route and store a lot more user data (in particular in the clear) than necessary because it might get us to market faster. I think this is wrong for the above two principles, but its also wrong because it will NOT get us to market faster. Dealing with user data from an infrastructure perspective is a total pain. To handle or even store things like Facebook/Twitter/etc account authentication tokens or user contacts, we have to build out a serious security infrastructure. We need to hire expensive, highly trained personnel and we have to seriously tighten our security practices. That doesn’t mean we are unsafe right now. It just means our current practices match our current threat scenarios. For example we have external IT administrators who don’t even work for Mozilla administering our source code repository access controls. They are simply Mozilla project volunteers. Considering the limited risks, this is acceptable. When it comes to storing user data, entirely different standards will be needed. And getting all that sorted out and implemented will require a lot of audits, careful planning … and a lot of time. So if you want to go fast, go zero user data. Or encrypt the user data on the client so all we get to see are blobs of meaningless zeros and ones. That’s how Sync works, and we got it up and running within a couple months. That’s how you go fast.

What’s next?

We are currently discussing what our process will be to store user data. Expect people with actual authority to make decisions (and to talk about them) to start talking about this publicly in a few weeks. I already know that the result of our internal deliberations will be a policy that will focus on what’s best for our users, and that will minimize risks for them (and in the end, for us). And expect a safe and secure implementation of F1 to show up in your browser really soon. You can already try out the prototype now. It really rocks.

This blog post represents my personal opinion, not the official position of Mozilla.

We have implemented a major change to the way Firefox manages JavaScript objects. JavaScript objects include script-instantiated objects such as Arrays or Date objects, but also include JavaScript representations of Document Object Model (DOM) elements, such as input fields or DIV elements. In the past, Firefox held all JavaScript objects in a single JavaScript heap. This heap is occasionally garbage collected, which means the browser walks the entire object graph in the heap and determines which objects are still reachable and which are not. Unreachable objects are de-allocated and space is reclaimed.

Having all JavaScript objects in the browser congregate in a single heap is suboptimal for a number of reasons. If a user has multiple windows (or tabs) open, and one of these windows (or tabs) created a lot of objects, it is likely that many of these objects are no longer reachable (garbage). When the browser detects such a state, it will initiate a garbage collection. Unfortunately though, since objects from different windows (or tabs) are intermixed in the heap, the browser has to walk the entire heap. If a number of idle windows are open, this can be quite wasteful, since those windows haven’t really created any garbage, so whenever a window with heavy activity triggers a garbage collection, much of the garbage collection time is spent walking unrelated parts of the global object graph.

In Firefox this problem is even more pronounced than in other browsers, because our UI code (also called chrome code, not to be confused with Google Chrome) is implemented in JavaScript, and there are a lot of chrome (UI) objects alive at any given moment. These UI objects tend to stick around and every time a web content window causes a garbage collection, Firefox spends a lot of time figuring out whether chrome objects are still alive instead of being able to focus on the active web content window.

Compartments

For Firefox 4 we changed the way JavaScript objects are managed. Our JavaScript engine SpiderMonkey (sometimes also called TraceMonkey and JägerMonkey, which are SpiderMonkey’s trace-compilation and baseline Just-in-Time compilers) now supports multiple JavaScript heaps, which we also call compartments. All objects that belong to a certain origin (such as “http://mail.google.com/” or “http://www.bank.com/”) are placed into a separate compartment. This has a couple very important implications.

• All objects created by a website reside within the same compartment and hence are located in the same memory region. This improves cache utilization by reducing false sharing of cache lines. False sharing occurs when we are trying to operate on an object and we have to read an entire cache line of data into the CPU cache. In the old model JavaScript objects could be co-located with arbitrary other JavaScript objects from other origins. Such cross origin objects are used together very infrequently, which reduces the number of cache hits we get. In the new model most objects touched by a website are tightly packed next to each other in memory, with no cross origin objects in between.
• JavaScript objects (including JavaScript functions, which are objects as well) are only allowed to touch objects in the same compartment. This invariant is very useful for security purposes. The JavaScript engine enforces this requirement at a very low level. It means that a “google.com” object can never accidentally leak into an untrusted website such as “evil.com”. Only a special object type can cross compartment boundaries. We call these objects cross compartment wrappers. We track the creation of these cross compartment wrappers, and thus the JavaScript engine knows at all times what objects from a compartment are kept alive by outside references (through cross compartment wrappers). This allows us to garbage collect individual compartments, in addition to a global collection. We simply assume all objects referenced from outside the compartment to be live, and then walk the object graph inside the compartment. Objects that are found to be disconnected from the graph are discarded. With this new per-compartment garbage collection we shortcut having to walk unrelated heap areas of a window (or tab) that triggered a garbage collection.

Wrappers

Wrappers are not a new concept in Firefox, or browsers in general. In the past we have already used them to regulate how windows (or tabs) pass objects to each other. In the past, when another window (or tab or iframe) tried to touch an object that belongs to a different window, we handed it a wrapper object instead. That wrapper object dynamically checks at access time whether the accessor window (also called the subject) is permitted to access the target object. If one Google Mail window is trying to access another Google Mail window, the access is permitted, because these two windows (or tabs or iframes) are same origin and hence its safe to permit this access. If an untrusted website obtains a reference to a Google Mail DOM element, we hand it the same wrapper, and if it ever tries to access the Google Mail DOM Element the wrapper will at access time deny the property access because the untrusted website “evil.com” is cross origin with “google.com”.

A disadvantage of the Firefox 3.6 wrapper approach (which is similar to the way other browsers utilize wrappers) was the fact that these wrappers had to be injected manually at the right places in the C++ browser implementation, and each wrapper had to do a dynamic security check at access time. With compartments we can do a lot better:

• Since all objects belonging to the same origin are within the same compartment, and no object from a different origin is in that compartment, we can let all objects within a compartment touch other objects in the same compartment without a wrapper in between. Keep in mind that this doesn’t just apply to windows but also to iframes. A single Google Mail session often uses dozens of iframes that all heavily exchange objects with each other. In the past we had to inject wrappers in between that kept performing dynamic security checks. This is no longer necessary, and there is an observable speedup when using iframe heavy web applications such as Google Mail.
• Since all cross origin objects are in a different compartment, any cross origin access that needs to perform a security check can only happen through a cross compartment wrapper. Such a cross compartment wrapper always lives in a source compartment, and accesses a single destination object. When we create a cross compartment wrapper, we consult with the wrapper factory to see what kind of security policy should be applied. When “evil.com” obtains a reference to a “google.com” object, for example, we have to create a wrapper to that object in the “evil.com” compartment. When that wrapper is created the wrapper factory will tell us to apply a stringent cross origin security policy, which makes it impossible for “evil.com” to glean information from the “google.com” window. In contrast to our old wrappers, this security policy is static. Since only “evil.com” objects ever see this wrapper, and it only points to one single DOM element in the destination compartment, the policy doesn’t have to be re-checked at access time. Instead, every time “evil.com” attempts to read information from the DOM element, the access is denied without even comparing the two origins.

Brain Transplants

A particularly interesting oddity of the JavaScript DOM representation is the existence of two objects for each DOM window (or tab or iframe), the inner window and the outer window. This split was implemented by web browsers a few years ago to securely deal with windows being navigated to a new URL. When such a navigation occurs, the inner window object inside the outer window is replaced with a new object, whereas the actual reference to window (which is the outer window) remains unchanged. If such a navigation takes the window to a new origin, we allocate the inner window in the appropriate new compartment. This of course creates now the problem that the outer window can possibly no longer directly point to the new inner window, because it is in a different compartment.

We solve this problem through brain transplants. Whenever an outer window navigates, we copy it into the new destination compartment. The object in the old compartment is transformed into a cross compartment wrapper that points to the newly created object in the destination compartment. So the term brain transplants is very appropriate here. We are essentially transplanting the guts of the outer window object into a new object hull in the same compartment we allocated the inner object in.

Processes

Some readers might wonder how compartments compare to per-tab processes as they are used by Google Chrome and Internet Explorer. Compartments are similar in many ways, but also very different. Both processes and compartments shield JavaScript objects against each other. The most important distinction is that processes offer a stronger separation enforced by the processor hardware, while compartments offer a pure software guarantee. However, on the upside compartments allow much more efficient cross compartment communication that processes code. With compartments cross origin websites can still communicate with each other with a small overhead (governed by certain cross origin access policy), while with processes cross-process JavaScript object access is either impossible or extremely expensive. In a modern browser you will likely see both forms of separation being applied. Two web sites that never have to talk to each other can live in separate processes, while cross origin websites that do want to communicate can use compartments to enhance security and performance.

Future

We have landed the main compartments patch and current nightly builds (and Beta 7) are running with per-origin compartment JavaScript heaps. Some of the functionality described above will not ship until Beta 8, most importantly per-compartment garbage collections. Those currently still happen for all compartments at once. The foundation we laid with the compartments work will also enable a number of future extensions. Since we now cleanly separate objects belonging to different tabs, future changes to our JavaScript engine will permit us to not only perform JavaScript garbage collection for individual compartments, but we will also be able to do so in the background on a different thread for tabs with inactive content (i.e. no event handler is firing at the moment).

Zaphod

Brendan Eich and Mike Shaver have posted an update on our progress on TraceMonkey. There has been a lot of buzz around Google’s new Chrome browsers and its V8 JavaScript VM. Some voices have claimed that V8 is several times faster than TraceMonkey. We did some head to head comparisons and these claims don’t match our observations.

We used Apple’s SunSpider benchmarks for our tests. Depending on the OS and machine configuration we are 1.18x to 1.28x faster than V8. Since V8 is only available for Windows, we didn’t perform any tests on MacOSX and Linux, both of which we support already. Our latest builds also work on ARM, by the way.

I am sure you can derive different results by tweaking the benchmarks or designing entirely new custom benchmarks alltogether, but since SunSpider has been used fairly intensively in the past two years to measure the evolution of JavaScript performance in Safari, Firefox, Opera, and IE, I think SunSpider is probably the most reliable cross-platform benchmarking tool at this point (which doesn’t say that its a particularly good one, its just the best we have right now.)

Talking about IE, our tests also indicate that we are about 15 times faster than IE 7, and about 5 times faster than IE 8 beta on the SunSpider aggregate scores.

If you want to give TraceMonkey a try, take a look at our nightly builds. You can enable the JIT in the about:config settings. The nightly builds are certainly not ready yet for wide-spread use, but we have improved stability significantly since our initial preview release. Firefox with TraceMonkey enabled is now my default browser, and I am writing this post with it.