"You can never be completely secure" is not a good justification for security theatre.
How exactly would you implement a browser based crypto solution?
That, plus a notification to the user if the signed JS has changed since the last time it was loaded, with SHA hashes of the scripts (and other data) stored directly in the browser in a way not accessible from the DOM.
Since in-page scripts could still on-the-fly rewrite the functions of loaded JS, they would have to be provided read-only by the browser, or there would have to be some kind of out-of-DOM API for working with them.
My hope would be that we'd see a handful of signed libraries provided and reviewed by cryptographers and that they wouldn't change very often because it would be a pain in the ass when they did.
But: I am not a cryptographer or even a qualified security expert. There is probably a good reason not to do it this way.
How is this a justification for JavaScript crypto? It might be a justification for some form of crypto, but if that's the case, why not stick with SSL + server-side encryption?
But then again at some point you will add some logging to client-side code as well, so the point will be moot - you will have to sanitize logs at point of production.
Another thing is that it makes much better messaging - "the encryption key never leaves your machine".
1. Given that either will work for this scenario; and
2. Given that JavaScript has every weakness that the other method has; and
3. Given that JavaScript also has weaknesses that the other method does not have; then
Why would you use JavaScript to solve this problem?
As far security is concerned, the two are equally (in)secure. And client-side crypto still has the advantage that key management is much easier to explain to the user, thus the app is more likely to be used.
Trivially: JavaScript encryption is vulnerable to MITM attacks that SSL is not. The only solution to this is to deliver your JS over SSL, but browsers will complain if you try to mix https and non-https elements in a page, and you might as well serve the whole page over https anyway. If you do that, then you still don't need JavaScript. (As one example; I know there are others but I just came in from the yard and my brain is a little melty right now.)
> As far security is concerned, the two are equally (in)secure.
This is a statement which flies in the face of the recommendations of some very smart people in the security field, some of whom have written extensive posts which have been linked to in this thread.
Even if I didn't (barely) know enough to evaluate your claims on my own, I could conclude that you might be right ... but I wouldn't bet on it.
Look, this subject has been discussed to death and nauseum, including here on HN. There have been extensive essays written about it. If you don't want to believe me, I'm OK with that. Go read their stuff, and see if it makes more sense to you.
If, after reading all of that, you still think you have some new insight in the field that everyone else has overlooked, and you can show why JavaScript is "equally (in)secure" to SSL + server-side encryption, then make your own blog post or essay about it. Make it good and in-depth, link to it from HN, tell everyone about it. I'd be happy to read it.
Otherwise you and I are just going in circles and not getting anywhere.
1. The people maintaining the service turned out to be not trustworthy, and have been harvesting the keys all along.
2. The hackers took control of the server and injected code to harvest the encryption keys for long enough to catch you in the net.
If you look at the relative probabilities of these two events compared to a straight-up data leak, we're looking at orders of magnitude reduction in risk. Most people who did the right thing in the past are in the habit of doing the right things, so you can lean on the host's reputation - we've been doing that for thousands of years. Code injection on the site is much less likely than the data leak, and it is a lot less fruitful for the attacker as he would have to sit there undetected and wait for enough users to punch in their keys.