Pages

Tuesday, May 4, 2010

Well, It's Been a Few Weeks: XAuth is Dead

Does anybody remember that service the Meebo team launched a little while ago, XAuth, I believe it was? :) To refresh everybody's memory, XAuth was a service where social networking sites would store a token in the user's browser, and then other sites would read that token and customize the user experience to whatever services the user is currently logged in to. Bravo to Meebo for making one of the only attempts at decentralizing this dictatorship of social media that everybody is obeying under. However, I do not think I have seen a single major social networking service even come close to adopting XAuth. In fact, Facebook came out with its own stuff around the same time. Despite best intentions, I believe the problem with XAuth is a fundamentally flawed concept: there is no halfway between authoritarian and decentralized.

Now XAuth's real concept was to make social networking information on specific sites become relevant to the user. This is an interesting concept to consider, but the XAuth approach is not one I would follow. The first problem is lack of specificity. The "token" that sites can install in your browser are not defined. They are just random tokens, maybe session IDs, maybe user IDs, maybe a random number, who knows? With no token standard, how can websites derive any useful information from the XAuth tokens if the website has to know how to use each and every one. It actually puts us right back in the original situation, where a website has to know how to collaborate with every social networking site if it is to bring relevant information to the table. While specificity I think is the main problem, there is also another major flaw: centralization.

You'd think that XAuth easily installs with a few lines of code, runs off your site, and begins making users happy. Unfortunately, only the first of these is true. XAuth does have a one line installation, but that external script actually uses HTML5 to create an iframe to xauth.org. In other words, it actually loads xauth.org in the background so the tokens can be forwarded there. While an alternative method may or may not be available, having to rely on one domain to handle your tokens is definitely not the way to go, especially if it means loading the page in an iframe. (And do you think Facebook is going to rely on a third-party site to manage tokens for its users?) These two problems are the primarily disabilities with XAuth, but there are other reasons it is not being adopted as well. These problems include errors caused by restricting cookies and a poor privacy infrastructure. What if you don't want a site knowing about your tokens? Unfortunately, the only option there would be to remove your tokens. (And you can only do that at, you guessed it, xauth.org.)

So while XAuth was a half step, or really quarter step, in the right direction, I doubt it will gain momentum passed where it is already at. Within the week, or maybe next week, I will have an alternative solution to social networking customization (though the chances of implementation are slim). Does anybody have any suggestions on how XAuth could improve?

2 comments:

  1. Since it's been over six hours since you posted this and no one has commented I think it's fair to say your blog is dead. Might as well give up :-P

    XAuth could improve by clarifying it's potential use a bit. Meebo created XAuth for a limited purpose that it's major competitor FB Connect also serves; identifying browsers that have logged in to other sites. I think a lot of people must forget about it after they learn it doesn't give them access to any of the data associated with those users. FB goes that extra mile and many will consider XAuth to be too limited to supplant Connect. That's just because Meebo doesn't draw the connection to OAuth for us. OAuth lets sites manage access to a user's data just like FB Connect. XAuth may not stand a chance against FB Connect, but XAuth+OAuth do!

    Lets not talk about XAuth in the past-tense just yet. I still have hope.

    ReplyDelete
  2. It is true that X+OAuth would be quite a competitor, but I am weary of the concept. It would need to be combined into one product; we could not have XAuth then OAuth.

    ReplyDelete