For god's sake, however complex ACME might be it's better than not supporting TLS
TLS isn't for you, it's for your readers.
Maybe the answer is disabling the JS runtime on non-TLS sites, maybe that has the added benefit of making the web (documents and “posters”) light again.
SMS is unencrypted, phone calls are unencrypted- yet we don’t worry nearly as much about people injecting content or modifying things. Because we trust out providers, largely, but the capability 100% exists for that; with no actual recourse. With browsing the internet we do have recourse- optionally use a VPN.
All of this security theatre is just moving the trust around, I would much rather make laws that protect the integrity of traffic sent via ISPs than add to the computational waste from military grade encrypting the local menu for the pizza shop.
Worse still, the pizza shop won’t go through the effort so they either won’t bother having a website or will put it on facebook or some other crazy centralised platform.
I’ll tell you something, I trust my ISP (Bahnhof- famous for protecting thepiratebay) a lot more than I trust Facebook not to do weird moderation activities.
Except when an adversary MITMs your site and injects an attack to one of your readers:
* https://www.infoworld.com/article/2188091/uk-spy-agency-uses...
Further: tapping glass is a thing, and if the only traffic that is encrypted is the "important" or "sensitive" stuff, then it sticks out in the flow, and so attackers know to focus just on that. If all traffic is encrypted, then it's much harder for attackers to figure out what is important and what is not.
So by encrypting your "unimportant" data you add more noise that has to be sifted through.
What someone chooses to read on a blog is no one else's business, and can be very sensitive.
Visitors to your website may encounter it. Do you not care that your visitors may be seeing ads?
You're also leaking what your visitors are reading to their ISPs and governments. Maybe you don't consider anything you write about to be remotely sensitive, but how critically do you examine that with every new piece you write?
If you wrote something which could be sensitive to readers in some parts of the world (something about circumventing censorship, something critical of some religion, something involving abortion or other forms of healthcare that some governments are cracking down on), do you then add SSL at that point? Or do you refrain from publishing it?
Personally, I like the freedom to just not think about these things. I can write about whatever I want, however controversial it might be in some regions, no matter how dangerous it is for some people to be found reading about it, and be confident that my readers can expect at least a baseline of safety because my blog, like pretty much every other in the world today, uses cryptography to ensure that governments and ISPs can't use deep packet inspection to scan the words they read or use MITM to inject things into my blog. Does it really matter? Well probably not for my site specifically, but across all the blogs and websites in the world and all the visitors in the world, that's a whole lot of "probably not"s which all combine together into a huge "almost definitely".
So while it's not perfect, it's pretty good, and a very low investment for me as a website owner :)
I see no other reason to serve content over HTTPS.
The reason you don't see many MITM boxes injecting content into HTTP anymore is because of widespread HTTPS adoption and browsers taking steps to distrust HTTP, making MITM injection a near-useless tactic.
(This rhymes with the observation that some people now perceive Y2K as overhyped fear-mongering that amounted to nothing, without understanding that immense work happened behind the scenes to avert problems.)
If I'm really curious about your plain http site I'll check it out through archive.org, and I'm definitely not going to keep visiting it frequently.
It's been easy to live with forced https for at least five years (and for at least the last ten with https first, with confirmations for plain http).
It's a restaurant that's been here with the same menu since the 1970s, and their website does absolutely nothing besides pass out information (phone number, menu, directions), so they probably put it up in 2002 and haven't changed it since. It was just a startling reminder of how ubiquitous HTTPS has gotten.
And can generally be configured by the user not to downgrade to http without an explicit prompt.
Honestly I disagree with the refusal to support various APIs over http. Making the (configurable last I checked) prompt mandatory per browser session would have sufficed to push all mainstream sites to strictly https.
Absolutely, and this works quite well on the current web.
> Honestly I disagree with the refusal to support various APIs over http.
There are multiple good reasons to do so. Part of it is pushing people to HTTPS; part of it is the observation that if you allow an API over HTTP, you're allowing that API to any attacker.
In the scenario I described you're doing that only after the user has explicitly opted in on a case by case basis, and you're forcing a per-session nag on them in order to coerce mainstream website operators to adopt the secure default.
At that point it's functionally slightly more obtuse than adding an exception for a certificate (because those are persistent). Rejecting the latter on the basis of security is adopting a position that no amount of user discretion is acceptable. At least personally I'm comfortable disagreeing with that.
More generally, I support secure defaults but almost invariably disagree with disallowing users to shoot themselves in the foot. As an example, I expect a stern warning if I attempt to uninstall my kernel but I also expect the software on my device to do exactly what I tell it to 100% of the time regardless of what the developers might have thought was best for me.
I agree with this. But also, there is a strong degree to which users will go track down ways (or follow random instructions) to shoot themselves in the foot if some site they care about says "do this so we can function!". I do think, in cases where there's value in collectively pushing for better defaults, it's sometimes OK for the "I can always make my device do exactly what I tell it to do" escape hatch to be "download the source and change it yourself". Not every escape hatch gets a setting, because not every escape hatch is supported.
In theory I agree. In practice building a modern browser is neither easy nor is it feasible to do so on an average computer.
Given that a nag message would suffice to coerce all mainstream operators (thus accomplishing the goals I've seen stated) I'm left unconvinced. That said, I'm not particularly bothered since the trivial workaround is a self signed certificate and the user adding an exception. It's admittedly a case of principle rather than practice.
This was my experience sending a link to someone who primarily uses an iPad and is non-technical. They were not going to find/open their Macbook to see the link.