Hacker News new | past | comments | ask | show | jobs | submit login
Open Letter to Mozilla: Bring Back Persona (stavros.io)
905 points by stavros on Dec 24, 2015 | hide | past | favorite | 237 comments

I hate that the best user experience for logins is "Login with facebook" or "Login with Google". I don't want to impose that privacy failure on my users, but I also don't want to impose the annoyance that is "Sign up with a username, email address, and password". Offering all of the options is also a compromise that complicates the user experience.

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.

> And, I didn't even know it was an option until it stopped being an option.

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

> Defintely something to note for future UX designs... but Persona, the service hosted by mozilla, is being decommissioned in late 2016.


> In the event that Persona is decommissioned, we will provide at least 9 months of notice, so there are no actions that need to be taken right now. Persona continues to be monitored and supported, though there is still no new feature development.

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.

I’m sorry, wasn’t my intention to spread FUD.

Cool. I'll give it a shot. There is a Drupal module for it (I run Drupal on my current primary site, for now), though it only has 38 active installs, which is somewhat worrying.

From what I read (very very briefly), the spec is similar to what OpenID was, in that anyone who runs a web server can become an authentication provider. Ideally there'd be a distributed-hash-table type web-of-trust so its semi-centralized (i.e. somewhat like PGP or BGP routing tables where you peer with people you trust).

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.

I still run my own open id, but very few people support open id anymore. Slashdot removed support, shirt.woot removed support after the Amazon buyout ... The only thing I use that still supports it is stack overflow.

So I can have an authentication provider that is not an email provider and people can have accounts in my provider just to use them in Persona logins?

Yes, see https://persowna.net/. Setup is as easy as copying a file to your web server.

There is an Apache module too: https://github.com/mozilla/mod_authnz_persona

Having used Persona on my last project, I'd agree.

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.

The entire point of "Persona" is that it was actually something in the backend called "BrowserID" that was supposed to integrate with the browser instead of running some random JS widget in a page. Well, Mozilla never even finished implementing the first version of that before they declared "no traction"! What nonsense!

Having native code handle something in the browser instead of a thin, easily verifiable javascript widget seems the opposite of a more secure solution.

You’re missing the point. Emphasis on “in the browser” not “native.”


No, because javascript puts the server in control of the code being run on the client. It renders the whole thing vulnerable to nasty attacks like spoofing and MITM.

While I too would love to see continued development of Persona and Thunderbird by Mozilla, it's important to remember that as open-source projects they're still freely available. I still use both, and see no reason to stop. Development can continue without Mozilla.

