Home of the Mozilla Identity team
We’ve received a lot of very useful feedback on the Mozilla Labs’ BrowserID project. We want to take a moment to focus on the privacy aspects of BrowserID and what we’re trying to accomplish. For background information, you may want to skim our original announcement and Lloyd Hilaiel’s explanation of how BrowserID works.
We designed the BrowserID experiment to increase user convenience and safety online. Using our Privacy & Data Operating Principles as guidelines, we built a system that seeks to maximize user privacy and control by shrinking the user-data minefield, disclosing information to sites only on a need-to-know basis, employing a model that is intuitive and users understand, and limiting tracking of browsing behavior while also enabling pseudonymity online.
The Verified Email Protocol that underlies BrowserID is focused on simply letting users prove that, at a particular moment, they own a specific e-mail address. We believe that is a good thing for user privacy and we’re reaching out to the privacy community to validate this and answer additional questions about our BrowserID work.
In today’s Web, users are exposed to data breach risks because most websites implement their own login system. Because website implementors don’t (and shouldn’t have to) specialize in login systems, they are often not as secure as they could be. Not only that, but most websites use a password-based system, encouraging users to reuse passwords or pick ones that are too simple, which can create additional risks. BrowserID gives sites an easy solution to deploy which minimizes the chances of implementation mistakes.
Additionally, because users don’t need to remember a password for every site, BrowserID reduces the potential damage that would result from a data breach. That’s good for everyone on the Web.
As we mentioned in our last blog post, BrowserID is different from other federated ID protocols in one crucial respect: When a user logs in to a website using a Google, Yahoo, Facebook, Twitter or any OpenID account, their identity provider (Google, etc.) is inextricably involved in the transaction. This means that the ID providers know every time you log into a site with credentials they’ve issued. The physical analogy would be if the DMV were notified of every location where you use your driver’s license to prove your identity. We think that’s an unnecessary data leak.
With BrowserID, the identity provider is on a need-to-know basis: the login process between user and website will use a digital certificate provided by the identity provider, which means the identity provider will be represented by proxy, much like the DMV is represented by the seal on your driver’s license, but never directly involved in the login flow. Once we implement native support in a future browser add-on, not even browserid.org will have access to which sites you are signing into, as the browser itself will handle mediation of the certificate.
User privacy is better protected if the user understands the information transaction in which they partake. People have different personas, in real life and online. Most users already associate e-mail addresses with personas and understand, for example, the difference between their personal and professional e-mails. They probably wouldn’t reveal their personal e-mail address to co-workers.
It’s hard to overstate the importance of this pre-existing user intuition. Logging into an online project management website? Use your work e-mail. Logging into your spouse’s photo album? Use your personal e-mail. We don’t need to reinvent a mental model for users. And because users understand the decisions they are being asked to make, they can choose when to consent to disclose their identity or not. This might be obvious, but it’s worth emphasizing that BrowserID does nothing without the user’s explicit consent!
BrowserID uses cryptographic keys only to ensure the identity provider is not involved in the login process. We never use a key for more than one e-mail-device pair, and a key is not available to a website until the user signs in. In the next phase of experimentation we will implement support for certificates, and we will limit their lifetime to a short period of time. These measures in BrowserID mean that no new identifiers (or “correlation factors”) are introduced which would make it easier for sites to track a users movement on the Web, nor to correlate their distinct identities.
Furthermore, with an architecture based on e-mail addresses as identifiers, we can tap into existing techniques for pseudonymity. Users can set up single-use e-mail addresses in combination with BrowserID. We plan on experimenting with ways to make this pseudonym creation even easier. Once the user’s browser is part of the login flow, new privacy-protecting features based are easier to build.
Stay tuned as we’ll share more information as the BrowserID project evolves. If you have any questions, please don’t hesitate to ask us, either on our mailing list or via Twitter, using hashtag #browserid.
—
The Mozilla Identity Team
