4 ms·
Dropbox has a simple technical recourse to prevent de-duplication from being used for file sharing - issue a random challenge (a slightly more sophisticated ver
by shasta 16y ago
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?
- power78 16y agoConsidering 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.
- shasta 16y agoThey 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.
- tlrobinson 16y agoFor 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.
- kragen 16y agoAIM 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. Caveat utilitor.
- crocowhile 16y agocaveat utilitor.
- kragen 16y agoThanks, fixed. My acquaintance with Latin is mostly by way of Spanish, where it is utilisador (well, in normal speech, usuario.)
- deleted 16y ago[deleted]