Google's OpenSocial API initiative got a lot of buzz and hype last week which I thought was misguided. This week my friends Mark Cuban and Tim O'Reilly cut through the hype and get right to the heart of the matter with two excellent posts.
Mark Cuban's idea -
I thought that if you put the 2 together, enabling Yahoo to access the Facebook database of users within the current API constraints, Yahoo search and ad serving would improve considerably. Expand the Facebook database with an opt in option to add further personal data that could be used FROM WITHIN THE YAHOO WEBSITE, the results for Yahoo could be extraordinary. A Yahoo search box within Facebook , or a search from a Yahoo site that recognizes you are the owner of a Facebook profile and customizes the results according to information culled from your profile would be incredibly powerful.
Great idea Mark. Substitute Microsoft for Yahoo and that sounds like a great plan :-)
Tim O'Reilly's idea - Tim agrees that Mark has a good idea, but extends it further. Tim says;
We all want what Mark describes: a definitive place under our own control where we can describe who we are and what we care about so that applications can use that data to provide us with smarter services. We don't really care whether that repository is at Facebook or Google or any other site, or perhaps even if it's an aggregation of data from many places, but we do want it to become more useful to us. Not just more useful to the holder of our profile, but to every site we touch on the internet. Whichever company gets there first, to a truly open, user-empowering, internet-turbocharging social network platform, is going to be the net's next big winner.
I like both ideas. I also have two concerns - security and privacy.
Security - The first OpenSocial app on Plaxo was hacked within 45 minutes, and quickly taken down. We are talking about personal information here...names, pictures, contact information, friends lists, etc. Security is important here. It can't be just an afterthought.
Privacy - Tim O'Reilly nails it with this quote "What would it take for me, as a user, to have fine grained control over that authentication, so that some applications could see all of it, and some could see only a little? What kind of system would make it easy for me to manage the data that appears about me, to reduce duplication of effort, yet to give me a single credential that I could proffer as a proxy for "the real me"?"
My Friends List is not like an OPML of my RSS feeds. Everyone is talking about data portability of "my data". Some have used the example of being able to take their list of RSS feeds in an OPML file and export it to another RSS reader of their choice. They want to be able to do the same with their Friends List. Be careful. The concepts are similar but the data and implications are very different.
My RSS feeds are a list of my favorite blogs. I can show that list to anyone without exposing anything personal about those blog authors. My Friends List is different. It includes the names, pictures, activities, and contact info of my friends. Even if it were just the names and pictures, and even if they can't interact or access the friends, that is still too much personal information to expose anywhere without their permission.
What if? - OK, what if I am a friend of someone on MySpace. Cool, my name and picture appears on their friends list and anyone can see it. But what if this MySpace friend joins a PornSpace social network site and wants to import his friends list to that site? Now my name and picture shows up on his PornSpace page as a friend of his? Hey, wait a minute, I didn't agree to that. How do I control where my name and picture go once I become a friend of someone? Will there be guilt by association?
Social Networks are fun and will evolve to be even better. I like Mark and Tim's ideas. However, security and privacy must be considered in these new initiatives.
For each friend in the friends list you can expose only an ID with no private information. It would then be up to the friend him/herself to control what private details are divulged depending on who dereferences the ID.
Posted by: Daniel Feygin | November 05, 2007 at 09:37 AM
Daniel, That is the way it should be, but I'm not sure that is the way the OpenSocial API works today. In fact the demos I saw at the Google campfire were importing friends AND activities. I didn't see anything in the demo about EACH friend deciding what to expose.
Could you point me to call in the OpenSocial API that does that?
Posted by: Don Dodge | November 05, 2007 at 09:43 AM
Unless I'm missing something, this seems like a non-issue...for this use case, I don't see a difference between importing from my list of e-mail contacts and importing from one of my social networking apps. When I import contacts from my e-mail address into Facebook, it looks at the e-mail addresses and finds existing Facebook members. If they're not in there, I can invite them to join. If they don't join, they don't show up as a friend. This is, in fact, the same approach that basically every social networking app takes to this problem.
Posted by: Paul | November 05, 2007 at 10:58 AM
Tim's quote is dead on, but it conflates 2 issues - "who we are," and "what we care about" - to the detriment of forward progress on both.
We need to de-couple enabling users to take control of their own online preferences from much bigger and hairer problem of online identity management.
See http://www.matchmine.com for at least one example of how.
Posted by: MikeTrap | November 05, 2007 at 11:05 AM
So far the OpenSocial initiative really only helps developers.
It is about portability of applications rather than data.
Facebook have previously enabled third-party developers to build applications to be hosted on their site. Now many others are creating similar platforms, all at the same time. OpenSocial just means they're all implementing the same developer standard so that the same code can be used on all of these sites.
It's a bit like writing a desktop application in Java. If Linux, Windows, and Apple machines all have a Java interpreter, then they can all run your application. But they do so completely separately.
Posted by: Dan Lester | November 05, 2007 at 12:20 PM
I wrote two related posts recently:
1. First was pre the MSFT-FB deal and was about how a Yahoo-FB partnership might look, with in-FB Yahoo search leveraging the so called social graph. My idea was similar to Mark's but I went further to suggest that users could easily convert unresolved search queries to questions for their friends, friends' friends and other subscribed members.
2. The second was about what Open Social should have been in my opinion. Rather than portability of friend lists without permission, one of the things I suggested was the ability to quickly see which of your friends from other networks are on a new website you are joining and connect to them. Or invite those that are not there to join. I also suggested Open ID of course and the idea of a central set of profile data, a subset of which a user can choose to expose to a particular site.
Posted by: IdeaTagger | November 05, 2007 at 06:27 PM
Don, OpenSocial API documentation does not specify privacy constraints of the host container. The data returned for each of the calls could be incomplete or obfuscated in container-specific ways. Consider that the OpenSocial container always knows which app is accessing its data and which user authorized it to do so on his behalf. It is revealing that the examples in http://code.google.com/apis/opensocial/docs/gdata/people/developers_guide_protocol.html reveal no contact information, only user IDs and names, which, for all practical purposes, is the same as just having IDs.
Even if someone explicitly releases all of his data to some app, that app's ability to use the API to retrieve that person's friends will likely be subject to the friends' permissions with respect to the app, which, by default, are likely to be ID only (though complete invisibility is potentially also an option).
Because of these privacy controls I believe social network friends are fundamentally different from address book or RSS feed entries.
Posted by: Daniel Feygin | November 06, 2007 at 01:47 PM
Dan, that's how I started thinking about the analogy to Java, but it goes much further: http://dondodge.typepad.com/the_next_big_thing/2007/11/50m-facebook-us.html#comment-88726902
Posted by: Daniel Feygin | November 06, 2007 at 02:21 PM