Ben Adida on BrowserID and identity

This is the second installment of Mission:Mozilla, a series of interviews that link Mozillians, the technology they produce and the Mozilla mission. Today Ben Adida is in the hot seat to discuss BrowserID, Mozilla’s identity initiative.

Tristan Nitot – Hi Ben, can you briefly introduce yourself?

Ben Adida – I’ve been hacking since high school and, since college, I’ve been fascinated with cryptography, security, and controlling my data. I built my first DB-backed web site before cookies. I ran my own IMAP mail server starting in 1997 because no one else was doing it the way I wanted it. I started an open-source web dev shop in 2000, went back to grad school in 2003 to work on secure voting, explored security and privacy of health data at Harvard Med for a few years, and joined Mozilla in March 2011. I’m now Tech Lead on Identity and User Data, and I’m having a blast.

TN – Oh my… running your own IMAP server in 1997? That’s the kind of thing that gives instant nerd credibility ;-)

BA – Oh yes, big nerd and proud of it!

TN – So you’re now with Mozilla, focusing on Identity and User data. Can you update us on what’s Mozilla is doing on these fronts?

BA – Everyone I talk to within Mozilla realizes that the Open Web depends on more than just the Firefox web browser. People are storing massive quantities of their personal data online, using dozens of services, and an open browser is not enough to ensure that they have true choice, true control, that they can shape the Web to their liking. So we need to be working towards providing user choice in web-based services, too. The first piece of the puzzle is a usable, federated, and distributed identity system. That’s what we’re doing with BrowserID.

TN – “federated, distributed”, with users having control… Sounds like the original pillars of the Web, right? I mean, as opposed to what we tend to see these days, with identity being concentrated into the hands of very large commercial organizations… How do you plan to achieve this?

BA – That’s right, distributed/federated *is* the way of the Web, but when you look at today’s identity solutions, most are incredibly centralized, and those that are more distributed in terms of protocol tend to become centralized in implementation because of the so-called NASCAR problem: you get to log in with Google or Yahoo, and if you’re *really* knowledgeable then maybe you can log in with your own Identity Provider. We think we can do better for users and developers in terms of ease of use and adoption.

TN – And what about privacy?

BA – We’ve specifically designed BrowserID to reduce the amount of private data that changes hands to the bare minimum required for authentication. For example, in every other web-based identity system today, the site you log into phones home to your identity provider. In the real world, the equivalent is: you check into a hotel, present your ID to confirm your name, and the receptionist calls the issuing government agency and says “Hi, this is the Hyatt San Francisco, Tristan is checking in just now, is that okay?” Why does the government agency or, in the case of a privately issued identifier, the commercial entity, need to know where and when you’re checking in? In the real world, the receptionist just checks the seal on the ID without phoning anyone. BrowserID recreates this more restrained, more privacy-protecting data flow for web logins.

TN – So how do you manage to get the best of both worlds: user experience and user control?

BA – First we’re making the browser an important part of the protocol. After all, the browser is the User’s Agent. Isn’t it a little bit silly on today’s Web that you typically have a tab open to your gmail, and then another site asks you to log in with Google or Yahoo? Why can’t the browser help coordinate those two tabs? You’re logged into gmail, of course you have a gmail email address you can use to authenticate! And in the enterprise setting, you’re logged into your company webmail, of course you can authenticate using that enterprise identity! The browser can help reduce user complexity significantly.

TN – But I could want to use another email address, than the one I use for my Webmail…

BA – Right, so we’re always going to give users a choice. Users can choose exactly which persona they want to present. And one major BrowserID design point is simply that users understand email addresses as personas. They typically have home and work email addresses, and they don’t use them the same way. If they have a moonlighting job, they often have a separate email address for that. So BrowserID is based on this concept users already understand: logging in is simply delivering an email address to a web site in a way that the web site can easily verify.

TN – Cool. Say I’m a Web developer that wants to use BrowserID on my site. How hard is that? How much do I have to relinquish control of my users to Mozilla?

BA – It takes about 5 lines of JavaScript and 10 lines of backend code to integrate BrowserID, and it works today. It’s by far the easiest of the available identity solutions. In the short term, it means you’re relying on Mozilla servers to provide the BrowserID interface and verify users’ email addresses. That said, this is only temporary scaffolding for our distributed system.

