Web browsers are definitely way measurably better and more stable than they've been basically since the beginning. We went from buffer overflows in the URL parser, dog slow JS interpreters, and unclear specs that are implemented completely differently in every engine, to today, where browsers are some of the finest engineering in the whole field, featuring state of the art JITs, extremely precise specifications, and bug bounties blowing past six figures once you get to code execution.
Of course you can do something ridiculous and compare today's Firefox with NCSA Mosaic or something. And yeah, old-school HTML would still be perfectly usable if people wanted to do that, so it's not like this is entirely pointless. But if you even make the comparison slightly more reasonable, like comparing Chrome and Firefox today to their versions from 10 years ago, I mean it's really no contest. From the standpoint of the core functionality, these are better browsers that are faster and generally more efficient. It's not just because computers got faster; that enabled more complicated things of course, but I have several older machines still new enough to run some modern software (Pentium 2-4) and generally, the newer browsers just run significantly better when doing equivalent things. They handle load better, they generally load pages better, scrolling generally feels better... Even on crappy single core processors. Even crappy sites like YouTube can work pretty decently on a Pentium 4.
This is not really that surprising because it's not like they haven't been optimized for this. Even if phones are starting to get very fast, there's still plenty of lower end phones on the market where it's important to be able to deal with slow processors with few cores.
Chromium is often my go-to codebase when I want to see how to do something correctly, especially with weirder OS APIs. Perhaps somewhat fittingly, I used to often use Qt for this, in a different world.
> 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.
Of course you can do something ridiculous and compare today's Firefox with NCSA Mosaic or something. And yeah, old-school HTML would still be perfectly usable if people wanted to do that, so it's not like this is entirely pointless. But if you even make the comparison slightly more reasonable, like comparing Chrome and Firefox today to their versions from 10 years ago, I mean it's really no contest. From the standpoint of the core functionality, these are better browsers that are faster and generally more efficient. It's not just because computers got faster; that enabled more complicated things of course, but I have several older machines still new enough to run some modern software (Pentium 2-4) and generally, the newer browsers just run significantly better when doing equivalent things. They handle load better, they generally load pages better, scrolling generally feels better... Even on crappy single core processors. Even crappy sites like YouTube can work pretty decently on a Pentium 4.
This is not really that surprising because it's not like they haven't been optimized for this. Even if phones are starting to get very fast, there's still plenty of lower end phones on the market where it's important to be able to deal with slow processors with few cores.
Chromium is often my go-to codebase when I want to see how to do something correctly, especially with weirder OS APIs. Perhaps somewhat fittingly, I used to often use Qt for this, in a different world.