I used it two weeks ago for a weekend project (shameless plug: https://www.pastery.net/, a beautiful pastebin), and it's just not the same. Feature requests go into the void, although the team at Mozilla was kind enough to answer even though it's not their job any more, but you can't really use it for a "serious" site while it's very unsupported.

Project rot is a thing. This is one thing Mozilla has been good at, keep projects alive and create network effect (well known name backup).

Another Thunderbird user...

> but I also don't want to impose the annoyance that is "Sign up with a username, email address, and password".

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.

And more importantly, signing in with fb is simply handing over our personal details.

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.

Really, Facebook/Google get the sweeter end of the deal. They'll know that you use Fred's arbitrary website. They will know when you use it, how often you it, and how long you use it each time.

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.

They already get that from Facebook like buttons on every single page

To be fair, Fred's Arbitrary Website probably only captures your email address, if that. OAuth2 permissions and the like.

But I agree, some users would rather cut out the middleman than be chained to the social network du jour.

Side note: usernames should just be emails these days, they're unique and save all the effort of needing another made up name.

Theoretically yes, but it's not as simple as that. Every identity can have more than one email associated with it, and emails can change over time. So "username == email" is fine as long as the concept of a username mutating is fine.

I don't see a problem, it just means you can login with multiple emails then. They're still unique to you. LinkedIn and Facebook and other services already do this.

A username/real name can still be used as the "name" if this is an online community or something similar.

LinkedIn and Facebook can do this because your email is not your username. There likely isn't really a username in those systems, just a user id. Almost all systems have a user id, but the distinction here is slightly different. Instead of a user record which has an id, username and possibly full name, Facebook likely has a user record with an id, a (display) username, and then there is a separate set of auth records with the multiple ways you can authenticate to the account, such as emails and passwords, API tokens, phone numbers, etc.

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.

You are describing the tripartite identity pattern: http://habitatchronicles.com/2008/10/the-tripartite-identity...

For the most part. My example was more a bipartite pattern, because I was covering the authentication aspects, not the entire identity structure (which I believe Facebook and LinkedIn would implement as the article outlines). For a system where you don't need to track multiple social identities, and where you interact within that system through your identity on that system, that's probably enough.

Yea maybe I should've been more specific but I was just talking about the user's perspective: usernames aren't necessary for most sites and just means one more thing they have to create and remember.

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.

What you're describing is "use a synthetic primary key for your User", which is something even the most naive junior web developer does automatically these days. There's nothing special about LinkedIn and Facebook except that they went through the trouble of adding additional authentication mechanisms. You can too, no matter what you treat as a "username".

I'm not entirely sure where you got the impression I was implying it was hard and esoteric, and only Facebook and LinkedIn could do so. I was simply noting that there's a difference between email as a username and email as part of one or more authentication tokens, and the differences in design and how it affects the possible future need of users to change what are often usable as authentication (email addresses, phone numbers, etc).

> They're still unique to you.

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.

Also, people share email addresses.

Really, they do.

That thought makes me feel dirty.

Many email addresses are dumb forwards without the eventual receiver (the "identified") even having an account directly related to the domain where the forwarding is done. Would those be usable for persona or only the "backend" address with an actual user login that collects forwarded emails and is ideally never given to a third party?

These are not unique to email addresses as identifiers, because people change over time. You can't even count on people's real names staying the same over time, as something as simple as marriage gives many an impetus to change it. Any database that assumes immutability of one's visible identity is broken by design.

Wouldn't a new email be as unique as the old one? I mean mutating is only a problem if usernames collide.

Services that don't require email for functionality shouldn't require email addresses at all. An excellent example of this is reddit.

Functionality such as "forgot password"?

Completely optional. Like HN for example.

So if someone forgets their login details, they're basically screwed? Because I've used some sites like that, and they're a royal pain whenever something goes wrong. For example, TV Tropes didn't used to have a password reset, so every time something went wrong, you'd pretty much have to either register a new account or bug someone on the forums about it.

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.

Agreed. Whenever I've made email addresses optional, it just means I can expect to do a bunch of manual "forgot my password" support. And it's hard to justify responding with "sorry, can't help you since you didn't input an email" when you're in the early stages of growth and your one active user's remember-me session finally expired.

These days I prefer to require an email address. That way, the few users that want to opt-out can insert a bogus one.

You can have a password reset feature, but it would be optional. If the person decides not to include their email, they would have to bug a mod who would maybe reinstate them. You could also use SMS or a twitter handle or even snail mail instead of requiring an email address.

It's not that obvious how to delegate out a task that involves giving someone full access to an account when they ask for it.

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

You'd rather share your phone number or home address than your email address?

Instead of hiding my identity from the site, maybe I'd rather hide my use of the site from my email provider.

They have access to every e-mail you send and receive, if you don't trust your e-mail provider to that extent you should probably change them.

I thought so too. But then people started forgetting their passwords, so i made email mandatory. People will rarely write down/take note of their password to a website that they "just want to check out".

If they just want to check your website out, why are you forcing them to choose a password anyway?

Indeed. People shouldn't have to choose a password the first time they use your site. Our login flow in the open source http://qbix.com/platform lets the user check out the site without having to go through signup -> go to email -> click confirmation link -> back to site -> choose a password -> recover context.

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

How do they prevent Sybil attacks and DOS?

Perhaps by limiting the rate at which password-free accounts can be created. If this limit is exceeded then the system switches back to creating user accounts in the normal way.

And what if they want a lot of users? How do they know which are legitimate?

w8, I had to provide email address?

What's the benefit? And, more than this, why do I must provide anyone my mail address? Why do I have to provide it at all?

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.

Password reset. Services need to identify you in another way to authenticate you that isn't your password.

If you don't want that, use Mailinator and forget about it. It's insurance against stupid support requests is what it is.

They don't need to identify me, they want to identify me. And throwaway emails are not a solution to the problem, they're just workarounds.

They need to have a way to reset passwords for people that scales.

I agree. We're doing this wrong. Airport "free" WiFi wanting to know my date of birth, and cranky weird crap like that.

And im just going to lie anyway. How many people tell the truth on those?

I do the same, but how long will it be until that's some sort of TSA violation that will get us on a list?

They are not necessarily unique over time. There's no guarantee that jrandom@example.com today is the same person it was a year ago or a year hence. Or in the case of services like mailinator, even unique at all.

It depends on the security needs of the service. Email addresses are discoverable making it easier for an attacker to target a particular account while usernames give the user the opportunity to further insulate themselves from being discovered on a service and potentially brute-forced or cross-ite attacked. Perhaps less important for a social sharing service and more important for a financial service, but it depends on the user.

Visiting my parents for Christmas, I helped my mom set up her new win10 laptop. (and she's real good with computers for someone her age whose job wasn't in IT)

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

Except that users are really bad at choosing strong passwords. A significant percentage will even use the same email/password combination accross multiple sites. For a site which contains sensitive financial or medical data, it is better to issue a 'username' that contains random characters. (This is the technique the UK government uses when users log in to pay tax)

That depends on context, of course. As an obvious example, if you're actually selling something, you very much do need to know the real name and possibly real address of the person you are contracting with.

Yes, I was only talking about usernames and how they're often unnecessary for most sites, especially the login process.

So what happens when I want to change my email? I lose all my accounts?

You... just update your email. Or add the new one if the service supports multiple.

"the annoyance that is "Sign up with a username, email address, and password"."

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 ?

Emails may be globally unique but they aren't static over time. I have some accounts on websites where the login is an email address I no longer have access to.

Heck, my microsoft account is tied to an email I can no longer access, but I'm not able to change it, because my generic gmail identity somehow got an xbox account tied to it and that apparently means I can no longer transfer my xbox profile from my old email account to my new one.

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.

Because i'd love for my reddit username to be my email when i decide to play devils advocate, and campaign for Trump.

If you have that kind of site, then do what reddit did -- cut out the email address. Still a 33% saving.

Pretty easy to register TrumpRulez2016@yahoo.com for that purpose.

Registering Yahoo addresses is actually anything but "simple" anymore.

Use Mailinator for your throwaway email address needs:


Almost everybody blacklists mailinator addresses these days...

It's my go-to and I can't remember ever having a problem.

Mailinator has many alias domain names.

Our website has forums and an issue tracker. Many users do not want to reveal their email address in those contexts.

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.

Unless you need a way to identify someone in the UI like here on HN.

Facebook Anonymous Login is definitely a step in the right direction to address those concerns. And yet it's hardly adopted anywhere.

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.

Facebook Anonymous Login is a menace to the open internet.

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.

"and Facebook can take them away from you at any time"

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"

Have they actually done that to any website? Absolutely. Facebook freezes application ids all the time, mostly for what you or I would consider "good reasons" (spam, fraud, abuse, etc). Has it ever happened for less noble reasons, or grey zones? Do you want to bet that this will never be the case? How long is your time horizon?

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

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.

Facebook’s “Anonymous Login” doesn’t protect you in any way from Facebook, it’s for hiding information Facebook owns about your life from other websites. So it doesn’t help with this:

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

And the moment Facebook decides to shut down?

Or worse, the moment they start abusing their position as your identity provider?

Holy shit, are you me?

>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 don't want to impose that privacy failure on my users, but I also don't want to impose the annoyance that is "Sign up with a username, email address, and password".

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.

"Why not just...?"

I enjoy that you offer up a quite complex, confusing, often insecure, and error-prone methodology with this phrase.

How is sending a user an email complex, confusing or error-prone? As for security, given that an account can already be accessed if one has access to the holder's email (which is the case for any password reset flow relying on email), this is no more insecure than the current state.

Seriously, this sort of thing is not complex, not at all.

Complex situations:

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


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


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


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

Medium does this, but I'm not a fan because it takes longer than just using a username/password generated with LastPass.

However, this method can't really be used everywhere -- not all emails are encrypted up to the point where the recipient reads them.

> However, this method can't really be used everywhere — not all emails are encrypted up to the point where the recipient reads them.

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

This is essentially the same thing as having your password emailed to you and is insecure for all the same reasons. Youre putting the responsibility of security on the email provider, which you can't control.

The emailed login link is a short-lived, one-time password and can be associated with a cookie already set on the website's "send me a login email" page.

> This is essentially the same thing as having your password emailed to you and is insecure for all the same reasons.

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.

How does logging in with Twitter compare to Google and Facebook? Same experience?

I found Persona to have some pretty bad UX. I do not want to have to log in again when I close a browser window.

Why do you require a sign in/sign up in the first place? My ad blocking is configured to disable all that crap and I don't make accounts unless I really want whatever is behind it (which is exceedingly rare). On the other hand, I'm the only one I know personally who does not have a Facecrook account and when I tell people they're the product they just stare at me with doll eyes. shrug

My website has:

- 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?

An account of some sort is the only way for a website to store state about you, most notably for authentication/permissions. Do you have a better way of, for example, identifying whether I should be allowed to see a private Github repository or not?

Disclaimer: I work for Mozilla, I maintain django-browserid (and StravosK is a valued contributor <3), and I have implemented Persona on many sites. This is all just my own personal opinion.

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.

To me, Persona never _shipped_. They still discourage self-hosting the identity verification code, so even on a happy path where the user somehow managed to get an email provider that natively supported Persona you still had to talk to Mozilla servers. That's not federated identity, it's centralized; it offers nothing above Facebook Connect.

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

I agree with you on most of this. And yes, a "Persona 2.0" should really just take the Persona lessons and learn from them, avoid the mistakes.

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.

> (there aren't many)

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, ... ?

I could see a joint effort, similar to what happened with Let's Encrypt. The players who benefit are different though so it's harder to get the same kind of pull.

> It should've been supported directly within the Firefox chrome ASAP.

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?

Well, yeah, but Persona/BrowserID didn't fail, YOU (Mozilla) failed. BrowerID was the right concept, and it was insanely stupid to create a different frontend branding, to not build the browser integration, to not explain anything well, and then to describe the project as a failure when it hadn't even been implemented at all on your side.

> Well, yeah, but Persona/BrowserID didn't fail, YOU (Mozilla) failed.

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.

Yes, I wasn't posting to argue with the other poster, I was just writing to clarify and emphasize further the BrowserID aspect of things and other contexts.

Many things are wrong in many projects. In my yard , if something breaks I fix it, I don't buy a new yard.

Hey Michael! <3

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?

The only thing that has a chance of happening is some external party coming up with a different protocol or extending the existing one, and gaining traction as an identity provider. Then, like we did with Pocket and "Save for Later", it's not unreasonable to think that Firefox would accept a system add-on that is compatible with this protocol to ship an in-browser UI.

"gaining traction as an identity provider" being the hard part, of course.

If it was built as a WebExtension, it could work in Firefox and Chrome. :)

Frankly, the name was the worst of it It took some effort to kill the UI-theming Persona with fire (and there were very good reasons to do so); anything that even hinted at the possibility that you'd have to resurrect that in order to do something that looked useful wasn't going to fly unless there was a lot of forgetting time in between uses. Yer average user doesn't monitor tech news sites in order to determine whether or not a product of the same name from the same outfit is really something completely different.

So, perhaps a different question - Can Mozilla host / bless the mailing list / forum where these successors to persona are discussed, built with volunteers and tried out?

All these points don't seem unsolvable problems to me. The only failure was to abandon the project before it had it's chance out in the world.

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

Can you elaborate on this?

Here's the thread: https://groups.google.com/forum/#!searchin/mozilla.dev.ident...

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 don’t know if something like a Kickstarter campaign to raise some money to pay for engineer time would help sway Mozilla at all, but I’m perfectly happy pledging a few hundred dollars and running the campaign, if necessary. I just really want to see Persona succeed.

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.

I too, am in the camp that would like to see open alternatives to the proprietary SSO function. To me this is much more than just a technology problem, however. It's a two sided market creation problem.

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.

Did I ever get back to you on that with the update?

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.

You did not :) Have you talked to Dan Callahan yet?

