Facebook and your Contact Info, a Proposal

Facebook just announced that they are suspending a previously announced expansion of their API allowing third party developers to request access to a user’s address and phone number. Some history and a modest suggestion follow.

When Facebook announced Facebook Connect in 2008, Dave Morin wrote about a concept he called Dynamic Privacy. Facebook Connect would let developers to access your profile but data retention policies required developers to flush this cache of data and refresh it every 24 hours. This way, Facebook could  guarantee your data would not only be current but also deleted if you decided to revoke an application’s permission to access your profile.

Since then, Facebook’s data caching policies have been relaxed. With every Facebook platform developer hitting their servers for a data refresh every 24-hours you can imagine the impact this had on the Facebook infrastructure. In April 2010, Facebook announced that the 24-hour data caching policy would be removed. Developers rejoiced. Facebook operations could relax again. But, for users, the promise of Dynamic Privacy was no more.

Fast forward to last Friday’s announcement that Facebook would allow developers to ask for access to your profile Contact information such as home address and phone number. Without Dynamic Privacy, an application could ask for access to your contact information and keep it. One stray click could give out some very personal data.  There’s no way to opt out of giving out this information in error. No way to put your phone number or address into a special bucket that is locked down to all but a handful of mobile or shopping applications that would be greatly enhanced with access to your phone number.

Rules-based Privacy

Is there a way for Facebook (or any service) to grant access to information provided the conditions under which I grant this access are maintained? How can Facebook ensure that anytime I delete my information it will also be removed from any sites that ever had access to this info? What if I store my private information with a site such as threewords.me which, after only a few weeks in play, is auctioned off to the highest bidder? Is there a way to require the eventual new owner to re-acquire permissions to my contact data. The Facebook Platform Policy currently states:

You will not sell any data. If you are acquired by or merge with a third party, you can continue to use user data within your application, but you cannot transfer data outside your application.

My reading of this is that the new owner of threewords.me can use the data as long as it is used in conjunction with the operation of threewords.me. This includes any future features added should they improve the site to meet their needs. In 2008, the passage of 24-hours required a data refresh, in 2011, at a minimum, legal change of control should do the same. The Platform Policy further states,

You must not give your secret key to another party, unless that party is an agent acting on your behalf as an operator of your application. You are responsible for all activities that occur under your account identifiers.

What if the statement was re-written so that an application’s secret key can never be transferred? Any new owner of an application could run it using their own secret key but it would kick off a refresh of all requested user data. This request could be sent out as via a notification on Facebook Messaging or an alert that would appear the next time the user tries to use the application or web site. Maybe this is already the case but it would be better to state this clearly.

So my modest proposal to bring back the original intent of Dynamic Privacy is,

1. Revision of the Facebook Platform Policy to clearly state that change in ownership would require re-authorization of grated user permissions.
2. Enforcing limitations on transferring application secret keys by tying each key to verified named accounts only. An example of this is how domain names are tied to an administrative and technical contact who are legally and technically responsible for activity on that domain.
3. Requiring all applications to support the Deauthorization Callback and extending it with an API call that is authorized to overwrite or remove data on the 3rd party server. All domain-name root servers are given the ability to update the hosts file information on their downstream servers. Might a similar root server role be appropriate for Facebook as the provider for your private data stored on all downstream applications?
4. The option for users to place personal data into a more secure area which would require more than a single click to grant access.  Something that requires two step authorization and sends me a confirmation email informing me that this access has been granted.

The best way to build up trust is to put in place features that give users control and the option to take something back. These are the post-lunch ramblings of an observer. Please correct me if what I’m suggested is crazy talk!