Identity at Mozilla

Streamlining Login with Privacy Policy and Terms of Service APIs

Mon, 14 May 2012 08:01:03 -0700

A new feature landed in Persona last month that promises to make the sign-in process even smoother by asking users to consent to site-specific Terms of Service and Privacy Policies as a native part of the login flow.

This means that sites using Persona can easily present their own terms of service and privacy policy to users in an obvious, seamless, and uniform location. Moving user consent into the sign-in dialog also lets websites get rid of their “I agree” checkboxes, while still being certain that users were informed of and consented to the site’s terms on every sign-in.

Supporting this API is dead simple, saves users a click, and means one less form for websites to manage. We think it makes sign-in easier for everyone, and we’d love to see more sites using this new, optional feature. To lean more, check out our documentation and let us know what you think via our mailing list, IRC channel, or by tweeting with the #mozpersona hash-tag.

Streamlining Login with Privacy Policy and Terms of Service APIs

Mon, 14 May 2012 07:25:06 -0700

Introducing Mozilla Persona

Wed, 22 Feb 2012 12:54:00 -0800

This past year we’ve been building the core of a Web-scale identity system. We’ve been calling it BrowserID: our name both for the technology¹ and the Mozilla service that implements the technology. Today we’d like to introduce Mozilla Persona, our new name for the complete Identity offering from Mozilla: a collection of components and experiences we’re designing to manage the whole of a user’s online identity with our core values of user control, safety, and convenience.

The Persona name resonates with the idea of personhood as well as online identity as a facet of our lives, and therefore strongly tied to user identity. We’re very excited about this new name and the new features our identity system will offer. Some of the things we’re planning: an identity dashboard, user data interconnect features, and more.

What about “BrowserID?”

BrowserID remains the developer-facing name of the protocol. Websites, email providers, and browser implementors will continue to refer to the BrowserID protocol.

Over the next few months, we will begin to transition the Mozilla Web-based implementation of the BrowserID pop-up over to the new name. But don’t worry, we’ll work hard to make sure the transition is completely seamless for everyone.

Wait, what about Firefox’s Personas?

For the past few years, many Firefox users have enjoyed “Personas”—a quick and fun way to theme the background of the Firefox toolbar. The Addons team blogged about changing their name a couple of weeks ago. No doubt there will be some confusion during this transition, so if you have ideas for how to make the transition smoother, definitely let us know! We believe the long-term value of the Persona name will far outlast the short-term discomfort of change.

We hope you’re as excited about this change as we are. We look forward to an action-packed 2012 for our distributed Identity system under the Mozilla Persona umbrella!

As always, feedback and questions are always welcome on our mailing list, or by tweeting with the #browserid or #mozpersona hash-tag.

¹: Some of you may remember that BrowserID came from the Verified Email Protocol. We haven’t forgotten, of course—but BrowserID has become the name of the technology nonetheless.

BrowserID now available in 28 languages

Thu, 16 Feb 2012 13:49:12 -0800

We’re proud to announce that with the latest update to BrowserID the sign-in flow is available in 28 languages, in addition to English.

Like many of our previous updates, users and sites automatically benefit from the added feature without having to change anything. Users will see BrowserID in their preferred language, based on their browser’s settings.

Here’s what BrowserID looks like in traditional Chinese:

This change has been possible because of our amazing community of volunteers. Firefox ships in over 70 languages and that energy also powers our vision for a cross-platform identity management.

Along with ID provider support, shipping our service in multiple languages are two big milestones for BrowserID maturity.

Users of your websites can now have a native language experience in the following locales:

Afrikaans (af)	català (ca)	Čeština (cs)	Dansk (da)
Deutsch (de)	Ελληνικά (el)	Español (es)	Eesti keel (et)
Euskara (eu)	suomi (fi)	Français (fr)	Frysk (fy)
Gaeilge (ga)	Hrvatski (hr)	Italiano (it)	Ligurian (lij)
Nederlands (nl)	ਪੰਜਾਬੀ (pa)	Polski (pl)	Русский (ru)
slovenčina (sk)	slovenščina (sl)	Shqip (sq)	Српски (sr)
Svenska (sv)	Türkçe (tr)	中文 (简体) (zh-CN)	正體中文 (繁體) (zh-TW)

Dig Deeper

ID provider support now live on BrowserID

Tue, 07 Feb 2012 05:04:00 -0800

Last week we pushed out a BrowserID feature that gets us closer to the decentralized identity system we envision for the Web. But more than that, it enables a truly awesome user experience—registration flows go from 8 screens to one simple sign-in. Seriously! See for yourself:

Chicken or egg

Some context: Building a distributed system is a chicken and egg problem - you have to design a system that can demonstrate the power of your idea and the advantages of a distributed architecture while you bring in participants who will become actual nodes in the system. That’s why, so far, BrowserID has operated with scaffolding that uses the BrowserID service itself to vouch for email addresses.

With our latest update, however, we’re setting aside some of that scaffolding and allowing a fully decentralized system to emerge: Identity providers can become full-fledged participants in BrowserID and directly vouch for their users’ email addresses.

