>You could always hash the e-mails, although this would make resetting your password impossible.

Not really - everywhere I've gone has asked me for my email to send me my password. Same principle as with passwords: enter your email, we hash it, if it matches a hashed email in the DB, we send a 'reset' email to the address you entered.

Would splitting the data in half work?

I mean literally cutting the data sent into two pieces and each piece entering a different database server in a different country. Then, when requested, pulling both pieces and sending them to users who patch them together with client side script...?

So, basically a RAID array? You'd have to have a fair amount of redundancy, to make sure that if your Dystopiastan server gets taken down, your servers in Freedomia and Libertania have enough data to continue serving your users. (And yet you can't have so much redundancy that a single country could rebuild your database if they take enough servers.)

Not to mention, latency issues would be a problem.

There has been some academic work on this (CIDR'05), but I'm not sure if it has been used in practice.

http://ilpubs.stanford.edu/659/

Thanks, printed it off, will try to read on the train.

Sounds like a good use case for Instapaper :P

Might not want the FBI to know he read the article if they come back for a "followup visit"

Yes, OAuth tokens contain the Facebook id of the user. It is unlikely that this would matter since session tokens (required for most permissions) expire after an hour (no reason to store those) and sessionless tokens are per-application not per-user.

However, obtaining the application credentials for Instapaper would allow you to limited access to a user account on behalf of Instapaper. Since the credentials for doing this are per-application, Instapaper would likely store your Facebook id in their database. Given a Facebook id, you can easily see the account name by visiting https://graph.facebook.com/$id.