I might have misunderstood what you meant, but #1 is invalid.
If I can look at my data any time I want, I just need the key to it. Dropbox just gives me access to the encrypted stream.
Giving access to my data to someone else would therefore just be a question of sharing the key with that person, again, without Dropbox ever having access to this key.
Your killer argument is to me #3. If you don't trust a company, don't do business with it. It all comes down to this.
One of the reasons Dropbox is successful is because anyone can use it. Even your mother. In fact, one of the reasons Drew was originally accepted into the YC program was because his sister was using it when he applied.
"If I can look at my data any time I want, I just need the key to it. Dropbox just gives me access to the encrypted stream."
In order for the data to be encrypted securely, you would need to generate a key on your own computer which Dropbox then uses to perform the encryption. (Tarsnap works this way.)
Forcing Drew's sister (or your mother) to generate a key would be bad for accessibility.
The authentication token can be generated and managed by the software. It would then be protected by the account password, if any (Windows and MacOS X offer this feature).
Doable, and even better, you can make that a 30 € / month corporate option. ;)
If the key file is stored on Dropbox servers, then Dropbox has access to all of your files. This defeats the original purpose (security).
If the key file is not stored on Dropbox servers, then you can't easily use Dropbox across several different computers. This defeats the other purpose (accessibility).
You can store a key escrow on the dropbox server protected by a password or a token. Just a matter of designing something secure and useable. Not easy, but possible.
That doesn't work, Dropbox/your favourite TLA will just wait for you to supply the password and then save the key. Trading off the inconveniences of good crypto (e.g. no web interface) for that little security isn't worth it.
If Dropbox wants to serve the files to a standard browser, it does need the decryption key. If I misunderstood and shin_loa wants to drop the web interface, why "key escrow" - why not directly derive the key from the passphrase?
Isn't one of the major cool things about dropbox that if your computer hard drive gets smashed (and thus the key is destroyed), you can still access your files somewhere else?
We are talking here about Dropbox being simple to use for everyone and you start talking about keeping backups of keys. In safe deposit boxes, no less. Wow.
You don't need to worry about safe deposit boxes. Just don't be upset when you get a letter in the email from a law firm that's noticed some of the music in your dropbox has the same hashes as the music in someone else's dropbox.
The cloud is a scary place. Making it easy to use is not necessarily a good thing.
Funny, when I visit my mom I use her computer for emergency bug fixes and I have my Dropbox installed on her computer. Every now and then I'll see a notification about a document being added to my DB so I checked and it turns out she's saving her documents there cause she "likes the name of the folder".
Tarsnap provides exactly the sort of service you're referring to, where they only store encrypted data and don't have a copy of the key.
I'm a big fan of that architecture, if only because it greatly reduces the payoff of a successful attack. When everything is stored unencrypted (or with a common master key), there's an absolutely massive payoff for the hacker who breaches the security.
> dropbox is many UA ahead in terms of useability and platform interoperability
That's besides the point. Tarsnap is more than useable enough for its target audience, which is why cperciva (rightfully) doesn't give a rat's ass about making it as user-friendly as Dropbox and its ilk.
The two issues are completely separate. Implementation of client-side encryption and user-friendliness are not mutually exclusive. Tarsnap is simply proof that client-side encryption is entirely within the realm of possibility for cloud-based data storage services.
Tahoe-LAFS provides a storage service that is encrypted by the client, but the original uploader of the data is still able to delegate read-only or read-write access to others on a per-file or per-directory basis.
The overall design, including how it is possible to do secure delegation, is fairly well described in a paper from the 'Storage Security and Survivability 2008' workshop - http://tahoe-lafs.org/~zooko/lafs.pdf
Resuming downloads, large downloads (can't decrypt and stream to the disk as it comes in), and handling any future changes to the encryption algorithm (say, asymmetric instead of symmetric)? How about that, as it's in JS / attached to the DOM, an injected script has access to it? Or the several gigabytes of memory it would take to store and decrypt a gigabyte download? It'd also likely end up being an even bigger battery drain than Flash.
It's a definite problem. It won't be for long, I think, but it most certainly is now.
Downloading client-side generated files is possible using data-uri. However these are usually small; it would be very difficult to store a 1GB file in memory (in javascript) while you decrypted it and I doubt data-uris that large work across different browsers.
If I can look at my data any time I want, I just need the key to it. Dropbox just gives me access to the encrypted stream.
Giving access to my data to someone else would therefore just be a question of sharing the key with that person, again, without Dropbox ever having access to this key.
Your killer argument is to me #3. If you don't trust a company, don't do business with it. It all comes down to this.