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.
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.
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.
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'.
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 :-).
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.
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.
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.
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.
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.
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)
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)
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.
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.
edit: ack. just read his twitter feed and it looks like he's out for a week.