TN – But as BrowserID becomes native in browsers and identity providers appear, this will change?

BA – We’ve taken great care to design the system so that, as browsers begin to support the BrowserID APIs natively, we can remove our scaffolding and leave standing a truly distributed protocol. Best of all, web sites don’t have to change a line of code for that to happen: as the identity providers and browsers start supporting BrowserID, our scaffolding automatically fades away. And let’s say you’re a web developer and you want to stop using BrowserID for whatever reason: just send your users an email with their new password, and you’re done. No other identity system minimizes lock-in this much, for both users and web developers.

TN – So minimizing lock-in is part of the BrowserID design goals?

BA – Absolutely! This is part of our mission and manifesto. We don’t want to own users, we want to empower them. Mozilla is in a unique position to build this kind of identity system because, as we all like to say, Mozilla answers only to users, and we can leverage Firefox to deploy these pro-user designs.

TN – Fantastic! What would you recommend to Websites who want to do a test-run on their site? And for users who want to experience BrowserID right away?

BA – Web developers can check out our documentation. Users can check out http://current.openphoto.me, a very promising distributed photo storage system shepherded by WebFWD that chose BrowserID. Just click the distinctive BrowserID login button to get a taste of the user experience.

TN – I’m sure our readers will try it right away! Thanks a lot Ben for your time. Long live BrowserID!


