5 ms·

Alternative question: why shouldn't I use OpenID? What are the common concerns, and which are valid/invalid?

immad 19y ago
I think the only real answer to that is if you think OpenID is likely to confuse users during signup and therefore you loose users. I think even though its early the increase of signups is likely to be greater than the loss of users through confusion. Especially if implemented well using Clickpass ;-) Also another answer is that it is currently not completely trivial to implement, so if you don't think the benefit outweigh the time to implement than you wouldn't. Hopefully we will help fix that soon as well.
ambition 19y ago
As far as I can tell, the biggest concern is that OpenID makes phishing easier and more valuable. When the same user ID and password open all your accounts, one mistake compromises everything. Let's say clickpass gets huge, and someone forges a malicious clickpass-lookalike widget. They spread it around the net. Any password they steal gets them in to all clickpass-enabled accounts.
- jlam 19y ago
  The weakness of the above argument: Why would site-owners install an untrusted Clickpass widget spread around the net but not from Clickpass itself? I can see how some users might fail to recognize a Clickpass or OpenID url and give their login credentials to a fraudulent site, but no worse than password management, OpenID requires folks be on guard against phishing.
  - ambition 19y ago
    It's the same problem as current passwords, but with higher consequences for those who don't use the same userid and password across sites.
mechanical_fish 19y ago
Here's my list, in no particular order: - OpenID is a mystery to anyone who isn't a geek, and also to many geeks. - The extent of OpenID's positive (or negative) influence on user signup rates, or anything else, is unproven. The technology brings no clear benefit on day zero. Nobody can tell you what the return on investment is. - OpenID used to be about the promise of one-textfield signup. But, oops, if you want to speak to the user again you also have to ask for an email: two textfields. If you want to make sure the email is valid you need to mail out a confirmation link. At which point do the advantages of OpenID wash out? There is no usability data. - There are security questions, but few answers. The number of free variables, and the fact that nobody bothers to attack a system with no significant userbase, makes these issues hard to pin down. It is certainly true that a less-than-perfectly-competent provider can render OpenID very insecure. - OpenID, as proposed, introduces a dependency between your code and the code running on hundreds of providers scattered across the net. You have no control over these providers, they have no legal obligation to you, and your site's uptime is completely dependent on their uptime. - There is no standard OpenID provider implementation, so there is no way to know at any time which of your users' identities might have been compromised by insecure or unpatched software. There is no way to run automated tests between your code and that of every provider. If you do find a bug in a third-party-provider's code, you have to beg them to fix it, or beg a subset of your users to switch providers. Yeah, I know, there's a standard. There are standards for email, too. Find a forty-year-old email admin and ask them how easy it was to make all the mail servers on the net conform to those standards. - Your users probably don't understand OpenID very well, so when they have login troubles they will complain to you. You can't fix many of these problems, but they will not know that. Your $20-an-hour tech support person may not know, either: is your site at fault, or the provider's site? Even your $100-an-hour back-end programmer may have to spend twenty minutes figuring it out. Then, if it's the provider's fault, that fact has to work its way back up the support chain to the user, who will be confused and unhappy. Multiply the cost of such an incident by the number of confused users. Estimate the number of users who will be confused. By OpenID. Better go looking for another round of investment. - Finally, an OpenID provider owns a subset of your users -- it may not own them outright, if you've been shrewd enough to capture email addresses, but it certainly owns them as much as you do. The provider can redirect the users, show targeted ads to them on the login page, allow your competitors to bid on them. It can do all this with perfect knowledge of when, where, and how often your users log in to your site and most of the other sites on the net. --- Now, a lot of these problems go away if you give up on the "Open" part of OpenID and restrict your users to a certain subset of "trusted" providers. Like, say, Clickpass. You can sleep well at night knowing that the Clickpass folks are smart, that they fix their bugs and answer their mail, that if something goes wrong for a user there's only two places the bug can be (your site or Clickpass), that their security has been audited, that they have a decent privacy policy, and that they've done their best to make it all so simple that a monkey can understand it. Then, after Clickpass has become successful, they'll be bought by Microsoft, renamed to "Passport II: Electric Boogaloo", and everyone will live happily ever after.
ken 19y ago
In my case, we're a startup with finite time. Adding OpenID support (AFAICT) would take more than 3 lines of code, and very few (if any) of our target audience has an OpenID. Therefore, today, I think it's not a good use of our time. If/when this equation changes (i.e., everybody has an OpenID, or it's trivial to support), I'd be happy to add it.

immad 19y ago

I think the only real answer to that is if you think OpenID is likely to confuse users during signup and therefore you loose users. I think even though its early the increase of signups is likely to be greater than the loss of users through confusion. Especially if implemented well using Clickpass ;-) Also another answer is that it is currently not completely trivial to implement, so if you don't think the benefit outweigh the time to implement than you wouldn't. Hopefully we will help fix that soon as well.

