HSTS only works if (1) the endpoint properly supports it, (2) the browser supports it, (3) the list is up to date, (4) there is no attacker ever waiting for you to hit the page for the first time or when HSTS expires.
(2) is not really a concern any more, (3) occasionally becomes a concern, (1) is a concern for most of the web, and (4) is a concern for literally every use of HSTS.
The whole point of HSTS is to ward off man-in-the-middle. If all a man in the middle has to do is wait, and is eventually guaranteed a shot at exploiting you, they will. So all HSTS gives you is the small hedge that if an attacker is present, but not persistent, and not targeting you specifically, you're slightly more secure.
Basically, it only protects you if a random hacker is sitting in a coffee shop you don't normally go to, and only if your browser is up to date, and only if every site you want to visit uses HSTS, and only if you've visited them before. It's so incredibly specific that it's almost pointless.
A better solution would be either (A) an extention to the specification to actually support a "secure://" URI prefix, or (B) a proxy or browser mode that only allows valid HTTPS connections. These are user interface fixes, because the entire point of HSTS is to prevent users (and really bad apps, I guess) from accidentally using HTTP.
(4) is solved by HSTS preloading. The request is upgraded to https before any traffic hits the network, even if you've never visited the domain before. The list of HSTS preloaded domains and TLDs is hard-coded into your browser. For more info: https://hstspreload.org/
Clearly it's not solved by preloading, since an old list invalidates the preload, and not every site supports HSTS, and I imagine they would have individual expire times (but perhaps not as a preload)
Also, does that site even work?
Status: google.com is not preloaded.
Status: microsoft.com is not preloaded.
Status: duckduckgo.com is not preloaded.
Status: news.ycombinator.com is not preloaded.
Status: aws.amazon.com is not preloaded.
Status: bankofamerica.com is not preloaded.
Status: capitalone.com is not preloaded.
Well right off the bat, I'm screwed... I hope nobody else on the internet is visiting these sites.
(2) is not really a concern any more, (3) occasionally becomes a concern, (1) is a concern for most of the web, and (4) is a concern for literally every use of HSTS.
The whole point of HSTS is to ward off man-in-the-middle. If all a man in the middle has to do is wait, and is eventually guaranteed a shot at exploiting you, they will. So all HSTS gives you is the small hedge that if an attacker is present, but not persistent, and not targeting you specifically, you're slightly more secure.
Basically, it only protects you if a random hacker is sitting in a coffee shop you don't normally go to, and only if your browser is up to date, and only if every site you want to visit uses HSTS, and only if you've visited them before. It's so incredibly specific that it's almost pointless.
A better solution would be either (A) an extention to the specification to actually support a "secure://" URI prefix, or (B) a proxy or browser mode that only allows valid HTTPS connections. These are user interface fixes, because the entire point of HSTS is to prevent users (and really bad apps, I guess) from accidentally using HTTP.