Clock sync would be a requirement for access.
A recent device would be a requirement for access (not everyone can afford a new one).
Site admin keeping up with certificate registration would be a requirement.
Approval from the centralized certificate authority would be a requirement.
Server's self domain name matching accessed domain name would be a requirement.
These are all real scenarios where real people can be denied access to information that is crucial to them, up to the point of survival.
Just a few of the reasons why all my websites still allow HTTP.
HTTP is also way faster on slow connections.
> Clock sync would be a requirement for access.
If you're on the Internet, then unless you have a religious reason against the NTP protocol, setting the time accurately is not a problem.
> A recent device would be a requirement for access (not everyone can afford a new one).
It's a fair point to raise, but if we target TLS 1.2 (1.0 and 1.1's been deprecated, and 1.3 support still isn't everywhere.) then all Android phones with Lollipop, which was released in 2014, and up support TLS 1.2. (The shittiness of cheap Android devices means phones from back then don't work anymore, so low end phones from a few generations back are more accessible than a Nexus 6 (Google's launch pre-Pixel phone for Lollipop) would be.
If you're on a laptop/desktop, there are no released versions of Chrome on Windows that are so old they don't support TLS 1.2. This includes the now-unsupported XP SP2+ and Vista. That dates back to 2007. On Apple desktop/laptops, Mac OS X Snow Leopard (10.6) and greater have Chrome support for TLS 1.2. I'm away from my 2012 Macbook Pro right now, but it's on something newer than 10.6.
So if your audience would have to be on 9+ year old Android phones, 16+ year old Windows computers, or a similarly old Apple computers (which is entirely possible), but they've already been excluded from the running any credit card transactions on the Internet (and have been since June 2018 due to PCI forcing the deprecation of TLS 1.0 and 1.1).
> Site admin keeping up with certificate registration would be a requirement. > Approval from the centralized certificate authority would be a requirement.
Let's Encrypt, which has been around since 2014 just handles all that nonsense, with automated support for most of the popular web servers. It's free (gratis) even for commercial and for-profit purposes, and is sponsored by the EFF, among other organizations.
> Server's self domain name matching accessed domain name would be a requirement.
That's not the case, unless you're using bespoke web server software. Name-based virtual hosting is quite common, even in the TLS world, and lets the client specify which service it would like to connect to. The web server is then configured to reply with the hostname that was asked for, and multiple services, (with different names) can be run on the same server on the same IP address.
Regardless though, if the primary failure mode you're worried about is users being denied access to your site, they can always just click through the warning to access underlying site. They'll be used to it from using the rest of the web (eg Wikipedia switched over to be exclusively HTTPS in 2015, and Chrome started labeling HTTP as insecure Jan 2017).
As for speed, I was in South East Asia recently, and found that cities had LTE and 4G, but while there were stretches of no service (which exists even in a rich nation like the USA), what surprised me was finding EDGE cell data. If you're that constrained then sure.
Edit: Also around half the pages I currently have open are passing through cloudflare anyway and signed by them, so a third party hijacking the connection to throw in ads is just one business minded CEO away.
Cloudflare's customers aren't going to stand for that and will find a new CDN if it was ever shown to be the case that Cloudflare was intentionally altering content they're rehosting. Cloudflare's imperfect, but Prince isn't that dumb, so we're years away from even the hint of that being possible.
I run a trivial site via http and I don’t care about isps and coffee shops injecting ads. I’ve never witnessed this myself or known anyone affected, but my site is free and non-commercial so I wouldn’t care if a location did that.
For me, it’s worth the removal of a minor chore to not run ssl. Comically, my host automatically ads ssl every once in a while, then tries to charge me, then breaks ssl.
What's even more fun is when people inject actual attack code because every major browser executes javascript by default.
Running non-ssl on the public internet is like unprotected sex with a random partner. Maybe because you've not witnessed a STD doesn't mean that there aren't a entire shitload of them out there that present real risks to the population.