[SirWart]

Just to clarify things (I work on the iPhone app), the only thing being transmitted in plaintext are the names of the files, not the file data or username/password, and because we are using OAuth, no session cookie is getting sent so you can't steal credentials (a la firesheep). This is also not a technical limitation, we already use SSL in our app so sending metadata over https is a trivial change.

The only reason we send metadata unencrypted is for user experience issues: setting up SSL requires extra round trips , and because cell networks have a lot of latency this makes browsing your Dropbox slower. We are close to shipping our next release and we'll definitely be reviewing our policy before we ship, so what are people's feelings on this tradeoff?

[cstross]

Here's my problem with not encrypting metadata:

Suppose we have a determined attacker who is looking to target DropBox accounts. They can attempt to crack username/password pairs, or maybe intercept an entire SSL session and do a brute-force attack on it later. (If there are virgin credit card records in that session stream it may be worth doing this even if the cost is CPU-years.)

Letting this attacker see the names of files in a session gives them a clue as to what's stored in the DropBox account in question, and therefore lets them choose their targets -- if a user is uploading nothing but files with names like Hot-Fuzz-Directors-Cut.h264, they probably don't want to bother: but if the user is updating files like customer-accounts-backup.sql or passwords.txt, there may be money to be made. If the metadata is encrypted it forces attackers to tackle accounts at random in hope of finding something worth money. Which is much less attractive because the attacker has to do a lot more work in order to be assured of a pay-off.

At the very least, it would be best if the decision of whether or not to encrypt metadata was in the customer's hands. (Then maybe I wouldn't need to keep my business-critical files on DropBox inside an encrypted filesystem image, which almost certainly causes a much worse performance hit than an extra SSL roundtrip.)

[izak30]

I _definitely_ prefer the speed/smaller bandwidth footprint over filename security. I use Dropbox as a utility for sharing, not a mission critical thing that stores sensitive business or client files (or most particularly, filenames).

I understand that some people do, and How this could be important to them.

[edanm]

Personally, I'd prefer Dropbox being quicker to Dropbox being more private. But my guess is most of the techie-crowd will disagree. Also, my guess is most of the non-techie crowd won't understand the issue, but will assume filenames are not able to be snooped on.

[JoachimSchipper]

Doesn't SSL caching, or even just leaving the connection open, take care of the performance issue?