You're getting (maybe unfairly) downvoted because the popular opinion in security is that client-side JavaScript anything is worthless in terms of security. Since it's not authenticated in any way by the browser, any successful MITM attack on a connection can feed malicious JavaScript which would request the user's key. Or, a malicious add-on in the browser could do the same. Or, possibly, an XSRF.
I'm somewhat skeptical of this because I think that such attacks can be successfully mounted against most other web-related activities. DNS poisoning and self-signed SSL would be enough to phish many people's bank login credentials, and a lot of attacks don't even go to that much trouble.
But, anyway, client-side JavaScript for security purposes is supposed to be verboten.
The number of people who will find an attack in the middle of a ton of Javascript is much smaller than the number of people who properly handle a certificate warning.
Thanks for the information. I didn't realize that it is verboten. I presumed it was for efficiency purposes and implementation hassles. I do realize that there are plenty of attack vectors the moment you start trusting JS from a remote website.
It was just a proof-of-concept of how Dropbox can still allow you to view files in your browser, but perhaps flash a big warning saying that this is a lot weaker security-wise than locally running your dropbox client. That way they cater to people who are willing to forego a little security for convenience.
I'm somewhat skeptical of this because I think that such attacks can be successfully mounted against most other web-related activities. DNS poisoning and self-signed SSL would be enough to phish many people's bank login credentials, and a lot of attacks don't even go to that much trouble.
But, anyway, client-side JavaScript for security purposes is supposed to be verboten.