JavaScript crypto is simply not a protection against that attack model. It is protection against the attack model of the passive eavesdropper. That's all I'm saying. I completely agree with what you say.

Whether you view that attack model as something worth considering depends entirely on context. But it's a valid view for many applications. As long as people don't use it with any expectations of security under active attack models, I'd say that's okay.

> protection against the attack model of the passive eavesdropper

My argument would be that trying to protect against passive attackers with JS adds nothing beyond what SSL already offers.

Which is already required as a matter of course, and already compromises the payload if SSL is broken (again).

Sure, TLS probably covers many use cases. But if protection against overzealous public Wifi spots is your goal, or uploading encrypted files to something like Mega over HTTP, there are still uses that TLS cannot cover.

Again, I am not advocating JavaScript crypto. I'm just putting it in its place.

That's not true. Client side encryption allows the server to never have to touch user-generated content, which makes defense against subpoenas (and certainly blanket wiretapping) more feasible. It doesn't defend against the NSA who want to target a particular individual, but it's better than storing all content encrypted with the same known key, or storing it unencrypted.

Which circles back to the "Javascript is hostile to cryptography" point the article makes; I welcome any expert-audited JS libraries that can accomplish secure file encryption, for example. But even assuming this blocker is overcome, any illusions are shattered by the F5 key.

As pointed out elsewhere in the thread, there are few attacks that allow you to listen in on an SSL connection's content without also allowing you to modify that content - say, with a version that pastebins your keys.

Hence my argument that JS cannot provide anything SSL lacks, plus or minus some wishful thinking. Combine this with the fact that it's impossible to protect against a MITM-modified JS payload (see the "chicken-egg problem" portion), and you have a rather uphill battle here.

My colleagues who do this more than I say that while it's possible, it's rare for an attacker to be able to sniff traffic without being able to interfere with traffic.

Not true, depending somewhat on your attacker, but there are plenty of ways to read emissions from networks which give you no opportunity to modify the traffic.

On the other hand, plenty of people who can modify the traffic exist. Starting with every employee at your ISP and the Amazon picker who shipped your router.

> Waving away a problem via "the bad guys would need to think for more than one second" is not exactly reassuring.

The NSA are well resourced, but I doubt they have much more than a second spare for every internet user on the planet. So speaking as a relatively uninteresting person, I actually would find that somewhat reassuring. If you're a Person Of Interest, that's obviously a very different situation, and you shouldn't use browser-based crypto.

You're right to point out the difference between targeted and general attacks, but you're also misrepresenting the problem. An attack on SSL can take quite awhile to research and implement, but then can be used widely. One would expect the exact same scenario to play out with any javascript crypto library, as it does with all software.

So, yeah - if you rolled your very own library that's unique to this planet for exactly one website, congratulations! You're secure as long as there are no attackers! Doesn't really say anything useful about your security though. Or about the viability of using a fundamentally broken crypto platform to do crypto.