12 ms·

Introducing BrowserID: A better way to sign in

364 points by joeshaw 15y ago

dendory 15y ago
How is this any different than current single signon systems, like Microsoft Live, Yahoo, Google, Facebook Connect.. I mean sure maybe this is open and anyone can run their own but lets not forget users dont care at all about that..
- bct 15y ago
  As a user, once your browser and email provider support it, it's single-click login (and signup), without any redirects. As a site operator, you don't need to choose which company you're going to accept as an auth provider, or have a login page with lots of icons on it; you just have one button that says "Log in".
omarqureshi 15y ago
Whilst I understand and really like the non-tied in aspect of it, I'd probably implement some sort of facebook/twitter/google account authentication alongside of it. Reason being is that, it too is just another authentication service that I'd rather users not have to make the effort to sign up for.
- bct 15y ago
  The intention seems to be that browserid.org is temporary, just there so that this can work until it's supported by browsers and identity providers directly. Once that is achieved, there's nothing extra to sign up for.
  - omarqureshi 15y ago
    Sorry, the video didnt make that clear - not even slightly.
bruceboughton 15y ago
Can someone explain what makes this a browser ID? I don't get it...
- mbrubeck 15y ago
  It's designed so that the browser can interact directly with the authentication protocol, saving steps for the user. This grew out of Mozilla Labs' "account manager" project, which had a protoype UI you can see here: http://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/ http://hacks.mozilla.org/2010/04/account-manager-coming-to-f...
sirn 15y ago
How is it different from OpenID, apart from it's not decentralized?
- cgranade 15y ago
  I'm wondering if it's at all possible to integrate this with OpenID, and how this interacts with previous Mozilla Identity projects to make your identity a part of the browser chrome. It all seems rather tangential to their other efforts, rather than coherent with.
  - JoshTriplett 15y ago
    I certainly hope it isn't possible to integrate this with OpenID. If it is, sites will just continue relying on OpenID, and treat this as a weird special case, rather than a superseding technology that gives the user control without requiring a third-party provider.
- deleted 15y ago
  [deleted]
- mbrubeck 15y ago
  This lets users sign in with an existing email address, so they don't need any new sevice or identifier to remember. It's decentralized; Mozilla has a service for web developers for convenience, but any site can implement the protocol itself instead (or use another provider). And it's designed to let browsers handle the login flow in the future, simplifying login and account creation for end-users.
  - pavel_lishin 15y ago
    Most of the oauth services I used allowed me to create an account with ... an e-mail and a password. Literally the same thing, here.
    - Osiris 15y ago
      Isn't one of the advantages of this system is that your password doesn't get stored by the website? Just some type of token? If their database gets stolen or leaked, they shouldn't be able to hash attack your password and gain access to it since it's not there. I'm just assuming it works this way, as passing the password along would defeat the security of the system and make you more vulnerable.
shockie 15y ago
What's the advantage over openid?
- bct 15y ago
  Some people think that using URLs instead of email address in OpenID was a big mistake. Having in-browser support for this kind of thing seems like a plus, too.
  - NathanKP 15y ago
    Email addresses are something that people are fairly familiar with when it comes to signing in. Trying to explain why URL's are used instead of email addresses in OpenID is difficult when you are dealing with a non techy user.
  - codyrobbins 15y ago
    To this day I still do not understand how this inane argument happened to be the single thing that killed OpenID. How is ‘cody.my-open-id-provider.com’ more confusing as a login than ‘cody@my-email-provider.com’? Hint: it’s not. I’m not one for conspiracy theories, but the whole URL-versus-email argument against OpenID seemed like the excuse various people used to put a nail in OpenID’s coffin when they didn’t like it for other less defensible reasons.
    - nl 15y ago
      I'm a reasonably competent web user. I've implemented OpenID. I run my own Open ID server. I've implemented Shibboleth (and lived!). I know that Yahoo is an open ID provider, and I think Google is too, but when I'm presented with an old-style (URL) OpenId login I don't have a clue what to enter to use either my Yahoo or Google account to login. Yes, I know that now most login forms provide easy links to use Google or Yahoo to login. The point is that entering the URL is confusing because no one knows what their OpenID url is, and it isn't standardized in anyway. The situation is so bad that the OpenID providers had to develop a way for users to enter their email addresses, and then the client performs a discovery request to find their URL.
ams6110 15y ago
More at https://browserid.org/ https://browserid.org/
- falava 15y ago
  and https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol
tobylane 15y ago
I hope that one of these services is on the user's side, so much that the ID isn't enough for, say, advertisers to track users over different sites. And how graceful is it for versions of IE that aren't 'recent'?
ams6110 15y ago
This seems to encourage using the same credentials everywhere which I think most agree is a "bad idea." If BrowserID is compromised, the attackers have access to all the sites where I use browser id, right?
- bct 15y ago
  Once this is supported by browsers and email providers there is no "BrowserID" to be compromised, your email provider would have to be compromised (which already gives attackers access to all the sites that you use that email on). (Unless you meant "BrowserID" the protocol.)
- ignifero 15y ago
  Isn't that what happens when someone compromises your email too?
- jdunck 15y ago
  There is a large distinction here - the provider (in the video, BrowserID.org) would have to be compromised, as only they have your credentials. This is quite a bit different and more secure than using the same credentials with many different providers, because in that scenario, the weakest of any party could get compromised and that way compromise all parties.
  - slowpoke 15y ago
    In addition to that, since the ID provider does not get any sort of information about which websites you visit with your ID, it would be impossible to know where exactly the ID is in use. At least that's how I understand it.
- mrinterweb 15y ago
  The same could be said about OpenID and OAuth providers like Twitter, Facebook, Google, etc. The idea of having a centralized authentication provider is definitely not a new one. There are many advantages to using 3rd party authentication providers. The biggest security advantage 3rd party auth providers have is that they do security right and often they implement their authentication service using a commonly defined protocol. Many websites that choose to roll their own systems make many security mistakes and many people use the same credentials on many sites. So if any website is not secure authentication a user's login information is likely compromised across multiple websites because people generally use the same credentials.
