> 1. HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs. Man-in-the-middle attacks of this sort really have happened, [0] and

> 1. HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs. Man-in-the-middle attacks of this sort really have happened, [0] and remember that the browser itself may have exploitable security vulnerabilities. 1a. Spy agencies or botnets that have compromised routers and want to attack Internet users. (The spy agencies are probably more of a concern for backbone routers, while the botnets are probably more of a concern for CPE routers.) > 5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just 3 reasons: I've encountered, I guess, five others: you want to use the server in a mostly or totally offline environment (so it can't count on getting Internet access to perform renewals), you want to use a totally air-gapped environment, you don't possess a domain name or can't be sure of renewing it for some reason, you want to use web protocols for a very lightweight (but not necessarily very old) embedded system in a LAN, or you are subject to sanctions that prevent CAs from charging you for a certificate and/or issuing one to you at all. I guess also "for some reason you want to use TCP/IP on a point-to-point link to collect telemetry where very low latency is your absolute highest priority, and integrity and/or confidentiality are handled sufficiently by some other layer somehow". (Although in that case the client probably isn't a web browser, so this probably isn't an issue.)