With 'Ubiquity,' Mozilla chooses functionality over security

How popular can a piece of software get before being in "beta" is no longer a legitimate excuse for known software flaws? Or, to put it another way, is it responsible to allow hundreds of thousands of people to install your product, when you know ahead of time that doing so opens them up to attack?

The software visionaries at the Mozilla Corporation, which makes the popular Firefox web browser, have taken the approach that creativity and functionality is king--even if security has to take a backseat. Case in point: The widely praised "Ubiquity" software add-on, which brings an amazingly rich and extensible new form of interaction to the Firefox Web browser.

The technology press has showered praise upon the developers of this software tool. However, in prioritizing functionality over security, Mozilla Labs punted complex trust choices to end users--the vast majority of whom are ill-equipped to make such decisions. The end result is that the hundreds of thousands of users of Ubiquity face a significant risk of browser hijacking by attackers, which could result in the theft of e-mail and online banking account information.

The Ubiquity add-on brings a new form of command-driven interaction to the Firefox Web browser. Using the tool, a user can perform actions based on the contents of a page--such as translating the foreign text on a page into English, or generating a Google map of a highlighted address. While this is certainly cool, it is the extreme extendability of Ubiquity that makes it a truly compelling tool.

One of the main design goals for Ubiquity was that it should be extremely easy for users to be able to create their own commands, which they could then share with others. As a result, a useful command can be whipped together in a couple lines of JavaScript--for example, allowing a user to send a Twitter message from within the browser. Aza Raskin, the head of User Experience at Mozilla Labs summed up the goals of Ubiquity in a blog post introducing the tool:

The fundamental problem is that extending the browser, and hence the Web, is too difficult. The closer new browser functionality can be packaged to look like standard HTML and (Javascript), the larger and more diverse a community will create it. The desktop paradigm for extension development, while powerful, has a high cost of adoption. Right now we have a short tail of browser functionality with thousands of add-ons. There should be millions. We can get to that long tail using a more Web-like model for functionality development--tools that are accessible to hobbyists and tinkerers, but that scales to professionals.

Mozilla Labs was hugely successful, and within a week of the first public beta release of Ubiquity, over 100,000 users downloaded and installed the tool. Even more telling, is the number of commands that have been created and shared by users. The Ubiquity Wiki lists 300-plus different commands, while Mozilla's Raskin wrote in his blog that "thousands of commands (have been) written for Ubiquity" and that "in under a week, we have a roughly comparable number of Ubiquity commands as there are Firefox extensions."

Mozilla does not release stats on the number of downloads, but given the rapid adoption of the browser add-on, it is quite reasonable to assume that by now it has been installed by at least 250,000 users, if not far more.

No security, no problem

The success of Ubiquity has come at a high cost--the Mozilla Labs team completely punted on the issue of security, and made users responsible for judging the safety of downloadable Javascript, something that few of the hundreds of thousands of its users are likely able to do.

When a user wishes to install one of the thousands of publicly available Ubiquity commands, they are first taken to bright red warning screen. The user is clearly told the risks that they face should they accidentally install a malicious command, and then they are given the opportunity to read through the command's JavaScript source code in order to see if it is good or evil.

The vast majority of the users on the Web are not able to read JavaScript. Even those skilled users that know enough to throw together a Ubiquity command or two are unlikely to be able to properly assess the security of someone else's code. This point can be clearly driven home by looking at the success of the Underhanded C Programming Contest, in which users submit code that "looks" clean and safe, but which actually performs evil actions.

Furthermore, while Mozilla has been surprisingly frank with users about the risks they face when installing commands, this approach of education and disclaimers is simply not enough. It is totally unreasonable to offer a shiny, awesome and powerful new tool to the Internet at large if clicking on a wrong link could result in a user suffering identity theft or worse. Bruce Schneier has often said that humans are really bad at judging risk, and so of course, the vast majority of Ubiquity's users are going to install foreign and unknown commands, simply because they offer awesome functionality.

In addition to the general problems of untrusted JavaScript, Ubiquity also suffers from significant security issues due to the ability to auto-update commands. By checking a box, a user can permit the browser to automatically upgrade commands whenever the author releases a new version. This option creates two major issues.

First, a developer could release a legitimately useful command, wait until thousands of users have subscribed to it, and then send out a malicious update to those users that have enabled auto-updates. Since users only get to see the JavaScript at the time of first install, they face significant risks from future malicious updates.

Second, command updates are currently served via non-encrypted HTTP connections, and the Ubiquity infrastructure lacks the code-signing functionality that is provided to Mozilla add-ons. This creates a significant potential for man-in-the-middle attacks against the Ubiquity update process, particularly when users are connected to the Internet via a public wireless network. Last year, I revealed that a number of toolbars for the Firefox 2.0 browser were vulnerable to this same type of attack. This flaw was eventually fixed by moving the distribution of commercial browser-addon updates to SSL-encrypted servers.

The Mozilla Labs team has recognized these risks, and has plans to fix them at some point in the future. However, for now, users of Ubquity remain vulnerable to attackers, particularly those who have opted to allow automatic updates of commands.

In releasing Ubiquity, the Mozilla team also created a Web site it calls the Herd, which enables users to opt-in to reporting which commands they have installed. Thus, one assumes, if 20,000 other users have installed a command, it is probably safer than one that five other people are using. While better than nothing, Herd is still very new, and due to the pro-privacy opt-in model chosen for data reporting, it only captures a small slice of the Ubiquity user base.

When asked to comment on some of the security issues, Aza Raskin issued the following statement regarding security issues in Ubiquity:

Mozilla Labs is a shared space for exploration for future user experiences on the open Web. It's a place where we, as a part of larger community, can experiment and iterate on new ways of interacting with the Web, having the Web fundamentally enhance the browsing experience. It's also a place where we can safely explore new security and trust models among a technically savvy group, before bringing them to a wider audience.

The Herd is one way of trying to involve the community as a corner-stone of solving the security problem. It's still in its infancy. We are working towards creating an open API so that everyone can pitch in to create a safe place for everyday users to get commands. Just like Ubiquity UI not being right yet, neither is the Herd.

Eventually, I expect there to be hybrid models. Mozilla, and other trusted sources (think folks like Bruce Schneier), will vet core and recommended commands. The Herd, enhanced by numerous metrics of "browser health," will constantly be watching for bad actors. Clearly, we don't expect end users to need to read code--and we do plan on adding manifests of some form to sandbox certain types of commands. Right now, however, the emphasis is on empowering verb authors to be generative.

Raskin did not answer specific questions posed by this blogger, and neither he nor Dan Veditz, Mozilla's security lead, would confirm if the Ubiquity code base was audited by members of Mozilla's security team before being released to hundreds of thousands of users. I'd be willing to bet a few beers that it hasn't.

There is of course a legitimate reason to release beta software, even when it has known security flaws. Were Ubiquity available only to those Web programmers proficient in JavaScript, this wouldn't be an issue. However, when hundreds of thousands of people are using your product, you can no longer reasonably hide behind the claim of "beta."