I very much agree. A while ago I spent some time making an extension for MediaWiki for Persona, in hopes of maybe bringing Persona to Wikipedia at some point, but after Mozilla abandoned it we sort of lost hope on that front.

I am! Federated authentication would be a beautiful thing. I'll lend my dev/sysadmin experience to a project like this.

They may not be directly comparable with Persona, but such things are widely deployed in academic/research communities: https://shibboleth.net/ (web-specific), https://www.eduroam.org/ (roaming wifi-specific in practice?), and "e-science certificates" in the UK (specifically horrible -- definitely not a beautiful thing) which I think come under https://www.igtf.net/.

The recent generalized effort is Moonshot/ABFAB (https://jisc.ac.uk/assent), which I think has made disappointingly slow progress.

I was also sorry to see Mozilla give up on Persona - I believe the web needs something like this.

I happen to be quite good with Node / JavaScript and I will happily help out.

Same here, though Node is not my forte yet.

FIDO protocol support would be nice to have too by default.

Anyone who wants to see a demo of it, just sign-in here (top right): https://login.persona.org/

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.

To address some of your points:

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.

If you're so supportive of Persona, why don't you make your work in the area (persowna.net) FOSS?

I just might.

I just tested the sign-in demo, on persona.org & lfgss.com. Persona feels like the on shared 1st place best login experience I've seen.

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.

It does get better, if you have more than one email address associated to your Persona ( via https://login.persona.org/ ) then during sign-in you are asked which you'd prefer to use. Then it's really clear which is used.

Mozilla shutting down Persona was one of my biggest internet-related disappointments this year. It seemed like the perfect OpenID replacement (that might actually get used by normal people). Bring it back please!

I've hit the upvote button, tweeted Stavros that I think this is awesome - but I still want to document my support with a post.

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.

For more (and better) counter arguments, start with this thread (which was about one particular comparison with Facebook Connect: possibly click to see the parent for context) and then follow my chain of earlier comments I link at the bottom of that one (which were more general, going into the flawed assumptions in Persona about email).


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


For the abovementioned reason that life is too short, did not read the entire tl;dr thread linked above, but the core objection seems to be that email accounts are fungible. Given the operational experience with Cydia, I will accept at face value that this is a serious real-world problem. What seems wrong to me is throwing up our hands and casting our lot with either of two giant incumbents whose main motivation here is obtaining a constant stream of information on people using their authentication interfaces.

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.

While I agree that dealing with lost/defunct email addresses and thus accounts can be a challenge there may be other solutions to these (e.g. SMS confirmation, backup pass phrases). In any case it seems we're letting the perfect be the enemy of good with this line of argument. Persona provides significant privacy and perhaps security to alternatives.

The problem at that point becomes you start to implement a service, rather than a protocol. I'm not sure there is necessarily a solution for identity with the way email is currently implemented.

I created this Persona Advocacy mailing list 11 months ago, but didn't get any traction:



You can subscribe by sending an email to (first message is ditched):


I was an early adopter of Persona (my site is billed as example in the docs) and was similarly disappointed when Mozilla gave up on it.

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

The main problem with Persona was not the tech, Persona is great and works well. The problem is that building federated identity services is hard. Persona is not a centralized login system such as "login with Facebook". With Persona, once you decide to login with your email account, first Persona looks for an IdP with your domain/provider, the if not found it goes back to the persona catchall service. For a while gmail.com had support for Persona as well and it worked transparently. I don't know if that is still the case.

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.

> What killed Persona was not tech but the lack of traction. Developers loved it but failed to use 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...

I agree. Some people in this thread are saying Persona is not dead because it's still up... but without the browser integration (which never was arrived), it's not even half as good as what it could be, and without Mozilla endorsement, it's not going to get serious adoption.

> With Persona, once you decide to login with your email account, first Persona looks for an IdP with your domain/provider, the if not found it goes back to the persona catchall service.

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.

It worked even if their email provider didn't supported it because in such cases there was a fallback Mozilla IdP. You can try it right now on MDN or MozillaWiki.

I don't really see the point in this and this is why: let's say Persona won and all the big ones switched to it (Facebook, Google, Twitter etc.) by becoming providers. Most people would still be using their Facebook, Google or Twitter persona anyway (except for a few privacy sensitive users who don't like SaaS anyway because it's bad for privacy according to them). So we would have a situation that would be de facto very similar to what we have now (3 sigin buttons for facebook, google and twitter) and then an extra one for people using their own hosted provider. This is what happened with OpenID, problem was that supporting people using their own providers became a nightmare as these providers went down or had some incompatibilities. People were just angry they couldn't sign in with their old providers, many of theme may have not even known they were using custom providers or what providers are and the other half would be privacy nerds who enjoy complaining every time their custom provider stops being fully compatible. For app owners, it would just be a big waste of time and resources supporting these users.

You misunderstand how Persona works. You can't log in with Facebook or Twitter, because they don't provide your email address. You can log in with an email address, and the email provider doesn't know what sites you're logging in to.

Try https://pastery.net, log in there. If you have a Gmail account, you'll just click "accept" and you're in.

I just tried it and it redirected me to google oauth2 dialog. Same thing. If anything, it's one step more than using google's oauth2 directly.

Even though I didn't use Persona, having read this, I think this is a big WTF moment for all of us, not just Mozilla. Now I want this thing I didn't know existed because I have, and have had, a need for exactly this. I use a password manager, but I don't really want to use one. I certainly don't like my parents using them, because in fact I have to use them for them because the UI/UX varies so much among web sites. There is no standard UI for changing passwords or doing account resets. All of that shit could go away with this. Fuck. We need to go retrieve that ship!

I find Keepass and/or Lastpass are better solutions - you can have different logins for different sites, generate truly strong random passwords and login with two clicks in any modern browser.

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.

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

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.

The problem Facebook Connect solves isn't just logging in to multiple accounts but also signing up with them.

> Google Web History already creeps me out :-)

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.

Do you actually believe this accomplishes anything… This data is still in their server logs[1] (and streamed directly to NSA).

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

I did, though I might need to recheck it, since they used the word "paused" instead of "disabled" :-)

