What did Persona get right? Why did Persona fail to gain wide adoption?
wiki.mozilla.org
wiki.mozilla.org
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.
I also wrote a post on how you can use it with disposable email addresses: http://www.stavros.io/posts/persona-accounts-disposable-emai...
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.
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.
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.
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.
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.
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.
That's how I read:
https://developer.mozilla.org/en-US/Persona/Identity_Provide...
anyway?
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]
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.
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.
Persona fails to solve a problem which either end-users or people who operate websites for profit actually have.
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.
Let's not forget that for a vast amount of people, this just means remembering a single username+password.
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.)
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.
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.
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.
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've also had a work email that was deleted (when I changed work), and a college email that was deleted (when I changed college).
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.
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)?
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.
I disagree. The end user benefits from being able to quickly sign up to a service without having to validate his/her email address.
The developers benefit from not having to store passwords.
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.
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)
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.
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.
It isn't: http://www.tomshardware.com/reviews/chrome-27-firefox-21-ope...
>Firefox' usage numbers are dropping
Numbers have mostly stabilized during last year: http://gs.statcounter.com/
>We see the same with Firefox Mobile. It really isn't superior to the alternative browsers in any way
It's the highest rated browser in the Google Play Store.
That said, I never understood the problem that Persona was trying to solve.
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.
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.
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
> Had Rust been more stable in 2012, maybe it'd be a
> different situation today.
> 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.
Your narrative really needs some rethinking!
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.
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.
That's huge.
[1] http://www.letscodejavascript.com is profitable enough to support me full-time.
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.
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.
What makes you say that? That certainly isn't my experience with Shibboleth.
We deployed our IDP in 2006-07 (I think) and slowly migrated services to it.
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)
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).
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.
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.
The rest, all good points.
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.
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.
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.
(Added after an hour) To illustrate my point: https://www.dropbox.com/s/fn4nuwszt5buuzd/tls_auth_ui.png (mad design skills and windows 8, sorry for both; wording is not changed but I suppose it needs improvements, too)
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.
[1] https://news.ycombinator.com/item?id=5447097
[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.
[3] a !!!! blunder see e.g. https://devcenter.heroku.com/articles/apex-domains
I just went looking. There's a whole thread over here: https://github.com/mozilla/persona/issues/1523 & https://groups.google.com/forum/#!msg/mozilla.dev.identity/d... where the developers effectively shitcanned the idea of using SRV records because they fear DNSSEC. Hilariously ignoring the huge elephant in the room viz. that they were already relying on DNS to resolve endpoints.
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.
The issues above talk about delegation, which is a whole other matter.
Also, why are you guys talking about Persona in past tense? sounds like you're dropping the project.
Most, if not all users have JavaScript enabled. The ones savvy enough to turn it off, will also be able to turn it back on.
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.
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.
* 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.
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...
Persona is a solution in search of a problem.
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.
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.
So I searched on Google, and this probably didn't help Mozilla: http://security.stackexchange.com/questions/5323/what-are-th...
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
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.
* we didn't give some people a way to join?
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?
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.
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.
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...)
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.
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?
2. I don't think Google exposes a way to use OAuth and skip past the list of accounts.
1. value proposition for developers was never clear
2. many saw it as a firefox only thing
3. chrome usage is overtaking firefox
4. I felt burned by developing for firefox in the past, why was I going to do it again (this is me personally, and is likely my #1 reason)
5. Never saw how it simplified my users lives.
6. I saw it as another waste of time like openID ended up being (and I loved the idea of openID, but so few people ever used it).
/rant
quote: We looked at Facebook Connect as our main competitor, but we can't offer the same incentives (access to user data).
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.
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.
- BrowserID has been renamed to Persona
- Personas have been renamed to Firefox themes
Yup.