37Signals to retire OpenID for logins on May 1(productblog.37signals.com) |
37Signals to retire OpenID for logins on May 1(productblog.37signals.com) |
1) Tweet negative/positive questions about x.
2) Tweet negative/positive observations about x.
3) Tweet negative/positive observation backed by data about x.
4) Tweet article about how positive/negative x is on blog.
5) Take action about positive/negative x.
There is nothing wrong with it, and I don't know if its intentional but its super effective.
I certainly grew more confident in the decision to dump OpenID after talking with lots and lots of people on Twitter about it. You get to test your ideas, see what the feedback is, tweak, and retry. All while making the decision process public.
Surely you jest :) If there's one thing 37signals do extremely well it's getting people to talk/write about them.
I think there's a really huge opportunity in this space, and the first who'll be able to figure out the perfect (and, most importantly, simplest) way to offer a single-sign-on, integrating privacy and security features, will be hugely thanked.
InfoCard is surprisingly non-evil, and I also think Firefox is ideally placed to work on this (oh look, here's the solution: http://www.azarask.in/blog/post/identity-in-the-browser-fire... ), but they don't seem to care enough.
There are probably better news reports out there, but this is what I found with a quick google: http://www.commerce.gov/news/press-releases/2011/01/07/us-co...
What could have been done better?
I spent a couple of years advocating for OpenID adoption, because I believed that the alternative (one or two companies controlling login for the entire Web, ala Microsoft Passport or Facebook Connect) would be a massive blow to the decentralised nature of the internet. I believed that OpenID's usability issues could be resolved if enough smart people got involved in figuring them out.
Clearly I was wrong on that last point.
And yes, my latest project (lanyrd.com) uses Twitter rather than OpenID for authentication. From a developer point of view, that gets me the benefits I hoped for with OpenID (SSO, portable identities, instant contact lists) without having to wait for the world to agree on the standards. I just wish we could have figured out a decentralised solution.
Were there HCI experts a big part of the community that put together the vision and architecture? How diverse (tech background, language, age) was the original community? Both of those are areas that could have made a big difference.
It remains a great vision, so hopefully people will continue to work on it.
The problem with OpenID and other Open Web work IMO is the sheer number of half-baked specs brought forward. Much more than any other standards group. I don't know why. “The nicest thing about standards is that there are so many of them to choose from,” like Tannenbaum said. Perhaps there is a general lack of attention span, a ohh-shiny problem, a not-invented-here problem that is particularly rampant in this community.
I'll tell you what it should look like (the fact that it's impossible is not the point): whenever I land on a site that asks me to login, I get a menu of all my possible accounts, I pick one, and I'm in. End of the story.
Kind of like Dropbox being simple and intuitive when everyone else was building overly complex stuff.
I'd have tested the UI on my mom.
Solving that in a way that doesn't violate the privacy concerns of your users seems like something of a holy grail. Panacea if it exists, but far from demonstrated.
But using those services to check into the applications running your business? Fuck no. I'm certainly not going to let anyone depend on their ability to get paying work done by whether Twitter is up or not. And I know of plenty of people who aren't interested in mixing their private-life Facebook with their work-life accounts.
Then of course there's Google. I'd be weary to let a large number of customers be owned by that Gorilla.
OpenID was promising because it was an open standard, not controlled by any one party. But unfortunately it had the usability of your average open source project (acceptable for hackers, terrible for anyone else).
This might be the good middle ground between facebook login and an entirely new login... a facebook-assisted signup procedure.
Hmm nice !
There is no way OpenID can be improved when there is no interest in solving global internet issues. Neither Facebook for implementing the own mechanism nor 37signals would get medal of honor for uniting the internet.
If OpenID usage had been in any serious numbers, our support department would have revolted.
If you're trying to build a profitable online business, cutting your support costs is key. And the easiest way to cut your support costs is to dump confusing features or technologies that people constantly write in about.
Same reason we originally dumped FTP in favor of hosting files ourselves. The support costs were way too high.
OpenID was not successful in changing that equation.
RPX, by contrast, appears to have done so successfully for a lot of people.
The story of OpenID (not)success sounds like the html compatibility issue. Overall, time pass by and it starts shaping up. But probably no lessons learned from it (yet).
And when the big players are giving up on it no way small startups will be able to maintain, improve and support OpenID features.
Every time I see a web app supporting openid Im glad that I don't have to invent yet another user/password combo. again.
As to failing openid providers I have a good suggestion - use OpenId delegation to have a single openid that you can reroute to any openid provider you want. all it takes is a domain name and a very small file hosted on S3 (for example). Then you can switch providers at will.
The problem is most people don't bother doing this; they just trust every site with the same password. The benefit I see in OpenID is that it is not a secret, and canot be "compromised" (intentionally or not) in the same way as passwords.
(I also am one of the few, it seems, to use OpenID for my 37signals account)
Unfortunately, for this to work, several things need to happen:
1) Users need to learn what a private key is.
2) Browsers need to provide flexible, intuitive, easy-to-use user key support that's not tucked away in 3 levels of dialogs/tabs.
3) We need good key-management tools so I can log on to sites from internet cafes, etc (perhaps a session-lived key cache in the browser, with support for syncing it remotely?)
Every technology is new at some point. My thesis is that keys are not that hard and technical people should actually try to push understanding of them into the non-techie realm. If they fail, they fail, but if they succeed, it would make all computing so much more secure.
Edit: I should also point out that it's not really any more complicated than OpenID, and people seemed willing to give that a fair shake, at least to the extent that a lot of sites implemented it.
Giving out your private keys like that (what, you actually trust an internet cafe computer?) is a rather bad idea. Instead have a service that your local client can authenticate to (with a normal password if you trust your client, or rsa keyfob, or application that makes your phone act like a keyfob), that acts vaguely like either ssh-agent (with the connection established in the opposite direction) or a kerberos KDC (which would let you not need to keep track of privkeys).
Uses the site's domain as a salt though which isn't exactly secure if whoever hacks the database decides to ignore the low-hanging unencrypted fruit and crack your password. You can configure the encryption settings a bit though and add your own pre-salt kinda deal.
StackOverflow demonstrates aptly that OpenID is a technology that can work really well. You just need to: - Funnel users to pervasive, competent providers like Google, Facebook, Verisign - Make the integration experience as smooth as possible.
If your implementation of OpenID requires users to enter URLs and encourages users to use random providers, than yes, it sucks.
Instead of managing 1 SO and 1 MetaSO login, I'm managing a connection from SO to one of many providers and MetaSO to one of many providers. Best case, that's 3 pages (SO, MetaSO and Yahoo) to manage logins to 2 sites.
But it's still a pile of redirects where the net result is that you can tie a user to their identifier and nothing more — it's mostly useless without implementing it paired with an LDAP/AD backend to get group membership and whatnot.
Just not storing a password field in your backend does nothing — you really have to get rid of the per-app account models entirely. WebFinger is a nice step along these lines, but it layers on top of OpenID and even then still doesn't provide the complete picture.
Sounds great, Yahoo/Google/Facebook take your pick with a button or if you're hacker/paranoid enough to have your own infrastructure the slightly complexity of using a URL?
Main complaint seems to be it's URL and not user@host? Couldn't one just add support for user@host into the next iteration of the standard? Maybe using something like DNS SRV records that seem to work well enough for XMPP?
Decentralisation is important and more cultural than technical. We need to keep working for it and it's not a short term goal--if it happens over decades so be it, but we shouldn't give up ground where we don't have to, especially with things trending against at the moment.
Maybe the execution was not crystal perfect, but I think all of us would have liked OpenID (or some other free and open standard) to succeed.
Open world 0 : Corporate overlords 1
The problem was the underlying concept is not sound and no amount of layer on more features was ever going to solve it. What we need now is to get the browser makers involved in a secure authentication system and start it first inside of smartphones.
I suspect that until things like a TondioPlug become useful for a lot of people, (if they ever do) asking people to be their own provider will be a lost cause.
What is wrong in that a spammer could easily host its own OpenID server and log in with that account on numerous sites. You even can write scripts to do it automatically, so I didn't really get the idea of OpenID.
I think in the future we get OAuth as the winner. Yes, its main purpose is different, however "signing in" with OAuth is so much easier. Even a simple user can understand how it works. And by implicit use of only specific OAuth providers (where you registered your app), you close the door for "bot"-providers. Of course one can argue, that you can also force to use only specific OpenID providers, but this is not core idea of what OpenID was created for.
Instead of using the same username + password combination for all the sites on the Internet (and suffering from Gawker-like incidents), or writing down a bazillion passwords in my keyring, I use my OpenID when I want to comment on random people's blogs or sites like StackOverflow.
Furthermore, when using OpenID, users have to remember yet another type of token. As opposed to the ubiquitous email+password.
Who do you trust more to control who can use your identity? A gossip blog like Gawker Media? Or a place like Google, Verisign, etc who employs real security experts who know what they are doing.
I have a PayPal token so that I can use two-factor authorization for my account. Since Verisign PIP is powering that solution, I also now have a two-factor openid that I can use anywhere. So if I decide that I want to have additional protection for my StackOverflow or Tripit accounts -- I can.
[1]: http://blog.theamazingrando.com/the-road-to-better-authoriza... [2]: http://news.ycombinator.com/item?id=2128966
So, it makes sense to go where users are. What I think needs to be done is standardize an api for the sites like twitter, facebook, Google and who-knows-what-in-the-future to use in providing accessing to user information to developers ...
That way, when superdupersocialnetworking.com explodes and has 1 billion users, providing sign on access to its users for your app is as simple as changing one or two lines of code.
That would be really awesome
It is my understanding that that's pretty much exactly what OpenID is.
Looks like they renamed it... seems proprietary?
http://news.ycombinator.com/item?id=2083774 http://www.curated.by/splaice/zed-shaw--dan-kaminsky-talk-ab...
but "here is a thing in two parts, one of which you give to everyone but one of which you need to keep absolutely to yourself or you're screwed" doesn't have a common analogy. even the "i give you an open box with a padlock" analogy can feel a bit contrived.
However I also feel that there was no cohesive attempt at building a similar story for OpenID - which is a shame as it could be as simple as "tell us which site you want to log in via and we'll do the rest"
Hits nail on head. It's unbelievable how dumb geeks who try to design UX experiences can be (and I say this as one of them). The first day I saw OpenID I was amazed that anybody would try and use a URL as an identifier.
Why would anybody put something that no normal person understands front and center of their UX? This is like opening a shoe shop and putting a quiz about 2nd order differential equations on the front door. Guess what - nobody is going into your store!!!
It was already a huge challenge to get people to understand the concept of using a login from one site to login to another. But it was doomed from the start the minute someone said you should have "http:// in front of your username.
http://www.readwriteweb.com/archives/google_enables_webfinge...
It uses your email address, and seems to offer a good way to get access to an OpenID-like sign in (maybe this is using OpenID or OAuth under the covers?)
The previous example being the DHS censoring web sites such as The Pirate Bay and Wikileaks.
Even if you do it so that the actual data stores are separate and you manage to keep the APIs the same, lots of countries will have huge issues with adopting U.S. policies.
I just think Open ID was over elaborate, I'm hoping something simpler could succeed where it has failed. Hope that makes sense.
Its not crazy. Facebook just announced something along those lines today http://marketaire.com/2010/12/23/facebook-registration-tool/
IMHO, one of the things they do correctly is that the user doesn't have to remember an OpenID url in most cases, just click on the logo for which of your likely ID providers (Google, Facebook, Yahoo, etc.) that you want to use. What could possibly be easier or friendlier for the end user?
The problem is that StackOverflow is also about the only example of OpenID done right, or done at all...
Yes, there are a few others. But at least in my internet usage I hardly ever run into one. I can't remember having used my OpenID for any site other than SO in the past couple years.
* Tripit.com only supports Google, Google Apps, and Facebook, but it's very end-user friendly to use any of those three.
* Catch.com, like Tripit, supports Google and Facebook OpenID logins.
* mindmeister.com supports Google, Google Apps, or a generic OpenID login.
* springnote.com supports a number of openID providers including generic OpenID. This one is actually an even better example than StackOverflow of an end-user friendly OpenID login/signup page.
Those are just ones I pulled from my Google account settings page. I'm sure there are other good examples out there.
The fact that you can conceive of it means that it likely isn't impossible, merely very difficult and possibly non-obvious. But that's how pretty much every real success story starts. You really may be on to something here.
http://hacks.mozilla.org/2010/04/account-manager-coming-to-f...
Nice implementation, poor sales/marketing.
Most websites simply can't see enough of a bang for an engineering buck they could be spending on something else (i.e. they don't even want to install it, never mind pay for it) and if it's done well consumers don't even see it so there's no money to be had from them either.
I'm sure we could have made it all slicker still but even Facebook login takes some justification and Clickpass didn't deliver anything like the value that that does.
With that said... isn't that really like OpenId?
Yep, and it's not exactly a standardized API, neither would it be easy to move a system built on this to the next greatest thing from Twitter or Google. User data lock-in is nice like that.