Federated Social Web Summit
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
README.md

README.md

DataPortability Project 2.0

At the Fall 2012 Federated Social Web Summit (#fsws) in San Francisco, we had a session on what it would take to reboot the now-quiet DataPortability Project half a decade later.

Remember the DataPortability Project 1.0?

The DataPortability Project was a volunteer group. It advocated for user data portability principles, policies and practices. These included demands for user-controlled:

  • data import, export, and synchronization;
  • access to all -- data created directly by the user (like photos, text, audio), -- data co-created with other users (threaded conversation, Etherpad docs), and -- data observed or inferred about the user (click streams, scores, facial recognition profiles);
  • the right to delete personal data, profiles, and history;
  • control over distribution of the data and the faithful binding of these portability promises upon other parties;
  • disclosure of where data is physically held (jurisdictions) and by whom (agents and proxies); and
  • due process when ending a service or closing an account.

The group was successful in promoting the idea of data portability but failed to promptly convert public attention and support into effective programmes that changed business and government behavior. Nevertheless, the project demonstrated public concern and interest.

Approach

What could be different this time?

Mr. X [I'm applying the Chatham House Rule] said it was time to try again.

Three Fronts

Mr. X advocated three components that should work well together.

  1. Plumbing. Find or build infrastructure services. These could be pipes that move data from sources of personal data to apps, like Singly or Kynetx. They might also be infomediary services, sometimes called personal clouds, personal data stores, and data banks, like Mydex or Personal.

  2. Apps. Find or build user-facing apps using those infrastructure services to present users with controls and ways to use their data, like Reputation.com or Lifedash.

  3. Activism. Promote the ecosystem of apps and plumbing to consumers/citizens/patients, infotech developers/product managers/founders, and large holders of personal data (Big Internet, telcos, banks, etc.). A project site and tools could be used to crowdsource public naming and shaming of services failing a simple, objective, easy-to-prove litmus test. (Perhaps "Minimum Viable Compliance"?).

Ask less, get more

This time around, Mr. X said, the project should simplify.

  • Data Export. Only ask for export from data suppliers. Limit the data to that provided directly by the user; not inferred or observed or co-created data. The model is Google's Data Liberation Front. While more would be better and could be acknowledged, our ask is for export.
  • Fidelity. Ask that data and their structures be exported without distortion or censorship.
  • Delivery. The data should be delivered in a useful, documented format.
  • Persistent Access. Access to the data export must always be turned on.
  • Free to Use. Access to this data should be without strings, free of charges, and without liability. Treat users like adults.

Potential Actions

Let My Data Go! banner featuring engraving of Moses holding tablets aloft

  • Enroll the partners. Recruit existing data providers and startups to come together. Does the small developer community look like PDEC's Startup Circle, members of the personal data ecosystem consortium?
  • Organization. Discuss whether we need a new identity for this project or to take over DataPortability Project's domain, accounts and 501c3 corporation.
  • Business model. Who's the customer? What value will we deliver? How do we cover costs and fund staff and operations? Perhaps a business model canvas session?
  • Contemplate deadlines and milestones. Could we have a Let My Data Go! month in late Spring 2013? Maybe April? See Data Freedom Month notes.

Get involved