3 ms·

You are precisely missing my point here - the attacker doesn't merely have the ability to modify the visual content on the page, but to inject arbitrary content

You are precisely missing my point here - the attacker doesn't merely have the ability to modify the visual content on the page, but to inject arbitrary content of their choice into the response body, including JS scripts / WASM programs. This isn't some pedantic complaint about data integrity, it's a warning about this decision (allowing for HTTP rather than forcing HTTPS with only modern TLS versions supported) results in a possible vector for malicious remote code execution. Sure, they will be in a browser sandbox, but that's more than enough of a starting point to perform e.g. CSRF attacks, or malicious redirects to exploit kits or phishing pages, or set up a proxy using your connection to do other naughty things... to say nothing of sandbox escapes, cryptominers, or any other manner of JS / WASM nasties.

anal_reactor 2y ago
The problem is, you're focusing on theoretical dangers that have like 0,0000000000000000001% chance of happening, instead of assessing what risks are actually probable. Basically the attitude "I don't allow my child to be out alone because there was a kidnapping case ten years ago on the other side of the country".
- anonym29 2y ago
  I don't believe you're accurately quantifying the risk here. Remember, the barrier to pulling off an attack like this is extraordinarily low, and the list of contexts where it can potentially occur is considerable: potentialy any public wifi network without client isolation, having a naughty neighbor with a yagi antenna and too much free time, ISP/upstream routing entities being shady, or themselves being compromised to serve malware (several ISPs actually performed this exaxt technique to inject ads in the pages their customers were visiting years ago). Recall that my call to action is adding HTTPS support, and you're arguing against that. What's the counterargument against adding HTTPS? I've yet to hear a reasonable justification for not supporting it. It's incredibly easy, it's free, and it takes less than 3 minutes with Let's Encrypt / certbot.

anal_reactor 2y ago

The problem is, you're focusing on theoretical dangers that have like 0,0000000000000000001% chance of happening, instead of assessing what risks are actually probable. Basically the attitude "I don't allow my child to be out alone because there was a kidnapping case ten years ago on the other side of the country".

anonym29 2y ago
I don't believe you're accurately quantifying the risk here. Remember, the barrier to pulling off an attack like this is extraordinarily low, and the list of contexts where it can potentially occur is considerable: potentialy any public wifi network without client isolation, having a naughty neighbor with a yagi antenna and too much free time, ISP/upstream routing entities being shady, or themselves being compromised to serve malware (several ISPs actually performed this exaxt technique to inject ads in the pages their customers were visiting years ago). Recall that my call to action is adding HTTPS support, and you're arguing against that. What's the counterargument against adding HTTPS? I've yet to hear a reasonable justification for not supporting it. It's incredibly easy, it's free, and it takes less than 3 minutes with Let's Encrypt / certbot.