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.
"We have received a notification under the Digital Millennium Copyright Act (“DMCA”) __from Dropbox__ that the following material is claimed to be infringing."
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.
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.
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.
No, that's the problem... they haven't stopped their own servers from helping at all, because anyone with the hash can still access the file, which is the whole basis of how Dropship works.
If Dropbox doesn't want Dropship to work, I think they should spend time actually updating their code to remove this exposure, rather than trying to get the code erased from the internet.
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.
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.
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.
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 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.
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.
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.
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.
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.
True, but when there is a bunch of angry villagers at your doorstep, you need to do something to placate them. It's no longer about who did what, it's about who takes the next move.
Dropbox needs to maintain goodwill among the programmers it sells it's services too. Dropbox can completely take the wind out of the "fuss-causer" by issuing an apology to everyone involved along with an open invitation for the dropship guy to join the team.
That would sufficiently diffuse the situation before the next guy starts ragging on dropbox. No need to play with snowballs here.
"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.
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.
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.
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.
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.
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.
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.
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.)
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?
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.
"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.)
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.
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.
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.
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.)
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.
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.
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
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.
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.
"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.
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.
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.
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.
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.
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.
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.
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?
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.
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...
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.
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.
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
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?
322 comments
[ 3.5 ms ] story [ 287 ms ] threadI had actually missed the original post, but now thanks to their takedown attempts I've downloaded a copy for myself as its very interesting.
As does the fake DMCA takedown. If Arash Ferdowsi wants people to think he's dishonest, he's going the right way about it.
http://news.ycombinator.com/item?id=2482803
(admittedly, several hours after you posted)
"Hackers, today, are up in arms with Dropbox. The hackers claim that the illegal files being stored there were protected by the first amendment. Dropbox claims that their service could be attacked with those files and removed them."
Bad publicity.
"We have received a notification under the Digital Millennium Copyright Act (“DMCA”) __from Dropbox__ that the following material is claimed to be infringing."
(underscores mine)
Drew would have to kill a baby panda with an elephant tusk for me to even begin thinking about switching.
This said: I stand with dropbox on this issue. Abusing their service to fake a p2p is definitely not the way to go and not that clever hack if you ask me.
What I'm more interested in is what HN users like and dislike and recommend, as opposed to a bunch of features charted into a table with nothing valuable in terms of reliability, usability and actual security.
Lately, I've been leaning towards Jungle Disk for file syncing & some S3 solution for cloud backups.
This is a tempest in a teapot just like those mass "Quit Facebook" protests that spring up every time the privacy settings change. The entire controversy exists because a tiny, yet incredibly vocal, minority makes a huge deal of it only to drop it the next week. And from reading write ups on freemium services, the vocal minority is also part of the non-paying majority.
Dropbox has a technically exploitable feature which they don't want passed around for file sharing purposes so they stopped their own servers from helping. Big whoop.
If Dropbox doesn't want Dropship to work, I think they should spend time actually updating their code to remove this exposure, rather than trying to get the code erased from the internet.
I no longer like what they're doing, so the gravy train stops.
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.
This seems an intentional exaggeration of the issue to drive traffic.
>wladimir: Arash (the CTO) asked me to, in a really civil way. So I decided to respect his wish and take down the repository.
http://news.ycombinator.com/item?id=2478688
We recently built a tool that allows us to ban links across the sytem (as of a few weeks ago) and I wasn't aware that a DMCA takedown email would be auto-generated and sent. This was a tool built for our support team and I'd never personally used it. That said, we feel strongly that the code is a violation of our TOS and don't believe the removal of the content from our site is censorship.
I'd also like to clarify that nobody's accounts were threatened: in every case my phrasing was as follows: 'I hope you can understand our position and can agree to remove the Dropship code'.
The attempt to quash knowledge is the offensive part - not the enforcing of your TOS. At least that's my 2 cents.
I understand it a little less if you are say sharing folders between friends.
And I wouldn't like it at all if they deleted something from my dropbox, but it seems we aren't there yet.
Is that accurate?
I'm on your side here, but you need to be as transparent as possible here. Are you also saying that your system automatically generates emails that make false claims about having received a DMCA takedown notice?
1. The system for banning files would not send out copyright infringement notices automatically. It would be set up for banning things like source code that could be used to violate the TOS.
2. Someone on the support team you claim the system was designed for, would have done the ban, instead of you having to come in and implement "higher-level business logic" by using the ban system for something besides copyright violations.
He knows your product well enough to "break" it and he has the motivation to create something strong enough that it is causing a fuss. Learn from Geohot. Don't scare away people who want to play with and extend your product.
That would sufficiently diffuse the situation before the next guy starts ragging on dropbox. No need to play with snowballs here.
Doesn't this seem to imply that Dropbox is the owner of the code and is both the DCMA submitter as well as the company executing upon it?
An automated system would still require a company name that is requesting the DCMA to be entered, or your automated system is implying that all DCMA requests are coming from Dropbox. Something isn't right about this...
But it's amusing nonetheless. Are there other incidents of a company serving itself DMCA requests?
I find it hard to believe that you did not anticipate exactly this happening when designing (a) an online file backup service, (b) a "de"-duplication algorithm. That said, you should have planned for exactly this a long time ago, whether by the means DropShip used, or any of several other potential file sharing hacks. I think a lot of us here are disappointed with how your actions reflect that planning, or lack thereof.
A) move the files to the public folder
B) watch out for bandwidth limits on the public folder
C) give your Dropbox account ID to everyone as it is tied directly to the URL
With this method, you get anonymous file transfers without bandwidth limits
Yes, only if dropbox let you do that. They can make you stop with a fix in 5 minutes and they will do it very soon.
Why would Dropbox want to let you circumvent bandwidth limits on your public folder?
While you guys have (and always have had) a technically exploitable issue with de-dupe/hashing (which I think is a feature) now that you're the big kid on the block I hate to see you forced to close it.
It was a nice feature, but it isn't going to stand up to random hackers trying to make a name for themselves with a public release of relatively simple code and blog post about how they used/abused your service. Good luck!
And I definitely think it's time to change your demeanor from your local friendly startup to your impersonal corporate entity. At this point you're just going to be stirring up bees.
Even so, my main issue is not whether it violates the terms of service or not -- let's just say using it does violate those terms -- the question is whether taking it down is the right thing to do, for Dropbox and its users. In this case, I don't think it is: the issue here is not the code itself (which does not appear to be malicious) but how that code accomplishes its purpose. That method is not something you can block with requests to take down source code.
Basically: this may violate the terms of service, but maybe the real issue here is that if those terms are blocking this, maybe those terms are wrong.
Disagree. Of course it's censorship. It may be justifiable, and the content in question may be against Dropbox's ToS, but it's still censorship: Dropbox is removing access to content it does not like.
Man you guys are dumb.
(Man, this thread is full of disinfo.)
With all due respect to you and your company (and while I fully support your right to invoke your TOS to take down content within your own service) I'd actually love to see one of the people you DMCA'd slam you on that aspect of this situation legally if for no other reason than to make other companies think twice (or three times) before they improperly invoke the DMCA to scare people into submission.
(The dropbox guy already has said he used an internal tool developed to remove files, without realizing that it would send this DMCA notice notice.)
Arash, you're confusing the software and its potential uses as if they were the same thing, which is standard DMCA brain damage. It's the FUTURE communication with the servers that COULD violate the terms via such communications, IF it actually happens because of an unknown person (possibly not the hoster) using the software at some (unspecified) later time. If that TOS-violating communication actually HAPPENS then you can gleefully shutter HIS account. You don't get to ban the software itself, if the hoster has permission (via MIT license) to host the file. Illegal sharing of copyrighted files is what's prohibited, and that is what the "automatic DMCA takedown" suggests---to wit, that your banning-files-by-hash system is designed to take down copyrighted files in response to DMCA takedown notices. If it was meant to ban files you don't like, you would have had a clue that it would send an erroneous DMCA message about the file.
So it's obvious you just wanted to ban the file. Can you really cite the TOS language that says hosting software that COULD be used for TOS-violating communications with Dropbox, is also a violation of the TOS?
I also think it would be interesting for readers of this forum to see whether or not you've already quietly changed your TOS to cover this case (or will soon do so.)
No one received a DMCA takedown notice. Rather, people received an informational message saying that Dropbox received a DMCA takedown notice.
This informational message has absolutely no legal implications. Everyone screaming perjury should stop practicing law from their armchairs.
IANAL but the dmca provides hosting sites protection against users who infringe. By actively checking for infringement of users having dropship could they be openning themselves to legal complications if they lose "hoster" status?
(sorry, none American and not a lawyer)
Copyright applies to original and derivative works, though multiple parties may own copyrights to a derivative work.
In America, derivative works include software programs which are inseparably reliant on code or features (including APIs) of another program. It's basically the same argument that WordPress and Drupal make in regard to themes, plugins, etc., falling under the same open source licenses (i.e., copyrights) as the platforms themselves.
In this case, dropship is entirely reliant on unique features of Dropbox. This makes it a derivative work, and would mean that Dropbox has copy rights over dropship. The programmer of dropship also has copyrights over dropship to the extent that the code is an original work, but Dropbox's rights trump his b/c they own the rights to the original underlying work.
I don't think that's true; if you've got any case authority, I'd certainly like to remedy my ignorance of it.
"Derivative work" is defined in the Copyright Act: [1]
"A 'derivative work' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a 'derivative work'." [Emphasis added]
I don't recall ever having seen any kind of ruling that sending API-compliant messages to another computer via the Internet, for processing by code already running on the other computer, somehow constitutes creating a derivative work of that code.
And I don't see how, in any normal case, the owner of the code on the other computer could claim that the API message sender had caused an infringing copy of the code to be made. If I were representing the API message sender, I'd likely argue that the owner of the code -- by (putatively) licensing the computer operator to configure the code to listen for and process API messages -- had consented to whatever copying might have occurred.
[1] http://www.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0...
A knife can be used to commit murder, but most often it is simply used to cut food. The problem with the way DMCA works is that it bars the development of new technologies because one of many uses could be harmful. The law stifles innovation when used this way.
Most of the time, a knife is used for cutting food and it can be used for murder.
Most of the time, torrents are used for piracy and they can be used for legitimate and legal files.
Search for "torrent" on Google. The majority of the results are search engines for pirated material (and in many cases, direct links to the torrents).
See the difference?
You are indeed correct that most Torrent Sites are mainly piracy distribution hubs. However, torrent sites are not indicative of torrent traffic by _Clients_. *
From what I understand, Blizzard uses torrents to spread patches for World of Warcraft. It is also used, I believe, in Steam as well.
* I would also argue that, although copyright violations, transfers of TV shows are already done via the main distributors' websites. Other than where the source is from, I do not see much a difference.
I would also argue that piracy itself is a response to market failure. When it's easier to get working media (notably cracked programs and music/movies/shows) via a 3rd party distribution than from the source, there is _something_ wrong. Many times, it is because of "We wont sell to that country until $later", or "Our antipiracy software wont run on your computer", or it just is infeasible to find it. But essays have been done on this topic alone.
I would argue that the prevalence of piracy harms, for example, Rapidshare’s image as a serious filesharing service. That’s not an issue for Rapidshare because piracy is their business, but it isn’t the business of Dropbox.
This is consequently not so much about the nature of piracy and much more about the image of Dropbox.
Whether or not Dropship would actually be a good tool for piracy is very much an open question (and one you can certainly argue about), Dropbox seems to think it is.
(I also want to note that even if only one percent of all torrent traffic is piracy related, it’s still wrong to compare it to knives. There are so many knives in the world, the fraction of knives which are used to harm people must be infinitesimal. And, to clarify something else: I would be vigorously against any legislative attempts at banning torrents. Legislatively, that’s just not the right way to go. But that’s the law and Dropbox is no government.)
RapidShare/MegaUpload/etc. have a very large amount of copyrighted material on them, and Dropbox would be wise to avoid becoming the easiest alternative to them, even if it involves breaking some eggs.
That's a really incendiary headline. Yes, they tried to kill an open source product, whose purpose was to facillitate illegal file sharing over DropBox.
The PR fallout from this among the tech community is probably nowhere near the fallout it would experience if it became the next Kazaa.
Where are you getting that information? My understanding it that its purpose was explicitly to facilitate legal file sharing over DropBox - Linux ISOs, for example.
The original post for DropShip gave, as an example, the trailer for a movie. Not the movie itself, but the trailer. That's the equivalent of saying "I've developed this great way to share files, such as videos, but am not going to explicitly say that it could be used for piracy even though everyone knows that that's the only thing it will be used for."
- a nicely sized file, consisting of multiple 4MB blocks but not overly huge
- already available on the network
- free to distribute (yes, that movie is free to distribute, so the trailer certainly is)
- apart from that, the blender foundation is simply awesome
I could also have used something like the tar archive of the source code or a photo, but this proved that it works for multiple blocks...
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?
... and how is that not supposed be flamebait?
Using this powerful law as a scare tactic isn't acceptable. If you wish to claim that the code was infact infringing, then the conversation is different.
This seems to be:
* illegal use of dmca by dropbox * dropbox says dropship using reverse engineered sync protocol broke anti-circumvention techniques or contains their copyright
Either of which are bold statments
People make mistakes. In the grand scheme of mistakes, this is an extremely trivial one.
The law is not a toy, and it's not supposed to be wielded casually. The DCMA is certainly not treated with the respect it is supposed to afford citizens, and this is just another example of that.
It was a mistake for them to use a DMCA request here, because the code was MIT-licensed and thus even the author can no longer ask for it to be taken down. But nobody paid legal fees here, nobody was sued, and the code is back online, so, no, I am not amenable to the idea that Dropbox is being abusive.
Continuing to file DMCA requests would be abusive.
However, requests should be filed in good faith, under the understanding that you have standing to file the requests. Clearly Dropbox does not, nor does the original author, having MIT licensed the code himself.
That pretty succinctly summarizes why this is problematic. Everyone here knows that they can't do this. The fact that they prepared letters and fired off the requests anyway demonstrates that they were acting in bad faith.
You don't accidentally reach for the DCMA and accidentally shoot off requests to github.
(and it's on that count alone that i criticize Dropbox, i think otherwise that i totally understand why they think this is a huge problem, and exposes them to legal liability.)
Edit: just read (http://news.ycombinator.com/item?id=2482803 ) explaining that the DCMA takedown letter that was email was in fact accidentally sent via an automated system. :P
Abuse of the DMCA is already dramatically overblown, and the cavalier attitude of "oh well, deal with it" is a significant part of the problem.
All that indicates there was is the message received by OP, which claims dropbox as both issuer and recipient of a DMCA notice. That makes no sense -- unless, as claimed by dropbox, it is simply an automated message generated by error.
I think a lot of people in this thread are under the impression that dropbox issued a DMCA request to github, which wasn't even what the OP was claiming.
It's a simple notification email that does almost nothing in the framework of the DMCA and simply notifies the Dropbox user that their file has been removed. It looks like their file removal system is a bit rigid in that it always assumes that a DMCA notice was received by Dropbox, even when they didn't receive one.
So, there seems to be absolutely nothing wrong here -- literally just a simple mistake.
It's the "write a sentence long enough you hope they won't reach the end" rhetorical strategy!
Lawyer: "Your honor, the only thing my client is accused of is politely asking Mr. Jones to stop talking to his girlfriend ... and then punching Smith in the nose believing he had Jones' agreement"
I have to say "well-done" (did you study with Suruman at Orthanc by any chance?).
The web is presently full of entities making egregious claims to intellectual property rights over anything and everything they happen to have touched. You should know quite well that a fair amount of property rights come whether or not a person can effectively claim them and so dropbox's claim to "own" an algorithm can never be simply irrelevant or a "figleaf".
It may not make that much difference but I think it makes some difference to cast some sunlight onto these efforts. Boring or not.
That doesn't mean Dropbox handled this flawlessly. They appear not to have. It does, however, imply:
* The nerds angry about the request to take down the code are not in fact creating a PR nightmare for Dropbox, because they are helping to spread the word that Dropbox is hostile to this use case.
* That Dropbox is probably not going to switch into kamikaze legal mode to keep people from talking about their protocols or building tools, because it was the particular use case fostered by this tool that set them off.
You are free to disagree. I promise not to caricature you as a supervillain for having done so.
My concern is the system they are using for DMCA notices. If it is indeed an automated system, then they are doing things wrong. Yes, have a DMCA notice generated, but someone should physically vet that notice prior to it being sent out - and that should most likely not just be a member of the support staff.
I am also concerned that Arash was using a tool, meant for support staff, that he was not familiar with to perform a mass-removal as well as a mass-DMCA takedown notice when it is obvious any such tool would require him to enter the claiming company name - in this case Dropbox. He should have asked, or been told what is going on with such a tool.
Sure, this isn't a big deal in the larger scheme of things; but it isn't as trifling a deal as your comment's rhetorics make it out to be. Dropbox's actions are hurting its geek credibility, and rightfully so; I take your point about them possibly wishing to appear tough on rapidshare-ization of their service, but they don't have to do this employing tactics that are widely considered to be low. A proper amount of posturing and some real tech work behind the scenes to make this sort of access harder, if not impossible, would achieve more and not hurt their image.
I do have another, more substantive disagreement with your original comment, not about style. I don't think it's as clear as you present that the code in question was obviously not going to be suppressed by Dropbox, and they obviously understood that, etc. Yes, the author of the blogpost is possibly biased towards seeing himself as the hero; but I see nothing to contradict his claim that if it weren't for this one stubborn developer, the code would've disappeared from public access. The amount of goodwill towards Dropbox in the community (notably so in the case of the original author) and their swift attempt at censoring the code might have helped this succeeded.
I don't think anything like that has really happened. There was no DMCA takedown notice, only the (false) message that Dropbox had received a notification from itself, issued when they blocked public downloading of the file. Probably because that's the only way to block hashes they have right now. And as far as I can tell the github repo was removed by the original author, after they asked him.
Edit: Fixed bad quoting.
To be sure, it could be a misunderstanding, a technical glitch, or an attempt at trolling. The Dropbox folks aren't getting my benefit of the doubt on this, though. Their actions, even the ones that aren't disputed, have been unbecoming. Banning the code distribution on Dropbox was a particularly ham-fisted move. It does nothing to curb its spread, because Dropbox is not a web-forum with easy discovery. If I put this file on my public Dropbox folder, the only way others will know to look there is when I advertise this elsewhere, not on Dropbox; but if I'm motivated enough to do that, surely it's no trouble for me to just host it elsewhere.
So the ban only hurts their image more. What if I write a text file with the description of their client-server protocol and put that on Dropbox, are they going to ban that file, too? When you willingly put yourself on a slippery slope, be ready to find yourself sliding.
They have mine.
Now where do we stand?
[1] http://news.ycombinator.com/item?id=2438181
Their initial solution to the problem was updating the TOS and calling it a day. DropShip proved there was a deeper problem that needed to be addressed and the fact that their solution did not start and end with a fix to the problem in the code is mind-blowing. This isn't a huge enterprise company. These guys should know better.
http://news.ycombinator.com/item?id=2440066
(note, the solution Dropbox should have implemented instead of fake-lawyering up was offered very quickly there...)
Wonder what the next headline is going to be.
You assume "everybody understands those things" which simply isn't true. Not everyone understands how Dropbox works. Not everyone understands security though obscurity (which I should have linked in my post for people to learn more, will fix).
As I said in the post I understand Dropbox is attempting to play damage control. The way they went about it was inappropriate. Removing the file from their service is one thing. It's their company, they can run it as they see fit. Requesting all files hosted elsewhere to be taken down and HN comments be deleted is going too far. That's an obvious attempt to kill the project, hence the title.
Is this line terrifying to anyone else? Between this and the published security problems, I am steering clear of this service.
I can understand them not wanting the files to be public, but as tptacek said this is probably fluffed up quite a bit.
As far as I'm concerned the only issue with how they handled it is the DMCA takedown request, and if the CTO acted as said but that is less of a factor.
If the files were never removed from the persons dropbox and only public urls disabled I'm okay with that. However if the files were removed I would probably count that as all three strikes and jump ship.
It should have been obvious to anyone else remotely familiar with security that dropbox had/has access to your files from the simple fact that you could reset your password, as well as the web interface.
http://dereknewton.com/2011/04/dropbox-authentication-static...
Edit: Thinking about this a bit more, the primary expense of this scheme would probably be accessing the file to verify the challenge results. Here's a question: is there a cryptographic scheme which would allow responses to some form of challenge to be verified using a relatively small key (32 or 64 bytes would be nice), but for which it isn't feasible to rebuild the key given a few thousand sample challenges?
I believe they've already implemented the former. If the de-dup benefits were significant they could implement the latter.
Given that Dropbox apparently has no qualms about perjuring themselves in order to stop Dropship (or, as discussed in an earlier thread, lying about their security measures in order to defraud their customers), they could probably also take retaliatory action beyond just denying service to the user. Here are some possible retaliatory actions they could take:
* they could publish the user's private files, or simply look through them for the user's credit card numbers.
* they could sell the above data to the highest bidder.
* they could use it to attempt to impersonate the user to their bank in order to empty their bank account.
* they could randomly corrupt the user's data. (This might require a backdoor in the client software.)
* they could wait for an unusual volume of requests from the user (perhaps indicating that the user was trying to restore from backup) before terminating the user's account without warning.
* they could carefully comb through the user's files looking for evidence of any crime (illegal drug use, underage drinking, copyright infringement, possessing seditious literature, importing obscene material, defaming Islam, apostasy, embezzlement, tax evasion, whatever is the biggest no-no in their locale) and anonymously tip off the appropriate authorities.
* they could insert faked evidence of such crimes into the user's files, and then tip off the appropriate authorities.
Perhaps potential Dropbox users ought to be wary. This is a second data point in the company's history of seriously unethical behavior; one hopes they wouldn't engage in any tactics like the above in a dispute with a former user, if their extremely polite requests failed, but my experience is that people who behave unethically in medium-large ways often behave unethically in larger ways as well.
Caveat utilitor.
No need to fake it even - they could insert files which are illegal to posses into your Dropbox account, wait for you to sync them to some/all of your devices, then tip off the relevant authorities.
Keep in mind too, you're running their closed source application on your machine with at least the same privileges as your user account - if you don't trust them, you're already hosed. I have no way of knowing the Dropbox app on my laptop or iPhone isn't rummaging around my filesystem looking for interesting stuff and uploading it to their servers. The very feature that makes Dropbox so much more useful than, say, tarsnap or Tahoe or any of the many S3 backed cloud storage options, the fabulous filesystem integration - fundamentally giver their app an enormous amount of access to my system. If you really think Dropbox are crooks, you need to uninstall their software from every machine you care about, and change every password, key-pair, credit card number, and any other credentials those systems might have ever stored in the file system in a way that's readable by the user accou t the Dropbox app was running with, or for the truly paranoid, any piece of data the system has ever stored or accessed...
Here is my quick and dirty technical solution.
(1) Place a restriction: only allow users who have uploaded a given file to download that file. In essence, keep an "uploaded" flag for each file/user.
(2) Challenge-response to validate local copy of a globally-known file: To continue receiving the benefits of de-dup, don't actually upload an already globally-known file, but perform a challenge-response with the client on the contents of the actual file. This will still leverage most of the benefits of de-dup w.r.t bandwidth savings.
At least Twitter had the sense to phase-in client auth for apps before shutting down 3rd party developers.
I guess the corollary here is, "If you don't own the server, you don't own the file."
Maybe this is why Richard Stallman calls cloud computing "careless computing."
Eric also had another post Three Systemic Problems with Open-Source Hosting Sites a few months later (October 2009) - http://esr.ibiblio.org/?p=1282
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