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.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.
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.”
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...
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: copyright, dmca, dropbox, dropship
Companies: dropbox
Reader Comments
Subscribe: RSS
View by: Time | Thread
Watch me
This is my totally blaming Dropbox face. They issued a false DMCA takedown. To themselves.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
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".
"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!
[ link to this | view in chronology ]
Re: Re:
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).
[ link to this | view in chronology ]
Re: Re:
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?
[ link to this | view in chronology ]
Re: Re: Re:
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..."
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
(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?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
Jeebus man, what does it take to get you to spell out what the frak you're on about?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
Rainbow tables are not involved. The equivalent is already provided by a large set of deduplicated files and their hashes on Dropbox.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
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).
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
Dropbox's real level of security is:
2^128 / (total number of deduplicated files within Dropbox)
[ link to this | view in chronology ]
Re: Re: Re: Re:
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
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).
[ link to this | view in chronology ]
Re: Re:
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.
[ link to this | view in chronology ]
Re: Re: Re:
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.)
[ link to this | view in chronology ]
Re: Re: Re: Re:
This isn't meant as sarcasm, just asking the question.
[ link to this | view in chronology ]
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?
[ link to this | view in chronology ]
Re:
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. :P
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re:
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.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re:
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.
[ link to this | view in chronology ]
Dubious value of de-duping.
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.
[ link to this | view in chronology ]
Cool!
[ link to this | view in chronology ]
oh, so they think they can take it down?
Check out https://github.com/nddrylliog/dropship if you're curious.
[ link to this | view in chronology ]
Re: oh, so they think they can take it down?
[ link to this | view in chronology ]
encryption
[ link to this | view in chronology ]
more info
http://news.ycombinator.com/item?id=2482712
[ link to this | view in chronology ]
Idle question…
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.
[ link to this | view in chronology ]
Re: Idle question…
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.
[ link to this | view in chronology ]
Re: Re: Idle question…
(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.
[ link to this | view in chronology ]
Re: Idle question…
[ link to this | view in chronology ]
I think there's a name for that, and it's:
Am I doing this right?
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
What you get
Heck, use ZFS and let the FS deduplicate. I bet they're more concerned about saving bandwidth than storage.
[ link to this | view in chronology ]
DropBox could be sued over this
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.
[ link to this | view in chronology ]
Re: DropBox could be sued over this
[ link to this | view in chronology ]
Re: Re: DropBox could be sued over this
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re:
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.
[ link to this | view in chronology ]
Re: Re:
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."
[ link to this | view in chronology ]
Re: Re: Re:
Which pretty much has to be among the favorites in the running for "Stupidest and least true saying of all time"
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Best alternative: 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!
[ link to this | view in chronology ]
buy dropship
[ link to this | view in chronology ]