Browser ID

We usually leave the coding details of BrowserID to the mailing list. However, we deployed a change last Thursday that unfortunately broke a few sites that use BrowserID, so we want to help fix this issue ASAP. First, we’re sorry. We thought the API ... [More] change was safe given our logs, but we didn’t look carefully enough. We’ll be working on a better process for backwards-incompatible API changes, even if we think the change shouldn’t break sites. We don’t expect this to happen very often, of course. So, what’s the issue? Once your web site obtains an assertion of the user’s email address, it calls the verifier to check the assertion. The verifier call, which used to be a GET request, must now be a POST. The reason for this change is simply that the length of our assertions has grown quite a bit, and we need to be sure that we don’t hit limits of HTTP client libraries and proxies. The complete developer instructions have been updated accordingly. If you have questions, please join our mailing list. [Less]

Yesterday, in our weekly BrowserID release, we included a brand new design for the BrowserID website and popup dialog. The login flow is streamlined, the colors and overall design are more subtle, and the transitions are clearer. Try it out on ... [More] myfavoritebeer or OpenPhoto and let us know what you think on the mailing list or by tweeting with #BrowserID. Those sites, like all BrowserID sites, automatically inherited the new user experience, of course. [Less]

A few weeks ago, I presented an overview of the BrowserID architecture especially as it pertains to privacy. We’ve got the video online now (30 minutes of presentation, 30 minutes of Q&A): as well as the slides. Meanwhile, BrowserID ... [More] development is moving along rapidly. We just deployed the certificate architecture, which brings the implementation much more closely in line with the design. This means we’re one big step closer to supporting primary identity providers, where individual domains will be able to certify their own users rather than go through the BrowserID email verification process. We expect to have progress on that in the next couple of months. We’ve also got a brand new user experience in the pipeline, which we’ll tell you more about next week. As always, we welcome your feedback on our mailing list! [Less]

Last week Mozilla held an All-Hands, and it was exciting to see so many people learning, teaching, and discussing all things Mozilla. The Identity team gave a short demonstration of the latest version of BrowserID during the opening keynote, and we ... [More] have a recording we can share with you: In the demo you’ll see an overview of BrowserID, but also some new features we’re prototyping. One feature that highlights how BrowserID can significantly improve the user experience of web login is something we call “primary authority” support. The idea is simple: your email provider or corporate intranet is a primary authority for your email account with them. BrowserID provides a simple way for that email address to be automatically added to your list of verified emails, so that it can be used on other sites on the Web. We’re working on deploying this feature within Mozilla, so that we can enable easy single sign-on across our websites, and potentially even with our partners. You’ll note that we used a site called OpenPhoto during our demo. OpenPhoto is one of the first groups to join WebFWD, a Mozilla Labs project about creating open solutions that push the Web forward. OpenPhoto chose to implement BrowserID support because it was particularly easy and fit their distributed model. As always, we encourage you to try out BrowserID yourself, implement it on your site, and give us feedback on our mailing list or via twitter. [Less]

One of the areas we’re actively exploring in the Identity team is how to make it easier and safer for users to sign into websites. The BrowserID project is part of that exploration, but not the sole component. Today, we are releasing an early ... [More] experimental add-on for Firefox, Browser Sign-In, that allows users to sign into supported websites with one click of a button in Firefox. Watch the video below for a short demo, or download the add-on to try it out! How does it work? Websites can easily add support for this experimental feature by using a new JavaScript API that the add-on provides. It’s just a few lines to set-up, and it works with any website, regardless of what technology it uses for user sign-ins (BrowserID, OpenID, username & password, etc). The feature activates when the page sets the navigator.id.sessions property. It can be empty if there are no active sessions (which means the user is signed out), or it can contain a session object like this: navigator.id.sessions = [{ email: "[email protected]" }]; Then the page just listens for two events, “login” and “logout”, which the browser will send to the page when the buttons are clicked by the user. It’s that easy! Since most websites use cookies to implement user sessions, we’ve included some special (but optional) support for them: if websites declare the name of the sign-in cookie, the add-on will watch it and display the correct signed-in state without any additional work from the site. See Shane’s post for additional details of how it all works along with a more detailed tutorial. It’s worth noting that this feature doesn’t communicate with any server-side components, and doesn’t capture, store or transfer any personal information. The button is semantically the same as clicking “sign in” on a page: it just tells the page you want to sign in (or sign out) right now. Try it out & let us know what you think! Simply install the add-on, then browse to our example website, myfavoritebeer.org. We’re very excited about this experiment, and as always we want to hear what you think! Try it out, and join our mailing list, or just tweet with the #mozid tag. [Less]

