I have already written about how I have enthusiastically adopted Amazon S3 as a solution for off-site backups, and for publishing heavier content than my home server could handle, such as video. The other day one of the hosts of Buzz Out Loud mentioned that he didn't trust his personal data in the cloud just yet. He could see that it was the way of the future, but was not yet comfortable with the trust issues. Then then this week John C. Dvorak echoed the same concerns on TWiT.

They are right of course, and I don't trust Amazon with my personal data either. I have a lot of personal data to back up, such as every e-mail I wrote or received from 1998 to around 2005 (I've let GMail handle it since then, where I technically ought to back it up via POP, but haven't...), not to mention other personal identifying data that I would not want in the wrong hands. It is not a question of trusting Amazon to abide by the terms of service—I do trust them as a company, but no company can be immune from a rogue employee or corporate espionage, and it is not easy to trust their security procedures unless you can audit them yourself at whim, which is a practical impossibility.

My solution to this problem is one that your average user, even a geek like Tom Merritt, probably can't do: I wrote my own S3 client which uses strong encryption on the I/O stream as it leaves my computer. Amazon thus stores for me a few gigabytes of what is literally useless ones and zeroes, but when I download it with my special client it is decrypted on the fly back into the original file. Such a solution requires not only the knowledge of how to code one's own S3 client, but also enough knowledge of cryptography and computer security to know whether a solution is really secure, or whether it could be cracked by those with enough resources. I'm fortunate to be in a position do do this by myself.

I'm sure that at some point there will be, and maybe there already is, a client program you can download to do this for you, where you set your own key phrase. But unless you audit the entire source code of that program, you can't be sure that it isn't sending your key out to some third party. An open source solution would allow you to check this, but frankly the time it would take to audit all the code would be longer than the time it takes to write your own (at least it was in my case). But in the absence of a widely audited and popularly acknowledeged open source way of encrypting the stream before it leaves your computer, we'll never get beyond the issue of trusting the company you're giving your data to.

(The only problem, now, is keeping my source code to my client and my key file safe, since if I lose those I would be left unable to download my own backups!*)

* Don't worry, I have worked out a solution for this, but I'm not going to post it here!