As a real practical question out of curiosity: how would you design their system differently so unauthorized people having only your hard drives couldn't get any data at all?
On my collocated server, I use encrypted LVM for all of my filesystems (except /boot, of course). On my next hardware upgrade cycle, I'm going to install a USB gyroscope (inside the chassis, using one of the front USB headers) and write a daemon that will issue a `umount -lfa && halt -n` if the box is ever moved.
Note that this isn't simply to keep prying eyes off my data; I live near an overdue earthquake fault line. When it does finally give, I should have a (slightly) better chance of the machine coming through intact.
Full-disk encryption. You enter the key whenever the system needs to be rebooted. I know at least one company that does this with all of their US-hosted servers.
Perhaps all their employees live in the US, so they consider it not worth the trouble to fly someone to Indonesia whenever a server in Jakarta needs rebooting.
This would only be protection against thieves that steal your harddrives, if the US government had your drives they can legally compel you to divulge your password.
The company in question is actually located outside of the US, and so are all employees who have access to the key. It keeps its servers in the US only because of issues with cost and latency, I think.
If there was a court order for the decryption keys for your drive and you gave them a key that destroyed it, you would almost certainly be found guilty of deliberately destroying evidence.
>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.
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.
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.
If the hardware is in hand then I don't see any practical way to protect the information. The only way that works is to not store the information in cloud servers.
Note that this isn't simply to keep prying eyes off my data; I live near an overdue earthquake fault line. When it does finally give, I should have a (slightly) better chance of the machine coming through intact.