As I understand it, the main point of Persona was improving the situation around authentication and passwords.

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


That seems like a much better approach to improving the situation around authentication and passwords than Persona was.

This might be a silly question, but why do we need Mozilla to build this system? Is it a matter of trust in Mozilla and a greater likelihood of adoption if Mozilla is the organization providing this service?

> Is it a matter of trust in Mozilla

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.

I'd definitely say that the trustworthiness is the reason since a large chunk of Internet is not really satisfied with the way Mozilla adopts things.

Please, don't.

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

Could you suggest a usable, practical alternative then?

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?

Sadly, no alternative currently exists. Well, none I know of.

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've used Persona on one project (see: https://github.com/OWF/owf2014/blob/master/website/auth/pers...). I was awesome (much much easier than the OAuth dance with the various providers we wanted to support). I wholeheartedly agree w/ Stavros.

> As security people like to say, “put all your eggs in one basket and stick the basket in Fort Knox”

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?

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




It doesn’t have to be an email acc. Persona doesn’t actually have any dependency on email. Addresses that look like email (user@domain.tld) are just used for namespacing. The only requirement is that domain.tld can assert that you control user@domain.tld.


Like you say, email is already the basket, so there are only advantages in migrating (such as not leaving your passwords all around the web).

Persona is a neat idea, but there's a better one: get rid of password logins altogether. I should just be able to enter my email on ANY site, and they'll send me an email with a login button. I click the login button in the email, and am automatically logged into the site for as long as necessary.

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!

