Designing for failure

Posted Jan 26, 2017 10:48 UTC (Thu) by ssokolow (guest, #94568)
Parent article: Designing for failure

I actively avoided Persona because the UX was accidentally hostile to users who give a different e-mail address to each site when they create an account.

(I don't like having to check a spam bin for false positives, so I've set up a system where e-mail aliases are treated as revokable API keys and, if I can find the time, I want to write a custom milter and browser extension to streamline and automate things even further.)

I was also holding a grudge that they'd "morphed" it from their 99% in-browser "Identity 2.0" plans which were slated to have the following benefits:

Unify the UX for HTTP basic/digest auth, "Remember Password", OpenID, etc.
Provide a panel-based login/logout UI that could be leveraged by HTTP basic/digest auth
Collaborate with the Google Chrome team to define a "this site's login API is..." HTML microformat that allows an in-browser login/logout UI to transparently learn new sites in a reliable fashion, similar to how OpenSearch allows the address bar to to transparently learn new site-specific search APIs.
Present an extension API that allows new authentication providers to be added to the browser's unified identity manager.

To this day, I'm still sore that such a thing never materialized when they seemed to have interest from the Chrome team at the time. The only thing that's really wrong with HTTP auth is that the client-end UX is terrible.

...and it also took far too long for them to explain how it was superior to OpenID+WebFinger. (Answer: The OpenID authenticator knows every site you logged into. A Persona identity provider doesn't.)