What’s changed and what you need to know

If you’re a website that’s already implemented BrowserID, you don’t have to do a thing: BrowserID is just better for you! Up to this point, Browser ID has been vouching for users’ email addresses on behalf of participating websites. Now email providers can directly vouch for their users, eliminating the need for an email confirmation step or a BrowserID password.

Note that this change only takes effect when the email provider for a given address implements BrowserID support. Other email addresses continue to work in the same way they do today, with an email confirmation and password from the BrowserID service.

With ID provider support, users will have a better, faster, smoother registration experience.

Give it a spin.

Attention email providers large or small: whether you’re an enterprise, an ISP, a university or institution, you owe it to your users to check out this key new feature of BrowserID. Now it’s easy and incredibly simple for any email provider to become an identity provider for their users.

Try out our demo ID provider at eyedee.me and your @eyedee.me address on any BrowserID site. Take a look at our code and documentation. Let us know what you think via our mailing list, IRC channel, or via the Twitter hashtag #browserid.

BrowserID Represents @NodeSummit

Mon, 23 Jan 2012 17:30:34 -0800

If you’re a regular reader of this blog or a developer working with Browser ID, no doubt you already know that it’s fundamentally a node.js project built on a Node.js platform. Not surprising then that we’ll be at Node Summit, a 2-day event that begins tomorrow at San Francisco’s Mission Bay Conference Center.

Node.js pioneer Mark Mayo is now a principal engineer in Mozilla’s innovation group, where he works on identity and compute platform projects. Mark will be on a Tuesday afternoon panel called “Large Scale Web,” discussing how Node.js is used by players like Mozilla, Google and Yahoo to keep up with humongous web-scale demand.

Mozilla CTO and Javascript creator Brendan Eich will be on a Wednesday morning panel called “The Evolution of Javascript,” along with Ryan Dahl, who started the Node.js project, and other industry leaders.

BrowserID core team engineer Lloyd Hilaiel will be at Node Summit also, along with some other talented Mozilla technologists.

If you plan to attend, look for us there. If you’d like to learn more about Node.js, it’s not too late to register. If you want to discuss BrowserID implementation or technology, you can always reach us on the dev-identity list or via the #browserid hashtag on Twitter.

Open Source Rookie of the Year

Thu, 19 Jan 2012 08:34:00 -0800

Even in the Open Source world, tooting one’s own horn is a reason to blog, right? Along with educating, announcing new features, raising awareness, inviting adoption and participation, and asking for feedback.

This post is one of those shameless brag moments. We wanted to to quack proudly about the fact that the 4th annual Black Duck Software Rookies of the Year program has recognized BrowserID as one of their 2011 winners. We’re honored by the recognition and thrilled to be included in the company of friends and colleagues from projects like Bootstrap and Cloud Foundry.

Black Duck Software (@black_duck_sw) is a leading provider of products and services for enterprise scale adoption of open source software (OSS), offering automated management, governance, security and compliance tools for licensing OSS across a range of industries.

The folks at Black Duck are “dedicated to the effective and informed use of open source software” - and so are we. We’re honored to be recognized by a vendor noted for their rigor and professionalism. And it’s great to feel like a rookie, with the best years of Browser ID development and deployment ahead of us.

Thank you.

Photo credit: Anas superciliosa rogersi (Pacific Black Duck) by Arthur Chapman

BrowserID deployments at Mozilla

Fri, 06 Jan 2012 18:05:18 -0800

Mozillians enjoy their holidays by… deploying awesome code. In the last few weeks, a number of Mozilla properties have deployed BrowserID:

We’re deploying BrowserID internally because the best way to ensure that we build it right is if we’re using it in mission-critical environments. The early comments we’re getting from users are very encouraging and helpful: we know we’re on the right track, and we also know how to prioritize issues based on how they’re affecting our users.

We’re also making sure to be respectful of the inherently global nature of the Mozilla community. Because BrowserID is not localized yet, we’ve chosen to deploy it only on sites that are predominantly English-speaking, or only on the English locales. As we localize, we’ll expand to other locales.

Enjoy BrowserID on Mozilla web sites and, as always, send us your feedback by joining the mailing list or by tweeting with the #browserid hashtag.

BrowserID this week: better, faster, more secure.

Thu, 01 Dec 2011 19:10:01 -0800

Today, we released an important set of new features for BrowserID. These features make BrowserID more useful, faster, and more secure. We look forward to your feedback, as always on the mailing list or on Twitter using the #browserid hashtag.

Features

BrowserID now lets you stay signed in to web sites of your choosing. This will work only with web sites that want to allow persistent sign-in, and of course it only happens if the user specifically opts in. There are clearly web sites to which users want to always be logged in: we want to make that easy as long as it’s the user’s choice. You can always change your mind and log out.

BrowserID now also lets web sites specify a required email for logging in. This is useful when the web site already knows the user’s email address via other means. For example, if Alice shares a photo with Bob using a BrowserID-enabled photo-sharing site, the web site needs to authenticate Bob against the exact email address Alice used to invite him. With this new feature, Bob doesn’t need to type his email. Even better, Bob isn’t misled into using an email that will lead to an authentication dead-end because it’s not the email Alice used to share the photo with him. (You may be familiar with this unfortunate situation if you use Google Docs extensively but are logged in with the “wrong” email address.)