If you have an identity server, a website and a browser that all support Persona, (and you've already been through the process once), Persona would work much better than that. You don't have to memorise a new password and you don't have to click on a verification email. You just land on a new site, click log in with Persona, choose your email address, and TADA! you're in. And the beauty of it is that your email provider doesn't even know which sites you're logging in to.

Yeah but if you do that what happens if you want to use the site again the following week? Do you have to do the check your email thing every time which could get annoying or leave them logged in for ever with cookies which could be a security issue. Not saying it's necessarily a bad idea but I wonder how well it would work in practice compared with the normal stuff.

While I think Persona is way better than password-based auth, I can't help but feel that it's also a sideways step. No, authentication should be provided by the user-agent, not by some third party identity provider (even if you control it by running your own). We have this for ssh: you have your private ssh key and it's up to you to manage having it in the right places (work desktop, laptop, phone, etc.) It's clunky, but that's OK: it's aimed at tech people.

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.

BrowserID works by default with email but it has absolutely to dependency on email. It uses it for namespacing and bootstrapping, but nothing else.

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


To some extent, this is similar to SSL/TLS certificates that can be used to authenticate the user (not just the server). If I recall correctly, http://startssl.com/ does that.

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)

Yeah, basically this. I have used it before and client side TLS certs are anything but intuitive. They are also not widely supported.

