Change Facebook to use encryption, to increase privacy

         Please send any feedback to me.

Motivation section
New Architecture section
Notes section




Motivation:


With revelations of NSA spying, and legal requirements that corporations surrender user data when served with a warrant or subpoena or National Security Letter, many people feel corporate control of their data is bad.

Encryption can be used to reduce this problem: a user's data can be stored encrypted, so even the central corporation can't read it, and thus can't surrender it to the government.

The following is a proposed way Facebook Corp could change the Facebook system to use encryption to increase user's privacy.



Anticipated criticisms:




New Architecture:


  1. Facebook Corp would change its central server to:

  2. Each User and Group Owner will run their own little Facebook service and Facebook database on their machine.

    The database contains:
    A single machine could run the services and databases for multiple users (such as in a family) and for multiple Groups.

    How does a user use Facebook if they are not at their home machine, and their home machine is shut down ? They can't. (Unless they take their database with them, on a thumb-drive. And if the home machine IS running, they could access the database across the internet.)

    For people who don't want to run a local service on their machine, or leave their home machine running while they are traveling, hosting services could offer to run services for many users. This really would be almost mandatory for Group Owners.

  3. Keep the standard web-based Facebook UI. Just have it connect to the local service as well as the Facebook server.

  4. When user A wants to read a Thread owned by user B, user A has to obtain the Thread's encryption key, in one of three ways:
    1. Finds Thread ID and encryption key in the local cache.
    2. Finds Thread owner's IP address in the local cache, uses it to contact Thread owner, fetches Thread ID and encryption key into cache, go to step 1.
    3. Contacts Facebook server to fetch Thread owner's IP address into cache, go to step 2.
    If step 1 fails, and the Thread owner is offline (logged out), the Thread can not be read at this time (a MAJOR problem with this design).

    When a user logs in to Facebook, perhaps there is a list of all users who tried to contact this user while they were offline. Then those users can be notified to try again now.

    When a user creates a new Thread, perhaps they immediately try to send the Thread ID and encryption key to all of the users who can read that Thread (or, the first 200 users in that list). This will succeed for the users who are logged on at the time the Thread is created, putting the information into their local caches.

    Perhaps there could be some central server for users to send keys to each other, to avoid the "thread owner is offline" problem. The clearinghouse shouldn't be owned by Facebook Corp, and shouldn't retain keys after they've been delivered.

    Another possibility: if Thread owner is offline when someone wants the key, Facebook server directs them to another user who has access to that Thread. Facebook server never sees keys, but does know who (probably) possesses the keys.





Notes:






Last update: November 2013.



Bookmark and Share

Home       Site Map

Privacy policy