I would much rather make a new account with my e-mail than have anything linked to my Google/Facebook account. I'm really uncomfortable exposing other sites to that information.
Indeed. The article doesn't make the context clear up front (perhaps because it's on a blog and partly aimed at people who already know what the blog is about), but the author and Mozilla have a solution to that problem that isn't "social". The post mentions it toward the end:
"We built the Persona protocol to reduce data sharing to the minimum needed for the user to easily log in: the browser mediates the login without leaking data to the identity provider. In the end, Persona is the easy login solution that respects users."
Ben is a smart guy, I've read about Persona, and it seems to be really well thought out and to have learned from the failings of e.g. OpenID. I intend to use it the next time I need an easy login solution for users.
I don't like social login because I'm not on any social networks. It could be a great service, but as soon as I see that it's Facebook/Twitter/G+ only, I'm out.
That's what I like with Persona, since I've made my personal domain a Identity Provider. I just log on and click okay to authenticate.
Not tied into Google/Yahoo/Facebook/MyLittlePonySocial - but not having to create a new account. Oh, and I own the data (Not the AppData of course though).
While I'd like to agree, I'd also like to see something beyond anecdotal evidence on this. It'd give me a great excuse next time someone wants a Facebook login and a Twitter login and a Pinterest login [sic] on the same site.
100% agreed -- anecdotal blog posts should not be up-voted to oblivion simply because the community at HN agrees with them. (Though I find it ironic that such a technical community doesn't consider lack of data in arguments like these an issue.)
In case you're not familiar with them, this blog comes from the Mozilla Identity team, which is creating a unified login product called "Persona." It's basically the features of social login (you don't have to create a new account for every site) without the drawbacks (an advertising-driven company knowing your every login).
I use Persona on my costs-real-money subscription site[1] and I'm very happy with it. Integration was easy, the user experience is pretty good, and it's been stable and reliable. The best thing, of course, was not having to implement my own password-management infrastructure, which saved me a ton of time, as well as insulating me from the hard security problems that come along with such a beast.
If you decide to try Persona, I heartily recommend it. There are a couple of gotchas to be aware of:
1- On iOS, only Safari works due to Persona using a pop-up window for login. People using Chrome on iOS will get a confusing "relay frame not found" error.
2- Signup flow could be better. When users create an account, they get a confirmation email. Clicking the link in that confirmation email redirects them to the Persona site, not back to your site. It's possible this is configurable and I haven't figured it out yet.
3- Persona emails are case-sensitive. There's some rare issues that occur as a result. At one point, it could crash the login, but I believe that's been fixed.
Don't let these flaws stop you, though--Persona is very well done and constantly getting better. I've had hundreds of people sign up for paid accounts and only two have had trouble to the point of asking for help. (And nobody's cancelled their subscription because of login problems. :-) )
> returnTo: Absolute path to send new users to after they've completed email verification for the first time. The path must begin with '/'. This parameter only affects users who are certified by Mozilla's fallback Identity Provider.
shouldnt be too bad, because the button they click to login says "Persona," as does the email. I guess if a person is already familiar with logging via fb/google/twitter, then they should "get it." but someone not familiar with logging to site A using credentials from site B.... yea i can see that being confusing.
Upgrade to the Observer API (`.watch` and `.request`) and your users will automatically get a super smooth post-verification experience, just like you described.
I like it a lot, but at the end of the day I'm still relying on a single company to hold the keys to many accounts of mine on the web, which is still a bit jarring (not that it's going to stop me).
> at the end of the day I'm still relying on a single company to hold the keys to many accounts
Actually, with Persona, you're not. :)
Persona has a fully decentralized architecture. The centralization you're seeing right now is completely temporary, and only serves as a bootstrapping convenience. If you own your own domain you can turn it into a Persona Identity Provider and start minting your own identity certificates today, without Mozilla (or any other single company) being forced into the trust path.
We're going to build a Persona <-> Gmail OpenID bridge soon. Probably launching in May or June. It'll almost be like Google supports it directly. :) After that will come Google Apps support.
I'll submit a feature request to Spotify to get them to support Persona log in. When Gmail and Spotify are gone I'll be two big steps closer to getting rid of that pesky Facebook account ;)
We wouldn't even have to turn it off -- as soon as gmail.com can vouch for its own users, the protocol automatically and preferentially switches over to that. The centralized parts fall away on their own whenever they can. :)
Actually, it won't. You'll OpenID auth into google.login.persona.org, and then get a straight up Persona certificate signed by that fallback, along with all of the privacy safeguards that has.
Honestly, we haven't quite figured out a good way to do a "beta" or partial roll-out for this without breaking other users. Yaaaay decentralization! Instead, we'll be extensively QA'ing it in testing environments, and then we'll flip a big switch to enable it for everyone.
I'm interested to know how Persona works server-side? AFAIK, it's entirely done in JavaScript. I can't imagine sending the browser ID over Ajax to make a session, it seems far too easy to exploit.
In short: it's bog standard public key cryptography. My browser has a keypair and my email provider has a keypair. My public key and email address are bound together and signed by my email provider's private key. When I want to log into a site, I pass along that certificate. I also pass along a document containing where I want to log in and and the current time, signed by my browser's private key.
The latter document ties a given login request to a specific keypair.
The former document ties a given keypair to an email address.
Together, they identify me and prove that the person logging in really is the same person that was authenticated by the email provider.
Thanks for the suggestion. I'll keep tweaking it. I'm seeing fewer (actually, none) bounces off the payment page than before, which suggests that the change I made has already helped.
I'm limited by a serious lack of graphic design skill, and this page wasn't part of Primate's original design work for the site. It shows. :-) It will get a proper design at some point in the future.
Don't let these flaws stop you, though--Persona is very well done and constantly getting better. I've had hundreds of people sign up for paid accounts and only two have had trouble to the point of asking for help. (And nobody's cancelled their subscription because of login problems. :-) )
Just as a point of info "only two have had trouble to the point of asking for help" is a really bad way of judging whether something is working well or not for your customers.
The vast majority of people do not complain if they hit problems. They just silently go away. From my experiences of optimising this sort of stuff I'd pretty much guarantee that you have at least 10x times than number failing and walking. Possibly much higher.
Not in this case. The signup flow for my site is "decide to subscribe, put in email address, put in credit card, create Persona account."
By the time they get to the "create Persona account" part, they're already invested in it working.
I also monitor my logs for signs of trouble. One of the two issues I was talking about above was actually initiated by me reaching out to the subscriber. (I happened to see them bouncing on the "now log in" page within a few minutes of their subscribing.)
And I also ask people who cancel why they did so. The vast majority respond, and none have said "I couldn't log in." :-)
It's quite possible there are still some angry silent unsubscribers who were stymied by Persona, but at this point I'm satisfied that it's not a significant number.
"not having to implement my own password-management infrastructure, ..., as well as insulating me from the hard security problems that come along with such a beast."
But you do realize it does definitely create another, much more serious, security problems right? What happens when the single sign-on server gets compromised? What happens when tokens aren't as secure as they should (like the recent OAuth SNAFUs, with an 's')? What happens when you don't pay attention to all the fineprints in the Persona docs stating things like:
"Be careful if you don't do this it's going to be easy to forge"
and:
"Guidelines to use Persona securely"
?
So it can be used not securely? Like OAuth? Do you think I find it re-assuring that I have to take steps so that things are not easy to forge? What when the latest JavaScript / browser exploits manages to forge requests?
Don't get me wrong: this seems very convenient. But you're trading time for something here. It saves you time by now having to roll your own security correctly (a DB into which you put emails and bcrypt encrypted passwords) but it comes at a price.
The price is the added insecurity that single sign-on adds.
Authentication requires attention to security no matter how do it. There's no silver bullet.
As far as I can tell, using Persona requires less attention to security than doing it myself. I don't see how that translates to creating "much more serious" security problems.
Perhaps you are a security expert who can do a better job than a team of Mozilla developers who are dedicating themselves full-time to solving authentication problems. I'm not. I know enough to know that security is harder than it looks, and that even if I salt my fries and crypt my bees, I can still screw things up[1]. Better to outsource it... well, as much as I can, anyway.
I learned today that StackOverflow (and company) have responsive support persons who respond via e-mail, that will help you recover and merge your cookie-based StackExchange accounts if you've lost access and there is sufficient evidence that they belong to you. (I thought I had registered the account under the myid.net provider (who is now defunct?) but no.)
That has to cost a lot of money. With the dozens of ways you can authenticate with StackExchange, I don't know why I was surprised to learn I had previously created an account without actually creating an account, but it was so.
Also, anyone who reads Korean can tell me if this says "sorry we're closed"?
What is infuriating about the stackoverflow sites is that they treat each site separately so you end up with multiple logins across the "network" that you really don't care about. Then they do that annoying thing where they display the page, then detect you are "logged in", and then tell you to refresh.
That site is very good at Q&A, but UX wise it's terrible. It's as if they've only ever tested it with their own devs, and never done any real hallway or external usability testing.
I've tried to participate in their "meta" site, but the pedantic and condescending tone there is even worse than it is on the main sites.
Furthermore, Atwood seems to take the success of the platform as a ringing endorsement of all its characteristics, as evidenced by the recent commentary on user experience and the development of his forum.
Bob Martin's recent "And I'm very sorry that when you finally brute-force your way to some modicum of success that you will credit your bad behavior, and recommend it to others" has sprung unbidden into my mind once again ...
This seems likely. Still, with a bit of planning they could have gotten around this. Everything dealing with identity could have been served from a single domain. There probably would still have been issues, but they would have been resolvable.
Yes! I hate it when I have to register for a service, wait for the email activation link only to find out that I that the service isn't for me. Then I have to delete the account and wait for emails to come to unsubscribe to those.
Even worse is that many times you can't delete your account, or if you can, it's just a soft-delete -- and now that site has your email address (at a minimum), and sometimes may have much more information about you.
Call me paranoid, but I think "deleting" your account has the potential to actually do more harm than good, since in doing so you are voiding any agreements or terms that you had previously agreed to, including those that promise not to sell or otherwise abuse your info.
I use mailinator for pretty much every site that wants an email address. Pick an obscure enough address and your risks are minimized to practically nothing but you get all the convenience of "deleting" your account simply by never thinking about it again.
I have a domain with a catch-all address, and so I just makeup addresses to use on the spot, but I know people like me and you are in the vast minority; none of my non-tech friends and family would ever do this. Also, sites like mailinator are often banned from sign-ups.
I know this will not work everywhere (not everyone implements correctly the RFC's regarding e-mail) but if you have an address, you can make up addresses on the spot by using the + notation
eg messages to myrealemail+mytag@gmail.com will always be received by myrealemail@gmail.com
I too have a domain with catch-all, and I do that rather than using the + notation, but it's something you can teach your friends who would never do that.
Yeah, I'm counting on e-mailers to send mail to the address I give them. No, I don't expect folks to send me spam unsolicited, or sell my address when I give it to them. I don't consider my name or e-mail address to be secret, and I'm also counting on anyone who sells my contact info to be doing it in bulk, not paying enough attention to strip out +tags, and by passing the address to spammers unaltered (or losing control of their database), give themselves away when I start receiving spam at that address.
Honestly I don't use the feature very often and I had not considered it to be a security measure before. Maybe novelty is the right word.
If I give myaddress+dropbox@mydomain.com to Dropbox, and they mail me from different addresses, I would be able to catch them all and put the "Dropbox" tag on them all, rather than having to make a filter for *@dropbox.com or some other extraordinary measure for classifying their mail.
It's part of the RFC, and supported by every mailer that I know. What part of this technique seems like obfuscation?
I guess that's the disconnect, because I do consider my email address secret -- since it is 1/2 of the information required to access my Google account, I take great measures to make sure that outside parties never see it (as best I can). If I can prevent any site from ever knowing that address, then my chances of being targeted (phishing, brute-force, whatever) are drastically reduced.
So, if you only use +tag for your own personal organizational purposes, then have at it! But if your goal is to conceal your account ID with Google in the interest of personal security, then you really need a better angle.
I actually have a domain like that too. I just like mailinator because I know I'm never going to want their email so I don't even have to put in a rule to block out.
On a related note, some spammers have really done a number on me. First they impersonated thousands of addresses at my domain in the form of xxxxxx@mydomain.com where x is a hex digit. This is despite me having DomainKeys and SPF enabled. So not only did I get a lot of bounced spam to my catch-all, the spam that went through ended up in places that other spammers picked it up as a valid address so now I am getting spam sent to those randomized addresses.
At first I figured I could put together a rule to block all hexadecimal address of six digits but it turns out that at least another round of spammers started using the full alphabet and variable lengths.
I've come to the conclusion that I'm going to need to include a cookie in the addresses I use - so instead of dropdox@mydomain.com and amazon@mydomain.com it will be something like DOQ.dropdox@mydomain.com and DOQ.amazon@mydomain.com - addresses without the cookie get binned. But that's not going to help with all the addresses I've used over the last 15 years, and haven't kept track of.
The simple fact that one would have to jump through so many hoops just to try out a new service means that the system is broken.
It's like making you buy a car without allowing you to take it for a test drive. At least the reasons for photocopying your license before taking a test drive are understandable.
That is absolutely true, or at least I think it is. The single best thing we did it to allow our customer to do a purchase without being logged in.
If the email address entered on our checkout page is already in our database, we link that purchase to the relevant account. If the customer want to login, they can, if not, that's cool to. We get a lot of wrong matches which needs to be fixed, but that seems to be a price we can and will pay.
We have had customer adding orders to other people accounts, because their email address was entered wrong ( even though we require the customer to enter the email twice. ) and we have customers ending up with multiple account that we need to merge. Despite all the problems, customers love not having to log in before doing a purchase. It's hit and miss in a few cases, but we try to do what our customers expect, matching their purchase to their account, regardless of login credentials. That's what consumers want.
We did the same thing with one of the sites at work... You can make a purchase without login, and the related emails to a given order includes a token so you can see that order's status without login.. If there isn't an account at that email, we generate one with a few space-separated random words, and email the user... password recovery is email only and pretty easy. All in all, the user experience has been pretty well received.
Now that I've seen this in practice, it would be my preferred way moving forward. It didn't/doesn't take that much effort to do things this way. The bigger issue is in the occasional phone order our demographic is mostly men 50+, so some genuinely don't have email.. we use an internal address in that case...
My favourite online tea store does this too, and it's one reason I ended up eventually creating an account with them. anybody who dies this automatically gets a credibility boost in my eyes.
One could use something like a copy-and-pastable session/state string/encoding (that a user should keep secret, if secrecy is important to them) at the bottom of every important page that a person might want to return to (rather than in the URL or the invisible, and therefore unmanageable, cookie). If they care enough to save it, they have an account (ex, they don't have to fill in their shipping info for the 9th time...). If they don't care enough to save it, it can be automatically deleted after a period of inactivity. (This was a common solution to "saving state" in older video games without persistent memory. It wasn't "too complicated" either. People used it, if they wanted to get back to that difficult boss level.)
A login is a continuation, or a state/session key. So is a link/URI. There's no need for a mandatory "account" just to be able to pick up where you left off, even if it's to continue checking your email. (Though one could opt-in to further "protect" pages with passwords, biometrics, non-invasive mucus swab samples, and so on...)
Tangentially related, for similar reasons Paypal remains my payment processor. Lots of people have Paypal accounts and find it much more convenient to use it rather than haul out their credit card and hand key all of their address and payment info. Every time I think about switching I review how many people use PayPal Express checkout rather than credit card DirectPay (both of which I offer), and I think about how many people simply wouldn't pay if the minimal friction of the PayPal Express button wasn't there on my checkout form.
Totally agree! Because I am not the biggest fan of PayPal, one of the best things I did to speed up ecommerce for myself was to memorize my CC details.
I have recently been converted to the joy of filling in credit card details (and address and phone number and...) with LastPass' form fill function. I previously had my CC details memorized for similar reasons, but I didn't realize just how much time I was wasting typing this stuff in over and over until it was magically done for me. And since security is what LastPass does, I have no problem with having their extension save my CC info in a secure manner.
I am an avid LastPass user and I already have my CC details in LastPass. But, until now I didn't realize you can add them to the Form Fill details! Thank you tempestn!
I'm a technical person and I don't like social login and I don't like creating individual account for every site. What I would like is a decentralized single-login protocol like the article is talking about.
One example of this is pud's launching of fandalism.com. When he announced the site on HN[1] some HNers complained about Facebook only login. But he was still able to get 400,000+ signups within 3 month[2].
Highly likely because MailChimp is a BUSINESS site, not some consumer site. Normal people love to just click a button and see their facebook image and name saying, "Welcome back, John Doe!" - without any pesky emails or other junk.
Aren't most of the people logging into Mailchimp online marketers? Maybe "technical" is the wrong word, but their customers are all in the tech business somehow or another. I think that qualifies.
Wow, my experience and testing was quite different (not a huge site, a few hundred thousand users). When given the choice between creating a new login/password or using Facebook it broke about 70% to a new login/password. Demphasizing facebook login increased conversion rate pretty substantially.
There are obviously hundreds of variables in play here from the content of the site to the fundamental design that may be influencing this.
Interesting! That's what I expected but I think the vertical matters quite a bit. My old startup (http://getpressi.com/) that had more of a tech crowd focus definitely had more people signing up with email while the new one (https://makersalley.com/) has a more general population that tends to like using Facebook.
At this point our total users is in the hundreds so who knows how it'll turn up.
Yea - I definitely agree. Just throwing in my experiences. I will never use Facebook or Twitter if I can help it but in my experience "mainstream" users tend to prefer that to using their email.
Agreed -- this article shows not one data point to back-up their argument, but if you do look users actually opt for social login due to ease of access and use. Hell it's what makes paypal so easy and popular -- you put your data in one trusted service, and it works with minimal pain points across any site that requires payments.
Technical person here, and I will use Facebook or Twitter login 10 times out of 10. I do not want to create a new account for your service unless you absolutely force me to.
I think adding social auth was one of the biggest mistakes we made for the beta of Jetstrap. Users constantly forget which service they use. We added email/pass authentication, but now older users think they had a password when they didn't, and with django social auth you can't reset the password for a social account.
It was one big mess not at all worth it. I'd like to try Persona and see how that compares, but I think normal email/pass is better than plain social auth.
Why don't put the way the user was logged in by last time in cookie and just highlight it next time for him? Or even more explicit - add the "you have logged in this way last time" under the appropriate button?
If a user returns relatively quickly they generally remember how they logged in. The problem is when they come back after some months. At that point, they've probably completely forgotten how they logged in, and have cleared their cookies for some reason or another. It's a standard troubleshooting suggested by many websites. (Not saying it should be so, but it is.)
Users always complain about social logins. On iOS apps that I've built, I've found Facebook login to have something like a 50% conversion. I'd be curious to hear whether or not the conversion is improved by using Mozilla's Persona product. Is the only sales pitch here that the login is managed by a non-profit organization?
Not sure how that makes this a better product overall. Can anybody clarify?
Major difference: Social auth outsources your user table. Persona outsources your password column. You still have your own users, and you still have a portable identifier for them.
What's more, Persona is built as a fully-decentralized architecture with a temporary centralized fallback. That means that one button can support all users, via their email provider's native authentication mechanisms (in the future) or via Mozilla's centralized fallback (for now).
I don't understand your first point. How can you have an app function without a users table?
The main issue as I see it is just the baggage that comes with a private company login. For instance, Facebook login raises questions about what Facebook will do with the login information, and also what the site will try to do with your Facebook data and permissions. Those questions will increasingly become a concern for everyone, but beyond that some people have opted completely out of Facebook because they find it actively harmful and so they are excluded a priori.
Persona is simply a login mechanism with the users interest in mind. People may take or it leave it, but it will be on its own merits rather than being overshadowed by needlessly related general concerns with a third-party product.
Hi, I'm on the Persona team at Mozilla. If you'd like to learn more about what and why Mozilla is doing with authentication, I gave a 45-minute talk at PyCon US this past Saturday. You can find the video here: http://pyvideo.org/video/1764
I'm also happy to answer questions in-thread or via email.
My main question is: where is the support for the assertion made in the article title? As far as I can tell, it's just made, and then the remainder of the article treats it as a premise or a claim to be supported only with vague anecdotes.
The proliferation of sites that only or primarily accept social logins seem to suggest that it's not a sound premise. However, I'd be interested to know if you guys have some data that's not shared in the article that suggests it is.
Hopefully someone else will chime in with actual citations, but we've seen a preponderance of evidence from our own user studies, from MailChimp, TechCrunch, and Voo.st's published comments, from Gawker Media's creation of an in-house non-social mechanism shortly after they tried to go social-only, and from private conversations with companies who have daily active user counts well into the millions.
> The proliferation of sites that only or primarily accept social logins seem to suggest that it's not a sound premise.
I'm not sure that necessarily follows. Google's own advertising for G+ authentication touts its privacy features, which suggests that Google also believes that users are uncomfortable with social auth as it exists today.
(Anecdotes aren't data, but they're what I have on hand at the moment. Sorry! Still at PyCon.)
All right. Thanks for this. Best of luck with your talk. I was nervous the last time I gave one and my audience was much smaller than yours will be. ;)
Thank you! I actually gave the talk a few days ago (I'm sticking around for the post-conference sprints), and I think it went well. In the future, I'd love to have hard data ready to cite in response to your question. I'll try to gather some once I get back home.
I looked at Persona for a project a friend of mine is doing, and I pretty much rejected from the start. Persona seems flawed in that it assumes email as identity.
I'm a developer on a e-commerce site, when we started out we assumed what Persona assumes, that email is a unique and stable identity. We found out the first day of production mode that this assumption is flawed. People changes email address all the time, it's at least as unstable as their home address, most peoples phone number is more stable.
As software developers we assumed that pretty much no one would ever change their email address, or that at least they wouldn't discard their old one. Regular people however do that. They do not care about their email address.
Is this something that the Persona team that given any thought. If so, what did you come up with?
Persona's about page says that you can use multiple email addresses with a single account.
"Within Persona, your identity is your email address. You can use as many email addresses as you want, but you still only need one password.". - https://login.persona.org/about
It's not really clear if it maps to the same identity. I should test that.
However I think it might still confuse customers. A normal user expect to be able to change their email address on the site where they do business and the "MAGIC". I think we would have been better of requiring a username, email and password, rather than using the email as the username. For a large number of people needing to have both username and email seems redundant and stupid, for real life customer... not so much.
My issue is, a customer has X number of orders on our site. Then he/she changes email and expect that using the new email address the old orders are magically available. This seems naive but that is what you have to deal with.
Again I should check to see if Persona indeed maps multiple emails to the same identity. It didn't seem like it when I tested it last, but I would not rule out that I did something wrong.
It maps multiple emails to the same identity, in that you use the same password to log in with all of them. The end site gets the email you log in to the site with (I can log in to Persona with email A but let all sites know email B every time. If I change that to email C, sites will think I'm a different user).
You can let users change email addresses, and nothing bad will happen. They'll just have to log in with the other address next time.
On the one hand, I think email addresses are FAR more understandable as "identity" to an average user than URLs are, which to me is the fatal flaw with OpenID. To an "ordinary" user, URLs are websites, not people.
On the other hand people do change identifiers. They change usernames (jsmith gets married and now wants to be jadams) and they change emails (for the same reason, or because they change ISPs or mobile carriers or whatever). ANY authentication process you use should allow the user to change his identifier (or any other personal attribute even gender) at will.
Internally you deal with this by connecting the identifier to an other token that is the real "permanent" identity for the user in your system. But it's one that's never exposed to the actual user. It sounds like your system was using the email address in the order records to identify the customer. That is what your real problem is, not that people change email addresses.
> But it's one that's never exposed to the actual user.
Why not expose it to the user? Because then they'll want to change it? Are you talking about browser fingerprinting?
We already expose this on the user/email level, where users can link and log in with as many email addresses as they like, under one account (identifier).
Sure, sometimes their usernames are their primary keys. Even if the actual primary key is arbitrary, the primary identity is still exposed to the user, in that they know what their user account is, and which email addresses are linked to it.
Email address is the backbone of web identity. Nearly every registration system uses it. If you're having trouble with it, maybe, just maybe, it's on your end?
If you honestly believe that, I would claim that you either have no customers or that your customer reside in a very limited sub-section of people.
People do not believe that their email and identity is in any way linked. You and I might believe that, but don't count on your customers sharing your beliefs.
People do not believe that their email and identity is in any way linked
I think that you might have to explain that a bit.
I think that others try to argue that people use email at least as temporary identity, in the sense that at time t, they identify themselves with at least one of their email addresses. In practice this is enough for many web sites to use the email address as login. Perhaps you are talking about some longer sort of permanence, or uniqueness?
Say what? My email addresses are linked to my identity because they are my email addresses. Most of them even have my name on them. Sure, I have several of them, and one of them disappeared when I graduated from college, so the mapping isn't perfect -- but they are nevertheless mine.
The main exceptions to this are:
1. People who share an email address for convenience, like my grandparents.
2. Group-facade email addresses, like support@whatever.com, which may be routed to several people.
3. Email addresses that don't belong to anyone, like "noreply@whatever.com", or "autogenerated-4b243efa37e5b013a1d90b694c3bcaa3@hell.com"
You'll note that both Facebook and Google provide ways to hook up multiple emails to the same account, and multiple recovery accounts. Why do this if nobody uses it?
(Damn, I had wanted to post this yesterday, but then I forgot to quite finish it and it ended up sitting in a tab, unsent.)
Yes, it does: it means that you cannot count on it as a canonical form of identity for any long period of time, as people expect to be able to change it; in fact, many people go through "the great purge" every couple years, deleting their e-mail address and selecting a new one, in order to purposely reboot the people who have their address: to them, it is a way to purposely restart their identity.
You thereby have to think of e-mail addresses as more akin to your home address. If you ask me to log in with my home address, yes, that works: it doesn't work for everyone, as not everyone in the world has a home address, but the same thing can be said for e-mail addresses. Sometimes people will share a home address, but surprise surprise: sometimes people share e-mail addresses as well.
When I am asked to log in to that form with my home address, and it works, you now might claim I've accepted it as part of my identity. Well, I haven't: I'm going to change my home address at some point, and someone else is then going to start living here, which is exactly what happens to many people who use ISP or University -provided e-mail. Hell, it also happens to people with vanity e-mail addresses if they let their domain registration expire (as happened to one of my friends, who otherwise was using the same e-mail address for a very very long period of time).
Yes: it works temporarily, but it isn't my identity, and eventually it will fail, and unless you are really really weird (like, you are the kind of technology person who would probably consider it digital suicide to allow their domain name to expire, and has had the same e-mail address now for well over a decade), it will fail sooner than later, and may even fail on purpose when users invalidate it.
How are usernames any different? You're saying identity is transient. This is true of every sort of identity except perhaps your soul. Regardless email addresses are more stable and unique than usernames. In fact they are just a username plus a domain that happens to have the ability to be routed messages in a standard way.
Of course you should be able to change the email on an account. Usernames can also be changed and are far from canonical. Your point about emails is not invalid, it's just not addressed by usernames, and usernames are actually inferior in that respect.
So, I did not use the word "username" in that comment you are replying to. I thereby will assume you mean "stable and opaque identifier assigned and chosen by the authentication provider", which is what I would argue for (as opposed to attempting to rely on an e-mail address as a stable identifier).
I did use the word "username" in a response to someone else, but that was a very different (and much more abrasive :() argument path.
> Regardless email addresses are more stable and unique than usernames.
E-mail addresses are not more stable that usernames, because e-mail addresses have an external purpose: they receive e-mail. Many people actively go and change their email addresses periodically in order to stop receiving e-mail from people they previously were receiving e-mails from.
A "username" (your word here), especially (and maybe specifically) the "good" kind that is never shown to another user and is just used for account canonicalization, which conceptually could be a random number assigned by the system, is something that the user has no reason to change unless they actually want to never log in to the account again.
E-mail addresses also are tied to the DNS system, which other forms of identification need not be: you can instead tie them to a private key kept by the authentication provider. That would make "me" be A@B where A is a number and B is a key pair. In this way, even if the way you continue to contact my authentication provider lapses (such as attempting to use a hostname) only if the new owner has the same key are they able to claim the identities there (unlike e-mail) and as the user specifier is opaque (not a string that I'm going to care about and want to make pretty, or something I'd ever want to change unless I actively want to lose access to my account) it will not run afoul of the problem with e-mail where people feel compelled to reuse them after some time of abandonment.
The problem then with Persona is that it is the websites consuming it who have the onerous job of dealing with every possible e-mail address change a user may request. With more classic attempts at federated login, users may end up with multiple authentication providers that can become somewhat confusing, but they demand to change authentication providers and especially lose access entirely to authentication providers sufficiently rarely that it is a non-issue to handle the support load of helping users remap their accounts (something that is difficult to automate, of course, in the case where the user already lost access to their old identity). With Persona, this is now something that the user has to do when they change e-mail addresses at every site they may ever have logged in to using their account, ever. :(
Nope, like all other large providers (Facebook, Google, etc.) Amazon allows users to use e-mail addresses to log in, but they are not canonical stores of identity. In fact, Amazon is the most humorous example you could have pulled, because Amazon actually allows multiple accounts with the same e-mail address, and uses the password to differentiate (which is pretty much what jointb86 said, but I doubt if you knew this is the case that his comment was clear).
"Why Does Amazon.com Allow Multiple Accounts With the Same Email Address?"
"Note: If you change the e-mail address on your account to an e-mail address that is already associated with another Amazon account, we will ask that you first verify your e-mail address."
I have had the same email address for 18 years, but I'm a dying breed. Most people I know change email address pretty regularly - as in more than once a year.
Seriously, most people you know change their email address more than once per year? Honestly, MOST of the people you know do that? I highly doubt that.
Sure, but the Facebook login is just "any e-mail address"; it doesn't really mean something for your account. You can add more e-mail addresses to your account, and all of them are allowed to be used to log in; the same, incidentally, is true of Google accounts.
- Many people never abandon their primary identity email.
- But many other people often abandon their email identity.
- You don't want to use a social network as the gatekeeper to *your* site.
- You don't want to have human support for password resets.
Sekrit questions/answers along the lines of your first car's maiden name? Those can be forgotten just as easily as usernames for login.
Not once a year, but here in new zealand for most people the email address is provided by the ISP.
When they change their ISP, they typically get a new email address.
Most people I know have changed their ISP a couple of times.
Surely most people in that kind of situation would move to gmail/hotmail/yahoo or similar, though? I'm sure my ISP offers me a free email, but I can't say I've ever used it (or even asked after it...)
Users using cloud e-mail addresses have addresses that are slightly more stable, but eventually they decode that @hotmail.com looks better than @aol.com, that @yahoo.com looks much better than @hotmail.com, and eventually that @gmail.com looks better than @yahoo.com. When they do this, they change their e-mail addresses, and often just derelict the old one so they don't have to think about it anymore.
Also, to the extent to which this becomes important, it only becomes important too late, as in after you've already used an address or two. I have had the same address now since 1997 when I registered saurik.com, but I did that because I had in the two years prior "learned the hard lesson" that my ISP-provided e-mail address was doomed to be something I'd end up having to move off of, potentially fairly often.
> Email address is the backbone of web identity. Nearly every registration system uses it.
"Everyone else is doing is doing it that way" isn't a reason to do it that way, especially for a product, like Persona, that is supposedly about fixing what is wrong in what everyone else is doing.
Except that:
1. Email actually works quite well as an individual identifier. At any given time, an email account is probably linked to only one person.
2. No alternative exists, in real world use, that really looks better
> Except that: 1. Email actually works quite well as an individual identifier.
No, it doesn't.
> At any given time, an email account is probably linked to only one person.
Lots of people have shared email accounts. And even without that the "at any one time" is one reason why it doesn't work as an individual identifier, its not stable. (Since cell phones and number portability have become ubiquitous, phone numbers are probably better than email addresses at this, but share the same sorts of problems.)
> 2. No alternative exists, in real world use, that really looks better
Sure alternatives exist. While its often important to have a contact email address connected to an identity, there is no reason to have an externally-meaningful value that is inextricably tied to the online identity, particularly if that value doesn't have an intrinsic, unique, and stable link to a particular person.
You're justifying choosing a bad natural key with the argument that its the least-bad natural key, when not only is the proposition that the proposed key is the least-bad natural key somewhat dubious, more importantly, the use case calls for a key, but there is no reason for it to be a natural key.
«You're justifying choosing a bad natural key with the argument that its the least-bad natural key, when not only is the proposition that the proposed key is the least-bad natural key somewhat dubious, more importantly, the use case calls for a key, but there is no reason for it to be a natural key.»
Of course it has to be a natural key! Are you expecting that users will learn your theoretically perfect surrogate key? Do you understand that you will be competing for space in people's brain? For what reason? Because shared email accounts break the many to one relationship on mail <-> person?
> Of course it has to be a natural key! Are you expecting that users will learn your theoretically perfect surrogate key?
I'm not sure why users should ever need to know the key.
> Because shared email accounts break the many to one relationship on mail <-> person?
No, I probably wouldn't even both with addressing the problem of shared email accounts (which would require some discriminator), but with one person having multiple email accounts and email accounts changing over time. These things indicate that accounts should have transitory, one-to-many relationships to email addresses, rather than email addresses serving as a key.
«These things indicate that accounts should have transitory, one-to-many relationships to email addresses, rather than email addresses serving as a key.»
The only requirement for the email to be a key to the account is the association of one email to one person. A person can have more than one email, at different times or at the same time. The only thing that can't happen is one email mapping to two individuals. Full circle: the majority of emails do map to one individual and the cases where they do not map, are not enough to preclude the use of emails as keys.
Perhaps the confusion occurs because you think I'm defending email as a primary key for the account. I'm not. It's one key, not the primary key.
Isn't that his point? Email address is a backbone of web identity simply because we don't have anything better. Maybe we should finally get around to figuring out something better?
It's a hard problem because anything real world like a identifying number is flawed for anonymity. There needs to be a unique identifier for a web entity.
It's always annoyed me that solutions like persona etc are approaching this by simply replacing email, when shouldn't they be abstracting my online identity? I hold several "personas" throughout various sites, email addresses, and applications. However, I don't want a product that simply merges them, I want a product that is more of a "meta-persona", that lets me easily track, manage, and expand them.
Sounds like it already does kind of do that. From StavrosK above:
"It maps multiple emails to the same identity, in that you use the same password to log in with all of them. The end site gets the email you log in to the site with (I can log in to Persona with email A but let all sites know email B every time."
So based on that, if you want to expose three different identities to 3 different sites, you can set up Persona to do that automatically, without having to remember the separate emails and passwords you used for each one. I guess the only problem would be if you needed multiple separate logins to the same site, but unless it's your own site, presumably that should be rare.
I think you may have a unique case on your hands. I am a web developer for a big eCommerce site and we use emails to identify users (we switched from usernames to emails after a few months of testing actually). After three years of the site being up we have only had a handful of people get confused about their email changing.
If a user does change their email they can log in as their old email and simply update their account to their new one.
Email is a much better system than username because people constantly forget the unique username they created for that specific site. You don't really forget your email very often.
+1 to your decision. I HATE site that use usernames instead of emails... i wont even use sites that do that unless i really really have to (like my health care provider).
The problem is not displaying a username. The problem is using the username to login. Because users forget that.
If you're stupidly using your email as your username then your email becomes public should the site you're on show, at any point, your username.
Which is why sites correctly done use the email for login but display a username and never your email. Correctly done sites also forbid username from containing '@', so that you can be sure that people don't do anything retardedly stupid like using their email as username, which would be displayed publicly on the site...
That actually sounds pretty hard to believe - Amazon uses your email id as your username for one, as does iCloud. Both services have hundreds of millions of users.
First, Amazon actually allows multiple separate accounts to have the same e-mail address, and will use the password to decide which one you are trying to log in to. Second, using your e-mail address as a potential username (sometimes, one of many possible, as is the case with Facebook or Google, which will let you use any of the e-mail addresses associated with your account or your username to log in) is very different from treating it as your identity, and you can tell the difference when you ask the question "what happens if I lose access to that address, change to a new one, and someone else is assigned the one I was using previously?", which happens to many people using e-mail addresses provided by third parties (such as companies, ISPs, or universities).
How, today, can I integrate Persona login into my site without referencing any third-party Javascript? Does any solution exist for sites that by policy only load Javascript from the same origin?
Thank you so much for this system. I sincerely hope that this gets more traction than OpenID. This is the most essential feature the entire web has never had.
I am very happy with the way persona works, both as an end user, and how easy it is to integrate into applications. I am hoping it gets some good marketing done or whatever is needed to make more sites start using it.
I actually do not login to website that asks me login either using Google a/c, Facebook or so. Twitter being an exception because everything at Twitter I've anyway made public, but I hesitate still.
That's a strange opinion to have though, because before doing login through either of these services, you will be asked if you want to give that app permission to certain parts of your account. For example, I might have you log in through Google to verify your email and I don't see a reason why you wouldn't let me see it; you've already shared your email with my app to register an account in the first place.
Most of the website, do not just ask Email. Most ask other info too, like my DOB, full name, Other Profile information. And when I say I "do not use", I am talking about the first time logins of course. I don't really know what kind of a website it is, legit or just a vapour. And I do not know in advance what information it will ask.
Take the example of The Old Reader, till recently they wanted to take control of your Contacts too(along with Reader; now they don't). I knew it once I was at past the Google SigIn page(and I aborted right there). It was frustrating even for those few seconds. Many do this.
So, I have given up on them altogether.
I mean I have OpenID accounts set up especially for this with the data I would like to provide for this. There Mozilla's Persona(it's Identity Management System)- etc. Why not use these?
And do not even get me started on Facebook. I don't open a website again if the only way to login was via Facebook. Paranoid? No, rather pissed off. (By the way, whenever I tried using Facebook logins the above mentioned problems surfaced only in bigger multitude).
Because everyone has Google, and the lowest setting on Sign in with Google+ contains some personal information from your account, including things like DoB, Full name, etc. Google recommends OAuth2 over OpenID for authentication, and I'd rather be using the service Google supports the most in order to provide the best experience to users.
Just because you use OpenID and Persona doesn't mean that the majority of people will. But the majority of people will have a Gmail account, or a Facebook account.
There's an "evil" incentive to have social logins such as Twitter + FB. It gives you a free access token, which can be extremely useful, especially if you're building a social media analytics service, or some sort of tool that requires making API calls.
The worst offenders are those that lead you into a social login, then post every page you view on your facebook wall. I've learned some fascinating things about my friends' reading tastes this way, but I'm sure they weren't happy about it.
Yes, I do this exact same thing. I really don't want to store password on my side and I'm of the impression that sites like Google, Facebook, and Twitter do this better than I ever will and that most of the users visiting the site will have some kind of account on these sites. Ignoring man-in-the-middle attacks, if one of the above thinks the email is valid, I have no reason not to.
As a disclaimer, though, I've worked on highly specialized apps where the users belong to a certain organization bound by one of the above. For example, I made a website for my school and every student there has an email address that is tied to that school's Google Apps for Edu account, so I'm guaranteed that all valid users (students) will be able to log in via Google.
As hard as remembering different passwords for different sites is for the end user, I really think it's about time the user took a step toward meeting security and engineers in the middle.
Did 20th century humans think key rings were too complicated? Why are we implementing tokenization, one way hashing, etc. when the end customer can do this much more securely? Oh yeah, we'd like to get at their data when they're not around..
Exactly. But sadly you're in a tiny minority of people thinking about the security implications. Most developers don't: which is why we're having countless OAuth exploits and whatnots.
Schneier wrote a long time that anything too complex cannot ever be secure. That's the case of OAuth and of many federated/unique/single sign-on logins.
We just implemented Persona across all our sites and are very happy with it.
We did it in a way that's completely independent of our normal email/password login as well, but integrates seamlessly. That made me really happy, as the reliability of our system hasn't decreased a bit.
The Persona team was also really helpful, though it turned out we didn't need much help implementing it.
I doubt users really care about what type of login they use. Instead, users are starting to associate social logins with spammy bullshit, federated identity marketed shitfest of Web 3.0, built on the SAML/HTML5-based Intelectual Property and right forfeiture platform.
Surprisingly companies are finally realizing this. Like companies really thought people would not care to give away all their 'social' unneeded information for some random x or y service.
The point about having multiple providers and forgetting which one you used rang true to me. My gotos are twitter, google, or github and it seems I change based on the type of app I'm connecting with.
With regards to the last point - privacy from your identity provider -- isn't that somewhat moot for most sites as they have those facebook/twitter/google+/etc share/like/plus icons that report back anyways.
231 comments
[ 4.3 ms ] story [ 246 ms ] threadAnd that's the way I like it :)
"We built the Persona protocol to reduce data sharing to the minimum needed for the user to easily log in: the browser mediates the login without leaking data to the identity provider. In the end, Persona is the easy login solution that respects users."
Ben is a smart guy, I've read about Persona, and it seems to be really well thought out and to have learned from the failings of e.g. OpenID. I intend to use it the next time I need an easy login solution for users.
Not tied into Google/Yahoo/Facebook/MyLittlePonySocial - but not having to create a new account. Oh, and I own the data (Not the AppData of course though).
I use Persona on my costs-real-money subscription site[1] and I'm very happy with it. Integration was easy, the user experience is pretty good, and it's been stable and reliable. The best thing, of course, was not having to implement my own password-management infrastructure, which saved me a ton of time, as well as insulating me from the hard security problems that come along with such a beast.
If you decide to try Persona, I heartily recommend it. There are a couple of gotchas to be aware of:
1- On iOS, only Safari works due to Persona using a pop-up window for login. People using Chrome on iOS will get a confusing "relay frame not found" error.
2- Signup flow could be better. When users create an account, they get a confirmation email. Clicking the link in that confirmation email redirects them to the Persona site, not back to your site. It's possible this is configurable and I haven't figured it out yet.
3- Persona emails are case-sensitive. There's some rare issues that occur as a result. At one point, it could crash the login, but I believe that's been fixed.
Don't let these flaws stop you, though--Persona is very well done and constantly getting better. I've had hundreds of people sign up for paid accounts and only two have had trouble to the point of asking for help. (And nobody's cancelled their subscription because of login problems. :-) )
[1] Let's Code Test-Driven JavaScript, letscodejavascript.com
https://developer.mozilla.org/en-US/docs/DOM/navigator.id.re...
> returnTo: Absolute path to send new users to after they've completed email verification for the first time. The path must begin with '/'. This parameter only affects users who are certified by Mozilla's fallback Identity Provider.
Of course, if you find anything we've missed, please file a bug :)
Upgrade to the Observer API (`.watch` and `.request`) and your users will automatically get a super smooth post-verification experience, just like you described.
I like it a lot, but at the end of the day I'm still relying on a single company to hold the keys to many accounts of mine on the web, which is still a bit jarring (not that it's going to stop me).
Actually, with Persona, you're not. :)
Persona has a fully decentralized architecture. The centralization you're seeing right now is completely temporary, and only serves as a bootstrapping convenience. If you own your own domain you can turn it into a Persona Identity Provider and start minting your own identity certificates today, without Mozilla (or any other single company) being forced into the trust path.
Awesome, good to hear. I saw the thing about Identity Providers and got excited, but then I logged in and was like... aww..
So, hopefully Google will be doing it soon with Gmail/Google Apps!
I'll submit a feature request to Spotify to get them to support Persona log in. When Gmail and Spotify are gone I'll be two big steps closer to getting rid of that pesky Facebook account ;)
EDIT: Oh, can I help beta test it?
Perhaps I'm missing something.
In short: it's bog standard public key cryptography. My browser has a keypair and my email provider has a keypair. My public key and email address are bound together and signed by my email provider's private key. When I want to log into a site, I pass along that certificate. I also pass along a document containing where I want to log in and and the current time, signed by my browser's private key.
The latter document ties a given login request to a specific keypair. The former document ties a given keypair to an email address.
Together, they identify me and prove that the person logging in really is the same person that was authenticated by the email provider.
perhaps an additional field: Email: [_____________] Confirm Email: [________________] Subscription: $24.95/Month (after free 7-day trial)
I tend to be suspicious when the price isn't at least as conspicuous as the biggest/boldest text.
Example: http://www.roadreadycertified.com/
I'm limited by a serious lack of graphic design skill, and this page wasn't part of Primate's original design work for the site. It shows. :-) It will get a proper design at some point in the future.
Just as a point of info "only two have had trouble to the point of asking for help" is a really bad way of judging whether something is working well or not for your customers.
The vast majority of people do not complain if they hit problems. They just silently go away. From my experiences of optimising this sort of stuff I'd pretty much guarantee that you have at least 10x times than number failing and walking. Possibly much higher.
By the time they get to the "create Persona account" part, they're already invested in it working.
I also monitor my logs for signs of trouble. One of the two issues I was talking about above was actually initiated by me reaching out to the subscriber. (I happened to see them bouncing on the "now log in" page within a few minutes of their subscribing.)
And I also ask people who cancel why they did so. The vast majority respond, and none have said "I couldn't log in." :-)
It's quite possible there are still some angry silent unsubscribers who were stymied by Persona, but at this point I'm satisfied that it's not a significant number.
But you do realize it does definitely create another, much more serious, security problems right? What happens when the single sign-on server gets compromised? What happens when tokens aren't as secure as they should (like the recent OAuth SNAFUs, with an 's')? What happens when you don't pay attention to all the fineprints in the Persona docs stating things like:
"Be careful if you don't do this it's going to be easy to forge"
and:
"Guidelines to use Persona securely"
?
So it can be used not securely? Like OAuth? Do you think I find it re-assuring that I have to take steps so that things are not easy to forge? What when the latest JavaScript / browser exploits manages to forge requests?
Don't get me wrong: this seems very convenient. But you're trading time for something here. It saves you time by now having to roll your own security correctly (a DB into which you put emails and bcrypt encrypted passwords) but it comes at a price.
The price is the added insecurity that single sign-on adds.
As far as I can tell, using Persona requires less attention to security than doing it myself. I don't see how that translates to creating "much more serious" security problems.
Perhaps you are a security expert who can do a better job than a team of Mozilla developers who are dedicating themselves full-time to solving authentication problems. I'm not. I know enough to know that security is harder than it looks, and that even if I salt my fries and crypt my bees, I can still screw things up[1]. Better to outsource it... well, as much as I can, anyway.
[1] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Proje...
Persona has a federated architecture. In the very near future, most users will not be vouched for by a central authority.
> bcrypt encrypted passwords
Don't forget to upgrade everyone to scrypt when that recommendation changes.
So long as you specify your origins properly and properly check the response from their verification service, it's perfectly secure.
Just put auth info in a cookie, and let the user associate it with an e-mail address later, once he actually knows he will keep using the service.
I believe "I can't be arsed to register" is one of the top reasons websites lose prospective users.
That has to cost a lot of money. With the dozens of ways you can authenticate with StackExchange, I don't know why I was surprised to learn I had previously created an account without actually creating an account, but it was so.
Also, anyone who reads Korean can tell me if this says "sorry we're closed"?
http://kingdon.myid.net
I've tried to participate in their "meta" site, but the pedantic and condescending tone there is even worse than it is on the main sites.
date of close : 2013-02-27
Call me paranoid, but I think "deleting" your account has the potential to actually do more harm than good, since in doing so you are voiding any agreements or terms that you had previously agreed to, including those that promise not to sell or otherwise abuse your info.
eg messages to myrealemail+mytag@gmail.com will always be received by myrealemail@gmail.com
I too have a domain with catch-all, and I do that rather than using the + notation, but it's something you can teach your friends who would never do that.
I'd never want to depend on that for anything, it's really just a novelty; a simple regex will nullify any effect you'd gain for using that.
Yeah, I'm counting on e-mailers to send mail to the address I give them. No, I don't expect folks to send me spam unsolicited, or sell my address when I give it to them. I don't consider my name or e-mail address to be secret, and I'm also counting on anyone who sells my contact info to be doing it in bulk, not paying enough attention to strip out +tags, and by passing the address to spammers unaltered (or losing control of their database), give themselves away when I start receiving spam at that address.
Honestly I don't use the feature very often and I had not considered it to be a security measure before. Maybe novelty is the right word.
If I give myaddress+dropbox@mydomain.com to Dropbox, and they mail me from different addresses, I would be able to catch them all and put the "Dropbox" tag on them all, rather than having to make a filter for *@dropbox.com or some other extraordinary measure for classifying their mail.
It's part of the RFC, and supported by every mailer that I know. What part of this technique seems like obfuscation?
So, if you only use +tag for your own personal organizational purposes, then have at it! But if your goal is to conceal your account ID with Google in the interest of personal security, then you really need a better angle.
On a related note, some spammers have really done a number on me. First they impersonated thousands of addresses at my domain in the form of xxxxxx@mydomain.com where x is a hex digit. This is despite me having DomainKeys and SPF enabled. So not only did I get a lot of bounced spam to my catch-all, the spam that went through ended up in places that other spammers picked it up as a valid address so now I am getting spam sent to those randomized addresses.
At first I figured I could put together a rule to block all hexadecimal address of six digits but it turns out that at least another round of spammers started using the full alphabet and variable lengths.
I've come to the conclusion that I'm going to need to include a cookie in the addresses I use - so instead of dropdox@mydomain.com and amazon@mydomain.com it will be something like DOQ.dropdox@mydomain.com and DOQ.amazon@mydomain.com - addresses without the cookie get binned. But that's not going to help with all the addresses I've used over the last 15 years, and haven't kept track of.
It's like making you buy a car without allowing you to take it for a test drive. At least the reasons for photocopying your license before taking a test drive are understandable.
If the email address entered on our checkout page is already in our database, we link that purchase to the relevant account. If the customer want to login, they can, if not, that's cool to. We get a lot of wrong matches which needs to be fixed, but that seems to be a price we can and will pay.
We have had customer adding orders to other people accounts, because their email address was entered wrong ( even though we require the customer to enter the email twice. ) and we have customers ending up with multiple account that we need to merge. Despite all the problems, customers love not having to log in before doing a purchase. It's hit and miss in a few cases, but we try to do what our customers expect, matching their purchase to their account, regardless of login credentials. That's what consumers want.
Now that I've seen this in practice, it would be my preferred way moving forward. It didn't/doesn't take that much effort to do things this way. The bigger issue is in the occasional phone order our demographic is mostly men 50+, so some genuinely don't have email.. we use an internal address in that case...
A login is a continuation, or a state/session key. So is a link/URI. There's no need for a mandatory "account" just to be able to pick up where you left off, even if it's to continue checking your email. (Though one could opt-in to further "protect" pages with passwords, biometrics, non-invasive mucus swab samples, and so on...)
Real people (non-tech / nerd) prefer not having to create individual accounts for all sorts of different services.
I've seen proof of this time and time again.
Lowest friction wins.
[1]https://news.ycombinator.com/item?id=3559081
[2]https://news.ycombinator.com/item?id=3850739
I really do wish that people would at least offer something other than a single method for us that don't like linking together everything though.
https://blog.mailchimp.com/social-login-buttons-arent-worth-...
There are obviously hundreds of variables in play here from the content of the site to the fundamental design that may be influencing this.
So really, just a data point:)
At this point our total users is in the hundreds so who knows how it'll turn up.
Yep - it's definitely just a data point.
A very small, and probably very uninteresting data point: I wouldn't sign up - if you'd only allow login through "social media" accounts.
(I would however, if you offer Persona or regular sign-up username/email accounts though)
Here is a presentation on one of their recent studies https://air.mozilla.org/online-identity/
It was one big mess not at all worth it. I'd like to try Persona and see how that compares, but I think normal email/pass is better than plain social auth.
Technically that's easy to implement.
Not sure how that makes this a better product overall. Can anybody clarify?
What's more, Persona is built as a fully-decentralized architecture with a temporary centralized fallback. That means that one button can support all users, via their email provider's native authentication mechanisms (in the future) or via Mozilla's centralized fallback (for now).
The main issue as I see it is just the baggage that comes with a private company login. For instance, Facebook login raises questions about what Facebook will do with the login information, and also what the site will try to do with your Facebook data and permissions. Those questions will increasingly become a concern for everyone, but beyond that some people have opted completely out of Facebook because they find it actively harmful and so they are excluded a priori.
Persona is simply a login mechanism with the users interest in mind. People may take or it leave it, but it will be on its own merits rather than being overshadowed by needlessly related general concerns with a third-party product.
I'm also happy to answer questions in-thread or via email.
The proliferation of sites that only or primarily accept social logins seem to suggest that it's not a sound premise. However, I'd be interested to know if you guys have some data that's not shared in the article that suggests it is.
> The proliferation of sites that only or primarily accept social logins seem to suggest that it's not a sound premise.
I'm not sure that necessarily follows. Google's own advertising for G+ authentication touts its privacy features, which suggests that Google also believes that users are uncomfortable with social auth as it exists today.
(Anecdotes aren't data, but they're what I have on hand at the moment. Sorry! Still at PyCon.)
And again, autocorrect makes someone look the fool.
I'm a developer on a e-commerce site, when we started out we assumed what Persona assumes, that email is a unique and stable identity. We found out the first day of production mode that this assumption is flawed. People changes email address all the time, it's at least as unstable as their home address, most peoples phone number is more stable.
As software developers we assumed that pretty much no one would ever change their email address, or that at least they wouldn't discard their old one. Regular people however do that. They do not care about their email address.
Is this something that the Persona team that given any thought. If so, what did you come up with?
"Within Persona, your identity is your email address. You can use as many email addresses as you want, but you still only need one password.". - https://login.persona.org/about
However I think it might still confuse customers. A normal user expect to be able to change their email address on the site where they do business and the "MAGIC". I think we would have been better of requiring a username, email and password, rather than using the email as the username. For a large number of people needing to have both username and email seems redundant and stupid, for real life customer... not so much.
My issue is, a customer has X number of orders on our site. Then he/she changes email and expect that using the new email address the old orders are magically available. This seems naive but that is what you have to deal with.
Again I should check to see if Persona indeed maps multiple emails to the same identity. It didn't seem like it when I tested it last, but I would not rule out that I did something wrong.
You can let users change email addresses, and nothing bad will happen. They'll just have to log in with the other address next time.
On the other hand people do change identifiers. They change usernames (jsmith gets married and now wants to be jadams) and they change emails (for the same reason, or because they change ISPs or mobile carriers or whatever). ANY authentication process you use should allow the user to change his identifier (or any other personal attribute even gender) at will.
Internally you deal with this by connecting the identifier to an other token that is the real "permanent" identity for the user in your system. But it's one that's never exposed to the actual user. It sounds like your system was using the email address in the order records to identify the customer. That is what your real problem is, not that people change email addresses.
Why not expose it to the user? Because then they'll want to change it? Are you talking about browser fingerprinting?
We already expose this on the user/email level, where users can link and log in with as many email addresses as they like, under one account (identifier).
People do not believe that their email and identity is in any way linked. You and I might believe that, but don't count on your customers sharing your beliefs.
I think that you might have to explain that a bit.
I think that others try to argue that people use email at least as temporary identity, in the sense that at time t, they identify themselves with at least one of their email addresses. In practice this is enough for many web sites to use the email address as login. Perhaps you are talking about some longer sort of permanence, or uniqueness?
The main exceptions to this are:
1. People who share an email address for convenience, like my grandparents.
2. Group-facade email addresses, like support@whatever.com, which may be routed to several people.
3. Email addresses that don't belong to anyone, like "noreply@whatever.com", or "autogenerated-4b243efa37e5b013a1d90b694c3bcaa3@hell.com"
Even Facebook uses email for login, as does google and just about every other website I use.
It's an interesting and bold statement that needs some supporting eveidence and explanation.
Yes, it does: it means that you cannot count on it as a canonical form of identity for any long period of time, as people expect to be able to change it; in fact, many people go through "the great purge" every couple years, deleting their e-mail address and selecting a new one, in order to purposely reboot the people who have their address: to them, it is a way to purposely restart their identity.
You thereby have to think of e-mail addresses as more akin to your home address. If you ask me to log in with my home address, yes, that works: it doesn't work for everyone, as not everyone in the world has a home address, but the same thing can be said for e-mail addresses. Sometimes people will share a home address, but surprise surprise: sometimes people share e-mail addresses as well.
When I am asked to log in to that form with my home address, and it works, you now might claim I've accepted it as part of my identity. Well, I haven't: I'm going to change my home address at some point, and someone else is then going to start living here, which is exactly what happens to many people who use ISP or University -provided e-mail. Hell, it also happens to people with vanity e-mail addresses if they let their domain registration expire (as happened to one of my friends, who otherwise was using the same e-mail address for a very very long period of time).
Yes: it works temporarily, but it isn't my identity, and eventually it will fail, and unless you are really really weird (like, you are the kind of technology person who would probably consider it digital suicide to allow their domain name to expire, and has had the same e-mail address now for well over a decade), it will fail sooner than later, and may even fail on purpose when users invalidate it.
Of course you should be able to change the email on an account. Usernames can also be changed and are far from canonical. Your point about emails is not invalid, it's just not addressed by usernames, and usernames are actually inferior in that respect.
So, I did not use the word "username" in that comment you are replying to. I thereby will assume you mean "stable and opaque identifier assigned and chosen by the authentication provider", which is what I would argue for (as opposed to attempting to rely on an e-mail address as a stable identifier).
I did use the word "username" in a response to someone else, but that was a very different (and much more abrasive :() argument path.
> Regardless email addresses are more stable and unique than usernames.
E-mail addresses are not more stable that usernames, because e-mail addresses have an external purpose: they receive e-mail. Many people actively go and change their email addresses periodically in order to stop receiving e-mail from people they previously were receiving e-mails from.
A "username" (your word here), especially (and maybe specifically) the "good" kind that is never shown to another user and is just used for account canonicalization, which conceptually could be a random number assigned by the system, is something that the user has no reason to change unless they actually want to never log in to the account again.
E-mail addresses also are tied to the DNS system, which other forms of identification need not be: you can instead tie them to a private key kept by the authentication provider. That would make "me" be A@B where A is a number and B is a key pair. In this way, even if the way you continue to contact my authentication provider lapses (such as attempting to use a hostname) only if the new owner has the same key are they able to claim the identities there (unlike e-mail) and as the user specifier is opaque (not a string that I'm going to care about and want to make pretty, or something I'd ever want to change unless I actively want to lose access to my account) it will not run afoul of the problem with e-mail where people feel compelled to reuse them after some time of abandonment.
The problem then with Persona is that it is the websites consuming it who have the onerous job of dealing with every possible e-mail address change a user may request. With more classic attempts at federated login, users may end up with multiple authentication providers that can become somewhat confusing, but they demand to change authentication providers and especially lose access entirely to authentication providers sufficiently rarely that it is a non-issue to handle the support load of helping users remap their accounts (something that is difficult to automate, of course, in the case where the user already lost access to their old identity). With Persona, this is now something that the user has to do when they change e-mail addresses at every site they may ever have logged in to using their account, ever. :(
"Why Does Amazon.com Allow Multiple Accounts With the Same Email Address?"
http://www.experimentgarden.com/2009/11/why-does-amazoncom-a...
"Note: If you change the e-mail address on your account to an e-mail address that is already associated with another Amazon account, we will ask that you first verify your e-mail address."
-- http://www.amazon.com/gp/help/customer/display.html/?nodeId=...
Also, to the extent to which this becomes important, it only becomes important too late, as in after you've already used an address or two. I have had the same address now since 1997 when I registered saurik.com, but I did that because I had in the two years prior "learned the hard lesson" that my ISP-provided e-mail address was doomed to be something I'd end up having to move off of, potentially fairly often.
"Everyone else is doing is doing it that way" isn't a reason to do it that way, especially for a product, like Persona, that is supposedly about fixing what is wrong in what everyone else is doing.
No, it doesn't.
> At any given time, an email account is probably linked to only one person.
Lots of people have shared email accounts. And even without that the "at any one time" is one reason why it doesn't work as an individual identifier, its not stable. (Since cell phones and number portability have become ubiquitous, phone numbers are probably better than email addresses at this, but share the same sorts of problems.)
> 2. No alternative exists, in real world use, that really looks better
Sure alternatives exist. While its often important to have a contact email address connected to an identity, there is no reason to have an externally-meaningful value that is inextricably tied to the online identity, particularly if that value doesn't have an intrinsic, unique, and stable link to a particular person.
You're justifying choosing a bad natural key with the argument that its the least-bad natural key, when not only is the proposition that the proposed key is the least-bad natural key somewhat dubious, more importantly, the use case calls for a key, but there is no reason for it to be a natural key.
Of course it has to be a natural key! Are you expecting that users will learn your theoretically perfect surrogate key? Do you understand that you will be competing for space in people's brain? For what reason? Because shared email accounts break the many to one relationship on mail <-> person?
I'm not sure why users should ever need to know the key.
> Because shared email accounts break the many to one relationship on mail <-> person?
No, I probably wouldn't even both with addressing the problem of shared email accounts (which would require some discriminator), but with one person having multiple email accounts and email accounts changing over time. These things indicate that accounts should have transitory, one-to-many relationships to email addresses, rather than email addresses serving as a key.
The only requirement for the email to be a key to the account is the association of one email to one person. A person can have more than one email, at different times or at the same time. The only thing that can't happen is one email mapping to two individuals. Full circle: the majority of emails do map to one individual and the cases where they do not map, are not enough to preclude the use of emails as keys.
Perhaps the confusion occurs because you think I'm defending email as a primary key for the account. I'm not. It's one key, not the primary key.
It's a hard problem because anything real world like a identifying number is flawed for anonymity. There needs to be a unique identifier for a web entity.
It's always annoyed me that solutions like persona etc are approaching this by simply replacing email, when shouldn't they be abstracting my online identity? I hold several "personas" throughout various sites, email addresses, and applications. However, I don't want a product that simply merges them, I want a product that is more of a "meta-persona", that lets me easily track, manage, and expand them.
"It maps multiple emails to the same identity, in that you use the same password to log in with all of them. The end site gets the email you log in to the site with (I can log in to Persona with email A but let all sites know email B every time."
So based on that, if you want to expose three different identities to 3 different sites, you can set up Persona to do that automatically, without having to remember the separate emails and passwords you used for each one. I guess the only problem would be if you needed multiple separate logins to the same site, but unless it's your own site, presumably that should be rare.
If a user does change their email they can log in as their old email and simply update their account to their new one.
Email is a much better system than username because people constantly forget the unique username they created for that specific site. You don't really forget your email very often.
If you're stupidly using your email as your username then your email becomes public should the site you're on show, at any point, your username.
Which is why sites correctly done use the email for login but display a username and never your email. Correctly done sites also forbid username from containing '@', so that you can be sure that people don't do anything retardedly stupid like using their email as username, which would be displayed publicly on the site...
Most of the website, do not just ask Email. Most ask other info too, like my DOB, full name, Other Profile information. And when I say I "do not use", I am talking about the first time logins of course. I don't really know what kind of a website it is, legit or just a vapour. And I do not know in advance what information it will ask.
Take the example of The Old Reader, till recently they wanted to take control of your Contacts too(along with Reader; now they don't). I knew it once I was at past the Google SigIn page(and I aborted right there). It was frustrating even for those few seconds. Many do this.
So, I have given up on them altogether.
I mean I have OpenID accounts set up especially for this with the data I would like to provide for this. There Mozilla's Persona(it's Identity Management System)- etc. Why not use these?
And do not even get me started on Facebook. I don't open a website again if the only way to login was via Facebook. Paranoid? No, rather pissed off. (By the way, whenever I tried using Facebook logins the above mentioned problems surfaced only in bigger multitude).
Just because you use OpenID and Persona doesn't mean that the majority of people will. But the majority of people will have a Gmail account, or a Facebook account.
As a disclaimer, though, I've worked on highly specialized apps where the users belong to a certain organization bound by one of the above. For example, I made a website for my school and every student there has an email address that is tied to that school's Google Apps for Edu account, so I'm guaranteed that all valid users (students) will be able to log in via Google.
Did 20th century humans think key rings were too complicated? Why are we implementing tokenization, one way hashing, etc. when the end customer can do this much more securely? Oh yeah, we'd like to get at their data when they're not around..
Schneier wrote a long time that anything too complex cannot ever be secure. That's the case of OAuth and of many federated/unique/single sign-on logins.
We did it in a way that's completely independent of our normal email/password login as well, but integrates seamlessly. That made me really happy, as the reliability of our system hasn't decreased a bit.
The Persona team was also really helpful, though it turned out we didn't need much help implementing it.