Next week, Mozilla is hosting a brown bag on the BrowserID privacy architecture. Ben Adida, Mozilla’s technical lead for Identity, will describe the details of our experimental BrowserID system for the web and lead an open discussion on privacy and ... [More] security related properties associated with our approach. Bring your lunch and join us in Mountain View or eat at your desk and participate remotely online. Topic: BrowserID Privacy Architecture Presenter: Ben Adida Date: August 17, 2011 Time: 12:00 PM Pacific Location: 650 Castro Street, Third Floor, 10 Forward Live Video: http://air.mozilla.org/ IRC: irc://irc.mozilla.org/airmozilla Background Mozilla Labs designed the BrowserID experiment to increase user convenience and safety online. Using Mozilla’s 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. For more information, be sure to check out our blog post about privacy and BrowserID, as well as the BrowserID homepage. [Less]

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 ... [More] 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. Shrinking the User-Data Minefield 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. Need-to-Know Basis 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. A Model Users Already Understand 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! Limiting Tracking & Enabling Pseudonymity 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 [Less]

We launched Mozilla Labs’ online identity experiment, BrowserID, only 24 hours ago, and the feedback has been incredibly useful already. At Mozilla, we believe in empowering individuals to shape their online experience. Our work on a decentralized ... [More] identity solution for the Web matches that mission well. Also, because we believe that transparent community-based processes promote participation, accountability, and trust, we will be posting technical explanations, points of debate, and roadmaps on this blog. One important question we immediately received from early adopters is how BrowserID compares to OpenID. Both projects have three important common goals: (a) make it easier and safer for users to log in to web sites by reducing the number of passwords they have to remember, (b) make it easier for web sites to add authentication features, and (c) accomplish all of this in existing modern browsers. Beyond these similarities, we think Mozilla Labs’ BrowserID project provides a few key advantages over OpenID. Lloyd Hilaiel has written an excellent technical primer on BrowserID, which highlights our key design goals. These have led us to three key differences. BrowserID uses email addresses to identify users Users understand that an email address is like a persona. People typically have a work email, a home email, and maybe more. For developers, email addresses are useful, too: they are unique and provide an obvious contact mechanism when developers inevitably need to contact their users. With OpenID, the user’s email address may be available to Web sites requesting authentication, or it may be absent. In any case, it’s not the identifier. We believe that, for both developers and users, an email address is the right identifier. BrowserID protects the privacy of your Web activity With BrowserID, by design, your identity providers are not involved in the login transaction. This means they need not be aware of your entire Web activity, a significant privacy advantage. With OpenID, your identity provider is, unfortunately, a necessary participant in the login flow. BrowserID can be smoothly integrated into the browser Web-based login systems may increase the risk of phishing attacks if users become accustomed to typing their password into a dialog that an untrusted web site opens up for them. So, eventually, we want the login activity to happen within an easily recognizable, fully trusted browser UI. Because OpenID was designed primarily for use with zero browser intervention, it’s difficult for the browser to step in and provide that more secure login experience: we’ve tried, and haven’t found the right user experience. Mozilla Labs designed BrowserID with the specific goal of making it easy for browser vendors to implement directly, without preventing pure HTML implementations like the one we deployed yesterday. To explore how the integration of a secure BrowserID user interface could work in a browser, we’re developing a Firefox add-on. And, in parallel, we are open to working with other browser vendors who want the same functionality, of course. [Less]

Today we’re excited to announce BrowserID: an experimental new way of signing into websites. Our goal with BrowserID was to design something safe and easy for users and the developers. We’d love for you to try it out and let us know what you think. ... [More] Why BrowserID? For a Web developer, creating a new application always involves an annoying hurdle: how do users sign in? An email address with a confirmation step is the classic method, but it demands a user’s time and requires the user to take an extra step and remember another password. Outsourcing login and identity management to large providers like Facebook, Twitter, or Google is an option, but these products also come with lock-in, reliability issues, and data privacy concerns. With BrowserID, there is a better way to sign in. BrowserID implements the /verified email protocol/, which offers a streamlined user experience. A user can prove their ownership of an email address with fewer confirmation messages and without site-specific passwords. BrowserID is: easy to use Users gain a streamlined one-click experience that feels the same on any site they visit. Developers save time by deploying BrowserID, eliminating the need to implement email verification. Check out the links at the end of the post for more information. secure BrowserID implements the Verified Email Protocol, which is designed with security in mind. Sites get proof of ownership using public key cryptography—but don’t worry, we have a verification service so you can get started without writing a single line of crypto code. cross-browser BrowserID will work on all modern browsers, including recent versions of IE, and on mobile browsers! decentralized Anyone with an email address can sign in with BrowserID, and email providers can implement BrowserID support to make the system even easier for their users. even better on future browsers Although the prototype is implemented entirely in HTML and JavaScript, the system is designed to seamlessly integrate into future browsers. Check out our mockups for an idea of the kind of experience that is possible. respects user privacy Unlike other sign-in systems, BrowserID does not leak information back to any server (not even to the BrowserID servers) about which sites a user visits. BrowserID is highly experimental and we’re still iterating, Today we’re happy to announce the launch of a prototype for community review. We’d love for you to try it out and let us know what you think. To get started check out the quick tutorial and demo site. We look forward to hearing your feedback! Check out browserid.org. File bugs on github. Join our mailing list, or simply tweet and include the #browserid tag. [Less]