drew from dropbox here. i hope you guys can give us the benefit of the doubt: when something pops up that encourages people to turn dropbox into the next rapidshare or equivalent (the title on HN was suggesting it could be the successor to torrents), you can imagine how that could ruin the service for everyone -- illegal file sharing has never been permitted and we take great pains to keep it off of dropbox. the internet graveyard is filled with services that didn't take this approach.
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)
> illegal file sharing has never been permitted and we take great pains to keep it off of dropbox.
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?
> Which is great, except you are punishing the crime, before it even occurred.
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.
It's clearly a violation of ToS to use Dropship, however, it's less clear whether it's a violation to store code that has the potential to violate the ToS.
Presumably if someone has reverse engineered Dropship¹ then we're not far off having an FOSS Dropbox-a-like to use it with? I'd have thought that is the problem Dropbox is most likely to be addressing?
Run your own organisation-wide Dropbox? Yes please.
Edit: ¹ I mean of course created Dropship by reverese engineering Dropbox's protocols.
> Presumably if someone has reverse engineered Dropship¹ then we're not far off having an FOSS Dropbox-a-like to use it with?
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.
>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.
>...Run your own organisation-wide Dropbox? Yes please.
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...
Yes, now that the bug is fixed I would have liked looking at the source code of Dropship just to see how it worked... So it's a pity that they asked people to take it down.
Yeah, I agree to enforcing the violation of ToS. I was writing for the DMCA take down notice for the possibility of illegal file sharing via dropship. (as mentioned by arash/drew in comments.)
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?
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;
Even I am struggling to understand how exactly did this violate ToS?
Was it "illegal code/file"? No! It was a file to a s/w that had the potential to be used maliciously, but the file uploaded itself wasn't, but hadn't really manifested in that form (yet).
I feel asking the dev to take down the Github project is ok, but blocking/restricting access to the file itself, until proven malicious was a bad idea. And if that part about taking down the HN is true, its a dick move.
Yes, its their platform and from an ethical stand point, being proactive this way helps everyone, but it could have been handled better.
Agree the Dropship s/w itself was in some violation of the ToS, but was the file that was uploaded to the public dropbox share in violation? What I am trying to separate here is, how could Dropbox the company "determine" the uploaded file indeed was the Dropship s/w? [I know in this case it was obvious as the dev had probably linked to it].
I am trying to pose a question to a different level, where how can/will dropbox scrutinize each uploaded file in this manner without actually receiving a DMCA from a third person?
And Dropbox hasn't done anything to any users of the code, as far as I know. What do you think Dropbox is doing to people who poke at the code or use it?
"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.
we have a variety of easy-to-use sharing mechanisms (public links, shared folders, etc.) that people have been using for a long time for legitimate uses.
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.
>"to be clear, we _never issued_ any DMCA takedowns to anyone"
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.
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.
I don't think cynicism is justifiable here. Let's use Occam's Razor:
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.
To be clear, Dropbox isn't wording any takedown notices. These are just automated e-mails saying that content is being removed because Dropbox itself received a takedown notice from a third-party and that they are complying.
Actually, you are misrepresenting the issue here from what I understand.
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.
If you mean that I, pbhjpbhj, am misrepresenting then please read the quote and first line again.
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.
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.
Which is great, except you are punishing the crime, before it even occurred.
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?
As mentioned before, IANAL, and I do not have deep/any knowledge of the laws Dropbox is incorporated in. However, "Presumption of Innocence" (http://en.wikipedia.org/wiki/Presumption_of_innocence) aka "Innocent until proven guilty" is one of the universally applied (if not, also accepted), legal concept.
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?
I downvoted you because you are discussing DropBox as though it is a public utility that you have a right to, and some form of due process needs to take place. In my mind, you are completely and absolutely missing the point.
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.
I understand your point, and it certainly ok for DropBox to defend its ToS. But behind this story, seeing how fast they reacted to a single json hack in their model, it shows that DropBox is currently fighting a lot against a strong trend, and moreover against their own users, which is not a good sign for them. Fear is a bad advisor.
Not sure I agree. What indication do you have that this is a "strong trend" or that a significant number of users want this feature? Maybe they see that a small number of users would have a disproportionate impact on their service.
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?
Presumption of Innocence is only valid when being held or otherwise detained due to suspicion of guilt by the government, at least in the USA.
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.
Sure, they have legal rights to do so. However, just because it is legal it does not make it fair (Ref - Sony vs. Geohotz).
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.
I think the comparisons are not correct. Dropbox is a privately held entity and the founders have every right to enforce the ToS and to compare that against Internet itself is not right.
Your logic sounds consistent with plenty of established principles.
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.
There's a pretty easy solution if that happens. Host your files somewhere else. Your use of Dropbox (and their decision to allow you to use their service) is on a purely voluntary, at-will basis.
That's not how the presumption of innocence works. I say that as someone who has practiced both civil and criminal law. Presumption of innocence only applies to crimes. Copyright violations are not crimes, they are civil torts. (Though some actions incident to copyright violations, i.e., circumventing DRM, can be crimes.)
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.
Thanks, It was helpful information. As said before IANAL.
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.
> I understand that you disagree with how Dropbox went about protecting themselves from civil liability.
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.
Are laws purely a cultural phenomenon? Do laws have no association with morals? Your sentiments sound more like the product of an ideology and less like conclusions based on an anthropological, historical, philosophical, or any sort of open-minded inquiry into culture, societies, and human nature.
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.
I wasn't conflating society and culture. American society, the group of people who are citizens of the United States of America, is a superset of the Christian culture.
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.
You're wrong. You're not even wrong, to be more precise. Your comments are filled with inconsistent use of terminology and drift between discussions of individual people, cultures (semi-coherent bodies of artistic, intellectual, and artistic achievement), and societies (aggregates of people who more or less share a culture, physical space, and institutions).
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.
I'll just chime in to post another point that was missed here. Arguably the most important (and controversial) principle in American jurisprudence is the freedom to enter into contracts. Dropbox has terms of service to which you manifest assent either directly (by clicking "I agree") or by your actions (that is, just by using the service). I'd venture to guess that in their terms of service is some provision that gives them the basis to remove accounts at any time, for any reason.
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.
It's biased to say that torrents and rapidshare are equivalent to illegal file sharing. Illegal file sharing is just how people use these platforms, but not these platforms themselves. Dropbox is just another file sharing platform which directly exposes to the threat of illegal file sharing.
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.
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?
No DMCA takedown requests were sent to GitHub. We simply nicely asked the author of Dropship to take down the link and he fully understood our position and took the code down.
The only erroneous use of DMCA was when we attempted to take down the link on Dropbox, which was an entirely honest mistake.
"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."
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.
Since the original dropship repo mentioned on razorfast is still available (and has a pull request waiting), and the comment didn't really contain any context, I wouldn't give it much weight yet.
Asking people to remove stuff from HN? That's utter bullshit, and if true, I'm basically done with Dropbox. Asking people not to talk about something (with access to your service as the gun to their heads) is not something I will tolerate in someone I do business with.
I don't actually use Dropbox for anything, though, so perhaps my thoughts don't matter.
You're done using something you don't use because they _asked_ someone to do something (rather than taking the industry standard approach of getting lawyers involved)?
we've fixed the deduplication behavior serverside to prevent "injection" of files you don't actually have, for a variety of reasons
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.
> ... the substantial information disclosure and possible misappropriation of sensitive documents that it could have facilitated
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.
I agree that random collisions is an unlikely attack vector. However, there is not a general understanding that disclosing sha256 hashes is the same as disclosing the file. Imagine a social engineering attack that requested employees run a 'sha256sum ~/Documents/* > hashes.txt' and mail the results with the explanation that this is to make sure they have no infected documents/old versions/unauthorized files on their hard drives. Many people would be willing to do something like that if it appeared to be from a legitimate source, but if they had been asked to email all their documents they'd be much more unlikely to comply.
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.
It would still allow collision attacks though. There are probably a lot of legal and medical documents (recipes) that only differ in a few words, such as name and date of birth. By trying a bunch of combinations you can test if those documents exist.
The collision attacks outlined above still work, with a regular dropbox account, no dropship needed. You can create 100,000 attack files, and then upload each one. The ones that don't actually transmit bytes show you that the file exists. (EG a highly regular file like some health or banking record...)
Its just watching if de-duplication happens or not.
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.
From what I understand about Dropbox's anti-piracy system, he's talking about what they do when, say, someone posts a public link to "Spiderman.3.DVDRip.avi" in a forum in China. This obvious and illegal use of Dropbox is a big liability, not to mention source of traffic.
I appreciate the nice-guy approach here, but there remains two problems with it: relying on the goodwill of internet strangers not to abuse the service and exposing Dropbox to false DMCA takedown liability. "Under penalty of perjury," I think the clause goes. That auto-takedown workflow might need a little revision, but I'm sure you already realize this.
Out of interest, how do you plan to stop people using dropbox like rapidshare? It would be easy for one to upload a file divided into multiple rar files and distribute them to different dropbox accounts. The only way you would be able to block this is watching for a large amount of downloads of a particular file and finding out the context of the file which may prove impossible (and possibly illegal).
In terms of the software, it is unlikely that the general user will use it without some technical skill.
Dropbox already has provisions for restricting those accounts which use an excessive amount of bandwidth. They'd be able to block those files without needing to know the actual contents.
If I wanted to be a complete ass about using dropbox for piracy, I'd use GPG.
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.
If dropbox opened the archives (to check) then it would be against the British data protection laws (and probably most other countries) if they were not given the access by the owners.
I have no want or need to trash it with pirated material either.
Yes, in an ideal world their system would only ever store and forward a received DMCA notice.
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.
Hey Drew, Alex from JDownloader (an OS project with over 15M activeusers, btw) here.
>>"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).
I sympathize. But could you please explain how that email was "auto-generated"? I'm trying to give you the benefit of the doubt, I love what dropbox does, I understand the need to protect yourself from people looking to abuse the service, but... come on... was it really autogenerated? I think that is the part that has everyone scratching their heads.
I think they only ever planned to manually remove user's files in the event of receiving a DMCA takedown notice. So they implemented an automatic notification stating that.
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.
I would like you to answer a simple question because after reading Arash and your responses I have doubts about using Dropbox.
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?
At the time they requested the removal of the tool, they hadn't yet fixed the problem server side. I don't think it's egregious to request that the tool be taken down while they worked on fixing the problem. Much like how security exploits aren't just immediately published without notifying the company so they have a chance to fix it.
Regardless, I can completely understand the actions of staying away from Rapidshare (read the full comment for a day pass of $5, or wait 30 seconds).
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.
Just a quick thing to point out. The rabbit is out of the hat (or whatever is the correct proverb for it). As with all technologies seen in years past, don't fight it on "legal" terms, and I don't mean legal as in suing the crap out of them (the Sony method), I also mean pleading to the community (the Valve method).
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.
Consider that maybe what's happening here is boring. Recognize that we all have a cognitive bias towards narratives, and especially interesting narratives. The discussion on this story is trying to build a narrative about Dropbox vs. open source developers. The real story is probably not that interesting.
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?
Understandable except the assertion of filing a dmca because he thinks that the reposts of code are "geek rage". The DMCA provides that you may be liable for damages (including costs and attorneys fees) if you falsely claim that an
item is infringing your copyrights.
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
Am I reading the article wrong? The way I read it, Dropbox did NOT issue a DMCA notice to Github; it's system just automatically triggered a notification to a Dropbox user that Dropbox had received a DMCA notice for that file.
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.
Are we arguing over whether filing DMCA takedowns on innocuous MIT-licensed code was a mistake? I'm sorry if I communicated that I didn't think it was a mistake. But it's my perception right now that even Dropbox thinks this was a mistake; the guy who wrote this blog post posted more mirrors of the code. Is Dropbox trying to get them taken down?
People make mistakes. In the grand scheme of mistakes, this is an extremely trivial one.
I don't think that the unjustified and unilateral removal of code from someone else's access or threatening anyone with legal action is ever an acceptable mistake, let alone "trivial".
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.
We disagree. The mechanism for getting Github to take down code is the DMCA request; it's what you use when someone at Github is hosting code that they didn't own that you'd like removed and you feel you have some grounds to have removed.
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.
I understand the justification for the DMCA's existence. I agree with the measures that Google for instance has put in place both to file DMCA requests and to file counterclaims. Google also goes to great pains to proactively inform users of possible infringement on Youtube. That's all well and good.
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
No, it isn't used for "some grounds", it's used for content (in this case, code) that directly violates your copyright, period. The DMCA process is very clear, and it isn't for "I don't like $content".
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.
Let's put this in context. Here's what I don't get: the DropShip code is just an exploit of the fundamental architecture flaw of cross-user content deduplication, revealed earlier this month [1]. As the closest thing to a resident security expert around here tptacek (at least to me, I find your comments very enlightening on the whole), how do you feel about a company dismissing an exploit when it's still just an idea, then rushing to erase all evidence of the exploit once it's realized?
I hope this point does not get lost in the shuffle. This whole issue is very much due to the fact that Dropbox did not handle the initial reporting of this problem when it was announced.
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.
"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"
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.
I don't appreciate being told that I'm being deliberately disingenuous. I have no dog in this hunt. I've never spoken to any of the founders of Dropbox. Maybe you didn't mean to be this dramatic in your response? Or maybe I said something that specifically set you off, in which case, let me know so I can amend my comment.
Your comment does appear disingenuous, though I'm sure that's not deliberate. Neither false DMCA notifications nor github takedown requests are legitimate responses to "simple nerd-rage" when it's about MIT-licensed code. I'm sure you understand this and you say as much elsewhere in your comment; but your sentence appears to trivialize these actions by including them after a soothing "the only thing... purported to have done... to politely ask...", and dismissing their significance with "simple nerd-rage".
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.
> Your comment does appear disingenuous, although I'm sure that's not
deliberate. Neither false DMCA notifications nor github takedown
requests are legitimate responses to "simple nerd-rage" when it's about
MIT-licensed code.
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.
I don't know what tptacek based his words on github takedown requests on; I'm basing mine specifically on the comment by 'R' to the blog post. You make a point elsewhere that the post's author's repository is live on github, but that's not the original one, which was removed by its author. The way I understood the comment by 'R' was that they forked the original repo, and the fork was silently deleted, perhaps due to a request by Dropbox (DMCA or otherwise) that followed up to the original author's voluntary deletion.
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.
> 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.
Sorry, as written, your sentence seems fairly calculated to give the impression something minimal is happening when you clearly know something other than "a friendly discussion" is happening. My post above says why I believe this. Feel free to answer the specific problems I raise.
No, I think something minimal is probably going on here. My spidey sense tells me Dropbox is not the evil empire trying to suppress freedom of expression among coders. I can imagine that were I in Arash's shoes, I too would be very worried about impending Rapidsharization of my service.
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.
I can completely understand Arash not wanting Dropbox to be used as a Rapidshare or other similar site - he has every right to enforce his Terms of Service - that's what they are there for, and what users agree to when they signed up (their own fault for not reading it and just now seeing that their files can be removed or their account can be suspended).
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.
I'm seeing a much different narrative, which is very interesting to me. It is the continuing narrative about Dropbox and security. Last week it was the revelation that their crypto is backdoored. This week it is the revelation that their devs are piggybacking ACL functionality onto their dedupe hashing algorithm. I'm seeing a pattern here, that your files are nowhere near as safe on Dropbox as you think they are, nor as safe as Dropbox represents them to be.
I'm not sure I get your point. Everything in my blog post was true. The writing style is irrelevant to the facts. So what if I wrote it in a manor interesting to HN readers? That's the point, to get people interested and spread the word.
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.
This is Arash from Dropbox. We removed the ability to share the project source code 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.
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'.
Of course you're well within your rights to remove the content from Dropbox itself as it violates your TOS - I think most people are objecting not to that, but to you requesting that copies of the source be removed from third party sites like github.
The attempt to quash knowledge is the offensive part - not the enforcing of your TOS. At least that's my 2 cents.
I agree that the removal of the code from your site is not censorship, but I think that misses the point. Asking for the code to be removed from GitHub is very different than removing it from the Dropbox website.
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.
I agree that the removal of the code from your site is not censorship...
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.
"We have received a notification under the Digital Millennium Copyright Act (“DMCA”) from Dropbox that the following material is claimed to be infringing."
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...
Accidents happen, but you sure do not want your startup to have an accident involving a DMCA takedown notice sent in error. There are penalties for doing such. It is generally best to vet this stuff with a lawyer.
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.
I agree. I actually proposed this idea a while back but never went through with the implementation. I hope Dropbox turns a blind eye to this because I think its fair use of Dropbox. Instead of someone sending you the file and then you adding it to Dropbox manually, you can just send the hash for the file and receive without P2P. This is where the world of online storage might head anyways.
"We removed the ability to share the project source code because it enables communications with our servers in a manner that is a violation of our Terms of Service."
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.)
If I may ask something quite specific: how do you justify _automated_ transmission of DMCA take-down requests? Shouldn't a human being be reviewing them first to prevent this sort of thing? Do you guys care? I mean, who's idea was that? As a customer and a developer, I'd really like to know.
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 the email auto-generated and sent a DMCA takedown email. This was a tool built for our support team and I'd never personally used it.
The form letter the OP got wasn't a DMCA takedown notice. The letter stated that a takedown notice had been received. That was untrue (the file was being removed for a different reason) but since no takedown notice was sent it certainly isn't perjury.
I personally feel that Dropbox removing files from someone's account is completely wrong, regardless of your ToS. Your service is there to backup files. When you delete references to files from someone else's accounts, you're violating the trust that people put in your service.
This contradicts your earlier statement -- that you removed the file from the person's account.
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?
This whole situation is pretty revealing about Dropbox. If hosting software that COULD be used to violate the TOS were also a violation of the TOS, and if Dropbox had been in the practice of banning such files, then 2 outcomes would have obtained:
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.
Despite that, I'm reading your terms of service, and it sounds to me like you reserve the right to terminate service (which sounds like it would include deleting files) with or without notice, if you deem there has been a sufficiently egregious violation of your ToS.
I don't understand why you would bother? If they still had the file, wouldn't they be quite able to post it elsewhere? Why the censorship? I'm not comfortable in the knowledge that Dropbox can willy nilly refuse to allow me to share files on a case by case basis.
I can understand dropbox not allowing you to publicly share files on a case by case basis, or else I could simply put illegal content in my public folder and send out the link.
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.
Pimp slapping developers works well for Facebook and Apple so why you miss out on all that fun, right? Next time don't take the personal touch and email them personally. Instead wait for their app to gain a following then suddenly ban them and let them cry like bitches. Then send them a form letter saying their account was banned for violating the new ToS you haven't even posted yet, and by the way this communication is considered a national security secret so they can't talk about it to anyone including their spouse. That's big pimping. Then sign the email with "You've been Dropboxed, bitch!" That'd be your tag line. You're my hero.
DMCA notices aren't a joke that you can idly send to anyone who annoys you. You are legally liable for them, and telling a judge "Oh, we just send them automatically without checking" is not going to help your case.
To razorfast guy:
Can you look at the SMTP headers of the DMCA takedown to see if they're coming from a desktop e-mail client or indeed some sort of auto-mailer? Might give a clue if the e-mail was indeed "auto-generated" or not
Congratulations on becoming a large enough company to start getting hated on. The web recently started piling it on you guys which I think is something you should take pride in.
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.
Best thing you can do now: offer the dropship guy a job.
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.
I'm sure I'm not alone in not quite getting how mere possession of software which enables the violation of your TOS is itself a violation of your TOS. Can you clarify that?
You _accidentally_ sent a DMCA notice?! That might be worse than sending an erroneous one. You're technically under penalty of perjury for false DMCA notices.
It is a shame your developers allowed you to commit perjury in such an automated fashion.
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.
There's another comment that has a pretty good theory -- the form the tool uses probably has a field that asks you to fill in who requested the file(s) be removed.
(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.)
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.
By policing and issuing a dmca notice dropbox seems to be risking their status from "carrier/hoster"?
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?
You're mixing up your concepts, thinking of common carrier status that is used for communications networks. DMCA takedowns were designed so that hosting companies could avoid contributory copyright infringement accusations only. Common-carrier was designed, for example, to prevent telephone companies from being accused of contributing to crimes hatched on their wires.
Would the civil litigation be against the company or the person? What sort of penalties are involved in such cases? If they lose, would the winner basically own a chunk of dropbox?
Not an invalid DMCA request, even assuming one was sent out.
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.
> In America, derivative works include software programs which are inseparably reliant on code or features (including APIs) of another program. ... 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.
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.
I can see why Dropbox would be upset about the existence of such a thing, but trying to force people to take it down seems incredibly foolish. The whole issue will garner them negative publicity and people will see it anyways thanks to the Streisand effect.
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.
Assume for a moment that this makes the nightly news. How many people in "average joe" America who don't know about Dropbox will checkout it out and say, "oh man, this is useful! and they even have a free account!" Do they care about this DMCA garbage, or what Dropbox actually did/did not do? Maybe, but the national news won't report it correctly anyway. Here's how it might be spun:
"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."
This won't make the nightly news. This will only be reported to the types of people who 1) already know about dropbox, and 2) understand the significance of DMCA takedowns made in bad faith.
In order to disprove the statement "there is no such thing as negative publicity" one merely needs to produce a circumstance where there is indeed negative publicity. This is pretty trivial to do, and doesn't require imagination.
Dan DeFilippi: "In my unhumble opinion censorship is never an option."
Dan DeFilippi would certainly not like it if all his documents and code from his personal hard drive were splashed across the internet.
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.
However justified you think piracy is, resisting efforts to turn a product you created for legitimate personal file sharing into a better BitTorrent is a valid business decision.
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.
> Yes, they tried to kill an open source product, whose purpose was to facillitate illegal file sharing over DropBox.
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.
Linux ISOs are always the example people come up with when they're defending protocols and methods which are primarily used for illegal purposes.
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."
And hell, movie trailers are copyrighted too, and I assume aren't licensed for arbitrary distribution. So posting/sharing a trailer using DropShip is likely copyright infringement too.
Do you need Dropbox or just something like it? Dropbox doesn't seem to have very strong network effects so it seems like it would be easy to replace with a similar product. If you're willing to give up features that require hashes to be shared across accounts you could even have a secure replacement with client side encryption.
Thanks for the sarcastic response, but I'm already familiar with that page.
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.
I've used SpiderOak and I was happy with it. I only used it to synchronize files across my laptops and desktops so I don't have any experience with mobile clients for it. I now use cron, rsync, and ZFS snapshots for versioning of all of my home directories. Both solutions worked well for me and which one, if either, is best depends on your situation.
To say it all, in the past few years a number of alternative have emerged. I never bothered looking into it because I am so happy with Dropbox anyway but I bet I would find another to be happy with.
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.
"We have received a notification under the Digital Millennium Copyright Act (“DMCA”) __from Dropbox__ that the following material is claimed to be infringing."
I already deleted it. I'm not sure how I can prove it to you as I didn't get an email, and when I clicked the "Delete Account" button to commit to deleting my account it just bounced me to the dropbox homepage. But thanks for trying to call me out.
You don't need to prove it to me because I don't particularly care and it doesn't actually matter, so let's just say I believe you.
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 had, and dropped a paid account to free. I wasn't above my quota, and was basically just paying as a "I like what you guys are doing" sort of feature.
I no longer like what they're doing, so the gravy train stops.
You know, I really don't understand the rage around this case, or more specifically that it's supposedly all coming from people who otherwise love Dropbox.
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.)
Or from a slightly different perspective, "strongly encouraging the developers at Dropbox to focus _now_ on security/privacy issues that ought to have been dealt with before pushing their existing code live". Doesn't seem to deserve the label "worst crime" when described like that.
Dropbox has a simple technical recourse to prevent de-duplication from being used for file sharing - issue a random challenge (a slightly more sophisticated version of "ok, what is the 100th word in the file?") before acknowledging a collision as a true duplicate.
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?
AIM used to ask for a cryptographic checksum of a randomly chosen byte range of the AIM executable. The Gaim (now Pidgin) developers had to set up a server that would return checksums on demand. This doesn't meet your requirement of the verifier needing a small key.
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.
"* they could insert faked evidence of such crimes into the user's files, and then tip off the appropriate authorities.
"
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...
Considering Dropbox doesn't do automatic upgrades (at least on a Mac it doesn't), you can always stay at an older version of the client where this new protocol isn't supported and thus Dropship still is valid. I doubt that Dropbox would ever ban previous versions of their client purely for this purpose.
They could still do something. In cases where they have reason to suspect this is going on (which could be based on file usage patterns), they could start asking clients to send the file. Clients that start an upload and then disconnect when asked for the file are pretty much caught red handed, and you could just block their accounts until they upgrade to the next version.
For older clients they could require upload of the full file (same as if the file has never been uploaded). For new clients you could use the challenge/response scheme.
I believe they've already implemented the former. If the de-dup benefits were significant they could implement the latter.
Tip: If something is on the web and has been linked to via a site like HN, don't ask them to remove it no matter how bad it hurts you. It will never result in a good thing for you and will definitely hurt more afterwards.
This is not about the Github repository of the original developer. Someone managed to download a tar archive of the repository from github (after the repository was removed from github) and uploaded it to his public dropbox folder.
I spent a few minutes going over the Dropbox Terms of Service.
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;
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.
The DMCA notice came as a result of an automated support system. The CTO's understanding was the system blocked access to individual files, but the real purpose is blocking access as part of DMCA requests, so it automatically sends the DMCA notices out.
This wasn't somebody trying to strong-arm somebody else. It was an understandable mistake.
- 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).
I've seen a lot of comments that misunderstand the DMCA. Many people seem fixated on this issue. Had I realized this would be the case I wouldn't have emphasized it as much.
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.
Am I the only one who finds it refreshing to see a business trying to protect itself with a friendly email rather than legal threats? Kudos to the Dropbox guys for walking that fine line with such finesse.
Yes. I think that's the only thing that's deserved to be said here.
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.
Why does everyone make the assumption that torrents and services like Dropship must be used for piracy? Major video game companies use torrents all the time to distribute patches and betas.
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.
The vast majority of torrenting currently is piracy related. The vast majority of knife use isn't murder related. That is the difference, and talking around the issue doesn't help.
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.
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.
My guess is that Dropbox cares about its image and wants everything piracy related to be kept at arms length. It’s not their business model. They want to be a trustworthy service everyone – from nerds to their moms and dads – wants to use.
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.)
As much as I'd like to see companies busted for abusing the DMCA to take down things they object to, I would rather it had been one of the traditional Big Media Thugs who was on the wrong end of a lawsuit for fraudulent DMCA claims rather than Dropbox... who I otherwise like.
Isn't the so called DMCA take down notice in this example not just a notification for the user that Dropbox received such a take down notice and not a DMCA takedown notice?
This behavior is unconscionable when there is such an obviously trivial technical solution to this problem.
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.
I gues they're already at a point in their business where they feel like it's easier for them to try to silence their fanbase-hackers-modders-addon developers instead of just quietly fixing the issue.
At least Twitter had the sense to phase-in client auth for apps before shutting down 3rd party developers.
Dropbox can decide what its servers/resources are used for, and allowing 'Dropship' to be used to transfer copyrighted files sounds like a problem they don't want - and neither would I, as a company owner.
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.
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."
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.
I don't know because I thought your comment was insightful. But since this is one of the worst threads I have read since I joined HN, in terms of FUD and signal-to-noise ratio, it is not impossible that someone who misunderstood the situation downvoted you.
Sure: When the client has created a hashsum of the file and sent it to the server, the server can respond with a challenge: "What's the SHA1 of the bytes between X and Y" (where X and Y are random numbers). This is something both parts can easily compute and the client must have the whole file in order to answer the challenge.
If you spend so much time, passion and money building a product like Dropbox you will try to defend it from every kind of threat: today the "piracy" topic is a hot one, sounds like its worse than killing someone, and Dropbox is hit by this "piracy" threat. I fully understand and respect Dropbox founders positions, and the DMCA issue is clearly a bug in my opinion (i wouldn't automatically send those kind of communications upon a system-forced file deletion, however).
Anyone saying that Dropship has legal uses is wrong -- you're stealing from Dropbox by using it whether you're sharing your academic, public-domain dataset or your pirated movie.
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.
I suppose so, I always took that statement to be that employees didn't have easy access to your files (such as without decrypting from the servers).
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.
wewyar, like kragen & iamjustlooking pointed out I considered that whole episode as strike1. I agree I am being extremely critical and have to agree in spirit that this is their real goof up. Poor security is not a reason to abandon the ship if they show an intent to fix it ASAP.
What I felt a bit let down by this whole take down thing was, their initial approach was to surpress the hackers rather than fix their problem. I see in another post they seem to addressed it the loophole (?), which is the way to go. Embrace ppl tinkering this way but make your platform robust.
Forget about DMCA and other excuses. Dropship-like hacks could have huge negative impact on Dropbox business model. I can't fault them for taking actions to protect their business.
It's a shame that Dropbox has resorted to attacking its users and threatening them with loss of data. Looks like it's time to clone Dropbox and offer some respectable service to users.
I can't see that they've done any of this. They've been pretty polite about the whole thing. At least that's what the article says. The fact they mention that their terms give them the right to deny users access to their service at any time doesn't mean they're threatening. It's just a reminder.
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
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)