See the link: p/chromium - so that is clear.
The browser has a HSTS preloaded list.
Websites could enlist here: https://hstspreload.appspot.com/
Minimal requirements:
Have a valid certificate.
Redirect all HTTP traffic to HTTPS—i.e. be HTTPS only.
Serve all subdomains over HTTPS.
Serve an HSTS header on the base domain:
Expiry must be at least eighteen weeks (10886400 seconds).
The includeSubdomains token must be specified.
The preload token must be specified.
If you are serving a redirect, that redirect must have the HSTS header, not the page it redirects to.
Be aware that inclusion in the preload list cannot really be undone!
Read about the parent problem here: http://blogs.msdn.com/b/ieinternals/archive/2014/08/18/hsts-strict-transport-security-attacks-mitigations-deployment-https.aspx link article author Eric Law
The attacker causes the victim's browser to navigate to http://example.com. Because the HSTS policy applies only to sub.example.com and its superdomain matches, this insecure navigation is not blocked by the user agent. The attacker intercepts this insecure request and returns a response that sets a cookie on the entire domain tree using a Set-Cookie header. All subsequent requests to https://sub.example.com carry the injected cookie, despite the use of HSTS.
This attack scenario has to be mitigated via a
background fetch of a resource at the first-level domain. This resource should carry a HSTS header with an includeSubDomains directive that will apply to the entire domain and all subdomains.
polonus