ambition 19y ago

As far as I can tell, the biggest concern is that OpenID makes phishing easier and more valuable. When the same user ID and password open all your accounts, one mistake compromises everything. Let's say clickpass gets huge, and someone forges a malicious clickpass-lookalike widget. They spread it around the net. Any password they steal gets them in to all clickpass-enabled accounts.

jlam 19y ago
The weakness of the above argument: Why would site-owners install an untrusted Clickpass widget spread around the net but not from Clickpass itself? I can see how some users might fail to recognize a Clickpass or OpenID url and give their login credentials to a fraudulent site, but no worse than password management, OpenID requires folks be on guard against phishing.
- ambition 19y ago
  It's the same problem as current passwords, but with higher consequences for those who don't use the same userid and password across sites.

mechanical_fish 19y ago

Here's my list, in no particular order: - OpenID is a mystery to anyone who isn't a geek, and also to many geeks. - The extent of OpenID's positive (or negative) influence on user signup rates, or anything else, is unproven. The technology brings no clear benefit on day zero. Nobody can tell you what the return on investment is. - OpenID used to be about the promise of one-textfield signup. But, oops, if you want to speak to the user again you also have to ask for an email: two textfields. If you want to make sure the email is valid you need to mail out a confirmation link. At which point do the advantages of OpenID wash out? There is no usability data. - There are security questions, but few answers. The number of free variables, and the fact that nobody bothers to attack a system with no significant userbase, makes these issues hard to pin down. It is certainly true that a less-than-perfectly-competent provider can render OpenID very insecure. - OpenID, as proposed, introduces a dependency between your code and the code running on hundreds of providers scattered across the net. You have no control over these providers, they have no legal obligation to you, and your site's uptime is completely dependent on their uptime. - There is no standard OpenID provider implementation, so there is no way to know at any time which of your users' identities might have been compromised by insecure or unpatched software. There is no way to run automated tests between your code and that of every provider. If you do find a bug in a third-party-provider's code, you have to beg them to fix it, or beg a subset of your users to switch providers. Yeah, I know, there's a standard. There are standards for email, too. Find a forty-year-old email admin and ask them how easy it was to make all the mail servers on the net conform to those standards. - Your users probably don't understand OpenID very well, so when they have login troubles they will complain to you. You can't fix many of these problems, but they will not know that. Your $20-an-hour tech support person may not know, either: is your site at fault, or the provider's site? Even your $100-an-hour back-end programmer may have to spend twenty minutes figuring it out. Then, if it's the provider's fault, that fact has to work its way back up the support chain to the user, who will be confused and unhappy. Multiply the cost of such an incident by the number of confused users. Estimate the number of users who will be confused. By OpenID. Better go looking for another round of investment. - Finally, an OpenID provider owns a subset of your users -- it may not own them outright, if you've been shrewd enough to capture email addresses, but it certainly owns them as much as you do. The provider can redirect the users, show targeted ads to them on the login page, allow your competitors to bid on them. It can do all this with perfect knowledge of when, where, and how often your users log in to your site and most of the other sites on the net. --- Now, a lot of these problems go away if you give up on the "Open" part of OpenID and restrict your users to a certain subset of "trusted" providers. Like, say, Clickpass. You can sleep well at night knowing that the Clickpass folks are smart, that they fix their bugs and answer their mail, that if something goes wrong for a user there's only two places the bug can be (your site or Clickpass), that their security has been audited, that they have a decent privacy policy, and that they've done their best to make it all so simple that a monkey can understand it. Then, after Clickpass has become successful, they'll be bought by Microsoft, renamed to "Passport II: Electric Boogaloo", and everyone will live happily ever after.

ken 19y ago

In my case, we're a startup with finite time. Adding OpenID support (AFAICT) would take more than 3 lines of code, and very few (if any) of our target audience has an OpenID. Therefore, today, I think it's not a good use of our time. If/when this equation changes (i.e., everybody has an OpenID, or it's trivial to support), I'd be happy to add it.