ukaszg 15y ago
so, its an easier way for sites to track users?
- bct 15y ago
  Not really. It's a way for a user to prove to a site that they control an email address.
  - ukaszg 15y ago
    sounds like tracking to me
    - bct 15y ago
      Ok, but only In the same way that typing in a username and password on a website allows them to track you.
      - capnrefsmmat 15y ago
        Various forums already verify you own a certain email account when you sign up. Basically everyone does to send your account information or their marketing stuff. This isn't new.
      - superuser2 15y ago
        To have a conversation with someone, you have to uniquely identify them, and correlate all the words they've said as coming out of their mouth and not somebody else's, then put all these words (which you've identified as being part of the same sentence) together into meaning. As you get to know someone, you correlate all these meanings into a mental model of the person, and use this to guide how you interact with them. People who can't do this are considered mentally ill. It's one of the defining pieces of consciousness, and essential to the human experience. So, as programmers, we make a deliberate choice to enable this functionality for end-users in most internet applications (like email, IM, social networking, and discussion boards) by displaying a token belonging to you (and only you) next to what you're saying and doing. This can be a username, email address, phone number, picture, etc. This particular spec is a more convenient way of establishing your ownership of a token used to identify you. You can choose to use sites (like 4chan) which don't reveal this information publicly. But if you sign your posts, or indicate in any way that you are the same person as a previous poster, you are establishing an identity which 4chan is tracking and revealing to the world. There is no conversation without tracking. Whether or not the sites you use choose to identify you, however, they know you by the IP address you are coming from; they have to, in order to send information back. Tor can mitigate this (if you change exit nodes with every request) by hiding your path from A to B within a cryptographically secure mass of data, but if the random number generator determining the amount of time to wait before forwarding your packets is broken, that's blown too. IP addresses change, so if I want to correlate you between your ISP's DHCP leases (or between your multiple internet connections - Starbucks, home, work), I'll set a cookie. This is how when you clicked "reply", Hacker News knew it was still the same person who logged in with "ukaszg/hunter2". Tracking is essential to civilized conversation. To fight tracking itself is to ask that the entire Internet become 4chan and that nobody assume the same identity from post to post. I hope this isn't what you mean. -- Tracking makes you nervous because a) computers exhibiting human behavior is kind of creepy b) sometimes, companies choose to violate users' expectations of what will be done with the information they've correlated But you can't take this information away from them while still using their services. You can refuse to use services which violate your expectations, you can demand better, and I encourage you to. But ultimately, these services have to pay the bills and make a profit. I could be wrong, but I'm going to take a wild guess and say you wouldn't pay for Facebook; I'm going to go even further and say that you would be offended at the idea of having to pay for Facebook. Well, Facebook's employees want to feed their children and buy cars and houses and video games and TVs just like you. And Facebook's owners and investors want to get rich. If these objectives aren't met, there won't be a Facebook. So instead of taking your money, they take what they can guess about what you will buy, and charge advertisers for it. Advertisers, in turn, can show you products which you won't scoff at paying for, and eventually some less speculative cash enters the equation. You cannot avoid tracking. But if you want the companies tracking you to conform to your expectation that your data not be used to sell you stuff, you're going to have to pay them. Rackspace email is $2/mailbox/month. There are no ads.
NathanKP 15y ago
When I tried to sign in on the demo site I got a 502 Bad Gateway error. This isn't an encouraging sign.
ora600 15y ago
What I'd really want to see is public-key authentication for website. Let me upload my public key when I create an account on a website, and let the browser interact with my ssh-agent to authenticate.
- JanezStupar 15y ago
  This... A million times this. Where do I signup?
- lucian1900 15y ago
  This. Perhaps ssh+http is the solution.
  - Iaks 15y ago
    Where is 'this.' coming from? Coding syntax? I just don't get it. I've seen it in HN comments for a few days now, but I fail to understand how 'this.' relates any new information. Reply indenting already tells me you are referring to an antecedent post. (A specific post in fact.) Am I missing something, or is this just a new web fad I'm not savvy too? (Second option is not entirely unlikely...)
    - StavrosK 15y ago
      It's just for added emphasis. It's the contraction of roughly "this is the correct answer".
      - Iaks 15y ago
        Thanks for enlightening me =)
    - absconditus 15y ago
      It is popular on sites like reddit. It basically means "I agree".
    - billforsternz 15y ago
yarone 15y ago
So, it's basically a traditional single-sign on system? Is that right? Like, in the old days, I integrated one of my products with AOL. You could click a link and it would automatically sign you into my product using you AOL Screenname and Password (behind the scenes, AOL would verify that the screenname and password are correct and my app would create a new user in my database).
- bct 15y ago
  Your description is too vague to generate an answer to your question.
