In a way yes, it's trying to avoid the initial redirect. But not in order to save you from the potential latency of the initial redirect:
> These sites do not depend on the issuing of the HSTS response header to enforce the policy, instead the browser is aleady aware that the host requires the use of SSL/TLS before any connection or communication even takes place. This removes the opportunity an attacker has to intercept and tamper with redirects that take place over HTTP.
> Also, wouldn't bundling (tens of) thousands of domains start to add up, and slow down first page load for regular browser use?
Why would it? Checking in a data structure if the domain the user requested should be loaded over HTTPS can be done in a perfectly efficient way. A hash table would give you O(1) lookup times on average and there's other things you can use to mitigate the worst case lookup of O(n).
I was hoping the article would cover the scaling aspect a bit more. I guess it's just meant to be a mid-step towards browsers defaulting to HTTPS at some unknown point in the future.
> These sites do not depend on the issuing of the HSTS response header to enforce the policy, instead the browser is aleady aware that the host requires the use of SSL/TLS before any connection or communication even takes place. This removes the opportunity an attacker has to intercept and tamper with redirects that take place over HTTP.
Read this: https://scotthelme.co.uk/hsts-preloading/
> Also, wouldn't bundling (tens of) thousands of domains start to add up, and slow down first page load for regular browser use?
Why would it? Checking in a data structure if the domain the user requested should be loaded over HTTPS can be done in a perfectly efficient way. A hash table would give you O(1) lookup times on average and there's other things you can use to mitigate the worst case lookup of O(n).