> Anyone with access to your email account can simply reset any password on any site. The right solution is to make your email account very, very secure.

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

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?

SMS is an awful point of failure to inject into a protocol. It is plain-text, monitored in many countries, and can be unreliable and expensive in emerging markets, and just no.

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

SMS though provides a higher level of security. Some hacker anywhere on the planet could have accessed my email and passwords but they can't get a code sent to my phone unless they are nearby and have got hold of the phone. I'm not sure it being plain text and monitored matters much as all that's bring sent is a random number usually. I'll admit it could cost more and so may not be the thing for sites with lots of free users. If you can't get sms some sites will phone you with a recorded message.

You can use a dedicated e-mail address for accounts.

- Can Mozilla set up a kickstarter for this project?

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

Man, Linux desktops would have a huge gain to usability if we could get a distributed accounts framework in place for all the distros so if you signin using online credentials through Persona on one desktop all your config files and preferences are carried over. Its annoying to have to manually sync my laptop and desktops config files.

To your second question, yes, it is. Your identity provider can do whatever you want, so as long as you can make a website that shows you a "connect with your SSH now" prompt and have that turn green when you connect, then Persona can go on top of that.

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.

The client that wants to login always needs to execute a browser (or at least a render and JavaScript engine). See this (stalled) proposal to make it more compatible with non-browser/simpler agents: https://groups.google.com/d/msg/mozilla.dev.identity/L2ETKkd...

