Category Archives: AOL

An unflattering comparison

Jeff Atwood has some harsh words for the iTunes Store requirement to have iTunes installed before you can even see what there is to shop for. He makes a rather unflattering comparison:

And yet this is exactly how the iTunes Store works. Or doesn’t work, depending on your perspective.

I can understand requiring iTunes once you want to sync your media with Apple hardware devices — although I would argue syncing should really be a fundamental, built in function of the operating system. But I’m not trying to sync anything! All I did was click on a link. It’s downright user hostile to demand installation of a special application merely to browse the store, and it is most certainly against everything the web stands for and was built on.

The last “application” I can recall needing to install to get to things online was AOL.

And we all know how great that turned out.

Ouch.

Not So OpenID

A lot of attention is being paid AOL’s announcement that they will support OpenID, but only from a select White List of providers. Ashish Jain has his thoughts here and relates his experiences trying to get SignOn.com added as a provider.

Kim Cameron offers his thoughts here, and thinks that AOL and other sites should allow any OpenID provider in order to drive traffic. He makes the distinction between credentials and accounts and makes a great point:

Credentials should be seen as a cost center, and accounts as a profit center.

The common thread here is the recognition that there are currently a lot more OpenID providers than relying parties. Most OpenID relying parties are only leveraging OpenID for relatively low sensitivity things like enabling blog comments. It seems that the few that are allowing OpenID authentication to important accounts are using a white list approach like AOL.

Now why is that? The main reason is probably the perceived business case that most of these posts mention. Most of these sites want to be driving the identity experience. The perception is that the site that serves as the launch pad for the rest of the user’s browsing controls their destiny.

But there is another issue at play here as well, and that is the perception of asymmetric risk.

I want to use an analogy that may get me into trouble, but bear with me. OpenID without white lists is what I call a promiscuous trust system. By default OpenID trusts everyone. In other words, it sleeps around a lot.

Now image a population in which there existed a sexually transmitted disease for which the transmission from male to female was far easier than the transmission from female to male. Obviously there would need to be some transmission risk in all cases or the disease would die out, but image that the risk is very asymmetrical. In this scenario, it’s much less risky to sleep around if you are a male than a female. Now compare this to OpenID.

In OpenID, there is very little perceived risk in being a provider. If a user compromises your site and uses your site to authenticate to a relying party as someone else, there is really very little consequence to you. After all you don’t have any agreements with any specific relying parties. Why not be a provider, if there is so little risk involved?

Being a relying party however is a different matter. If someone compromises a provider and falsely authenticates to your relying party, they are misusing someone’s resources. The sensitivity of these resources would make the difference between allowing unrestricted OpenID or white list controlled OpenID.

(Mirrored from TalkBMC)