For our use-case Persona is great. I've personally built the "web account" solution several times for different clients and I did not want to build it again. Persona is the lightest drop-in and easiest to implement solution you can imagine, and it works extremely well.
We've had a couple of issues, but nothing of significance. Mostly these have been us doing things unexpected, i.e. pre-loading user accounts obtained face-to-face and the case of the user@ part of the email address differing from the Persona provided email address.
I personally also wish that persona.js is added to CDNJS to increase the speed by which it's served.
What we found through asking, was that people feel very protective of their Google, Twitter, and Facebook accounts. They will sign in with them, but there's a wariness of doing so as they do not want to be spammed, have things posted on their behalf, etc. These fears mostly apply when people first arrive on one of our sites. We wanted a lower friction to that initial sign-in, and we feel that Persona gives us this.
We also found that on interest-based communities there is a reticence to associate real-identity to the nerdiest of their interests. This meant that not using Facebook and Google is a good thing in our scenario.
One of the things we like about Persona is the user experience. For our product, simplicity and ease are core goals. Persona helps rather than hinders on this front.
We really like Persona and hope that it remains under active development for a long-time.
We are not of the belief that it's failed, simply that it's a slow-burner and needs some marketing support.
My first and only experience with Persona is oddly enough, to log into the Islington CC forum (small world) and I found the whole experience oddly disconcerting. Am I logged into Google or Microcosm? Do I have to stay logged into my Google account? What does firefox have to do with my Gmail account? What is Persona and what do they have to do with anything?
I had lots of questions and none were answered on the nice minimally designed log in page. All of a sudden I'm sent to Google, but I don't want my work account associated with ANYTHING outside of work. Ok, I'm smart, I can just log out and no link will be created. I log in with my personal G account and everything seems ok. But now I have to log out/in again to get back to work.
Why all this trouble? I have a password manager, and it can easily remember another 30 character password. If it gets hacked, the damage is limited to a forum that I occasionally visit. No biggie. But now, everything is linked to everything else and who knows what is happening in the background that I agreed to because I didn't read the small print.
Ok, I'm being a bit dramatic. But personally I don't like services to mixed. That's all it comes down to.
One last thing, you mention that people didn't like associating real identities etc, but the only way I could log in was by associating my real identity from my Google account.
Disconcerting, that's not come up in any of the UX testing or feedback we've received recently.
In our earliest version (last summer) we had pushed the "Sign In with Persona" branding but later moved to just saying "Sign in". But that was caught in UX testing and we did change that so that it was clearer (by saying less) that you were signing in to the site you were on (Islington CC).
> the only way I could log in was by associating my real identity from my Google account
The great thing about Persona is you can use any email you wish to login to something. You can choose to use an email address that is associated with real identity, but just as easily you could've chosen not to.
The advantage Persona supplies is that even if you do choose to use an email associated with real identity, Google (or the email provider, e.g. Facebook) will only see a "Sign in to Persona" event, and will not have additional data revealing that you had signed in to Islington CC (in this case).
Persona effectively acts as a behavioural data firewall that grants you sign-in with email ability, but without leaking your behaviour activity back to the email issuer.
If you have any feedback on how you think we can improve this from our side (the forum software), just email me: david@microcosm.cc
I've yet to write FAQ support documentation, and I think you could help provide a lot of the questions around sign-in for me to answer.
Thanks for the explanation. Maybe my experience was tainted by the myriad times I've been asking to sign in to a service using Facebook, only to be met with a form asking for my name, email and password. So what was all that FB nonsense about then? So to be fair, the Persona procedure was painless in that respect.
Something that would have been helpful would be a bit more information at the first point of contact with Persona. Ok, so I've just gone to the site and clicked the Sign in or Register link, and the pop-up (ugh) that appears doesn't really explain anything. It asks me to sign in with my email. But you don't have my email yet. What am I signing in to? Is this one of those FB logins where you already know everything about me? And where is the registration page I was promised? I was given a choice, but now one of those choices is gone. There's a bit of a disconnect there.
Soldiering on, if I enter a gmail email then Google's presence makes itself known. Why? Did I accidentally click a bookmark or something? Google wasn't mentioned before. Did I fall victim to a xss attack? No way am I signing in to this pop-up asking for the keys to the kingdom. I know I'm sounding a bit thick here, but I'm 100% certain my mother would've bailed by now.
What is missing is some explanation as to why certain info is being asked for, and will it be shared with anyone. I have the option to agree to T&Cs and a Privacy Policy, but I still don't know why. Yes, I could click on the Learn more link at the bottom of the page, but I don't feel I should have to. I just want to register with the forum.
Anyhow, I'll put chicken little back in the pen because I think I'm being kind of harsh. I applaud services such as Persona, but I've yet to use one that I would compel me to integrate it into one of my websites. If I can think of any more constructive criticisms I'll be sure to pass them along. Cheers!
For this service, you can sign in with your email address. If you are using one of the supported email providers, you will be redirected to them to finish signup, otherwise you will be asked to create a Persona account. Your email provider will not know which sites you are signing in to, and we won't know your email password or other data.
I just tried out the forum.islington.cc registration (without being logged in to Google). The way it redirected me to a Google sign in when I gave a gmail address made me think it was going to end up using OpenID at the back end, something I have never used Google for.
Personally, if I had to register for an account on a site that used Persona, I'd create a special barrkel.persona@gmail.com address (or something similar) to firewall it from my other gmail accounts.
> The advantage Persona supplies is that even if you do choose to use an email associated with real identity, Google (or the email provider, e.g. Facebook) will only see a "Sign in to Persona" event, and will not have additional data revealing that you had signed in to Islington CC (in this case).
In this case, it would seem size does matter. If alice@example.com is the first user from example.com to sign in (or first modulus cache of exmaple.com's key at the service) -- example.com will see 1) a sign-in-to-persona-for-alice@example.com in close temporal proximity to a request for it's certificate from the service.
So, if a site already has gmail.com's persona cert on file, google will only see that alice@gmail.com uses persona (and only whenever alice needs a new/refreshed persona session).
I don't think this is much of a flaw, but there definitively is a bit of traffic going back and forth. But much better than with the alternatives (that I'm aware of).
[edit: and obviously the site/service will get the email address as well, but then most other solutions also require the site to get the email address]
I 100% agree with all of this. I think Persona needs some native support in browsers/etc and will succeed. I find it the easiest login system to implement, bar none.
If disposable email providers (mailinator, 33mail, etc) implement it, you will just be able to log in with your disposable email address everywhere. If the browser implements "remember which address I signed up to this site with", it will be the most transparent login system available.
Here's why I won't use it if I have any other option: As an example to see if it's still an issue -- I tried clicking your islington.cc "sign-in or register" button. I'm greeted with a popup saying "We are sorry, but currently your browser is not supported. <firefox logo> Persona works with Firefox and other modern browsers". The browser I'm using? Firefox (ESR 24.whatever is current). Closing the pop-up and trying again worked, eventually. This happens about a third of the time I try to use a persona-based sign-in.
>This meant that not using Facebook and Google is a good thing in our scenario.
That's why there's this idea of a 'username' paired with a stored salted hash of a 'password'. This allows people to have independent accounts per service.
This is true. However, part of the thinking behind persona is that most sites will want to let you reset your password, so they store: salt+password:username:email. Some are being "clever" and use the email as the username -- hopefully paired with a numeric/uuid uid -- so that when you change email providers, you can retain your account. Some might store a phone number for recovery etc. Some require a working email in order to register (to fight spam accounts).
Further, in general most sites will log your ip, be able to match that to your username, and so, unless you're using tor, be able to provide enough information to track you across sites anyway.
In the spirit of helping out my fellow developers at Mozilla, who I respect a lot, I would like to add one additional cause of failure, in the knowledge that it is a bit bracing but is really important and should inform project selection in the future:
Persona fails to solve a problem which either end-users or people who operate websites for profit actually have.
Perhaps not enough people who operate websites for profit, but there are a reasonable number of us working on PaaS/SaaS products where using Facebook Connect is out of the question because of data-protection laws, which does leave a pain-point around user management. The current gold standard is "roll your own", but Persona is an interesting alternative.
Why aren't people using it even in that sphere? One issue is that it's precisely when you need to take advantage of the federated aspect that the win on up-front effort is weakened. By the time you're setting up your own in-house Persona server rather than using Mozilla's, you're probably at the point where it's less effort to just use some crappy off-the-shelf account-management system that comes as a CMS plugin. This might be counteracted if using Persona improved conversion, but that's a chicken-and-egg problem as long as users don't recognize Persona.
The other bit imo is that the security downsides of roll-your-own are a bit of an unpriced externality. If you have a password breach, it's bad PR for a bit, but legal liability around it is relatively toothless: data-protection laws seem not to care about mere incompetence in keeping users' data private. Make your users pick passwords with at least 2 digits and 2 non-digit characters and you've "done your part". So rolling your own crappy login system doesn't have as big a downside for you the provider as for your users. The users, for their part, are oblivious to the risk before the fact, and lack serious legal recourse after the fact, so they'll go along with your crappy in-house signup system, and shoulder the risk.
Are you talking about a login mechanism to a site, or about authenticating yourself to other sites? I don't understand what "roll your own" is referring to.
Developers/tech savvy people have hundreds of passwords for all their services. The serious ones use Keepass or similar to store the passwords, and don't have a problem.
The "normal" computer user does not have hundreds of passwords. They have a few. And they give them all the same password, or similar enough. They don't have a problem remembering them, because they're simple, easy-to-remember passwords (e.g. that can be cracked).
Is this a good situation? No. But people don't know it. And implementing a whole new system to solve a problem that most people don't know about is simply not going to help.
The point is that the developers that would give Persona visibility in the broader market are the kind that don't care to invest the time to make an (albeit usually insecure) password database. Big sites aren't using Persona and apparently that is why Mozilla sees it as a failure.
But sites apparently don't care about this enough to want it, and users apparently don't care enough to demand it.
So how does it solve a problem these sites actually have?
Some small percentage of end users have this problem (the ones demanding a solution to privacy problems), but the rest don't think it's a problem, apparently.
(Surveys up the wazoo that show that people care about whatever mean nothing when people don't actually change their behavior)
> But sites apparently don't care about this enough to want it, and users apparently don't care enough to demand it.
That's not apparent at all. As far as I know, lots of people never even heard of Persona. I thought it was still beta. It's just in the works, so it makes sense not everyone jumped on board. There wasn't tons of marketing even.
Sure, but Facebook has a number of problems as a general-purpose login mechanism:
A. Not everyone has an FB account.
B. Those that do don't always trust that logging in with FB won't mean that the website they're logging in to will spam their wall.
The sense you'd have to have today is that if you sign in with Facebook credentials your profile picture will appear on all your friends' timelines next to a made-up quote about how you really love the site when you don't even have an opinion about it yet.
Sorry, this isn't true. As someone who operates a website for profit [1], Persona solved a huge problem for me: not having to waste time on implementing, maintaining, and securing an authentication management solution.
For end-users it solves the same problem that Facebook Connect solves - an end-user doesn't have to remember a username and password for each account he has. And when creating an account on a website with Persona, the email is already verified if that user already has a Persona account, so the user doesn't have to go though the email verification process again. This lowers friction and increases conversions.
For end-users it solves the same problem that Facebook Connect solves - an end-user doesn't have to remember a username and password for each account he has.
Let's not forget that for a vast amount of people, this just means remembering a single username+password.
Facebook Connect offers other advantages to Persona that have nothing to do directly with login: you get a profile picture, a name, and a gender. You get this same information from other value-added login providers, such as Google. This dramatically cuts down on the complexity of a sign-in process for both the user and the website. You additionally have fairly rapid access to a social ecosystem (which I realize not everyone wants; I have personally never taken advantage of this on my site), and can start doing things like "friends of yours did this thing". This means that Facebook Connect is something a website might use even if they consider login to be a non-problem (and I think patio11's point is that login is largely a non-problem).
Even just for login, though: Persona doesn't solve this problem as well as Facebook Connect (from either the perspective of the site administrator or the user) as it assumes email addresses are canonical and unchanging, which is not true for normal users (who tend to change email addresses occasionally to get rid of spam or old contacts they no longer like; they also often get their email addresses only temporarily from schools, employers, and network providers). Please understand: I have had the same email address since the late 90s, and likely most people reading HN care about canonical identifiers, realize the security issues involved with losing their email accounts, and often have business reasons to not lose access to old contacts--we are not "normal people".
With Facebook Connect the user normally cares more about their account (people change Facebook accounts much less often than email addresses), and when their email address changes they can update it on Facebook without bothering the site they are using. (I run a site that uses only external login providers, either Facebook or Google, and the users who log in using Google often contact me saying they changed their email address and now can't log in to my site anymore as they had to make a new Google account. I frankly only offer Google because some people hate the very idea of Facebook.)
This undermines one of the major advantages of using third-party authentication providers. For site administrators, it means you still need some way to identify and authorize accounts separate from Persona (so as to know the user contacting you, who no longer had access to their old email address, is really the user they claim to be), and for the user it means they still have to find all the websites they have previously logged into in order to correct their email address, and they must do so manually and painfully (potentially talking to a customer support representative).
If all Persona did was "email verification" that might actually be kind of awesome, and then have that tied to an existing login system (maybe one involving a username and a password) provided by the site (or even by a third-party), but it ends up being sufficiently intrusive to the flow that it just doesn't feel right to use it and another login mechanism, which means that these killer "email changed, don't have access to old e-mail address" issues become entrenched. That also isn't how Persona was marketing itself, so no one seems to think to use it that way (leading to the "it doesn't seem to better solve a problem I really have" issue).
(I have written more about this subject in the past, with at least a small amount more detail on some of the other problems that can arise with relation to email accounts provided for temporary use, such as by the aforementioned schools, employers, and network providers; the short version, though, is that email addresses often get reassigned, which makes the entire idea of using an email address as the basis of what is supposed to be a widespread secure login mechanism insane. OpenID has tons of its own adoption issues, but at least it required providers to never reuse their identifiers between different people, and provided a simple way to allow that to be possible... I mean, even Yahoo and Hotmail expire and recycle accounts, so this is a serious problem.)
OK, then a answer this question: how does the user log in to change their email address? They can't use Persona, as they already deleted their old email address. (And if you try to tell me this doesn't happen, you are wrong: this happens constantly; again, I run a site with tens of millions of users and rely on third-party login providers: I am not making these issues up. Most users don't use your site constantly, and only realize they are locked out long after they've moved on from their old email address. In fact, it would never even occur to them that this is a problem, as they are used to sites using passwords for login, which even when emails are used as the username continue to work after they delete their account.)
The easy solutions I can come up with to this problem negate all the benefits of Persona past "email verification without sending an email", which is a non-problem for most people, and not how Persona is marketing itself (in particular, you can't rely on it as a login provider: you need a password or something instead). It is ludicrously irritating to have to deal with these issues manually; at least Google (which also causes this problem) offers other benefits (names, genders, profile pictures, and with G+ a list of friends to easily add social features). The other options you have are ludicrous "account recovery" flows, such as Facebook's "get five of your most trusted friends to vouch for you" mechanism, which shouldn't be needed for this all-too-common case.
This is actually a fairly easy problem to solve; instead of "change your email address" you offer "add email address" and "remove email address" functionality. It tends to be a much more useful approach anyways, especially if you offer multiple authentication options (ie Facebook Connect).
I do not see how this affects the analysis: to use either change or add/remove you have to first be able to authenticate somehow, and if your e-mail address has already been deleted (either by you, or by the group that temporarily granted it you) then you will be unable to do this.
Isn't it the case that it only actually sends an email if you forget your password or you want to sign up? That has been my experience with persona. So why can't you log in with your old email and then change it to your new email?
Sure, if you delete your email address before you've changed it on the site, you're screwed, but how do you log in with Facebook/Twitter/Google after you've deleted your Facebook/Twitter/Google account? You aren't just screwed, but there's no way to change login accounts at all, even if you go around to all of your sites beforehand.
Persona is better than the other centralized login systems in this respect, and is second only to username/password. Username/password can identify you after you've changed whatever you like, but it's not centralized, so we're comparing apples to oranges.
> Sure, if you delete your email address before you've changed it on the site, you're screwed, but how do you log in with Facebook/Twitter/Google after you've deleted your Facebook/Twitter/Google account?
People delete their Facebook accounts much more rarely than they delete their email accounts. There is simply very little reason to delete your Facebook account other than "I have decided I am afraid of Facebook", a thought a normal user doesn't have (the only people who have this thought are the tiny percentage of highly paranoid people that probably didn't use Facebook to log in to your site in the first place ;P). For whatever reason, normal users delete their e-mail addresses constantly. Normal users also often use third-party provided email addresses (from schools, employers, or network providers), and thereby will lose their email address; that is never true of Facebook/Twitter (though it does happen with Google Apps accounts, which sucks).
This problem ("user lost access to their email address") is thereby orders of magnitude greater in prevalence than "the user deleted their Facebook account"; the latter problem is so rare that "they can send us an email and talk to a customer service person" is reasonable, but for the former problem you really need some kind of automated solution... (as it stands, the fact that I support Google login for Cydia is a serious problem on this front: while users can delete their Gmail accounts without deleting their Google account, and can then link their Google account to a third-party non-Gmail email account, none of them ever do this, and most normal users don't even realize it is possible).
> You aren't just screwed, but there's no way to change login accounts at all, even if you go around to all of your sites beforehand.
You make this problem sound worse than the Persona problem, but it is in fact the exact same problem as Persona: Persona is, for every email account, like a separate Facebook/Google/Twitter account. If the website somehow magically solves this problem for Persona (such as offering "transfer account to another federated login account"), this problem is identically and immediately solved for all these other account mechanisms as well. Persona offers no advantage on this front, and yet has the as-described worse property of being directly tied to the one thing users seem to not value much or even have no control over (their email address), leading to the common "I deleted my account before I transferred it" issue.
> Username/password can identify you after you've changed whatever you like, but it's not centralized, so we're comparing apples to oranges.
The core of this argument doesn't start with a comparison: this is an explanation that Persona fails to solve a key problem (user changes email address) that is sufficiently common that any large low-margin site will need to implement a password-based login system as a supplement (unless they can come up with a reasonable "account recovery" flow, which is hard and almost always a serious security issue), at which point Persona becomes redundant (again: the only problem it is solving is email verification without sending an email, which is a "non-problem" for most people, and not worth the separate branding and the external dependencies). That said, Persona really isn't centralized anyway: it is in fact decentralized federated login, with no "centralization" that can be used to store any account information at all.
You've solidified my reasoning as to why I find FB Connect useful, despite the privacy implications.
Isn't it weird that email for normal people is more ephemeral than social networking accounts? I wonder what the best way of getting that stickiness would be, without relying on these big third party providers per se. Perhaps Persona, but more towards an ID rather than focusing on an email? I need to do more research on this.
I would not say it is weird: there is only one Facebook and most people only sign up to it once.
There are many email address providers and many people have many email addresses.
Many people have their email address provided by their employer. And many people use this address as their contact address in even non-professional capacities. I presume such people also use their work address to sign up to web sites/services. When they change jobs the old address dies.
The same applies for students in schools or universities and it once applied to the ISP's customers too.
I used to have all my (private) email at a shell account with ukshells. They used to run qmail, so I had lots of <sitename>@<myusername>.ukshells.co.uk emails associated with various services. I forgot to reset a number of them when I moved to hosting my own email.
I've also had a work email that was deleted (when I changed work), and a college email that was deleted (when I changed college).
Whoa. Your "tens of millions of users" sounds very intriguing (and the 'tens of' part is interesting, as if 'millions of users' isn't enough - seems like a very conscious choice of words).
Is the name of the site a secret? How many sites have this many users (I understand you talk about registered users, since we're talking profiles/login issues here)?
It is no secret that I run Cydia (and if someone didn't know that, or didn't check, I did mention "Cydia" in one of the comments of this thread ;P). Also, you make a very important point: I normally am just talking about "users" (and so motor-memory my way through "tens of millions"), but not all of those users log in (you only have to log in to buy something, not to download things for free; the vast majority of my users simply use the service for free--that said, some users have multiple accounts, potentially simply having logged in with both Facebook and Google on various occasions, so the numbers maybe aren't as low as one might then expect), so I only have 7.5 million federated accounts registered (just checked the database), fairly equally split between Facebook and Google (Google has the edge, partly because it handles more demographics and in particular more countries). I am sorry about the confusion (although the resulting number is still high enough that I don't think it wears down the impact sufficiently to be a concern ;P).
I could not disagree more. Most people hate having to manage passwords across many sites and using a password manager doesn't help enough. Email validation is a speed bump but a necessary one for many sites.
It sounds like Persona will move in the right direction of being a really simple way to confirm an email address without other privacy implications. That seems like a great deal to me over having to maintain and de-dupe huge lists of passwords in every device / browser you use.
This is just another symptom of what I think is a prolonged stagnation at Mozilla. I suspect they've lost touch with the needs of their users a lot of the time.
Firefox hasn't been in a good place lately. Most of the changes since Firefox 4 haven't been to the users' benefit. It's like these changes have been more about imitating Chrome, regardless of whether or not this is good for Firefox's users. Yet Chrome is still superior where it really matters, such as performance and resource usage. If Firefox users are just going to get a Chrome-like experience these days, but not as good as that offered by actual Chrome, then they might as well just move to Chrome. And I think that's exactly what we've seen, and why Firefox' usage numbers are dropping.
We see the same with Firefox Mobile. It really isn't superior to the alternative browsers in any way. In many ways it's significantly inferior. There's really nothing to pull users to it.
Thunderbird was perhaps their second most useful product, after Firefox. Yet they've basically given up on it now. I know I've migrated to another email client, and many others have chosen to do the same, too, now that Thunderbird doesn't really improve over time. Even then, the changes we've seen lately have been more harmful than good. The UI is less usable now than it was in earlier release, for instance.
Firefox OS is another example. It really doesn't offer anything tangible over Android, iOS, or the many other mobile OSes that already exist and already widely available on many devices. In fact, it offers a very limited development environment compared to the alternatives, which surely doesn't help its case. The only reasons I've heard to use it are ideological, about Mozilla somehow being "more open" or something of that sort. That's just not enough to gain real traction, I'm afraid.
And Persona is yet another example. It just doesn't meet the needs of its potential users.
Rust is perhaps the only interesting thing I've seen coming out of Mozilla lately. But it has taken a long time to get to where it is, and I'm not sure if it still has the momentum to have the impact that it might have had were a stable version available a year or two ago. Go, and even C++11, can now provide a lot of its benefits today, if not much earlier.
I think there's been a lot of wheel-spinning at Mozilla lately, in terms of their offerings. Their successful products are being ignored or actively made worse, while their new offerings don't actually benefit a wide audience, or offer an insufficient amount of benefit.
I'm not going to pretend to know how to fix these problems, but focusing on product that users actually want, and giving these users the functionality they want, may be a good start.
> Go, and even C++11, can now provide a lot of its benefits today, if not much earlier.
The main benefits of Rust are (a) bare metal performance with zero overhead with (b) memory safety, for security and developer happiness. Go lacks (a), with its mandatory runtime, garbage collection, and ecosystem based around a non-optimizing compiler, and C++ lacks (b), with its memory safety problems that are real, pervasive, and cannot be fixed without breaking backwards compatibility. What you said is only true if by "a lot of Rust's benefits" you mean "basically none of its benefits".
It sounds like you are unhappy with some of the user interface decisions in Firefox and are trying to use this story as a way to spin this out into some sort of narrative of Mozilla's decline and stagnation.
I can use Go and C++ today without fear that code I write now won't be able to compile next month, due to significant language and/or library changes. The same cannot be said for Rust.
Since I can get perhaps 90% of the benefits of Rust today using other languages that I can actually use seriously, I might as well just use them. Had Rust been more stable in 2012, maybe it'd be a different situation today.
And you can read my original comment again, if the big picture isn't clear to you. I hope it's obvious then that this is far more than just a few bad UI decisions involving Firefox. That is an issue, of course, don't get me wrong, but it clearly goes much beyond that.
Almost all of Mozilla's major projects, from Firefox, to Thunderbird, to Firefox for Mobile, to Persona, to Firefox OS, and even Rust are suffering from some pretty serious detachment from the needs of their users. This is resulting in a decrease in adoption, like in the cases of Firefox and Thunderbird, limited adoption in the case of Firefox for Mobile, or basically no adoption in the cases of Firefox OS, Persona and Rust.
> Since I can get perhaps 90% of the benefits of Rust
> today using other languages
Incorrect, unless you're one of the rare few using Ada or Cyclone. Bare-metal memory safety is fundamentally impossible in both Go and C++.
> Had Rust been more stable in 2012, maybe it'd be a
> different situation today.
Incorrect. I was there! And trust me when I say that 2012 Rust was very far off the mark. Rust is a language that was designed to be released in 2014, not 2012 or 2006 or 2038.
> Almost all of Mozilla's major projects, from
> Firefox, to Thunderbird, to Firefox for Mobile, to
> Persona, to Firefox OS, and even Rust are suffering
> from some pretty serious detachment from the needs
> of their users.
Citation needed. By any estimate, Firefox still has a fifth of all web traffic, with 500 million users. Firefox for Android has between 50 and 100 million downloads and is the highest-rated browser on the Android app store. Firefox OS continues to find new carriers and launch in new territories, which is more than can be said for Tizen or Meego or Symbian or Ubuntu Touch. And even though Rust hasn't even launched yet we're seeing month-over-month growth in traffic on every outlet.
Go does not give you bare-metal control without GC and C++ does not give you safety. They do not give you "90%" of what you want, if you're in a domain that needs those features. If you need to write libraries to be used by Ruby, for example, Go does not give you 90% of that, it gives you 0%. If you need to write secure, memory-safe software, C++11 does not give you 90% of what you want, and anybody in the security field will tell you that.
It has taken time to stabilize Rust because it is doing something that no language in industry has done. Rust is not designed to be a Go that's 10% better or a C++ that's 10% better. It's designed to let you do things you can't do in those languages. Like writing libraries callable by C that are guaranteed not to segfault. Or writing games that can't afford GC.
I would have agreed with you a year ago on Firefox. I was almost ready to give up on it the performance was so bad. But recent fixes have had a huge improvement for me. Firefox is at least as stable and fast for me as Chrome--on Mac 10.8.
That said, I never understood the problem that Persona was trying to solve.
The problem Persona solves is: how can I log in to various sites securely without having to generate site-specific and inconsistent widely-varying sign-ins and security AND without having all my activities tracked by Google or Facebook or others etc.
In short: how can we get "sign-in-with-Google" but with anything and not just these big players and protect privacy fully?
because one project doesnt work out... lets conclude all other projects sucks!
such a cool argument.
im typing this from "firefox mobile" - its called firefox or fennec however. it has a high rating on the play store.a 4.5 stars. it works very well too, much better than chrome has for a long time.
Agreed. Sweeping generalizations about Mozilla and subjective discussions of Firefox's UX have nothing to do with a public dialogue about evaluating Persona's current state.
I simply don't understand this blog entry. I guess it's their official project resignation... OK. Even so, it seems misinformed about the adoption problems. Persona, to me, seems a truly lovely solution to a difficult problem. It was successful, just at the beginning of a hard adoption curve.
What's missing is fully functional, advertised implementations of the Service Provider, that work with LDAP and ideally older Kerberos backends. What's missing is the native, built-in interface. What's also missing is a SLA... big players can't adopt it unless Mozilla says they are going to support it. What's missing in Persona is a promise to have the code security audited and get it passed federal agencies. What's missing is some grass-roots effort to get it into universities.
What they list as failures aren’t exactly. So, there are some UI issues.. but those aren’t the problem. The Persona service was meant as transitional, till native implementations appeared. It's not going to adopt itself, they need a "Sales Engineer" full time working on adoption. Hell, they could even charge people for that sales engineer and many would pay for it. The alternative to Persona is Shibboleth/Kerberos, and Persona kicks it.
Note that this isn't a blog entry, it's a wiki page. We (Mozilla community) often use the Mozilla wiki as a place to store long-term notes or information.
Barring vandalism (which this isn't), you can think of it as a public internal wiki for Mozilla, that has pretty much everything we're allowed to make public (Unlike HR stuff for employees, which goes on an internal wiki) that we want to write down.
(This doesn't address your argument, just wanted to clarify that)
I admire Mozilla's openness, and the existence of TFA is an example of that, but in this case it amounts to really poor communication with the rest of the world. Why all the past tenses? Would it have killed anyone to say "What does Persona get right?" or "Why has Persona failed to gain wide adoption so far?"
The whole attitude here is bizarre. It seems Persona is supposed to have taken over the world by now, while in reality it's not clear that it's even in beta, let alone out of it. E.g., we're supposed to get the javascript lib from one place only, because we're warned that the protocol could change in breaking ways at any time. Let's get to version 1.0 before complaining that facebook hasn't been driven out of business!
I support the recommendations to simplify and get rid of sessions.
So, to confirm, is it a post-mortem or not? I'm about to launch a fairly big project using Persona and would love to know if its a bit to get shut down..
So far, it seems to me that persona is an incredibly useful technology in our space (Enterprise SAAS apps). Our space is populated by lots of apps that have various shitty login systems, but one thing they pretty much all have in common is an email address - and Persona seems to be a killer SSO system for securely leveraging/livening up these existing databases of email addresses.
Unless I'm missing the point, I don't see much alternative either. Just looking at the traffic from the Persona communit reinforces to me that I never want to be building my own authentication system - even if persona were to die as a project I would be better off cloning it than writing my own (or giving in and using social login, which is pretty undesirable in the enterprise world).
If that's what I need I'd rather use WS-Federation or SAML. Both have been around for longer, and I consequently have a lot more faith in them. Sure, they're XML-based, but that's quite ok for what I'm getting.
With all due respect you probably do not work in an institution where you have to rely on SAML for day-to-day operations (I work in a uni, so Shibboleth). If you did, you would realize why SAML is lauded as a great solution, but in reality can be very fragile and needs to be rolled out all or nothing. I have been part of a multi-year piecemeal deployment and it has rough edges.
I have, and know exactly what the issues are. It's why (if given the choice) I prefer WS-Fed and Active Directory. ADFS 2 for .Net is phenomenally good.
Service Provider is usually a synonym for Relying Party (RP), which is the service that's relying on your authenticated identity, typically a web server.
I think they're spot-on with the idea that it needs to be integrated into sites rather than appearing as a separately branded popup.
I tried it out on a site I was building a couple months ago. Every time I had a non-"techie" user try it out, they got confused. What's this popup? What's Persona? What am I signing up for exactly? It was just bad UX.
That said, I think there's a very real need for what they're offering. I don't want to store passwords myself, even if they're hashed. I also don't want to re-implement forgotten usernames, passwords, reset emails, etc. It's a bother, I'd rather focus on my app rather than a solved problem like this, and to be honest I don't quite trust myself enough to get it 100% right.
So, I think it would be the best of both worlds to offer auth as an API rather than providing their own experience. As in, I could just call Persona.login("username", "password", ...) and get back an assertion. I really hope they go in this direction.
UX is one major problem with Persona. I built a small site that used Persona a while back (without offering any other login choices) and most user can't figure out how to sign up.
Facebook login as a separate brand works because user already knows and uses Facebook. This is completely opposite in Persona case. User don't already have Persona "account" and they don't understands why should they sign up for it.
IMO, Persona should aim to replace classic login instead of social login, e.g. by making Persona nearly invisible to the user.
Heartily second the idea of Persona being re-rolled as classic login replacement, with emphasis on standardizing login best practices, such as password strength, password format disclosure, input naming that plays nicely with other password management systems, etc. The sheer amount of cruft and non-standardization involved with basic site login actively discourages user involvement. If Persona solved that unobtrusively, they would be adopted and evangelized all over the land.
And I'll 'third' the suggestion. Would love to see a SSO option that didn't bleed private info and wasn't linked to someone trying to make money from my data.
Could we please consider not implementing something completely new, but fixing TLS client certificate auth, finally making it usable? Every browser out there supports this already, but UX is horrendous. All what was relatively polished over the years was the presentation of server certificate when you click on lock icon in location bar. The rest (selection of client certificate, generation of a new one, viewing a backing up of installed ones) remains needlessly scary to use by ordinary humans, so it can't be used except if we know users are quite tech-savvy.
Instead of bringing a new technology with known downsides (like https://news.ycombinator.com/item?id=7219034) we could give a second life to a known and provably working one. Doing so we could promote security (HTTPS), anonymity (not giving email address by default, unless one's provided with a signed certificate, chosen by user's decision) and independence from any service providers (including email and domain registrars) at the same time.
I rejected Persona out of hand at the time[1] for the design gaffe of using HTTPS at the root of a corporate website[2] (worse, via a DNS apex A record[3]) as the identity-provider infrastructure discovery mechanism.
I haven't reviewed the protocol since maybe a year ago, but my view then was that system administrators within enterprises could only adopt Persona as identity providers if federated discovery was via records in the DNS, as the lords of protocol design intended, preferably SRV records at that.
Not the only barrier to adoption, perhaps, but definitely one of them. No-one substantial was likely going to use anything but the Fallback server, and there is no commercial reason to choose that rather than social-media-SSO where you'll enjoy the marketing bonus of reaching their outbound feed.
[2] a !! blunder because marketing won't let you in many organisations. also because most sites won't even have a port 443 https listener, let alone a valid certificate, on the apex A record. all this indicative of lack of real-world experience by the designers.
The verification, the trust, comes from TLS with a valid cert, and that doesn't change, however you located the https listener in the first place.
Even better, though, if you did use DNSSEC you can validate a self-signed cert via DANE/TLSA rather than having to buy one from CrappyCA. And that would make the ISPs very happy.
As I explained in issue 1523, the above is misunderstanding Persona and conflating various issues, and is wrong. Pretty much the only way Persona uses DNS is to perform an A lookup to get the user's domain, which could be SRV (or have an SRV fallback instead).
The issues above talk about delegation, which is a whole other matter.
No, that is exactly what I'm saying. It should be an SRV lookup to find the support document. This solves a lot of problems. No misunderstanding here. You may actually be in total agreement with me.
I am in agreement with you, but the misunderstanding is about DNSSEC, etc. The only reason SRV records are not used for that is probably that nobody suggested it (it's a good idea, you should probably open an issue).
I agree with the first part, and was also puzzled by the second part. Are you guys dropping it? I don't think there was enough of an effort made to consider it a failure, creating a new login system for the web won't take three months.
If it were truly useful, it would have generated its own promotion. It'd be more like the early years of Firefox, where the benefits it provides are so overwhelming that the early adopters are very willing to spread the word and get others to use it. But Persona clearly isn't that useful to enough people. Even those who've known about it for a long time now just haven't found it practical enough to try to get others to use it.
Another point. Not everything is web-based (I know it might be hard to believe at Mozilla), and the fact that you have to use javascript to access the API is also a limiting factor.
When I first looked at Persona/BrowserID eons ago, there were non-web ways to use it. I remember some examples given that worked in a terminal or with an embedded device.
Well, we did build a Persona SSP so you could use it with Outlook, Exchange, CIFS. The protocol spec is in draft-howard-gss-browserid. Very little interest though.
I've been waiting for a solution for non-browser use-cases before exploring Persona/browserid. I've never seen a hint of this drafts existence on the Persona website. In the presentations I've seen, Mozilla personnel have never mentioned this or have indicated that no solution is available.
Maybe I've looked in the wrong places or have not been paying attention, but it seems to me like there's a communication gap here.
I really like Persona. I use it (with the browserid gem for sinatra) for a couple of my side projects, as the only login option. It works great when it works and developing without having to bother about password management is great, though I first had to get my head around how that concepts works, serverside, that I have to remember an email address of a user in the database to assign him special rights (example: admin of a blog). What I didn't like, though granted, some of that is not very universal:
1. I made a small user test with it, and all user failed to complete the login, iff the email was new to persona. Because then, the new account has to be activated by email, and the link in that email lead to the persona account management. All users were confused by that and asked for confimation what to do, when confronted with the email confirmation message, and all of them got stuck in the new tab with that account management and were unable to return to the registration page on its own.
I understand that it is possible to change that link, though I didn't find that parameter at that time and marked it as an issue to fix later (A quick search just now showed nothing). And it might be a gem thing. Still, bothered me.
2. I would have loved a demo mode that works offline (maybe that exists?). Had spotty internet for a while and it was very bothersome to test the persona part of the project, as the registration/login worked only every 10th time, if at all. That was so cumbersome that I stopped working on it till I got a better connection. Which also means that a user with a bad connection won't have fun with persona, not resilient enough.
3. I don't like that the name was used for another FF-Project before (FF-designs, if I'm not mistaken) - if that confused me at first, it might confuse users. Have no better alternative though (maybe I would just brand it Email Login).
4. The browserid-gem for sinatra doesn't work with ruby > 1.9.3, and the maintainer does not fix the issue even though there is a working patch in a pull request. So instead of just having to specify the gem in my gemfile, I have to provide the link to the alternate github implementation. I hate that, that does not feel safe. I tried to look up how a gem might be replaced with another one and found nothing about how that (or the gem infrastructre in general, note that this was while having no really usable internet connection) work.
The page is more positive than the title. It recommends:
* Persona should be pared down to its core: a decentralized email verification and login API for the web. No more session management, no attribute exchange.
* Persona should be built natively into Firefox, Fennec and Firefox OS to make the JavaScript shim unnecessary on these platforms. The base functionality should be cross-browser, but the experience should be optimized for the native platforms.
* Sites should control most of the user flow and Persona should be almost invisible to users.
* Sites should be able to offer these benefits to their users with a native UA implementation: better UX, reduced login friction and phishing protection.
All of which sound great!
BTW, has Persona reached 1.0 yet? Last I was aware, it was still in beta, which might partly explain the lack of adoption.
It failed to get wider adoption because the average consumer doesn't see the problem they solve as a problem. There's a far small potential userbase who recognize the privacy benefits of the Persona system.
Which they can already do with accounts they most likely already have: Facebook, Google, Twitter, LinkedIN any OpenID provider... So the only potential benefit of Persona is the privacy, and if a user doesn't care about that then it's just another account you have to worry about (i.e. the very problem it tries to solve). As it stands, Persona's problem is that it just reinvents the wheel with slightly different spokes when people already have wheels that they consider good enough.
What did it get right? It can be useful and it's backed by a solid brand.
Why did Persona fail to gain wide adoption? For the most obvious reason: because nobody cares. People don't want to use something new unless there's a pressing reason. Trivial conveniences don't cut it.
I don't see the point compared to having separate logins so if one is compromised, others aren't. Even past that, that space is already hugely cluttered with OpenID, OAuth, Facebook, Gmail, Twitter...
I disagree. Facebook connect, google+ sing on, sign on with Twitter, and username / password reuse all demonstrate the demand from 'normal' users for a SSO solution. There is also a distrust of these companies and the lock they have on your data so I believe there is room for an SSO solution that doesn't leak private info.
Unfortunately for Persona a simple, fast, convenient user experience is not optional and that is where Persona has failed. I also believe getting to a great UX will be difficult or impossible with the decentralized system currently behind persona.
"We made Persona a user-visible brand but that competed with a site's own brand."
This would indeed have been the main reason for me not to use it. I have not been in a position to implement login functionalities recently, but when I do, I will still strongly consider Persona, and even more so if the Persona brand can become almost invisible as it says in the post.
That's a good point. To delegate your sign-up/log-in to a third party, you have to put some degree of trust into that service provider. The numbers show that most people "trust" Facebook, Google and others enough to do so.
The idea of removing the need for trust is elegant and some of the technical folks do appreciate it. However, it's difficult to communicate that to the wider audience, especially since it is not really aware of there being an issue with that.
Firefox Accounts is a step into the right direction regarding this, so let's see how this goes.
Unlike 'mozilla' or 'persona', firefox is a household name. I think people would be willing to sign up for "firefox identity" to use around the web, and the persona project should capitalize on that.
People use fb connect because of the combination of ease-of-use and trust. Persona has the ease-of-use but users don't recognize it as trustable.
What is needed to push it further is a landing page to "create firefox identity" and a campaign to push it as "the nonprofit, safe authentication provider". Instead of trying to make the protocol completely transparent, it had better be promoted as a recognizable identity provider
Couple that with spreading persona servers as far away from the NSA as possible and transparency that guarantees that data are not being logged by mozilla, and i can see "firefox connect" being a legitimate fbconnect and twitter-sign-in killer
I don't know whether it is my Internet disability manifesting, or some kind of weird region limiting or sth., but in last 6 months I tried to create a "Persona account" several times, followed the instructions precisely, and always ended up with a nonexistent "register"/"create account" button.
Was Persona account creation disabled at some point in time? Why wasn't it clearly stated anywhere on the page? Or am I that stupid and can't see a register button?
This highlights another one of the problems, which was explaining what Persona was to people.
See, there's _technically_ no such thing as a "Persona account". Persona is a system that lets you log in with an account that works with the system. Someone who provides an account that supports Persona logins is called an Identity Provider, or IdP.
However, most places don't work with the system when it first comes out, so Mozilla provided a "Fallback IdP" that just did straight up email verification. Getting your account from the Fallback IdP is what you probably wanted to do, and AFAIK the only way to do that was to essentially attempt to login with an email that didn't have an account with the Fallback IdP, which would trigger the verification step for you to create an account.
This is a bad mixture of a) A confusing concept that's really hard to explain, and b) Bad UX around the fallback IdP and getting an account with it, especially if you don't assume clicking "Sign Up" will work for you.
It's complicated by the fact that, if one of your goals is to get other login systems (like Facebook or Google) to support Persona as an IdP, you don't necessarily want to push people towards creating accounts with the fallback.
It's hard to get all these things right, and I agree that Persona needs some more work to find a good solution to the problem of creating accounts that work with Persona.
You hit the nail on the head here. I'd add that if part of persona's success is tied to getting email providers to adopt it by becoming an IdP then it's likely a flawed model. Why would google support/promote something that competes with Google+ sign up bit offers a poorer ux and robs th of the data they crave?
Users are very much accustomed to accepting the security and privacy implications of conventional web logins. Persona promises to improve on that by introducing itself as a third party. However, users with a trace of security awareness will be skeptical of promises like that and will subconsciously do a simple equation in their heads: if everything else fails (the promised improvements), then more involved parties imply less privacy/security. Getting beyond that point requires at least a level of understanding that allows for a rough estimation on a scale between "totally bogus" and "this might actually work if done right".
I'm not sure why I don't see other people complaining about this but I myself tried to be my own Browser ID provider and after trying to install it for a couple of days I failed. Now I still have to use it with Persona which is just another centralized login system.
When Persona was released, they split the FOSS crowd between OpenID and Persona adoption. Having two similar tools that solve the same problems (regardless of which one is better) did nothing beyond create two incompatible camps, each advocating for one while discouraging adoption of the other. I see it as a rather large blind spot of Mozilla to not recognize this.
As an administrator, I would also like to complain about this behavior from a practical viewpoint. Spending first mindshare and time implementing OpenID to solve a real problem, Persona came like an unwanted alternative to a solved issue. Had they joined like an upgrade (i.e. backward compatible with OpenID), my reaction would to be an advocate rather than skeptic.
When Persona was released, OpenID is already dead. I implemented OpenID on a few sites (I was an early proponent) and had nothing but trouble. Nobody could remember their OpenID URL, whereas everyone knows their email
address.
Tried to register on forums posted here as an example of Persona integration. Have gmail email, so no password authentication (OAuth or OpenID instead.) Did not work due third-party cookies blocked in my browser. Sorry, this is not going to work for me.
"Users and developers trust Mozilla and want us to fix identity on the web."
Maybe it's just me, but I trust iceweasel, a firefox derived browser that originates from Mozilla, but their continued increased interest in accumulation of browser and user data (albeit more anonymized than google et al), does not lead me to trust them.
I accept persona is designed to protect against id-provider leakage, but when my id provider also has hooks to my browsers anonymous statistics and crash logs - I don't accept it's really private or trusted. (Same reason I don't login to chrome either...)
I don't find Persona compelling, but I do think they offer an interesting value proposition for people - and framework developers - who have to implement their own user authentication.
Even Django - which is about as close to the proverbial bicycle with training wheels as you can get - can be a pain, especially after django-registration was abandoned. The Django documentation was never really good either, to make matters worse.
It also makes writing guides that much simpler, so although Persona doesn't hold much sway in a vaccum, it's great to have as a pragmatic option.
what would make Persona a killer solution for me is if it could hand out disposable email addresses to every site I sign into, that forward transparently to my main address (a la Gishpuppy). This way, I can identify which site is the cause of me suddenly receiving a bunch of spam (whether they're doing it themselves or their email database was hacked). Then its a simple question of disabling that disposable address from forwarding to my private one, and notifying the site that their database might be exposed.
It sure reads like that. What the heck‽ It is a good system and just needs continued work and support. This is a very poor way to announce a discontinuation or a very poor writing style for a reflection on an ongoing project.
So I want to use Persona. So I go to https://login.persona.org/ and there is no "Sign Up" just "Sign In". So I enter my email which is through GMail and it is asking me to choose one of my Google Accounts.
1: I want Persona not permission to use my Google Account with another service.
2: I entered an email why would I want to use a Google Account with a different email?
1. It's decentralized; email providers provide the authentication. Google doesn't directly support Persona right now, so Mozilla is supporting them via an Identity Bridge that hooks into Google's OAuth functionality. Google doesn't see what site you're signing into, just that you logged into a thing using Persona. Before Identity Bridges, you had to click a verification link in an email; this is a lot better.
2. I don't think Google exposes a way to use OAuth and skip past the list of accounts.
It does seem inelegant that I can't seem to avoid having two sessions: Persona's and whatever I have for my site. I'm not sure how the two ought to be combined, or even if the Persona session is necessary. I guess maybe Persona can just confirm the email association whenever the site requires it and just stay out of the loop otherwise.
It is really great that they have guts to admit the failure. Though this confession is a bit overdue, I hope they've learned the lesson and some day will come back with a better solution. No doubt that the problem is really worth solving.
I use it on several sites, and it works quite fine, The problem is with users they are so used to registering with "omgonies/1234568" into sites that federated login is weird to them
for the record the main reason for adoptions issues around me seem to be:
i got a fb/googke/twitter account that let me login too. i aint making a new account/pass. privacy? i care but not enough for that
That quote is alarming to me, because it fundamentally misunderstands why companies choose to use Facebook Connect. Absolutely no B2C company in the Valley has ever decided to use Connect because it lets you slurp in demographic information. They do it because of a) a mostly mistaken belief that it increases conversion rate to a signup and b) a mostly accurate belief that after you get someone to Connect you're going to be much, much more successful at getting your content on their wall as a viral distribution mechanism.
There are plenty of situations when using Facebook Connect is inappropriate. If I wanted to look professional, I wouldn't associate myself with fb (Is that a personal perception or is it shared among the public that Fb is intensely a consumer platform?). If I wanted to have control over my own assets, including the userbase, I wouldn't use fb.
Even if you look into consumer market, Snapchat went out of their way to _avoid_ Facebook Connect.
So I think Mozilla could have done more marketing against Facebook Connect.
Most users have a facebook account, supporting a facebook oauth sigup/login flow means one less set of credentials the user has to remember. It simply reduces the barrier to entry into an app for the average user.
Huh, I never saw them as competing with Facebook Connect.
I use Persona as a way to login to our blogs admin, and it is just so easy to have an array of white listed email addresses in the config and not have to worry about the rest.
With Facebook Connect you have to have a Facebook account, with Persona you do not care.
I don't see why you shouldn't let people add a small amount of personal data to their personas at their own option. I'd like to see public key/profile picture/blog url.
For our use-case Persona is great. I've personally built the "web account" solution several times for different clients and I did not want to build it again. Persona is the lightest drop-in and easiest to implement solution you can imagine, and it works extremely well.
We've had a couple of issues, but nothing of significance. Mostly these have been us doing things unexpected, i.e. pre-loading user accounts obtained face-to-face and the case of the user@ part of the email address differing from the Persona provided email address.
I personally also wish that persona.js is added to CDNJS to increase the speed by which it's served.
What we found through asking, was that people feel very protective of their Google, Twitter, and Facebook accounts. They will sign in with them, but there's a wariness of doing so as they do not want to be spammed, have things posted on their behalf, etc. These fears mostly apply when people first arrive on one of our sites. We wanted a lower friction to that initial sign-in, and we feel that Persona gives us this.
We also found that on interest-based communities there is a reticence to associate real-identity to the nerdiest of their interests. This meant that not using Facebook and Google is a good thing in our scenario.
One of the things we like about Persona is the user experience. For our product, simplicity and ease are core goals. Persona helps rather than hinders on this front.
We really like Persona and hope that it remains under active development for a long-time.
We are not of the belief that it's failed, simply that it's a slow-burner and needs some marketing support.