Liminal Existence

AccountChooser

Tim Bray recently posted about AccountChooser, a project that’s come out of Google and made its way into the OpenID foundation. Go read that post first, as this post is explicitly a response (as requested). Against my better judgement, I’m compelled to say something, because damn it, I actually care about this stuff and I think it matters. And I think AccountChooser is a terrible, counter-productive approach to solving the increasingly large problem of “identity”.

The problem, stated succinctly, is “how can we allow users to sign in easily, without requiring passwords?” The existing solutions are, simply: email+password (I’m not going to get into why passwords suck), Sign in with Facebook, Sign in with Twitter, and Sign in with Google. I’m not sure if anything else works in practice (maybe LinkedIn? Does anyone use that? Simon/Nat?). The latter three use open standards, but lack mechanisms for discovery and thus end up with a “NASCAR” sign-in interface. AccountChooser is an evolution of the XAuth idea (which was riddled with bad security problems, updated to address the security problems, but not the fundamental questions). It’s related to Mozilla’s Persona, but uses OpenID instead of Persona’s custom infrastructure.

Preamble finished, I think there are several key issues with AccountChooser, and I believe each one is sufficient to thwart adoption.

  • Design matters: AccountChooser hijacks your site’s design intent by placing an AccountChooser-branded page in every sign-in interaction. You can customise it to some extent, but the account buttons remain the same. Website owners aren’t going to be happy about giving up this level of control – I’m not, and I won’t implement AccountChooser for this reason alone.
  • It doesn’t work: When I tried to sign in to Tim’s demo site with two separate Google accounts at the same time, AccountChooser (not Tim’s demo, but actually accountchooser.com) failed. I didn’t even try to do anything weird! This is obviously fixable, but not exactly inspiring of confidence for the future, given that they’ve had well over a year to make this simple and primary integration work.
  • Browser independence matters: AccountChooser is premised on the idea that people can’t remember anything, and the browser can remember everything for them. Despite having a work computer that’s mine, a laptop that’s mine, a phone that’s mine, and a tablet that’s mine, each of those devices sometimes is used for others’ logins (guests, friends with dead/forgotten phones, coworkers, etc). AccountChooser doesn’t provide an easy path to temporary sign-in, and it demotes the user’s own sense of agency when signing in. Which of my six accounts did I use to sign up to example.com? Not sure? The solution: sign in to each in turn with AccountChooser, because the computer has helped me forget.
  • It’s run by the OpenID Foundation: accountchooser.com, the necessary gatekeeper domain to make AccountChooser work, is run by the unaccountable, corporate, 90% white, 90% male OpenID Foundation. There’s no option to change this, and there’s no story for why this is OK, or explanation for why it’s not. By centralising identity in a single domain, AccountChooser effectively thwarts user choice, and does so by placing control in the hands of people and organisations who are not user-focused and whom I actively distrust. I’ve made similar comments about Mozilla Persona, but at least I kind of trust the Mozilla foundation, and they have a story for how you don’t need to be stuck trusting a single domain that they own.

There are ways to fix this; most of them involve being smart about discovery and making things easy for users without locking those users in to any one solution. I’m trying a strategy that I think already works well at poetica.com, and I’m still improving it. In fact, most of the issues I’ve had are down to shoddy OpenID / OAuth implementations (and their implementors not listening to their customers).

I remain doggedly hopeful that we can fix all these things.

Comments