It's all relative. The problem was somewhat (unintentionally?) misleading marketing and disclosure, not their actual architecture, at least for most uses of dropbox.

Dropbox seems to have decent transport security, which is more than 99% of apps. Keeping files in dropbox might also keep unencrypted and out of date copies from persisting on local drives, random USB thumb drives, borrowed computers, computers at the print shop, etc.

Yes, someone who compromises dropbox, or a rogue high-level dropbox employee, or a law enforcement officer with a warrant, could get access to your files on disk at dropbox. Dropbox is probably not the weak link, though.

For a normal user (individual or corporate), trusting dropbox is not any worse than trusting gmail or anyone else who has your data and has market, legal, and other reasons to keep it safe for you. I've met with a bunch of top-tier attorneys in the past couple weeks, and none of them want to mess with PGP; they trust that if gmail or an outsourced exchange provider were snooping on their messages, there would be legal recourse; sure, it's an issue if there's no way to prove it, but generally they are pretty trusting of major service providers.

I personally don't use dropbox for anything except "public" files, because I try to constrain long-term storage of my data to my own infrastructure, or something encrypted end to end and fully under my control. However, dropbox is probably a cut above the effective level of security most organizations or individuals have in practice.

I'd sure prefer if dropbox did client-side encryption and never had access to the keys, but then you'd also need to trust that the dropbox binary doesn't secretly send your password to Russia, and that no future version of the dropbox binary that you use has the send-to-Russia feature added. And, you'd need to trust that none of the devices from which you access dropbox has been keyloggered, trojaned, etc.

Of course, dropbox seems pretty robust in terms of availability; I just lost an SSD which didn't have timely backups of certain files, something which is going to ruin my weekend and which would have been avoided had I been less paranoid and used dropbox more.

(and, I'm working on solving the issues with trusting remote services, actually...)

| Dropbox seems to have decent transport security

Unless you're using the mobile app.

| For a normal user (individual or corporate), trusting dropbox is not any worse than trusting gmail or anyone else who has your data and has market, legal, and other reasons to keep it safe for you.

Except Google doesn't (afaik) lie about their ability to en/decrypt or view your personal data.

Yeah, both points are true. At least it looks like they are fixing the mobile app ssl thing.

I think lying is a bit excessive as a description; they were misleading, hopefully unintentionally, on something where full and clear disclosure would have been a better standard. It isn't like Crypto AG or other famous vendor vs. users situations, though. Ascribing malice to them seems inappropriate.

Encrypt with Truecrypt, share with Dropbox. Problem solved.

> Encrypt with Truecrypt, share with Dropbox. Problem solved.

Not so fast. How big is the binary diff when you change a file within a Truecrypt volume? Ie, how much Dropbox bandwidth will you be using, even with a small change?

I performed the following experiment. Start with a 250M Truecrypt volume. Mount it. Create a 1M file from /dev/random. Unmount the volume.

Now, look at what blocks in the Truecrypt volume file have changed. Dropbox uses a 4M blocksize [1].

  seq 0 63 | while read i; do
    { dd bs=4M skip=$i count=0; dd bs=4M count=1; } < truecrypt.bin.before | md5sum
  done 2>/dev/null | sort > md5s.before

  seq 0 63 | while read i; do
    { dd bs=4M skip=$i count=0; dd bs=4M count=1; } < truecrypt.bin.after | md5sum
  done 2>/dev/null | sort > md5s.after

  comm -13 md5s.before md5s.after | wc -l
  8

Conclusion: in this case, Dropbox will transfer 32M (8x the normal 4M) because I added a 1M file to my Truecrypt volume. Note: I haven't tried adding bigger files, but suspect the number of blocks changed will go up linearly but steeply with the size of the added file.

It's not actually that surprising that TrueCrypt mixes file changes throughout the volume file.

Why bring this all up? Because something that does client side block encryption (tarsnap is an example) would only transfer the affected block. 4M, if that's the block size.

And you don't have to trust the cloud storage provider at all.

EDIT: My pipelines were wrong on the first go, suggesting a much larger number of differing blocks. Sorry about that.

[1] http://forums.dropbox.com/topic.php?id=17631

Except then you can't use those files on mobile devices or from the web UI, both of which are useful (my primary interest in dropbox, and the one thing I can't trivially accomplish on my own, is the iOS device support. The alternative is just to use Apple's iDisk, which has exactly the same risks as Dropbox, minus the cross-platform capabilities.)

I'm not sure if it's helpful to you, but I use Keypass & Dropbox to sync some encrypted data to my Android phone. It's limited but useful for storing sensitive text. There is an iPhone app: http://ikeepass.de/

I use 1password and wifi syncing. I asked them to add WebDAV support to store the bundle, which is how omnifocus does this, which is probably the most cloudiness I will accept for my password file.