> browser Javascript, which can only be as secure as the server's verified TLS key anyways (and thus doesn't add any security TLS doesn't)
This is not precise. While it does not stop even the most basic active attackers, it does prevent passive logging on the server without changing the served JavaScript, therefore making undetectable mass surveillance on the server harder. The effect is analogous to the difference between TLS with and without forward secrecy: with a similar argument you could conclude ephemeral DH/ECDH does not add any security to TLS, which is not quite the case.
When you stop passive attacks, then attackers will just step up their game to active attacks.
If you want to call something secure, you need to design a threat model that doesn't involve an attacker with one arm tied behind their back. That doesn't serve anyone's interests, except maybe the blackhats'.
> When you stop passive attacks, then attackers will just step up their game to active attacks.
Not always. It often changes the economics of the game. Especially when facing mass surveillance, considering the potential risk of detectability. Just because some attackers can step up their game for some targets, it does not imply they will do the same for all targets.
> If you want to call something secure...
I don't disagree with your point of view about what can or cannot be called "secure". One can debate that definition. However, stopping passive attackers is often NOT useless and it does add value. Security is not a binary proposition.
> Do you know what WebCrypto adds that TLS doesn't? Nothing.
No, consider this: an end-to-end encrypted messaging web page delivered over TLS that stores keys in browser local storage.
A passive attacker that can see the incoming traffic on the server but does not want to alter the JavaScript sent to the clients will never see the messages. I argue this is weak but not useless.
(I would argue all TLS encryption in the browser is, in a sense, opportunistic to a certain extent, since very rarely people look at the address bar, effectively making it unauthenticated.)
"Cryptographically secure" sounds like a vague thing you bring up here. To me, it sounds it is by definition secure (and cryptographically so, if they use cryptography) against passive attackers (and probably nothing else), but I am not really debating abstract and fuzzy definitions here.
My objection is very concrete: to say whatever uses JavaScript cryptography is as secure as TLS is false. Precisely, what it means is for all threat models imaginable, if you can somehow subvert TLS, you can always break the JavaScript crypto, and this is obviously false at least for one scenario I described in the other comment. We could reasonably debate the likelihood of the scenarios, but it's really hard to argue the mathematical equivalence of the two.
This is not precise. While it does not stop even the most basic active attackers, it does prevent passive logging on the server without changing the served JavaScript, therefore making undetectable mass surveillance on the server harder. The effect is analogous to the difference between TLS with and without forward secrecy: with a similar argument you could conclude ephemeral DH/ECDH does not add any security to TLS, which is not quite the case.