We’re all tired of acquaintances tugging on us to sign up for new
social networks, and of the torque we feel bouncing between the
networks we’re on if we can’t resist the herding instinct that brings
us to join them. But we wouldn’t want to have just one big social
network, either. That would inhibit innovation and prevent people from
enjoying a site’s special features and cultural uniqueness.
which was announced on Monday and covered by
as well as other sites, represents a small step toward a middle
ground. It could be considered the natural succession to
also discussed extensively on
The OpenSocial API forms the basis for communications between Friend
Connect widgets and the site hosting them, using lightweight Ajax and
JSON protocols. Friend Connect uses the APIs provided by other sites
for communication with them.
I had a little tour of Friend Connect last night at the party
celebrating the opening of Google’s new Cambridge office, covered in
Previously, if you wanted to advertise a cool video and ask
people to pass it on to all their friends on Facebook, you’d have to
be a member of Facebook and post the link on Facebook (or ask your
friends to do all the heavy lifting manually). Now you can put the
notice on your own site and still leverage the powerful viral
information spreading features of Facebook–and Orkut, and Yahoo!, and
other sites whose APIs Friend Connect supports.
There’s still some friction preventing this publicity machine from
attaining perpetual motion. You have to individually invite each of
your friends (even if they’re already connected to you on Facebook,
Orkut, etc.) to your new site, and they have to explicitly log in to
your site, although OpenID reduces this to a one-time step.
This explicit signing up is probably a design choice, negotiating the
traditional tension between sociability and privacy. The easier Google
made information sharing, the more risk there would be of having it
take place when someone doesn’t want it.
The same can be said for the initial disappointment some reviewers
expressed that Friend Connect doesn’t do more. They were hoping it
would allow seamless access from any web site to data and API
functions on various social networks.
But to do so would mean mingling your data and social networking
functions fully with any site that supports a Friend Connect widget.
Once you logged in to a friend’s site, it would be able to do anything
it wanted–and attacks would soon materialize that exploit innocent
people’s sites. A compromise to a single provider hosting a few
hundred web sites could quickly become an epidemic of data theft.
Instead, each Friend Connect runs within an IFrame, so that data from
the social networks are not available to the surrounding web page. By
logging in, you still trust the widgets, but this is the same level of
trust (which some people don’t have) as accepting a Facebook
One way to allow more sharing might be to expose data and functions
between sites but provide immediate feedback to each user about
running processes and data transfers. This would require substantial
changes to web architectures and interfaces, and I’m not sure what it
could look like.
I also doubt that we could achieve seamless integration of social
network functions because different networks offer different features,
backed up by different architectures and data structures. Sharing
among networks is limited to certain features they have in common,
just as cooperation between different programming languages is limited
by the interfaces they expose to let functions in one language call
functions in another.
Although I think an explicit login is a good security feature, I fear
it will hold back adoption of Friend Connect. It becomes tedious to
log in, even once, to every page someone invites me to. On the other
hand, it’s an acceptable burden if I really intend to leave ratings
and comments, play games, or engage in the other activities offered by