Yet Another Sign Up (Why Isn't Open ID More Popular By Now?) | Hacker News Reader

Yet Another Sign Up (Why Isn't Open ID More Popular By Now?)

blog.amir.rachum.com

13 pointsNurdok38 comments

It's common knowledge now that OpenID has severe usability problems. As much as I wanted it to work, none of my apps' visitors (hell, back in 2006) could understand what it was or how to use it.

BrowserID, however, has now fixed most of these issues, and it's very straightforward to use. To try it out, you can have a look at http://www.yourpane.com/

I just never understood how the hell it worked.

1) I would go to a website, it would ask me to register or sign in with "OpenID". It would tell me a little bit about OpenID "Yahoo, ___, and ___ are OpenID providers. If you have a Yahoo ID then you have an Open ID".

2) WTF is the point of an OpenID then?! If I could just sign in with a Yahoo account I thought...

3) I try to sign in with my Yahoo ID like it said. It fails every time. WTF.

4) I go back to Yahoo to GET an OpenID. It tells me I already have one. I try to get one from other "providers" and somewhere along the way I always get misdirected or the sign up / registration process just fails and I just get sick of the whole OpenID-Mind-Game and sign in with my facebook account.

After 3 or 4 mind games I became extremely frustrated and soulfully HATED OpenID. It was all over the place, I didn't get it. It couldn't work for me. So I felt like it was a feature I was not allowed to have. Just thinking of the OpenID logo and name evokes feelings of annoyance. So the brand is trashed is what I'm saying.

This too.

And the so-called "informational" documentation on the OpenID project site is ... vague to the extreme, and that's being charitable.

While it's fine abstracting away technical information from users who don't want it, if you're going to create a Grand Unifying Identity Service, you're going to get much better buy-in from those who do care to find out about how things work under the hood, if you make it possible to do so (and without reading the source / diving fully into the developer docs).

OpenID is a trust dud.

"To log in, just enter your email address below and click the link that we send you. To log in again, you can save the link and use it directly (you don't have to request a new one)."

In what world is that more usable than "Click here to login with Google / Yahoo"?

StavrosK has a hybrid auth system -- that's not a part of Persona (née BrowserID). Which is actually kind of cool -- because we use email addresses as identifiers, it's really easy to add Persona support alongside traditional auth mechanisms, and without giving up ownership of your users.

If you want to see a more "pure" Persona implementation, our standard example site is at http://123done.org/ (and you can preview the "Persona" redesign at http://dev.123done.org/).

As for as being as easy for first-time users as "Click here to log in with Google / Yahoo," well, we've got some tricks up our sleeves. Look for a blog post next month at http://identity.mozilla.com/ :)

When are you guys going to add browser support already?!

Also, I love how I can integrate Persona with Django in (quite literally) three minutes, with zero changes to any existing auth mechanism.

Native browser support is slated for Firefox 17, though it'll be disabled by default for a while, much like with our SPDY support. Of course, native support in Gecko is a hard requirement for our Boot2Gecko phones, and the first big code freeze for that is rapidly approaching (mid-August, IIRC?), so it's absolutely on its way!

BrowserID is horribly complicated. Even to log into Mozilla's own Web Apps store. I had to remember my browser id, wait, enter it again and then enter a password. Why are there more steps to something so simple. It's for these reasons that no one wants to adopt these things.

Err, click the "BrowserID" button. Those are two separate auth mechanisms.

So I just signed up to your site with BrowserID, clicked the link in the mail they sent me, and got directed to... an almost blank BrowserID page.

You're losing users right there if it doesn't redirect back to your site after account verification.

I don't think they can do that, unfortunately. Verification is done when you create a BrowserID account, so it'll never happen again, no matter which site you go to next. You'll just get logged in.

Yeah, that totally sucks. We're working on it. Support for post-verification redirects should land in production in ~2 weeks, IIRC. There will be an announcement on the Mozilla Identity blog when that goes live. (Sorry to threadsit here!)

Actually yes, now that I think about it, you can just include the referring site in the verification link and redirect back. That will be very handy and help with the visitor drop-off problem.

I'm really hoping Persona takes off, especially with widespread browser support. Will it still need a third party service then, or will everything happen in-browser?

Also, in the step when you enter a password (to create a BrowserID), the second field is called "Reset password". What's up with that? Should it not be something like "Password (confirm)"?

Our translation files were messed up. The fix should enter production on Monday: https://github.com/mozilla/browserid/issues/1905 Thanks!

And why wouldn't I prefer to have a set of fully independent, unlinked accounts at different sites?

If I understand correctly, using OpenID means that Site A can confirm that User X is the same as User X on Site B, using OpenID?

I can see where that's a win for sites A & B. I can also see many instances where that is not a win for me.

If you use the same e-mail address to sign up for both sites, they can already determine this. The only way to get the anonymity you want is to create new throwaway accounts for each service. (I realize GMail lets you do things like + aliases, but these should be stripped when trying to match up users across databases.)

So let them, let them have to do that work and share email addresses, which would potentially be a PR nightmare if discovered, and users did not consent. I'd rather do that than willingly give multiple domains my ID letting one service unify them, and share my ID across multiple sits if the service chooses to. And who's to say people don't already use multiple email addresses?

Or run your own mailserver and hand out email addresses like servicename @ [yourmailserver].com

Everything gets forwarded to the same inbox.

tuffmail.com is awesome and cheap; I'm a happy subscriber.

I like 33mail.com.

or 33m.co for those quick to type throwaways.

That works? That's awesome, thanks!

