While https is a good default, and LetsEncrypt has made it relatively trivial, I wouldn't say this particularly needs it; there isn't any user data at all.
I suppose without TLS it could be intercepted and modified to return a malicious bash command, or something, but this random site on the internet could do that on its own without being intercepted anyway.
> I wouldn't say this particularly needs it; there isn't any user data at all.
I use NoScript. This page requires me to enable JavaScript for it to work. Because it doesn't use TLS, this allows any miscreant in the middle to injected JS doing god-knows-what into my browser.
If you really insist (in this case IMO understandable) on having me download and run your program, written in a turing complete scripting language, please let me do so in a way where I can be sure it is actually your program (assuming I trust you that far; which for most people I don't, hence NoScript).
Wiktionary is a website that has improved functionality after turning on JavaScript, but works just fine without it. It does not insist on using JavaScript.
I guess what you actually mean is "no one is insisting on me looking at their website"? That would be true, but I don't recall making any contrary claims.
If I do want to look at a website, the site insists on using JavaScript, but does not use HTTPS, that can be a security issue. That's what my original comment tries to point out.
> I wouldn't say this particularly needs it; there isn't any user data at all.
> I suppose without TLS it could be intercepted and modified to return a malicious bash command, or something
A hacked version doesn't have to return a variation of what's on the page already. There's lots of sneaky things you could return, like a malware download pretending to be a Bash PS1 setup script, a fake GitHub based sign-up to harvest login details, a payment form for a fake product, or a simple redirect to another malicious site.
Always having https removes the need to consider the security implications of unencrypted transport on case-by-case basis.
I have been using HTTPS Everywhere extension and currently Firefox's HTTPS-Only feature in strict mode for a long time. Nowadays few links fail to work for me, so the failing ones stand out.
(I use the :where(…) wrapping so that any site actually trying to use :link::after for real stuff can override my styles without specificity conflicts.)
It’s interesting especially to see how often https: sites have http: links to their own domain, which are just going to get redirected back to the https:. (The HN footer has the “Legal” and “Apply to YC” links being to http://www.ycombinator.com/* for no good reason, a very similar case.)
And how horribly many emails use http: tracking links, and how painfully many of those domains don’t speak HTTPS.
HN’s front page normally has 0–2 out of 30 of the links being HTTP, almost always old domains. It’s fairly rare for a new site to go plain HTTP.
> I suppose without TLS it could be intercepted and modified to return a malicious bash command, or something, but this random site on the internet could do that on its own without being intercepted anyway.
Those are two completely different attack surfaces. You should be able to trust a single site without having to trust every other hop on the Internet and a good reason why TLS should be used here.
This is a website which serves the sole purpose of encouraging people to copy snippets of text and paste them into their terminal, and there are plenty of techniques that ensure what you see on the page isn't what gets into your clipboard.
I suppose without TLS it could be intercepted and modified to return a malicious bash command, or something, but this random site on the internet could do that on its own without being intercepted anyway.