this is arash from dropbox. a similar thing happened to us a couple years ago and mattcutts helped resolve it pretty quickly (https://twitter.com/mattcutts). I would try to reach out to him ASAP.
edit: ack. just read his twitter feed and it looks like he's out for a week.
iOS does it that way. My iPod touch always forgets date and time when it runs out of battery. After restart you can't do anything in the App Store or on https websites before you've set the correct date (it defaults to 1970 which is when the iPod was first introduced I believe).
hmmm, I think it's fairly common practice amongst similar software (i.e. firefox, chrome, etc.) to use system time as a signal that you may be connecting to a server that has an outdated SSL certificate. while it's not perfect, it's a good first order security precaution to take (in addition to verifying the CA) to ensure you are talking to who you think you are.
Certificate validation for 802.1x networks relies on this, with the effect that you sometimes can't get an internet connection without fixing your clock.
If you know you're on a network -- and Dropbox does -- then I'd fetch the time from a time server somewhere, perhaps Dropbox itself, or time.nist.gov. Of course, then you're at the mercy of the user's hosts file, I suppose.
If the time is just used to check for certificate expiration, maybe nobody considers it worth worrying about. Which I guess is fine as far as it goes... but the other day I couldn't get Dropbox to do its thing when my clock was only a few hours off. It didn't seem likely that an SSL date check was involved in that case.
Well. Chrome and Firefox won't let you log in to GMail, for instance. IE at least allows you to continue if you really want.
It's a common thing on school/university computers, where for various reasons, system time is always wrong and it requires Administrator privilenges to change it (I can't understand why).
No DMCA takedown requests were sent to GitHub. We simply nicely asked the author of Dropship to take down the link and he fully understood our position and took the code down.
The only erroneous use of DMCA was when we attempted to take down the link on Dropbox, which was an entirely honest mistake.
"He requested that I not only remove the archive from Dropbox but delete my posts on Hacker News, which at that point included the fake DMCA takedown."
What you tried to do there is censor and resorted to fake legal repercussions. You can brush it aside saying that it was a mistake but it is still uncool for a corporation to do that to an individual.
I forked Dropship, just in case, and my GitHub repo of it was deleted. I was not notified of this. NOT happy with DropBox, and ESPECIALLY not happy with GitHub.
Since the original dropship repo mentioned on razorfast is still available (and has a pull request waiting), and the comment didn't really contain any context, I wouldn't give it much weight yet.
This is Arash from Dropbox. We removed the ability to share the project source code because it enables communications with our servers in a manner that is a violation of our Terms of Service. By our TOS, we reserve the right to terminate the account of users in this case.
However, we chose to remove access to the file instead of terminating the account of the user.
We recently built a tool that allows us to ban links across the sytem (as of a few weeks ago) and I wasn't aware that a DMCA takedown email would be auto-generated and sent. This was a tool built for our support team and I'd never personally used it. That said, we feel strongly that the code is a violation of our TOS and don't believe the removal of the content from our site is censorship.
I'd also like to clarify that nobody's accounts were threatened: in every case my phrasing was as follows: 'I hope you can understand our position and can agree to remove the Dropship code'.
Of course you're well within your rights to remove the content from Dropbox itself as it violates your TOS - I think most people are objecting not to that, but to you requesting that copies of the source be removed from third party sites like github.
The attempt to quash knowledge is the offensive part - not the enforcing of your TOS. At least that's my 2 cents.
I agree that the removal of the code from your site is not censorship, but I think that misses the point. Asking for the code to be removed from GitHub is very different than removing it from the Dropbox website.
Even so, my main issue is not whether it violates the terms of service or not -- let's just say using it does violate those terms -- the question is whether taking it down is the right thing to do, for Dropbox and its users. In this case, I don't think it is: the issue here is not the code itself (which does not appear to be malicious) but how that code accomplishes its purpose. That method is not something you can block with requests to take down source code.
Basically: this may violate the terms of service, but maybe the real issue here is that if those terms are blocking this, maybe those terms are wrong.
I agree that the removal of the code from your site is not censorship...
Disagree. Of course it's censorship. It may be justifiable, and the content in question may be against Dropbox's ToS, but it's still censorship: Dropbox is removing access to content it does not like.
"We have received a notification under the Digital Millennium Copyright Act (“DMCA”) from Dropbox that the following material is claimed to be infringing."
Doesn't this seem to imply that Dropbox is the owner of the code and is both the DCMA submitter as well as the company executing upon it?
An automated system would still require a company name that is requesting the DCMA to be entered, or your automated system is implying that all DCMA requests are coming from Dropbox. Something isn't right about this...
Accidents happen, but you sure do not want your startup to have an accident involving a DMCA takedown notice sent in error. There are penalties for doing such. It is generally best to vet this stuff with a lawyer.
I find it hard to believe that you did not anticipate exactly this happening when designing (a) an online file backup service, (b) a "de"-duplication algorithm. That said, you should have planned for exactly this a long time ago, whether by the means DropShip used, or any of several other potential file sharing hacks. I think a lot of us here are disappointed with how your actions reflect that planning, or lack thereof.
I agree. I actually proposed this idea a while back but never went through with the implementation. I hope Dropbox turns a blind eye to this because I think its fair use of Dropbox. Instead of someone sending you the file and then you adding it to Dropbox manually, you can just send the hash for the file and receive without P2P. This is where the world of online storage might head anyways.
"We removed the ability to share the project source code because it enables communications with our servers in a manner that is a violation of our Terms of Service."
Arash, you're confusing the software and its potential uses as if they were the same thing, which is standard DMCA brain damage. It's the FUTURE communication with the servers that COULD violate the terms via such communications, IF it actually happens because of an unknown person (possibly not the hoster) using the software at some (unspecified) later time. If that TOS-violating communication actually HAPPENS then you can gleefully shutter HIS account. You don't get to ban the software itself, if the hoster has permission (via MIT license) to host the file. Illegal sharing of copyrighted files is what's prohibited, and that is what the "automatic DMCA takedown" suggests---to wit, that your banning-files-by-hash system is designed to take down copyrighted files in response to DMCA takedown notices. If it was meant to ban files you don't like, you would have had a clue that it would send an erroneous DMCA message about the file.
So it's obvious you just wanted to ban the file. Can you really cite the TOS language that says hosting software that COULD be used for TOS-violating communications with Dropbox, is also a violation of the TOS?
I also think it would be interesting for readers of this forum to see whether or not you've already quietly changed your TOS to cover this case (or will soon do so.)
If I may ask something quite specific: how do you justify _automated_ transmission of DMCA take-down requests? Shouldn't a human being be reviewing them first to prevent this sort of thing? Do you guys care? I mean, who's idea was that? As a customer and a developer, I'd really like to know.
We recently built a tool that allows us to ban links across the sytem (as of a few weeks ago) and I wasn't aware that the email auto-generated and sent a DMCA takedown email. This was a tool built for our support team and I'd never personally used it.
The form letter the OP got wasn't a DMCA takedown notice. The letter stated that a takedown notice had been received. That was untrue (the file was being removed for a different reason) but since no takedown notice was sent it certainly isn't perjury.
I personally feel that Dropbox removing files from someone's account is completely wrong, regardless of your ToS. Your service is there to backup files. When you delete references to files from someone else's accounts, you're violating the trust that people put in your service.
This contradicts your earlier statement -- that you removed the file from the person's account.
I'm on your side here, but you need to be as transparent as possible here. Are you also saying that your system automatically generates emails that make false claims about having received a DMCA takedown notice?
This whole situation is pretty revealing about Dropbox. If hosting software that COULD be used to violate the TOS were also a violation of the TOS, and if Dropbox had been in the practice of banning such files, then 2 outcomes would have obtained:
1. The system for banning files would not send out copyright infringement notices automatically. It would be set up for banning things like source code that could be used to violate the TOS.
2. Someone on the support team you claim the system was designed for, would have done the ban, instead of you having to come in and implement "higher-level business logic" by using the ban system for something besides copyright violations.
Despite that, I'm reading your terms of service, and it sounds to me like you reserve the right to terminate service (which sounds like it would include deleting files) with or without notice, if you deem there has been a sufficiently egregious violation of your ToS.
I don't understand why you would bother? If they still had the file, wouldn't they be quite able to post it elsewhere? Why the censorship? I'm not comfortable in the knowledge that Dropbox can willy nilly refuse to allow me to share files on a case by case basis.
I can understand dropbox not allowing you to publicly share files on a case by case basis, or else I could simply put illegal content in my public folder and send out the link.
I understand it a little less if you are say sharing folders between friends.
And I wouldn't like it at all if they deleted something from my dropbox, but it seems we aren't there yet.
Pimp slapping developers works well for Facebook and Apple so why you miss out on all that fun, right? Next time don't take the personal touch and email them personally. Instead wait for their app to gain a following then suddenly ban them and let them cry like bitches. Then send them a form letter saying their account was banned for violating the new ToS you haven't even posted yet, and by the way this communication is considered a national security secret so they can't talk about it to anyone including their spouse. That's big pimping. Then sign the email with "You've been Dropboxed, bitch!" That'd be your tag line. You're my hero.
DMCA notices aren't a joke that you can idly send to anyone who annoys you. You are legally liable for them, and telling a judge "Oh, we just send them automatically without checking" is not going to help your case.
To razorfast guy:
Can you look at the SMTP headers of the DMCA takedown to see if they're coming from a desktop e-mail client or indeed some sort of auto-mailer? Might give a clue if the e-mail was indeed "auto-generated" or not
Congratulations on becoming a large enough company to start getting hated on. The web recently started piling it on you guys which I think is something you should take pride in.
While you guys have (and always have had) a technically exploitable issue with de-dupe/hashing (which I think is a feature) now that you're the big kid on the block I hate to see you forced to close it.
It was a nice feature, but it isn't going to stand up to random hackers trying to make a name for themselves with a public release of relatively simple code and blog post about how they used/abused your service. Good luck!
And I definitely think it's time to change your demeanor from your local friendly startup to your impersonal corporate entity. At this point you're just going to be stirring up bees.
Best thing you can do now: offer the dropship guy a job.
He knows your product well enough to "break" it and he has the motivation to create something strong enough that it is causing a fuss. Learn from Geohot. Don't scare away people who want to play with and extend your product.
I'm sure I'm not alone in not quite getting how mere possession of software which enables the violation of your TOS is itself a violation of your TOS. Can you clarify that?
You _accidentally_ sent a DMCA notice?! That might be worse than sending an erroneous one. You're technically under penalty of perjury for false DMCA notices.
It is a shame your developers allowed you to commit perjury in such an automated fashion.
With all due respect to you and your company (and while I fully support your right to invoke your TOS to take down content within your own service) I'd actually love to see one of the people you DMCA'd slam you on that aspect of this situation legally if for no other reason than to make other companies think twice (or three times) before they improperly invoke the DMCA to scare people into submission.
There's another comment that has a pretty good theory -- the form the tool uses probably has a field that asks you to fill in who requested the file(s) be removed.
(The dropbox guy already has said he used an internal tool developed to remove files, without realizing that it would send this DMCA notice notice.)
at the expense of conveniences like web access, document previewing, simple sharing, etc. - sure :-). if your answer to the web access concern is: derive the key from the password, who's to say we wouldn't store the key and later use it to decrypt your data?
web access non-withstanding, you'd be making a leap of faith to believe that the client is 100% trustworthy and that encryption is actually happening. at some point you have to make a decision as to whether or not you trust the entity (dropbox, google, or anybody else). if you don't, you should use something like truecrypt between you and the service.
all arguments made against dropbox apply to your gmail attachments, gmail mail, google docs, etc.
> make a decision as to whether or not you trust the entity
If I don't trust the entity, how could I be installing any of its software on my machines? I have to trust what I am told if I am to use the software for its intended purpose.
If Dropbox claims what Miguel has quoted in his post, and then it happens that claims are (basically) not true, then it raises the question of integrity, i.e. what other assumptions that I have made were off? Say, that your .sys is not doubling as a key logger or your software is not scanning my disks at government's request, etc.
If you publish security spec and adhere to it in a way that allows independent verification of its implementation, then - yes, you will convince that what was claimed is true.
Perhaps, the easier route for you would be to just drop the whole "encrypted" angle and simply state that you provide reasonable protection of files while in transit and in your possession. That would satisfy 99.9% of real users and it will not rub cryptographic pedants the wrong way. The issue at hand is not that you don't encrypt properly, but that you over-promised, and over-promised in a very sensitive area.
(correction) "over-promised" = "implied more than what was said", i.e. what Miguel referred to as "wishy-washy statement".
hi there, arash from dropbox here. all data is (as we state in the referenced help article) encrypted before it's stored on the backend.
all data on dropbox can be made shareable and is web viewable. as a consequence, we do need the ability to decrypt in the cloud.
re. employee access to files - there are controls to prevent this. for example, even drew (founder/CEO), doesn't have physical access to our storage servers anymore.
for very sensitive data, there's always the option to use truecrypt (we even offer this as a recommendation in our security documentation: https://www.dropbox.com/terms#security)
What's the ETA for detailed security architecture whitepaper?
"(A)ll data is encrypted before it's stored on the backend" statement is completely worthless unless (at the very least) you also describe how the keys are generated and managed.
Technically speaking, whats the point of encrypting data on the backend if you can decrypt it? This strikes me as a waste of computations for no real gain.
Someone in an Amazon datacenter that gets ahold of a random backup tape/hard drive can't read it. I'm not sure if Dropbox is hosted on EC2, but if not, it means that Amazon couldn't read the data at all. (If it's hosted on EC2, Amazon could probably get ahold of the key if they really wanted to)
Going off of that assumption, what if the decryption keys were also stored in an Amazon data center? It is then possible for Amazon read the contents of these files.
I'd like to hear from Dropbox how this works instead of speculation.
we take as firm as stance as possible on user privacy (google faces and fights these very issues)
the government needs to comply with the provisions of the electronic communications privacy act by obtaining a warrant supported by probable cause (or in some cases a court order from a judge). these safeguards protect user privacy, even when the government is involved.
Assuming you store files as a combination of a hash digest function as a key and file data as a value; what controls do you have in place to handle situations where law enforcement discovers some sort of 'illegal' file data on one users account subsequently requests details on users with hash digests that match the data in that file?
Due to Dropbox's implementation of de-duplication of identical files, any user can (in theory) determine whether (but not who) some other user is storing the same file. If you upload a file that any other user has aleady uploaded, your file transfer will be nearly instantaneous.
See: "How Dropbox sacrifices user privacy for cost savings"
de-duplication doesn't make users any more vulnerable to intrusive government actions. today, a government agency could ask any online service to provide the names of all users who have a particular file, whether or not the service employs de-duplication. and in that case, the government would also need to support its request with a warrant or court order. the rules that provide a check against unwarranted government snooping apply to online services equally, regardless of their backend architecture.
To parse that, are you saying that under such a circumstance, a government agency would have to provide the names of each person they suspect have that particular file? Or could they demand the names of all users that have a particular digest of that file?
basically, the government could try to make that type of request independent of backend implementation. what protects users against such an obtrusive action (effectively violating every user's privacy in search of the bad guys) are the provisions of the electronic communications privacy act.
A point of feedback: I know it is illegal for you to inform users if you have received a warrant for their data, but you should devise a method where a flag such as 'third party access' is set in the user preference panel to let them know that somebody has accessed the data
architect this flag as part of any 'admin' access and describe it on your website - users would feel better about it
if the feds know your system is designed in a way that you can't help but to inform users that data has been accessed, it might dissuade them from approaching you with warrants in the first place
I poured through the laws and talked to a lawyer about it, though this was years ago. It is illegal to inform a user directly in any way, they can't make you re-architect your system to provide them a backdoor unknown to the user.
also the wording can not mention 'warrant' or 'fbi' so it has to be something like 'third party access'
I have been meaning to do this as a 'project' with full legal advice etc. and suggest it to google, other cloud providers
Wait, Truecrypt? Haven't I seen warnings in the Truecrypt docs against keeping several copies of the same file? And doesn't Dropbox backup every little change? You might want to add a note on your security page that storing encrypted files on a service with automated backups, like Dropbox, may pose security risks.
Really? That'd be amazingly broken - consider any of the append-only log-structured filesystems currently in vogue on Linux, which are very likely to preserve multiple versions of any file being stored (right?). Not to mention normal backups.
Everything on your website that in any way addresses "Dropbox's security" should make absolutely clear the extent to which users can expect their data to be "secure".
In Dropbox's case, users can expect the following:
- Data is probably secure from sniffers
That's it.
It matters little whether "Drew has physical access to our storage servers anymore". Your code obviously has easy access to the keys used to encrypt and decrypt the data. This means all of the following scenarios are possible:
- User's data is obtained via the government (users
aren't necessarily even informed about this)
- User's data is obtained by rouge employee (potentially
leaking to _anyone_ or _anything_)
- User's data is obtained by hacker (again, implies ZERO
assurance of data security).
So don't flash around "AES this or that" without making it absolutely clear to the average user that what you are doing is the equivalent of storing their data in a shed guarded by a lock that can be accessed by anyone who can find (or demand) the key that you've hidden under a rock somewhere.
you're right in that all these things are theoretically possible in a system where the encryption key is not stored client-side. I don't know of many services that advertise every way in which their systems could be compromised. I think you'd be hard pressed to find a company doing this. in the case of google - is there a document explaining all the places your email could end up?
we believe that what we advertise is in our userbase's best interest. in theory, we could generate a lengthy document attempting to explain every possible way dropbox could be compromised. but in practice, discussing these extremely unlikely theoretical vulnerabilities would generate undue fear. as an ironic sidenote: this thread was spawned by an attempt we made to clarify our handling of court orders (see: http://www.businessinsider.com/dropbox-updates-security-term... )
I say "undue fear" for a couple reasons. first and foremost because we are vigilant about making sure that user data is never compromised. our reputation would be permanently damaged if dropbox is compromised. we have a lot of smart, security conscious people making sure data in dropbox is safe.
we're also listening to feedback we've been hearing from the community on things we can do to improve security. a couple concrete examples: we're working on better protecting the authentication token (config.db) so that gaining access to a dropbox account on a compromised machine is much more difficult. similarly we're working on a performant way to transmit file metadata over SSL on the mobile apps.
secondly, we believe that storing data in dropbox is far more safe than the alternatives. we've designed dropbox to protect user data against threats of all kinds, but we've focused the most on helping users avoid the most common threats to their data: not having any backups at all, not having current backups, accidentally deleting files, losing hours of work, leaving files on the wrong computer, losing a USB drive with sensitive info, protecting from curious snoopers on the dorm network, etc.
for all the talk of security issues in the last few weeks, we're not aware of anybody having been affected by these theoretical vulnerabilities. on the flip side, we have (literally) saved thousands of college kids from losing their theses :-).
Arash good security is about mitigating theoretical risks before they become actual.
I am most disappointed in Dropbox because you had made statements like all our data is AES encrypted and our staff do not have access to your data. These are clearly incomplete for the former and are plainly not true for the latter. They are misleading and un-ethical in that they have assisted you in gaining you all these customers. As stated above you should clearly stop using security as selling point and only state you provide security in transit (https) or actually put in place technical measures to make those statements true.
Personally I will no longer be recommending Dropbox and will instead recommend your competitors including changing my answers on Quora: http://www.quora.com/Dropbox?q=dropbox
Really, dropbox is probably more secure than most complainers' computers; but when you say things like
- All transmission of file data occurs over an encrypted channel (SSL).
- All files stored on Dropbox servers are encrypted (AES-256)
and this turns out to mean "file metadata may not be encrypted" and "all files stored on Dropbox servers are encrypted with the same key (AES-256)"... well, people are going to call "snake oil".
This is a discussion of the consistency of advertised security claims with disclosures about availability of data to government subpoena.
In that context, statements like "we believe that what we advertise is in our userbase's best interest" make my ears prick up. I'm not a crypto expert, but this sort of thing does not seem like a straightforward response to the OP.
The point is that these are the kinds of claims you should be making in the marketing. Users are smart enough to understand "We are vigilant about making sure that user data is never compromised". You shouldn't be trying to bamboozle them with official-sounding acronyms like AES - that when it comes down to it, mean little.
There are classes of users who will consider it snake oil if well-known encryption algorithm names aren't used, because it implies home-grown encryption.
But you are not Google, and I expect you to have higher standards. Don't take Google as the reference data point, it's a fairly low one as far as reference data points go.
On a related note, Dropbox is not the only company that advertises security even though what really is offered is kind-of-security. See Backblaze, for example — yes, the data is (supposedly) encrypted using my private key, which (supposedly) only stays on my machine, but I can't be sure because it isn't auditable, and to do a restore I have to supply my private key to the Backblaze website, instead of using a local decryption tool. Not good.
>we're not aware of anybody having been affected by these theoretical vulnerabilities. on the flip side, we have (literally) saved thousands of college kids from losing their theses
I like the idea of what your service does, but this statement just advertizes the success of one feature to back up the failings of another.
If you just want to offer file storage, just set up an http-only svn server and be done with it.
If you want to offer proper encryption, do so, or don't say that you do.
hi there,
arash from dropbox here. all data is (as we state in the referenced help article) encrypted before it's stored on the backend. I'm not sure why you're concluding that de-duplication implies lack of encryption. the de-duplication occurs prior to encryption.
all data on dropbox can be made shareable and is web viewable. as a consequence, we do need the ability to decrypt in the cloud.
re. employee access to files - there are controls to prevent this. for example, even drew (founder/CEO), doesn't have physical access to our storage servers anymore.
for very sensitive data, there's always the option to use truecrypt (we even offer this as a recommendation in our security documentation: https://www.dropbox.com/terms#security)
I love your product but your encryption is pretty useless and y'all must know it.
It only protects my data if your S3 account is compromised. There is a much greater chance that your web frontend, servers or client are compromised (either by an external or internal attacker) and then my files are easily accessed and decrypted.
It is like naive programmers who store user passwords with 'government level encryption' instead of correctly salting and hashing them, thus having to put encryption key in the source code
esteemed mr. arash, perhaps it might be a good idea for someone within dropbox to write a blog post answering common security-related concerns.
having a security sub-section in TOS is great, but it might be buried in google searches. anyways, it seems like this is a common concern amongst bloggers as you guys are exponentially rising in popularity, so some good PR on that front might be needed.
Dedupe and cleartext metadata as stated in the article I referenced, would allow for the following possibilities:
If an attacker could figure out the hash method used by dropbox on the files and intercept a few hashes from a victim, it's plausible that an attacker could trick the service into thinking that he had uploaded the files on his own account, allowing access to the victim's files.
Could you explain what would need to be done to protect against this attack method?
cryptographic signatures of files are never transmitted over plaintext. yes, the current incarnation of the mobile apps don't encrypt the names of the files but we are working on a fix for this as soon as we can adequately improve the SSL performance of our mobile apps.
Hi all, Arash from Dropbox here. We understand the concern that the government could try to guess whether a particular file has been uploaded to Dropbox based on processing times and then request that Dropbox identify a user who has access to that file. However, to seek user content information, the government needs to comply with the provisions of the Electronic Communications Privacy Act by obtaining a warrant supported by probable cause (or in some cases a court order from a judge). Those safeguards protect user privacy. De-duplication does not make users any more vulnerable to intrusive government actions. Today, a government agency could ask any online service to provide the names of all users who have a particular file, whether or not the service employs de-duplication. And in that case, the government would also need to support its request with a warrant or court order. The rules that provide a check against unwarranted government snooping apply to online services equally, regardless of their back-end architecture.
Granted, but the point of the article is that other services which do not have this ability are not vulnerable to said orders, they cannot do what they do not have the ability to do.
Still, this lets the government probe (as an ordinary user) to know that at least one prior user has a contraband file, without any warrant. That could be the thread of probable cause they use to take the next steps.
If you don't mind my asking, what is the percentage savings achieved by de-duplication across all of Dropbox? Some others here have wondered if it was premature optimization.
It wasn't a premature optimization. It was both a better experience for the user (saves bw/reuploads for the user) and was simpler to implement (can keep things in one global bucket) given we didn't want things like renames to trigger reuploads and had to use checksums as a result.
But you could prevent reuploads with per-user de-duplication, while avoiding the privacy issue of cross-user de-duplication.
I could see why this would be more work to implement (you have to key on user+contenthash), but it would still be interesting to know how much Dropbox and its users actually benefit from cross-user de-duplication.
I have a hard time understanding this line of argument.
Per-user deduplication will mean, I need not upload the same file twice into my own account? What's the use of this?
I keep some of my 'paid for' software installables backed up in my Dropbox, and they tot up to ~1.5 GB (the Humble Indie Bundle games). When I started the upload however, it took maybe 5 seconds because of cross-user deduplication, and I am super grateful to them for this feature.
I imagine this feature saves users tons of bandwidth, as most of the people I know use Dropbox for backing up important software, rare music and videos.
> I have a hard time understanding this line of argument.
It's not a line of argument. It's a line of inquiry. You've given anecdotal evidence that cross-user deduplication benefits you and people you know, but what about some actual numbers from Dropbox?
Producing actual numbers -- "eg cross-user deduplication saves our users 30% of their upload time and bandwidth, on average" -- seems like a great way for Dropbox to counter this issue.
> I imagine this feature saves users tons of bandwidth, as most of the people I know use Dropbox for backing up important software, rare music and videos.
We don't have to imagine! Let there be numbers!
Also -- "rare" music and videos that everyone's uploading duplicates of? ;)
To the point that it does not make users any more vulnerable to intrusive government actions, as you put it -- in practice, that's not going to be true.
Let's say right now Agent Bob or RIAA layer Cindy decides they want to know everyone in the country who has a copy of a file. There's no practical way for them to do that. But now, they can upload target.iso to dropbox, see that it uploads instantly, and all they have to do is get a court order to compel Dropbox to tell them all the other users who have that file.
Every user that has that file is now exposed. Dropbox is now a single point of failure for every user's privacy, and vulnerable to attacks from any legal court order -- and we've seen what can happen with the abuse of prosecutorial and judicial power. Copyright infringement's the obvious case, but when you start to consider how this ability to fish for files could be abused, and how tempting it'll be for people try to abuse it, it seems more serious than I think you're considering.
Has your organisation considered offering "no de-duplication" to paying subscribers?
Personally I have no qualms with it, but I know some might, and they could be willing to pay for it.
edit: ack. just read his twitter feed and it looks like he's out for a week.