5 ms·

I'd highly recommend taking a look at the talk "Designing for Failure" by Dan Callahan, a former Mozilla developer on Persona: https://www.youtube.com/watch?v=3

I'd highly recommend taking a look at the talk "Designing for Failure" by Dan Callahan, a former Mozilla developer on Persona: https://www.youtube.com/watch?v=3dDGkLHOldw https://www.youtube.com/watch?v=3dDGkLHOldw In it, he made a very compelling case on exactly why developers within Mozilla considered Persona's design to be fundamentally flawed beyond a point where it was worth expending the effort and resources to promote and pursue further: Persona had a "intractable point of centralization" designed into the protocol in the form of the fallback relay that defaulted to login.persona.org. Eventually, the browser was supposed to integrate this functionality and act as this relay, and in a perfect world where Persona is standardized and available in every browser, the fallback relay could, in theory, no longer need to exist. However, the harsh realities of the web platform unfortunately means that day may never come, even if Persona were to become reasonably successful. There will always be a significant portion of users who remain on older browsers that won't necessarily support the newest features, either by ignorance or by necessity, and very few serious web products are going to risk closing themselves off to such a significant potential source of visitors/revenue just to make use of a shiny new browser feature. This is why most web developers' adoption of ES2015+ are limited to those features where transpilers and polyfills are available (see the abyssmal adoption rate of ES6 Proxies, despite longstanding support in latest versions of major browsers, as an example: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...). This means that Persona would need to have the login.persona.org fallback available and supported indefinitely in order to have any chance of widespread adoption by developers, which brings us back to the point on intractable centralization: Nobody asides from Mozilla can meaningfully host a fallback relay for Persona without having to also fork the Persona community, because Persona was not designed to allow for any possibility of fallback-relay negotiation between the client (the app the user is trying to authenticate with) and server (the server providing the Persona identity) directly, mainly out of the very noble intention to prevent any loss of user privacy that might result from allowing the client to exchange user info with the server directly (the browser or fallback relay was meant to serve also as an additional layer of security and a gatekeeper to confidential user info). Ultimately, Mozilla had no choice but to become a single point of failure on a critical piece of authentication infrastructure for the internet if Persona were ever to gain widespread adoption, and this certainly didn't fit with Mozilla's vision for an open and decentralized internet. The team eventually realized this, and ended up winding down development and support for the Persona platform at least in a large part because of it, in hopes that other projects would learn from its mistakes and flourish. Unfortunately that hasn't happened yet, and I think it has a bit to do with the fact that the team's learnings got drowned out in a perfect storm of negative publicity in response to their dropping support for Persona. Apparently the concept itself was quite well loved among developers, despite issues in this particular actual implementation, which is really the silver lining here, and is what makes me really optimistic about the future of authentication on the web. Dan lamented in the video that "if we hadn't been within Mozilla, we wouldn't have been so audacious as to have predicated the design, predicated the decentralization of the system, on the browser natively implementing our protocol... I honestly think this is something that could have been solved in a different way if we weren't a browser vendor. We were blinded by our context." It's a really poignant point, in my opinion, and I completely agree that the right way to approach a problem like this is to first develop a solution that can stand on its own merits with or without browser support, then proving itself to be decentralized and open enough to support a rich ecosystem of competing service providers and implementations, and compelling enough to gain widespread adoption. While browser support could and should be obviously beneficial in terms of providing a more streamlined UX, predicating on it opens up the possibility for very severe failures of the imagination, as the Persona team has learned. And if a solution exhibits all the properties I just mentioned, then it becomes a very natural candidate to base a browser standard proposal on, because these are the very same properties that are often deemed most desirable in real web standards to begin with. I personally can't wait to see what comes out of the current project Dan's working on, Portier, which is positioned to be a spiritual successor to Persona: https://portier.github.io/ https://portier.github.io/

