grab the pitchforks!… again

I’m fascinated with how quickly people have reached for the pitchforks recently when the slightest whiff of a privacy/security violation occurs.

Last week, a few interesting security tidbits came to light regarding Dropbox, the increasingly popular cloud-based file storage and synchronization service. There’s some interesting discussion of de-duplication techniques which might lead to Oracle attacks, etc., but the most important issue is that, suddenly, everyone’s realizing that Dropbox could, if needed, access your files. Miguel de Icaza wonders if Dropbox is pitching snake oil.

Yes, Dropbox staff can, if needed, access your files. I don’t mean to harp on my fellow technologists but… this has been obvious since day 1, because Dropbox offers a web-based interface to download your files, and even with the latest HTML5 technology, you’d be very hard-pressed to do in-browser file decryption. Let’s say you still don’t buy that, you still think that Dropbox might find a way to encrypt files and decrypt them in your browser. Dropbox also offers a password recovery mechanism, which means they can fully simulate you, the user, including, of course, getting at your files.

In other words, unless you’re ready to lose the convenience of password resets and web-based UI, Dropbox inherently has access to your files. Just like Facebook has access to your entire account, and Google to all of your docs, spreadsheets, etc. The only question is what kinds of internal safeguards do these companies have to prevent abuse by employees. Unless you’ve worked there, it’s hard to know. You could ask Dropbox to do third-party auditing, like Miguel proposes, but in my experience that provides little real security, since you have little way to know what that third-party actually did as part of their auditing (was it just “logic and accuracy” testing?)

The other thing we could ask is for the law to finally recognize that my files stored on Dropbox are no different than my files stored on a hard drive in my basement, from a legal perspective. They’re my property. And accessing them should require the same level of judicial oversight as a warrant to my home. That’s what a group of young MIT techies (myself included) and Harvard lawyers proposed in 1998.

But back to Dropbox. Did they do something wrong? Yes, they did. They exaggerated their security and privacy claims. Just like almost every other cloud data host today. I wish, instead of picking on whichever startup suddenly succeeds, we picked on the industry as a whole. Stop talking about encryption in transit and encryption at rest in the same breath, as if they were the same thing. Stop using “encryption” as a synonym for “secure.” Stop saying “military-grade security.” Start being honest about who can access what.

And we, technologists, should stop with the drama, and not fall prey to the inflated expectations that marketing-heavy security policies have set. The Dropbox weaknesses should have been obvious to technologists from day one. The problem is that all privacy policies and security statements make exaggerated claims using reassuring keywords. Let’s harp on that.

10 thoughts on “grab the pitchforks!… again

  1. Thanks for airing this view.

    A related point is that people like to pretend that the security-usability tradeoff doesn’t exist. Dropbox optimizes for convenience, and security-wise this is absolutely the best they can do, and people need to get used to it.

    For most users, myself included, convenience trumps the benefits of client-side encryption. What would be good though is if they offered a specific folder that had that capability.

  2. If you don’t control it, don’t assume it can’t be accessed. If you’re really worried about people accessing your Dropbox files, put a TrueCrypt/Encrypted DMG in dropbox and use that. At that point, the file can be accessed, but the key is still in your control (theoretically).

  3. I don’t think we’ll solve this one with the legal system any time soon. But technology moves fast and we can and should do our best to improve the situation with better technology.

    We need Web APIs for cleint side encryption and decryption. DOMCrypt is a good start but something like this needs to be standardized and available in all browsers.

    Then we need a few popular services to do the right thing and offer users a choice — convenience and sharing vs security and privacy.

    Then we need an education campaign to help users to understand these choices and the trade-offs they imply.

    – Asa

  4. So it says “last updated 4/13.” I think most of the hoopla happened afterwards. I would like to see them respond, that’s for sure, and I think their response will say a lot about whether they want to be responsible, or want to sweep this under the rug.

  5. Only the legal system can help protect us from abusive court orders. Even with DOMCrypt, a web site under court order could deliver modified HTML to the user that extracts the data and ships it back to home base.

    I agree with you regarding choice and education. Education, especially, is very hard.

  6. You actually don’t even need a username or password to access someone’s files as pointed out by Derek Newton’s blog post which initially trigged all these other “Drop box lacks security” blog posts In response to Derek’s post several other people have created proof of concept “trojans” and posted the source on Hacker News to show how easy it is to steal stupid people’s data. Drop Box’s security, for the most part, was meant to protect you from remote users accessing your files. It was never meant to protect you from having actual access to the files….which is bad on their part considering a person doesn’t necessarily have to be there at the computer to still gain control (ie. a trojan can be placed and the config.db could be stolen).

  7. There was a lengthy discussion (with lots of links) about this problem on Greg Laden’s Blog in september:

    The main problem is that efficient sync (like rsync) seems to be fundamentally contradictory to real encryption (which requires to flip on average 50% of the ciphertext bits if any change to either plaintext or key happens). I have no mathematical proof, but my guess is that securely encrypted efficient (i.e. differential or similar) remote backups are theoretically impossible.

    I would not hope for laws to improve – if they change at all, then for the worse.

  8. I use encfs – it does per file encryption which is probably inherently less secure then something like truecrypt but it’s easier to rsync and it seems secure enough.

Comments are closed.