Dropbox Tries To Kill Off Open Source Project With DMCA Takedown
from the copyright-as-censorship dept
Teck points us to the troubling news of Dropbox seeking to kill off an open source project through questionable means, involving DMCA notices. As you may have heard, Dropbox got into a bit of a security/privacy kerfuffle lately after some researchers questioned the news that it uses a hash function to deduplicate files on its servers. If you don’t know, Dropbox is a cloud storage system that’s pretty useful. However, one of the ways it attempted to save some costs was that if you sought to upload a file that was identical to a file on someone else’s shared server, it wouldn’t actually “upload” your file, but just point you to the single file. There were clear security and privacy questions about this.
Of course, some noted that it could also represent an “opportunity” of sorts, and out of that came a project called Dropship — which used a little hack to use this deduping tech to make Dropbox think you were trying to upload specific content that you might not actually have, and then the actual file (if already stored in someone else’s Dropbox) would automatically appear in yours as well. Obviously, one key use of such a technology would be to make unauthorized copies of music and movies. Dropbox, for obvious reasons, didn’t like that aspect, but its response to this was pretty troubling: it focused on censoring information about Dropship.
Dropbox’s CTO and cofounder, Arash Ferdowsi, did not like Dropship. His reaction was swift. According to the project?s creator, Wladimir van der Laan, Ferdowsi contacted him soon after and requested “in a really civil way” that he take the project off of github. van der Laan complied.
Others quickly mirrored the project (some in their own Dropboxes) and Dropbox contacted all of them in a that same “civil way,” asking each to remove the content… but in at least one case, with Dan DeFelippi, they sent a DMCA takedown, despite not being the legitimate copyright holder (a violation of the DMCA process). When confronted on this, Dropbox backed down and claimed that the DMCA notice (and subsequent limits on the guy’s account) were really a mistake, but, along with admitting that, Dropbox was still asking the guy to remove all info about Dropship:
Soon after Ferdowsi contacted me directly, sending what I now assume is the same ?really civil? request he sent to others. He requested that I not only remove the archive from Dropbox but delete my posts on Hacker News, which at that point included the fake DMCA takedown. He outlined his objections, that Dropship reveals their proprietary client-server protocol and that it could be used for piracy. He told me that the DMCA takedown was a mistake and reverted the lockdown on my public files.
First of all, attempting to protect a proprietary protocol is going to get them nowhere. His argument implied security by obscurity. Security by obscurity falls completely flat on its face in this case since their client can be analyzed by anyone with the proper skills and could be deciphered again.
Second, dealing with piracy is the responsibility of Dropbox. It?s not the problem of an innocent hacker who wrote some useful code that could benefit legitimate users and advocates the use of his software for ?sharing photos, videos, public datasets, git-like source control, or even as building block for wiki-like distributed databases.?
While it’s good that Dropbox has been mostly civil on this, resorting to a DMCA takedown, even as a mistake, is problematic. Of course, you can’t totally blame Dropbox here. As we’ve seen, copyright maximalists in industry and in government seem quite eager to blame tech companies if their tech might possibly be used for unauthorized access. While the law is almost certainly on Dropbox’s side that it has no liability for Dropship, that wouldn’t necessarily prevent them from getting hit with an annoying lawsuit. It’s really an unfortunate sign of the copyright times.
Of course, the end result is also likely to be exactly the opposite of what those maximialists hope. While DeFelippi notes that Dropbox has been successful in getting many of these mirrors taken down, some are still up (including his) and the whole attempt to censor the project is only going to call that much more attention to it in the long run. I think there’s a name for that phenomenon…
Filed Under: copyright, dmca, dropbox, dropship
Companies: dropbox
Comments on “Dropbox Tries To Kill Off Open Source Project With DMCA Takedown”
Watch me
Of course, you can’t totally blame Dropbox here.
This is my totally blaming Dropbox face. They issued a false DMCA takedown. To themselves.
At least they didn’t sue claiming they own the word Drop.
Re: Re:
that would be “dRopbox”
I discovered the hashness of Dropbox about a year ago when I uploaded a large file that was instantly uploaded. A ~600 MB file available in seconds. That confused me for a moment until I realized what they were doing and it made sense.
Storing hashes of files and linking to those in the user’s accounts is no more of a privacy concern than having hashes of passwords on a server (which is impossible to get around). There’s really no problem, especially since the way it works is they store files, hash them, then each account has pointers to the hash, not the other way around. Furthermore, each account is encrypted and not available to be seen by Dropbox employees, so security is pretty much as good as it gets.
And if they didn’t reduce file duplication (a problem that many enterprises contend with on exchange servers when someone emails 50 people a 100MB slideshow, which goes through a revision and there’s another 100MB slideshow sent out, etc), it might not be FREE.
Re: Re:
“Storing hashes of files and linking to those in the user’s accounts is no more of a privacy concern than having hashes of passwords on a server (which is impossible to get around)”
Sure it is. Now it’s trivial find out if someone has a copy of a file. Would you want someone you don’t know be able to determine what files you have on your computer? If you care about privacy, the answer would be “no”.
“Furthermore, each account is encrypted and not available to be seen by Dropbox employees, so security is pretty much as good as it gets.”
Actually, Dropbox has now updated their privacy policy to explain that some of their employees are granted rights to decrypt your files and that they can/will decrypt files and hand them over to the gov’t when asked. This is pretty crappy from a security design perspective, but was required to allow Dropbox do de-duping of files on the back end to save them money on disk drives.
“And if they didn’t reduce file duplication …. it might not be FREE.”
Oh no! Not FREE! If only there was some standard way for me to compensate someone for a service that would meet my needs! What a horrible idea!
Re: Re: Re:
Actually, Dropbox has now updated their privacy policy to explain that some of their employees are granted rights to decrypt your files and that they can/will decrypt files and hand them over to the gov’t when asked.
I use JungleDisk, which has the ability to encrypt your files with a password ahead of time (such that not even JungleDisk can get at them).
Re: Re: Re:
Sure it is. Now it’s trivial find out if someone has a copy of a file. Would you want someone you don’t know be able to determine what files you have on your computer? If you care about privacy, the answer would be “no”.
Yes, it’s trivial to determine if someone on dropbox has the same *exact* file as you. You don’t know *who* has it, nor do you know *how many* people have it, but my the gods, you know what *someone* has it. I fail to see the security concern.
If you upload youMeAndFUDMakesThree.pdf and I’ve already got it, you’re not actually uploading it, you’re just having it linked to the copy already on their server. You don’t know that *I* have it. It doesn’t tag it as “linked from Joe’s Dropbox”, does it?
Re: Re: Re: Re:
“I fail to see the security concern.”
I’m sure you do. But your lack of perception does not cause the underlying issue to cease to exist. I invite you to consider, at whatever length is required for enlightenment, the consequences of this mechanism combined with the use of a medium-sized botnet (let’s say, 1 million systems, something easily affordable) and a distributed checksum database.
I presume that in some point in thinking through that, you’ll see it and make this noise: “Ohhhhhhhhh shhhhhhiii…”
Re: Re: Re:2 Re:
You’re suggesting brute forcing every possible hash?
Re: Re: Re:3 Re:
The modern equivalent of monkeys, typewriters, and Shakespeare.
Re: Re: Re:3 Re:
No, I’m not: there’s no need to. Are you not aware that large, readily accessible databases of hashes already exist?
(And even if they didn’t: an attacker armed with a million systems could easily generate their own pretty quickly.)
My larger point is this: when evaluating the threats that can be deployed against a service like Dropbox, one MUST presume attackers armed with (a) an arbitrarily large number of systems (b) essentially unlimited CPU, memory, disk storage and bandwidth (c) full access to legitimate and illegitimate databases (d) access to custom malware creation and testing facilities (e) intelligence and experience (f) access to inside information/insiders, whether via penetration or payoffs.
One must make these presumptions because this has been the threat environment for the better part of a decade. (In fact, this describes today’s typical large-scale spam operation, among others.)
Incidentally, in this particular instance, one should also presume that some number of systems in the botnet belong to Dropbox users. (Why? Because a large enough botnet will of course include some, just like it will include some eBay or WoW users. And because the botnet renter can stipulate same as a condition from the lessor. And because the botnet renter can of course mass-create Dropbox accounts.)
So, presuming savvy attackers with all these resources, does the problem become more obvious now?
Re: Re: Re:4 Re:
The most obvious problem I see is that you are a leaky douche canoe. Climb out and get to the point.
Re: Re: Re:5 Re:
I would think by now that anyone with even modest reasoning skills could have worked it out, but apparently the security clue level here is minimal.
What happens when an attacker enumerates a significant portion of the files held by Dropbox? Further, what happens when the attacker can control a significant portion of the files held by Dropbox? (That’s by number of files, not by aggregate size of files.)
If you can’t work this out, then you’re not worthy of participation in this discussion. Please seem remedial training in the basics of information security and come back when you’re at least minimally qualified.
Re: Re: Re:4 Re:
Are you talking about Rainbow Tables?
Jeebus man, what does it take to get you to spell out what the frak you’re on about?
Re: Re: Re:5 Re:
AC is bringing battleships to a war in the desert. The only real resources needed to force a hash collision are a large sum total of CPU power matched with network bandwidth and a lot of time. Insiders would be very useful though.
Rainbow tables are not involved. The equivalent is already provided by a large set of deduplicated files and their hashes on Dropbox.
Re: Re: Re:4 Re:
AC has made a couple of valid points but doesn’t do the analysis needed to find out if there is a real security vulnerability in the Dropbox context.
1). if the [SHA-2] hash of a file is known, that encryption on that file can be bypassed by anyone via Dropship. You have to be careful now, to not inadvertently publish the hash of any file you want to keep private. Why would anyone publish such a hash value? One answer is: to authenticate the file. This assumes you don’t encrypt the hash itself and you don’t use the hash as part of a MAC (Message Authentication Code). Such uses are real and Dropbox needs to address this. One way they could do it is to add a salt and make all their SHA-2 hashes unique to Dropbox.
If the file is a publicly known file to begin with, then the ability to decrypt it doesn’t matter. It does allow someone to infer the existence of a particular file on Dropbox’s server and possibly use that information to initiate legal action (e.g. a subpoena) to find out the owner(s) identity.
2). Dropbox is offering security to a large multitude of cloud users. They tout their usage of AES(256) to show the files are strongly protected. A user’s assumption now is that even governments with fantastic resources (e.g. NSA) cannot defeat this security. AC’s point is valid, Dropbox’s security must take into account the possibility of attackers armed with great resources.
What AC didn’t do was the analysis needed to find out if such an attack could be successful given Dropbox’s real level of security (see my post below). Dropbox’s real level of security does not correspond to a level of effort of 2^255. With their deduplicating/hash scheme it is actually:
2^99 / (total number of deduplicated files within Dropbox)
However, it is still outside of NSA’s ability to bypass encryption on even a random file. It would probably be much easier to brute force account passwords.
The weakest part of their security is that Dropbox knows the keys used to encrypt all their files. This allows the government to access any particular file through legal means (always justified and completely ethical of course).
Re: Re: Re:5 Re:
oops, minor mistake:
Dropbox’s real level of security is:
2^128 / (total number of deduplicated files within Dropbox)
Re: Re: Re:2 Re:
Distributed checksum database? If you are generating the checksums from already existing files, then you already have the files and don’t need copies of them from DropBox.
If you don’t have the hashes, then the chances of finding one are vanishingly small, even with millions of computers.
Let’s suppose there are 10 million users of DropBox and each user has 10 million files. That’s 10 ^ 14 files or hashes. Suppose the hash is weak and has a mere 128 bits. That’s 2 ^ 128 or more than 10 ^ 38 possible hashes. That means each possible hash value has less than one chance in 10 ^ 24 of being used. Let’s suppose you have 10 million bots each trying 10 million hashes per second. (Again 10 ^ 14 total hashes per second.) That’s going to take you 10 ^ 10 seconds, or 317 years before you get a hit.
Re: Re: Re:3 Re:
There are two mistakes in your calculation. You calculated how long it takes to be absolutely assured of a hit. One normally calculates how long it would take on average to get a hit (probability = .5). For a 128 bit hash, where one is trying to find a particular match (weak collision resistance) the level of brute force effort is 2^127.
The second mistake was not taking into account that in this context, where you just need to match any hash value on the server, strong collision resistance is required. The level of effort needed when strong collision resistance is required is 2^n/2. In this case 2^64. Your example of 10^14 files, or roughly 2^46 files, needs only 2^19 attempts. A single computer making 2^12 or ~4000 attempts per second could do this in 2 hours. Look up “birthday attack” in reference to hashes if you want more information.
luckily, Dropbox is using SHA-2 at 256 bits. So, instead of 2^19 attempts it is 2^83. With your botnet running 10^14 (2^46) hashes per second, it would take 4000 years on average to get a hit. Still, they inadvertently reduced file security with their setup. They are using AES(256) to encrypt files which requires a brute force level of effort of 2^255 to decrypt a particular file. If you want to decrypt a random file, this effort has been reduced to 2^128 divided by the number of total files on their servers. This is a significant reduction in security but is not catastrophic in the light of their choice to use SHA-2.
However, the other problems their system raises are more significant. (see my other post).
Re: Re: Re:
Although The Infamous Joe has already covered most of this…
You seemed to miss the part about “each account has pointers to the hash, not the other way around.” So yes, if I upload copyrightinfringingfile.rar and someone else has already uploaded it, I know I’m not the first one. But I can’t do ANYTHING with that knowledge.
Plus, Dropbox acts as a sort of version control system… it keeps previous versions of files. That gives further insight into the advantages of centrally located files with users having pointers to those files.
You also seemed to miss the point about the “FREE” comment. By removing file duplication, they can reduce their costs by a massive amount. They know their audience… dropbox is for file sharing, both legitimate and not. People do upload copyright infringing materials, but people also use dropbox for collaboration. Indeed, that is one of their main selling points. If there is a company using dropbox with many accounts with a bunch of shared files, storing all those duplicates would cost a lot of money when multiplied by all the users. The point of the comment on “FREE” was not that being “free” alleviates security concerns; it’s the massive cost savings on dropbox’s part that allows them to offer their services at an extremely competitive rate (or for free). If they had to store each person’s files without any sort of duplication control, their storage costs would go through the roof and they might not be able to even offer free service while making money.
So basically, Aaron T, you either lack reading comprehension skills or are being intentionally facetious, both of which I find annoying.
Re: Re: Re: Re:
So yes, if I upload copyrightinfringingfile.rar and someone else has already uploaded it, I know I’m not the first one. But I can’t do ANYTHING with that knowledge.
Well…
The lawyers can. Download popularinfringingmovie.avi via torrent. Upload to account on Dropbox. If it uploads instantly, at least one other person already uploaded it. Subpoena Dropbox to provide info on all users with access to it. Sue and profit.
(Public Service Announcement: Encrypt your files before uploading them to the cloud.)
Re: Re: Re:2 Re:
Just having a movie isn’t illegal. You have to distribute it. Now, one *might* suggest that uploading a movie to your personal cloud drive is illegal, but I don’t think that’s clear cut by any means, so uploading it to dropbox is probably legal. Distributing the hash file? No more illegal than a torrent file. So, when I dropship the hash file, have i made a copy? What laws were broken?
This isn’t meant as sarcasm, just asking the question.
So…isn’t Dropship just doing what Dropbox does…only…backwards?
What is the issue if so? An infringing file is the same either way, and it’s up to a rightsholder to point it out to Dropbox so they can take appropriate action.
Am I misunderstanding?
Re: Re:
I’m only guessing, but I imagine the problem would be that it would be almost impossible to hunt down the so-called infringers. You’d ‘dropship’ a json file and the file would appear in your dropbox folder. No IP address to pretend equals a person to sue people, it’s just there, already on the Dropbox server.
What are they going to do, go to Dropbox and ask for everyone that has myMovie.avi in their Dropbox folder? I didn’t upload it, I didn’t download it, I just tricked Dropbox into linking it to my Dropbox folder. Seems legally messy.
I love it. 😛
Re: Re: Re:
Well, there is one advantage for “content holders”: They only need to knock down one file to stop the infringement, as opposed to torrents where they would have to swat the whole swarm.
Re: Re: Re: Re:
But the file could also be legitimate for the original uploader.
Re: Re:
it lets you pretend to upload a file, so you can get access to it from Dropbox without having the actual file.
Pretend you want Windows 7. You find a title, and you use DropShip to match the file and name. Then you download Windows 7 from the other person’s Drop Box.
DCMA could come into play…if the Drop Box contains Copyrighted Material, then using Drop Ship breaks the encryption to allow the download.
However, what they really should be focused on is fixing the tech instead of lawsuits, they will never be able to suppress knowledge.
Re: Re: Re:
They did fix the tech. Dropship no longer works.
Re: Re:
So…isn’t Dropship just doing what Dropbox does…only…backwards?
What is the issue if so? An infringing file is the same either way, and it’s up to a rightsholder to point it out to Dropbox so they can take appropriate action.
Am I misunderstanding?
More like missing the bigger picture…
The way Dropbox was intended to work is that users would only have access to the files that they, themselves, uploaded. To save time and space, if Dropbox detects that a user is trying to upload a file that’s identical to one already on the server, they skip the upload and simply link to the existing file. However, users still only have access to files that they already had.
Dropship uses a file hash to tell the server that you have a file that you actually don’t and this fools the server into letting you access the copy that’s already on the server. In effect, it turns Dropbox into a distribution platform.
Let’s say that user A uploads the latest Hollywood movie. He then posts the file hash on a dozen sites. hundreds of people load up Dropship, input that hash, and suddenly, several hundred people have access to that movie. It basically turns it into a cyber-locker, like Rapidshare. One upload, distribute the code required to access the file and then anyone can have it.
Re: Re: Dubious value of de-duping.
I dunno. It sounds like this whole thing is built on a very shakey founding assumption. If people are storing their own files, then there should rarely if ever be any overlap. The value of that overlap should be very small possibly approaching the point where the de-duping technology is more trouble than it’s worth.
This whole thing seems to be an implicit assumption that the entire site is meant to be used for nefarious means where n+1001 users are all “sharing” the same copy of the same file.
I think this whole shenanigan more than anything paints DropBox with a big black brush.
Cool!
I didn’t know about this Dropship thing. I’m definitely going to check it out, if only out of curiosity…
oh, so they think they can take it down?
In France, we call that “la ran?on du succ?s”.
Check out https://github.com/nddrylliog/dropship if you’re curious.
Re: oh, so they think they can take it down?
thanks for that! i had expected someone to toss the source on one of the popular public torrent trackers, but no dice. you made my day!
encryption
I always used and am using one which provides you encryption facility….nothing less…
more info
The Hacker News thread on this has more information, including comments from 2 Dropbox employees. Apparently, the DMCA notice was a misfire from an automated system.
http://news.ycombinator.com/item?id=2482712
Idle question?
Reading about this caused me to wonder: could a government issue a warrant or subpoena for the users who have certain hashes in their accounts? Can you send a DMCA takedown request based on “knowing” the hash or series of hashes for a given allegedly copyrighted file?
As a dropbox user, the thing they’ve gotten right is the dead simplicity of sync-ing data. They seem to be blowing any positive buzz from that on their privacy practices and this dropship thing.
Re: Idle question?
In theory, two different files could have the same hash.
In practice, the possibility is too small to be worth considering. (The difference between engineering and mathematics.)
Depending on the hash size, say 2 ^ 256, that is more atoms than are in the observable universe. Not likely that two files have the same hash.
Re: Re: Idle question?
There is a possibility of corruption of your file if there is a hash collision with another file under deduplication. Some people think the remoteness of this means you needn’t worry about it at all. I’m not sure, but it’s probably better to have a backup other than a deduplicated database. Since this requires strong collision resistance, the odds are:
(2 ^ 256/2) / (number of files in cloud)
If there are a billion files, the odds of collision are:
1 / (2 ^ 99)
It is not 1 / (2 ^ 256) but is still a very small probability. It’s more likely your co-worker will go postal and then file corruption won’t matter.
Re: Idle question?
When a computer is seized, hash value databases are used to determine if it contains any known illegal files (e.g child porn) or to eliminate known system files so a forensic examiner doesn’t have to look at them. If law enforcement could determine if a cloud server contained a hash value match of an illegal file, that could definitely be justification for a subpoena. Current hash value databases are for MD5 and SHA-1. SHA-2 values could easily be added. I don’t know about DMCA. On Dropbox, the files aren’t being shared (unless with Dropship), so a user could claim fair use in storing them there. I don’t know what can happen if you have removed DRM from a file.
I think there's a name for that, and it's:
Duck Sauce.
Am I doing this right?
The DMCA was a misfire from an automated system? Wouldn’t it be nice if they had an actual human checking these things before they send them, or would that be too much trouble?
I uninstalled Dropbox after trying it because 2gb of free storage seemed laughably small. But I’ll take a look at this dropship thing and see if it’s any good.
What you get
That’s what happens when you let the client validate the data. Don’t they know, the Business Layer should also validate. The only way to do this would be to upload the entire file and have the server hash instead of the client.
Heck, use ZFS and let the FS deduplicate. I bet they’re more concerned about saving bandwidth than storage.
DropBox could be sued over this
Hey that idea of using hashes to avoid storing multiple copies of large files is a great idea.
Someone should patent it. (Obvious? Already patented? Completely irrelevant I say! Just ask any USPTO examiner.)
Then they should sue DropBox for infringing that patent.
Re: DropBox could be sued over this
It’s already in wide use…
Re: Re: DropBox could be sued over this
If it’s already in wide use, then that is clear evidence that it is valuable and should be patented by someone in the name of innovation. (sarcasm)
The main problem here is that this shouldn’t even be possible if Dropbox had actually provided a secure system it would not be.
It should be that the key used to encrypt files exists only on clients, and so the server does not have it, and so the server would be very unlikely to be able to do any de-duplication.
Re: Re:
This is not about encryption. The hash is about de-duplication.
There is nothing insecure about it. They simply avoid uploading and storing the same file again.
As another commenter posted, he uploaded a 600 MB file and it uploaded in under 1 second. He then realized that they hashed the file and someone else, had uploaded it.
Nothing insecure. It’s the exact same file. You don’t know who else has uploaded that same file. You only know, because of the unrealistically fast upload, that someone somewhere had already uploaded that file.
Re: Re: Re:
Encryption is very much involved. The files stored in the cloud are encrypted, to deduplicate, a single encryption key must be used regardless of how many users may claim that file. This means, if the deduplication is across multiple accounts, that the cloud provider, Dropbox, has to know that key. Allowing a 3rd party to have the key to your encrypted files is a security risk because an entity can gain legal access through a warrant, national security letter, or in some cases just a subpoena. This is less protection than you would have for files stored at home or business. Having less protection may be OK, but the user should know this.
The Dropbox system is even less secure because it allows someone to infer that their server contains a particular file of known contents. With this knowledge, an entity can gain legal access to find out the owner(s) through a subpoena or national security letter. A warrant isn’t necessary. Again, this is a lot less protection than you would have for such files at home. Please note, that if possession of a particular known file is considered suspicious, the legal process is greased to find out who you are. If that doesn’t bother you fine, but users should be made aware of this. As Eric Schmidt said:
“If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place.”
Re: Re: Re: Re:
Which pretty much has to be among the favorites in the running for “Stupidest and least true saying of all time”
Re: Re: Re:2 Re:
I’m in total agreement. What was scary is that he said it while being CEO of that ad broker company with the motto “don’t be evil”.
The moral of the story?
And that’s an obvious consequence of allowing a pseudo-legal process that bypasses courts and put it in the hands of the people with most to gain from it.
Expediency of “enforcement” = “we’ve got more money than you and we say so” i.e. protection racket as legal process.
dropbox can stop this easily by disabling “magic uploads” and hashing on the server. i dont think many legit dropbox users will mind this, and while it costs dropbox some bandwidth, it will prevent their system from turning into a warez farm with millions of free 2GB accounts just hosting a few parts of warez files.
Best alternative: SugarSync
Good review ? here is the best alternative as of June 2011: SugarSync.
You get 5GB of cloud storage space with the FREE version, but now there is no restriction to the number of computers you can sync/backup (up from 2).
It gives you the ability to upload and sync any folder on your computer.
It is the only service that offers such a broad device and OS support with apps for BlackBerry, Android, iPhone/iPad, Symbian, not to mention your computer!
You can also stream MP3 music files to your smartphone or computer.
Also if you use the below referral code you get a bonus 500MB extra on top of your Free 5GB!
https://www.sugarsync.com/referral?rf=tbtp0asbw9pt
Hope this helps someone!
buy dropship
Hi w0qj, thanks to your informative post. You really do have a concern to share it.