Main

Friend Connect or the Deportalization of Social Networks

The issue of personal data portability is rapidly moving center stage. So, what is the big fuss about and what is really at stake here?

For us, as consumers, it is an important issue because eventually, it will determine how much ownership we will be able to enforce upon our personal data and content, including our social graph, that today, is dispersed across competing social networks and Web portals.

For Google, and FaceBook (FB), the stakes are equally high. Ultimately, the winner could take it all and be the one who really drives revenue from social networking. But to understand, we need to review the controversy first.

It really all started with OpenSocial. OpenSocial was Google's response to the rapid rise towards hegemony of FB APIs. To counter FB, Google created an alternative that it self-proclaimed an open standard by rallying a large number of FB competitors behind it.

Competitive response aside, Open Social also arises from our industry's realization that social network is much more than a destination. Social networking is really a new application dimension. It is a new form of interactions that can augment almost any application, or any web site. To add social networking capabilities to an application, you need APIs. OpenSocial fills that gap.

With OpenSocial, Google is also reducing social network to mere "containers". Google is turning the social networking portals into a set interoperable data sources that it can dip into. In fact, with the consent of the end-user, these social databases become instantly accessible to a whole new layer of identity services. The first generation of these new of services is now known. It is called Google Friend Connect.

It is clear that FB understand the threat of a layer above social networks dominated by Google. Its decision to block Friend Connect under the excuse of privacy control does not fool anyone. It is also likely that OpenSocial may have forced FB into exposing its own APis to third party Web sites. Friend Connect, on the other hand, is consistent with Google "social cloud" strategy. It simply extends OpenSocial by alleviating the need for site owners to write code. Although it remains to be seen whether an embedded widget can provide the right user interface, by putting itself, between Web sites and social networks, Google is moving fast to disintermediate the leading social network. If Google were to succeed, it would surely make a significant dent into FB's $15B valuation.

But what is the real prize here? What is really at stakes? Let me venture an explanation. How do you discover sites, products, music, videos on the Internet? You Google it,of course. Now, in the real world, how do you discover products, movies, or books? Very often, you discover them through your social connections. Social events are always full of "I love this new product, you should really buy it too", "you must see that movie", "I highly recommend reading that book", "this restaurant is unbelievable". So maybe, social discovery is the perfect complement to search when it comes to generate and monetize traffic to other sites.

So here may lie Google's bet on Open Social. The bet is that social networking capabilities integrated into a Web site can drive viral traffic (because your social feed will notify your friends of a site visit or of a transaction, because you will recommend a merchant by becoming a 'member of the site' or writing a review, because you will trust a site by finding people you know who have already experienced this site). Not withstanding the data mining and advertising intelligence opportunity that sitting between sites and social networks can present in the long run, the bet is that social interactions will drive more site visitors. Of course, for an ad network like Google that strives on monetizing new customer acquisition and traffic, it is a very rational bet.

So while FB seems initially more concerned about keeping interactions within the walled garden, Google is forcing all the social networks to embrace a deportalization strategy. Of course, it is a smart move for Google who, unlike social networks, has already strong customers relationship with most Web sites through its AdWords and AdSense programs. Without access to a direct channel to online merchants and .COM sites, FB is in a relatively weaker position but it had to respond and Facebook Connect is its current answer to Google. Will FB be more effective in driving revenue by deportalizing its APis and driving traffic outside FB instead of raising the walls of the garden day by day? That remains to be seen.

At the end of the day, social traffic is still a theory in search of validation. For these merchants and Web site owners, that traffic may never materialize. To the non-believers, I can only oppose the success of Yelp whose sole purpose of its community is to drive traffic to local businesses. Considering the energy that Google is deploying around open Social and Friend Connect, we should have our final answer soon. One thing is almost certain, for the near future, the social cloud is likely to be the strongest market force driving internet-scale identity services, and that is very good news for OpenID.

05/19/08 | permalink | comments [0]

Lightweight Signatures for XML

Check out this proposal published by Johannes Ernst of NetMesh. I challenged him a couple weeks ago to apply his skills at developing lightweight, straightforward solutions to the problems presented by XML Digital Signatures, which are too numerous to recount here. XMLDSIG is a powerful technology, but it's very heavy and quite complex, which works against its success in the marketplace, particularly in lightweight development environments.

Just as a gedankenexperiment for Johannes, we wondered what should be done if we wanted something besides XMLDSIG -- something much simpler and lighter -- for identity, publishing and social networking applications we've been looking at. Johannes idea is to forego XML canonicalization -- or transforms of any kind -- and simply sign a single node as a blob, signing the XML in a monolithic way, the way you'd sign a JPEG image.

The single element signing strategy won't work for a variety of existing and legacy XML document formats. But it may be that if one keeps the constraints applied in Johannes' proposal in mind, XML documents might be effectively designed to support this method. If so, it would create a much lower threshold for web apps to clear in order to support basic trust and cryptographic semantics in XML. Essentially, Johannes is asking what would happen if we did away with transforms.

In any case, if you're interested in this kind of thing, it's worth clicking over there to give it a read.

02/20/06 | permalink | comments [0]