The problem is not the site, but the network in the middle. On-path attackers typically don't care about which site they MITM in order to inject javascript e.g. to show ads, insert tracking tokens or hijack the browser for other purposes. The site is the vector, not the target.
Sounds like a great argument for keeping js disabled in my browser. Because "httpS://" does nothing whatever to sanitize the js that it delivers. And one perfectly legit site may pull in js from two dozen or more different servers. Zero of which are magically guaranteed to only deliver benevolent code.
Vs. `traceroute` suggests that would-be on-path attackers are up against a vastly smaller attack surface.
> Sounds like a great argument for keeping js disabled in my browser. Because "httpS://" does nothing whatever to sanitize the js that it delivers. And one perfectly legit site may pull in js from two dozen or more different servers. Zero of which are magically guaranteed to only deliver benevolent code.
See:
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Yes, great. When used. And maintained. All the way down the foo.js => bar.js => baz.js => etc.js chain.
Might you know which js blockers support "only with 'integrity='" conditionals?
Ironically, this Google page itself fails to work without Javascript enabled!
Ironically? For maximum monetization, Google needs js, to turn "your" web browser into their web browser. https://news.ycombinator.com/item?id=42747092
most sites pull blindly pull and exec JS from their vendors, especially adds / tracking. you don't need a MITM attack on the site, plenty of supply chain issues for which https does nothing.