Hacker News new | comments | show | ask | jobs | submit login

> I don't think any of the Mozilla-branded sites ever used it

You're right that AMO never used Persona, but a ton of Mozilla's other sites used (and still use) it. MDN, Bugzilla, Etherpad, the Firefox Marketplace, most of our metrics dashboards, etc. It wasn't a complete sweep, but we did see pretty solid internal adoption.

> after just a year it got unceremoniously dumped.

Longer than that. I think Lloyd and Mike hashed out the first version of the protocol back in March 2011. The bulk of the team came together around March 2012. Most of us were moved off the project in around November 2013, so we had closer to two years as an official project.

...wow, it really felt longer than that.

> I didn't want to invest a lot of time in an unproven technology.

That was a big reason we didn't go further than we did. People loved the idea, but relatively few folks were willing to actually back up that belief with action.

We also share some of the blame: We thought we had more time to experiment with the core protocol and product design, but with Mozilla Labs' somewhat sudden dissolution, we were unexpectedly asked to demonstrate traction and commercial adoption that simply wasn't there.




Dan, I know you are not to blame for this but I hope you can at least forward the sentiment.

I was at MozFest last year, with one of the execs on stage talking about Mozilla's efforts to "free the web". He went on and on for 15 minutes about it and I swear, the only thing on my mind at the time was how Persona had been gutted. Today's web isn't "free" if a core part of it is behind Facebook and Twitter.

> People loved the idea, but relatively few folks were willing to actually back up that belief with action.

Either Mozilla is full of it when they say they fight for the free web, or they massively misunderstand how important it is to get rid of proprietary authentication.

If this is Mozilla's stance, Mozilla's belief, then Mozilla is the one not backing it up with action.

Edit: Followup thoughts: I cannot get behind the way Persona was dumped. Firefox had an atrocious market share for many years, but devs didn't dump it. Persona can't revolutionize the web by taking down Facebook and Twitter in 24 months, and it's not good enough? Grr, there were at least a dozen other ways to stop spending as much effort on it without outright killing it.

> Maybe my attitude was a common one, and doomed Persona to a chicken-and-egg situation.

Yuuuup: https://bazqux.uservoice.com/forums/190752-general/suggestio...


In these cases it's really helpful to recognize the distinction between the Mozilla Foundation (MoFo), the Mozilla Corporation (MoCo), and the broader, open source Mozilla project that binds everyone together.

The non-profit Mozilla Foundation exists to support the project, and does truly wonderful, pure work on keeping the Web open. Advocacy, education, grants, etc. They also own the for-profit Mozilla Corporation, which is in trenches directly competing with other browser vendors to ensure that the project has sufficient influence to fulfill its mission.

Persona was housed in MoCo, which afforded it greater resources at the cost of greater organizational risk.

> Either Mozilla is full of it when they say they fight for the free web, or they massively misunderstand how important it is to get rid of proprietary authentication.

The Mozilla project is too small to fight effectively on every front; we have to focus on areas of greatest urgency and where we have the greatest leverage. In the instance of Persona, two major things changed: (1) Persona became less urgent, and (2) we discovered that we couldn't credibly leverage Firefox to boost Persona adoption.

To the first point, back in 2012 we were seeing huge startups, including Spotify and Pinterest, run without offering any means of authentication besides Facebook Connect. The lack of traditional authentication on these sites looked like an ill omen for the freedom of the future Web, but that didn't come to pass. Both sites now offer email-based authentication in addition to Facebook Connect. It's not as slick as it would have been with Persona, but the immediate threat to user autonomy isn't there anymore. If I had to guess, it seems like the tide started turning in late 2012 / early 2013, around the time of Mailchimp's "Social Login Buttons Aren't Worth It" blog post at http://blog.mailchimp.com/social-login-buttons-arent-worth-i....

Secondly, Persona's passwordless design wasn't suitable for use in Firefox Accounts, the development of which had become quite urgent. So not only could we not use Firefox Sync / Accounts to boost Persona's active userbase, the Persona team suddenly found itself with domain knowledge that was quite valuable to the Accounts and Sync efforts. Oops. :)