Exactly. This reminds me of facebook and every site with "login with facebook" implemented. For example, I choose not to log into hulu with facebook because I'm sure its great for facebook to know what bad shows I watch to serve me better ads. But i don't need all of my friends and family seeing that information on their news feed. I believe Spotify forces this on their users and as a result i get the joy of seeing every song my friends listen to on Spotify.

That depends on the OP's implementation. Google, for instance, will return two different identifiers when the same user logs in to two different sites.

Of course, in reality, both sites will request your email address, so they can figure it out anyway.

That would only be true if both OpenID consumers published their user's endpoints

How is this different than correlating user names or email addresses? Especially given that most of the OpenIds out in the wild are specifically keyed off of email addresses anyway.

Who says I use the same user names or email addresses (particularly when making a concerted effort to divide my identities).

... Then you would have OpenIDs for those email accounts. Or you could just as trivially make throw away subdomains to use as OpenIDs with free providers. (There are several DNS providers with hundreds of free second-level domains that you can make as many subdomains as you like for free in 45 seconds.

Between this and your comments on G+, you seem really interested in villianizing your service providers when there are obvious ways to avoid their naive account associations [1], as you even take advantage of.

[1] I say naive because I would be willing to be a large amount of money that I could track you between accounts unless you're taking some insane precautions against it, even without an email address or OpenID url.

I suspect you could, or an entity with sufficient motivation could.

For casual purposes, which encompasses much of my present threat model, the measures I'm taking should be reasonably sufficient.

The point I and others are making is that:

0. There's a growing default assumption that individuals have no privacy, that privacy is dead, and that we should all just roll over and forget about it.

1. Even if you trust your service provider today, you may not trust them tomorrow.

2. Even if you trust your service provider, you may not trust those who have access to your data through your service provider. Intentionally or otherwise.

I'm well aware that roughly 32 bits of leaked information should be sufficient to identify me, if not precisely, then with reasonable accuracy. This doesn't mean I'm going to hand over my SSN and DOB to anyone who asks.

It may also be the case that I'm deliberately trying to create various associated identities.

That said: if you're interested in trying to link this identity to others, you can GMail me any of your prospective linkings.

Take this as a few bitter words from an "grumpy OpenID early adopter":

* because the user experience really requires you to have the "nascar effect" of several well-known icons. OpenID could scale horizontally technically but in fact it doesn't work that way. Except for a few providers (like Google) it is not "peer to peer" (many to many) but more like "business to customers" (one to many) relation

* because the "like"-generation beloved blue button talks something else (and is "way more important" than some technical nice thing)

* because it requires putting too many eggs in one basket (one ID to rule them all. And even "the few big ones" are these days hacked without problems)

* because your database of users is your asset (at least in the US). In EU it is more often a liability. * As this is an asset, nobody wants to pay anything for a secure identity as a TTP service.

* because it forbids "sensible" use on mobile devices (I have a phone and a PC, I would like to link my phone(s) to my services through numbers rather than on-phone cumbersome username or openid hack)

* pairing with a QR code works well for me. It even allows to establish a more meaningful key for further communication (I check the "green bar" of the browser than the underlying, semi-anonymous, DNS-depending OpenID)

* because OpenID does not really work for anything than medium-security identification transport. I hope my bank will never use an OpenID to authenticate anything.

* just try a new service with a throwaway account. or a throwaway password. Maybe one day people build services, which do not require pairing to "something" at all. Or Just use "click-the-link-in-e-mail-or-copy-token" approach.

> because the user experience really requires you to have the "nascar effect"

Seriously. I love SO, but this is one of the scariest log in pages I've ever seen: https://img.skitch.com/20120627-d49s8rqaeu5p5d3dkmn2p26tim.p...

At OpenRent [1], we use the google identity toolkit [2] and whilst it has a few quirks and bugs, it's been received fairly well by even our non-tech crowd. It uses email providers as identity providers - and is only as intrusive as inputting your email into a traditional log in box, just with much less friction, and without the requirement to remember another password!

I'm surprised it's not seen bigger adoption in the start-up crowd, but I guess it was slightly more work and isn't quite in-line with the MVP culture.

It also places a reliance on a third party - but in this case I expect good reliability from Google, and have a fallback option in place (both for availability, and to support older browsers).

[1] - http://www.openrent.co.uk

[2] - https://developers.google.com/identity-toolkit/

"It boggles my mind that this is apparently a big question for techies and, to me, is a perfect example of the Silicon Valley mindset that doesn't understand how to build products that real people want to use.

"The short answer is that OpenID is the worst possible 'solution' I have ever seen in my entire life to a problem that most people don't really have. That's what's 'wrong' with it."

http://www.quora.com/OpenID/What-s-wrong-with-OpenID/answer/...

The real question is why these guys didn't let you signup with Facebook.

The reason you dont see it mainstream is because for someone like my mom its too difficult to understand. She does however understand "Login with Facebook/Google/Twitter" because it is simple, one click, approve permissions and done. Anything more is just a hassle for them to remember and they will fallback to email/password instead.

And when you have more than one option, your users will start to make more than one account for your site.

Nothing is stopping them from doing that with Username/Password or OpenID. In fact I would argue that it probably happens more with the username method because users forget they have an account. With Google/Facebook/Twitter signin they click and that service remembers everything for them and sends it to the app for authentication.

There's no way to make everyone happy, but pretty much all the options suck. Setting up yet another account sucks. OpenID sucks because nobody intuitively understands it. My login is a URL?? WTF? Facebook/Google/whatever login sucks because some people don't have it and some people who have it don't trust it.

I don't have any answers.

BrowserId is another option that I'm rather fond of.

Reply on news.ycombinator.com