But before that happens, if the user always goes to the http address and it works for them (whether by legitimate redirect or by the legitimate site simply supporting http) it lulls them in to a false sense of security, and a belief that going to the http address is ok.
So the idea behind having the http address be broken from the start is to make the users see that the address they're trying is broken, and therefore the wrong one for them to use. Hopefully at that point they'll investigate why (perhaps complaining or talking to their sysadmin, if they have one), and be straightened out by someone providing the https link to them (or the more tech-savvy users like the OP figuring it out for themselves).
Firefox have some scripts which go through and check to make sure everything still on the Chrome list is still announcing the preload headers, and will autoremove if that isn't that case, IIRC. I wouldn't be too shocked if Apple/Microsoft were doing something similar.
Is there any documentation for these browsers that officially say exactly what they're doing and how their preload lists are generated?
https://wiki.mozilla.org/SecurityEngineering/HTTP_Strict_Tra...
I'd really like to know which of these is the better solution.
It seems to me that if people go to the http address, they could be redirected to an attacker's address with a simple MITM attack. So there's an argument to be made for not using http at all, even for a legitimate redirect, because it can be so easily MITM'ed.
On the other hand, if the http address is left unused, then people who try it anyway and it fails will be confused. For this solution to work, it seems the users have to be educated to always and only use the https address.
For these reasons, the whole separate http/https scheme seems broken by design.
What's the consensus from the security community as to the right setup here? Am I missing something, or is there a better way?