4 ms·

In these cases it's really helpful to recognize the distinction between the Mozilla Foundation (MoFo), the Mozilla Corporation (MoCo), and the broader, open sou

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

rfk 11y ago
> 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.
- WorldMaker 11y ago
  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.

rfk 11y ago

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

WorldMaker 11y ago
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.