Running Scoble’s Roadblocks on Data Portability - Part 2

In my last post I looked at an idea for distributing social networking profiles and how that would be an alternative to data portability. Now I want to continue to look at what Scoble presents as the roadblocks and see if the rest can be solved with distributed profiles.

Deleting a Profile

“What if a user wants to delete his or her info off of Facebook.” In the data portability world the profile might be copied onto various other sites which might not agree to delete the info. In my distributed scheme your profile only resides at one place - the profile provider site - and therefor you can delete it once and rest assured that it is gone from everywhere.

Now it’s not really quite that simple. Once the information is distributed it can be cached in various other sites and if they don’t handle the caching properly your data might still persist after you delete it from the provider. In this distributed social networking world your profile provider will only distribute your profile to trusted third parties. Sites that don’t comply can be shut off from the feeds. Of course this same carrot/stick approach can be used in the data portability world as well. With the distributed model you can add one further scheme - remote content. If you (or your profile provider) don’t quite trust a third party site you can allow them to display your profile information remotely - via iframes or the like - rather than giving the third party the data to display. In this use however the third party would be limited in the use they can make of your profile information since they don’t have direct access to that information.

Noisy Systems

credit: cosmonautirussiSome people are sensitive to the amount of email sent by various sites and while you might be happy with the control your profile provider gives you the third party might make use of your email that you don’t want. My distributed profile scheme adds an element and that’s the profile viewer. What this means is that the profile information that is available depends on who is looking at it. You can present one set of data to family and close friends, another set to co-workers and still another set the the general public. You can also determine what information you want available to applications which tend to be a big source of email noise. You can use this to prevent those applications from having access to your email address. Now again this only really works with other sites that want to play nice and follow the rules. A site might obtain your email while showing your profile to a friend and then use that email address for other purposes. Sites that do that would be excluded from the distributed social world but that might not help you once your information is in the wild.

Ensuring Privacy

“You want your closest Facebook friends to know your birthday, but not everyone else.” Is this even possible on most social sites today? I think this is a major failing and one that’s caused by grouping everyone into a “friend” relationship. If sites provide fine grained privacy controls you might be forced to allow or deny every piece of information you have to each of your friends. If however they add the concept of defining the relationship type in the friend request/acceptance then the user can apply privacy controls based on relationship type. Family members get my birthday information. Co-workers get my birth date but not the year. The general public gets no birthday info.

What Data is Yours?

The question of what data belongs to the user and what belongs to the site is a good one and not really addressed via distributed vs portable data. The distributed world needs a standards body to work out how profile information is requested and used and what data goes into that profile would be part of that standard. The profile provider could of course give only a portion of the data if they chose to take the stance that not all the data belongs to the user. But the big benefit of the distributed and open model is that the user if free to chose their profile provider. Say Facebook doesn’t want to share photos you upload across other sites. Certainly another profile provider will be willing to do so. And you can use that other provider and still retain the ability to “friend” Facebook users.

The cross site nature of the open/distributed model also allows for some things that “don’t make sense” in the closed/data portability world. Scoble mentions a comment by a Facebook user not making sense on Flickr. I imagine this is because the Facebook user might very well not have a Flickr profile of their own. But since in the open world the Facebook user can “friend” a Flickr profile or comment on Flickr directly it really doesn’t matter.

Multiple Profiles

Scoble also talks about the complications that arise if someone want to share their profile information across multiple sites but have some bits different - eg. use a different email on Flickr and and Facebook. You can of course solve this in either the data portability or distributed world by allowing overrides - even if you profile is hosted a Facebook you can override some of the profile information when that profile is displayed at Flickr. Overrides aren’t the greatest solution because they re-introduce the problems of having dozens of profiles to update across dozens of sites when you want to change some information. A better solution is to allow - and encourage the use of - multiple profiles. In my own case the main reason I’d want to use multiple email addresses or different profile information across different sites is to segment my world. There’s Solo the entrepreneur, Solo the dad and Solo the poker player. Each of these could be separate profiles - either with different providers, with different accounts at the same provider or by a provider allowing different profile information depending on the relationship of the profile viewer. Just as you might give a different email address to a family vs a business contact so might you give different profile information to a public viewer based on site. Flickr that don’t have a relationship to Scoble would get the Scoble-the-photographer view while those on Facebook might get the Scoble-the-dad view.

No Easy Solutions

I’ve shown here that an open/distributed social networking scheme can work and can solve most of the problems of difficult cases that Scoble brought up. Such a systems is a much more drastic change from the current world than even the data portability model and that makes it even less likely that such a scheme will be adopted any time soon. The key points of this model are:

• openness - can “friend” across sites and use foreign profiles
• more nuanced relationships than just “friend”
• information controls based on relationship with the viewer of the profile

While the distributed/open model solves some problem (and I think is just plain better than what we have now) it does introduce some new problems of its own and I’ll address those in the next post.