vertex-four 9y ago
The issue, of course, is that web technologies outright don't allow true decentralisation - there is no way for arbitrary web pages to ask the browser "who is the identity provider I should be talking to?", or to make a request of such an identity provider. This has been a problem for a number of years - the OpenID Foundation's hack is "Account Chooser", a centralised website that keeps a list of accounts for a given browser in localstorage. Being able to click "log in" and have logged in, and having functional single logout, with a decent UX over the whole thing, is the holy grail. Facebook has the current solution, and browsers don't. Portier does not even attempt to solve the same problem as Persona did, and by being a "self-hosted" application, it can't.
- lewisl9029 9y ago
  I'm not quite sure what you meant by "true decentralization", but even if some arbitrary ideal of maximum decentralization isn't possible on the current web, I think it's still worthwhile to strive for some degree of decentralization over none. And many technologies on the web do in fact offer varying degrees of decentralization through federation and interop, with email being the canonical example. And the use case you mentioned, for an arbitrary web page to ask the _user_ (because there's no reason why the browser absolutely needs to be an intermediary here. More on this in a bit) who it should be talking to in a decentralized manner, has been a solved problem for quite a while in the form of the WebFinger standard, whereby the user simply needs to provide an email address from a provider that implements the protocol on its domain (though it's not often used as a standalone protocol, it is actually quite well adopted as the discovery mechanism behind OpenID Connect, and I have used it in practice through the remoteStorage project: https://remotestorage.io/ https://remotestorage.io/). Portier certainly doesn't claim to be trying to copy Persona's approach to authentication on the web exactly, and specifically it makes a conscious effort to avoid predicating the system's usefulness and any of its fundamental design considerations on native browser support (that's of course not to say that they would refuse to integrate with browsers if the opportunity does eventually present itself), a decision that stems from the lessons learned from the failures of Persona: https://github.com/portier/portier.github.io/blob/master/Non-Goals.md https://github.com/portier/portier.github.io/blob/master/Non... At the end of the day, Portier strives to succeed Persona as an authentication mechanism, not as a browser-integrated authentication mechanism. And Facebook's current "holy grail" UX around authentication is living proof that you don't need explicit browser support to provide a great auth experience for the end-user. Whether Portier can be successful in replicating an experience like Facebook's while providing a useful degree of decentralization and user privacy as its mission statement declares remains to be seen, of course.

vertex-four 9y ago

The issue, of course, is that web technologies outright don't allow true decentralisation - there is no way for arbitrary web pages to ask the browser "who is the identity provider I should be talking to?", or to make a request of such an identity provider. This has been a problem for a number of years - the OpenID Foundation's hack is "Account Chooser", a centralised website that keeps a list of accounts for a given browser in localstorage. Being able to click "log in" and have logged in, and having functional single logout, with a decent UX over the whole thing, is the holy grail. Facebook has the current solution, and browsers don't. Portier does not even attempt to solve the same problem as Persona did, and by being a "self-hosted" application, it can't.

lewisl9029 9y ago
I'm not quite sure what you meant by "true decentralization", but even if some arbitrary ideal of maximum decentralization isn't possible on the current web, I think it's still worthwhile to strive for some degree of decentralization over none. And many technologies on the web do in fact offer varying degrees of decentralization through federation and interop, with email being the canonical example. And the use case you mentioned, for an arbitrary web page to ask the _user_ (because there's no reason why the browser absolutely needs to be an intermediary here. More on this in a bit) who it should be talking to in a decentralized manner, has been a solved problem for quite a while in the form of the WebFinger standard, whereby the user simply needs to provide an email address from a provider that implements the protocol on its domain (though it's not often used as a standalone protocol, it is actually quite well adopted as the discovery mechanism behind OpenID Connect, and I have used it in practice through the remoteStorage project: https://remotestorage.io/ https://remotestorage.io/). Portier certainly doesn't claim to be trying to copy Persona's approach to authentication on the web exactly, and specifically it makes a conscious effort to avoid predicating the system's usefulness and any of its fundamental design considerations on native browser support (that's of course not to say that they would refuse to integrate with browsers if the opportunity does eventually present itself), a decision that stems from the lessons learned from the failures of Persona: https://github.com/portier/portier.github.io/blob/master/Non-Goals.md https://github.com/portier/portier.github.io/blob/master/Non... At the end of the day, Portier strives to succeed Persona as an authentication mechanism, not as a browser-integrated authentication mechanism. And Facebook's current "holy grail" UX around authentication is living proof that you don't need explicit browser support to provide a great auth experience for the end-user. Whether Portier can be successful in replicating an experience like Facebook's while providing a useful degree of decentralization and user privacy as its mission statement declares remains to be seen, of course.