If you’d like to add these features to your site, check out Advanced BrowserID Features on our wiki.

Speed and Security

We’ve changed the digital signature algorithm used in BrowserID so that signing in is much faster. It’s so much faster, in fact, that we’ve been able to increase our key size to a much more secure level than before while retaining a much faster experience. Even on mobile devices, logging in is now quite fast.

another introduction to BrowserID for WebFWD

Mon, 28 Nov 2011 10:21:44 -0800

A few days ago, we chatted with the WebFWD teams about BrowserID. WebFWD is Mozilla’s initiative to fund and support creative teams that build on the Open Web. The WebFWD blog summarizes the chat, and includes the screencast of our presentation:

Download Video: MP4, WebM, Ogg
HTML5 Video Player by VideoJS

Deploying BrowserID at Mozilla

Thu, 17 Nov 2011 17:55:52 -0800

Over the next few months, we’ll be deploying BrowserID on Mozilla web sites. When we do, we’ll point users to this blog post to explain what BrowserID is and why we think this is good for users. If you still have questions, remember you can easily join our mailing list or just Tweet with the hashtag #browserid.

What is BrowserID?

BrowserID is a very easy way to log into web sites by proving you own an email address. BrowserID is designed to be tightly integrated into your web browser for ease-of-use, and it is designed to be privacy-protecting: the only data exchanged is that which is strictly necessary to log in. BrowserID is a product of Mozilla, and we are working to standardize it so that other browser vendors can, if they choose, easily integrate it. In the meantime, Mozilla provides a simple JavaScript mechanism that lets web sites use BrowserID right away, across all modern browsers, on desktop and on mobile.

How is this good for users?

BrowserID makes it easier for users to register at new web sites and subsequently log back into those sites, using any email address they choose. Users are free to use different email addresses for different purposes, and the process of signing in becomes easier and safer. Users maintain complete control over their identity, only now they have fewer passwords to remember.

At Mozilla specifically, it makes even more sense for our users to sign in with BrowserID: rather than have a dozen accounts with different Mozilla web sites, users need only one BrowserID account, which will let them partake in any site they choose at Mozilla. What’s the point of having multiple accounts, each with a different password, yet all with the same organization?

It’s important to note that this is not automatic single sign-on. Users can log into a new Mozilla web site with only two clicks, but they are logged into only the specific Mozilla web sites where they choose to be logged in. BrowserID makes logging in easy, while maintaining complete user control.

Some additional details

BrowserID is new, so you probably still have questions. Here are some additional points we’ve found can be helpful in understanding BrowserID:

BrowserID does not share data between sites that use it.
Because BrowserID lets users choose any email address to log into a web site, it’s easy for a user to create a single-purpose email address to log into a given web site. BrowserID remembers which email you used on which site, so it helps you pick the same single-purpose email the next time you log in.
BrowserID stores your email addresses on Mozilla servers, protected by Mozilla’s infrastructure security team. We do not sell or transmit your information to third parties, and you can completely delete your account with us at any time. You can read our complete (and simple) privacy policy.

BrowserID now remembers the email you last used on a site

Fri, 11 Nov 2011 17:59:24 -0800

Every Thursday, we deploy a new version of BrowserID to all users transparently. The user experience continues to improve, browser support is expanding, and new features are added. As of this week, BrowserID remembers the email address you last used on a given web site. If you used your home email address on a shopping site, that address will be selected by default the next time you log into that shopping site. If you choose to use a single-purpose email address at another site, BrowserID will remember it and suggest that same email the next time you log into that web site, and only that web site. As always, you control when and how you log in. We’re just making it easier for you to present the same persona to a given web site over time.

Because we aim to protect your data, the correspondence of email addresses to web sites remains locally stored within your browser. We don’t synchronize it via the BrowserID servers. If you use BrowserID with multiple computers and browsers, that means BrowserID won’t remember your login preference from one browser to the next. Over time, if we can do it safely, we’ll look into ways of synchronizing these preferences across browsers.

Note to Implementers: we changed the Verifier API

Tue, 18 Oct 2011 19:07:15 -0700

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 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.

New BrowserID User Experience

Fri, 14 Oct 2011 16:31:36 -0700

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 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.

BrowserID Design for Privacy

Fri, 07 Oct 2011 11:04:27 -0700

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 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!

BrowserID at the Mozilla All-Hands

Mon, 19 Sep 2011 15:54:00 -0700

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 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.

Sign Into Websites Directly From Your Browser Toolbar

Fri, 12 Aug 2011 16:31:00 -0700

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 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: "user@foo.com" }];

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.

Join our BrowserID Privacy Brown Bag

Thu, 11 Aug 2011 15:22:00 -0700

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 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.

Privacy and BrowserID

Thu, 21 Jul 2011 14:50:00 -0700

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.

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

How BrowserID differs from OpenID

Fri, 15 Jul 2011 17:57:30 -0700

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 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

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.