6 ms·

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 wit

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?

saurik 14y ago
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.)
- geon 14y ago
  Not to mention that email is really unsecure. A password reset link will be sent as plaintext. Is there at least a way to change the email addredd associated with an account? I can't see anything about that.
  - callahad 14y ago
    What password reset link? :) If you're using an email provider with native support for Persona, the only password you have is with your email provider.
    - geon 14y ago
      Ah. I hadn't realized it's using the mail server. http://lloyd.io/how-browserid-works http://lloyd.io/how-browserid-works
- etherealG 14y ago
  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.
- ollysb 14y ago
  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.
  - ciex 14y ago
    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?
jorangreef 14y ago
"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.
- callahad 14y ago
  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.
  - jorangreef 14y ago
    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. See Tim Berners-Lee on the subject: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...
StavrosK 14y ago
I've been using BrowserID/Persona on my sites and I love it. For an example, go to http://www.yourpane.com 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.
- drcongo 14y ago
  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.
  - StavrosK 14y ago
    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...
    - drcongo 14y ago
      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.
      - StavrosK 14y ago
        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.

saurik 14y ago

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

geon 14y ago
Not to mention that email is really unsecure. A password reset link will be sent as plaintext. Is there at least a way to change the email addredd associated with an account? I can't see anything about that.
- callahad 14y ago
  What password reset link? :) If you're using an email provider with native support for Persona, the only password you have is with your email provider.
  - geon 14y ago
    Ah. I hadn't realized it's using the mail server. http://lloyd.io/how-browserid-works http://lloyd.io/how-browserid-works
etherealG 14y ago
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.
ollysb 14y ago
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.
- ciex 14y ago
  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?

jorangreef 14y ago

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

callahad 14y ago
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.
- jorangreef 14y ago
  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. See Tim Berners-Lee on the subject: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...

StavrosK 14y ago

I've been using BrowserID/Persona on my sites and I love it. For an example, go to http://www.yourpane.com 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.

drcongo 14y ago
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.
- StavrosK 14y ago
  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...
  - drcongo 14y ago
    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.
    - StavrosK 14y ago
      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.