|
|
|
|
|
by runningdogx
5514 days ago
|
|
That would prevent de-duplication in the non-shared case, which as I understand it is important to Dropbox for increasing storage efficiency. I suspect that is the primary reason why they don't have an option to "store encryption key locally only" in the client. The excuse that users expect to be able to share and access files on the web can be overcome with a big scary warning indicating that is not possible when using client-side-only encryption keys. Dropbox advocates TrueCrypt in one breath, but refuses to integrate client-only encryption keys in the client with the next breath. Obviously they know what we all know: TrueCrypt presents a poor UX for non-technical users, and so most people won't use it even if it's recommended. Then DropBox gets to be the hero for advocating TrueCrypt while they get de-dup efficiency because they know few people actually bother using TrueCrypt. Any transfer of keys to dropbox, even temporally, means your data on dropbox should be considered insecure. You have no way to know what's going on on the dropbox side. The same issue arises for CAs that let customers generate SSL keys within a web interface, to avoid the nuisance of having to generate a key/cert/csr themselves and uploading that. It doesn't matter if the CA promises never to store the private key. It's insecure and it's bad practice. |
|