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

Review URL: https://codereview.chromium.org/1888913004 .

Cr-Commit-Position: refs/heads/master@{#394582}
2 files changed