Posts Tagged 'Google'

OAuth or bust

Hot off the press! (is that still an expression given the apparent demise of newspapers?) Mashups: Google’s Adoption Makes oAuth a Must Have for All Apps. This right after MySpace announcing support for OAuth with their Data Availability initiative the day before.

IMHO, this is huge for data portability, in this case, OAuth support for all Google Data APIs, everything from Gmail contacts to Google Calendar to Docs to YouTube. Bottom line, users no longer need to give up their confidential Google accounts username and password to 3rd party services in order for the 3rd party services to access their data on Google services. I suspect that Google is doing this because it helps them become the service provider of choice using an open and standard means of authentication hence channeling even more traffic through Google servers that they can figure out how to monetize later, much like their Friend Connect effort.

This is a major win for OAuth, in fact I would say that OAuth has now become a bigger player than OpenID in the space of data portability technologies. Given the recent history of big players announcing back to back support of similar features, I predict (ok I hope) that Facebook and Microsoft will follow suit.

Is MySpace data availability truly more open?

In the post MySpace Opens Up The Data Pipe With Full Launch Of Data Availability, Arrington praised MySpace on fully launching data availability

MySpace is taking a much more interesting approach than Google, which controls data sent to third party sites via an iframe. MySpace is actually streaming data to these sites, which allows for true integration between the services, not just a bolted-on social tool.

My initial reaction is awesome, now I (as a 3rd party service provider) can consume the open user data but reading further into the article

Since actual data is being streamed out of MySpace, they have a strict terms of use policy that forbids third party sites from storing or caching the data, other than the unique MySpace user id of the user. Each time a page is rendered the third party must re-request the data from MySpace via a set of APIs. That means any changes by the user to their MySpace profile data or friends list will be instantly applied across third parties who access the data.

So basically MySpace TOS forbids me to do anything more than what is currently allowed by Google Friend Connect. Granted that there is a technical difference between the two, Google Friend Connect uses an iframe and MySpace actually lets the data out, there is no inherent difference in the 3rd party service provider ability to consume the data. In fact I would argue that it is more work for the 3rd party service provider to provide a UI page to render the data rather than just sticking in an iframe and letting Google do the heavy lifting.

Saying that MySpace’s data availability solution solves the problem of constant syncing of data so that the users remain in control is like Facebook saying that they are blocking Google Friend Connect due to user privacy concerns. IMHO the real reason is to maintain control and quoting the user privacy concern is merely a convenient PR front for both companies. I am surprised that Arrington is buying into MySpace’s PR spiel especially since he called Facebook on their user privacy concern blocking Google Friend Connect.

Danger, Will Robinson!

This post from techcrunch today, As Predicted, Yahoo Joins OpenSocial. But Wait, There’s More, has raised concerns for me for the DataPortability project.

At this moment, there are no official published DataPortability standards / blueprints, yes there is a page that lists various open source technologies on DataPortability site but nothing official. And it looks like the 3 big guys (Google, MySpace, Yahoo) have taken the opportunity to rally around Google’s OpenSocial as one data portability standard under the charter of a non-profit foundation OpenSocial Foundation like OpenID.

IMO, this could spell trouble for If sufficient momentum gathers around this initiative with already published standards (and why not, 3 big guys are already on it), it can become the de facto standard quickly rendering yet-to-be-established DataPortability standards inert. The expression that comes to mind “Danger, Will Robinson!”.

A problem for DataPortability to tackle

Today, Michael Arrington from Techcrunch posted an article on “Is OpenID Being Exploited By The Big Internet Companies?” According to the article, 4 big companies Google, Yahoo, Microsoft, AOL claim to support openID but upon closer inspection, all of them have only implemented partial support for openID – technically Google implemented the full openID framework but only for Quoting from the post,

Microsoft has done absolutely nothing, even though Bill Gates announced their support over a year ago. Google has limited its support to Blogger, where it is both an Issuing and Relying party. Yahoo and AOL are Issuing parties only.

To put openID framework into context, again quoting from the post,

There are two ways companies/websites can participate in the OpenID framework – as “issuing parties” or as “relying parties.” Issuing parties make their user accounts OpenID compatible. Relying parties are websites that allow users to sign into their sites with credentials from Issuing parties. Of course, sites can also be both. In fact, if they aren’t both it can be confusing and isn’t a good user experience.

So what can DataPortability do in this case? IMO (and strictly mine), DataPortability could publish a technical and policy blueprint stating that to claim support for a particular standard like openID, a vendor needs to at least implement the relying party feature. From the user perspective, that’s the key value of openID, i.e., get an openID and use it everywhere. It seems like vendors don’t need much incentives to be an openID issuer, there is inherent value to a vendor to provide that feature as is already done by Yahoo and AOL.

If I have my drudders, these are the types of issues that DataPortability should swiftly address and publish standards for, just my $0.02.