9 comments

  1. pd

    None of the web sites I develop rely on JavaScript for login so I guess BrowserID is not for me?

    October 20th, 2011 at 08:36

    1. zoulou

      You can use whatever you prefer. You don’t *have* to use BrowserID, but if everyone uses it, no one loses (well, except the data-gathering corporations)

      Technically speaking, to ensure a proper authentication chain, javascript must be used (aka the *client* must do the auth work, everything else is http-auth or server-side)

      October 20th, 2011 at 10:37

  2. Stephan Sokolow

    I intend to avoid BrowserID support in the sites I create for the following reasons:

    1. No support for clients without Javascript runtimes as far as I can tell. (What I variously call the “PDF does NOT mean Pretty Downloadable Forms” problem, the “WHY must I base my site spider on a copy of GTKWebKit” problem, and the “Protocols other than HTTP exist, y’know” problem)

    2. I cannot endorse something which has a UI that would severely penalize me for giving a unique e-mail alias to every site I log into.

    3. I feel it’s reinventing a lot of wheels that have OpenID+WebFinger were already hammering away at (does it even SUPPORT an easy-to-use analogue to combining WebFinger and OpenID delegation to have, say, GMail act as the authenticating party for foo@bar.com aliases?) and that it’d be better to improve existing OpenID+WebFinger solutions. (Which I WILL support in my creations)

    4. I’m bitter that BrowserID is taking developer time/effort away from the “Integrate OpenID handling into the browser as part of a successor to the antiquated HTTP Basic Auth UI” effort I really wanted.

    It also doesn’t help that I’m getting flashbacks to KDE essentially deprecating Konqueror as a file manager and writing Dolphin (which only allows tabs to contain DolphinPart because, otherwise, people would see what a wheel reinvention it really is) and using “we didn’t like where that was going, end of discussion” as their justification.

    October 20th, 2011 at 15:07

    1. Ben Adida

      Stephan,

      Some quick points:

      (1) yes, JavaScript is required.

      (2) we’re working on improving the UX if you want to provide a unique email address to every site, and we’re thinking about automated solutions to provide pseudonyms.

      (3) there are a few important advantages of BrowserID over OpenID:
      http://identity.mozilla.com/post/7669886219/how-browserid-differs-from-openid

      Also, we’re just starting to explain how primary identity providers will work. We absolutely intend to make that a key feature:
      http://lloyd.io/primary-identity-authorities-in-browserid

      (4) we have to look at the entire UX. The OpenID UX is not good enough, in our opinion.

      We hope you’ll take another look at BrowserID.

      October 20th, 2011 at 18:09

      1. Stephan Sokolow

        For #1, I’m a big-time NoScript user and I also like to write various non-browser HTTP User-Agents like web scrapers, so Javascript being required as more than a polyfill is a big no-no for me.

        However, if future developments fix that then, given what else you’ve said, I think I’ll support it whole-heartedly. (As much as I hate site-specific passwords and as inefficient as OpenID is, they’re both easier to script in a scraper without no Javascript engine)

        For #2, that would be a BIG point in favor of me using it… though keep in mind that when you say “pseudonyms”, that has to include e-mail aliases. My main reason for giving out a unique address to every site is so that I can revoke their ability to mail me if I start to get spam or if their unsubscribe form is broken.

        As for #3, I’ll admit that WebFinger arrived late in the game, but I won’t call that a point in BrowserID’s favor, given that, with all the semi-drop-in OpenID libraries out there, supporting WebFinger is more a version bump than a new authentication method.

        I’m not fully clear on the specifics of how BrowserID provides better privacy, but I’ll trust your word on that one.

        Finally, #4, I will admit that OpenID does have UX issues. It’s always been something I’ve been a bit concerned about.

        For my own use, since I don’t really compute on the go, I’ve been planning to work around those for my own use by using a delegation, a DynDNS subdomain, and a special purpose OpenID/HTTP daemon that pops up a native GTK+ Allow/Deny dialog when a site tries to authenticate.

        (If I needed to travel, I’d SSH in and run the OpenID provider in a tunneled X session)

        I suppose, pseudonyms aside, my biggest problem with it is that, if you’re trying to be the next big authentication mechanism, I strongly believe you should try to be something more along the lines of a modern Kerberos that gets along with shared hosting and can use Javascript to polyfill for browsers that don’t implement it directly… not merely a decentralized, privacy-protecting “Login with Facebook” button.

        Speaking of which, what are your plans regarding OAuth? I haven’t needed it yet, so for all I know, it depends on OpenID and I worry that other people might jump to that same conclusion.

        October 21st, 2011 at 00:50

        1. Stephan Sokolow

          Ugh. There should really be a “first minute or two, you can edit” function for fixing things like typing “without no” when your mind is caught between “with no” and “without a”.

          October 21st, 2011 at 00:52

        2. Ben Adida

          Hi Stephan,

          Thanks for taking a look at this additional info. A little bit more info that you might find useful about BrowserID and Privacy:

          http://identity.mozilla.com/post/7899984443/privacy-and-browserid

          http://identity.mozilla.com/post/11145921163/browserid-design-for-privacy

          Regarding JavaScript, remember that our major use case is users interacting with sites. Most sites are broken today with NoScript, so it’s hard for us to optimize for that use case. For automated access, we may want to consider an additional REST API that accepts a BrowserID assertion and returns to you some kind of session token. We’d be happy to field proposals on this, if you’d like?

          October 21st, 2011 at 09:43

          1. Stephan Sokolow

            I definitely like the viewpoint taken in that first Identity at Mozilla post you linked. It’s the kind of thing I often find myself saying. I’ll take a look at the video when I have more time to spare.

            However, I think we’d need to do some research before we make claims about what percentage of sites are broken with Javascript disabled. From my perspective, only a small minority of highly popular sites are broken with Javascript disabled (killing ads and breaking features I never even notice to be broken because I never try to use them doesn’t count) and I will fight, tooth and nail, any technology which makes full implementation of progressive enhancement more difficult. (From my perspective, requiring Javascript for login as more than just a polyfill is like re-implementing :hover in Javascript for drop-down menus)

            As for the ReST API, that would satisfy me from a technical standpoint, but given how slow the uptake has been of WebFinger and given previous experience elsewhere, I worry that if it’s merely an alternative to the default API, many sites will fail to implement it either out of laziness or out of some misguided belief that refusing to implement it will work as some sort of makeshift CAPTCHA… at which point, we’re back to where we started and developers of automated tools have to either pass in username/password pairs or embed WebKit in otherwise minimal, lightweight tools.

            October 21st, 2011 at 17:08

  3. R Stephens

    Forgive me if I misunderstood, but how does BrowserID “fix” the NASCAR problem?

    Few, very few users will run their own BrowserID primary authority. Most will rely on their megacorp e-mail provider such as Google or Yahoo to act as the primary. So in what way will it really decentralize authentication? How is this empowering users?

    If a BrowserID user wants to take control of their identity they will have to ditch their current e-mail host and move elsewhere.

    January 21st, 2012 at 12:35

Comments are closed for this article.