The only problem here is that because the Javascript is delivered by the server which is supposedly offering privacy from itself, nothing is stopping the developers from simply changing the Javascript and stripping away the encryption through either capturing keys or not applying it in the first place.
Of course, but that's not the threat model we're protecting against. Note that we link to that article (and agree with it!) in the discussion. This isn't just for browser based products. The reference implementation is in JS and intended for packaged HTML5 mobile apps, and we'll follow with implementations in C, Python, Java, etc.
In the browser app scenario, we also declare on that very same page that the threat model is explicitly this: you're an application provider who doesn't want the liability of having a database of plaintext user supplied content. (I.e. protecting a business from its customers' activities.) Not the other way around.
Nonetheless you do have at least some liability because if your server is compromised for long enough for one or more users to sign in, their details could be captured using modified Javascript and used to decrypt their private data. It does provide protection against hackers stealing the whole database in one shot though.
Do you think a dedicated native client would work? Something like a lightweight site-specific browser with Crypton libs. The same way you can appify sites with Chrome.
> Do you think this can be remedied by moving the code out of the web container?
That's what I did in my own design. My protocol's purpose is different from cryptocat's, but the problem that in-browser javascript is untrustworthy is the same.
I designed my protocol so that it needn't be embedded in the browser at all -- or for that matter, piggybacked on HTTP.
This is the problem I have with Lastpass - someone could hack their servers, replace the javascript encryption file to send the decryption password to their server, and get all of your passwords.
you are talking about web access from a public computer I suppose? if you are connecting from your computer then I suppose the decryption happens in the browser extension and you are safe from the scenario you describe, or am I missing something?
I am talking about either situation. Someone could hack their site (angry employee, outside person, etc), and modify the code to send the decryption password to their server. This would work for either situation since the person could push an update out for the browser extension.
I'm sure they are very careful about the security of their system, but they are still one step away from having all of your passwords (a simple extension update, or site javascript modification). If I use a program like keepassx, I know when it's updated, and can verify that it doesn't attempt to communicate with a remote server.
see: http://www.matasano.com/articles/javascript-cryptography/