Requesting a merge of https://chromium.googlesource.com/chromium/src.git/+/c2ed5d4ef0dc5dbb94240dadb56a08c2a3f7c9b0 to Chrome 53

Reasoning (copied from  https://crbug.com/601561#c2 ):
Although the commits contain a large diff of static data, this data is auto-generated using a process that has been working reliably for the last 2 years. Therefore, the merge is semantically equivalent to removing just the given sites from transport_security_state_static.json.

(As mentioned in the first commit, this is the fourth time for such a merge commit. The three previous times went without any issues)

Approving merge to M53 branch 2785 based on comment #1. Please merge ASAP or latest before tomorrow, Tuesday 3:00 PM PT in order to make into the desktop Stable final build cut. Thank you.

Merging to branch 2785 right now. This is a regular process, so the commit will apply cleanly and should not cause any problems.

(Sorry for cutting it a bit close this time. By my normal timeline, I would have done this last Thursday/Friday, but I had some other urgent work.)

Thank you lgarron@.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e59c79cf665c789b3a66fb2121262ef9e8dc9900

commit e59c79cf665c789b3a66fb2121262ef9e8dc9900
Author: Lucas Garron <lgarron@chromium.org>
Date: Tue Aug 30 05:09:59 2016

HSTS preload list removals for Chrome 54.

ecosystem.atlassian.net:
Covered by atlassian.net

redbee.nl:
> We cannot support HTTPS on the following subdomains:
> • staging.schoolwijzer.redbee.nl - Customer staging environment, out of
> our control and just for testing purposes.

cerfrance.fr:
> We cannot support HTTPS on the following subdomains:
> • link.85.cerfrance.fr – use by a email marketing service (sarbacane)
> • link.cn.cerfrance.fr – use by a email marketing service (sarbacane)

spacecompute.com:
> I have no idea how this happened, since I never submitted the domain, but I
> would like to remove it because unfortunately it's breaking some services that
> integrate with google apps -- which it turns out do not play well with HTTPS
> requests.

ptsoft.de:
> We cannot support HTTPS on the following subdomains:
>
> • dm8000.ptsoft.de - Forwarding to internal server
> • config.ptsoft.de - Forwarding to internal server

everythingkitchens.com:
[15 subdomains] hosted on separate server than main domain

hilti.com, etc. (25 hilti.{eTLD} domains):
internal systems with same domain hilti.com do not all support https yet

souyidai.com:
> We cannot support HTTPS on the following subdomains:
> • mail.souyidai.com - cooperation with other company

nitho.me:
> I am afraid that it due to that blindly following online tutorial.

hovie.at:
> We cannot support HTTPS on the following subdomains:
>
> • andrew.hovie.at - I don't have to time to manage my own server
> anymore, so I switched to a hosting provider, wildcard certs are
> expensive, they do not support certs with multiple domains.
>
> Also, when I enabled preload, I did not actually know what I am doing,
> I was just following the recommendation from https://cipherli.st/.

constructdigital.net:
> We cannot support HTTPS on all sub-subdomains, since we don't have a wildcard
> SSL for them. Also, this domain is meant for development purpose and was
> configured as HSTS preload by mistake.

groovinads.com:
> We cannot support HTTPS on the following subdomains:
> • my.groovinads.com - Appnexus does not handshake over https, and it's killing us.
> • groovinads.com - same as above
> • *.groovinads.com

shamka.ru:
> We cannot support HTTPS on the following subdomains:
>
> • [water] - don’t have ssl cert.
> • [w] - not open 443 port
> • and many new subdomains

terravirtua.com:
> chalk it up to copy-pasting something without fully understanding what i was
> doing... i had added that after doing the ssl checker, following a
> recommendation about increasing the 'grade' it returned. i later removed it
> (the whole HSTS header) only to discover that everything continued to redirect
> to https... and finally realizing i was preloaded.

domainkauf.de:
> We support HTTPS in another way and so we have problems with the following
> subdomains:
> • mail.domainkauf.de HTTP Redirect to the main mailserver
> • imap /smtp / pop / pop3 / webmail with same reason

internl.net:
Uses uniquely generated domains per user with second-level subdomains, e.g. www.*.pa.internl.net; this can't be handled using wildcard certs.

rinobroer.nl:
No citable reason given.

sexton.uk.com:
> We cannot support HTTPS on the following subdomains:
>
> • mail.sexton.uk.com - costs for multiple SSL or SAN cert
> • webmail.sexton.uk.com - costs for multiple SSL or SAN cert

extracobanks.com:
> We cannot support HTTPS on the following subdomains:
>
> • Various internal subdomains - Although our external website,
> www.extracobanks.com, exclusively uses HTTPS, we also use extracobanks.com as
> our internal domain.  Having extracobanks.com on the HSTS preload list is
> causing problems for our employees connecting to internal sites, such as our
> internal CRM that uses a self-signed certificate.  Chrome and Firefox are
> giving "certificate authority invalid" errors when connecting to these
> internal subdomains.  We also have some non-HTTPS 3rd party vendor provided
> internal sites that cannot be changed to HTTPS that we cannot connect to at
> all.
>
> Our www.extracobanks.com site was built and is managed by a 3rd party
> Marketing firm.  I'm sure they added the HSTS header with the best intentions,
> but it is causing issues for us internally with our employees.

intramanager.co.uk/intramanager.dk:
> We cannot support HTTPS on the domain, since we changed our whole SSL setup
> and therefore do not support HTTPS on the intramanager.co.uk
> [/intramanager.dk] domain anymore.
>
> We have moved all activity to intramanager.com, where we have full HTTPS
> support.

thekelvinliu.com:
> I have a Tumblr blog at blog.thekelvinliu.com, which does not support https.

h-neef.de:
> We cannot support HTTPS on the whole Domain including subdomains, because we
> moved to a new IP Address and Need it for test purposes!

nathancheek.com:
> I never intended to be preloaded, nor to include subdomains, but I made the
> mistake of adding ‘preload’ and 'includeSubDomains’ to the HSTS header,
> without understanding what they entailed.

mercurystorm.co.za:
> I have moved from a Virtual Private Server to shared hosting, and can no
> longer use SSL certificates

klaxn.com:
> my client is not able to pay for a SSL certificate

postpi.com:
> self signed certificate

stupus.com:
> We cannot always support HTTPS on the all of our subdomains.
> ...
> I can no longer always support HTTPS on my domain because I change server
> distributions frequently.

upstox.com:
> We cannot support HTTPS on the following subdomain:
>
> help.upstox.com -> We are using this domain to point help.rksv.in with CNAME
> record and for rksv.in domain we don't have Wildcard SSL certificate so
> whenever we open help.upstox.com it goes to HTTPS in chrome.

TBR=palmer@chromium.org
BUG= 527947 ,  641449 

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

Cr-Commit-Position: refs/heads/master@{#414299}
(cherry picked from commit c2ed5d4ef0dc5dbb94240dadb56a08c2a3f7c9b0)

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

Cr-Commit-Position: refs/branch-heads/2785@{#787}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/e59c79cf665c789b3a66fb2121262ef9e8dc9900/net/http/transport_security_state_static.h
[modify] https://crrev.com/e59c79cf665c789b3a66fb2121262ef9e8dc9900/net/http/transport_security_state_static.json