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.
[ Cybersecurity is no joke. But what do you think about this New Security Trend: Bring Your Own Attorney. ]
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.