> Web browsers are definitely way measurably better
Just recently Firefox did not let me view a website even though the server was up because the certificate was expired and the site used HSTS previously. No override provided to me as a user. Better? No.
So an older browser that doesn't support HSTS is good, because it means you can browse a page even when your browser has valid reason to believe a downgrade attack could be occurring? The nuances of secure connections can be pretty awful, but a vast majority of the time, HSTS is good. The fact that HSTS is ubiquitous makes it less likely that attackers will even try attacks like these.
If a website admin messes up TLS when using HSTS, that's unfortunate. But: they opted to use it on purpose. It's hardly the browser's fault for trusting the website that it's not OK to browse in this circumstance.
Or they didn't - e.g. the entire .dev TLD is HSTS preloaded or it could have been a previous domain owner. Or they were blindly following up a guide.
But even if they mean to have HSTS, mistakes do happen and the browser should not prevent me (the user) from working around them.
Security without any other considerations is not reasonable - and if you want that you might as well prevent all connections to avoid all 0days.
Ultimately the browser is not in a position to fully judge the threat model and thus should allow the user to override its guess - always. For example when I want to look at a blog of funny pictures without any login info I don't care if someone tries to MITM that connection. And unless you are in a country with shitty consumer protections, an MITM is already so unlikely to be a conspiracy-theory level concern.
> So an older browser that doesn't support HSTS is good, because it means you can browse a page even when your browser has valid reason to believe a downgrade attack could be occurring?
Well I mean false positives are bad because they are false. That much doesn't require further justification or someone to embrace false negatives instead or whatever. This policy of "treat everyone as stupid and gullible and ditch them if they won't upgrade" makes sense for giant tech companies, but not necessarily for everyone. Some of us have to be able to work with old technology.
It's not a false positive because it's broken, though. It's a false positive because it's working as intended and the host is simply violating the rules. It's weird that a site would opt-in to a feature like this, use it incorrectly, and then when the browser correctly rejects it, you would get mad at the browser. Nobody was actually forced to use HSTS here, and there's also no good reason for a TLS certificate to be expired either; in production, this is an incident no matter what.
The browser really isn't treating you as stupid, it's telling you "this is a serious security issue, if you really want to bypass this, you're on your own." You absolutely can, using flags in chromium or config in Firefox, or sometimes by clearing the HSTS cache in either. The benefit of this is that it ensures users who don't know better, the majority, don't stumble into an attack in the most critical situations, and it as well makes it significantly harder for developers and malicious attackers alike to try to convince end users to wrongly bypass security features, a problem that plagued early web browsers which had much worse UX around TLS. Even though it can be annoying, it's helpful to all of us, because the security posture of those around you naturally impact your own security posture, too.
This is all especially reasonable because HSTS is opt-in from the host's perspective. You're supposed to use it when you'd absolutely rather have false positives than not catch an attack.
This particular point doesn't have much to do with old technology, but I honestly don't think most developers set out to just break old tech. I agree that it is a shame the degree of churn we go through, but even if you have a super valid reason to absolutely need to use old technology, it's still not a good argument for the rest of the world to hold off on improving security, privacy and performance by holding back TLS upgrades or continuing to include and debug polyfills for all of eternity. If you really absolutely can't make TLS work for you, nothing is stopping you from running an SSL stripping proxy in the middle. Works pretty well for me.
Hopefully in the future the churn of technology will slow down and computers will last longer, but we're literally still near the beginning of the computing revolution, and the computers from 20 years ago are probably a much more enormous delta from today than the computers 20 years from today will be. (And even if a breakthrough proves this untrue, it still seems unlikely that today's boxes will become useless, with how much compute they pack.) And yet despite that, Linux is still dutifully supporting processors as old as 486, even though it's not really that important to be running the latest kernel on a machine that old. That's pretty good, and even if browser updates are difficult on machines that old, I have little doubt that some people will be maintaining them all the way to the 2038 problem where it will get much harder.
Chrome will do the same thing and so will any other browser that honors the HSTS standard in RFC 6797. You probably want to direct your ire at the owner of the website, setting the HSTS header is a positive affirmation by the server that it does not accept insecure connections.
Special attention should be paid to section 12.1 of that RFC:
>If a web application issues an HSTS Policy, then it is
implicitly opting into the "no user recourse" approach, whereby all
certificate errors or warnings cause a connection termination, with
no chance to "fool" users into making the wrong decision and
compromising themselves.
This reminds me of Microsoft having a strong incentive to make sure hardware manufacturers write their drivers correctly, because if a bad driver causes problems the average user will blame Microsoft, as they don't know that MS don't write the drivers.
In this situation Firefox are being blamed for correctly implementing the standard and preventing access to the site, when the blame should fall on the site owner for not setting the security up correctly.
The html spec also defines that audio can be set to autoplay and the JS spec allows websites to freely open popups. Yet browsers are able to ignore that in the interest of the user - because they are (supposed to be) user agents not website agents that have to blindly follow what the website says. Browsers are free to not implement user-hostile specs or only implement parts of them and they commonly chose to do so.
Ultimately, protocol specs have no purview over user interaction and can at best recommend the expected behavior. There is nothing wrong with the browser telling the user that this website is expected to be accessed trough TLS with a valid certificate and isn't and to redirect HTTP requests to HTTPS but the spec is no excuse for the browser not letting the user overwrite that policy.
So no, the ire should be directed at the browser because the broser is there to make sure my interest as the user are followed not those of some website owner (or someone making decisions for them like Google for *.dev).
Neither the HTML spec or the JavaScript spec require that audio be auto played or that pop-ups be opened without restriction. HSTS is different in this respect.
I'm sure if you want to hack your browser so that it ignores that header you can, but the idea is that any server sending that header is telling you to go away if the certificate is invalid.
HSTS can be annoying when such things happen but from what I understand the browser is acting properly there. Also I've been able to clear that in Firefox in the past, I think I had to clear all data for the site. I do think that an easier mechanism could be a good thing.
Just recently Firefox did not let me view a website even though the server was up because the certificate was expired and the site used HSTS previously. No override provided to me as a user. Better? No.