latchkey 15y ago
This is full of fail. Your email address is not your identity. I must be able to change my email address without having to change my identity.
- 51Cards 15y ago
  It's not that simple. They authenticate against your Account at Browser ID. I would assume you can go into Browser ID and add / remove email addresses from your account which makes it even easier when you change your email. Now you don't have to visit 20 different sites to update them.
  - stickfigure 15y ago
    Is there some sort of account ID other than an email address? It looks like the email is all that gets sent to the website (although I didn't read deeply enough to be sure). If you change (add new, remove old) your email address at browserid.org then revisit a site you authenticated to before, what happens?
    - JoshTriplett 15y ago
      Indeed. Ideally, the site would end up with the user's public key, and optionally their email address; they should use the former as the primary key in their database, and the latter as an easily-changed property.
      - bct 15y ago
        That would be nice except I think that you will have different keys for different browsers, and for different machines. Presumably you could sync them up if you really wanted to, but it would be an awful user experience if that was mandatory.
  - ignifero 15y ago
    The implementation at browserid.org returns the email only. So there's no way to change the email without visiting all the sites you've registered in using browserid.
stickfigure 15y ago
One huge problem: Email address != identity. I should be able to change my email address (and/or email hosting provider) without changing my identity on a bazillion sites around the internet. Facebook got this right from the beginning. Google is sort-of getting this, although the chasm between Google Accounts and Google Apps Accounts makes this really messy. Really this product should be called BrowserEmailAddress, not BrowserID. It doesn't serve identity.
- paulosman 15y ago
  I agree that email address != identity, but nothing would stop a site that uses BrowserID from allowing a user to change the email address that they use on that site. It's very similar to the countless existing services that rely on email for identity... you'd just have to verify ownership of the new email address (usually through a confirmation email).
  - yarone 15y ago
    My thoughts exactly. I actually respect the thinking process which is: rather than invent something from scratch (some new user ID), let's use something that everyone is already familiar with: a traditional e-mail address.
  - stickfigure 15y ago
    Sure, every website can implement this flow, and users could could go to every website they've ever logged into and update their email address... assuming it all works properly even though they might not have access to the old email address anymore. At the very best this technology offers considerably less value to websites and more hassle to users than Facebook or Google. And it's about 5 years too late.
    - paulosman 15y ago
      "Sure, every website can implement this flow, and users could could go to every website they've ever logged into and update their email address... assuming it all works properly even though they might not have access to the old email address anymore." And how is this different than the current situation? Nearly all web sites require an email address. With BrowserID, you at some point confirmed ownership of that email address, so you could continue to use it to login, then change when you're ready. "At the very best this technology offers considerably less value to websites and more hassle to users than Facebook or Google. And it's about 5 years too late." Tell that to users who a) don't have Facebook accounts or b) don't want to use Google or Facebook with their identity. Far more people have email addresses than Facebook or Google accounts.
pavel_lishin 15y ago
Was that... was that a blink tag?
- deleted 15y ago
  [deleted]
ignifero 15y ago
You can try it live at http://textchannels.com/ http://textchannels.com/ . I like it , it's pretty simple and neat. Easier than oauth login.
- riffraff 15y ago
  can you explain why this is easier than oauth?
  - ignifero 15y ago
    - No need to register your application with browserid.org - No need to use an oauth library (just 1 GET request) - Oauth provides access to user data on the provider, while browserID provides no data. Less anxiety for the users. - No request_token/access_token pairs - In the future, the user will (hopefully) be able to change his default browserid and as a developer you just don't care.
    - riffraff 15y ago
      thanks, I thought you meant it was easier _as an end user_ and could not see why.
      - JoshTriplett 15y ago
        The implementation using browserid.org, to an end user, will not get any easier or harder than OAuth or any other third-party service. On the other hand, a browser-based implementation could simply bring up a browser notification saying "Authenticate to example.org using your email address?", to which you could click "yes".
SeoxyS 15y ago
They seriously need to work on their communication skills. It took me a good 15min to figure out what this thing actually does. And I'm still not sure I got it right. OpenID failed because it was too complicated for mere mortals. This, I fear, may be too confusing. At least form the way it's presented. After reading the protocol spec, I have a somewhat better understanding of this. If I got this right, this is basically what this does: * asymmetric crypto authentication in the backend. * control over email address == authentication. * allows a trusted third-party to authenticate the user. This could be a user or a web service (like browserid.org?). * falls back to regular email authentication we see every day. I'm still unclear how you can securely verify email ownership thru cryptographic means. Anybody care to explain it?
- ignifero 15y ago
  They give you a token, you do a GET request to browserid.org with it and get the user's email, that's all. The user has to register their email with browserid.org first.
  - dave1010uk 15y ago
    Wasn't one of the benefits that you don't need to rely on a third party service?
    - ignifero 15y ago
      I believe you will definately rely on one (of many possible) 3rd parties.
    - JoshTriplett 15y ago
      The third-party service handles the case where the user's browser doesn't handle BrowserID natively, which makes it possible to adopt this service without waiting for user's browsers to catch up.
- bct 15y ago
  Ignifero described what happens when your browser or email provider don't support BrowserID. When your browser and email provider both support BrowserID: 1. You log into e.g. gmail. 2. Your browser generates a keypair and sends the public key to gmail. 3. Gmail signs your public key and sends your browser a certificate saying "this key is owned by whoever@gmail.com". 4. You click "sign in" on some site (e.g. Hacker News) that uses BrowserID. 5. Your browser sends Hacker News an message saying "my user is whoever@gmail.com", that is signed with the private key generated in step 2. 6. Hacker News looks at the "gmail.com", grabs gmail's public key (the one that signed your public key in step 3) and verifies the signatures. Hacker News now knows that you control whoever@gmail.com. The process is described fairly well (diagrams and everything) at http://lloyd.io/how-browserid-works http://lloyd.io/how-browserid-works
superuser2 15y ago
My first ever programming project (I was 11) was basically this (edit: from a UI perspective, not under the hood), in PHP. I had no idea what I was doing, the architecture was questionable and at this point decentralization and OpenID were new and hot. It flopped horribly; it would have been a nightmare had it taken off, but it was fun. My flow was basically this: website links to http://my-site/login?to=http://site.com/authenticate http://my-site/login?to=http://site.com/authenticate. User logs in against my MySQL database with an email I verified and a password. If successful, I generate a "ticket" number, my site makes an HTTP post to http://site.com/recevive http://site.com/recevive with md5(ticket number + secret key) and the user's details, and then the user is redirected to http://site.com/authenticate?ticket=12345 http://site.com/authenticate?ticket=12345. Site.com verified the ticket using its API key and stuck it in its database. When the user hits site.com/authenticate, it looks it up by ticket number and has that person's details. Obviously a terrible idea for a number of reasons (MD5, the race condition between the user and the ticket, and the reliance on my shared server being up) but my 11-year-old self thought it was pretty cool. Just thought I'd share.
- rubyrescue 15y ago
  that's a really cool project at 11 years old, both in terms of your idea and what you can actually accomplish! off topic, but when i was 11 i had a c64 and basic and couldn't dream of talking to another computer unless i saved my program to the tape drive and had my mom drive me to my friend's house to load it on his c64.
Raphael 15y ago
And then you get phished for your one password.
- JoshTriplett 15y ago
  The password only applies to browserid.org, not the browserid standard. Native browser implementations won't involve a password, just a public/private key.
deleted 15y ago
[deleted]
rnicholson 15y ago
Interesting that in the demo video he used in-browser Gmail vs. using Thunderbird. I realize its nitpicky, but figured for a demo like this Mozilla would use the opportunity to showcase all their offerings in the workflow.
rkalla 15y ago
I interpreted this as OAuth + Gravatar... is that the gist?
flashmob 15y ago
Email != authentication Websites providing a disposable email address are mainstream - even hotmail allows you to create them these days.
kpanghmc 15y ago
Am I the only one who kind of wishes we never went down this "let's fix authentication!" rabbit hole? It feels like we've just replaced one problem with another. Now, instead of simply having to remember what username/password combination I used, I have to remember which (if any) OpenID provider I used, how much information about myself does said provider expose, and how to merge my accounts when I inevitably end up choosing the wrong provider and create a duplicate account on the site.
- ora600 15y ago
  You see, passwords suck. Big time. They are extremely vulnerable to brute-force attacks, people forget them, people write them down on post-it notes, and people use the same password on every single site. Not to mention that the website has to store your password securely, and not every website has amazing track record doing that. Passwords make the world less secure. So we need to replace them with something. And that "something" has to be secure and easy to use. Turns out that this is a difficult problem to solve, so we keep trying. I agree that OpenID is not exactly the perfect solution, but it doesn't mean that there is no problem to solve.
  - kpanghmc 15y ago
    I never said that there wasn't a problem. I'm simply saying that the solutions we've come up with so far have not yielded a net gain. If anything, the site owners that I know who have incorporated OpenID / Facebook Connect / etc. into their sign up / login forms have said that they have to answer more questions from users having login issues than ever before.
- starwed 15y ago
  Did you read the article? This is an attempt to fix all those issues you list.
  - kpanghmc 15y ago
    BrowserID only fixes those issues if it ends up as the only game in town. Otherwise, it's simply going to be tacked onto the end of a daunting list of other OpenID / BrowserID providers that users will have to choose from.
jerrya 15y ago
I like this idea, and I hope mailinator supports it.
newman314 15y ago
Thought that popped into my head. Instead of having separate passwords for different sites, now you are trusting your email provider to be absolutely secure (with that one ultra-secure password you are using, right?). So if a BrowserID user were to ever get their email service compromised, it's keys to the kingdom. IMO, I think this needs a rethink.
- caf 15y ago
  The idea is that you would use this in situations where you currently would offer a "reset password via email" option - since this means you already treats control of the email address as identity.
  - newman314 15y ago
    Wondering why I was downvoted for pointing this out. But anyways, my impression from reading the page was this is not just used as a password reset scenario but as a general login method. Which if you agree with, leads us back to the scenario where authentication & authorization lies solely with the email account, which if compromised is the single point of failure. I would appreciate it if someone were to help point out what flaws there in this line of thought rather than a straight downvote with no explanation.
    - Dove 15y ago
      If an email account can be used for password reset, a compromised email account can be used to log in. Since much of the internet already works this way, the proposed system has a neutral effect on security, while making things easier for users. In effect, any site that offers a password reset via email is already using your email as your identity.
      - bxc 15y ago
        I actually use this as the primary authentication mechanism for sites I rarely/occasionally visit... password reset at every login!
lojack 15y ago
Do people really consider OAuth2 difficult to implement? Also, not trying to knock BrowserID or say that it'll never work, but due to browser compatibility this is still probably 5 years off before I'd begin using it. From what I can gather it requires postMessage which alienates IE7 users.
rlpb 15y ago
This looked great until I got to certification. At this point I think they've just re-invented X.509 and added browser/Javascript integration. Why not have a new way of using X.509 in the browser? I'm not talking about client side SSL certificates as they are at the moment. I mean that on login to your mail provider the browser will automatically generate a keypair and get a certificate either from your mail provider or from a third party which has verified that you own the email address in the traditional way. This certificate will contain a Subject of mail=me@example.com, Issuer of either CN=example.com or CN=trustedverifier.com. Then the browser can just present that certificate as normal to destination.com, and perhaps only on request (so the user can choose whether to "log in" or not). If the issuer matches my email address domain then destination.com will fetch the public certificate of example.com to verify. If the issuer matches trustedverifier.com then destination.com will already know whether it wants to trust it or not and have the public key if it does. This does seem to be what the article describes, only the article has more optional elements and re-invents some of the cryptosystem rather than re-using X.509.
NHQ 15y ago
This is just another web based open sign-in. Why did they tie this to email, of all things? My immediate thought was that a browser-based ID implementation would let you keep secure credential on the computer, saved by the browser, up to and including pics, profile, etc. In other words, take social credentials native.
detay 15y ago
I don't want to see another browser-specific feature from mozilla. As mentioned here several times it doesn't seem too different from openId and it's for mozilla! seemed pointless to me.
AlexeyMK 15y ago
BrowserID is a good first step, but ultimately as a website owner I'd much rather authenticate with Twitter/Facebook, since it makes it easier for me to figure out who the user is/ask them to share with friends. Identity is cool, but Facebook is winning the 3rd party connect game right now because it offers websites syndication, which is more valuable than just authentication. I'd love to see a BrowserID that can also grant permissions to Facebook, Twitter, etc.
- AndrewDucker 15y ago
  I do not want to link my Facebook with anything else. Nor do I wish to link my Twitter to that. I do not trust either of these companies, or have a strong attachment to them. If they want to support BrowserID then they can - as username@facebook.com or username@twitter.com
orijing 15y ago
Does that mean this is as secure as the user's email provider? What if I have an AOL email and AOL gets hacked?
alecbenzer 15y ago
anyone else notice the video is recent enough to have google+ enabled?
drfloob 15y ago
Say you're signed in to BrowserID already ... is there anything that would stop an attacker from being able to log you into some other BrowserID website without your knowledge or consent? With login reduced to two mouse clicks, it seems like a well-crafted webpage could log you in wherever it wanted. If that were the case, a CSRF-vulnerable BrowserID webpage could easily be exploited at a large scale.
bergie 15y ago
Somehow I find WebID (http://www.w3.org/wiki/WebID http://www.w3.org/wiki/WebID) more appealing. There are already countries that give their citizens SSL client certs.
- bergie 15y ago
  Here's a quick WebID to BrowserID comparison: http://lists.w3.org/Archives/Public/public-xg-webid/2011Jul/0011.html http://lists.w3.org/Archives/Public/public-xg-webid/2011Jul/...
nikcub 15y ago
can't see it taking off only because it solves a problem that 99% of internet users do not know exists. I have never had a regular, average, non-tech internet user say to me 'you know what is a real pain in the ass - signing up for web applications'. Most of those users only ever signup for a handful of applications, and are using oauth for everything else (twitpic etc.)
nolliesnom 15y ago
By what mechanism does BrowserID require RPs to respect the valid-until field?

364 points by joeshaw 15y ago

How is this any different than current single signon systems, like Microsoft Live, Yahoo, Google, Facebook Connect.. I mean sure maybe this is open and anyone can run their own but lets not forget users dont care at all about that..

bct 15y ago
As a user, once your browser and email provider support it, it's single-click login (and signup), without any redirects. As a site operator, you don't need to choose which company you're going to accept as an auth provider, or have a login page with lots of icons on it; you just have one button that says "Log in".

omarqureshi 15y ago

Whilst I understand and really like the non-tied in aspect of it, I'd probably implement some sort of facebook/twitter/google account authentication alongside of it. Reason being is that, it too is just another authentication service that I'd rather users not have to make the effort to sign up for.

bct 15y ago
The intention seems to be that browserid.org is temporary, just there so that this can work until it's supported by browsers and identity providers directly. Once that is achieved, there's nothing extra to sign up for.
- omarqureshi 15y ago
  Sorry, the video didnt make that clear - not even slightly.

bruceboughton 15y ago

Can someone explain what makes this a browser ID? I don't get it...

mbrubeck 15y ago
It's designed so that the browser can interact directly with the authentication protocol, saving steps for the user. This grew out of Mozilla Labs' "account manager" project, which had a protoype UI you can see here: http://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/ http://hacks.mozilla.org/2010/04/account-manager-coming-to-f...

sirn 15y ago

How is it different from OpenID, apart from it's not decentralized?

cgranade 15y ago
I'm wondering if it's at all possible to integrate this with OpenID, and how this interacts with previous Mozilla Identity projects to make your identity a part of the browser chrome. It all seems rather tangential to their other efforts, rather than coherent with.
- JoshTriplett 15y ago
  I certainly hope it isn't possible to integrate this with OpenID. If it is, sites will just continue relying on OpenID, and treat this as a weird special case, rather than a superseding technology that gives the user control without requiring a third-party provider.
deleted 15y ago
[deleted]
mbrubeck 15y ago
This lets users sign in with an existing email address, so they don't need any new sevice or identifier to remember. It's decentralized; Mozilla has a service for web developers for convenience, but any site can implement the protocol itself instead (or use another provider). And it's designed to let browsers handle the login flow in the future, simplifying login and account creation for end-users.
- pavel_lishin 15y ago
  Most of the oauth services I used allowed me to create an account with ... an e-mail and a password. Literally the same thing, here.
  - Osiris 15y ago
    Isn't one of the advantages of this system is that your password doesn't get stored by the website? Just some type of token? If their database gets stolen or leaked, they shouldn't be able to hash attack your password and gain access to it since it's not there. I'm just assuming it works this way, as passing the password along would defeat the security of the system and make you more vulnerable.

shockie 15y ago

What's the advantage over openid?

bct 15y ago
Some people think that using URLs instead of email address in OpenID was a big mistake. Having in-browser support for this kind of thing seems like a plus, too.
- NathanKP 15y ago
  Email addresses are something that people are fairly familiar with when it comes to signing in. Trying to explain why URL's are used instead of email addresses in OpenID is difficult when you are dealing with a non techy user.
- codyrobbins 15y ago
  To this day I still do not understand how this inane argument happened to be the single thing that killed OpenID. How is ‘cody.my-open-id-provider.com’ more confusing as a login than ‘cody@my-email-provider.com’? Hint: it’s not. I’m not one for conspiracy theories, but the whole URL-versus-email argument against OpenID seemed like the excuse various people used to put a nail in OpenID’s coffin when they didn’t like it for other less defensible reasons.
  - nl 15y ago
    I'm a reasonably competent web user. I've implemented OpenID. I run my own Open ID server. I've implemented Shibboleth (and lived!). I know that Yahoo is an open ID provider, and I think Google is too, but when I'm presented with an old-style (URL) OpenId login I don't have a clue what to enter to use either my Yahoo or Google account to login. Yes, I know that now most login forms provide easy links to use Google or Yahoo to login. The point is that entering the URL is confusing because no one knows what their OpenID url is, and it isn't standardized in anyway. The situation is so bad that the OpenID providers had to develop a way for users to enter their email addresses, and then the client performs a discovery request to find their URL.

ams6110 15y ago

More at https://browserid.org/ https://browserid.org/

falava 15y ago
and https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol

tobylane 15y ago

I hope that one of these services is on the user's side, so much that the ID isn't enough for, say, advertisers to track users over different sites. And how graceful is it for versions of IE that aren't 'recent'?

ams6110 15y ago

This seems to encourage using the same credentials everywhere which I think most agree is a "bad idea." If BrowserID is compromised, the attackers have access to all the sites where I use browser id, right?

bct 15y ago
Once this is supported by browsers and email providers there is no "BrowserID" to be compromised, your email provider would have to be compromised (which already gives attackers access to all the sites that you use that email on). (Unless you meant "BrowserID" the protocol.)
ignifero 15y ago
Isn't that what happens when someone compromises your email too?
jdunck 15y ago
There is a large distinction here - the provider (in the video, BrowserID.org) would have to be compromised, as only they have your credentials. This is quite a bit different and more secure than using the same credentials with many different providers, because in that scenario, the weakest of any party could get compromised and that way compromise all parties.
- slowpoke 15y ago
  In addition to that, since the ID provider does not get any sort of information about which websites you visit with your ID, it would be impossible to know where exactly the ID is in use. At least that's how I understand it.
mrinterweb 15y ago
The same could be said about OpenID and OAuth providers like Twitter, Facebook, Google, etc. The idea of having a centralized authentication provider is definitely not a new one. There are many advantages to using 3rd party authentication providers. The biggest security advantage 3rd party auth providers have is that they do security right and often they implement their authentication service using a commonly defined protocol. Many websites that choose to roll their own systems make many security mistakes and many people use the same credentials on many sites. So if any website is not secure authentication a user's login information is likely compromised across multiple websites because people generally use the same credentials.

ukaszg 15y ago

so, its an easier way for sites to track users?

bct 15y ago
Not really. It's a way for a user to prove to a site that they control an email address.
- ukaszg 15y ago
  sounds like tracking to me
  - bct 15y ago
    Ok, but only In the same way that typing in a username and password on a website allows them to track you.
    - capnrefsmmat 15y ago
      Various forums already verify you own a certain email account when you sign up. Basically everyone does to send your account information or their marketing stuff. This isn't new.
    - superuser2 15y ago
      To have a conversation with someone, you have to uniquely identify them, and correlate all the words they've said as coming out of their mouth and not somebody else's, then put all these words (which you've identified as being part of the same sentence) together into meaning. As you get to know someone, you correlate all these meanings into a mental model of the person, and use this to guide how you interact with them. People who can't do this are considered mentally ill. It's one of the defining pieces of consciousness, and essential to the human experience. So, as programmers, we make a deliberate choice to enable this functionality for end-users in most internet applications (like email, IM, social networking, and discussion boards) by displaying a token belonging to you (and only you) next to what you're saying and doing. This can be a username, email address, phone number, picture, etc. This particular spec is a more convenient way of establishing your ownership of a token used to identify you. You can choose to use sites (like 4chan) which don't reveal this information publicly. But if you sign your posts, or indicate in any way that you are the same person as a previous poster, you are establishing an identity which 4chan is tracking and revealing to the world. There is no conversation without tracking. Whether or not the sites you use choose to identify you, however, they know you by the IP address you are coming from; they have to, in order to send information back. Tor can mitigate this (if you change exit nodes with every request) by hiding your path from A to B within a cryptographically secure mass of data, but if the random number generator determining the amount of time to wait before forwarding your packets is broken, that's blown too. IP addresses change, so if I want to correlate you between your ISP's DHCP leases (or between your multiple internet connections - Starbucks, home, work), I'll set a cookie. This is how when you clicked "reply", Hacker News knew it was still the same person who logged in with "ukaszg/hunter2". Tracking is essential to civilized conversation. To fight tracking itself is to ask that the entire Internet become 4chan and that nobody assume the same identity from post to post. I hope this isn't what you mean. -- Tracking makes you nervous because a) computers exhibiting human behavior is kind of creepy b) sometimes, companies choose to violate users' expectations of what will be done with the information they've correlated But you can't take this information away from them while still using their services. You can refuse to use services which violate your expectations, you can demand better, and I encourage you to. But ultimately, these services have to pay the bills and make a profit. I could be wrong, but I'm going to take a wild guess and say you wouldn't pay for Facebook; I'm going to go even further and say that you would be offended at the idea of having to pay for Facebook. Well, Facebook's employees want to feed their children and buy cars and houses and video games and TVs just like you. And Facebook's owners and investors want to get rich. If these objectives aren't met, there won't be a Facebook. So instead of taking your money, they take what they can guess about what you will buy, and charge advertisers for it. Advertisers, in turn, can show you products which you won't scoff at paying for, and eventually some less speculative cash enters the equation. You cannot avoid tracking. But if you want the companies tracking you to conform to your expectation that your data not be used to sell you stuff, you're going to have to pay them. Rackspace email is $2/mailbox/month. There are no ads.

NathanKP 15y ago

When I tried to sign in on the demo site I got a 502 Bad Gateway error. This isn't an encouraging sign.

ora600 15y ago

What I'd really want to see is public-key authentication for website. Let me upload my public key when I create an account on a website, and let the browser interact with my ssh-agent to authenticate.

JanezStupar 15y ago
This... A million times this. Where do I signup?
lucian1900 15y ago
This. Perhaps ssh+http is the solution.
- Iaks 15y ago
  Where is 'this.' coming from? Coding syntax? I just don't get it. I've seen it in HN comments for a few days now, but I fail to understand how 'this.' relates any new information. Reply indenting already tells me you are referring to an antecedent post. (A specific post in fact.) Am I missing something, or is this just a new web fad I'm not savvy too? (Second option is not entirely unlikely...)
  - StavrosK 15y ago
    It's just for added emphasis. It's the contraction of roughly "this is the correct answer".
    - Iaks 15y ago
      Thanks for enlightening me =)
  - absconditus 15y ago
    It is popular on sites like reddit. It basically means "I agree".
  - billforsternz 15y ago

yarone 15y ago

So, it's basically a traditional single-sign on system? Is that right? Like, in the old days, I integrated one of my products with AOL. You could click a link and it would automatically sign you into my product using you AOL Screenname and Password (behind the scenes, AOL would verify that the screenname and password are correct and my app would create a new user in my database).

bct 15y ago
Your description is too vague to generate an answer to your question.

latchkey 15y ago

This is full of fail. Your email address is not your identity. I must be able to change my email address without having to change my identity.

51Cards 15y ago
It's not that simple. They authenticate against your Account at Browser ID. I would assume you can go into Browser ID and add / remove email addresses from your account which makes it even easier when you change your email. Now you don't have to visit 20 different sites to update them.
- stickfigure 15y ago
  Is there some sort of account ID other than an email address? It looks like the email is all that gets sent to the website (although I didn't read deeply enough to be sure). If you change (add new, remove old) your email address at browserid.org then revisit a site you authenticated to before, what happens?
  - JoshTriplett 15y ago
    Indeed. Ideally, the site would end up with the user's public key, and optionally their email address; they should use the former as the primary key in their database, and the latter as an easily-changed property.
    - bct 15y ago
      That would be nice except I think that you will have different keys for different browsers, and for different machines. Presumably you could sync them up if you really wanted to, but it would be an awful user experience if that was mandatory.
- ignifero 15y ago
  The implementation at browserid.org returns the email only. So there's no way to change the email without visiting all the sites you've registered in using browserid.

stickfigure 15y ago

One huge problem: Email address != identity. I should be able to change my email address (and/or email hosting provider) without changing my identity on a bazillion sites around the internet. Facebook got this right from the beginning. Google is sort-of getting this, although the chasm between Google Accounts and Google Apps Accounts makes this really messy. Really this product should be called BrowserEmailAddress, not BrowserID. It doesn't serve identity.

paulosman 15y ago
I agree that email address != identity, but nothing would stop a site that uses BrowserID from allowing a user to change the email address that they use on that site. It's very similar to the countless existing services that rely on email for identity... you'd just have to verify ownership of the new email address (usually through a confirmation email).
- yarone 15y ago
  My thoughts exactly. I actually respect the thinking process which is: rather than invent something from scratch (some new user ID), let's use something that everyone is already familiar with: a traditional e-mail address.
- stickfigure 15y ago
  Sure, every website can implement this flow, and users could could go to every website they've ever logged into and update their email address... assuming it all works properly even though they might not have access to the old email address anymore. At the very best this technology offers considerably less value to websites and more hassle to users than Facebook or Google. And it's about 5 years too late.
  - paulosman 15y ago
    "Sure, every website can implement this flow, and users could could go to every website they've ever logged into and update their email address... assuming it all works properly even though they might not have access to the old email address anymore." And how is this different than the current situation? Nearly all web sites require an email address. With BrowserID, you at some point confirmed ownership of that email address, so you could continue to use it to login, then change when you're ready. "At the very best this technology offers considerably less value to websites and more hassle to users than Facebook or Google. And it's about 5 years too late." Tell that to users who a) don't have Facebook accounts or b) don't want to use Google or Facebook with their identity. Far more people have email addresses than Facebook or Google accounts.

pavel_lishin 15y ago

Was that... was that a blink tag?

deleted 15y ago
[deleted]

ignifero 15y ago

You can try it live at http://textchannels.com/ http://textchannels.com/ . I like it , it's pretty simple and neat. Easier than oauth login.

riffraff 15y ago
can you explain why this is easier than oauth?
- ignifero 15y ago
  - No need to register your application with browserid.org - No need to use an oauth library (just 1 GET request) - Oauth provides access to user data on the provider, while browserID provides no data. Less anxiety for the users. - No request_token/access_token pairs - In the future, the user will (hopefully) be able to change his default browserid and as a developer you just don't care.
  - riffraff 15y ago
    thanks, I thought you meant it was easier _as an end user_ and could not see why.
    - JoshTriplett 15y ago
      The implementation using browserid.org, to an end user, will not get any easier or harder than OAuth or any other third-party service. On the other hand, a browser-based implementation could simply bring up a browser notification saying "Authenticate to example.org using your email address?", to which you could click "yes".

SeoxyS 15y ago

They seriously need to work on their communication skills. It took me a good 15min to figure out what this thing actually does. And I'm still not sure I got it right. OpenID failed because it was too complicated for mere mortals. This, I fear, may be too confusing. At least form the way it's presented. After reading the protocol spec, I have a somewhat better understanding of this. If I got this right, this is basically what this does: * asymmetric crypto authentication in the backend. * control over email address == authentication. * allows a trusted third-party to authenticate the user. This could be a user or a web service (like browserid.org?). * falls back to regular email authentication we see every day. I'm still unclear how you can securely verify email ownership thru cryptographic means. Anybody care to explain it?

ignifero 15y ago
They give you a token, you do a GET request to browserid.org with it and get the user's email, that's all. The user has to register their email with browserid.org first.
- dave1010uk 15y ago
  Wasn't one of the benefits that you don't need to rely on a third party service?
  - ignifero 15y ago
    I believe you will definately rely on one (of many possible) 3rd parties.
  - JoshTriplett 15y ago
    The third-party service handles the case where the user's browser doesn't handle BrowserID natively, which makes it possible to adopt this service without waiting for user's browsers to catch up.
bct 15y ago
Ignifero described what happens when your browser or email provider don't support BrowserID. When your browser and email provider both support BrowserID: 1. You log into e.g. gmail. 2. Your browser generates a keypair and sends the public key to gmail. 3. Gmail signs your public key and sends your browser a certificate saying "this key is owned by whoever@gmail.com". 4. You click "sign in" on some site (e.g. Hacker News) that uses BrowserID. 5. Your browser sends Hacker News an message saying "my user is whoever@gmail.com", that is signed with the private key generated in step 2. 6. Hacker News looks at the "gmail.com", grabs gmail's public key (the one that signed your public key in step 3) and verifies the signatures. Hacker News now knows that you control whoever@gmail.com. The process is described fairly well (diagrams and everything) at http://lloyd.io/how-browserid-works http://lloyd.io/how-browserid-works

superuser2 15y ago

My first ever programming project (I was 11) was basically this (edit: from a UI perspective, not under the hood), in PHP. I had no idea what I was doing, the architecture was questionable and at this point decentralization and OpenID were new and hot. It flopped horribly; it would have been a nightmare had it taken off, but it was fun. My flow was basically this: website links to http://my-site/login?to=http://site.com/authenticate http://my-site/login?to=http://site.com/authenticate. User logs in against my MySQL database with an email I verified and a password. If successful, I generate a "ticket" number, my site makes an HTTP post to http://site.com/recevive http://site.com/recevive with md5(ticket number + secret key) and the user's details, and then the user is redirected to http://site.com/authenticate?ticket=12345 http://site.com/authenticate?ticket=12345. Site.com verified the ticket using its API key and stuck it in its database. When the user hits site.com/authenticate, it looks it up by ticket number and has that person's details. Obviously a terrible idea for a number of reasons (MD5, the race condition between the user and the ticket, and the reliance on my shared server being up) but my 11-year-old self thought it was pretty cool. Just thought I'd share.

rubyrescue 15y ago
that's a really cool project at 11 years old, both in terms of your idea and what you can actually accomplish! off topic, but when i was 11 i had a c64 and basic and couldn't dream of talking to another computer unless i saved my program to the tape drive and had my mom drive me to my friend's house to load it on his c64.

Raphael 15y ago

And then you get phished for your one password.

JoshTriplett 15y ago
The password only applies to browserid.org, not the browserid standard. Native browser implementations won't involve a password, just a public/private key.

deleted 15y ago

[deleted]

rnicholson 15y ago

Interesting that in the demo video he used in-browser Gmail vs. using Thunderbird. I realize its nitpicky, but figured for a demo like this Mozilla would use the opportunity to showcase all their offerings in the workflow.

rkalla 15y ago

I interpreted this as OAuth + Gravatar... is that the gist?

flashmob 15y ago

Email != authentication Websites providing a disposable email address are mainstream - even hotmail allows you to create them these days.

kpanghmc 15y ago

Am I the only one who kind of wishes we never went down this "let's fix authentication!" rabbit hole? It feels like we've just replaced one problem with another. Now, instead of simply having to remember what username/password combination I used, I have to remember which (if any) OpenID provider I used, how much information about myself does said provider expose, and how to merge my accounts when I inevitably end up choosing the wrong provider and create a duplicate account on the site.

ora600 15y ago
You see, passwords suck. Big time. They are extremely vulnerable to brute-force attacks, people forget them, people write them down on post-it notes, and people use the same password on every single site. Not to mention that the website has to store your password securely, and not every website has amazing track record doing that. Passwords make the world less secure. So we need to replace them with something. And that "something" has to be secure and easy to use. Turns out that this is a difficult problem to solve, so we keep trying. I agree that OpenID is not exactly the perfect solution, but it doesn't mean that there is no problem to solve.
- kpanghmc 15y ago
  I never said that there wasn't a problem. I'm simply saying that the solutions we've come up with so far have not yielded a net gain. If anything, the site owners that I know who have incorporated OpenID / Facebook Connect / etc. into their sign up / login forms have said that they have to answer more questions from users having login issues than ever before.
starwed 15y ago
Did you read the article? This is an attempt to fix all those issues you list.
- kpanghmc 15y ago
  BrowserID only fixes those issues if it ends up as the only game in town. Otherwise, it's simply going to be tacked onto the end of a daunting list of other OpenID / BrowserID providers that users will have to choose from.

jerrya 15y ago

I like this idea, and I hope mailinator supports it.

newman314 15y ago

Thought that popped into my head. Instead of having separate passwords for different sites, now you are trusting your email provider to be absolutely secure (with that one ultra-secure password you are using, right?). So if a BrowserID user were to ever get their email service compromised, it's keys to the kingdom. IMO, I think this needs a rethink.

caf 15y ago
The idea is that you would use this in situations where you currently would offer a "reset password via email" option - since this means you already treats control of the email address as identity.
- newman314 15y ago
  Wondering why I was downvoted for pointing this out. But anyways, my impression from reading the page was this is not just used as a password reset scenario but as a general login method. Which if you agree with, leads us back to the scenario where authentication & authorization lies solely with the email account, which if compromised is the single point of failure. I would appreciate it if someone were to help point out what flaws there in this line of thought rather than a straight downvote with no explanation.
  - Dove 15y ago
    If an email account can be used for password reset, a compromised email account can be used to log in. Since much of the internet already works this way, the proposed system has a neutral effect on security, while making things easier for users. In effect, any site that offers a password reset via email is already using your email as your identity.
    - bxc 15y ago
      I actually use this as the primary authentication mechanism for sites I rarely/occasionally visit... password reset at every login!

lojack 15y ago

Do people really consider OAuth2 difficult to implement? Also, not trying to knock BrowserID or say that it'll never work, but due to browser compatibility this is still probably 5 years off before I'd begin using it. From what I can gather it requires postMessage which alienates IE7 users.

rlpb 15y ago

This looked great until I got to certification. At this point I think they've just re-invented X.509 and added browser/Javascript integration. Why not have a new way of using X.509 in the browser? I'm not talking about client side SSL certificates as they are at the moment. I mean that on login to your mail provider the browser will automatically generate a keypair and get a certificate either from your mail provider or from a third party which has verified that you own the email address in the traditional way. This certificate will contain a Subject of mail=me@example.com, Issuer of either CN=example.com or CN=trustedverifier.com. Then the browser can just present that certificate as normal to destination.com, and perhaps only on request (so the user can choose whether to "log in" or not). If the issuer matches my email address domain then destination.com will fetch the public certificate of example.com to verify. If the issuer matches trustedverifier.com then destination.com will already know whether it wants to trust it or not and have the public key if it does. This does seem to be what the article describes, only the article has more optional elements and re-invents some of the cryptosystem rather than re-using X.509.

NHQ 15y ago

This is just another web based open sign-in. Why did they tie this to email, of all things? My immediate thought was that a browser-based ID implementation would let you keep secure credential on the computer, saved by the browser, up to and including pics, profile, etc. In other words, take social credentials native.

detay 15y ago

I don't want to see another browser-specific feature from mozilla. As mentioned here several times it doesn't seem too different from openId and it's for mozilla! seemed pointless to me.

AlexeyMK 15y ago

BrowserID is a good first step, but ultimately as a website owner I'd much rather authenticate with Twitter/Facebook, since it makes it easier for me to figure out who the user is/ask them to share with friends. Identity is cool, but Facebook is winning the 3rd party connect game right now because it offers websites syndication, which is more valuable than just authentication. I'd love to see a BrowserID that can also grant permissions to Facebook, Twitter, etc.

AndrewDucker 15y ago
I do not want to link my Facebook with anything else. Nor do I wish to link my Twitter to that. I do not trust either of these companies, or have a strong attachment to them. If they want to support BrowserID then they can - as username@facebook.com or username@twitter.com

orijing 15y ago

Does that mean this is as secure as the user's email provider? What if I have an AOL email and AOL gets hacked?

alecbenzer 15y ago

anyone else notice the video is recent enough to have google+ enabled?

drfloob 15y ago

Say you're signed in to BrowserID already ... is there anything that would stop an attacker from being able to log you into some other BrowserID website without your knowledge or consent? With login reduced to two mouse clicks, it seems like a well-crafted webpage could log you in wherever it wanted. If that were the case, a CSRF-vulnerable BrowserID webpage could easily be exploited at a large scale.

bergie 15y ago

Somehow I find WebID (http://www.w3.org/wiki/WebID http://www.w3.org/wiki/WebID) more appealing. There are already countries that give their citizens SSL client certs.

bergie 15y ago
Here's a quick WebID to BrowserID comparison: http://lists.w3.org/Archives/Public/public-xg-webid/2011Jul/0011.html http://lists.w3.org/Archives/Public/public-xg-webid/2011Jul/...

nikcub 15y ago

can't see it taking off only because it solves a problem that 99% of internet users do not know exists. I have never had a regular, average, non-tech internet user say to me 'you know what is a real pain in the ass - signing up for web applications'. Most of those users only ever signup for a handful of applications, and are using oauth for everything else (twitpic etc.)

nolliesnom 15y ago

By what mechanism does BrowserID require RPs to respect the valid-until field?