Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1888913004:
HSTS preload list removals for Chrome 52. (Closed)
DescriptionHSTS preload list removals for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> Our dev team who manages the our public website has mistakenly
> configured the preload function + include_includesubdomains. This
> feature has blocked our internal websites as well, even if the don’t
> use SSL at all. :(
mpac.ca:
> Please remove mpac.ca from the HSTS preload list, as the header was
> added with the includeSubDomains flag by mistake. Both internal and
> external systems share the same apex domain, and it is not possible to
> move all internal systems to https in the near future.
truweight.in:
> Some of my sub-domains e.g. loseweight.truweight.in are actually
> hosted by third parties such as leadsquared, unbounce, which do not
> support https.
2e-systems.com:
> we incorrectly announced HSTS for the complete domain, but we are not
> yet ready, there are several internal sites available only over VPN
> that we forgot about, so if you can please remove us from the
> preloaded list.
macaque.io:
> We are using campaign monitor for our email marketing platform and
> utilising a vanity url of http://macmail.macaque.io. Because we cannot
> implement https on this platform we would like to be removed from the
> hsts preload list.
fless.co.uk:
> The domain fless.co.uk runs a url based dynamic proxy on multiple
> levels of subdomains so can't be covered by a wildcard certificate.
> While the fless.co.uk will return to using hsts once resolved, the
> subdomains can't be maintained with hsts.
carthage.edu:
> we have a few subdomains that are not yet https and that is causing a
> bit of a stir.
matspar.com, matspar.se:
> One of our subdomains, exportera.matspar.se and exportera.matspar.com
> needs to be able to be served over http, we did not plan for this ever
> to be the case initially.
aiflab.com
> We don't want to HSTS preload all time. We will manually make https
> when we need. but, forcing HSTS preload is panic now-a-days.
rushball.net, hiphop.ren:
> these domains is no https now
lightspeed.com:
> We initially included this for all subdomains but that affects
> internal servers we have that don’t have ssl certificates required.
ceu.edu:
> [...] we wanted to force browsers to use https when visiting our main
> website. However we now see that unfortunately we have some other
> subdomains on other web servers where implementation of SSL is
> problematic or delayed, and in the new version of chrome these sites
> do not load.
end.io:
> Please can you remove it as I am the webmaster and it is breaking the
> site.
alastyr.com:
> We use this domain our main domain for hosting services, we provide to
> customer non-ssl web services, customers did not connect via Chrome or similar
> web browsers.
mobocasino.com:
>I'd like to remove us because we employ subdomains (other than www) over http
>which we cannot serve over https for cost reasons.
compuscan.co.za:
> We have a few services running internally on HTTP and HSTS is “breaking” this
> for us via Chrome browsers.
No citable reason for the following. :-()
- wover.me
- ono.es
BUG=527947
TBR=palmer@chromium.org
Committed: https://chromium.googlesource.com/chromium/src/+/d2bdb307d12f0ed4ae4296b72795342f53d11743
Patch Set 1 #Patch Set 2 : #Patch Set 3 : #Patch Set 4 : #Patch Set 5 : lightspeed.com #Patch Set 6 : #Patch Set 7 : #Messages
Total messages: 11 (8 generated)
Description was changed from
==========
HSTS preload list updates for Chrome 52.
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
BUG=
==========
to
==========
HSTS preload list updates for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> We didn’t requested it and we insist to be taken out.
BUG=527947
==========
Description was changed from
==========
HSTS preload list updates for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> We didn’t requested it and we insist to be taken out.
BUG=527947
==========
to
==========
HSTS preload list updates for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> We didn’t requested it and we insist to be taken out.
BUG=527947
==========
Description was changed from
==========
HSTS preload list updates for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> We didn’t requested it and we insist to be taken out.
BUG=527947
==========
to
==========
HSTS preload list removals for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> Our dev team who manages the our public website has mistakenly
> configured the preload function + include_includesubdomains. This
> feature has blocked our internal websites as well, even if the don’t
> use SSL at all. :(
mpac.ca:
> Please remove mpac.ca from the HSTS preload list, as the header was
> added with the includeSubDomains flag by mistake. Both internal and
> external systems share the same apex domain, and it is not possible to
> move all internal systems to https in the near future.
truweight.in:
> Some of my sub-domains e.g. loseweight.truweight.in are actually
> hosted by third parties such as leadsquared, unbounce, which do not
> support https.
2e-systems.com:
> we incorrectly announced HSTS for the complete domain, but we are not
> yet ready, there are several internal sites available only over VPN
> that we forgot about, so if you can please remove us from the
> preloaded list.
macaque.io:
> We are using campaign monitor for our email marketing platform and
> utilising a vanity url of http://macmail.macaque.io. Because we cannot
> implement https on this platform we would like to be removed from the
> hsts preload list.
fless.co.uk:
> The domain fless.co.uk runs a url based dynamic proxy on multiple
> levels of subdomains so can't be covered by a wildcard certificate.
> While the fless.co.uk will return to using hsts once resolved, the
> subdomains can't be maintained with hsts.
==========
Description was changed from
==========
HSTS preload list removals for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> Our dev team who manages the our public website has mistakenly
> configured the preload function + include_includesubdomains. This
> feature has blocked our internal websites as well, even if the don’t
> use SSL at all. :(
mpac.ca:
> Please remove mpac.ca from the HSTS preload list, as the header was
> added with the includeSubDomains flag by mistake. Both internal and
> external systems share the same apex domain, and it is not possible to
> move all internal systems to https in the near future.
truweight.in:
> Some of my sub-domains e.g. loseweight.truweight.in are actually
> hosted by third parties such as leadsquared, unbounce, which do not
> support https.
2e-systems.com:
> we incorrectly announced HSTS for the complete domain, but we are not
> yet ready, there are several internal sites available only over VPN
> that we forgot about, so if you can please remove us from the
> preloaded list.
macaque.io:
> We are using campaign monitor for our email marketing platform and
> utilising a vanity url of http://macmail.macaque.io. Because we cannot
> implement https on this platform we would like to be removed from the
> hsts preload list.
fless.co.uk:
> The domain fless.co.uk runs a url based dynamic proxy on multiple
> levels of subdomains so can't be covered by a wildcard certificate.
> While the fless.co.uk will return to using hsts once resolved, the
> subdomains can't be maintained with hsts.
==========
to
==========
HSTS preload list removals for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> Our dev team who manages the our public website has mistakenly
> configured the preload function + include_includesubdomains. This
> feature has blocked our internal websites as well, even if the don’t
> use SSL at all. :(
mpac.ca:
> Please remove mpac.ca from the HSTS preload list, as the header was
> added with the includeSubDomains flag by mistake. Both internal and
> external systems share the same apex domain, and it is not possible to
> move all internal systems to https in the near future.
truweight.in:
> Some of my sub-domains e.g. loseweight.truweight.in are actually
> hosted by third parties such as leadsquared, unbounce, which do not
> support https.
2e-systems.com:
> we incorrectly announced HSTS for the complete domain, but we are not
> yet ready, there are several internal sites available only over VPN
> that we forgot about, so if you can please remove us from the
> preloaded list.
macaque.io:
> We are using campaign monitor for our email marketing platform and
> utilising a vanity url of http://macmail.macaque.io. Because we cannot
> implement https on this platform we would like to be removed from the
> hsts preload list.
fless.co.uk:
> The domain fless.co.uk runs a url based dynamic proxy on multiple
> levels of subdomains so can't be covered by a wildcard certificate.
> While the fless.co.uk will return to using hsts once resolved, the
> subdomains can't be maintained with hsts.
carthage.edu:
> we have a few subdomains that are not yet https and that is causing a
> bit of a stir.
matspar.com, matspar.se:
> One of our subdomains, exportera.matspar.se and exportera.matspar.com
> needs to be able to be served over http, we did not plan for this ever
> to be the case initially.
aiflab.com
> We don't want to HSTS preload all time. We will manually make https
> when we need. but, forcing HSTS preload is panic now-a-days.
rushball.net, hiphop.ren:
> these domains is no https now
==========
Description was changed from
==========
HSTS preload list removals for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> Our dev team who manages the our public website has mistakenly
> configured the preload function + include_includesubdomains. This
> feature has blocked our internal websites as well, even if the don’t
> use SSL at all. :(
mpac.ca:
> Please remove mpac.ca from the HSTS preload list, as the header was
> added with the includeSubDomains flag by mistake. Both internal and
> external systems share the same apex domain, and it is not possible to
> move all internal systems to https in the near future.
truweight.in:
> Some of my sub-domains e.g. loseweight.truweight.in are actually
> hosted by third parties such as leadsquared, unbounce, which do not
> support https.
2e-systems.com:
> we incorrectly announced HSTS for the complete domain, but we are not
> yet ready, there are several internal sites available only over VPN
> that we forgot about, so if you can please remove us from the
> preloaded list.
macaque.io:
> We are using campaign monitor for our email marketing platform and
> utilising a vanity url of http://macmail.macaque.io. Because we cannot
> implement https on this platform we would like to be removed from the
> hsts preload list.
fless.co.uk:
> The domain fless.co.uk runs a url based dynamic proxy on multiple
> levels of subdomains so can't be covered by a wildcard certificate.
> While the fless.co.uk will return to using hsts once resolved, the
> subdomains can't be maintained with hsts.
carthage.edu:
> we have a few subdomains that are not yet https and that is causing a
> bit of a stir.
matspar.com, matspar.se:
> One of our subdomains, exportera.matspar.se and exportera.matspar.com
> needs to be able to be served over http, we did not plan for this ever
> to be the case initially.
aiflab.com
> We don't want to HSTS preload all time. We will manually make https
> when we need. but, forcing HSTS preload is panic now-a-days.
rushball.net, hiphop.ren:
> these domains is no https now
==========
to
==========
HSTS preload list removals for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> Our dev team who manages the our public website has mistakenly
> configured the preload function + include_includesubdomains. This
> feature has blocked our internal websites as well, even if the don’t
> use SSL at all. :(
mpac.ca:
> Please remove mpac.ca from the HSTS preload list, as the header was
> added with the includeSubDomains flag by mistake. Both internal and
> external systems share the same apex domain, and it is not possible to
> move all internal systems to https in the near future.
truweight.in:
> Some of my sub-domains e.g. loseweight.truweight.in are actually
> hosted by third parties such as leadsquared, unbounce, which do not
> support https.
2e-systems.com:
> we incorrectly announced HSTS for the complete domain, but we are not
> yet ready, there are several internal sites available only over VPN
> that we forgot about, so if you can please remove us from the
> preloaded list.
macaque.io:
> We are using campaign monitor for our email marketing platform and
> utilising a vanity url of http://macmail.macaque.io. Because we cannot
> implement https on this platform we would like to be removed from the
> hsts preload list.
fless.co.uk:
> The domain fless.co.uk runs a url based dynamic proxy on multiple
> levels of subdomains so can't be covered by a wildcard certificate.
> While the fless.co.uk will return to using hsts once resolved, the
> subdomains can't be maintained with hsts.
carthage.edu:
> we have a few subdomains that are not yet https and that is causing a
> bit of a stir.
matspar.com, matspar.se:
> One of our subdomains, exportera.matspar.se and exportera.matspar.com
> needs to be able to be served over http, we did not plan for this ever
> to be the case initially.
aiflab.com
> We don't want to HSTS preload all time. We will manually make https
> when we need. but, forcing HSTS preload is panic now-a-days.
rushball.net, hiphop.ren:
> these domains is no https now
BUG=527947
==========
Description was changed from
==========
HSTS preload list removals for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> Our dev team who manages the our public website has mistakenly
> configured the preload function + include_includesubdomains. This
> feature has blocked our internal websites as well, even if the don’t
> use SSL at all. :(
mpac.ca:
> Please remove mpac.ca from the HSTS preload list, as the header was
> added with the includeSubDomains flag by mistake. Both internal and
> external systems share the same apex domain, and it is not possible to
> move all internal systems to https in the near future.
truweight.in:
> Some of my sub-domains e.g. loseweight.truweight.in are actually
> hosted by third parties such as leadsquared, unbounce, which do not
> support https.
2e-systems.com:
> we incorrectly announced HSTS for the complete domain, but we are not
> yet ready, there are several internal sites available only over VPN
> that we forgot about, so if you can please remove us from the
> preloaded list.
macaque.io:
> We are using campaign monitor for our email marketing platform and
> utilising a vanity url of http://macmail.macaque.io. Because we cannot
> implement https on this platform we would like to be removed from the
> hsts preload list.
fless.co.uk:
> The domain fless.co.uk runs a url based dynamic proxy on multiple
> levels of subdomains so can't be covered by a wildcard certificate.
> While the fless.co.uk will return to using hsts once resolved, the
> subdomains can't be maintained with hsts.
carthage.edu:
> we have a few subdomains that are not yet https and that is causing a
> bit of a stir.
matspar.com, matspar.se:
> One of our subdomains, exportera.matspar.se and exportera.matspar.com
> needs to be able to be served over http, we did not plan for this ever
> to be the case initially.
aiflab.com
> We don't want to HSTS preload all time. We will manually make https
> when we need. but, forcing HSTS preload is panic now-a-days.
rushball.net, hiphop.ren:
> these domains is no https now
BUG=527947
==========
to
==========
HSTS preload list removals for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> Our dev team who manages the our public website has mistakenly
> configured the preload function + include_includesubdomains. This
> feature has blocked our internal websites as well, even if the don’t
> use SSL at all. :(
mpac.ca:
> Please remove mpac.ca from the HSTS preload list, as the header was
> added with the includeSubDomains flag by mistake. Both internal and
> external systems share the same apex domain, and it is not possible to
> move all internal systems to https in the near future.
truweight.in:
> Some of my sub-domains e.g. loseweight.truweight.in are actually
> hosted by third parties such as leadsquared, unbounce, which do not
> support https.
2e-systems.com:
> we incorrectly announced HSTS for the complete domain, but we are not
> yet ready, there are several internal sites available only over VPN
> that we forgot about, so if you can please remove us from the
> preloaded list.
macaque.io:
> We are using campaign monitor for our email marketing platform and
> utilising a vanity url of http://macmail.macaque.io. Because we cannot
> implement https on this platform we would like to be removed from the
> hsts preload list.
fless.co.uk:
> The domain fless.co.uk runs a url based dynamic proxy on multiple
> levels of subdomains so can't be covered by a wildcard certificate.
> While the fless.co.uk will return to using hsts once resolved, the
> subdomains can't be maintained with hsts.
carthage.edu:
> we have a few subdomains that are not yet https and that is causing a
> bit of a stir.
matspar.com, matspar.se:
> One of our subdomains, exportera.matspar.se and exportera.matspar.com
> needs to be able to be served over http, we did not plan for this ever
> to be the case initially.
aiflab.com
> We don't want to HSTS preload all time. We will manually make https
> when we need. but, forcing HSTS preload is panic now-a-days.
rushball.net, hiphop.ren:
> these domains is no https now
lightspeed.com:
> We initially included this for all subdomains but that affects
> internal servers we have that don’t have ssl certificates required.
ceu.edu:
> [...] we wanted to force browsers to use https when visiting our main
> website. However we now see that unfortunately we have some other
> subdomains on other web servers where implementation of SSL is
> problematic or delayed, and in the new version of chrome these sites
> do not load.
end.io:
> Please can you remove it as I am the webmaster and it is breaking the
> site.
alastyr.com:
> We use this domain our main domain for hosting services, we provide to
> customer non-ssl web services, customers did not connect via Chrome or similar
> web browsers.
mobocasino.com:
>I'd like to remove us because we employ subdomains (other than www) over http
>which we cannot serve over https for cost reasons.
compuscan.co.za:
> We have a few services running internally on HTTP and HSTS is “breaking” this
> for us via Chrome browsers.
No citable reason for the following. :-()
- wover.me
- ono.es
BUG=527947
TBR=palmer@chromium.org
==========
Message was sent while issue was closed.
Description was changed from
==========
HSTS preload list removals for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> Our dev team who manages the our public website has mistakenly
> configured the preload function + include_includesubdomains. This
> feature has blocked our internal websites as well, even if the don’t
> use SSL at all. :(
mpac.ca:
> Please remove mpac.ca from the HSTS preload list, as the header was
> added with the includeSubDomains flag by mistake. Both internal and
> external systems share the same apex domain, and it is not possible to
> move all internal systems to https in the near future.
truweight.in:
> Some of my sub-domains e.g. loseweight.truweight.in are actually
> hosted by third parties such as leadsquared, unbounce, which do not
> support https.
2e-systems.com:
> we incorrectly announced HSTS for the complete domain, but we are not
> yet ready, there are several internal sites available only over VPN
> that we forgot about, so if you can please remove us from the
> preloaded list.
macaque.io:
> We are using campaign monitor for our email marketing platform and
> utilising a vanity url of http://macmail.macaque.io. Because we cannot
> implement https on this platform we would like to be removed from the
> hsts preload list.
fless.co.uk:
> The domain fless.co.uk runs a url based dynamic proxy on multiple
> levels of subdomains so can't be covered by a wildcard certificate.
> While the fless.co.uk will return to using hsts once resolved, the
> subdomains can't be maintained with hsts.
carthage.edu:
> we have a few subdomains that are not yet https and that is causing a
> bit of a stir.
matspar.com, matspar.se:
> One of our subdomains, exportera.matspar.se and exportera.matspar.com
> needs to be able to be served over http, we did not plan for this ever
> to be the case initially.
aiflab.com
> We don't want to HSTS preload all time. We will manually make https
> when we need. but, forcing HSTS preload is panic now-a-days.
rushball.net, hiphop.ren:
> these domains is no https now
lightspeed.com:
> We initially included this for all subdomains but that affects
> internal servers we have that don’t have ssl certificates required.
ceu.edu:
> [...] we wanted to force browsers to use https when visiting our main
> website. However we now see that unfortunately we have some other
> subdomains on other web servers where implementation of SSL is
> problematic or delayed, and in the new version of chrome these sites
> do not load.
end.io:
> Please can you remove it as I am the webmaster and it is breaking the
> site.
alastyr.com:
> We use this domain our main domain for hosting services, we provide to
> customer non-ssl web services, customers did not connect via Chrome or similar
> web browsers.
mobocasino.com:
>I'd like to remove us because we employ subdomains (other than www) over http
>which we cannot serve over https for cost reasons.
compuscan.co.za:
> We have a few services running internally on HTTP and HSTS is “breaking” this
> for us via Chrome browsers.
No citable reason for the following. :-()
- wover.me
- ono.es
BUG=527947
TBR=palmer@chromium.org
==========
to
==========
HSTS preload list removals for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> Our dev team who manages the our public website has mistakenly
> configured the preload function + include_includesubdomains. This
> feature has blocked our internal websites as well, even if the don’t
> use SSL at all. :(
mpac.ca:
> Please remove mpac.ca from the HSTS preload list, as the header was
> added with the includeSubDomains flag by mistake. Both internal and
> external systems share the same apex domain, and it is not possible to
> move all internal systems to https in the near future.
truweight.in:
> Some of my sub-domains e.g. loseweight.truweight.in are actually
> hosted by third parties such as leadsquared, unbounce, which do not
> support https.
2e-systems.com:
> we incorrectly announced HSTS for the complete domain, but we are not
> yet ready, there are several internal sites available only over VPN
> that we forgot about, so if you can please remove us from the
> preloaded list.
macaque.io:
> We are using campaign monitor for our email marketing platform and
> utilising a vanity url of http://macmail.macaque.io. Because we cannot
> implement https on this platform we would like to be removed from the
> hsts preload list.
fless.co.uk:
> The domain fless.co.uk runs a url based dynamic proxy on multiple
> levels of subdomains so can't be covered by a wildcard certificate.
> While the fless.co.uk will return to using hsts once resolved, the
> subdomains can't be maintained with hsts.
carthage.edu:
> we have a few subdomains that are not yet https and that is causing a
> bit of a stir.
matspar.com, matspar.se:
> One of our subdomains, exportera.matspar.se and exportera.matspar.com
> needs to be able to be served over http, we did not plan for this ever
> to be the case initially.
aiflab.com
> We don't want to HSTS preload all time. We will manually make https
> when we need. but, forcing HSTS preload is panic now-a-days.
rushball.net, hiphop.ren:
> these domains is no https now
lightspeed.com:
> We initially included this for all subdomains but that affects
> internal servers we have that don’t have ssl certificates required.
ceu.edu:
> [...] we wanted to force browsers to use https when visiting our main
> website. However we now see that unfortunately we have some other
> subdomains on other web servers where implementation of SSL is
> problematic or delayed, and in the new version of chrome these sites
> do not load.
end.io:
> Please can you remove it as I am the webmaster and it is breaking the
> site.
alastyr.com:
> We use this domain our main domain for hosting services, we provide to
> customer non-ssl web services, customers did not connect via Chrome or similar
> web browsers.
mobocasino.com:
>I'd like to remove us because we employ subdomains (other than www) over http
>which we cannot serve over https for cost reasons.
compuscan.co.za:
> We have a few services running internally on HTTP and HSTS is “breaking” this
> for us via Chrome browsers.
No citable reason for the following. :-()
- wover.me
- ono.es
BUG=527947
TBR=palmer@chromium.org
Committed: https://crrev.com/d2bdb307d12f0ed4ae4296b72795342f53d11743
Cr-Commit-Position: refs/heads/master@{#394582}
==========
Message was sent while issue was closed.
Patchset 7 (id:??) landed as https://crrev.com/d2bdb307d12f0ed4ae4296b72795342f53d11743 Cr-Commit-Position: refs/heads/master@{#394582}
Message was sent while issue was closed.
Description was changed from
==========
HSTS preload list removals for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> Our dev team who manages the our public website has mistakenly
> configured the preload function + include_includesubdomains. This
> feature has blocked our internal websites as well, even if the don’t
> use SSL at all. :(
mpac.ca:
> Please remove mpac.ca from the HSTS preload list, as the header was
> added with the includeSubDomains flag by mistake. Both internal and
> external systems share the same apex domain, and it is not possible to
> move all internal systems to https in the near future.
truweight.in:
> Some of my sub-domains e.g. loseweight.truweight.in are actually
> hosted by third parties such as leadsquared, unbounce, which do not
> support https.
2e-systems.com:
> we incorrectly announced HSTS for the complete domain, but we are not
> yet ready, there are several internal sites available only over VPN
> that we forgot about, so if you can please remove us from the
> preloaded list.
macaque.io:
> We are using campaign monitor for our email marketing platform and
> utilising a vanity url of http://macmail.macaque.io. Because we cannot
> implement https on this platform we would like to be removed from the
> hsts preload list.
fless.co.uk:
> The domain fless.co.uk runs a url based dynamic proxy on multiple
> levels of subdomains so can't be covered by a wildcard certificate.
> While the fless.co.uk will return to using hsts once resolved, the
> subdomains can't be maintained with hsts.
carthage.edu:
> we have a few subdomains that are not yet https and that is causing a
> bit of a stir.
matspar.com, matspar.se:
> One of our subdomains, exportera.matspar.se and exportera.matspar.com
> needs to be able to be served over http, we did not plan for this ever
> to be the case initially.
aiflab.com
> We don't want to HSTS preload all time. We will manually make https
> when we need. but, forcing HSTS preload is panic now-a-days.
rushball.net, hiphop.ren:
> these domains is no https now
lightspeed.com:
> We initially included this for all subdomains but that affects
> internal servers we have that don’t have ssl certificates required.
ceu.edu:
> [...] we wanted to force browsers to use https when visiting our main
> website. However we now see that unfortunately we have some other
> subdomains on other web servers where implementation of SSL is
> problematic or delayed, and in the new version of chrome these sites
> do not load.
end.io:
> Please can you remove it as I am the webmaster and it is breaking the
> site.
alastyr.com:
> We use this domain our main domain for hosting services, we provide to
> customer non-ssl web services, customers did not connect via Chrome or similar
> web browsers.
mobocasino.com:
>I'd like to remove us because we employ subdomains (other than www) over http
>which we cannot serve over https for cost reasons.
compuscan.co.za:
> We have a few services running internally on HTTP and HSTS is “breaking” this
> for us via Chrome browsers.
No citable reason for the following. :-()
- wover.me
- ono.es
BUG=527947
TBR=palmer@chromium.org
Committed: https://crrev.com/d2bdb307d12f0ed4ae4296b72795342f53d11743
Cr-Commit-Position: refs/heads/master@{#394582}
==========
to
==========
HSTS preload list removals for Chrome 52.
Reasons given:
sixt.{ch, co.uk, com, com.br, de}:
> These HSTS headers (includeSubdomains and preload) were set without
> thinking about the consequences in our IT infrastructure and the
> affected external hosted sites.
apiomat.com:
> we need to be removed from the Chrome's preload list as soon as
> possible, because some of our subdomains don't have HTTPS. Those are
> mostly for internal use and so there is no need the use HTTPS (cost
> reasons). We only wanted to use HSTS for our main domain (apiomat.com)
> but not for the subdomains.
flanco.ro:
> Our dev team who manages the our public website has mistakenly
> configured the preload function + include_includesubdomains. This
> feature has blocked our internal websites as well, even if the don’t
> use SSL at all. :(
mpac.ca:
> Please remove mpac.ca from the HSTS preload list, as the header was
> added with the includeSubDomains flag by mistake. Both internal and
> external systems share the same apex domain, and it is not possible to
> move all internal systems to https in the near future.
truweight.in:
> Some of my sub-domains e.g. loseweight.truweight.in are actually
> hosted by third parties such as leadsquared, unbounce, which do not
> support https.
2e-systems.com:
> we incorrectly announced HSTS for the complete domain, but we are not
> yet ready, there are several internal sites available only over VPN
> that we forgot about, so if you can please remove us from the
> preloaded list.
macaque.io:
> We are using campaign monitor for our email marketing platform and
> utilising a vanity url of http://macmail.macaque.io. Because we cannot
> implement https on this platform we would like to be removed from the
> hsts preload list.
fless.co.uk:
> The domain fless.co.uk runs a url based dynamic proxy on multiple
> levels of subdomains so can't be covered by a wildcard certificate.
> While the fless.co.uk will return to using hsts once resolved, the
> subdomains can't be maintained with hsts.
carthage.edu:
> we have a few subdomains that are not yet https and that is causing a
> bit of a stir.
matspar.com, matspar.se:
> One of our subdomains, exportera.matspar.se and exportera.matspar.com
> needs to be able to be served over http, we did not plan for this ever
> to be the case initially.
aiflab.com
> We don't want to HSTS preload all time. We will manually make https
> when we need. but, forcing HSTS preload is panic now-a-days.
rushball.net, hiphop.ren:
> these domains is no https now
lightspeed.com:
> We initially included this for all subdomains but that affects
> internal servers we have that don’t have ssl certificates required.
ceu.edu:
> [...] we wanted to force browsers to use https when visiting our main
> website. However we now see that unfortunately we have some other
> subdomains on other web servers where implementation of SSL is
> problematic or delayed, and in the new version of chrome these sites
> do not load.
end.io:
> Please can you remove it as I am the webmaster and it is breaking the
> site.
alastyr.com:
> We use this domain our main domain for hosting services, we provide to
> customer non-ssl web services, customers did not connect via Chrome or similar
> web browsers.
mobocasino.com:
>I'd like to remove us because we employ subdomains (other than www) over http
>which we cannot serve over https for cost reasons.
compuscan.co.za:
> We have a few services running internally on HTTP and HSTS is “breaking” this
> for us via Chrome browsers.
No citable reason for the following. :-()
- wover.me
- ono.es
BUG=527947
TBR=palmer@chromium.org
Committed:
https://chromium.googlesource.com/chromium/src/+/d2bdb307d12f0ed4ae4296b72795...
==========
Message was sent while issue was closed.
Committed patchset #7 (id:120001) manually as d2bdb307d12f0ed4ae4296b72795342f53d11743 (presubmit successful).
Message was sent while issue was closed.
Note: due to Rietveld limitations, this CL does not show an update to transport_security_state_static.h However, the commit includes the update to both files. |
