Not to take away from your overall point, but you can still very much use persona: https://developer.mozilla.org/en-US/Persona (linked from https://login.persona.org/ )
https://groups.google.com/forum/#!topic/mozilla.dev.identity...
I'm part of the team that runs the production service of Persona, and I can confirm it is operated, monitored and managed like any other critical production service today.
Now that 1st party browser certificates are available so you get that Trusty-Green-Lock(tm) on all browsers, geeks can theoretically run their own identity service based on some sort of combination of these technologies. (Ideally with the long term outcome solving the "Why Johnny can't have Crypto" problem, maybe using a cell phone app as an RSA SecurID type dongle.) This also has the benefit of letting you authenticate against your bud John's Identity Server, rather than Go-fuck-yourself-Fred's (you'd need token negotiation in there somehow though).
Someone smarter than me (DJB where are you?) should piece this together, release it as open source for the end-user, and fund it via expensive Exchange module integration.
The article brushes aside the "no traction" bit and says, basically, "the idea was awesome". But that's why we test ideas and measure them by results like traction: not all great ideas turn into great products.
Persona as deployed was an appealing idea that did not provide a great user experience (or really, a great developer experience). To fill the gap, you need to A) deliver lots of value, or B) target an audience that has some special motivation (e.g., idealism) to use the product. Persona did not do A, and general-audience users definitionally lack B. A site's developers might have that motivation, which is why some people tried Persona out. But if the users don't share the motivation, then to them it's just a low-grade experience.
If Mozilla wants to go after the identity market again, they need to do something different. The obvious thing to do would be to leverage their browser market share and make something lower friction than existing systems, rather than Persona's higher friction. But since this is an obvious idea and there are plenty of smart people at Mozilla, I presume there's some good reason they didn't do that in the first place.
http://www.extremetech.com/wp-content/uploads/2011/07/firefo...
Another Thunderbird user...
For me those big fat "sign in with google/facebook" buttons are an annoyance when it takes several clicks to get the old-fashioned account management. Some sites don't even have an option to not use a 3rd-party identity.
Not everyone has google/facebook.
I use gmail, I have no problem trading my info for goods and services - I know what they're realistically worth and judge accordingly.
But for Fred's Arbitrary Website? Go fuck yourself Fred, I'll hand over exactly as much information as I like.
They'll add your new usage patterns to the database they've been building about you for the past decade. They'll correlate your behavior with other users of Fred's arbitrary website.
But I agree, some users would rather cut out the middleman than be chained to the social network du jour.
A username/real name can still be used as the "name" if this is an online community or something similar.
It may not sound like a big distinction, but there is a big distinction there. Instead of your username being your email address, they've abstracted the authentication from the core user record such that usernames are not used for authentication, so don't have to mutate if the authentication identifier (email address, phone number) changes, just some auth settings. This is obviously a much more extensible and robust way to deal with authentication over time, but it's also obvious it's much more complex than a simple username/password pair.
Re: implementation - I don't see the big distinction. These are all just related properties of a master user id number. Those properties can be anything and any of them (in any combination) can be used to login.
Nope. Most free email providers out there (including gmail) have policies for username expiration, some even quite aggressively (like one month without login). "Me" on one of these services might not be "me" in three months' time, but you-website won't know that and will happily send a password reset link to my old email.
Really, they do.
Same with another site I was on, except the usual solution was seemingly 'find one of the staff on another site they're a member of and send them a message there'. Made for a nice security hole too, since people could (and did) impersonate others and get given their accounts as a result.
You need some sort of email (or other contact information, like a phone number) simply so people can get their account details back in a semi secure way.
These days I prefer to require an email address. That way, the few users that want to opt-out can insert a bogus one.
With an on-site "Contact Support" form, you can at least compare their IP address with historical login addresses. But that comes with its own weird problems like, for example, a sibling claiming their brother's account from the same household to read their juicy PMs or steal their credits or whatever. Or giving moderators access to more sensitive information and power than necessary.
Password reset being "optional" just means that people are going to use your support system for it when they eventually forget their password or the initial registration session expires. Reddit and HN have optional email while your new website's only user just forgot their password without an email address on file. What are you going to do when they ask for help off site?
And by the time you're fielding SMS and Twitter handle password resets, you may wonder why you didn't just put more emphasis on the email address input field. Now you're polishing your SMS or Twitter handle reset system that has far more narrow appeal/usage than an email system.
Of course, at the end of the day, it depends on the type of service you're operating. But "make email optional" is a trade-off, not universally good advice. Spend too much time in the HN echo chamber and you'll just do things that work against your users.
People can opt out via http://10minutemail.com/.
In fact, most of our app users don't even have to sign up! They are invited via sms or email, and given a link that works like a capability. Clicking that link established an account for them and they get a full experience right away, complete with all their followers (people who uploaded their address books and had their number or email in there).
This is instant engagement of the user.
We don't even require a password for when they download our native app. We just go to Safari and do an OAuth 2.0 flow with our own site and give an access token to the app. That access token can be for 100 years.
They only need a password when their cookie expires or if they want to access the site from another device.
In that case, it's good to have asked for the email address or phone number in the beginning. That's the user's identifier.
Our system also works with Facebook connect, etc. but that's not the coolest part. The coolest part is having the user choose their own Qbix app as the identity provider to authenticate with, so they can visit new sites and they are instantly greeted by name, find friends on there etc. without the site knowing anything about them on other sites. That's the holy grail :)
I understand and I'll provide my email address, my JID, my phone number and whatever else I'm willing to provide, if I want someone to contact me. But contact details are technically completely unnecessary to just have an account.
If you don't want that, use Mailinator and forget about it. It's insurance against stupid support requests is what it is.
Lesson here for anyone wanting to use emails for usernames:
Make it really clear that you're asking for the email as an ID, as the username. Otherwise this will incline people to enter the same password as their email because they think they're asked to log in. Even if they know it's important not to re-use passwords over different logins.
To make this anecdata N>1, I teach computer stuff to kids (ages 8-12, generally) and they tend to make the same mistake.
(working on semi-public computers, I am glad I get to teach them about Private Windows: "if it's not your computer, only enter your password on a window that shows the little mask/sunglasses-guy")
I know of an easy way to remove 33% of that ...
Email addresses are globally unique, and everyone already knows theirs ... email + password seems like a simple, well accepted and workable solution.
Right ?
My appleId has an @mac.com email address which means it is for some reason immutable - I can not change my address. Jobs only knows where emails from apple to me end up, I really don't do much with my appleid anymore other than re-authorize the appstore every month when I need to update xcode.
For a couple of service-oriented sites I'm working on, which won't have forums or public issue trackers, they only use email address (which is change-able). But, it's just not an option for my primary business website.
I think you're underestimating the importance of Facebook information towards making viable free content. The basic, accurate information you receive from the FB SDK really helps salespeople identify qualified leads for trial-to-paid conversions; the info also can be used to tell you what other websites people visit or software they use. This really helps make sales and improve your software in a way that seems generally net positive for consumers and producers.
As a website operator, these are no longer your users, they're Facebook's users, and Facebook can take them away from you at any time.
As a user, these are no longer your website accounts, they're Facebook's website accounts, and Facebook can take them away from you at any time.
Putting Facebook in complete control of identity is not healthy for anyone. At least when you get email addresses from Facebook, you can bootstrap an independent relationship with your customers if necessary. From the user's perspective: If Facebook blocks your account, the website operator can still validate your ownership with the email address.
Have they actually done that to any website? That would undermine their whole system. They'd do that once and everyone would leave their service. That's like saying "Well Google could publish all your emails! So you definitely shouldn't trust your emails to Google"
Facebook frequently freezes user accounts for all sorts of reasons. Maybe their name doesn't exactly match what's on their state issued ID. Maybe the art nude selfie they posted pissed off the censors. Maybe they expressed an unpopular political opinion. Maybe their name matches somebody on a sex offender list. Maybe they just got tripped up by an over-exuberant fraud bot.
I remember when Microsoft was the good guy and IBM was the bad guy. Things change.
I generally consider this kind of information warehousing and sharing unethical. While I understand the business case for it, and I understand that facebook has permission from their users because of the ToS agreement, I don't want to inflict it on my customers (who are often Open Source and Free software nerds who take their security somewhat seriously). I am a facebook user, but I don't like what facebook does to privacy. Google, same story.
So, I view participating in those login systems as low-grade evil, as it contributes to the incredible stockpile of data facebook and Google have about all of us. I don't make a big deal about it, and I use sites that require it, but I don't have to like it. And, if there were a way for me to provide a similarly nice user experience to my customers without invading their privacy in any way, I would do so.
>The basic, accurate information you receive from the FB SDK really helps salespeople identify qualified leads for trial-to-paid conversions; the info also can be used to tell you what other websites people visit or software they use. This really helps make sales and improve your software in a way that seems generally net positive for consumers and producers.
but does nothing at all to protect your privacy.
> And yet it's hardly adopted anywhere.
That’s because it’s Public Relations. Just like their TOR gateway. Just like Zuckerberg’s LLC “charity.” Just like everything else they do[1].
“Steps in the right direction” is the signature move of modern corporate PR.
[1] http://thehill.com/policy/cybersecurity/258060-advocate-accu...
Or worse, the moment they start abusing their position as your identity provider?
>Now, here's the sad thing, for me: I didn't even know Persona existed until its demise was being discussed on HN and reddit. Persona is exactly what I want for my users and my sites; and for my own use of the web.
That's the biggest standout for me as well. I've been /looking/ for a technology like this. Not looking very hard, it must be said. Ok, maybe it's more accurate to say I've been saying for years someone should make this without ever googling to see if someone had.
But how is it that in 3-4 /years/ of me discussing this with other developers every time we bring up account systems, no one has said "oh yeah, persona does that!". Did Mozilla not advertise this at all? The lack of mindshare is staggering.
Why not just 'log in with email address'? The user provides his email address; you send him an email with a URL of the form http://www.invalid/path/to/resource?access_token=aSBkb25lIGF... (where aSBkb25lIGF1dGhlbnRpY2F0ZWQgdGhpcw is a cryptographically-authenticated account identifier). When he follows the URL, you can set a cookie if you want him to be automatically logged in next time he visits your site, or not if you don't.
Extending this to be one-time only (to prevent replay by an email provider) is an exercise for the reader.
I enjoy that you offer up a quite complex, confusing, often insecure, and error-prone methodology with this phrase.
Seriously, this sort of thing is not complex, not at all.
- I'm logging in from a new computer. Maybe a computer I don't trust enough to log in to my email (which controls nearly everything, as you note). Not all services are that important or need the same level of care as email.
- I'm a user that has greylisting enabled on my mail server, potentially delaying the email for several minutes.
Confusing:
- I'm a user that has never seen/used this authentication workflow. While user/pass is annoying, it is widely understood. Sometimes "ease of use" is really just "what I'm used to". Thanks to facebook and Google authentication, the "Login with..." button is now "what I'm used to". I've never seen the authentication method you've described in 20 years of web use, except as a password reset method.
Error-prone:
- Implementation would have to be done by me on all of my sites. There is no off-the-shelf plugin for this for Drupal or Wordpress or Mediawiki, which run 90% of the websites I am responsible for. I could develop it but I am certain I would make mistakes in said implementation. I should be clear that I think any form of authentication is error-prone, unless it's already written and well-tested. User/pass and optional email is already written and well-tested for every site I maintain.
Security:
- It forces login to email to login to your site. This increases the risk of a user logging in from an untrusted computer or in an untrusted location to an incredible degree.
- Also, one can easily add security questions, or other second factor, to a password reset form, to make it more secure than your solution. Password resets are rare; happening every year or two, most likely. Logins are daily. One cannot impose those security questions on daily login form without paying the same annoyance price as user/pass (higher because it is unfamiliar). Cookies can mitigate this somewhat, but it doesn't solve multiple devices, and security-conscious environments that don't maintain cookies on logout.
If you believe this is an acceptable workflow for authentication, I won't try to stop you. But, it simply isn't a solution for my sites. I don't like user/pass, and I want something better, but I don't believe what you've described is something better. It's a neat idea, but not a solution to logins.
Neither are password-reset emails…
This is no more or less secure than sending password-reset emails; any additional security intended to protect in the case of password resets can be applied to login as well (e.g. SMS or landline contact, knowledge of shared secrets of varying security).
No, it's essentially the same thing as having a password-reset email sent to one, which is already the case for just about any account anyway.
> You're putting the responsibility of security on the email provider, which you can't control.
Your email provider is already capable of visiting a site, claiming to be you & claiming to have forgotten your password, then intercepting the password-reset email and resetting your password (about the only sites which require more than this are banks).
You can extend any flow which is secure against an evil email provider resetting a password to be equally secure against an evil email provider logging in. Obviously you could add an SMS code, which would then require subverting your mobile provider as well as your email; ditto a landline call.
- Shopping cart for selling our software and support products.
- Forums for discussing our software. Email notifications are available for users who want to follow threads.
- Ticket tracker for reporting bugs and making support requests about our software. Email notifications are, once again, available for users to follow threads.
- License manager, so that people who have bought our software can get the keys to download the software.
How would you suggest we accomplish those tasks without having a sign-in, at all?
Now, here's the sad thing, for me: I didn't even know Persona existed until its demise was being discussed on HN and reddit. Persona is exactly what I want for my users and my sites; and for my own use of the web. And, I didn't even know it was an option until it stopped being an option.
In short: I strongly agree. Mozilla has to focus resources on areas where it can have the biggest impact on privacy and the open web. This is one of those areas.
I hated to see Thunderbird dropped from the Mozilla roster, as it is my mail client of choice, but I understand where they're coming from. I hated to see FirefoxOS end, but I never got to use it, and it seems to have been doomed from the get-go by poor market fit and difficulty competing with the three biggest tech companies in the world in a market where money and influence play a role in which devices get into users hands. But, Persona is exactly the right kind of thing for Mozilla to be doing, and there's no reason they can't do it effectively, and without a huge amount of resources.