Should HSTS Preload List affect unqualified hostnames? |
|||
Issue descriptionagl@, rsleevi@, thoughts on this one? In Chrome 63, we added *.dev, *.app, *.page, *.foo, and *.chrome to the HSTS preload list. Perhaps surprisingly, the dotless (“plain hostnames”) http://dev/, http://page/ http://app/ http://chrome/ and http://foo/ are all impacted by new HSTS rules as well. We probably should not apply HSTS preload rules to these unqualified hostnames to avoid breaking users' Intranet sites. However, we may want to allow individual sites on unqualified hostnames to opt-in to HSTS via the response header.
,
Dec 12 2017
In order to avoid confusion, when writing HSTS names I write, say, (*.)dev and (*.)app in order to try and convey exactly what is covered. I think I agree with sleevi here that these are now global names and we shouldn't pretend otherwise.
,
Dec 15 2017
(Removing the bug from the enterprise triage queue as the corresponding owners seem to be involved already.)
,
Dec 18 2017
If the Enterprise team isn't screaming about us blowing up Intranets, then SGTM. |
|||
►
Sign in to add a comment |
|||
Comment 1 by rsleevi@chromium.org
, Dec 12 2017