Sunday, 15 April 2012

An idea for adding privacy to social media

It would be great if all the media that people upload to social media sites was still under the control of the owner and we didn't have to place complete trust in the social media site.  Initially I thought that maybe OAuth might offer part of a solution, but really it isn't designed to solve this problem, it just allows you to share a resource on one web site with another web site.  What we really want is to allow a user, the resource owner, to retain some control over their resources and not delegate all security to the social media site (to protect the innocent I'll reference a fictitious social media site called PinFaceTwitPlus).

Of course one way to protect a photo or video (a resource) that you upload is to encrypt it, but then you have 2 problems; where to put the encryption key and how to let people you share with decrypt the resource.  Obviously PinFaceTwitPlus can't have the key or we haven't gained anything, and you yourself can't store the key since you would have to run your own server.  So the solution would seem to be another service that was responsible for handing out decryption keys to those privileged few you have authorised to view your resource.  Let's call this service PrivacyPoint.

Here is how I see this working from the point of view of adding a new resource to PinFaceTwitPlus.  You go to PrivacyPoint in your browser, you select a locally stored photo and ask PrivacyPoint to protect it.  In your browser PrivacyPoint encrypts the photo and embeds an encrypted key that can be used to decrypt the photo (the key is randomly generated and encrypted to a key unique to you), and also a reference to PrivacyPoint.  You then upload the encrypted photo to PinFaceTwitPlus and share it with whoever amongst your friends is worthy.

How this works from a friends point of view is that when PinFaceTwitPlus wants to show them the photo, the encrypted version gets downloaded to their browser and the page determines that it needs to decrypt the photo, so using the embedded link to PrivacyPoint, it sends an identifier for the friend and the encrypted key to PrivacyPoint.  Using the friends identifier PrivacyPoint asks PinFaceTwitPlus if the friend is allowed to view the photo, if they are PrivacyPoint decrypts the key and returns it to the friend whose browser can now locally decrypt the photo and display it.

The desirable properties of this system are these:
  • PinFaceTwitPlus does not have (direct) access to your resources - a vulnerability in PinFaceTwitPlus would not immediately leak user resources.
  • Your resources do not pass through PrivacyPoint, even though PrivacyPoint could decrypt them - a vulnerability in PrivacyPoint would not immediately leak user resources.
This system is not perfect for the following reasons:
  • PinFaceTwitPlus is acting as a decision point for which of your friends can see which of your resources.  This means it could add itself to your list of friends and grant itself access to your resources.  What makes this issue potentially tolerable is that to access your resources it must ask PrivacyPoint for the decryption key, which means PrivacyPoint has a record of it asking; a record that would be viewable by you to audit who accesses your resources.
  • PinFaceTwitPlus can impersonate any of your friends though, so in any access audit log it would just appear as a friend viewed your resource.  I don't see a (sensible) technical solution to this, but I suspect there is pressure on PinFaceTwitPlus to not allow it's employees to impersonate it's users due to the negative business impact.
From a design point of view the goal has been to separate the resource from the social media site, and this has been done by distributing the trust between 2 services; PinFaceTwitPlus to store the encrypted resource and decide who has access, and PrivacyPoint to hold the decryption keys and enforce the resource access decision.

Clearly I have left out vast amounts of detail (lots of which would need to be thought through more thoroughly) as it's difficult to express it all in a blog post.

To be honest I wouldn't give this design high practicality points as it requires a fairly substantial infrastructure in order to work.  Still, any practical system often starts out as something that's possible and evolves into something that's probable.

No comments:

Post a comment