PGP being "too hard" doesn't mean that browser crypto "has its place".
While I've always enormously respected your opinion, you seem to have a very black/white perspective, aggressively attacking and/or belittling anything that isn't an infallible solution, even if it's a significant improvement for many or most scenarios.
So many password incidents since would have been a complete non-incident with such a solution (or anything similar), so I've always remembered your raw negativity because it wasn't a perfect solution: That because it didn't solve every possible issue, it's better to solve no issues.
What's the point of a fallible solution? The only people who actually need cryptography need infallible solutions. Everyone else can rely on security by obscurity--rot13ing their text will be good enough for them.
What's the point of a fallible solution? The only people who actually need cryptography need infallible solutions.
There is no such thing as an infallible solution. Start with that. When you're talking about actors who are exploiting RNG weaknesses, broaden your horizons a little.
PGP needs a key file. You need to (optionally) enter a passphrase. All someone needs to do is steal your key file and circumvent your passphrase (either of which there are countless mechnanisms to achieve. They aren't trivial, but if we're talking about organizations that are taking advantage of imperfect RNG generators...) and boom, PGP has been rendered a false sense of security over the history of your communications. I mean, if we're talking about rogue actors taking over servers and injecting false script, such a situation is just as viable.
Everything is on a gradient. Any simplification (such as "fallible versus infallible") is just garbage time.
Again, and I realize Ptacek is a bit of a hero around here, his words above question, but I go back to his response to that password thing, which was the moment I understood the disconnect between big security talk, and actual security. When the alternative is (and continues to be) nothing -- which is exactly the case in the password discussion -- discarding options because they don't cover every scenario is absurd. It is grossly destructive, just as it's destructive to discredit PGP because it requires access to a keyfile.
I think the difference is between attacks that are currently well-known, and are automatable (attacks that are, effectively, on the cryptosystem itself)--and attacks that boil down to social-engineering/rubber-hose cryptanalysis (attacks that are, effectively, on you.)
Or, to quote cperciva's talk (https://news.ycombinator.com/item?id=7883707), "the purpose of cryptography is to force the US government to torture you." If a cryptosystem makes torturing you for the required information easier than attacking the cryptosystem itself, the cryptosystem is "strong enough." Any system for which this isn't true isn't doing its job.
EDIT: I remain convinced that it is impossible to have any credible security discussion on HN. Everyone just clucks and spouts rhetoric, the Ptacek fan club in full effect.
No security solution is absolute, but instead every security approach is a "false sense of security" from some perspective, and every solution is steps on a gradient. Anyone who thinks otherwise is simply naive.
Do we eschew SSL rather than give users a "false sense of security"? There are many potential vulnerabilities to SSL, from stealing private keys, to co-opting or compromising root authorities, to more esoteric mathematical vulnerabilities.
Yet we still use SSL. We find a pragmatic medium where we achieve the greatest security possible within realistic confines and restrictions, understanding that there are (and always will be) potential weaknesses, and improve as we go. Simply tut-tuting and rote repeating the "false sense of security" nonsense does literally nothing for anyone. It is pseudo-enlightened babble.
Though I don't agree with all of it, I like this comment. Your SSL example is excellent. In the context of online shopping, SSL may protect your credit card number in transit, but it can't protect you from keystroke loggers that intercept the information before it is ever encrypted. Yet, the industry still uses it and people are consistently compromised by malicious software.
On the other hand, I'm still learning about crypto, so I find these conversations illuminating. Thinking about ways to attack security, or trying to understand how other people approach attacks has given me a far deeper understanding than merely reading about it.
However, that's a personal bias because being critical of what I learn is how I learn. Needless to say, I used to routinely drive teachers crazy...
People tsk-tsk'ing security systems as "that won't be perfect, so it will just give users a false sense of security" has been going on for over 20 years.
Sometimes it's right, sometimes it's not. I remember being yelled at that anti-spam products were stupid because "I can't stand losing even 1 mail out of 10,000!!" (In reality, email is a lossy system that doesn't have four 9's of reliability anyway.) I heard the same thing about all sorts of products from people in both industry and academia only to watch them become significant parts of the IT world.[1] Nerds like black/white answers, especially about areas where they aren't experts. It makes the world much easier to understand.
(And I think it was a stroke of marketing genius for Zimmerman to call his product "Pretty Good Privacy" instead of anything implying perfection.)
So I have sympathy for your position here.
Still -- the JavaScript runtime is a hell of a place to try to encrypt anything. If your only hope is to add an obfuscation layer, call it that explicitly, and expect support to fall off. Adding more pieces to a system can make it less secure.
[1] and I still regret not following up with Dave Mann about his attempts to create a numbering system for attacks because someone else at the table said the AV vendors would never go along
This is a terribly flawed argument because we do not in fact accept "many potential vulnerabilities to SSL". On the contrary, we declare vulnerabilities in SSL that require gigabytes worth of observations for a single target to be "hair on fire" emergencies.
On the flip side, we accept staggeringly obvious flaws in the security model of "server-proof" Javascript crypto --- flaws like, "despite what the server operators claim, they can at any time steal secrets from their users --- flaws that have in the past been exploited by law enforcement. Not only we do accept them, but people like you get pissy when people like the "Ptacek fan club" on this thread point them out.
When SSL gets broken, there are built in mechanisms that generally demonstrate 'something' is being screwed with.
With JS crypto, that goes away - if the JS is shipped over the wire, it can just be silently replaced.
If you're relying on SSL to protect the JS crypto, why bother with the JS crypto in the first place?
When vendors ship some kind of client-side pre-built verification capability (i.e. code that DOES NOT come over the wire), much like the existing SSL stack, things will change dramatically.
While I've always enormously respected your opinion, you seem to have a very black/white perspective, aggressively attacking and/or belittling anything that isn't an infallible solution, even if it's a significant improvement for many or most scenarios.
You don't seem terribly pragmatic in many cases. I realized that long ago in a discussion on passwords and the browser - https://news.ycombinator.com/item?id=2000833
So many password incidents since would have been a complete non-incident with such a solution (or anything similar), so I've always remembered your raw negativity because it wasn't a perfect solution: That because it didn't solve every possible issue, it's better to solve no issues.