HTTP is sometimes OK

The 2021 post Plaintext HTTP in a Modern World by joshua stein elucidates some of the reasons I’m not entirely keen on forcing HTTPS for reading websites. Old computers and old browsers won’t be able to use encryption strong enough to still be useful today. But that’s no reason to stop them from anynomous access to websites where users mostly read or view content and aren’t able to submit credentials or personal information. Like, for example, blogs.

I have a 10-year-old browser still installed (Opera 12.16) which cannot read Wikipedia anymore. I don’t expect to be able to log in to Wikipedia, but reading text and viewing images should be possible with a browser released in 2013. That’s not ancient history. We had good CSS then!

That’s a reason why I have HTTPS enabled on this domain, but not automatic redirecting to HTTPS. The only thing I was unsure about was how to let visitors know that there is an HTTPS version of the site available, without force-redirecting everyone. I was thinking of having two sets of HTML pages generated, one to be served over HTTP with a warning banner and a link to HTTPS at the top of the page; and the other to be served over HTTPS without the banner. But the post by joshua shows a cleaner solution: the Upgrade-Insecure-Requests HTTP header. The header indicates the browser’s preference for HTTPS, and as of 2023 the fact that the browser knows about this header also implies that the browser supports a currently-secure encryption level – so browsers that send it can be upgraded to HTTPS, and browsers that don’t can get the response over HTTP. Presumably they’ll change Upgrade-Insecure-Requests: 1 to Upgrade-Insecure-Requests: 2 once more recent encryption algoriths are deprecated and browsers of 2020 or 2023 have to be cut off from HTTPS.

Do keep your login forms on HTTPS though!

There was also the 2018 post Securing Web Sites Made Them Less Accessible by Eric A. Meyer which featured discussion which pointed out a problem with leaving HTTP open: it allows tampering of the content between server and client, for example ads injected by ISPs. I’m not entirely sure where I fall on this. On one hand, I can see site authors not wanting their content to be changed in transit. On the other hand, if the choice is between an old browser getting possibly-tampered content or getting no content, is the possibly-tampered content still more useful? And, the conditional upgrading using Upgrade-Insecure-Requests seems to offer a kind of herd immunity: if 99.5% of traffic is using HTTPS, the effort of injecting ads or tracking into 0.5% of requests might not be worth it, at least from a commercial perspective. Targeted injection (like for websites useful for activists) might still happen, but a locked-down old browser being used to read general-purpose web content for hobby reasons seems reasonably safe.

Like all old protocols, HTTP will eventually cease to be useful. But there’s no reason to make it happen earlier than necessary.