Issue metadata
Sign in to add a comment
|
consider removing the HSTS carveout for chart.apis.google.com
Reported by
dkee...@mozilla.com,
Aug 28 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 Example URL: https://chart.apis.google.com/chart?cht=p3&chd=t:60,40&chs=250x100&chl=Hello|World Steps to reproduce the problem: My understanding is it used to be the case that the servers backing chart.apis.google.com were incapable of using certificates that were valid for that hostname. This appears to have been fixed: https://chart.apis.google.com/chart?cht=p3&chd=t:60,40&chs=250x100&chl=Hello|World loads just fine for me. If this works for everyone and not just me, it might be good to remove the carveout/holepunch that was added to both Chrome and Firefox (and possibly other browsers?) for this one hostname. What is the expected behavior? What went wrong? Maybe chart.apis.google.com doesn't need to be special-cased to not be HSTS any longer. Did this work before? N/A Chrome version: <Copy from: 'about:version'> Channel: n/a OS Version: Flash Version:
,
Aug 28 2017
Indeed, this is fixed. I've been reluctant to take it out, because we may actually *want* carveouts in the near future. (I was surprised to learn last year that other browsers implemented the carveout... but they did.) For example, youtube.com and google.com may need them in order to do a practical rollout. Removing the only carveout might result in dropped support for carveouts. (Although I'm not super confident that the carveout support works properly across all browsers.)
,
Aug 28 2017
Renaming just so that it's consistent with past literature on this. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by mmenke@chromium.org
, Aug 28 2017Components: -Internals>Network Internals>Network>DomainSecurityPolicy