Open Letter to Mozilla: Bring Back Persona
stavros.io
stavros.io
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.
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.
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/.
These days I prefer to require an email address. That way, the few users that want to opt-out can insert a bogus one.
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")
Another Thunderbird user...
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...
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.
Or worse, the moment they start abusing their position as your identity provider?
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...
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 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.
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.
But I agree, some users would rather cut out the middleman than be chained to the social network du jour.
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.
- 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?
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.
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.
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.
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/ )
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.
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, 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.
I was very bullish on Persona early on, but the fact of the matter is, we failed. And not just because (as I feel is being implied) some higher up suddenly came over and asked for an unreasonable amount of adoption for a revolutionary product.
We failed for a thousand reasons. It should've been supported directly within the Firefox chrome ASAP. It had branding different than the site you logged in to and was in a popup[1]. It took the name of another Firefox feature that users already knew about. Because the team was experimenting fast, the code quality of the service was such that outside contribution to it (or even cross-team contribution internally) was hard to impossible. There was no (or very limited) metadata available for things like a shared avatar or display name.
We had enough time to do these things, but we didn't. The team accomplished something really amazing, but it wasn't enough, and most importantly, putting more effort into what already existed was not going to work. This idea that Mozilla can just turn around and throw effort at Persona and make it win now is, IMO, wrong.
Identity needs more experimentation, that much is certain. But harping bringing back Persona in particular is beating a dead horse. We need a successor or a new project.
[1] Not only did this make Persona look incredibly sketchy without a lot of priming users, it had a major privacy issue of leaking your identity provider and relying party to Mozilla via a centralized iframe we host. A mailing list thread among the Persona devs and community failed to find a solution to this.
Aw :( Do you think these problems can be solved with an extension or a different protocol? How close were you to a solution for this?
"gaining traction as an identity provider" being the hard part, of course.
That's also why I mentioned in my other reply that I'd be willing to help a project that has a chance to succeed - and that means being lead by someone who has themselves learned all the lessons from Persona. Someone who was on the original dev team.
But this also needs backing from Mozilla, or a corporation like mozilla (there aren't many).
While a lot of devs, including Mozilla devs, agree that Persona needs a successor... there's no sign of any such backing.
Because this is so important maybe it should be left to just one entity to run. Ideally a federated identity login thing should be backed by a plethora of orgs.
Let's make a list?
Redhat, Linux Foundation, Raspberry Pi, Ubuntu, Mozilla, LibreOffice, Eclipse, GNU, ... ?
Would doing that alone have made Persona a success? Probably not. But as it is, it's not even in the running.
(Context: I wrote my own IdP, so in theory I could have been on that happy path.)
Did you read the post? This is exactly what the OP said:
> I was very bullish on Persona early on, but the fact of the matter is, we failed.
That could have been fixed, and could still be fixed.
> It had branding different than the site you logged in to and was in a popup[1].
That could have been fixed, and could still be fixed.
> It took the name of another Firefox feature that users already knew about.
That could have been fixed, and could still be fixed really, but it's pointless now.
> Because the team was experimenting fast, the code quality of the service was such that outside contribution to it (or even cross-team contribution internally) was hard to impossible.
That could have been fixed, and could still be fixed.
> We had enough time to do these things, but we didn't. The team accomplished something really amazing, but it wasn't enough, and most importantly, putting more effort into what already existed was not going to work. This idea that Mozilla can just turn around and throw effort at Persona and make it win now is, IMO, wrong.
Why wouldn't it make it work? Persona was only alive for 2 years. It saw slow adoption, in part due to usability issues. If you fix the usability issues and give it more time, why wouldn't it be more successful? The issues holding it back were not fundamental. In fact, the fundamental design of Persona was sound and worked very well.
Now, yes, merely fixing things and making the project supported again won't make it more successful overnight. It may need rebranding, it may need a lot of promotion, strategic partnerships, etc. But to declare it completely dead and waste effort on recreating what you already have is silly and counterproductive.
Persona already has many sites - and people! - using it. It already has some (limited) brand recognition. It already has a solid protocol and design, a working codebase, a hosted service that is usable.
The hypothetical successor to Persona? It has none of this. A hypothetical new approach? It has none of this. Could that change? Sure, but you're still starting from zero, and you have to re-do everything.
But why start again when what you had wasn't fundamentally broken?
> We need a successor or a new project.
Why? What could a successor or new project bring that Persona couldn't?
Can you elaborate on this?
Basically, Persona by design needs to transmit a keypair and a signed certificate between the identity provider and the relying party. Without in-browser integration, the way this was done was using localStorage on the login.persona.org domain, making Mozilla a trusted third party. This was deemed okay as a temporary measure until in-browser support for BrowserID became commonplace, replacing the trusted third party with the user-agent.
Reading the thread again, my memory was a little off: possible solutions were proposed, but the conversation fell off before consensus could be reached, and no one had the time to drive any attempt to implement the change.
I mentioned this by email, but I'll repeat it here:
I believe in the design behind Persona. I believe a well structured, free authentication provider, is one of the core pillars of a free web, which is exactly what Mozilla claims to stand for.
I believe in a free web and I'm also willing to put my money where my mouth is. I'm ready to pledge not just my money but my time. I am willing to volunteer my skills as a developer, UX designer and my experience leading FOSS projects to Persona, or a Persona-like project that has a chance of succeeding. If you are involved in this, feel free to email me (see my profile for a point of contact).
I invite others willing to do the same to say so here.
For people not in the loop: I would also like to pledge my time in developing a Persona or Persona alternative. I'm just a bit apprehensive on such a project's chances if it weren't backed by a big company like Mozilla. Then again, maybe we should just go for it.
Email providers don't have significant incentive to become Identity Providers; Web site owners do not have significant incentive to accept persona at least until many users adopt/request it; Users are mostly unaware of Persona's existence and the argument in favor for many is rather weak as the people who seem to care about privacy seem to be in an exclusive club.
There are a few keys to success that I can think of off the top of my head:
1. Solid awareness campaign to explain benefits to non-HN type users. Would depend on solid benefits of security, convenience/simplicity, and privacy.
2. Fantastic "default" identity provider as most email providers will not, in the short term, become Identity Providers. This has to work without sacrificing UX, security, convenience/simplicity, and privacy.
3. Adoption by at least 1 major email provider (e.g. FastMail).
While I don't bring much in the way of development skills (not my strength at all), I would be very willing to help on the strategy, partnerships / business development, marketing etc. front.
The recent generalized effort is Moonshot/ABFAB (https://jisc.ac.uk/assent), which I think has made disappointingly slow progress.
I happen to be quite good with Node / JavaScript and I will happily help out.
Anyone who wants to see how easy it is to deploy (JS on your page, a button, and callback verifier on your server): https://developer.mozilla.org/en-US/Persona/Quick_Setup
Anyone who wants to see it in action: https://www.lfgss.com/
I love everything about Persona except for the fact that Mozilla are no longer supporting a team around it, and it was given to the community in almost an abandon-ware fashion.
The idea that this could have made an impact faster is laughable, choosing an auth provider is such a slow process requiring considerable points of trust to reinforce it... one of the most significant points of trust was Mozilla itself, but it also needed a social reinforcement as more people adopted it. Mozilla didn't give Persona the time it needed.
My criticisms of Persona are nothing to do with the fungible nature of email as identity, which I think is OK enough in principle (it's no less identifying than anything else and changes less frequently than a phone number), but to do with:
1) The way Persona wants to centrally log-out from all sites, when a user's experience is that they can sign-out from one site and remain signed-in on another.
2) The lack of 2FA in the default instance they shipped/supported.
3) Some of the phrasing and language confuses users, especially after changing to Persona. i.e. They were still a user on my site identified by email address, but Persona would declare that they were not recognised... so I'd have to spend time telling the user to ignore that and sign-in anyway.
The core product though, was exactly what the web needed, and exactly what I needed for all of the sites I run.
1) That is completely controlled by the site owner. In my sites, for example, I just disabled the Persona JS while the user was logged in, so there was no global log-out possible.
2) I believe the bridge was just a proof of concept, with the intention of email providers supporting Persona directly so all the security could be implemented there. I know you said "default bridge", but my side-project here supports 2FA: https://persowna.net/
3) That is very true, some UX changes were necessary, but imagine if the browser itself could just pop up a window saying "do you want to log in to this site using your email address? Yes/No", done.
Actually marginally better than Gmail, for me, because with Persona, I understood which address I signed in with, at lfgss.com. Gmail, however, doens't let me know which account I sign in with, if I'm logged in with just one of my Gmail account. Then Gmail silently assumes that's the account I want to use, although it might not be. Persona, however, clarified which Gmail account I was using.
I don't have a FB account and don't use my Google account a lot. I should really delete the latter.
But it would be so much easier with Persona. Yes, a lot of sites won't adopt it, at least at first. But with a well supported alternative that I want to use, I'd have an easier time to say "fuck it" and close the browser window.
Right now I'm trying to go for the next best thing: Different accounts per service (vs braindead "Log in with Silicon Valley Corp").
Alas .. Persona would simplify my password store a LOT. I'd back a campaign. Not sure if I could offer hundreds of dollars, but let me state here that I'd find a way to add 50-80 right away/as an incentive to adopt the project again and I definitely would be able to contribute a recurring amount (a la Patreon etc) for the ongoing development.
https://news.ycombinator.com/item?id=7243172
(By the way, I am going to try to avoid wasting even more of my life arguing on Hacker News about the benefits or lack thereof of Persona, so I am dropping these links here to maybe seed discussion among others, but I am going to attempt to avoid ruining my Christmas Eve by forcing myself to never look back at this particular thread again ;P.)
Also, for anyone wondering if I have anything credible to say on this subject before bothering to read any of this--and maybe to the one person who downvoted me from 3 points to 2 points, which I noticed as I fleshed out the "I will hopefully leave" message ;P--I have run a service with tens of millions of users that only uses federated login (though accounts are optional, so I "only" have just over ten million accounts on file), and have been staring at this space since 2001, when Microsoft announced Passport (at the time, I even was thinking of starting my own single-sign-on service, but was a naive college student ;P).
(later edit: I found another old thread on this subject that I am going to add here as an edit, mostly because any other way of adding it might cause me to see if there are any responses to this comment ;P. At the time, to this new link, there were two responses I hadn't bothered seeing and responding to: one from someone who insisted upon comparing the fundamental bug in Persona with an existing "worst practice" (as opposed to any of the better alternative options), and one who seems to be in left field assuming the value of a Facebook account is based on whether the user updated their email address: the point I was making is that Facebook isn't actually tied to email addresses, as they "understand" the problem inherent in relying on them for anything, and so users do not run into any of the issues that Persona not only doesn't solve but actually makes worse. Regardless, yeah: even without reading any comments from today I am already spending way too much time at this ;P.)
I think it would be highly useful to have a successful open standard for this not controlled by a commercial third party with a financial interest in the implementation.
To the point on account recovery and its pitfalls, any argument that reduces to "System A is better because (in my opinion) those accounts are changed/deleted less often" seems like handwaving. This argument can make any proposal the winner, I myself have no hard data on account churn for any major service, although I accept that email accounts are probably higher turnover than services that introduce user lock-in ... by things like supporting a single sign-on (i.e. Facebook Connect). But WHAT IF an authentication system relied on email accounts, for example. Perhaps users would then be motivated to maintain such accounts for the purpose if it being their auth key.
Finally on the topic of recovery, many services already support the use of a mobile number for this, since these are portable. Implementing this as part of a Persona implementation would seem to address the 'I/someone else threw away my key" problem.
persona.advocacy@librelist.com
http://librelist.com/browser//persona.advocacy/2015/1/24/the...
You can subscribe by sending an email to (first message is ditched):
persona.advocacy@librelist.comIn retrospect, I think that Mozilla made a mistake by centralizing the fallback identity provider. The fallback provider was just a temporary edifice to bootstrap the protocols; it didn't have to be run by Mozilla. Every website could have run a small stack which remained fully self-branded and would only verify email addresses for its own purposes.
I understand why Mozilla took the route they did - centralizing the fallback provider eased the RP implementation, made it possible to rapidly rev the protocols, and in theory made it more convenient for users since one Persona password would work across multiple sites. In practice, however, users were confused about the extra branding and the vague sense of logging into Persona so you can log into a site. More critically, it made the whole project depend on the whims of Mozilla - it's not just software we depend on, but infrastructure, and without Mozilla's support the infrastructure will eventually die.
If Persona is revived, I hope it becomes a complete software stack that every RP can run independently. The fallback IdP should be 100% branded by the RP so users are never confused about what site they are logging into. And as non-hosted software, it should be able to live and evolve as open source software without fear that some tepidly supported server will go down (or simply fail to evolve). IMHO, this is the only way that Persona (or at least the auth standard, which is what we care about) can survive long-term as a community project.
What killed Persona was not tech but the lack of traction. Developers loved it but failed to use it. By providing options such as FB, Google, Twitter and other logins, the user choose the familiar service and never tried Persona. In the end, the lack of traction together with the overall difficulty of building federated identity services killed it.
But what is dead cannot die! Persona still works, I still use it every day in lots of Mozilla properties and if I had to build some service that required logins, I would use it even today. It is in the hand of the community but with some care and more traction this can become cool again.
I will look into the source code and see if I can help somewhere.
This implies a classic chicken/egg dilemma: email providers won't implement Persona support unless that would be useful for lots of people; Persona wouldn't be useful for lots of people until their email provider supported it.
The idea was always that Mozilla would ship native integration in Firefox. There were very very pretty mockups going around and everyone was holding their breath for that to happen.[1] Even announcing they would ship it in the next version would mean 1) it’s stable now and 2) Mozilla is behind it.
My guess is Google (their sponsor at that time) made them drop it because they were preparing to launch G+.
I know it’s a conspiracy theory, but it frankly makes more sense than all those other non-reasons I keep hearing about in this thread.
[1] http://www.extremetech.com/wp-content/uploads/2011/07/firefo...
Try https://pastery.net, log in there. If you have a Gmail account, you'll just click "accept" and you're in.
I don't want Google (or God forbid, Facebook) knowing what sites I login to and part of my credentials, and I don't want websites to know my email address.
I know you say they don't have this information, but it's not hard to get access to it if they feel they want to. Google Web History already creeps me out :-)
I also feel more secure with different passwords (and even emails) on different sites.
You know that you can turn off most of their tracking by doing a privacy checkup? I can't guarantee that they don't know a lot about me and that they're still not tracking me, but I can guarantee you that my Google history is completely blank.
USE TOR BROWSER FOR BROWSING. DON’T STAY LOGGED INTO GOOGLE. Anything less is just a waste of time.
And seriously, Tor in 2015 is fast enough for 1080p h.264, there’s really no excuse.
[1] https://nakedsecurity.sophos.com/2011/10/20/law-student-trig...
The protocol makes it impossible for the identity provider to know where you're logging in, so they can't even if they wanted to, really.
Now, I'm seeing indications that Mozilla is working on implementing FIDO U2F support (“Mozilla’s commitment to add FIDO U2F support to the Firefox browser”).
https://www.yubico.com/2015/12/2015-was-a-yubico-rocket-ride...
That seems like a much better approach to improving the situation around authentication and passwords than Persona was.
Yes. Mozilla has helped bring a large number of Web-related standards while maintaining consistently high privacy and security requirements.
Note that Persona isn't a one-central-service system, though. You can have a ton of identity providers, assuming they all follow the same standard. You do need one service to get started, however.
Persona is an inherently bad protocol that continues the unnerving trend to shift the concept of identities from something that's owned to something that's merely leased and temporarily granted.
It's better than "Login with $Provider" in a sense that $Provider doesn't get the data, but it's equally worse in a sense that $Provider still owns your identity.
I wrote about it here: https://news.ycombinator.com/item?id=10595347
It seems from the other thread that you believe WebID to be a better alternative to Persona/BrowserID. How practical and usable is it right now, and what key advantages does it offer in your opinion?
There were some attempts like WebID and gpgAuth, but none is usable at the moment. They have to be dug out of dirt of oblivion, carefully analyzed and improved with important features they're missing to be usable for ordinary people (at least key escrow and sync - both completely optional, of course).
What I want from authentication system, is complete independence and full and ultimate control and ownership of my own identity. I don't want to trust, depend or even need any third party just to have account with someone. Not even if this third party is a domain name registrar, not even if I have a legal agreement with them.
When we had just usernames and passwords - it was exactly like that, except for mandatory emails thingy (but that's another story). I met someone, we introduce yourselves, negotiate a shared secret - and we're now acquaintances. With OpenID/OAuth/SAML/JWT/Persona this is no more the case - we have to call a notary and the notary will tell us who I am. And I really don't like this and want to see this fixed.
I want to revoke any possibility of any third party to revoke or otherwise deny my identity. They may assert my identity (say they know me and I'm a good lad) and revoke their assertion about my identity (i.e. say they don't trust me anymore), but not the fact who I am.
I'm not so sure I want to do that. The point is, even that single Fort Knox can be breached at some point, and if it is, then everything is lost.
I agree that nowadays, email is almost unanimously the way to verify a password reset, and hence all your eggs are already in one basket, but shouldn't there be further protections?
A few of the major webmail providers offer two-factor authentication, so that's one option to enhance protection. Here's some information about how to enable it for Gmail, Hotmail and Yahoo Mail:
https://www.google.com/landing/2step/
http://windows.microsoft.com/en-gb/windows/two-step-verifica...
https://developer.mozilla.org/en-US/Persona/Protocol_Overvie...
It's exactly as secure as the "Forgot my password" reset nonsense, but streamlined to be way easier on the user. Then you only need one password: the one to your email. This removes the need for Persona to "add support" for different email providers. Your provider doesn't matter, just the fact that you can receive emails!
I'd really wish more sites would just do this anyway. For instance, every time I get an analytics daily report from Fabric.io, I click the link in the email, and it asks me to login. WHY ARE YOU ASKING ME TO LOGIN, WHEN I JUST CLICKED AN EMAIL YOU SENT ME? It's obviously me!
Browsers should do something similar: provide a storage for private and public keys as proof of identity. But they should additionally provide a way to sync those identities across multiple browsers and machines. This latter concept will be familiar to anyone who has used LastPass. The former, well it should basically be a dropdown with your identities, and you choose one before clicking the "Login" button.
It's not a very intuitive mode of authentication, but if the UI was improved, and combined with a sync service (& encrypted with a passphrase), I guess it could be usable? (also, presumably it requires the site to use https, but that's also much more expected today than it was 10 years ago)
So foo@bar.com may or may not have any MX records, all that is required is that bar.com can provide an assertion that you control foo@bar.com.
The way bar.com determines that is entirely up to bar.com, it can be a password, smart crypto card, local kerberos or Windows auth, 3-way auth involving your cat Rufus, etc...
https://developer.mozilla.org/en-US/Persona/Protocol_Overvie...
No, the right solution is to stop using email as sole identification for password resets. Yes, there are other solutions you can implement right now without waiting for some big company to save you.
The most obvious one it to create a second factor of authentication just for account resets. It could be via an SMS OR simply by asking user to print out/write down a special randomly generated "reset" number.
"But SMS costs money!" No, for most providers you can send an email to a special address reserved for the phone number. It will get translated to SMS automatically.
"But users will forget/loose their reset number!" Maybe, maybe not. It's a cultural thing. You don't expect them to loose access to their email, but that happens all the time.
"But users will forget/loose their reset number!" Maybe, maybe not. It's a cultural thing. Really? Can you cite anything here that indicates this is the case?
Users treat email access differently, seeing as how it's bound to user identity, usually across dozens, if not hundreds of services.
That's mostly an US-only solution. In most countries, there's no free email2sms gateway, since our incoming SMSs are free.
Also, I don't want to share my phone number with you, random Internet site owner. Email spam is worse enough as it is.
"But users will forget/loose their reset number!" Maybe, maybe not. It's a cultural thing. You don't expect them to loose access to their email, but that happens all the time.
They won't lose or forget it; they just won't save it in the first place, except maybe for a couple of very important sites. If people don't use password managers, what makes you think they'll manage some database (physical or not) of reset codes for each site they register for?
- Is it technically possible to create a Bash/SSH integration? The Linux world pretty much has SSO now, it would be an awesome argument to have this and Persona extend each other.
* https://hacks.mozilla.org/2013/04/mozilla-persona-for-the-no...
Persona is just a way for your email domain to say "yes I know this person". The way the site does that doesn't matter to Persona, and there was a service similar to mailinator that just let you log in with a disposable email address everywhere, with no other authentication.
It's not just a bunch of dudes in their basements writing code. They have like $330 million in annual revenue. They are sitting on like $90 million in cash.
Mozilla isn't about software for its own sake or just for the sake of the web. They are about self preservation and Persona wasn't going to keep them alive, so they killed it.
Mozilla is a company. That is what companies do.
EDIT: Here's a quote from the Mozilla Foundation homepage (https://www.mozilla.org/en-US/foundation/):
"Many of Mozilla’s products are developed by the Mozilla Corporation, a wholly-owned subsidiary of the Mozilla Foundation. The Mozilla Corporation functions as a self-sustaining social enterprise — money earned through its products is reinvested into the organization."
Mozilla absolutely is the right kind of organization to try to attack this Gordian knot.
Mozilla is right in the sense that they're independent and a not-for-profit. But they're also small relative to the other players, with more limited resources. They also just don't seem to be very good at politics and/or building business partnerships.
In particular here they seemed to solve it as mainly a technical problem. They apparently launched it with the assumption that its existence alone was sufficient to generate uptake, which even at the time seemed naive to me. And then after a while they shrugged, said, "looks like it doesn't work" and closed it down. That doesn't seem like the right organization to me.
If so, the difference is that Persona works with whatever email address/account the user already owns, just like plain email/password authentication; they don't have to figure out that they need to create an account in some "identity provider", which then gives them an URL to copy-paste into the site.
I don't see other browser vendors implementing Persona before (if ever) it is an otherwise widely accepted thing.
How could they have possibly succeeded in that timescale? They seem to think there were flaws with Persona, and that's true, but those flaws could be fixed. Making a few mistakes on an attempt doesn't mean you should kill it off if the basic product works well. It means you fix them. Starting a new Persona is silly, Persona itself works.
Why can't they just focus on what people value them for, web browsers and privacy?
I liked the article, but this is not true - if a service gives out password reset tokens or log-in-via-emailed-link tokens, a breach of your e-mail will still require a reset on that service. Even in a fully Persona'ified world, such tokens are likely to exist for at least some services.
Then the site emails you anyway. (If you didn't want them to, you shouldn't have given them your email address).
This would be a win-win as this could help AppleID and TouchID becoming even more central for your users while demonstrating at the same time that you care about privacy and are willing to develop an open standard to support strong and distributed identity management system as an alternative to Google and Facebook centralized and privacy unfriendly solution.
Of course domains aren't as popular as email addresses, but OpenID used domains… This is like OpenID done right.
It was super easy to integrate, better UX in my eyes, but Mozilla just shut it down for some reason. It died down.
I hope they assign more resources to it. I hate having Facebook sign ins on my website.
Now we use Authentic (https://github.com/davidguttman/authentic). In some ways it's better (e.g. get to control your own UI/UX flows), but it would have been nice to just have Mozilla run/host everything.
Is there any official statement that Persona will shut down?