Dropbox (everyone’s favorite utility) has been taking a lot of heat lately from users, privacy nuts, and now the FTC over its encryption and data security practices. The two points that people seem to have trouble with are the following, from the FAQ Dropbox [posted](http://blog.dropbox.com/?p=735):
>Like most major online services, we have a small number of employees who must be able to access user data when legally required to do so. But that’s the exception, not the rule. We have strict policy and technical access controls that prohibit employee access except in these rare circumstances. In addition, we employ a number of physical and electronic security measures to protect user information from unauthorized access.
The above is likely due, in part, to this (from the same FAQ):
>That said, like all U.S. companies, we must follow U.S. law. That means that the government sometimes requests us (as it does similar companies like Apple, Google, Skype, and Twitter) to turn over user information in response to requests for which the law requires that we comply.
Basically Dropbox can look at any file you have stored on it’s service if it wants to and will turn over those contents (unencrypted) if compelled by court order. For law abiding citizens this is of no concern, for nefarious folk this is probably a deal breaker. The real question I have, I stated earlier when commenting on the [matter](http://brooksreview.net/2011/04/dropbox-security-2/):
>Is this like setting off a nuke — where two people need to turn two different keys to make it happen? If not, why not? That’s what I want to know.
Basically of the employees that can access my data — what security protocols must they go through to access it.
It seems though this issue runs a bit deeper than I originally thought as Mathew J. Schwartz for Information Week [reports](http://www.informationweek.com/news/storage/security/229500683):
>In particular, Dropbox–unlike some of its competitors, such as Spideroak and Tarsnap–uses file deduplication when files are first uploaded. As a result, when a user uploads a file, the Dropbox site first studies the file to see if it’s been uploaded by a different user. If so, Dropbox just links to the previously uploaded file.
I knew about the file deduplication methods that Dropbox is using, but never thought about how that could be a bad thing from a privacy standpoint, Schwartz adds:
>For starters, deduplication can make it easy for outsiders to know what’s already on Dropbox’s servers, since the website studies a file to see if it’s seen it before. “While this doesn’t tell you which other users have uploaded this file, presumably Dropbox can figure it out. I doubt they’d do it if asked by a random user, but when presented with a court order, they could be forced to,” he [Christopher Soghoian] said. “What this means, is that from the comfort of their desks, law enforcement agencies or copyright trolls can upload contraband files to Dropbox, watch the amount of bandwidth consumed, and then obtain a court order if the amount of data transferred is smaller than the size of the file.”
Again, not a problem unless you are breaking the law by storing illegal songs, videos, and the like on Dropbox.
Another thought this entire debate has set off is that Dropbox, I believe, uses Amazon’s S3 storage — what access does Amazon have to the data if compelled by law?
### Server Side ###
I am going to get out of my knowledge base for a little bit, but when all these issues came to a head a while back I had an interesting email conversation with someone that has intimate knowledge of these systems. The gist of the conversation is that Dropbox does server-side decryption and encryption — that’s why the key is stored with them and that is how they have access. Competitors like Spideroak, for instance, do client side encryption and decryption.
Client side means that they don’t have access to unencrypted data — it means that even if they turned over your data, the government agency would have to work to decrypt it because the don’t hold the key — you do. Dropbox (to the best of what I understand) doesn’t use this method because it would significantly slow down the user computer — as that is the computer that would be encrypting and decrypting data on the fly.
To add more complications, mobile apps — such as Dropbox on your iPhone — would have quite a bit of trouble (if it is even feasible/possible) to do this on the device. Meaning that with services like Spideroak the mobile devices sends the encrypted password back to Spideroak to decrypt the data first, thus breaking the security chain.
It’s a tough nut for these companies to crack because the heavier and more secure the system the slower it is — the slower the utility, the less utility it actually has to users.
### Solutions ###
Back when this all came out I mentioned that I will begin storing sensitive data in Dropbox inside of encrypted DMG files. This works and keeps your data secure, but again causes a massive inconvenience when you need to get that data because you need to open the file and enter a password.
Patrick Rhone recently [commented](http://minimalmac.com/post/5534765499/dropbox-lied-to-users-about-data-security-complaint-to):
>If you want your data to be 100% secure, here’s the solution:
>Don’t have data.
He’s absolutely right. The point is really this: don’t assume the data you store in the cloud is ever only accessible to you, thus don’t store sensitive data in the cloud. In other words: don’t be the villain telling the hero all your plans right before the hero escapes.