Dropbox Attempts To Kill Open Source Project

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.

> 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.

[1] http://www.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0...

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.