[celoyd]

No. Assuming it’s correctly implemented, it’s more secure than an identical app that sends the password over SSL to the server.

This is not an innovation in cryptographic theory, but it’s something you don’t usually see in a web app.

[tptacek]

It's something you don't see in web apps because the idea has been roundly rejected. Because in almost every setting where you could possibly implement crypto in JS, you have to run the app over HTTPS anyways, you gain only epsilon more security than if you would without added crypto --- and that's if you get everything right.

[celoyd]

Sure. As this is designed now, HTTPS’s prevention of malicious JS insertion is the big weak point I see. But it’s implicitly asking what you could do if you found ways of getting around that, for example by using client-side caches of the code after a strict initial check.

The real wow for me here is that JS is fast enough to do AES-128 at comfortable chat speed. That’s really suggestive. It’s an epsilon, but it’s a fertile and interesting epsilon.

[tptacek]

Nothing you just said is in the marketing material for this. Instead, it promises to be (paraphrased generously) so secure that not even the operators can tell what people are saying over the service.