Add an option to create secure folders which are encrypted client side, using a key which is only available client side. these folders wouldn't be usable with things like the web interface because there is no server side capability to decrypt their contents.
"But Drew!" Jimmy exclaims, "What if someone uses Dropbox at work and at home? Are these special folders going to be synced across computers? If so, how will the key be easily transferred (email, USB stick)? What happens when the user's hard drive crashes and his key file is lost permanently? Otherwise, if these special folders won't be synced, then what is the point of the folders being in Dropbox at all?"
Those are just minor implementation details. Off the top of my head, the key can be stored as a password protected file inside the Dropbox account its self, synced like any normal file, but perhaps hidden from the end user. The encrypted folders contents are synced like any others. On any client where you want to access the decrypted folder contents, you'd just enter the password to decrypt the password protected key and the folder contents would become available. If you forget the password then you're screwed.
The only way Dropbox could access those files then would be to backdoor the Dropbox client. But if they were going to do that, it wouldn't even be safe to use TrueCrypt or GnuPG either.
Will that work with the Dropbox clients on my Android phone, my Android tablet, my Windows desktop, my OSX laptop and my Linux server? If not, then it's no use to me.
It works well for me (primarily linux, also Windows in a linux-hosted VM with dropbox served locally via samba). ecryptfs is standard on Debian and Ubuntu (very likely Redhat as they develop it). I have noticed some efforts to get ecryptfs running on the sdcard/data partitions in Android, but I haven't tried them yet. I haven't used Dropbox on Android since I learned their mobile client doesn't use https. As far as OSX goes, I don't know and I'm unlikely to care.
The Android and iOS mobile clients don't currently use HTTPS for transferring meta-data, but do for file contents.
ecryptfs isn't a suitable alternative to my suggested solution which would involve all Dropbox clients having the capability built in. Of course, people who are really paranoid can use their own layer of encryption on top as well/instead.
Fair enough, but having something built in to Dropbox for people who value convenience wouldn't prevent anyone from using solutions like ecryptfs as well.
