For the reasons mentioned in this article—it's probably a good idea to keep plain HTTP access available on your websites.
If you support HTTP at all, you’re damaging the experience for the almost everyone that could have used HTTPS: almost no one will get the HTTPS version unless you deliberately push them over to it, which you will only be able to do after page load by some JavaScript-based user-agent or feature-based sniffing, so now the page loads and then reloads immediately, every time the user visits your site by URL, and you’re causing trouble with search engines, and it’s a regular maintenance burden because no one treads this path so you’ll have to figure out the cut-off points yourself as certificates change, and on top of that it’ll always be subject to a downgrade attack, so now you can’t ever depend on HTTPS.
Remember also that various new features are gated on using a secure context (which roughly means “HTTPS”), like HTTP/2 and HTTP/3. And as for entering passwords or the likes, you’d be opening quite a can of worms if you allow that over cleartext HTTP.
So… yeah, it sounds nice in theory, but I think that it’s just not practical or advisable to retain plain HTTP support. Even supporting TLS < 1.2 or older cipher suites is steadily becoming inadvisable, only to be used on a few sorts of websites. The unfortunate fact of the matter is that you can’t support ancient devices without harming things materially for everything else.
① If it’s on the same domain, it would necessitate weakening the HSTS policy, removing includeSubDomains and preload.
② If it’s on a separate domain, you’re actively training people to do dangerous things and get phished.
③ Pretty much the only way this will ever be used is if you push people to it and ensure that search engines choose it rather than the secure version. (Implicit in this is a significant SEO hassle.) Thus you’re back exactly where you started.
Most websites don't even need HTTPS and the complications and sacrifice of autonomy required isn't worth it. Remember, there are no cert authorities that are human people. They are all corporations or institutions. Having to get an incorporated entity's permission to communicate will have dangerous consequences eventually. HTTPS everywhere is done with the best of intentions but it will be the centralizing push that provides juicy targets for government and corporate censorship.
The privacy of all users is more important than supporting the outdated browser on an ereader.
This is false. All you have to do is configure your webserver to only redirect port 80 requests to port 443 if the request includes the "Upgrade-Insecure-Requests" header. Obviously since headers are sent unencrypted this means attackers could easily bypass it, but it's still suitable for personal webpages with no user data. For example, here's how you do it in Apache:
RewriteEngine on
RewriteCond %{HTTP:Upgrade-Insecure-Requests} =1
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
① An HSTS policy will protect people that have visited your site within max-age seconds, typically “within the last year”.
② An HSTS policy with preload will protect everyone.
③ HTTPS-only cookies will prevent them being sent over plain HTTP.
⑤ You could depend on various newer functionality that is only available in secure contexts <https://developer.mozilla.org/en-US/docs/Web/Security/Secure...>. For example, the Web Authentication API. (This also raises a good point about using the Web Authentication API for security: authentication is tied to the origin, so http://example.com, https://example.com and https://example.com.evil.example are all different origins and no one will be able to log in over the wrong origin.)
⑥ Any JavaScript code can check the origin and rebel if it’s not what you expect—in fact, I’d say that it’s very common to do this quite incidentally. This protects against a drive-by downgrade attack, increasing the effort required by the attacker who must now reverse-engineer a bit of your code.
I'm not willing to make security exceptions to support devices from 2011. "HTTPS by default" lifts all boats: people who would MITM your users can't tell if they're reading your nice blog or a critique of their local government, and that's a good thing.
That's 98.24% of users captured by CanIUse's sources (which seems to be StatCounter). Like most things on the Internet, that's a bubble - the bubble of users who visit statcounter-infested websites, and are able to run their scripts. And the point of the original post is to think outside the bubble. Not in all cases - if you're a B2B service, or selling T-shirts with slogans on them, CanIUse is likely a good enough source to base your choices on. But if you're a government website, or providing critical Covid-19 data for example, it's irresponsible to ignore these long-tail of users who fall outside expected and easily visible patterns. There's a spectrum between these two kinds of websites, and it's worth thinking about where you fall on that and how many you're comfortable with denying access to your website.
It's a tradeoff between security and accessibility, and we should at least be thoughtful about the implications of our decisions.
And honestly, I think a lot of people in the second group are there because they bought smartphone in 2007 and won't upgrade because "if it ain't broke, don't fix it". Well, now it's broken. Fix it.
This sounds like a personal consideration - one you're entitled to, but perhaps shouldn't force on others. Maybe consider Tor?
> ever-shrinking pool of people who can't/won't upgrade.
Are you sure about this? The kind of security you're advocating for here is a moving target. As the pool shrinks on the tail end, surely the head advances...
> Well, now it's broken. Fix it.
Erm, no. The device isn't broken, you are willfully breaking it. I can appreciate your stance, but glib comments like this aren't going to convince anyone in that camp.
It would be great if we could always automatically choose the right option, but browsers don't do that.