Dropbox File Brouhaha: Use Case Is The Issue

Before you pull your files over a perceived security threat, ask yourself: How are you using the cloud file sharing service?

Some are shocked by the revelation last week that Dropbox is indeed opening files that are stored in its cloud-based file service. It's now clear that there was a good reason for this -- Dropbox was processing a word processing file in an automated manner in order to provide an additional feature to users. Those who are shocked simply haven't thought through what the use case is.

From the time that cloud technology hit the streets, responsible cloud proponents were cautioning that not every use case for cloud was an appropriate one. Should you put your city government emails in Google mail? In the past, the Los Angeles CIO said, "Yes." But should you put law enforcement emails into that same Gmail store? In the past, the LAPD chief said, "No." You can debate these particular instances endlessly, but the point is this: Not everyone is comfortable with every use case.

Those that think of Dropbox as a place to put docs simply don't understand the app, and therefore can't appropriately match their use case to the app. Dropbox is not simply a file repository. It's made to share files easily, it's made to be low cost via file de-duplication and AWS storage, and it's made to be convenient to manipulate files via a Web interface to do things such as restore old document versions.

A document preview is something that doesn't make sense if you think of Dropbox as your father's G: drive, where you have to wait for IT to restore your files that you bollix up. But if you think of Dropbox as something greater than that, it makes perfect sense for Dropbox to use software to process files to offer features beyond what Dad had.

But it's also really important for decision makers outside of IT to understand how this process works in order to figure out whether this is a "good use case" or a "bad use case."

When Dropbox generates a preview of a .gif, it's doing almost the exact same thing to your file that the preview of a .doc file does. Your file must be read and processed by software in order to do anything useful with it, such as generate a preview. I say "almost" the same because a .gif doesn't contain active content -- it's a pretty simple file format that doesn't contain complex requests. On the other hand, a .doc file can contain active content. That's what the Honey Docs tool allowed the security researcher to do -- to embed active content into the file that would be triggered upon "processing."

Trouble was, Dropbox used existing software -- LibreOffice -- which allowed the active content to activate. That was not such a great decision by Dropbox; it fails the test of "least privilege, least feature," where complexity is the enemy of security.

Aha! So Dropbox is evil, right? Not quite. If there was a security issue with active content in your files, the very worst case scenario is that it would affect you no matter whether it lived in Dropbox or on your desktop. You can't throw a monkey wrench into an off-premises machine and then blame the machine.

So, in general, Dropbox doing automated processing is probably fine with many use cases. But your specific use case will be your true test.

If you're saving Fort Knox alarm system plans, Dropbox probably isn't the place you want to store them. And, to be fair, I'm not sure that you'd want to store them using any cloud provider's app. Perhaps in those use cases, a good IT organization might use a belt-and-suspenders approach, where staff uses on-premises software to encrypt storage prior to it being synchronized to the cloud. Or maybe that wouldn't be secure enough either -- but the manager of Fort Knox would be the one to make that call after IT explains it. The point is that talking about use cases creates a good conversation: "Here are the risks. Are the portfolio of convenience and low cost worth the risks?" "Can we mitigate the risks for this use case?" And so on.

Finally, those who are anti-cloud will use this brouhaha to convince those who don't know any better that CLOUD = BAD, and PREMISES = GOOD. The argument will go something like, we control the installation and configuration of all software, so nothing bad will happen if we host internally. Except, despite internal IT controls, stuff happens with premises software a lot more often than IT organizations like to admit. For example, last year at this time, Sophos released a bad update that created chaos for lots of large organizations.

Unless we decide to write our own software and provide our own maintenance, we're always going to have the possibility of something bad happening that we're not 100% in control of.

So it's not "good cloud, bad cloud." It's "good use case, bad use case." But, above all, it's about having an informed conversation about the risks and the benefits of any tool or service, no matter where it lives.

When moving to the cloud I weighed up Dropbox to similar providers and found their security not meeting my requirements and in the end signed up with SpiderOak who have a zero knowledge privacy policy. Their web UI is a little clunky however

Dropbox checks docs because of the so called deduplication process. It means if you upload anything to their servers, they check it, whether it is up already. If it is, they provide a shortcut to the already uploaded file and delete yours. (eg. this works very well wit videos and music files). it is a common market practice among public cloud providers like Dropbox, Google Drive and so on, even many of those do it, who claimed to be secure (like Wuala). As far as I know dedup. is unavailable by client side encrypted tools, so you can skip all this trouble by using eg. Tresorit. Boxryptor is good to encrypt your dropbox, truecrypt is not really for could it's service focuses on local encryption.

I recommended Boxcryptor or Truecrypt for encryption options. These would be encrypting the file rather than password protecting. I agree with you that file specific passwords may not be the best approach.

Thank you for mentioning the balance regarding the disclosure. It certainly can be difficult to sort through the FUD at times like these.

Haha, except that Word encryption is notoriously flawed (or at least it was in the past). ;-)

For what it's worth, I agree with Laurie - definitely appreciated that you were balanced about the disclosure. Still, you should have seen the press releases that I got from vendors - "this proves, once and for allGǪ" Even when you ARE balanced, there's someone out there that isn't.

Exactly. The explanation of the automated process made sense and it turns out that this applied to any service that offers this browser specific feature. It may be possible that many people (especially users of the desktop client) did not realize what the "effects of rendering low-quality previews" truly meant. Just another piece of info they can use to assess risk.Other services were tested and no responses were received from the files, so that seemed interesting. A theoretical attack surface was mitigated due to the discussion as well. The follow-up post mentioned encryption options if privacy is a consideration for any service that may offer this feature.

Enterprise cloud adoption has evolved to the point where hybrid public/private cloud designs and use of multiple providers is common. Who among us has mastered provisioning resources in different clouds; allocating the right resources to each application; assigning applications to the "best" cloud provider based on performance or reliability requirements.