Well, we had Persona working as both as GSS-API mechanism on Unix and a SSP on Windows. You could use it to sign-in to Exchange with Outlook - that was pretty cool. Links here:

* https://hacks.mozilla.org/2013/04/mozilla-persona-for-the-no...

* https://github.com/PADL/libbrowserid

* https://tools.ietf.org/html/draft-howard-gss-browserid-07

Not sure if anyone realizes this, but Mozilla is not really an open source thing. It's a company that happens to be a nonprofit. It deploys resources and runs itself like a Silicon Valley company.

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.

I've got plenty of quibbles with Mozilla (including their handling of Persona) but "open source thing" and "company" are not mutually exclusive. We need more entities with lots of resources doing almost exclusively open source.

From what I understand, there are two arms to Mozilla... Mozilla the company (sometimes referred to as MoCo) and the Mozilla Foundation (sometimes referred to as MoFo). Again, from what I understand, MoCo is the not-for-profit company supporting the work of the Mozilla Foundation. The Foundation has an ethical mission to improve and protect the web.

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

We've had 10+ years now of failures to build a proper federated authentication system (RIP OpenID). The problem isn't technical, and it's only a little bit product design. The problem is political. The big companies with the influence to support a system like Persona don't want it. Facebook, Google, etc believe they can own identity on the Internet themselves, so they won't support a neutral identity provider. Which is a terrible situation for users.

Mozilla absolutely is the right kind of organization to try to attack this Gordian knot.

I totally agree with the first paragraph, but I'm not convinced on the second.

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.

I agree the Mozilla organization has failed here. I guess I don't know any other neutral organization that could do this. We have precious few user-advocacy organizations out there. It's outside EFF's bailiwick. I don't think Apache is any better at politics than Mozilla.

Is there a short introduction as to how Persona deviates from the original decentralized OAuth approach? I'm a bit unclear why what didn't work for decentralized OAuth should work for Persona.

What was the decentralized OAuth approach? Are you referring to OpenID?

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.

The best way to get Persona adopted would be to have someone significant other than Mozilla to adopt it. If IE, Safari, or Chrome had adopted, it would have had a great chance at success.

Just to be clear, Persona works on IE, Safari and Chrome as well. It is not tied to Firefox. You can login to MDN for example using Persona on Chrome if you'd like to.

