[tylerhou]

I could, in a very tame example, inject a fake donation button which pointed to my own account instead of the author's. In a more extreme and dangerous example, I could inject malicious JavaScript which exploited an unpatched CVE (Meltdown, Spectre) or vulnerabilities in plugins like Flash, if enabled, to gain control of the user's computer.

It's true that these things could also happen over an HTTPS connection, but then the prevention method is "don't go on sketchy websites." It's far more dangerous over HTTP because a user might already trust the site or author themselves.

[twtw]

Thank you for answering.

I still don't see why either of those justify warning the user about the whole page. For the donation button, the browser could easily warn you with a big "insecure!" page when you click on the button. Regarding js exploits, I don't think https fixes that even for non-sketchy websites: I'm thinking of the js malware in ads and the recent cryptocurrency-mining ads on youtube.

[tylerhou]

> the browser could easily warn you with a big "insecure!" page when you click on the button.

But this implies that whenever you click on any link on a page served via HTTP, the browser should warn you with a big "insecure!" page. I think this is far more obtrusive than a simple "not secure" banner next to the URL.

> I don't think https fixes that even for non-sketchy websites

You're right, if the website served over HTTPS injects random JavaScript/is poorly designed. However, the danger with HTTP is that every single website is vulnerable to this attack, not simply the ones served by malicious or incompetent hosts.

[foo101]

The donation request may not always be in the form of a button. Sometimes it may be a request to make the donation by another means such as by sending bitcoins to a specific address.