That said, just because we're not fighting as visibly on this front doesn't mean we're out of the fight altogether. Firefox Accounts has an active userbase orders of magnitude larger than Persona's. We may be able to reintroduce a notion of federated identity into FxA at some point in the future, which would help us break out of the "three-way cold start" that Persona faced.

But that's all hypothetical. If anyone wants to run with these ideas, do it! For the sake of longevity, I'd recommend any spiritual successors to either establish themselves within independent foundations, or design the protocol without the sort of centralized bootstrapping that Persona had.


> Firefox Accounts has an active userbase orders of magnitude larger than Persona's.

> We may be able to reintroduce a notion of federated identity into FxA at some point in the future

As a member of the team working on Firefox Accounts, here's one (hypothetical!) way that might play out in practice:

* grow FxA userbase to significant size, integration with Firefox to significant quality

* allow websites to add "log in with Firefox" via OpenID Connect and get a really slick experience for Firefox users

* influence OpenID Connect ecosystem to be more of a level playing field for smaller IdPs (e.g. increasing adoption of IdP discovery and dynamic registration)

* a win for openness on the web!

Not as big a win as widespread adoption of Persona would be, but a win nonetheless.

This sort of thing isn't exactly on our concrete roadmap, our short-term focus remains on supporting Mozilla's own service ecosystem. But be assured that it's on our minds.


Why fallback to just OpenID Connect? You could use a multi-pronged approach to prop up BrowserID using (continuing to use) OpenID Connect as bootstrapping fabric. Maybe along these lines:

* Merge the login.persona.org fallback login provider and Firefox Accounts (grows both userbases!); you'd probably need a nice path forward to FxA users with Persona-supported email accounts, but that may just be a matter of selling "Connect your FxA account to your Gmail account for easier password management; Here's how FxA will (not) use your Gmail information"; (worst-case you need to figure out the BrowserID protocol changes to allow individual email opt-out to a different provider. Maybe easy enough to do in the case of the bridge providers to Gmail/Yahoo as login.persona.org is already mediating that...)

* Use the Firefox Accounts "brand" for the fallback provider; this gives potentially a needed distinction between the fallback provider and the platform/tooling (so long as you can do user acceptance testing to maybe avoid confusing users), so that Persona <=> OpenID Connect as a developer brand and FxA as the consumer brand

* Setup an OpenID Connect proxy to Persona/BrowserID and call that the "Login with Firefox"...

A proxy could drop in to existing OpenID Connect workflows, but really be a wrapper around the BrowserID navigator.id. With Firefox Accounts as the main fallback this is still seen as "Login with Firefox" button This would require fewer changes to the auth code of existing websites (drop in next to your Google/Facebook buttons), but then as people get used to it you can start to encourage websites to "skip the middleman" of the Proxy and directly use Persona/BrowserID navigator.id to back that "Login with Firefox" button.

Maybe the only twist here would be a way for other browser manufacturers/plugin-providers to play in this space and keep the branding friendly. An idea might be to add a navigator.id.branding spec that if implemented could override "Login with Firefox" to show a "Login with Chrome" or "Login with Edge" button. The trick of course there would be balancing site CSS abilities and browser branding abilities. Doing so, however, would further reduce the need of consumers to know/learn/interact with the Persona brand and at that point they are just associating that button as the "browser login button". On the other hand, if FxA is the fallback provider it seems fine to just always have it say "Login with Firefox" and it may be less confusing that way, but with the original goals of BrowserID it might be nice to have it be browser/plugin-configurable solely for that reassuring "Login with my Browser" feel.


Two years is nothing for something that's supposed to go global.

For how long was CSS developed before there was large scale adoption? It seemed to be seemlingly forever people were doing table based layouts even after it was available everywhere, and it probably wasn't available everywhere until many years after its inception.

> relatively few folks were willing to actually back up that belief with action

Which in this case turned out to be the correct decision. Nobody wants to implement a dying technology, no matter how good it is technically.

Most generally wait until it is best practice among the bigger players until they implement something, uness there is a clear user need.


Great comparison.

As a sidenote, basic authentication is part of the HTTP standard, so suggesting a truly open, standards based way of identifying a user for the purpose of accessing a service/system is not such a crazy idea.

It's not a dying concept, so there's scope still there.




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

Search: