Dropbox: when a security hole becomes a feature, and vice versa.

0.

About a month ago I blogged about the requirement to protect cloud storage users from the cloud service providers. I offered a mechanism to protect a person’s files from the cloud and gave Dropbox as an example. The reason I provided Dropbox as the example was both the simplicity of things, and that due to Dropbox’s architecture, I knew that the last month’s events are bound to happen. First, we found out that Dropbox did not protect end-users from the cloud and allowed law enforcement to access them, as a part of their privacy policy. Second, Dropbox misbehaved when terminating an open source file sharing project which based itself on a file sharing flaw in Dropbox, which was a feature, not a bug.

1.

In order to understand how the feature worked, you have to understand how Dropbox dealt with files, as a part of their service: Dropbox recognized files and their digital signatures, and when it saw that it already had a copy of the file, it used the existing copy instead of downloading it from the end-user’s computer. For example, if I wanted to put my (legally purchased) Justin Bieber MP3s in my Dropbox, then when connecting to the Internet, Dropbox would have recognized that it already has those files from another person (who, of course, legally purchased them) and just copied them to my cloud folder. This was not a bug, but a feature: it saved storage, bandwidth and computing power and it allowed users to thrive.

2.

However, it also allowed another thing: some people decided to use Dropbox to share files: all they needed to know in order to do so was to share the hash value of each file, where Dropbox did the rest: it took the files from the cloud and copied them to their computers. Of course, they could always create shared folders of pirate downloads and share them with the public, but the users decided to create a peer-to-peer system for cloud hosting. However, Dropbox did not like the idea at all and issued DMCA takedowns of the source code for the hack, called Dropship, calling the hosting companies that host the files (in this case, Dropbox itself) not to host it, as well as amended their services just to avoid such use.

3.

Dropship did not do anything illegal, it just did to Dropbox what AIMSter did to chat services a decade ago, When they found a security hole, which allowed you to copy files simply by knowing their Hash Value, Dropship showed the public the flaw with Dropbox, the fact that any person can copy any file from any other Dropbox without knowing anything but the Hash Value; this was not a feature anymore, it became a bug; where the only way to terminate the bug is actually to rewrite Dropbox with privacy by design.

4.

Dropbox came out as the lesser party. After enjoying a wave of great publicity and reaching 25,000,000 users without any marketing or advertisements, it seems that they jumped a bit too high. Freedom and flexibility were the main reasons to use Dropbox, as well as the lack of actual competition. However, once you know that your information is both insecure and constantly monitored, you feel less than safe in the cloud.

5.

Maybe it’s time to reconsider the whole cloud hosting model. Dropbox was great while it lasted, but it should go in the way of the dodo and find a more cooperative, interactive, friendly cloud storage service.

One thought on “Dropbox: when a security hole becomes a feature, and vice versa.

Leave a Reply

Your email address will not be published. Required fields are marked *