With 'Ubiquity,' Mozilla chooses functionality over security
Mozilla's Ubiquity brings awesome functionality, while at the same time completely punting on end-user security. Is this responsible?
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.
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
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.
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.