Miguel de Icaza noticed that Dropbox’s new security terms of service allows it to decrypt your stored files for law enforcement; but Dropbox has always claimed that it did not store the keys necessary to do this. This has been used as both a selling point (“we keep your files so safe, we can’t access them”) and an excuse (“don’t ask us for help if you lose your crypto keys, we don’t store them”), but it was, apparently, a lie. De Icaza worries that a company that lies about its crypto and security policy may not be trustworthy when it comes to files containing sensitive information:
If companies with a very strict set of security policies and procedures like Google have had problems with employees that abused their privileges, one has to wonder what can happen at a startup like Dropbox where the security perimeter and the policies are likely going to be orders of magnitude laxer.
Dropbox needs to come clear about what privacy do they actually offer in their product. Not only from the government, but from their own employees that could be bribed, blackmailed, making some money on the side or are just plain horny.
Dropbox needs to recruit a neutral third-party to vouch for their security procedures and their security stack that surrounds users’ files and privacy. If they are not up to their own marketed statements, they need to clearly specify where their service falls short and what are the potential security breaches that
Unless Dropbox can prove that algorithmically they can protect your keys and only you can get access to your files, they need to revisit their public statements and explicitly state that Dropbox storage should be considered semi-public and not try to sell us snake oil.
Update: Arash Ferdowsi, CTO of Dropbox, wrote to me to clarify Dropbox’s present and historical privacy policy:
first, I’d like to clarify what our intent was in how we represented privacy in our TOS. in our help article we stated “Dropbox employees aren’t able to access user files” we didn’t intend to mislead anybody with this statement – we prevent this via access controls on our backend as well as strict policy prohibitions. we don’t feel this statement implies anything about who holds the encryption keys or what mechanisms prevent access to the data.
that said, it’s become very clear to us that the statement wasn’t explicit enough about what the barriers to access are. consequently, we’ve updated our help article and security overview to be explicit about this.
secondly, I’d like to clarify that we’ve never stated we don’t have access to encryption keys. we’ve made quite a few posts in our public forums over the years about this very fact and we are quite open with our community: 1, 2, 3.
(via JWZ)