Dropbox Attempts To Kill Open Source Project
razorfast.com
razorfast.com
so, when something like this gets called to our attention, we have to do something about it. note that this isn't even by choice -- if we don't take action, then we look like we are tacitly encouraging it. the point is not to censor or "kill" it (which is obviously impossible and would be idiotic for us to try to do), but we sent kindly worded emails to the author and other people who posted it to take it down for the good of the community so that we don't encourage an army of pirates to flock to dropbox, and they voluntarily did so.
there were no legal threats or any other shenanigans to the author or people hosting -- we just want to spend all our time building a great product and not on cat-and-mouse games with people who try to turn dropbox into an illegal file sharing service against our wishes. (for what it's worth, dropship doesn't even work anymore -- we've fixed the deduplication behavior serverside to prevent "injection" of files you don't actually have, for a variety of reasons.)
that said, when we disabled public sharing of that file by hash, it auto-generated an email saying we had received a DMCA takedown notice to the OP, which was incorrect and not what we intended to do, so i apologize to dan that this happened.
(*edited the last paragraph: we didn't send a takedown notice, we sent a note saying that we received a DMCA takedown notice, which was also in error)
Great, and that's all you should've done in this case.
I doubt that is what the lawyers said.
Which is great, except you are punishing the crime, before it even occurred. Remember use of torrents are not illegal per se, sharing files which you do not copyright of, and piracy is.
> there were no legal threats or any other shenanigans to the author or people hosting. (EDIT - No applicable. Read Drew's edit.)
DMCA takedown notice is a legal threat. Worse part is, its not even valid, IANAL, but do you own the copyright of the data or the copyright owner approached you to issue a DMCA takedown notice?
> it auto-generated a DMCA takedown notice to the OP, which as many pointed out here was invalid and particularly inappropriate in this case, and was absolutely not what we intended to do.
Please do not send legal notices, without lawyers reviewing them?
This is pretty disingenuous. You really think their assumption that Dropship would quickly turn Dropbox into an illegal file sharing haven is an unrealistic grasping of straws?
Can dropship be used for illegal file sharing? Yes.
Is dropship being used for illegal file sharing? No, until proven otherwise.
Legal penalties are applied for the cases depending upon what happens/happened, not what could happen.
That being said, my understanding of law is deeply based on my country's law. The case might be different in the country dropbox is incorporated.
EDIT - I got a lot of downvotes for this reply. Can someone (who intend to downvote this comment), please explain where I am missing the point and/or being wrong?
Dropbox is a private service, and any notices stating that users cannot sync certain files when they use their product under penalty of removal of their account can be enforced, just like any brick and mortar store can enforce a "no shoes, no shirt, no service" policy and refuse to give service to anyone they please, even for trivial matters like whether or not the patron/user is wearing clean socks.
Punishing for the suspicion of crime, rather than actual crime, just because you are can get away with it, is evilish and not nice. I expect better from Dropbox, we all know and love.
Can dropshiip be used for illegal fire sharing? YES, in fact, that was the suggested and intended use. Under American case law, which governs Dropbox, that alone is enough to constitute a DMCA violation (see, e.g. Napster, Kazaa, and succeeding cases).
Dropbox took dropship down to prevent future legal issues. Since it's their service, they don't have to wait until they occur actual legal liability to act.
That being said, I realize Dropbox(or Corporate entities in general) is not government and/or legal system and it is not required of them to follow laws, which are applicable for governments.
However, Laws are legal representation of morals/ethics, which are applicable for every entity in the society, for its effective operation.
While the law is codified as Presumption of Innocence, its underlying sentiment, from moral point-of-view, Judge/punish based on definitive actions not speculations, are applicable for all entities of the society.
Not only are you not a lawyer, but you are also struggling with some basic concepts regarding the implementation of laws.
Laws, implemented as statutes, have no association with, or bearing on, morals which are purely a cultural phenomena.
I understand that you disagree with how Dropbox went about protecting themselves from civil liability, however the violated no laws by their actions.
I absolutely do not disagree with how Dropbox went about protecting themselves. What I disagree with is, trying to claim a tool or technology can be anti-law, rather than its usage.
All pieces of technology, from Atom energy to Internet, can be used for both wonderfully good or evil. What I am trying to say is, Laws are (should be) applied how a technology is used, not what technology is used.
That being said, I am not trying to defend or endorse dropship's reverse-engineering of Dropbox's proprietary code, and hence infringing the ToS. It certainly looks illegal.
> however the violated no laws by their actions.
Never disagreed.
Additionally, you're conflating society, which is comprised of a group of people, with culture, which is a product of a group of people that aren't necessarily members of the same society.
Christian culture defines a moral code by which they measure themselves. That culture is present in many societies and can influence (or not) the societal debate on governance (witness the current California constitutional ban on Gay Marriage as an example).
That leads to people who are culturally opposed to laws enacted by the society in which they happen to live.
Laws are enacted by the constituents of a nation-state as a means of defining roles, rights, and remedies. The process by which they are proposed, debated, and enacted is internally consistent but varies between governing bodies.
If you re-phrase whatever point you were trying to make by consistently using words with meanings we can agree on, then maybe we'll have something to disagree about.
For example, the government has no right to privacy whilst we as individuals do.
Courts have upheld these terms of service/use agreements in many cases; just googling ProCD v. Zeidenberg will give you more information, if you're interested.
But keep in mind the US part of the internet is by and large a collection of privately held entities. By your logic, it's completely reasonable for Sen. Lieberman's to place calls to Amazon to suggest websites and services they might want to review for ToS violations and take them down.
It cuts both ways dude. One day Dropbox, your ISP, whoever could decide that they don't like something you wrote (in code or in opinion) and "happyfeet" is then in violation of their ToS.
In fact, Dropbox is probably reading your comments in this thread right now. They might just decide your files are in need of review.
DropBox is a private company, whose behavior should be viewed based on what their ToS are, and how they stick to them.
They don't have to prove anything - if one is engaging in behavior, or taking action that jeopardizes Drop Box as a service, or as a company, something they have worked really, really hard for, their rational response is to shut down the person engaging in that behavior.
What DropBox is saying is that regardless of whether you think they should become the next RapidShare, or BitTorrent - that's not a business they are interested in - regardless of whether you think you might have some excuse as to why your behavior hasn't proven to be illegal file sharing.
These are not legal penalties. This is not about the Law. Drop Box is not the government. They do have the right to refuse service, and, in fact, to shut down uses of their service that they are not comfortable with.
I think another reason why you are getting down voted is that a lot of the people on YC have worked really, really, really hard to build these types of services, and get frustrated when people fundamentally don't get it.
Not supporting something that a small number of users want if it would make the service worse for other users is the sort of decision every web service makes every day. Why isn't this just another case of that?
I think Drew was mistaken when he called it a "takedown notice". That term has a specific meaning, and judging from the linked article, what DropBox actually sent to the OP was not a takedown notice. Instead, it was just a message saying that DropBox had received such a notice from a third party and consequently disabled access to the allegedly infringing file.
No, they aren't. They're enforcing the terms of use that Dropbox users agreed to when signing up.
I don't think asking folks to take stuff down was the correct solution...I think fixing the bug was the right solution, which they've also done. But, I don't see how Dropbox is "punishing" anyone, when they're just asking people to use the service as it is intended.
I am actually curious to know what ToS were violated (based on which Dropbox decided to take the action), except that I have not read about the real reason on either the Original Article or the discussion on HN.
Can Drew/Arash clarify what Terms were being violated actually by dropship?
http://www.dropbox.com/dmca#terms
Access, tamper with, or use non-public areas of the Site (including but not limited to user folders not designated as 'public' or that you have not been given permission to access), Dropbox's computer systems, or the technical delivery systems of Dropbox's providers;
Attempt to access or search the Site, Content, Files or Services with any engine, software, tool, agent, device or mechanism other than the software and/or search agents provided by Dropbox or other generally available third-party web browsers (such as Microsoft Internet Explorer or Mozilla Firefox), including but not limited to browser automation tools;
1. Dropship violated Dropbox ToS, by reverse-engineering Dropbox proprietary code.
Thats all.
Nothing to do with DMCA notice, which was sent by accident.
"This is Arash from Dropbox. We removed the project source code from the user’s Dropbox because it enables communications with our servers in a manner that is a violation of our Terms of Service. By our TOS, we reserve the right to terminate the account of users in this case. However, we chose to remove access to the file instead of terminating the account of the user."
I'm questioning whether possessing the file without using it against Dropbox is actually a TOS violation.
They definitely should have just fixed the bug. Deleting peoples files feels kinda nasty.
Run your own organisation-wide Dropbox? Yes please.
Edit: ¹ I mean of course created Dropship by reverese engineering Dropbox's protocols.
That's a pretty big stretch. You believe the client-side code to trigger download of a file that doesn't exist on the system is "not far off from having an FOSS Dropbox-a-like"? That's like finding a hub cap in the woods, and deciding you've almost got all the parts needed to construct a car.
I don't believe Dropbox is using any techniques that are secret; I believe anyone with the know-how, and time, and inclination, could use publicly available algorithms to replicate everything Dropbox has done. The "secret sauce" is not the protocol. There are a number of protocols for doing versioned filed storage (WebDAV, for instance) and a number of protocols for transferring only the parts of files which have changed (rsync, for instance). The hard part is in putting them all together, not in any magic to be found in a few lines of code.
I highly doubt this is all a conspiracy to prevent people from building a FOSS "Dropbox-a-like". People can already do that, without needing any Dropbox magic. Oddly enough, no one has. I reckon it's because it's really hard to put all those pieces together in a way that works easily for end users. Highly technical users have had these kinds of capabilities for years in the form of version control systems, rsync, etc. Open Source developers have solved the hard algorithmic problems already (and Dropbox is standing on their shoulders). What Dropbox did is make it accessible and usable by anyone.
Do people really need any explanation other than, "Somebody made a mistake and sent out the wrong email"? They don't strike me as being particularly evil guys when I've met some of them, and while they aren't bastions of Open Source generosity as far as I know, they also never seemed to be anti-Open Source, to me.
Sadly, the server only runs on Linux, but to me this contradicts the assertion that an OSS Dropbox-like software has never been developed.
Verily.
>People can already do that, without needing any Dropbox magic. Oddly enough, no one has. I reckon it's because it's really hard to put all those pieces together in a way that works easily for end users.
These two sentences are contradictory. The magic clearly doesn't lie in the protocol per se or the specific idea but in the implementation. Having a client that emulates Dropbox _seems_ to be the hard bit strange as that may sound.
I have used the web interface, but the client is generally the only point of contact I have if I have a new client that does exactly the same and that client can be switched to a new server my experience will be >99% unchanged and, in my scenario, the effectiveness will be the same.
If I can switch service without noticing any change in interaction (dropbox just sits there after all) and in fact can use the same client with either dropbox itself or a different server then it seems like a bad thing for dropbox.
YAY!
this is how Dropbox should pursue an enterprise offering, selling a Dropbox Server as a VM, a set of client licenses and instructions on how to run an internal dropbox server.
With encryption. With additional security features...
to be clear, we _never issued_ any DMCA takedowns to anyone -- the OP incorrectly received a bizarrely-worded email from us saying we had received a takedown notice from ourselves (no such notice ever existed) for which we've apologized.
Thanks. Already updated in the comment.
That's just disingenuous legalistic manoeuvring though isn't it. You claimed that you had issued a notice, to yourselves, and it was outside of the email recipients ability (without issuing an injunction - or whatever the process is in your jurisdiction) to confirm your claim. They took your word on it.
So fraud or a DMCA.
But no you say it was just "a mistake".
Forgive my cynicism but this is standard fare for the legal departments of big business, using the law to bully people who financially can't afford to protect themselves against false claims.
1. Dropbox staff hand-crafted oddly-worded DMCA takedown notices and purposefully sent those to specific individuals after having already sent them polite requests to remove certain content;
2. Dropbox staff hand-crafted oddly-worded DMCA takedown notices at some point in the past as part of an automated system, which fired incorrectly when staff removed content.
To me, #2 makes a lot more sense, and is the simpler (and in this analysis, the more likely) case.
They have a system they use for IP enforcement that bans based on file hash. They used this system to ban the files.
A side effect of this system is that it sends a DMCA notice to anyone who has a copy of that file hash (because that has always been what it was used for before). I'm guessing inside the hash-ban tool there is a field "owner" or something, which they filled in as "Dropbox" and is used as the source of the DMCA notice.
I don't think there is any conspiracy here. Never ascribe to malice what can be ascribed to incompetence. I's pretty harsh to call Dropbox incompetence, but given how it would make sense for their system to work, I think a mistake is a fair description.
No notice was sent to anyone. What the e-mail that was sent claimed was that Dropbox had received a DMCA takedown notice from a third-party and that's why the file was taken down. However, that was just an automated response to any file being taken down using whatever mechanism they had in place.
I'm not sure where the "law" is being used to bully people who can't afford it in this case.
My point was that whilst they were not issuing a notice they were claiming a notice had been issued and as Dropbox were the claimed issuer and receiver of said [non-existent] notice that without legal action the recipient of the claim could not confirm. For all intents and purposes the recipient of the claim is in the same position as if a notice has been issued.
I thought I'd made it clear enough. I did not once, knowingly, claim that an actual DMCA notice had been issued - hence the contentious suggestion of fraud (in claiming they had received a DMCA when they hadn't and using that claim as rationale to remove [the link to] the files from their clients account).
>I'm not sure where the "law" is being used to bully people who can't afford it in this case.
It goes something like this:
'Oh, I'm sorry Mr Nongrata I've got to take down your perfectly legal website because we got issued with a DMCA; why yes of course you can challenge that [big fat lie], mount a court case against the issuer. What's that you don't have $100k to spend getting it to court, oh too bad. Muahahahaha'.
In any case, it doesn't matter if the Dropbox team are nice guys it matters if the people behind Sequoia Capital et al. are the sort to use a legal threat to protect their millions of pounds of investment.
You developed a file sharing system that allows anyone to obtain the full contents of a file by simply knowing its hash?
Then when developers make tools to allow using this for simple cross-account file transfer you send DMCA takedown notices, claiming you are the rightful copyright holder of their code, to places like GitHub?
You seem to equate other file transfer services with "illegal file sharing".
Did you ever consider the possibility that someone could steal the contents of another person's file by knowing the hash of it? Sometimes hashes are public info and the file contents are not.
Or am I not understanding what just happened here?
The only erroneous use of DMCA was when we attempted to take down the link on Dropbox, which was an entirely honest mistake.
What you tried to do there is censor and resorted to fake legal repercussions. You can brush it aside saying that it was a mistake but it is still uncool for a corporation to do that to an individual.
I forked Dropship, just in case, and my GitHub repo of it was deleted. I was not notified of this. NOT happy with DropBox, and ESPECIALLY not happy with GitHub.
Is perhaps not accurate then.
However, pissing off the constituency that originally promoted your service isn't exactly #1 in your marketing plan. I'm not well known, but many who reside here are. Scaring off hackers just seems wrong, being Hacker News and all.
Already done.
EDIT: I get the following error:
[xxx@xxx laanwj-dropship-464e1c4]$ ./dropship examples/sintel_trailer-1080p.mp4.json ('Oops, blocks are not known: %s', ['lykR7INbdxXNk04IpJUxTvO97GeETwAbobol2283eqY', 'ciZ4YYqkiA9VssSpfmcagRJaYMtD3wNqZ4NTeV9BvOc', '7qe_U9KLL8t1RRH3K01PdTxnEGCnm1nP8S30ZkXK0KI', 'cPJPJ_uch8hJFhKaEeXufETDZ-q6Fqz1cibxoYwL8G8'])
Sorry, I may sound harsh, it's not my intention, but I have to ask: how often does it happen that you disable public sharing of files you don't like?
In terms of the software, it is unlikely that the general user will use it without some technical skill.
Share the GPG private key, the public key, the archive, and the password to use the key. It's too computationally expensive to automate opening these. And you could always spread the keys and keyphrase to where ever you want it.
But dropbox works well for what it is. I see no reason to trash it with pirated stuff.
I have no want or need to trash it with pirated material either.
I don't actually use Dropbox for anything, though, so perhaps my thoughts don't matter.
The de-duplication feature greatly helps pirates to gain access to files that don't belong to them, or even other people's privacy. If illegal file sharing service is something against your wishes, what you can do is to concentrate your effort to fight against copyright infringement (if you'd like to), instead of killing an innocent open source project that simply helps cross-account file sharing.
I used to love Dropbox's de-duplication feature, and I think that helps a lot of people with low bandwidth connections. Since I started noticing the existence of such feature, I'm already aware of:
1. My files are no longer mine. Anyone who knows the hash can access my files immediately.
2. Dropbox's claims about encryption are totally pointless in this case. Encryption is not going to help.
3. Requests from government agencies are going to be fulfilled very promptly.
4. Even hackers can access my files with the knowledge of only the hash, why can't employees of Dropbox?
I don't understand the "strict access policy" on employees inside Dropbox. Are there any difference between Dropbox's de-duplication and eDonkey's hash-to-file P2P?
To me, Dropbox is doing something here that against their wishes.
De-duplication requires commonality between files, which could not be found in encrypted data if users had unique keys.
Thus, if they have the ability to de-dupe _after_ you've uploaded a copy, they have the ability to decrypt your entire archive.
I'm not saying that's how they do it, but it would seem the logic is that your data never was particularly well encrypted.
I think this was a good call, and not just for the piracy issues but for the substantial information disclosure and possible misappropriation of sensitive documents that it could have facilitated. This is something that's been on my radar for some months, and frankly seemed like a significant reason to not trust dropbox with anything that wasn't effectively public.
So I'd consider the event a net positive for your firm and customers. I might consider trying to get out in front of any negative publicity that's going on here by publicly thanking the programmers and researchers that have brought these risks to light in the past month paying a few bug bounties to them. A few bounties similar in size to the ones the mozilla and chromium projects pay out certainly wouldn't break the bank, and might do something for public opinion. Not to mention the benefits of an ongoing program - people might be more inclined to contact you first instead of immediately going public with future issues.
They match duplicate files with an SHA256 sum and size in bytes. With those two factors, the probability of a collision is incredibly tiny and impossible to exploit usefully. If you tried a trillion combinations you might find a useless file, but by then you would be detected and banned from Dropbox.
Hashes are also disclosed in other ways. In certain cases security researchers will reveal a hash of a file publicly to provide proof of a file that might contain a proof of concept exploit against a privately disclosed bug - with the idea that the contents of the file could be revealed at a later date. If someone the researcher shared that file with privately placed it on dropbox, that file could be revealed publicly.
Online AV systems could be another form of disclosure. Many "online scan" products report the hashes of local files back to the server for malware detection - it is faster to upload your hashes than download the hashes of the many millions of signatures a product can scan for.
Another version of this is virustotal.com or similar services that will scan a submitted file against a large number of AV products. The resultant scans include the sha256 hash and are often publicly accessible, while the contents of the file isn't. In the days after several recent Adobe flash 0-days, virustotal reports on infected documents were reported publicly days before the bug was fixed or the actual exploit was publicly revealed. Here is one such example for CVE-2011-0611 submitted on 4/9/2011, made public on 4/11/2011 but no patch was available until 4/15/2011: http://www.virustotal.com/file-scan/report.html?id=1e677420d...
Granted, all of these presume that sensitive files are being placed on dropbox when they probably shouldn't be. But these things do happen.
As far as information disclosure, someone who has a legitimate copy of a file could then use the hash to determine if the file is being leaked off site or distributed inappropriately. This may be seen as a feature to some document owners, but it could serve to detect exfiltration that one might otherwise agree with. Whistle blowers come to mind. If you suspected a leak, one might provide slightly different copies of a sensitive document to a group of employees and see if any of the hashes appeared on dropbox after admonishing them to not allow the file to leave the enterprise.
I understand that many of these concerns could be dismissed with well, they already have bad document handling procedures, etc. Which would be valid, however in the real world a lot of poor behavior goes on. I'm just listing these as examples of the kind of problems that could arise, I'm not trying to take a stand on how likely any of the attacks might be.
They need to patch that hole, I think by requiring everything to upload, then deduplicate on the server...
Which is another way of saying what speleding points out.
Your 'automated' system should probably be either:
a) manual
b) have a big ass 'THIS F-ING SENDS A DMCA NOTICE' warning before you disable a file.
But here in the real world Dropbox doesn't really give a shit whether they actually got a real DMCA notice from Sony regarding the presence of "Spiderman.3.DVDRip.avi" in a particular 13-year-old's public folder — since none of those accounts are paid, they're just saving themselves money, and noone would discover it normally or have a reason to be pissed off at them. They can't even get in trouble for perjury since they were never sending DMCA notices to users, but rather telling users that Dropbox had received a notice.
Since you fixed the problem server side, why did Dropbox feel it necessary to then attempt to stamp out the no longer functional tool? Would you remove the ability for people to download DeCSS from my public folder due to potential harm? Would you remove the ability for people to download penetration testing tools from my public folder due to potential harm? Would you remove the ability for people to download disassemblers from my public folder due to the potential harm?
The code could be an interesting technical exercise and the censorship you are being accused of arises from this pointless action. That is what people are questioning. Where does that rabbit hole end?
Or maybe it was a default option, one of several, and it wasn't changed to something more appropriate.
It tries to make it sound like you tried to enforce patents on a Dropbox clone or something, while the truth is that the software was a parasitic service incapable of existing without Dropbox itself.
To me that last part makes irrelevant that the software was OSS or not.
In reality if Dropship is illegally accessing a person's private files without "sharing" or making it public, fix that. The approach is quite novel in that you can create a one-off dropbox account, make it private, and claim someone "hacked" into your account to acquire it as it would appear Dropship's methods cannot be proven different than a hacking attempt, which means the uploader is not "responsible".
However to counter people's points, dropbox has no choice but to demand that any copyright violation even in private files is forbidden, otherwise they are hit with DMCA, the US laws give them zero wiggle room here.
Dropship is a nifty loophole in the DMCA rules allowing dropbox to become the legal rapidshare in the US, probably involuntarily and taking on legal risk they don't want in any way.
>>"when something pops up that encourages people to turn dropbox into the next rapidshare or equivalent, you can imagine how that could ruin the service for everyone"
You don't want to be the next Rapidshare. I encourage you to overthink this.
They're your competitor.
Sure, if with Rapidshare you mean "illegal file sharing service", which I assume you do, because you use it in one sentence with Torrents, you might be right. Although Rapidshare hasn't hit the deadpool yet and is still around and strong and in compliance with current law etc. But if you mean the highly profitable business of sharing (legal) files, you should think again. They offer the same thing you offer in a way. Cloud storage + backups on a very similar freemium business model. Only for larger files. For some use cases your product might be exorbitantly better (automatically syncing files on a harddrive and not just having it in a filesystem in the cloud like RS), in some ways Rapidshare's product is a lot better though(e.g. sharing larger files with multiple people). But the nature of Rapidshare's product of course comes with a few strings attached. Since the incarnation of filehosting there have been people who try to exploit it for illegal purposes. Rapidshare obviously doesn't have the cleanest image, yet, they comply with the DMCA and offer an incredibly valuable product.
And, most importantly: Rapidshare (as well as the majority of one-click-hosters) learned about the Streisand-Effect (see http://en.wikipedia.org/wiki/Streisand_effect) early and did not as aggressively about things like this the way you did. Of course our and your situation is different, yet there are a few similarities you could have learned from.
This time you have successfully dodged the bullet and made a good strategic move, but I sincerly hope you have also learned sth. from this for the next time, because with user base that is still growing like crazy the next time WILL come. And next time it might hit mainstream media even bigger and not only be on HN and Techmeme.
BTW: I can of course understand that you try to fight piracy as good as you can in order to protect the brand as well as the company from expensive lawsuits and their even more hurtful consequences. It's just the way in which you handled things. You should have known better. The Streisand effect has happened to so much companies already. But congrats on handling the situation so well after seeing all the negative feedback. It shows true entrepreneurial skills as well as hard work that some arrogant entrepreneurs don't put in anymore once they have moderate success (in startup terms).
The CTO of a service as technically interesting as Dropbox certainly knows that he can't prevent the disclosure of their proprietary protocols. So impassioned arguments about "security through obscurity" and "the futility of trying to hide protocols" aren't adding much to the discussion. Everybody understands those things. To the extent that Dropbox's protocols factor into this story, they are obviously a fig leaf.
Thus far, the only thing Dropbox is purported to have done here is to politely ask a developer to remove an application; then, presumably believing that the mirror posts were simple nerd-rage, and that the author of the application agreed with Dropbox, Dropbox's CTO filed takedowns at Github. This is not the end of the world. As has been amply demonstrated, Dropbox can't effectively suppress MIT-licensed code, and probably won't try to.
Instead, consider that maybe all Dropbox is trying to do here is establish a track record of "not wanting Dropbox to become Rapidshare". This story then is not a "PR nightmare" for them; it's the expected outcome of their actions. They are trying to communicate both through words and actions that they are going to do what they can to not be Rapidshare.
That Dropbox cannot technically keep determined nerds from trying to coerce them into Rapidshare's use case is also not worth arguing about. I think we all know that's true. But how many of us are going to go out of our way to stick a thumb in Dropbox's eye?
Using this powerful law as a scare tactic isn't acceptable. If you wish to claim that the code was infact infringing, then the conversation is different.
This seems to be:
* illegal use of dmca by dropbox * dropbox says dropship using reverse engineered sync protocol broke anti-circumvention techniques or contains their copyright
Either of which are bold statments
People make mistakes. In the grand scheme of mistakes, this is an extremely trivial one.
The law is not a toy, and it's not supposed to be wielded casually. The DCMA is certainly not treated with the respect it is supposed to afford citizens, and this is just another example of that.
It was a mistake for them to use a DMCA request here, because the code was MIT-licensed and thus even the author can no longer ask for it to be taken down. But nobody paid legal fees here, nobody was sued, and the code is back online, so, no, I am not amenable to the idea that Dropbox is being abusive.
Continuing to file DMCA requests would be abusive.
However, requests should be filed in good faith, under the understanding that you have standing to file the requests. Clearly Dropbox does not, nor does the original author, having MIT licensed the code himself.
That pretty succinctly summarizes why this is problematic. Everyone here knows that they can't do this. The fact that they prepared letters and fired off the requests anyway demonstrates that they were acting in bad faith.
You don't accidentally reach for the DCMA and accidentally shoot off requests to github.
(and it's on that count alone that i criticize Dropbox, i think otherwise that i totally understand why they think this is a huge problem, and exposes them to legal liability.)
Edit: just read (http://news.ycombinator.com/item?id=2482803 ) explaining that the DCMA takedown letter that was email was in fact accidentally sent via an automated system. :P
Abuse of the DMCA is already dramatically overblown, and the cavalier attitude of "oh well, deal with it" is a significant part of the problem.
All that indicates there was is the message received by OP, which claims dropbox as both issuer and recipient of a DMCA notice. That makes no sense -- unless, as claimed by dropbox, it is simply an automated message generated by error.
I think a lot of people in this thread are under the impression that dropbox issued a DMCA request to github, which wasn't even what the OP was claiming.
It's a simple notification email that does almost nothing in the framework of the DMCA and simply notifies the Dropbox user that their file has been removed. It looks like their file removal system is a bit rigid in that it always assumes that a DMCA notice was received by Dropbox, even when they didn't receive one.
So, there seems to be absolutely nothing wrong here -- literally just a simple mistake.
It's the "write a sentence long enough you hope they won't reach the end" rhetorical strategy!
Lawyer: "Your honor, the only thing my client is accused of is politely asking Mr. Jones to stop talking to his girlfriend ... and then punching Smith in the nose believing he had Jones' agreement"
I have to say "well-done" (did you study with Suruman at Orthanc by any chance?).
The web is presently full of entities making egregious claims to intellectual property rights over anything and everything they happen to have touched. You should know quite well that a fair amount of property rights come whether or not a person can effectively claim them and so dropbox's claim to "own" an algorithm can never be simply irrelevant or a "figleaf".
It may not make that much difference but I think it makes some difference to cast some sunlight onto these efforts. Boring or not.
That doesn't mean Dropbox handled this flawlessly. They appear not to have. It does, however, imply:
* The nerds angry about the request to take down the code are not in fact creating a PR nightmare for Dropbox, because they are helping to spread the word that Dropbox is hostile to this use case.
* That Dropbox is probably not going to switch into kamikaze legal mode to keep people from talking about their protocols or building tools, because it was the particular use case fostered by this tool that set them off.
You are free to disagree. I promise not to caricature you as a supervillain for having done so.
My concern is the system they are using for DMCA notices. If it is indeed an automated system, then they are doing things wrong. Yes, have a DMCA notice generated, but someone should physically vet that notice prior to it being sent out - and that should most likely not just be a member of the support staff.
I am also concerned that Arash was using a tool, meant for support staff, that he was not familiar with to perform a mass-removal as well as a mass-DMCA takedown notice when it is obvious any such tool would require him to enter the claiming company name - in this case Dropbox. He should have asked, or been told what is going on with such a tool.
Sure, this isn't a big deal in the larger scheme of things; but it isn't as trifling a deal as your comment's rhetorics make it out to be. Dropbox's actions are hurting its geek credibility, and rightfully so; I take your point about them possibly wishing to appear tough on rapidshare-ization of their service, but they don't have to do this employing tactics that are widely considered to be low. A proper amount of posturing and some real tech work behind the scenes to make this sort of access harder, if not impossible, would achieve more and not hurt their image.
I do have another, more substantive disagreement with your original comment, not about style. I don't think it's as clear as you present that the code in question was obviously not going to be suppressed by Dropbox, and they obviously understood that, etc. Yes, the author of the blogpost is possibly biased towards seeing himself as the hero; but I see nothing to contradict his claim that if it weren't for this one stubborn developer, the code would've disappeared from public access. The amount of goodwill towards Dropbox in the community (notably so in the case of the original author) and their swift attempt at censoring the code might have helped this succeeded.
I don't think anything like that has really happened. There was no DMCA takedown notice, only the (false) message that Dropbox had received a notification from itself, issued when they blocked public downloading of the file. Probably because that's the only way to block hashes they have right now. And as far as I can tell the github repo was removed by the original author, after they asked him.
Edit: Fixed bad quoting.
To be sure, it could be a misunderstanding, a technical glitch, or an attempt at trolling. The Dropbox folks aren't getting my benefit of the doubt on this, though. Their actions, even the ones that aren't disputed, have been unbecoming. Banning the code distribution on Dropbox was a particularly ham-fisted move. It does nothing to curb its spread, because Dropbox is not a web-forum with easy discovery. If I put this file on my public Dropbox folder, the only way others will know to look there is when I advertise this elsewhere, not on Dropbox; but if I'm motivated enough to do that, surely it's no trouble for me to just host it elsewhere.
So the ban only hurts their image more. What if I write a text file with the description of their client-server protocol and put that on Dropbox, are they going to ban that file, too? When you willingly put yourself on a slippery slope, be ready to find yourself sliding.
They have mine.
Now where do we stand?
Their initial solution to the problem was updating the TOS and calling it a day. DropShip proved there was a deeper problem that needed to be addressed and the fact that their solution did not start and end with a fix to the problem in the code is mind-blowing. This isn't a huge enterprise company. These guys should know better.
http://news.ycombinator.com/item?id=2440066
(note, the solution Dropbox should have implemented instead of fake-lawyering up was offered very quickly there...)
Wonder what the next headline is going to be.
You assume "everybody understands those things" which simply isn't true. Not everyone understands how Dropbox works. Not everyone understands security though obscurity (which I should have linked in my post for people to learn more, will fix).
As I said in the post I understand Dropbox is attempting to play damage control. The way they went about it was inappropriate. Removing the file from their service is one thing. It's their company, they can run it as they see fit. Requesting all files hosted elsewhere to be taken down and HN comments be deleted is going too far. That's an obvious attempt to kill the project, hence the title.
We recently built a tool that allows us to ban links across the sytem (as of a few weeks ago) and I wasn't aware that a DMCA takedown email would be auto-generated and sent. This was a tool built for our support team and I'd never personally used it. That said, we feel strongly that the code is a violation of our TOS and don't believe the removal of the content from our site is censorship.
I'd also like to clarify that nobody's accounts were threatened: in every case my phrasing was as follows: 'I hope you can understand our position and can agree to remove the Dropship code'.
The attempt to quash knowledge is the offensive part - not the enforcing of your TOS. At least that's my 2 cents.
I understand it a little less if you are say sharing folders between friends.
And I wouldn't like it at all if they deleted something from my dropbox, but it seems we aren't there yet.
Is that accurate?
I'm on your side here, but you need to be as transparent as possible here. Are you also saying that your system automatically generates emails that make false claims about having received a DMCA takedown notice?
1. The system for banning files would not send out copyright infringement notices automatically. It would be set up for banning things like source code that could be used to violate the TOS.
2. Someone on the support team you claim the system was designed for, would have done the ban, instead of you having to come in and implement "higher-level business logic" by using the ban system for something besides copyright violations.
He knows your product well enough to "break" it and he has the motivation to create something strong enough that it is causing a fuss. Learn from Geohot. Don't scare away people who want to play with and extend your product.
Doesn't this seem to imply that Dropbox is the owner of the code and is both the DCMA submitter as well as the company executing upon it?
An automated system would still require a company name that is requesting the DCMA to be entered, or your automated system is implying that all DCMA requests are coming from Dropbox. Something isn't right about this...
But it's amusing nonetheless. Are there other incidents of a company serving itself DMCA requests?
I find it hard to believe that you did not anticipate exactly this happening when designing (a) an online file backup service, (b) a "de"-duplication algorithm. That said, you should have planned for exactly this a long time ago, whether by the means DropShip used, or any of several other potential file sharing hacks. I think a lot of us here are disappointed with how your actions reflect that planning, or lack thereof.
A) move the files to the public folder
B) watch out for bandwidth limits on the public folder
C) give your Dropbox account ID to everyone as it is tied directly to the URL
With this method, you get anonymous file transfers without bandwidth limits
Yes, only if dropbox let you do that. They can make you stop with a fix in 5 minutes and they will do it very soon.
Why would Dropbox want to let you circumvent bandwidth limits on your public folder?
While you guys have (and always have had) a technically exploitable issue with de-dupe/hashing (which I think is a feature) now that you're the big kid on the block I hate to see you forced to close it.
It was a nice feature, but it isn't going to stand up to random hackers trying to make a name for themselves with a public release of relatively simple code and blog post about how they used/abused your service. Good luck!
And I definitely think it's time to change your demeanor from your local friendly startup to your impersonal corporate entity. At this point you're just going to be stirring up bees.
Even so, my main issue is not whether it violates the terms of service or not -- let's just say using it does violate those terms -- the question is whether taking it down is the right thing to do, for Dropbox and its users. In this case, I don't think it is: the issue here is not the code itself (which does not appear to be malicious) but how that code accomplishes its purpose. That method is not something you can block with requests to take down source code.
Basically: this may violate the terms of service, but maybe the real issue here is that if those terms are blocking this, maybe those terms are wrong.
Disagree. Of course it's censorship. It may be justifiable, and the content in question may be against Dropbox's ToS, but it's still censorship: Dropbox is removing access to content it does not like.
Man you guys are dumb.
(Man, this thread is full of disinfo.)
With all due respect to you and your company (and while I fully support your right to invoke your TOS to take down content within your own service) I'd actually love to see one of the people you DMCA'd slam you on that aspect of this situation legally if for no other reason than to make other companies think twice (or three times) before they improperly invoke the DMCA to scare people into submission.
(The dropbox guy already has said he used an internal tool developed to remove files, without realizing that it would send this DMCA notice notice.)
Arash, you're confusing the software and its potential uses as if they were the same thing, which is standard DMCA brain damage. It's the FUTURE communication with the servers that COULD violate the terms via such communications, IF it actually happens because of an unknown person (possibly not the hoster) using the software at some (unspecified) later time. If that TOS-violating communication actually HAPPENS then you can gleefully shutter HIS account. You don't get to ban the software itself, if the hoster has permission (via MIT license) to host the file. Illegal sharing of copyrighted files is what's prohibited, and that is what the "automatic DMCA takedown" suggests---to wit, that your banning-files-by-hash system is designed to take down copyrighted files in response to DMCA takedown notices. If it was meant to ban files you don't like, you would have had a clue that it would send an erroneous DMCA message about the file.
So it's obvious you just wanted to ban the file. Can you really cite the TOS language that says hosting software that COULD be used for TOS-violating communications with Dropbox, is also a violation of the TOS?
I also think it would be interesting for readers of this forum to see whether or not you've already quietly changed your TOS to cover this case (or will soon do so.)
No one received a DMCA takedown notice. Rather, people received an informational message saying that Dropbox received a DMCA takedown notice.
This informational message has absolutely no legal implications. Everyone screaming perjury should stop practicing law from their armchairs.
Thankfully all DMCA requests are filed under penalty of
perjury. If he claims that he owns the copyright to
material he doesn’t own, he has now opened himself up
to civil litigation.
IANAL but the dmca provides hosting sites protection against users who infringe. By actively checking for infringement of users having dropship could they be openning themselves to legal complications if they lose "hoster" status?
(sorry, none American and not a lawyer)
Copyright applies to original and derivative works, though multiple parties may own copyrights to a derivative work.
In America, derivative works include software programs which are inseparably reliant on code or features (including APIs) of another program. It's basically the same argument that WordPress and Drupal make in regard to themes, plugins, etc., falling under the same open source licenses (i.e., copyrights) as the platforms themselves.
In this case, dropship is entirely reliant on unique features of Dropbox. This makes it a derivative work, and would mean that Dropbox has copy rights over dropship. The programmer of dropship also has copyrights over dropship to the extent that the code is an original work, but Dropbox's rights trump his b/c they own the rights to the original underlying work.
I don't think that's true; if you've got any case authority, I'd certainly like to remedy my ignorance of it.
"Derivative work" is defined in the Copyright Act: [1]
"A 'derivative work' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a 'derivative work'." [Emphasis added]
I don't recall ever having seen any kind of ruling that sending API-compliant messages to another computer via the Internet, for processing by code already running on the other computer, somehow constitutes creating a derivative work of that code.
And I don't see how, in any normal case, the owner of the code on the other computer could claim that the API message sender had caused an infringing copy of the code to be made. If I were representing the API message sender, I'd likely argue that the owner of the code -- by (putatively) licensing the computer operator to configure the code to listen for and process API messages -- had consented to whatever copying might have occurred.
[1] http://www.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0...
I had actually missed the original post, but now thanks to their takedown attempts I've downloaded a copy for myself as its very interesting.
As does the fake DMCA takedown. If Arash Ferdowsi wants people to think he's dishonest, he's going the right way about it.
http://news.ycombinator.com/item?id=2482803
(admittedly, several hours after you posted)
"Hackers, today, are up in arms with Dropbox. The hackers claim that the illegal files being stored there were protected by the first amendment. Dropbox claims that their service could be attacked with those files and removed them."
Bad publicity.
Dan DeFilippi: "In my unhumble opinion censorship is never an option."
What he considers "censorship", another person would call "not pushing someone in front of a train". He knows full well that (a) Dropbox is a pretty friendly company with reasonable people solving a real problem and (b) the RIAA and MPAA are NOT friendly and NOT reasonable.
This linkbait title ("kill open source project") is the equivalent of police going after students for bike tickets while avoiding the dangerous parts of town. Dan DeFilippi is going after the good citizen (Dropbox) for the minor philosophical crime of not supporting everything that calls itself "open source", while completely lacking the balls to actually take on the real bad guys here, namely the RIAA and MPAA's real lawsuits.
Indeed, even if he did set up his own torrent server, they'd ignore him for a while. Dropbox has financial resources, so they'd actually be the target. So DeFilippi is getting behind them and trying to push them in a fight that is certainly NOT one they want to engage in, without taking any personal risk himself. Not particularly ethical, IMHO.
This was an unfortunate reaction by them that will damage their social capital (a little at least) among one of their core markets. I doubt it'll drive them into bankruptcy, but it's irritating for me to see this sort of behavior.
That's a really incendiary headline. Yes, they tried to kill an open source product, whose purpose was to facillitate illegal file sharing over DropBox.
The PR fallout from this among the tech community is probably nowhere near the fallout it would experience if it became the next Kazaa.
Where are you getting that information? My understanding it that its purpose was explicitly to facilitate legal file sharing over DropBox - Linux ISOs, for example.
The original post for DropShip gave, as an example, the trailer for a movie. Not the movie itself, but the trailer. That's the equivalent of saying "I've developed this great way to share files, such as videos, but am not going to explicitly say that it could be used for piracy even though everyone knows that that's the only thing it will be used for."
- a nicely sized file, consisting of multiple 4MB blocks but not overly huge
- already available on the network
- free to distribute (yes, that movie is free to distribute, so the trailer certainly is)
- apart from that, the blender foundation is simply awesome
I could also have used something like the tar archive of the source code or a photo, but this proved that it works for multiple blocks...
I guess the corollary here is, "If you don't own the server, you don't own the file."
Maybe this is why Richard Stallman calls cloud computing "careless computing."
Eric also had another post Three Systemic Problems with Open-Source Hosting Sites a few months later (October 2009) - http://esr.ibiblio.org/?p=1282
Drew would have to kill a baby panda with an elephant tusk for me to even begin thinking about switching.
This said: I stand with dropbox on this issue. Abusing their service to fake a p2p is definitely not the way to go and not that clever hack if you ask me.
What I'm more interested in is what HN users like and dislike and recommend, as opposed to a bunch of features charted into a table with nothing valuable in terms of reliability, usability and actual security.
Lately, I've been leaning towards Jungle Disk for file syncing & some S3 solution for cloud backups.
This is a tempest in a teapot just like those mass "Quit Facebook" protests that spring up every time the privacy settings change. The entire controversy exists because a tiny, yet incredibly vocal, minority makes a huge deal of it only to drop it the next week. And from reading write ups on freemium services, the vocal minority is also part of the non-paying majority.
Dropbox has a technically exploitable feature which they don't want passed around for file sharing purposes so they stopped their own servers from helping. Big whoop.
I no longer like what they're doing, so the gravy train stops.
So let's examine what you're (potentially) doing by forcing this issue and so on:
(1) Calling down a streisand effect on Dropbox. Perhaps you believe that code is meant to be free to such an extent that this is part of your goal, so, sure.
(2) They clearly have no intention of allowing DropShip to become a common use case. If your Streisand effect results in wide adoption by people who just latch onto your censorship angle, they will have to take rushed action to prevent further spread.
(3) This rushed action could be a technical solution (maybe challenge-response, as mentioned) or a banhammer once they have narrowed down the use signature for dropship.
--
(3a-technical) If it's the technical solution, as it was produced under rapid duress, is buggy. Suddenly, your beloved dropbox starts corrupting your files, or refusing to sync some in edge cases. Oops. Some [paying] users who never even heard about this 'censorship' issue notice this issue and take their business elsewhere, and of course it's less useful to you too as a tool until they fix it.
(3a-technical alternative) It's not a buggy fix because they're supercoders. Still, their team had to put in an ungodly week to make and stress-test the fix; congratulations on ruining their quality of life for a week while still losing dropship.
(3b-banhammer) Well, they figure out how to track people using dropship, and maybe institute a 3 strikes policy (2 emails, 1 ban.) So you stop using dropship after the first email, with a bit of simmering resentment at dropbox; still no dropship. Meanwhile, there are false positives because of course there are; this generates a second, far louder streisand effect, and dropbox again loses some paying customers.
-
In summary: sure, open-source code is meant to be free. But your actions don't exist in a vacuum. At the end of the day, Dropbox is clearly not going to tolerate dropship on its network. Consider whether you would rather keep using dropbox as it is, or shoehorn yourself into basically open war on dropbox unless you can dropship on it.
(Tangentially: it was a neat enough hack, but it still doesn't seem any functionally different than sharing public URLs for the file, with the only differences being that you circumvent the bandwidth limits - again, congrats on fighting the TOS of a service you supposedly love.)
Edit: Thinking about this a bit more, the primary expense of this scheme would probably be accessing the file to verify the challenge results. Here's a question: is there a cryptographic scheme which would allow responses to some form of challenge to be verified using a relatively small key (32 or 64 bytes would be nice), but for which it isn't feasible to rebuild the key given a few thousand sample challenges?
I believe they've already implemented the former. If the de-dup benefits were significant they could implement the latter.
Given that Dropbox apparently has no qualms about perjuring themselves in order to stop Dropship (or, as discussed in an earlier thread, lying about their security measures in order to defraud their customers), they could probably also take retaliatory action beyond just denying service to the user. Here are some possible retaliatory actions they could take:
* they could publish the user's private files, or simply look through them for the user's credit card numbers.
* they could sell the above data to the highest bidder.
* they could use it to attempt to impersonate the user to their bank in order to empty their bank account.
* they could randomly corrupt the user's data. (This might require a backdoor in the client software.)
* they could wait for an unusual volume of requests from the user (perhaps indicating that the user was trying to restore from backup) before terminating the user's account without warning.
* they could carefully comb through the user's files looking for evidence of any crime (illegal drug use, underage drinking, copyright infringement, possessing seditious literature, importing obscene material, defaming Islam, apostasy, embezzlement, tax evasion, whatever is the biggest no-no in their locale) and anonymously tip off the appropriate authorities.
* they could insert faked evidence of such crimes into the user's files, and then tip off the appropriate authorities.
Perhaps potential Dropbox users ought to be wary. This is a second data point in the company's history of seriously unethical behavior; one hopes they wouldn't engage in any tactics like the above in a dispute with a former user, if their extremely polite requests failed, but my experience is that people who behave unethically in medium-large ways often behave unethically in larger ways as well.
Caveat utilitor.
No need to fake it even - they could insert files which are illegal to posses into your Dropbox account, wait for you to sync them to some/all of your devices, then tip off the relevant authorities.
Keep in mind too, you're running their closed source application on your machine with at least the same privileges as your user account - if you don't trust them, you're already hosed. I have no way of knowing the Dropbox app on my laptop or iPhone isn't rummaging around my filesystem looking for interesting stuff and uploading it to their servers. The very feature that makes Dropbox so much more useful than, say, tarsnap or Tahoe or any of the many S3 backed cloud storage options, the fabulous filesystem integration - fundamentally giver their app an enormous amount of access to my system. If you really think Dropbox are crooks, you need to uninstall their software from every machine you care about, and change every password, key-pair, credit card number, and any other credentials those systems might have ever stored in the file system in a way that's readable by the user accou t the Dropbox app was running with, or for the truly paranoid, any piece of data the system has ever stored or accessed...
This seems an intentional exaggeration of the issue to drive traffic.
>wladimir: Arash (the CTO) asked me to, in a really civil way. So I decided to respect his wish and take down the repository.
The section I believe that they are referring to when they removed the public link is:
General Prohibitions You agree not to do any of the following while using the Site, Content, Files or Services:
Post, publish or transmit any text, graphics, or material that: (i) is false or misleading; (ii) is defamatory; (iii) invades another's privacy; (iv) is obscene, pornographic, or offensive; (v) promotes bigotry, racism, hatred or harm against any individual or group; (vi) infringes another's rights, including any intellectual property rights; or (vii) violates, or encourages any conduct that would violate, any applicable law or regulation or would give rise to civil liability;
...
Attempt to decipher, decompile, disassemble or reverse engineer any of the software used to provide the Site, Content, Files or Services;
(Excerpted in whole for clarity. Full Terms at: https://www.dropbox.com/terms#terms)
Seemingly not only is posting the code for DropShip a violation, but just by me putting up this file ( http://dl.dropbox.com/u/1498040/2plus2equals5.txt ) in my public folder, I'm also violating the Terms, as I am publishing text that is false and possibly misleading.
This wasn't somebody trying to strong-arm somebody else. It was an understandable mistake.
https://github.com/apperoid/dropship
http://www.mediafire.com/?6gplpdpib6zg5dm
https://rapidshare.com/files/459187624/driverdan-dropship-56...
Is this line terrifying to anyone else? Between this and the published security problems, I am steering clear of this service.
- Overblown "geek rage" over a non-existent DMCA takedown notice and bizarre "legal" arguments
- A company mishandling a security flaw by asking a developer to remove code that exposes the problem rather than simply fixing the problem and leaving the code in wild to demonstrate that the flaw doesn't exist anymore
I use DropBox, although I wouldn't say I depend on it. What this episode did make me appreciate is the degree to which DropBox is a closed product - there may be good commercial reasons for this but as a consumer I'd rather use a service that has at least an open and documented interface (even if the implementations are still proprietary).
It was an automatic email sent by mistake and was retracted by when discovered. It's certainly an issue worth mentioning and discussing but don't fixate on it.
Don't get me wrong, I was completely enraged when I received it but I think Dropbox has done well in addressing it.
People here should just relax, I'm sure there are many companies that deserve your rage but Dropbox is not one of them.
They simply asked me to take down the repository while they could work on blocking Dropship technically on the server side. No threats involved. This should be very good PR and many companies can learn from this.
Sure, trying to prevent people from writing/distributing programs that use a service in unexpected ways is pointless in the long run. If something is technically possible it will be done.
Hence, as some more validation is added, Dropbox will overall be a more secure service. In my opinion it was a feature instead of an exploit :) but hey, it's their service.
All the meanness flunged in this thread at either me or Dropbox is completely uncalled for.
A knife can be used to commit murder, but most often it is simply used to cut food. The problem with the way DMCA works is that it bars the development of new technologies because one of many uses could be harmful. The law stifles innovation when used this way.
Most of the time, a knife is used for cutting food and it can be used for murder.
Most of the time, torrents are used for piracy and they can be used for legitimate and legal files.
Search for "torrent" on Google. The majority of the results are search engines for pirated material (and in many cases, direct links to the torrents).
See the difference?
You are indeed correct that most Torrent Sites are mainly piracy distribution hubs. However, torrent sites are not indicative of torrent traffic by _Clients_. *
From what I understand, Blizzard uses torrents to spread patches for World of Warcraft. It is also used, I believe, in Steam as well.
* I would also argue that, although copyright violations, transfers of TV shows are already done via the main distributors' websites. Other than where the source is from, I do not see much a difference.
I would also argue that piracy itself is a response to market failure. When it's easier to get working media (notably cracked programs and music/movies/shows) via a 3rd party distribution than from the source, there is _something_ wrong. Many times, it is because of "We wont sell to that country until $later", or "Our antipiracy software wont run on your computer", or it just is infeasible to find it. But essays have been done on this topic alone.
I would argue that the prevalence of piracy harms, for example, Rapidshare’s image as a serious filesharing service. That’s not an issue for Rapidshare because piracy is their business, but it isn’t the business of Dropbox.
This is consequently not so much about the nature of piracy and much more about the image of Dropbox.
Whether or not Dropship would actually be a good tool for piracy is very much an open question (and one you can certainly argue about), Dropbox seems to think it is.
(I also want to note that even if only one percent of all torrent traffic is piracy related, it’s still wrong to compare it to knives. There are so many knives in the world, the fraction of knives which are used to harm people must be infinitesimal. And, to clarify something else: I would be vigorously against any legislative attempts at banning torrents. Legislatively, that’s just not the right way to go. But that’s the law and Dropbox is no government.)
RapidShare/MegaUpload/etc. have a very large amount of copyrighted material on them, and Dropbox would be wise to avoid becoming the easiest alternative to them, even if it involves breaking some eggs.
Here is my quick and dirty technical solution.
(1) Place a restriction: only allow users who have uploaded a given file to download that file. In essence, keep an "uploaded" flag for each file/user.
(2) Challenge-response to validate local copy of a globally-known file: To continue receiving the benefits of de-dup, don't actually upload an already globally-known file, but perform a challenge-response with the client on the contents of the actual file. This will still leverage most of the benefits of de-dup w.r.t bandwidth savings.
At least Twitter had the sense to phase-in client auth for apps before shutting down 3rd party developers.
Legitimate users are not impacted at all from this recent change; people who were wanting to share copyrighted files to the masses are impacted but they aren't customers Dropbox would want in the first place.
I think its disingenuous to say Dropbox shouldn't have tried to stop the project from being used; if I ran Dropbox and something came up that threatened my company and its customers I would try and stop it being used in an instant.
The people Dropbox contacted voluntarily took down the project, so they must have agreed with Dropbox's logic in some form that yes perhaps the project would better off not be available.
I'm not sure I like the title, "... attempts to kill open source project" as if to say open source is some how an endangered species and Dropbox is some horrible elephant killer? :)
I suppose its disappointing to me when I read some comments that are immediately on the attack when it may not be warranted or fair, or put up arguments like 'torrents can be used to distribute linux ISOs' (not a real quote!) when everyone knows thats not what Dropship would be used for at all.
Could someone give me 1 example of a use case here? The only reason I can think of to share the hash of a file instead of a direct link, is because it's an illegal file, and you don't want to link straight to it. Why else would you go through the effort of hashing all 4mb blocks of the file, and sharing those elsewhere?
Of course, this is a dangerous gray legal area, but I think it's fair to say that the only reason to use this is because of illegal files. Also, they didn't take legal action (which wouldn't be right, as no one has been proven of doing illegal stuff), they just asked nicely, so it seems. Dropbox is right to act on this, as it could potentially ruin their platform.
The fact that comments like "Man you guys are dumb." (http://news.ycombinator.com/item?id=2482925) wasn't voted down is indicative of the health of this thread.
Dropship sidesteps the TOS of Dropbox by letting users get unlimited sharing bandwidth. Dropbox itself has a share feature which uses the exact technical mechanism by which Dropship works, except it also puts rate limits and caps on sharing.
OT: This is probably the worst comments thread I've ever read on HN. It's like an echo-chamber telephone game. Jeez.
I can understand them not wanting the files to be public, but as tptacek said this is probably fluffed up quite a bit.
As far as I'm concerned the only issue with how they handled it is the DMCA takedown request, and if the CTO acted as said but that is less of a factor.
If the files were never removed from the persons dropbox and only public urls disabled I'm okay with that. However if the files were removed I would probably count that as all three strikes and jump ship.
It should have been obvious to anyone else remotely familiar with security that dropbox had/has access to your files from the simple fact that you could reset your password, as well as the web interface.
http://dereknewton.com/2011/04/dropbox-authentication-static...
They're said the DMCA was a mistake and they hold their hands up to that. Aside from that, I can't see how they've done anything wrong. OK so asking the author to remove it from 3rd party sites is a bit cheeky, but that's all they did.. ask. I would have asked too, the author didn't have to. He clearly didn't want any trouble.
Imo Dropbox should have just fixed then, and sat there and laughed when people tried to use Dropship and it not work. It would have saved 'Dropbox attempts to kill open source project' and may have even caused for 'Dropbox fixes file hashing issue x days after open source project built to exploit it'. That way, both win. But that's just my 2 cents