We've been live for several months now in the Real World - our userbase (amateur athletes) is primarily nontechnical. About half of our users choose Persona/BrowserID and half choose Facebook. We were initially concerned about the BID login flow (in particular, the immediate email roundtrip) but it hasn't been a problem and the UX has been refined quite a lot over the last month or two.
For a mass-consumer audience, the combined FB/Persona solution is excellent:
* Facebook unquestionably has the slickest auth experience, even eliminating the followup name/sex/bday questions. However, a significant percentage of the world (possibly > 25%) either Hates Facebook or wants to keep their Facebook account isolated. This is unlikely to change in the near future and could even get worse depending on what sleeping dogs Zuckerberg decides to kick next week. We don't have the option of alienating the FB haters and we wouldn't want to anyways.
* The Persona UX is good and rapidly getting better. BigTent integration with gmail, yahoo, hotmail will bring one-click login to those users. A native experience is being built into browser chrome. All this is coming without me having to write code. It may not be as slick as Facebook, but I like where this train is headed.
* Integration is simple compared to writing a username/password system. The API is incredibly easy to work with. Dual-auth with Facebook is a little more complicated, but a complete Persona-based auth system is a question of hours, not days.
* The fact that identity is just an email address makes it easier to integrate with existing login systems. In our system, you can log into the same account with both Facebook and Persona as long as the emails match. No, email is not a perfect identifier, but even nontechnical users understand it immediately and really - what other option is there? "What email address did I use?" is a lot better than "What weird combination of letters and numbers did I use as a login name?"
* Support on the Mozilla dev-identity list has been fantastic.
We're pretty happy. Honestly, I don't ever see myself writing another username/password login system ever again. Persona is less work for a better UX.
OK so I tried to sign up to your site with BID and am pretty confused:
I'm using Chrome. Don't know if that affects things. Anyway.
Hit Browser ID, asks me for my email address. OK fine, add that in. It then says (quickly, and temporarily as it's an AJAX load), that it's looking up my email provider (Google Apps). It then asks me for my password.
So now I'm totally confused. I've not signed up with your site or BID before, so I dont know if it wants my GAPPS password or a new password. I don't feel like I want to put in my GApps password, as there is no Google branding anywhere and the URL is not Google.
So I try putting in my GAPPS password, because I use 2 factor, and it doesn't work. Most likely because I use 2 factor, and I can't authenticate with just my standard GAPPS password.
So it failed. I guess I'm an edge case as most people don't enable 2-factor on their Google account, but I was still really confused when it asked for my email password.
EDIT:
Same thing happened with Firefox version whatever the latest one is.
"Website operators still get a verified email address for their users, and users only have to remember a single password. BrowserID is also intuitive, since email addresses are commonly understood to be associated with identities."
Mozilla is really stressing the "email address/single password" concept. If they really mean "email address/separate dedicated Persona password" then they should make this clear.
The language around the number of passwords you need is really hard to get right. If you have suggestions, please let me know.
In a world where every email provider supports Persona natively, Persona truly is a "no new passwords" authentication system, since it delegates to your provider. If your email address isn't supported, Persona asks you to create a single new password at login.persona.org. You can then add many other unsupported addresses, without needing more passwords. So it's an "at most one new password" system.
Simply always refer to the Persona password as "Persona password".
> In a world where every email provider supports Persona natively, Persona truly is a "no new passwords" authentication system, since it delegates to your provider.
I don't know what this means. I won't give Persona my gmail/yahoo-mail email password.
Yeah, it's confusing. If your email provider is supported, your browser talks directly to your email provider, without Mozilla in the middle. We don't want your passwords, honest! :)
You can try out the supported email provider workflow by signing up for a dummy account at eyedee.me, and then using that account to sign in at, say, 123done.org.
Wait, if this system works with a dummy account, then a valid email address isn't necessary at all. Any domain can set up an identity provider to support user@domain. Why drag email providers into the discussion, then? It confuses everyone.
It confuses you because you are a technologist. For 99.99% of the world, user@domain == email address.
"Sign in with your email address" gets the point across. "Sign in with your user identity at a controlling DNS authority" may be more accurate, but will actually confuse everyone.
I got confused by this as well. What's happening is that the email address he used already has a Persona account.
If your email address isn't known to Persona it will ask you to create a password, which is cool. Otherwise, it will just bring up a password box with your email address just above it.
I must have used BrowserID once when it was launched, because what the OP got happened to me and I was just as confused. It might not be a problem in the future when it's more well known, but it would be nice for it to have an indication that they want your Persona password, and not your email password.
Coincidentally I've asked a question about login system just two days ago (http://news.ycombinator.com/item?id=4225270) where I mentioned BrowserID as one of the options. Apparently I hadn't properly checked out BrowserID/Persona because I thought of it as an OpenID replacement, not an email+password login replacement.
I'm positively surprised to see that you found a 50-50 balance between BrowserID and Facebook; I expected a lower pickup rate on BrowserID. So, I guess I've decided what login system to use for my project(s).
This is probably the web-thing I'm most excited about today, even though the development is kinda slow. I really want to implement it as a sole identity provider on my websites some day.
EDIT: I also began writing a Safari extension that would work like the mockup above, but gave up halfway since it was too convoluted and totally insecure... maybe I should try writing a SIMBL plugin or something like that.
A website relying on a single service to serve as a sole identity provider seems replete with risks. That sounds remarkably similar to Microsoft's Passport, an idea that was a non-starter for everyone except Microsoft.
It's hard to explain, but it's not much a "service" - the current implementation is just a "shim", since no browser supports it natively. Client-wise, it's just a JavaScript API. In the future, your browser will store your keys, not Mozilla.
But even with the current implementation it is possible to validate the assertion in your server without contacting browserid.org, but AFAIK nobody did it yet.
(I tried to find a reference for that, but they took it down from their Wiki. It used to say "You may choose to validate assertions on your own server": https://github.com/mozilla/browserid/wiki/How-to-Use-Browser... - the verification code is still online, though)
Your browser already stores your keys, even with the shim. :)
Faaborg's mockups are awesome, but they're well over a year old and not really guiding our current work. Still, definitely take a look at them, if nothing else than for the cool way of doing mockups!
You can definitely do your own verification without having us in the loop, but we'd urge you to hold off until this fall; the IETF is still standardizing some of the data formats we're using, so the exact serialization of keys and assertions might change between now and then. By using our verifier, you're certain to be up to date.
We're a completely decentralized protocol, so there's no need to rely on a single service. To help with bootstrapping, we do offer a fallback to provision users without native support from their email providers, but there's nothing that ties any of this to Mozilla or a centralized service.
So we have this, Open ID, Facebook, Twitter, Google, Microsoft Passport/Live ID, and probably like five other major players I'm forgetting. I apologize for being pessimistic, but this just doesn't seem like a solvable problem. I want it to be solvable, but players like Facebook benefit far too much for them to not push their particular version of "universal" login on everyone. Every player seems to think they are the One True Solution... But so far, it's all one big mess. I don't see it getting better any time soon.
I think if you look at Kim Cameron's Laws of Identity, it's clear that the research team at MS has had it right for at least a decade, it's just that none of their ideas have made it into production.
Ballmer had both the plans and source code for an identity product that would have been 10x more advanced than Facebook, but they decided to axe the project so they could make the Zune instead.
BrowserID is designed to be integrated into the browser. There are some huge usability benefits possible when your browser can log in for you. If the browser UI succeeds in reducing friction for signup and login, that could motivate sites to adopt the protocol.
you could argue, but statistics would show you otherwise for the foreseeable future. regardless of wether or not they are 'losing it' they clearly got it right for a very long time.
I know this probably fits only me but I never use my email address as id.
Every company and every account I sign up for I give a different email address. I'm not about to use a single one for my ID. Especially when they are easy to spoof (any one can send mail as you@there.com) and they are easy to spam and abuse. I had an email address that got 3000 spams a day. That's why I never give use email as ID because I want to be able to disable any email address that's giving me trouble.
So, not interested in BrowserID I think. Or maybe I didn't grok it.
There is a lot of scope for one-time emails, pseudonymous emails and other kinds of not-my-primary-email authentication systems within Persona. One simple example of how this might work is MockMyID:
https://mockmyid.com/
Try logging into a Persona-enabled website with anything@mockmyid.com - you will be able to authenticate without entering any password or giving away any personal information. Of course, so can anyone else, but it might give you an idea of the possibilities in this space.
But what is being authenticated exactly in this case?
My understanding of Browser ID is that it's a way to provide an email address to a site operator that doesn't need to be confirmed. It's a single-step subscribe/account creation, rather than an authentication per se.
BrowserID provides a way to say to a site "I own this email address", as well as a protocol for the site to verify such an assertion. What the site chooses to do with the information is up to them. It can be used for account creation or signup, but works equally well for authentication to an existing account.
In the mockmyid case, you are saying "I own the address xyz@mockmyid.com". But the MockMyID server will happily let anyone make such an assertion, so you get a simple kind of mock identity.
Of course, you shouldn't use that as your identity on any sites that you care about. Mail to anything@mockmyid.com doesn't go anywhere, and there's nothing to prevent other people from using the same @mockmyid.com address. But it's a neat example of the sort of thing that is possible.
> My understanding of Browser ID is that it's a way to provide an email address to a site operator that doesn't need to be confirmed. It's a single-step subscribe/account creation, rather than an authentication per se.
That's mostly right. The BrowserID protocol gives you a way to say to a site "Hi, I'm someone@mockmyid.com, and here's the proof." That proof is, in part, a certificate that has been cryptographically signed by the user's email provider.
Now, to verify that, instead of asking the user for a password, or emailing them a confirmation link, you just have to check the cryptographic signature on the certificate. So in this case, you'd go request mockmyid.com's public key at https://mockmyid.com/.well-known/browserid, verify the signature, and if it all checks out, you can let the user into your site!
As for being a "single-step subscribe/account creation", you're spot on. Since there aren't any per-site passwords anymore, there's no difference in the flow for a returning user and a brand new user, since they both say "Hi, I'm name@example.com, and here's the proof." If that user exists in your database, great! log em' in. If not? Yay! You have a new user. Ask them for any additional information you might need.
BrowserID lets you use any number of email addresses and choose which one to use for a given site (though I think the current UI might get a bit cumbersome if you have dozens attached to one Persona account).
One of the reasons FB and Twitter OAuth became so popular is because they solved a problem for the user (remembering passwords) and also gave the site owner a big carrot (social growth mechanics, more user data).
This seems much more one sided -- it's good for the user that doesn't use FB or Twitter but 'meh' for the website. I'm not sure we'll see fast adoption like we have for OAuth.
One of the biggest wins for sites is that we reduce account creation / sign in friction for your users, so you get an awesome, easy flow through your funnel without having to give up ownership of your user data.
We also let you reach many, many more people, since you're not forcing users into joining an anointed social network. Everyone has an email address, and people understand what it means to reveal it.
Also, there's no lock-in, because we're not giving you an opaque, one-way identifier for your users. Instead, you always get a verified email address. Want to switch away from Persona? Add a 'password' column to your database and send a few emails.
Edit: I should also note that we're really, really easy to implement. Like, roll-your-own-integration in less than 3 hours with zero previous experience easy. I want to see us become the de facto auth solution for weekend projects, but we're also a really nice option to put alongside your social login. If you're already offering Twitter and Facebook, why not provide a vendor-neutral option, too?
Wait, it relies on email address? (quickly reads up on it.) ... and it doesn't have user identifiers other than the email address? That is not reasonable: normal
people (as in, people who don't know much about what they are doing with computers) tend to have piles and piles of email addresses, none of which hold any canonical weight to them: they have email addresses from ISPs, from schools, from work, and they often have multiple email addresses from sevices like Gmail. If they lose track of one they just get another one (as email addresses aren't even important anyway), and they never remember which one they've used with any given site. I've even seen people purposely get a new email address every now and then as their way of dealing with spam and "people I don't want to talk to anymore". They don't think far ahead, so the notion that their email address from school will be retired a year after they graduate and given to someone else doesn't occur to them (and seemingly didn't occur to you either, as it undermines the argument that it is a reasonable way to do password resets): email addresses are about the worst possible (while still plausible) "unique" identifier you could have come up with. :( (And yes: this is coming from someone who has had a single canonical email address for over 15 years: I also run a popular website frequented by tens of millions of users, many of whom are non-technical customers, and I have had to realize that they are nothing like me.)
Here's what would be great for users, being able to sign in with _any_ of their email addresses and passwords. If you could register all of your email addresses and passwords then login would become as easy as entering the first set of details you think of.
That's an interesting idea. How would you go about collecting all these emails first though?
Would you tell the user to "just enter all email addresses you ever registered" and then send confirmation emails to all of them? I'd imagine this ending with one or two confirmed email addresses and maybe 3 additional unconfirmed ones.
When the user then tries to use one of the unconfirmed addresses to sign in — what do you do? Refuse log in because the address is not confirmed? Send another confirmation email to that account and ask the user to confirm it? List those confirmed addresses in the account and ask the user if he wants to sign in with one of them?
No need to send confirmation emails. Let him login with any email address. If the authentication is successful, you let him in. At this stage, it is a new account so give him an option to link this new account with his existing account with your service. If he had already provided all his email addresses with the first account, there is no need to authenticate one more time. Otherwise, simply authenticate once more with the original email and link the accounts if successful.
without trying to add more complexity into the system, it would be nice if multiple accounts per email were possible. why not just link them together so any will work in place of another? not sure how you'd help someone find their account if they don't remember the email though.
"we're really, really easy to implement"
"I want to see us become the de facto auth solution"
"We also let you reach many, many more people"
"but we're also a really nice option to put alongside your social login"
Assuming by "we" and "us" you mean Mozilla? Or do you also mean the other major browsers?
Why did you write it like that? Why not just say "Persona" instead of "we" and "us"? Surely Persona is much bigger than Mozilla or do you not think so?
Firstly, that kind of language does not inspire trust. It sounds very much "us" vs "them", instead of addressing the real problem, which is helping users by creating and managing more secure passwords.
Secondly, your marketing to users includes:
"Many sign-in systems carry your profile data with them; some even share that info with other sites and social networks. We believe you should control how your personal information is shared."
You seem to want to attract publishers and yet you show your distrust of them to users.
Also, from experience in Public Web Apps, and the fact that it's still not possible for a user to give raw and pure TCP, UDP or POSIX power to Web Apps (and WebSockets and IndexedDB are not at all the same), I don't think the issue is so much that the user has power, as it is that the browser should have power. As it is today, the user is given very little power at all by the browser. Very little trust. Most spec discussions seem to constantly worry about users shooting themselves in the foot, and are prepared to stop at that, rather than finding ways to empower users to give power to web apps.
I work for Mozilla on the Persona team, so it feels natural to say "we" to refer to us and the specific implementation we've built, but I see your point as to the feel of that language. Thanks for calling me out. Persona certainly has a scope beyond Mozilla, and its current state owes much to open collaboration.
Well done on your efforts and may Mozilla continue to develop into a force for good.
At the moment, however, and Persona is a good example of this, the browser approach to innovation is very much top-down with high-level APIs like UndoManager, WebRTC, IndexedDB rather than bottom-up with low-level APIs like UDP, TCP and POSIX which would trust the developer community to do the rest. Browsers are just not very programmable when compared to platforms like mobile and native.
For example, if the user would be allowed by the browser to empower a web app with raw POSIX, then that would unleash an explosion of databases running in the browser, orders of magnitude better and faster than IndexedDB.
Sadly, this kind of innovation is currently locked up tight inside the various spec committees. For sure, developers can contribute to the mailing lists, but innovation should not be made to go through that kind of process at all in the first place. Innovation on the web needs to be decentralized not centralized. Ideally, Mozilla needs to start making that possible, by providing just the right OS-level APIs and a simple way for users to grant these to Web Apps.
It must be 1984 that one can use a browser, but not be allowed to give raw TCP or UDP or POSIX annointing to web apps that one trusts.
That's the plan. Mozilla are just waiting on Gmail to cooperate and implement Persona on their side.
In an ideal situation, both your browser (eg: Firefox) and your email provider (eg: Gmail) would support Persona. In that case, you don't have to click on any links to prove your email address, you don't have to create a new password, you don't have to trust Mozilla's servers to store a hashed version of your password correctly. The log-in dialog itself with be part of the browser chrome, training users to trust the browser and not the website, which is a good thing.
If your browser or your email provider don't support Persona, then Mozilla have provided fallbacks, which require you to click a link in an email and to create a new Persona-specific password.
In the case of gmail, they're note even waiting. There is active development on a gmail-to-persona proxy so that you can authenticate with just your gmail password:
I've been using BrowserID/Persona on my sites and I love it. For an example, go to http://www.yourpane.com and click "BrowserID" (never mind the other fields).
It always takes me 5 minutes to integrate, doesn't require me to write any sort of "forgot password" functionality, doesn't require me to worry about storing passwords, and it's generally very easy to work with.
One problem is that users don't know if they're supposed to sign up or sign in, and that a Persona works for other sites, but I think this can be ameliorated with good copy.
That provided a pretty confusing journey. First attempt: I clicked the Browser ID button, entered my email address on Persona, got redirected back to your site with no messaging. Tried again, it asked me to give a password this time. Did so, but then didn't redirect me back to your site. I then had to manually go back to your site and hit the BrowserID button for a 3rd time, which then took me to a Persona page to log into your site.
That's odd... The first time, you probably needed to verify your email, and I'm using the old API, so it doesn't sign you in right away. The second time, I don't know why it didn't log you in, I'll have to look into it...
I'm not sure it's your issue, it seemed more like it was problem at the Persona end. Unless of course Persona was sending useful messages back to your site but your end wasn't handling them.
I'm not sure it's my issue either, the whole thing is pretty much plug and play using their library... It's rather old, however, there might be something they've fixed. I'll have a look and see if I can upgrade it.
I have to say (and this is Persona in general, not your site) the password dialogue freaks me out. I click BrowserID on your site, it opens a popup and it asks me to enter my email address, I enter one of them, and then it suddenly expects me to enter a password. Which password? My email password? On a site that isn't my email provider? Or another password? Or an existing password? Or... huh?
I think Persona really needs to sort that out, it's completely non obvious.
Many websites just want an identifier, without having to torture the user by asking them to give a password. Facebook and twitter are not a good option for that. I don't want to know my users' facebook details and certainly don't want them to think i'm one of those crappy apps that post on their wall. Twitter is down more often than not as i 've noticed, and again, i dont want users to be uncomfortable about sharing their identity with my website.
Plus, twitter and facebook won't be here forever and may be a fad. Imagine if people used their myspace handle to login to their bank account today. And facebook accounts get disabled/hacked much more often than, say, gmail. E-mail is much more signup-and-forget and nobody considers giving their email address a privacy violation.
I see lots of complaints here about the technical aspects of browserid, yet i believe it's the most pragmatic approach one can take to rid the web from the dreaded password plague.
I've wondered about "data-renting" setups before. For example, rather than giving a company my postal address, give them a token they can send to, and a post fulfilment company delivers to the actual address. If the address moves, the token follows. If I decided to revoke the token, they can't send me mail.
Can't do that with all digital data, but you could with e.g. email addresses, cc's, addresses, maybe phone numbers.
That's been possible with email addresses for decades. "Free email forwarding" returns plenty of services which give you an address that forwards to your own, and which you can revoke at any time. Personally, I just use a catch-all on my domain, but that requires you to have one.
Same with credit cards: my bank offers a free service where I can set up as many virtual CCs as I want. Until recently they were single payment only, but now you can choose if it's single or multiple.
Forwarding (physical) address exist too, 'though they seem to be mainly targeted at people outside the US who want a address there, and they cost you an extra shipping fee, of course.
I read a comment that the email provider can allow anyone to log into your accounts because they can sign any public key they want to say it's valid. This seems to be true from my 10 minutes reading the spec.
I know a password reset function that uses only email is basically the same level of trust in the email provider, and I'm no fan of email based password reset, but this feels even worse -- literally abdicating your security entirely into your email providers hands? Gmail is great because it's free, but I didn't join gmail with the idea of giving them the keys to my life.
Another thing I don't fully grok yet is the 'issued-by' concept. Does this mean that 'Relying Parties' need to whitelist all the secondaries they are willing to trust? How can that possibly fly?
Finally, in a native implementation, how is the keyring persisted on disk kept safe from malware extracting your private keys? If the browser can decrypt the keyring, so can malware.
Ok I lied, one more thing... Is there a password prompt when you first sit down at the native BrowserID implementation? Or does it just assume that your browser means its you sitting there?! Then of course the next question is, how do you tell your browser you are walking away (akin to logout) and is it going to expire all sessions that were tied to your identity when that happens? So much to worry about...
> I didn't join gmail with the idea of giving them the keys to my life.
Nor did I, but as you acknowledged, that sort of control has entered the status quo. Anyone who can break into your email account can trivially reset your password on many sites, at which point, per-site passwords just become another liability. We get rid of those, and empower you to independently decide who to trust with your identity.
> Does this mean that 'Relying Parties' need to whitelist all the secondaries they are willing to trust? How can that possibly fly?
The idea of a secondary (or fallback) isn't central to the BrowserID protocol; it's just a convenience so that we can actually bootstrap a fully decentralized system. In practice, all libraries trust Mozilla's fallback Identity Provider by default. As email providers add native support for the BrowserID protocol less and less traffic passes through our fallback until it simply and automatically drops out of existence.
> If the browser can decrypt the keyring, so can malware.
Yep, that's true. Same with your password manager, though we are trying to mitigate this by making the certificate itself relatively short-lived. To wit, each client has its own ephemeral keypair with certificates that expire regularly, requiring a silent renewal with the Identity Provider. This creates an opportunity for the Identity Provider to refuse to renew a certificate, should one of your machines become compromised.
> Is there a password prompt when you first sit down at the native BrowserID implementation? Or does it just assume that your browser means its you sitting there?!
If you have a valid, unexpired certificate available, you'll be able to log in to things straight away. If not, you'll need to authenticate with your identity provider to get a fresh cert. Native clients are, of course, free to implement additional security measures before allowing access to the keystore.
At least in the case of password resets, it's the site deciding they want "email" to be the weakest link, and many sites will require at least a little bit more (like secret questions) after a reset. In this scheme, email is by definition the weakest link.
The secondaries can never go away, unless sites are willing to straight up refuse customers based on their email address. There is an extremely long tail of corporate email servers out there, and those corporate employees are our users. I guess we just gracefully degrade back to standard usernames and passwords?
So the certa expire AND the key-pair is ephemeral, so if the user doesn't stay logged into their email account, they are going to get login prompts every 6 hours. If you use multiple emails, that means constantly cycling through your various gmail accounts every time the certs expire.
I think you need to allow flushing the key pair manually or else you're saying there really is no way to "Log out" with this. Worse, a user will click 'Log out' on their site, but the cert is still active so anyone can walk up / pick up the device and log right back in. So what we've been taught "make sure you log out and then quit the browser" wouldn't actually apply anymore.
Last thing for the night... If a site falls victim to a XSS vulnerability, does this mean an attacker can call id.get() and steal a users assertion, send it to themselves, and login as a user of my site by replaying the assertion? This is like stepping back to IE5 where cookies couldn't be HttpOnly!
Oh, sorry, there absolutely are prominent ways to log out / flush the keypair manually. It's after 02:00 local, so I need to get some sleep :).
As to XSS, the assertion that's transmitted to a site is scoped to that specific site, and is only valid for, iirc, 2 minutes. So replay attacks are severely constrained. Plus, the only meaningful data they contain is the user's email address, so phishing doesn't get you much of value or put the user at risk.
So that's a 'yes' this exposes authentication to XSS, albeit the attacker will have to hijack sessions in real-time as the assertions are forwarded to their server.
That's a huge step backwards in web security. Why pass the assertion to the RP via the most insecure channel possible, i.e. the client-side javascript? That was just the easiest way you could find so the RP could tie it to client's session id?!
Obviously the assertion must be sent from the browser plugin directly to the RP. You could do it by injecting an HttpOnly cookie for the RP's domain with the encoded assertion. Javascript can never see it.
In the case of a secondary, the secondary already has an HttpOnly session id with the end user, since they're authenticated in the first place. The secondary would post the assertion back to the RP directly at a well known URL, and the RP returns a URL to the secondary with a nonce built in. The secondary redirects the end-user to that nonce URL so the RP can give them an HttpOnly authenticated session id. I think you can do this in a way such that neither the assertion nor the nonce will be visible to client javascript.
Saying, 'oh your account can only be logged into by attackers for 2 minutes if they can XSS the RP' is beyond disappointing, it's borderline negligent.
For most people, it goes like this: click on the Facebook login button, done. OR, click on personaID, have a new window open, enter email, enter password, go through setup, get back to site. This will be hard for most web users to adopt.
For other people it goes 'click the Facebook login button' - What? This POS uses Facebook? What access does it get to my Facebook account? Is it one of those weird things that posts all over my Facebook wall? [cancel]
Generally I've noticed people are fine with FB login as long as you add "Don't worry we won't spam your friends without your permission" or "We won't spam your feed, we just want to know it's you." or something like that
Yeah but once the registration hurdle is jumped, it's click, password, go. Some of us do prefer passwords and multiple identities in this age of homogenized identity.
That's not entirely fair. If you're not logged into Facebook, you still have to log in there as well. As huragok said, once you're past set up, it is just click, password, and go as far as I can tell.
However, I'm not arguing against that a lot of people probably _are_ already logged into Facebook.
Mozilla Persona (AKA BrowserID) is exciting stuff. However, it doesn't seem to have changed much since the last time it hit Hacker News [0].
There are websites that have chosen Persona as an authentication method. We now need to see the following two pieces implemented:
- It needs to be implemented in the browser's GUI, like in this old screenshot [1]. People will be able to see the usability and security benefits of having a standardised way to log in that's built-in into the browser. Could we at least have a Firefox extension or a nightly build of Firefox that does this?
- At least one email provider needs to be a Persona "ID provider", which would eliminate the need to create a Persona password and to click on a link in an email. My guess is that getting Gmail to support this would be slow work, why not try persuading smaller email providers like Fastmail to be the first to openly support Persona?
Fortunately, Persona does work even without these two pieces, using fall-back servers and a shim. But most of the benefits of Persona are only valid once the browser and the email provider deliberately support it.
Much has changed, but we haven't written about it yet. We're working on it. This post to HN caught me by surprise. The new design went live, but we weren't planning on announcing things until early next month. Trying to stabilize and polish the new APIs, etc.
Native support should be coming in Firefox 17, albeit off-by-default. Native support will be enabled on phones running Boot2Gecko, which ship in Q1 next year.
The other personas (aka "lightweight themes") are supposedly being re-branded (thought I don't remember what they're calling them). It apparently hasn't happened yet, which will surely lead to some trouble.
This comment sounds so innocent but it really started me thinking. When should one call things simply by their name and when should one create a new name?
Would Twitter be the same if it was for short text messages? Or are Tweets so different that they deserve their own name?
Technically, this will work with chrome as-is, it just won't have a slick native interface. The basics are already implemented by Mozilla as a HTML/js library you can use on any browser.
As an email provider for multiple domains, I have a hard time seeing what this actually has to do with current email infrastructure. It seems the only time the email address is used is to support a fallback notification, in which case many of the claimed benefits of BrowserID are lost (as you've fallen back to a single centralized identity provider).
Correct me if I'm wrong, but BrowserID/Persona assumes that for a user@example.org identifier there is a corresponding https://example.org. That's not true for most of the domains I support. In many cases, example.org doesn't even resolve to to an IP address and web servers are only run on subdomains (and not all subdomains have HTTP servers). Does BrowserID/Persona support a DNS mechanism to discover the location of the required HTTPS web server, similar to an MX record?
The opposite problem is where a user has a single email account with multiple valid addresses at multiple domains, such as user@example.org, user@foo.example.org, user@bar.example.org, etc. I work for an organization approaching a million users where this is the case and isn't going to change anytime soon. Once again, you can't assume there is an identity provider running on a web server at all of these domains. Is there a DNS-based method of discovery to solve this problem?
Does BrowserID/Persona allow users to authenticate against the same system they use when accessing email? If so, why does the OpenPhoto example ask for a password? I thought the whole point was that users avoid sharing credentials with sites. That implementation is very confusing and looks like a scary phishing attack.
Finally, it's not very clear what I should expect in the way of connections from other computers, whether I'm running an identity provider or not. This is crucial information to avoid tripping an intrusion detection system (IDS) during unexpected connections, especially from my own users.
I tried the OpenPhoto example. One thing that introduces friction compared to username-password: The first time, I have to create a Persona account. Unfortunatelly, I'm not logged in afterwards.
Most sites nowadays log you in right after account creation and just wait for email-verification later. Is that even possible with Persona?
Yeah, that totally sucks, and we're working on it.
OpenPhoto is still using our old API, which can't handle post-verification redirects. Our new API does this automatically. Grab a mailinator account and try signing in to http://123done.org.
As for creating a Persona account, we're trying to fix that, too. Next month we'll be turning on a feature (codenamed "bigtent") that verifies Gmail, Hotmail, and Yahoo users by sending them through their respective provider's OpenID or Oauth endpoints. No more new account creation. No more email verification loop. Just three clicks and you're done.
The webpage should suggest a website other than OpenPhoto, then. First impressions count. (I say this as someone who's really excited by Persona and who wants it to spread as quickly as possible.)
One good reason: If Facebook goes broke, or decides to stop offering their authentication service, or anything like that, your user database is now filled with useless Facebook user IDs. If Mozilla's Persona system goes broke or gets taken offline, your user database is now filled with perfectly good, validated email addresses, so you can still contact your users and/or match up new registrations with existing accounts.
IIRC email is one of the few pieces of information about users that you get by default, and cannot be revoked by the user (without revoking the app entirely)
I have a facebook account, but I don't trust them enough to allow them to know anything about me except what I intentionally put on facebook. Thus, I don't use products that require me to authenticate with facebook. I will, however, authenticate with Google or a password. And, I would use Persona.
I'm simply not trusting facebook under any circumstances. I'm in the minority, I know. But, if you want my money, or my time, on your web app (and maybe you don't; maybe you want people who have low desire for privacy or security, since they're probably more likely to click on ads), you're gonna have to offer something other than facebook for logging in.
I don't think "I don't like Facebook" is limited to dev-centric populations. I know people who have nothing to do with software development who refuse to get Facebook accounts. And then there are the folks who use Facebook but refuse the install any apps (about half of my Facebook friends fall into this category). You need to offer something other than Facebook auth if you care about having the broadest reach possible. This Mozilla persona thing has a pretty intuitive workflow for signing up with any email address.
Exactly. Facebook isn't universally trusted and liked even by Facebook users, especially across external functions such as commenting on websites. Outside of Facebook, people often avoid signing in to post comments on websites.
Often the comments we want to write on websites have absolutely no business being concurrently posted back to FB. People like contributing without disclosing or offering their FB identities or sharing every micro-activity. And fair enough.
Not everyone is comfortable with fronting up to an unfamiliar website and saying "hi, I'm John Smith. Here's my comment about religious persecution in South Asia. And don't forget to Like me on Facebook. Sign up now to connect and share with the people in you life"...
In other words, the less clunky FB social plugin mess on websites the better. I hope Persona goes well.
> Honest question: As an app builder, why would you use this instead of facebook?
You should use both, to maximize the convenience of your users.
Some are always signed into Facebook, and like to just use that, others want other methods that offer different models of security and openness, Persona is the best of those I would argue (OpenID is nice too, but the lack of native browser integration is what makes it less impressive than Persona).
I can see a website offering only Persona/BrowserId, as it doesn't force you to create an account with a "commercial" website. If you go with Facebook for login, you have to offer an alternative because if a user doesn't have a fb account, it has way more implications to open a fb account than to create a browserid account. I just hope Mozilla don't overgrow it into something more than a simple auth system (like building a social network around it!).
well, my first guess is more people have web browsers than have a facebook account. if this can be standardized and propagated throughout all major clients, the user base would be much larger.
Exactly, and I think it's possible that Mozilla just doesn't understand this. Webapps aren't attracted to identity providers because they want to avoid managing a user table in their database, but because existing identity providers like Facebook provide a set of "social" APIs that can support the webapp. I can't see why a site would be drawn to BrowserID instead.
> I can't see why a site would be drawn to BrowserID instead.
There's more to Persona than liberating you from your password column.
Nevertheless, there are still huge classes of applications that don't benefit from social features, but do want the improved experience that Persona can offer. Think banks, universities, corporations, and governments.
So even in the absolute worst case versus Facebook Connect, we still have enormous potential for alleviating the pain of per-site passwords and containing the damage from security breaches in day to day life.
I've been sitting around thinking about implementing a user system on my current (and first) website to try and keep people returning to the site to see people responding to their stories etc.
Now I'm wondering whether to use Persona or build it myself from scratch.
First reaction: the bland beige looks terrible (maybe that's because I'm not American; I always notice that 1/2 of everything is beige when I'm in the US). Combine that with the name and I'm reminded of the Persona contraceptive device.
One thing that I don't get about BrowserID is how it's supposed to work on shared systems / web cafes. There doesn't seem to be any obvious way to log out. The best you can do is 'log me out after an hour', which is crap.
What about native mobile apps? Is it possible to easily use Browser ID for native iOS and Android apps? Or is it just too much of a hassle getting the information out of the web view?
I really, really need to post something like this on our blog soon. Watch http://identity.mozilla.com/ for something more polished next week or so. I'd also strongly urge you to just try implementing it on a site. It'll literally take less than 30 lines each of javascript on the frontend and python on the backend, and it'll really demystify the flow between the site and the user.
As an analogy, we work really similarlu to showing a bouncer your ID. The ID has identifying information on it, and it has features that allow you to know that it's authentic and hasn't been tampered with. The bouncer can learn how to validate IDs issued by many different authorities, and can remember this when he sees other IDs from that same authority.
Our IDs are personal public/private keypairs, signed by the email provider.
So, quick and dirty, here's how we work:
I want to log in to 123done.org as foobar@eyedee.me, but to do that, I need an ID with eyedee.me's digital signature on it. So in a popup, my browser sends me over to eyedee.me to ask for that signature.
Before eyedee.me will sign a public key with my name on it, I have to prove that I really am who I say I am. It's just between the two of us, so I can prove my identity however eyedee.me wants. It could be a password, an RSA keyfob, or entering a code from a text message. Whatever it is, eyedee.me is happy that I am who I say I am, and they sign my key and hand it back.
I want to show this to 123done.org, but it's not enough for it to be valid, since we have to prevent malicious websites or phishers from copying it and masquerading as other people. For my ID to be a valid login token, I have to add two more things: what site I'm logging in to, and a timestamp so it expires soon after I hand it over. I then sign that with my private key.
I then take that whole bundle and hand it off to 123done.org.
123done verifies it by asking for eyedee.me's public key (which can be cached), and seeing if that matches the first signature on the ID. If it does, then 123done pulls out the validly signed public key, and checks if it matches the second signature on the ID. If that matches, then the whole package is valid, and 123done knows that I really am foobar@eyedee.me.
Does that make sense? It really just revolves around a document with two signatures: An email provider's which says "This key is associated with this account," and a user's which says "I am associated with that key."
So in your example, eyedee.me is your email provider, right?
I made a Persona account just now. All I saw happening was that I clicked on a link in a confirmation email. Was there also communication between mozilla and my email provider? (I am with a small ISP who is serving my emails - I have my own domain, so my email address is sthg like me@myname.com). What went on behind the curtains, if anything, and why did it work with my small provider right away?
I appreciate that you've set up real domains for demonstration purposes, but wouldn't it be better to transfer ownership to Mozilla so they show up in the whois record? I don't mean to nitpick, but details matter when trying to promote such a sensitive protocol. There's no way I'm going to try out an authentication demo at a random privately owned domain.
For me, the big question was about whether email providers supported key signing without having to click on an email. Now I see that both ways work the same.
Do you have any links to specifications on it? I'm very interested on identity federation. But the post doesn't give away much info on persona's capabilities.
Mozilla has tons of stuff in production running Persona, so we're totally dogfooding with Bugzilla, Mozpad, MDN, Add-ons Builder, Firefox Affiliates, Firefox Flicks, Mozilla Marketplace, and Mozillians.
Voo.st, OpenPhoto.me, Crossword.TheTimes.co.uk, 5apps.com, Haskellers.com, etc. We're also working to get Persona working with some larger sites, but most of those are waiting to go live until after we formally announce API stability next month.
Try these links, which go into much more detail, answering the "why bother" questions.
https://developer.mozilla.org/en/BrowserID/Why_BrowserID
http://identity.mozilla.com/post/7899984443/privacy-and-brow...
http://lloyd.io/how-browserid-works
Note that BrowserID was the old working name for the project.