New Architecture section
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.
- "Why not just get rid of Facebook, and everyone move to Diaspora or something ?"
Facebook users won't move. Facebook works for them, it's good enough, they don't need flashy features,
most of them don't care much about privacy or buy into the "Facebook Corp is evil" mantra.
They have a big "investment" in Facebook (Friend relationships, photo albums, groups, Likes, conversations
in progress, history, knowledge of how to use it, etc);
it would be hard for them to move.
And they'd have to get all of their Friends and Groups to move simultaneously.
Not going to happen.
- "This change would be a big effort for Facebook Corp; why should they do it ?"
There are benefits for Facebook Corp, listed in the "Notes" section later.
I don't know if the benefits are big enough that they'd be willing to pay the costs to do it.
- Facebook Corp would change its central server to:
- Store all Posts and Comments (Threads) and Pictures in encrypted form. A few ad-targeting keywords will
be stored in plaintext with each Thread and Picture.
- Store each user's current IP address (if logged on).
- When asked by a user allowed to see a Thread (same for Pictures) owned by user X, supply user X's current IP address to the requester.
- Each User and Group Owner will run their own little Facebook service and Facebook database on their machine.
The database contains:
- A list of the Threads owned by this user, and the encryption key associated with each Thread. Each Thread may
have a different key.
- A cache of the Threads recently read by this user: ownerID, ThreadID, and encryption key associated with each Thread.
- A cache of the IP addresses for users whose Threads have been read by this user.
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.
- Keep the standard web-based Facebook UI. Just have it connect to the local service as well as
the Facebook server.
- 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:
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).
- Finds Thread ID and encryption key in the local cache.
- 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.
- Contacts Facebook server to fetch Thread owner's IP address into cache, go to step 2.
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.
- The change from old to new architecture could be phased in:
- Change Facebook server to support encryption of Threads, user IP addresses, etc.
- Make all users run a Facebook local service on their machines, and
access Facebook through that.
- From this point, all new Threads are created encrypted, by the local services.
- Have the local services slowly go through all of their existing old (unencrypted) Threads, generating keys and encrypting them.
- What has been achieved ?
- User experience:
- Facebook client UI and functionality haven't changed at all; no change for users.
- Facebook existing user base and user content haven't changed at all.
- Facebook Corp:
- Facebook Corp still makes money, and controls ads and user accounts and logins.
- Facebook Corp gets to trumpet itself as a "privacy champion".
- Facebook Corp spends less effort responding to warrants and subpoenas, because they no longer can read the data.
- Oppressive governments could no longer pressure Facebook Corp into censorship, because they no longer can read the data.
- Data for Threads, Pictures, etc is stored encrypted, and Facebook doesn't have the keys to decrypt the content.
- Problems and issues:
- Since admins at Facebook Corp can no longer read content directly, they can't root out systematic problems such
as spammers and scammers as easily as they could before. They would have to rely on users reporting each bad post or comment (a report
would include the Thread ID and encryption key needed to let Facebook Corp read the bad thread).
Once a pattern of bad behavior has been established, Facebook Corp can delete the offending user.
- What kind of encryption should be used to encrypt Threads and other content ?
Probably single-key symmetric encryption.
Some are Blowfish, AES, and DES.
Are they legal in all countries ?
Will the size of the data increase greatly when encrypted ?
Last update: November 2013.
Home Site Map