But why would they? All three have their own auth services to peddle.

I don't see other browser vendors implementing Persona before (if ever) it is an otherwise widely accepted thing.

But even Firefox didn't adopt it! Why expect other browsers to support what desktop Firefox never supported even for a day?

It's alarming that after 2 years they killed it off for lack of traction, and not only that, decided they had failed.

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.

It's nearly 2016 and Firefox can still only using 1 of my 8 CPU cores, and I can still bog down the UI with heavy web apps. My favorite email client is no longer supported, and now a potentially great privacy tool is being dropped. Meanwhile, after wasting countless man hours on a Mobile OS, they're now "pivoting" to IoT.

Why can't they just focus on what people value them for, web browsers and privacy?

> Even if your email provider does end up getting breached, you only need to change one password to be perfectly secure everywhere again.

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.

Persona seemed like the right identity product for its time, but technology has moved on in the years since. We now have blockchains: shared, publicly-writable databases that are perfect for hosting identities that users fully control. Figuring out decentralized identity is part of my day job, and if it's something you're interested in building or talking about, email me: niran@niran.org.

You're right. I sent Mozilla $5 this year just for doing what they already do. Kickstart this and they'd get millions, I'd guess.

>Tell the email provider you want to give a site permission to know your email address, without telling the provider which site it is.

Then the site emails you anyway. (If you didn't want them to, you shouldn't have given them your email address).

The email could be used for authentication purposes and not for actual email.

If someone at Apple is reading this... please fork it (or built up from scratch) a solid open source SSO system and become an official (but optional) identity provider for your millions customers.

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.

I backed persona with a well written example back when it first 'came out' into the mainstream: https://github.com/sergiotapia/ASP.Net-MVC3-Persona-Demo

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.

As a dev, it was really nice to use Persona and not have to build an authentication system for each project.

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.

Persona is a most promising idea because it will eventually lead to secure passwordless login everywhere. Keep the pedal to the metal guys!

But Persona isn’t passwordless, or?

Persona is passwordless. The idea is that you verify with your email provider who supports it. Your email provider may have a password, but there's no Persona-related password (unless you use Mozilla's Persona.org service because your email provider doesn't support Persona directly).

Don't know why persona never caught on, it was probably the best developer/user logon experience I've ever used. When I created my last site, I was very excited about persona, until I realized nobody was developing it anymore, which made me decide against using it. I wish Mozilla would have completed persona before abandoning it.

Sorry, where is it said they will stop development of Persona? The homepage and the service seem to be in full health, there's no warning anywhere for users of Persona.

Is there any official statement that Persona will shut down?

Persona sounds like what I've always dreamed of for authentication. Why is this not happening anywhere yet?

The message I got from Persona was "hey we're developing this thing, it'll be part of Firefox." Sounded like a pretty good idea to me and the signal for it being ready so I could reasonably push for adoption. Then it got shut down for no apparent reason.

My first experience with Persona was through my mobile phone provider, Ting. They still use Persona: https://ting.com/account/login. I loved it then, and I love it now.

I haven't looked into Persona since they shut it down, but is it a protocol or a service? If it was actively developed again, would one be able to use Persona without integrating with any Mozilla service at all or would there always be a Mozilla layer involved?

The backend was called BrowserID, and it was supposed to integrate with your browser and be supported by email providers not be some Mozilla service. It's only a service because they didn't get around to implementing the actual BrowserID design, so they run a service for now, and then they halted development before they even tried to build the actual design!

It is a service. Plus some code to make service integration into your website easy. Sadly, my experience was that it was not very reliable.

I really liked Persona and put a bunch of work into extending it (adding support for things like selective attribute disclosure). One real design limitation was that it didn't support delegation (the original use case for OAuth).

Just an idea but could they work with the wordpress guys to make it the default system for wordpress? They're both open source companies and apparently wordpress runs a large percentage of the web.

I didn't even realize Persona was shut down. It was a good idea.


My only gripe with Persona is that it is not easy to use in mobile apps, if at all possible.

Mitch Baker should be commended on her hard work turning Mozilla back into Netscape.

You know what poverty is? Always starting over. Mozilla is getting good at that.

Firefox is ancient.

People who write open letters need to fall in a hole. They're so lame.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact