[kybernetikos]

> if you have already gone that far, what would you gain by implementing browser based crypto when you have already solved the problem?

This is indeed the point made by Matasano, but I don't think it's valid. Sometimes you want to segment the trust, or maybe your software provider doesn't even want to be in the data storage game. So I might trust one entity to provide me with software to manage my inbox, particularly if I can inspect that software at will, and have seen it pass through a security review, however I might not want to trust them with actually storing the contents of my inbox. In that case, it's nice to be able to encrypt the inbox (and the index, to allow for nice searching) in my browser, and then actually store them on a commodity storage provider (s3 or dropbox). And yes, I'd use modern web standards to give the user control over when a new version was downloaded too.

So, I need to get the software over SSL, and be able to verify within reason that it does what it is supposed to, and then use that trusted software to work with data which I can store on untrusted services.

[rickycook]

Not to mention that it will protect the data at rest in the DB, where storing crypto keys on the server is as bad as plain text because they can just be harvested from wherever you store them... Obviously. Now, if your server is compromised then the attacker can deliver JS to the client, but the client needs to load the page and decrypt their data for this to apply; the attacker can't just wholesale steal all your data.