Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 527947 ☂ HSTS Preload List Removals
Starred by 7 users Project Member Reported by lgar...@chromium.org, Sep 3 2015 Back to list
Status: Fixed
Owner: ----
Closed: Sep 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocking:
issue 587954


Participants' hotlists:
HSTS-Preload


Sign in to add a comment
I've seen a recent uptick in the number of sites who ask to be removed from the HSTS preload list.
While we make the consequences of signing up to be preloaded quite clear, we honor webmaster requests for removal if there were unforeseen issues. This is a meta-bug to capture those reasons so that we can learn from them.

cs50.harvard.edu, cs50.net (crrev.com/456c9c2e03d)

friendlink.jp ( Issue 480785 )

golf3.de, golf4.de, golf-6.com ( Issue 468992 )

movelaria.com.br ( Issue 467486 )

wideup.net: "Apparently someone inadvertently add my site to this list." ( Issue 492531 )

uber.com: Issues with subdomains maintained by contractors. ( Issue 515318 )

delbart.se: "A month into the project, we realised that SSL made our ad income significantly lower, since lot's of the premium advertisers in my country apparently isn't providing secure scripts." ( Issue 527817 )

carbonmade.com: didn't realize that multiple-level wildcards like *.*.carbonmade.com are not supported by browsers ( Issue 518717 )

snowflake.ch: Needs to support third-level internal subdomains. ( Issue 487251 )

keycom.co.uk: "4th level subdomains are affected by HSTS also which as an unforeseen circumstance prevents some of our internal sites from working" ( Issue 517848 )

 
Blockedon: chromium:446240
Not a full HSTS removal, but crypto.cat had remove pinning (446240).
Project Member Comment 3 by bugdroid1@chromium.org, Sep 11 2015
Summary: ☂ HSTS Preload List Removals and Edits (was: ☂ HSTS Preload List Removals)
Project Member Comment 5 by bugdroid1@chromium.org, Sep 16 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0bc4f38cfe0d4a47c3d1d3031de0035b8600fd4c

commit 0bc4f38cfe0d4a47c3d1d3031de0035b8600fd4c
Author: lgarron <lgarron@chromium.org>
Date: Wed Sep 16 20:06:03 2015

Remove `includeSubDomains` directive for vino75.com in the HSTS preload list.

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#349203}

[modify] http://crrev.com/0bc4f38cfe0d4a47c3d1d3031de0035b8600fd4c/net/http/transport_security_state_static.h
[modify] http://crrev.com/0bc4f38cfe0d4a47c3d1d3031de0035b8600fd4c/net/http/transport_security_state_static.json

Project Member Comment 6 by bugdroid1@chromium.org, Sep 16 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0ce00a2b6a186d6bff73a6e57b7d5d4adc3e28d6

commit 0ce00a2b6a186d6bff73a6e57b7d5d4adc3e28d6
Author: lgarron <lgarron@chromium.org>
Date: Wed Sep 16 22:28:17 2015

Change the preload list entry for vino75.com to www.vino75.com .

VINO75 would actually prefer to preload only the `www` subdomain at the moment.

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#349256}

[modify] http://crrev.com/0ce00a2b6a186d6bff73a6e57b7d5d4adc3e28d6/net/http/transport_security_state_static.h
[modify] http://crrev.com/0ce00a2b6a186d6bff73a6e57b7d5d4adc3e28d6/net/http/transport_security_state_static.json

Project Member Comment 7 by bugdroid1@chromium.org, Sep 24 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e5ca8571b9009b6a8592d7fc8c8fb8201cbaf366

commit e5ca8571b9009b6a8592d7fc8c8fb8201cbaf366
Author: lgarron <lgarron@chromium.org>
Date: Thu Sep 24 00:31:08 2015

Update there HSTS preload list entry for guidetoiceland.is to include_subdomains: false.

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#350416}

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

Project Member Comment 8 by bugdroid1@chromium.org, Sep 30 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4f59451cae2e7a67342ad29201177435e07c93b3

commit 4f59451cae2e7a67342ad29201177435e07c93b3
Author: lgarron <lgarron@chromium.org>
Date: Wed Sep 30 05:25:19 2015

Remove astaxi.net from the HSTS preload list.

(By request from the domain.)

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#351498}

[modify] http://crrev.com/4f59451cae2e7a67342ad29201177435e07c93b3/net/http/transport_security_state_static.h
[modify] http://crrev.com/4f59451cae2e7a67342ad29201177435e07c93b3/net/http/transport_security_state_static.json

Project Member Comment 9 by bugdroid1@chromium.org, Oct 8 2015
Project Member Comment 10 by bugdroid1@chromium.org, Oct 14 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cf50d03e45e9eb3a8dd21b2594bd11af287e2fc3

commit cf50d03e45e9eb3a8dd21b2594bd11af287e2fc3
Author: lgarron <lgarron@chromium.org>
Date: Wed Oct 14 22:01:30 2015

Remove include_subdomains from branchtrack.com.

Reason given: branchtrack.com is "using tumblr with subdomain, but it's not supported over https."

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#354126}

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

Project Member Comment 11 by bugdroid1@chromium.org, Oct 22 2015
Blockedon: chromium:546149
etoprekrasno.ru: "We had to switch to Wix hosting which doesn't support HTTPS on custom domains."
Project Member Comment 13 by bugdroid1@chromium.org, Nov 4 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dd1011ede413980ee8b4ca9690abfd047ae1708a

commit dd1011ede413980ee8b4ca9690abfd047ae1708a
Author: lgarron <lgarron@chromium.org>
Date: Wed Nov 04 01:01:37 2015

Remove subdomains from segurosocial.gov, socialsecurity.gov, and ssa.gov HSTS preload entries.

Reason given: "The problem is that many of our *intranet* sites are not HTTPS, and we are seeing issues in our rollout."

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#357692}

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

Project Member Comment 14 by bugdroid1@chromium.org, Nov 20 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c849e9a22b326edb57306f63b4a1cb5707d10c79

commit c849e9a22b326edb57306f63b4a1cb5707d10c79
Author: lgarron <lgarron@chromium.org>
Date: Fri Nov 20 00:10:28 2015

Remove formationsfactory.co.uk from the HSTS preload list.

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#360690}

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

https://codereview.chromium.org/1503253003/

Remove haber1903.com and taskstream.com from the HSTS preload list.

Reason given by taskstream.com:
"Unfortunately, we overlooked one of our subdomains: www2.taskstream.com
which is managed by our Marketing Department and points to
www.pardot.com. Pardot does not currently take certificates to install
on their site, and we’ve found them to generally not be very responsive.
This has caused no end of headaches for us and at this time, we need to
request to be removed from the HSTS list."

TBR=agl@chromium.org

Committed: https://crrev.com/ae9c26b83ab496cf485d2921196b5d882f5e6992
Cr-Commit-Position: refs/heads/master@{#363666}
Project Member Comment 16 by bugdroid1@chromium.org, Dec 10 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c144c467ae73266dfaca1ba3a846da9477000c6c

commit c144c467ae73266dfaca1ba3a846da9477000c6c
Author: lgarron <lgarron@chromium.org>
Date: Thu Dec 10 04:39:08 2015

HSTS preload list: do not include subdomains for flipagram.com .

Reason given:

> Some time ago, I launched HSTS on flipagram.com and submitted it to the
> preload app with the includeSubdomains property set in the header.
> Unfortunately, I did not realize the full implications of including this
> flag until recently. Our engineering team cannot reach many of our
> internal subdomains because they are only reachable with http.

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#364277}

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

Project Member Comment 17 by bugdroid1@chromium.org, Dec 11 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e4bbbe82b5d6569caafea274801ef2b268778e8b

commit e4bbbe82b5d6569caafea274801ef2b268778e8b
Author: lgarron <lgarron@chromium.org>
Date: Fri Dec 11 23:08:03 2015

Remove attotech.net from the HSTS preload list.

The site operator believes that they never requested to be added.
It's still unclear how they ended up on the list unintentionally, since
they were added through hstspreload.appspot.com (which requires sending
an explicit `preload` token in an HSTS header from the root path).

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#364828}

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

Project Member Comment 18 by bugdroid1@chromium.org, Dec 23 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/478c38b0a9665bfa8de925bf0a93403f18f04cbb

commit 478c38b0a9665bfa8de925bf0a93403f18f04cbb
Author: lgarron <lgarron@chromium.org>
Date: Wed Dec 23 06:11:58 2015

Stop including subdomains for woima.fi in the HSTS preload list.

By request of the site operator.

(Note: This CL also fixes a comment indentation that was thrown out of whack by crrev.com/1535363003 . This is fixed in https://github.com/agl/transport-security-state-generate/pull/11 )

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#366709}

[modify] http://crrev.com/478c38b0a9665bfa8de925bf0a93403f18f04cbb/net/http/transport_security_state_static.h
[modify] http://crrev.com/478c38b0a9665bfa8de925bf0a93403f18f04cbb/net/http/transport_security_state_static.json

Blockedon: chromium:576249
Project Member Comment 20 by bugdroid1@chromium.org, Jan 14 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2cb6a94651373c776b4a4d75a9f916e76d4f5021

commit 2cb6a94651373c776b4a4d75a9f916e76d4f5021
Author: lgarron <lgarron@chromium.org>
Date: Thu Jan 14 20:08:08 2016

Remove o7.com, lucameraga.it, hostelinsplit.com, and kotarac.net from the HSTS preload list.

o7.com: "our domain was incorrectly submited to the HSTS list" (broke www.smp-31.o7.com)
lucameraga.it: tried HSTS on CloudFlare, changed their mind
kotarac.net, hostelinsplit.com: "noticed an issue [with subdomains] in the latest dev build."

BUG= 527947 ,  576249 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#369520}

[modify] http://crrev.com/2cb6a94651373c776b4a4d75a9f916e76d4f5021/net/http/transport_security_state_static.h
[modify] http://crrev.com/2cb6a94651373c776b4a4d75a9f916e76d4f5021/net/http/transport_security_state_static.json

There isn't a bug for this, but frankonia-bruenn.at asked to be removed from the pending queue (which is certainly a much better time to ask to be removed than after you land in the source code).
Project Member Comment 22 by bugdroid1@chromium.org, Jan 28 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2c181779d183055de81df4c6fff5397a577a02ad

commit 2c181779d183055de81df4c6fff5397a577a02ad
Author: lgarron <lgarron@chromium.org>
Date: Thu Jan 28 00:44:32 2016

Remove four domains from the HSTS preload list.

- ecobee.com: "I just noticed that this is actually a problem for us as we have some external sub-domains that are unable to support HTTPS at this time."
- emilstahl.dk: Has only been on the list one week; asked to be removed.
- liftcannabis.ca: "Unfortunately we found a few edge cases where HSTS is causing problems."
- mbdb.jp:  https://crbug.com/580764 

BUG= 527947 ,  580764 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#371942}

[modify] http://crrev.com/2c181779d183055de81df4c6fff5397a577a02ad/net/http/transport_security_state_static.h
[modify] http://crrev.com/2c181779d183055de81df4c6fff5397a577a02ad/net/http/transport_security_state_static.json

Project Member Comment 23 by bugdroid1@chromium.org, Feb 5 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8e25991b8a2839274c5e528aea165236015776ad

commit 8e25991b8a2839274c5e528aea165236015776ad
Author: lgarron <lgarron@chromium.org>
Date: Fri Feb 05 23:07:03 2016

Remove myfrm.org from the HSTS preload list.

Reason given by site operator: "My site is longer HTTPS not supported."

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#373936}

[modify] http://crrev.com/8e25991b8a2839274c5e528aea165236015776ad/net/http/transport_security_state_static.h
[modify] http://crrev.com/8e25991b8a2839274c5e528aea165236015776ad/net/http/transport_security_state_static.json

Project Member Comment 24 by bugdroid1@chromium.org, Feb 11 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dea3168945b6e701b2d8bf9a8f2d41220096b519

commit dea3168945b6e701b2d8bf9a8f2d41220096b519
Author: lgarron <lgarron@chromium.org>
Date: Thu Feb 11 02:23:49 2016

Remove sol.io from the HSTS preload list.

The site was added to the list in 2012. It became stale and the new site owner asked for it to be removed.

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#374836}

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

Project Member Comment 25 by bugdroid1@chromium.org, Feb 14 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/60e8ef9f1a6281d40ae07928ce73ed570f37a479

commit 60e8ef9f1a6281d40ae07928ce73ed570f37a479
Author: lgarron <lgarron@chromium.org>
Date: Sun Feb 14 05:17:43 2016

Remove emilstahl.dk and liftcannabis.ca from the HSTS preload list.

These were supposed to be removed in https://codereview.chromium.org/1640963002
but were accidentally not included.

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#375379}

[modify] http://crrev.com/60e8ef9f1a6281d40ae07928ce73ed570f37a479/net/http/transport_security_state_static.h
[modify] http://crrev.com/60e8ef9f1a6281d40ae07928ce73ed570f37a479/net/http/transport_security_state_static.json

Blockedon: chromium:587829
Blockedon: 587470
Cc: -timwillis@chromium.org -agl@chromium.org -palmer@chromium.org
Blockedon: 584307
Blockedon: -584307
Blockedon: 584307
e567d3252aa1cb923e049dd1e84e32f4472b36e6

rememberthemilk.io: "We're not able to get a bunch of SaaS hosted stuff to use HTTPS which live on subdomains (blog. runs on Tumblr, status. runs on StatusPage.io, etc and they don't support SSL)."

In particular, StatusPage.io does not support HTTPS on custom domains for less than $400/month (https://www.statuspage.io/pricing).
Blocking: 587954
Project Member Comment 34 by bugdroid1@chromium.org, Feb 27 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ffa3929a4e0ae37070c41abac63406efc0ffe5ae

commit ffa3929a4e0ae37070c41abac63406efc0ffe5ae
Author: Lucas Garron <lgarron@chromium.org>
Date: Sat Feb 27 01:33:42 2016

Remove a few sites from the HSTS preload list.

Bugs and reasons:

BUG= 587470 
spira.io: "our domain was incorrectly submited to the HSTS list in the website https://spira.io/, we want that our domain be removed as quickly as possible, because our customers are unable to access our domain"

BUG= 584307 
natukusa.com: "Our domain was incorrectly submited to the HSTS list in the website HSTS Preload Submission"

BUG=(none)
popcorntime.ws: "I, personally, did not ask for this, and would like to be removed, as
all subdomains are broken because we don't have a certificate for them."

BUG= 527947 
TBR=agl@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#378059}

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

Labels: Hotlist-HSTS-Preload-Removals Hotlist-HSTS-Preload
Blockedon: -446240 -468992 -584307 -546149 -527817 -587470 -480785 -487251 -587829 -515318 -517848 -576249 -518717 -467486 -492531
I'm removing all blockers in favor of the Hotlist-HSTS-Preload-Removals label.
Use the following link to search for view removal bugs:

Open Issues:
https://bugs.chromium.org/p/chromium/issues/list?q=label%3AHotlist-HSTS-Preload-Removals

All Issues
https://bugs.chromium.org/p/chromium/issues/list?can=1&q=label%3AHotlist-HSTS-Preload-Removals
Project Member Comment 37 by bugdroid1@chromium.org, Mar 8 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/97d372c2bc6233832ee573db666579ea15209430

commit 97d372c2bc6233832ee573db666579ea15209430
Author: lgarron <lgarron@chromium.org>
Date: Tue Mar 08 23:17:08 2016

Remove idealsvdr.com from the HSTS preload list.

Reason given:
"Unfortunately, we have two 3rd-party services linked over cnames [...]
that cannot be used over https as their 3rd party certificates [...] do
not include our domain."

BUG= 527947 

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

Cr-Commit-Position: refs/heads/master@{#379961}

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

Project Member Comment 38 by bugdroid1@chromium.org, Apr 7 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/253102d2f4b59a803816d2567233a5823ab5d782

commit 253102d2f4b59a803816d2567233a5823ab5d782
Author: lgarron <lgarron@chromium.org>
Date: Thu Apr 07 21:11:53 2016

Remove several domains from the HSTS preload list and remove an extra space.

videomail.io:
> I mistakenly used this code for helmet, a npm package to set various
> HTTP headers:
>
> ```
>         app.use(helmet.hsts({
>           maxAge:            108864000000, // Must be at least 18 weeks to be approved by Google
>           preload:           true
>         }))
> ```
>
> But now, I can't visit the local site with plain HTTP anymore. I need
> that for some tests.

tablotv.com:
> No one from our organization (we are small) added our domain to the list and
> according to the documentation on the HSTS preload site it may take many
> revisions to be removed from the list.
> ...
> As for how it happened, we are not sure.

involved-it.be:
> Several months ago I (accidently) added involved-it.be to the HSTS
> preload list presumably via https://hstspreload.appspot.com/.

bam.com.au: A mail subdomain hosted by a third-party does not support SSL.

logotype.se:
> The reason is that I do development, and for some subdomains I don't
> have TLS setup on the different server instances.

BUG= 527947 
TBR=palmer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#385850}

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

Comment 39 Deleted
For an attempted M50 merge of removals, see  Issue 601561 : Merge preload HSTS preload list removals to M50.
Project Member Comment 41 by bugdroid1@chromium.org, Apr 8 2016
Labels: merge-merged-2661
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/619a1d3f7fcb5972a75afce4c53a425864f79425

commit 619a1d3f7fcb5972a75afce4c53a425864f79425
Author: Lucas Garron <lgarron@chromium.org>
Date: Fri Apr 08 00:22:19 2016

Remove idealsvdr.com from the HSTS preload list.

Reason given:
"Unfortunately, we have two 3rd-party services linked over cnames [...]
that cannot be used over https as their 3rd party certificates [...] do
not include our domain."

BUG= 527947 

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

Cr-Commit-Position: refs/heads/master@{#379961}
(cherry picked from commit 97d372c2bc6233832ee573db666579ea15209430)

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

Cr-Commit-Position: refs/branch-heads/2661@{#519}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

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

Project Member Comment 42 by bugdroid1@chromium.org, Apr 8 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0e1ae5860dfc8a16b00545b8be3c89f1c77260e0

commit 0e1ae5860dfc8a16b00545b8be3c89f1c77260e0
Author: Lucas Garron <lgarron@chromium.org>
Date: Fri Apr 08 00:40:04 2016

Remove several domains from the HSTS preload list and remove an extra space.

videomail.io:
> I mistakenly used this code for helmet, a npm package to set various
> HTTP headers:
>
> ```
>         app.use(helmet.hsts({
>           maxAge:            108864000000, // Must be at least 18 weeks to be approved by Google
>           preload:           true
>         }))
> ```
>
> But now, I can't visit the local site with plain HTTP anymore. I need
> that for some tests.

tablotv.com:
> No one from our organization (we are small) added our domain to the list and
> according to the documentation on the HSTS preload site it may take many
> revisions to be removed from the list.
> ...
> As for how it happened, we are not sure.

involved-it.be:
> Several months ago I (accidently) added involved-it.be to the HSTS
> preload list presumably via https://hstspreload.appspot.com/.

bam.com.au: A mail subdomain hosted by a third-party does not support SSL.

logotype.se:
> The reason is that I do development, and for some subdomains I don't
> have TLS setup on the different server instances.

BUG= 527947 
TBR=palmer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#385850}
(cherry picked from commit 253102d2f4b59a803816d2567233a5823ab5d782)

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

Cr-Commit-Position: refs/branch-heads/2661@{#520}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

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

Project Member Comment 43 by bugdroid1@chromium.org, May 18 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d2bdb307d12f0ed4ae4296b72795342f53d11743

commit d2bdb307d12f0ed4ae4296b72795342f53d11743
Author: Lucas Garron <lgarron@chromium.org>
Date: Wed May 18 22:54:42 2016

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}

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

Project Member Comment 44 by bugdroid1@chromium.org, May 20 2016
Labels: merge-merged-2704
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/141931adad025d4577cbac51bcdca75f739f8d3f

commit 141931adad025d4577cbac51bcdca75f739f8d3f
Author: Lucas Garron <lgarron@chromium.org>
Date: Fri May 20 20:43:14 2016

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}
(cherry picked from commit d2bdb307d12f0ed4ae4296b72795342f53d11743)

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

Cr-Commit-Position: refs/branch-heads/2704@{#624}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

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

Project Member Comment 45 by bugdroid1@chromium.org, Jun 30 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ad73cd76bb2ab61445056987fd5076b5c66f4fd1

commit ad73cd76bb2ab61445056987fd5076b5c66f4fd1
Author: Lucas Garron <lgarron@chromium.org>
Date: Thu Jun 30 00:50:09 2016

HSTS preload list removals for Chrome 53.

rambitteh.ru:
>Прошу Вас удалить домен rambitteh.ru из HSTS по причине того что плохо прочитал
>документацию и ошибочно установил максимальный скрок обновления. На данный
>момент мы больше не хотим использовать HTTPS протокол для домена rambitteh.ru ,
>но браузеры автоматически перенаправляют с обычного протокола HTTP на
>защищённый протокол HTTPS.

doktorsitesi.com:
> We require the removal of doktorsitesi.com domain from hits servers, due to
> the redirect problems regarding smtp servers.

talktome.com:
> We have subdomains that are being hosted on separate servers which are not
> compatible with our ssl certificate and need to remain http.

bilrom.com:
> We also provide hosting services and need to use non-certified subdomains for
> both monitoring and testing issues.

euro.ro:
> apps.euro.ro hosts several custom webservers, difficult to migrate to https

bigbrownpromotions.com.au:
> The site is only going to be a very simple website with information only and
> no need to https. And the owner does not want to have the expense of buying an
> SSL

hoffmeister.biz:
> I never explicitly asked for inclusion in the preload list. The erroneously
> set "includeSubdomain; preload" headers are now removed.

skarrok.com:
> I was following some guide on how to setup ssl web host and yes it included
> 'preload'.

jaclynjohnson.com:
> no longer running a encrypted server on on domain and sub domains for
> jaclynjohnson.com running only normal unencrypted http website

sterlingtrader.com:
Same source requests as lightspeed.com removal for Chrome v52.

viviotech.net:
> Due to how we utilize our subdomains including them as part of HSTS is
> actually causing problems for many of our clients.

data102.com:
> As a datacenter and cloud provider, we have many subdomains that we cannot
> force SSL on – lots of them are internal to us only, and many things are
> industrial-style applications that do not even have SSL support (like
> environmental monitoring units, power monitoring units etc), much less work
> with chained/wildcards. [...] This was turned on via a wordpress plugin by our
> webdev person, who wanted to make our webpage SSL all the time, and foolishly
> set IncludeSubdomains=yes and Preload=yes, without having any idea what those
> actually do.

runway2street.com:
> • [int.runway2street.com] - This is an internal testing site.
> • [blog.runway2street.com] - This is also an internal test site.

estilos.com.pe:
> • [sie.estilos.com.pe] - Enterprise aplication can't use https
> • [mail.estilos.com.pe] - Mail Access from varous dives with not support https

surveypirate.com:
> . -  Changing owner and hosting of domain
> blog -  Changing owner and hosting of domain
> www -  Changing owner and hosting of domain

TBR=palmer@chromium.org
BUG= 527947 

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

Cr-Commit-Position: refs/heads/master@{#403043}

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

Project Member Comment 46 by bugdroid1@chromium.org, Aug 25 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c2ed5d4ef0dc5dbb94240dadb56a08c2a3f7c9b0

commit c2ed5d4ef0dc5dbb94240dadb56a08c2a3f7c9b0
Author: Lucas Garron <lgarron@chromium.org>
Date: Thu Aug 25 03:49:03 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 

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

Cr-Commit-Position: refs/heads/master@{#414299}

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

Project Member Comment 47 by bugdroid1@chromium.org, Aug 30 2016
Labels: merge-merged-2785
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

Summary: ☂ HSTS Preload List Removals (was: ☂ HSTS Preload List Removals and Edits)
This bug is almost entirely about removals now.
Project Member Comment 49 by bugdroid1@chromium.org, Oct 6 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bf314ad606b8153e52f64068e5550c61a320cdb3

commit bf314ad606b8153e52f64068e5550c61a320cdb3
Author: Lucas Garron <lgarron@chromium.org>
Date: Thu Oct 06 21:09:45 2016

HSTS preload list removals for Chrome 55.

eyyit.com:
> I jumped the gun on hsts preloading and now have a subdomain that needs to
> read xml feeds from non-https sites.  This HSTS preload including subdomains
> broke that.  Instead of waiting for the feeds to update their site to https,
> I'd rather get the removal process started soon so I have some options.

svallee.fr:
> • home.svallee.fr (many services, not all with HTTPS available)

vjirovsky.cz:
> axure.vjirovsky.cz – it’s branded (CNAME) version of axshare.com and they are
> not able to have certificate for axure.vjirovsky.cz

tradeacademy.in:
> list.tradeacademy.in -> We are using this domain for our newsletter
> application & we don't have Wildcard SSL certificate so whenever we open
> list.tradeacademy.in it goes to HTTPS in chrome.

almeria.fr:
> store.almeria.fr – problem with our website supplier

almeria-si.fr:
> store.almeria-si.fr – this site is managed by a partner, and we are not ready
> to migrate to https.

vozp.cz:
> • maps.vozp.cz – subsite dont using SSL
> • intranet.vozp.cz – internal application
> • helpdesk.vozp.cz – internal application

zen-trader.com:
> We cannot support HTTPS on the following subdomains:
> • status - Not under our control (third party server)
> • email - Not under our control (third party server)
> • clk - Not under our control (third party server)
> • mailsrv - Not under our control (third party server)

bratteng.me:
> dell.bratteng.me - some of the ports other than 80 and 443 does not support
> https yet

soleus.nu:
> We are a non-profit hosting association, and almost all subdomains are
> assigned to members (with their own vps and hosting services).

chrishamper.com:
> I had enabled the HSTS header with the "preload" directive on my domain while
> following an online guide related to HSTS, which didn't explain the meaning or
> repercussions of that directive. It is now causing much trouble when
> attempting to do development work using subdomains I'm spinning up as needed.

elisa.ee:
> tanama.elisa.ee – it needs to be opened with HTTP

mijailovic.net:
> • www.mijailovic.net - I’m moving my website from custom server to GitHub
> pages, but GitHub doesn’t support https on their custom subdomains.

skyo.com:
> • Skyo.com/api/ - Most Clients using API part of our site only support weak
> SSLv3 or dont support SSL/TLS at all. This had a huge impact on our business
> and we have found temporary ways around this until we can get off the preload
> list. We eventually will add the main site, skyo.com (www.skyo.com), back to
> HSTS but our backend Admin and API sections we will avoid the change due to
> too many clients not running modern systems.

mitell.jp:
> • [staging.mitell.jp, test.mitell.jp] - They are for test and our project
> cannot apply SSL for test sites.

callcap.com:
> We have several callcap.com subdomains that are used internally only that
> cannot work with HTTPS. The preload directive was configured by mistake on our
> webservers but has since been removed.

BUG= 527947 
TBR=palmer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#423678}

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

Project Member Comment 50 by bugdroid1@chromium.org, Oct 19 2016
Labels: merge-merged-2840
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/93786d31433b6c3513da5680dfe121c9b1aa5ef2

commit 93786d31433b6c3513da5680dfe121c9b1aa5ef2
Author: Lucas Garron <lgarron@chromium.org>
Date: Wed Oct 19 23:26:09 2016

HSTS preload list removals for Chrome 55.

eyyit.com:
> I jumped the gun on hsts preloading and now have a subdomain that needs to
> read xml feeds from non-https sites.  This HSTS preload including subdomains
> broke that.  Instead of waiting for the feeds to update their site to https,
> I'd rather get the removal process started soon so I have some options.

svallee.fr:
> • home.svallee.fr (many services, not all with HTTPS available)

vjirovsky.cz:
> axure.vjirovsky.cz – it’s branded (CNAME) version of axshare.com and they are
> not able to have certificate for axure.vjirovsky.cz

tradeacademy.in:
> list.tradeacademy.in -> We are using this domain for our newsletter
> application & we don't have Wildcard SSL certificate so whenever we open
> list.tradeacademy.in it goes to HTTPS in chrome.

almeria.fr:
> store.almeria.fr – problem with our website supplier

almeria-si.fr:
> store.almeria-si.fr – this site is managed by a partner, and we are not ready
> to migrate to https.

vozp.cz:
> • maps.vozp.cz – subsite dont using SSL
> • intranet.vozp.cz – internal application
> • helpdesk.vozp.cz – internal application

zen-trader.com:
> We cannot support HTTPS on the following subdomains:
> • status - Not under our control (third party server)
> • email - Not under our control (third party server)
> • clk - Not under our control (third party server)
> • mailsrv - Not under our control (third party server)

bratteng.me:
> dell.bratteng.me - some of the ports other than 80 and 443 does not support
> https yet

soleus.nu:
> We are a non-profit hosting association, and almost all subdomains are
> assigned to members (with their own vps and hosting services).

chrishamper.com:
> I had enabled the HSTS header with the "preload" directive on my domain while
> following an online guide related to HSTS, which didn't explain the meaning or
> repercussions of that directive. It is now causing much trouble when
> attempting to do development work using subdomains I'm spinning up as needed.

elisa.ee:
> tanama.elisa.ee – it needs to be opened with HTTP

mijailovic.net:
> • www.mijailovic.net - I’m moving my website from custom server to GitHub
> pages, but GitHub doesn’t support https on their custom subdomains.

skyo.com:
> • Skyo.com/api/ - Most Clients using API part of our site only support weak
> SSLv3 or dont support SSL/TLS at all. This had a huge impact on our business
> and we have found temporary ways around this until we can get off the preload
> list. We eventually will add the main site, skyo.com (www.skyo.com), back to
> HSTS but our backend Admin and API sections we will avoid the change due to
> too many clients not running modern systems.

mitell.jp:
> • [staging.mitell.jp, test.mitell.jp] - They are for test and our project
> cannot apply SSL for test sites.

callcap.com:
> We have several callcap.com subdomains that are used internally only that
> cannot work with HTTPS. The preload directive was configured by mistake on our
> webservers but has since been removed.

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

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

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

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

Cr-Commit-Position: refs/branch-heads/2840@{#762}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

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

Components: Internals>Network>DomainSecurityPolicy
Project Member Comment 52 by bugdroid1@chromium.org, Oct 27 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bf314ad606b8153e52f64068e5550c61a320cdb3

commit bf314ad606b8153e52f64068e5550c61a320cdb3
Author: Lucas Garron <lgarron@chromium.org>
Date: Thu Oct 06 21:09:45 2016

HSTS preload list removals for Chrome 55.

eyyit.com:
> I jumped the gun on hsts preloading and now have a subdomain that needs to
> read xml feeds from non-https sites.  This HSTS preload including subdomains
> broke that.  Instead of waiting for the feeds to update their site to https,
> I'd rather get the removal process started soon so I have some options.

svallee.fr:
> • home.svallee.fr (many services, not all with HTTPS available)

vjirovsky.cz:
> axure.vjirovsky.cz – it’s branded (CNAME) version of axshare.com and they are
> not able to have certificate for axure.vjirovsky.cz

tradeacademy.in:
> list.tradeacademy.in -> We are using this domain for our newsletter
> application & we don't have Wildcard SSL certificate so whenever we open
> list.tradeacademy.in it goes to HTTPS in chrome.

almeria.fr:
> store.almeria.fr – problem with our website supplier

almeria-si.fr:
> store.almeria-si.fr – this site is managed by a partner, and we are not ready
> to migrate to https.

vozp.cz:
> • maps.vozp.cz – subsite dont using SSL
> • intranet.vozp.cz – internal application
> • helpdesk.vozp.cz – internal application

zen-trader.com:
> We cannot support HTTPS on the following subdomains:
> • status - Not under our control (third party server)
> • email - Not under our control (third party server)
> • clk - Not under our control (third party server)
> • mailsrv - Not under our control (third party server)

bratteng.me:
> dell.bratteng.me - some of the ports other than 80 and 443 does not support
> https yet

soleus.nu:
> We are a non-profit hosting association, and almost all subdomains are
> assigned to members (with their own vps and hosting services).

chrishamper.com:
> I had enabled the HSTS header with the "preload" directive on my domain while
> following an online guide related to HSTS, which didn't explain the meaning or
> repercussions of that directive. It is now causing much trouble when
> attempting to do development work using subdomains I'm spinning up as needed.

elisa.ee:
> tanama.elisa.ee – it needs to be opened with HTTP

mijailovic.net:
> • www.mijailovic.net - I’m moving my website from custom server to GitHub
> pages, but GitHub doesn’t support https on their custom subdomains.

skyo.com:
> • Skyo.com/api/ - Most Clients using API part of our site only support weak
> SSLv3 or dont support SSL/TLS at all. This had a huge impact on our business
> and we have found temporary ways around this until we can get off the preload
> list. We eventually will add the main site, skyo.com (www.skyo.com), back to
> HSTS but our backend Admin and API sections we will avoid the change due to
> too many clients not running modern systems.

mitell.jp:
> • [staging.mitell.jp, test.mitell.jp] - They are for test and our project
> cannot apply SSL for test sites.

callcap.com:
> We have several callcap.com subdomains that are used internally only that
> cannot work with HTTPS. The preload directive was configured by mistake on our
> webservers but has since been removed.

BUG= 527947 
TBR=palmer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#423678}

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

Project Member Comment 53 by bugdroid1@chromium.org, Oct 27 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/93786d31433b6c3513da5680dfe121c9b1aa5ef2

commit 93786d31433b6c3513da5680dfe121c9b1aa5ef2
Author: Lucas Garron <lgarron@chromium.org>
Date: Wed Oct 19 23:26:09 2016

HSTS preload list removals for Chrome 55.

eyyit.com:
> I jumped the gun on hsts preloading and now have a subdomain that needs to
> read xml feeds from non-https sites.  This HSTS preload including subdomains
> broke that.  Instead of waiting for the feeds to update their site to https,
> I'd rather get the removal process started soon so I have some options.

svallee.fr:
> • home.svallee.fr (many services, not all with HTTPS available)

vjirovsky.cz:
> axure.vjirovsky.cz – it’s branded (CNAME) version of axshare.com and they are
> not able to have certificate for axure.vjirovsky.cz

tradeacademy.in:
> list.tradeacademy.in -> We are using this domain for our newsletter
> application & we don't have Wildcard SSL certificate so whenever we open
> list.tradeacademy.in it goes to HTTPS in chrome.

almeria.fr:
> store.almeria.fr – problem with our website supplier

almeria-si.fr:
> store.almeria-si.fr – this site is managed by a partner, and we are not ready
> to migrate to https.

vozp.cz:
> • maps.vozp.cz – subsite dont using SSL
> • intranet.vozp.cz – internal application
> • helpdesk.vozp.cz – internal application

zen-trader.com:
> We cannot support HTTPS on the following subdomains:
> • status - Not under our control (third party server)
> • email - Not under our control (third party server)
> • clk - Not under our control (third party server)
> • mailsrv - Not under our control (third party server)

bratteng.me:
> dell.bratteng.me - some of the ports other than 80 and 443 does not support
> https yet

soleus.nu:
> We are a non-profit hosting association, and almost all subdomains are
> assigned to members (with their own vps and hosting services).

chrishamper.com:
> I had enabled the HSTS header with the "preload" directive on my domain while
> following an online guide related to HSTS, which didn't explain the meaning or
> repercussions of that directive. It is now causing much trouble when
> attempting to do development work using subdomains I'm spinning up as needed.

elisa.ee:
> tanama.elisa.ee – it needs to be opened with HTTP

mijailovic.net:
> • www.mijailovic.net - I’m moving my website from custom server to GitHub
> pages, but GitHub doesn’t support https on their custom subdomains.

skyo.com:
> • Skyo.com/api/ - Most Clients using API part of our site only support weak
> SSLv3 or dont support SSL/TLS at all. This had a huge impact on our business
> and we have found temporary ways around this until we can get off the preload
> list. We eventually will add the main site, skyo.com (www.skyo.com), back to
> HSTS but our backend Admin and API sections we will avoid the change due to
> too many clients not running modern systems.

mitell.jp:
> • [staging.mitell.jp, test.mitell.jp] - They are for test and our project
> cannot apply SSL for test sites.

callcap.com:
> We have several callcap.com subdomains that are used internally only that
> cannot work with HTTPS. The preload directive was configured by mistake on our
> webservers but has since been removed.

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

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

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

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

Cr-Commit-Position: refs/branch-heads/2840@{#762}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

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

Components: -Internals>Network>SSL
Project Member Comment 55 by bugdroid1@chromium.org, Nov 17
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cc58a938580a8198d48e5949ba7dce5a54c0b4d8

commit cc58a938580a8198d48e5949ba7dce5a54c0b4d8
Author: Lucas Garron <lgarron@chromium.org>
Date: Thu Nov 17 23:25:33 2016

HSTS preload list removals for Chrome 56.

ispire.me:
> • go.ispire.me - reason: Using http redirects somethimes.
> • goto.ispire.me - reason: Using http redirects somethimes.
> • cdn.ispire.me - reason: Using http redirects somethimes.

ebfe.pw:
> i work in pentest space and sometimes i need certain stuffs to be hosted in
> non-https. 😉

eopugetsound.org:
> • dev.eopugetsound.org – we do not have a cert (nor can we get one) for this
> subdomain.

rocketmill.co.uk:
> • uptime.rocketmill.co.uk – points to a 3rd party server hosting an
> application. We don’t have control over the server and it doesn’t support
> HTTPS currently.

gig.ru:
> • all subdomains — https was left only for primary domain name

self-injury.net:
> The website was shut down and the main domain transferred to tumblr.com DNS
> which does not support SSL.

spritchard.photos:
> Migration to Nginx for new backend service expansion. Preload was previously
> required as there was no expectation of such expansion. The flag has been
> removed and max-age has now been set to 0. SSL & HTTP/2 will remain enabled
> where possible but preloading will not be required.

motoryz.nl:
> Due to a wrong default configuration the sites has been serving a HSTS header
> without actual intend.

klimat-pro.pl:
> • oddymianie.klimat-pro.pl - we do not have wildcard certificate for klimat-
> pro.pl, and our management is not willing to pay for such certificate, we
> still need to serve this page as it is page for our new product range.

sslhosting.cz:
> • www - it has been a project of mine, but I did not succeed

liverpoolmutualhomes.org:
> • “email.liverpoolmutualhomes.org” – this uses the CreateSend personalised URL
> service that can only be used over plain HTTP. To our knowledge, no request
> was ever submitted to include the “liverpoolmutualhomes.org” domain in the
> preload list other than a previous developer adding the
> “www.liverpoolmutualhomes.org” with the “preload” by mistake and this was
> removed about April 2016 – this referenced the www.liverpoolmutualhomes.org,
> yet “liverpoolmutualhomes.org” has been registered.

thijsalders.nl:
> I never intended to be pre-loaded in the HSTS list. On an old web server some
> time ago, I was experimenting with SSL, and I accidentally enabled HSTS, not
> knowing what it was. I’ve disabled it already, but somehow my domain got
> included in the pre-load list, and now I can’t run small test stuff without
> SSL anymore.

josip.at:
> I want to sell this domain asap.

guscaplan.me:
> guscaplan.me - moved to gus.host (pending HSTS)
> *.guscaplan.me - moved to *.gus.host (pending HSTS)

lavinya.net:
> because not working my subdomains if hsts on.

froot.se:
> Wasn't meant to have preload directive from the start.

BUG= 527947 
TBR=palmer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#433017}

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

Just noticed "0xAA55.me" appears in the list twice, once with capital "A"s and once with lowercase "A"s. The version with capitals can be removed as it will never be used.

I'll file a separate issue to add a test for this to the generator.
> I'll file a separate issue to add a test for this to the generator.

Thanks! Now would be a good time to add some consistency checks; also see 568378.
Project Member Comment 58 by bugdroid1@chromium.org, Jan 19
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c083c885f19967daef65cce687ab0b0d695adf69

commit c083c885f19967daef65cce687ab0b0d695adf69
Author: Lucas Garron <lgarron@chromium.org>
Date: Thu Jan 19 03:15:43 2017

HSTS preload list removals for Chrome 57.

mencap.org.uk:
> We have a lot of internal sites/subsites and as a charity all sites are not
> using ssl. We will do when when we purchase a wildcard ssl.

hzsh.xyz:
> HSTS verification needs to be disabled for Let's encrypt authentication
> errors. I tested cPanel Let's encrypt authentication, SNI does not support
> https authentication.

ssersay.com:
> • sport.ssersay.com – We suppose to bind this subdomain to a TV live platform
> which does not support https.
> • jekyii.ssersay.com – We plan to use the Coding Pages service which does not
> allow https

tokyopopline.com:
> We can not operate the site with HTTPS.
> • reason
> Since the portal site of the delivery destination does not correspond.

cgat.no:
> • cgat.no - root domain being transitioned to a 301 primary redirect to
> another site (https://christiangaetano.com) that will be on the HSTS preload
> list.

usap.gov:
> All usap.gov subdomains - Preload forces our internal (non-public facing)
> subdomains to https, which was an unforeseen consequence of HSTS preloading
> and which we are unable to support at this time.

cip.md:
> can't upgrade to HTTPS due to device limitation
> (http://asus.meriacre.cip.md:8081)

johndong.net, gooby.co:
> Basically all of gooby.co and johndong.net need to be removed from HSTS
> preload because I royally screwed up with my configuration and now I can't use
> HTTP on a subdomain of mine.

kinogb.net:
> We happened to turn on HSTS
> Part pages may not work on https, only on http

open-coding.org:
> I'd like to sell the domain

koophetlokaal.nl:
> Unfortunately due to a lack of understanding the HSTS logic fully I've used
> default settings for a certain software stack to setup my SSL certificates.
>
> This resulted in the preloading feature to be enabled by default and since
> I've moved to LetsEncrypt I'm running into issues.

jf-projects.de:
> • storage.jf-projects.de - It's an old box, that does not has the ability to
> provide HTTPS
> • router.jf-projects.de - It's an router.

kkaufmann.de:
> I cant connect to my Router at Home and other Sites.

mindwerks.net:
The site operator enabled HPKP, then accidentally switched to a certificate that
did not match the previously pinned set. As a precaution, they'd like to remove
the HSTS entry from the preload list (even though the issue mostly orthogonal).

glopoi.com:
- [various country-code subdomains] - we couldn't afford any more

mytripcar.com:
> • marketing.mytripcar.com - we use a third-party service and uploading custom
> SSL certificates has an extra cost

BUG= 527947 
TBR=palmer@chromium.org

Review-Url: https://codereview.chromium.org/2550763002 .
Cr-Commit-Position: refs/heads/master@{#444621}

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

Details from https://chromium.googlesource.com/chromium/src.git/+/95afc44bbf2a48971c4b0de896003b6dd9684c81
(which was accidentally attached only to  Issue 655854 , with a truncated commit message):

HSTS preload list removals for Chrome 58.

safic.net:
> • [oakwood] - audio stream server will not properly support https, oversite on
>   configuration preload and subdomains have been removed from headers.

medwayindia.com:
> We cannot support HTTPS on domain and we are removing it since our website
> provides only information and doesn't have payment or login functions that
> would require SSL.
>
> It was a mistake installing SSL which is not actually required by our static
> information purpose website.

sangwon.org:
> My blog service cannot support https

whiskeyriver.co.uk:
>  the reason for this is that I have recently taken over this domain, which I
>  have since discovered used to go to an https and is preloaded into the HSTS
>  list, but my brand new [and far superior] band website is created by Weebly,
>  http only and therefore will not work using this domain [it has been the
>  band’s domain for the last 9 years]. To add SSL to my new site so it will
>  work would cost more than the band can afford and so I am humbly asking if
>  you could remove it

jf.duckdns.org:
> This website is a dynamic DNS site hosted on my Raspberry Pi... I was just
> testing SSL on my site and enabled HSTS (recommended by ssllabs site tester)
> without being fully aware of the implications.  I have since removed this
> header in my apache conf however as you can see it's in the Chrome preload
> list.

avril4th.com:
> *.avril4th.com - This is blog which I take care of. However, it was moved to a
> naver blog (I was against that, but it's not my decision), which does not
> support https. At all.

builtritetrailerplans.com:
> No longer have ssl on [builtritetrailerplans.com] we have moved to
> builtritetrailerplans.com.au

x-case.de:
> [Subdomain with] Local SAP System with public DNS
Project Member Comment 60 by bugdroid1@chromium.org, Apr 14
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3467ad55e36b4780b267826f53530e41d0ec6b09

commit 3467ad55e36b4780b267826f53530e41d0ec6b09
Author: Lucas Garron <lgarron@chromium.org>
Date: Fri Apr 14 03:35:39 2017

HSTS  preload list removals for Chrome 59.

1p.ro:
> We cannot support HTTPS as this is a home, personal domain, and HTTPS was only
> enabled to test some features. Additionally there are some internal subdomains
> that run on HTTP only and now cannot be accessed on Chrome.
>
> The settings were erroneously copy-pasted from https://cipherli.st/ but now
> all websites settings have been updated to clear the „preload” and the
> „include subdomains” flags.

visage.ch, quirino.ch, designpilot.ch:
> • webmail - The configuration is on the server in a different directory, we
> have not access to this directory, it is a shared hosting

tomask.info:
> We cannot support HTTPS on all subdomains, because my new hosting supports only one certificate per domain (Let's Encrypt).

ahrq.gov:
> • [*.ahrq.gov] – we never intended to be preloaded, our domain was sending an
> HSTS header with the preload directive as a test to comply with the federal
> government’s HTTPS-Only standard.  We now realize that by ahrq.gov sending the
> preload directive in an HSTS header, it was considered to be requesting
> inclusion in the preload list.

falkena.net:
> • falkena.net - I didn't know what I was doing and how severe the preload
> directive in the Header would be. I'm using a raspberry pi to host a small
> website and having reinstalled my pi, I wanted to use letsencrypt to
> regenerate the certificates. Turns out there is a ACME validation step which
> now fails, because each time they try to access http://falkena.net it gets
> converted to https://falkena.net which doesn't have a valid certificate. Next
> time I will stick to dynamic HSTS, rather than static.

eisp.it:
> We do support https on our domain and subdomains but we would still like to be
> able to access them if the certificate is not timely renewed, like now, or for
> other reasons. I never intended to have our domain preloaded, I never even
> made the request but I did by mistake add the preload option in our
> configuration, while testing the config, but I honestly didn't know it would
> "send" the preload request anyway.

inwesttitle.com:
> We cannot support HTTPS on internal subdomains on some machines as they can
> not be updated, but we still need to access them locally. We set this up
> mostly because it was something that was recommended through ssllabs and
> suggestions made from websites about HSTS, but didn't realize how many things
> it would affect.

coronelpicanha.com.br, ilhadocaranguejo.com.br, mvixturismo.com.br:
> We no longer support HTTPS, because the some mobile devices don't load
> properly our websites.

BUG= 527947 
TBR=palmer@chromium.org

Review-Url: https://codereview.chromium.org/2732883005 .
Cr-Commit-Position: refs/heads/master@{#464668}

[modify] https://crrev.com/3467ad55e36b4780b267826f53530e41d0ec6b09/net/http/transport_security_state_static.json

Project Member Comment 61 by bugdroid1@chromium.org, Apr 14
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/440edf53f31507418a80bda58e2da143619b7ddb

commit 440edf53f31507418a80bda58e2da143619b7ddb
Author: Lucas Garron <lgarron@chromium.org>
Date: Fri Apr 14 03:46:48 2017

Update transport_security_state_static.h with removals from 3467ad55e36b.

Due to the rollback in https://chromium-review.googlesource.com/c/474009/ , we need to update the header manually.

BUG= 527947 
TBR=palmer@chromium.org

Review-Url: https://codereview.chromium.org/2821533004 .
Cr-Commit-Position: refs/heads/master@{#464669}

[modify] https://crrev.com/440edf53f31507418a80bda58e2da143619b7ddb/net/http/transport_security_state_static.h

Project Member Comment 62 by bugdroid1@chromium.org, May 25 (5 days ago)
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b6dd6525ce6d24e9d3713d639eefb9e372095bde

commit b6dd6525ce6d24e9d3713d639eefb9e372095bde
Author: lgarron <lgarron@chromium.org>
Date: Thu May 25 00:43:05 2017

HSTS preload list removals for Chrome 60.

cbtistexcalac.mx:
> The reason is because many of our clients use PC without have correctly set
> the date and also have pcs with very old windows versions and many times just
> don’t want to pay for a SSL.

pflege.de:
> we just removed the HSTS header at pflege.de because of problems with the subdomains.

fyrkat.no, jornane.no, jornane.nl, jornane.me:
> The reason is that due to the recent blacklisting of free CA StartCom, I
am not confident that I am able to provide HTTPS in the future.  In this
case, I want to revert to opportunistic HTTPS, which I cannot do while
the domain is HSTS preloaded.

monarcasystems.com:
> • The reason is because many of our clients use PC without have correctly set
> the date and also have pcs with very old windows versions and many times just
> don’t want to pay for a SSL.

skhosting.eu:
> We use subdomains on internal network just with selfsigned certificates and
> access them trought VPN. Nowadays we have to allow access them from public
> network and use letsencrypt certificates. But we would like to use this
> subdomains accessible only from our internal network for security reasons.

lincolncollege.edu:
> • http://libguides.lincolncollege.edu/ - libguides is hosted from a service
> provider not associated with Lincoln College.  The SSL certificate being used
> is not associated with Lincoln College and is therefore throwing security
> errors when the subdomain is masked with lincolncollege.edu.

47ronin.com:
> One of the subdomains: live.47ronin.com is on Tumblr and SSL does not work
> properly on custom domains, and it seems this may never be fixed.

opinello.com:
> • www.kiosk.opinello.com
> • www.ruch.opinello.com
> • and all new future domains in format www.*.opinello.com
>
> The reason is the high cost of buying new certificates for the next domains in
> www.*.opinello.com format. We are going to create a many subdomains in
> specified format.

hosted-service.com:
> A technician inadvertently copy/pasted a configuration that included the
> preload directive, and this was not discovered for some time. The directive
> has been removed and we are now serving max-age=0.

blupig.net:
> We have some internal devices that does not support TLS at all, or very
> difficult to enable and maintain + update certificates in them, since they are
> all in internal network, it would be ok for us to access without https.

avenelequinehospital.com.au:
> This is being hosted on a business catalyst (Adobe) site that does not support
> custom SSL certificates

tomwiggers.nl:
> - simagine.tomwiggers.nl (redirect)
> - svmware.tomwiggers.nl (redirect)
> - helios.tomwiggers.nl (self signed VMware certicate, it's an ESXi host, I use
>   Let's Encrypt for (sub)domains I can provide good HTTPS for but with VMware
>   this is difficult)
> - webmail.tomwiggers.nl (redirect)
>
> Users keep getting HSTS errors in Chrome when they visit any of the above
> websites because they are either redirects or do not support proper HTTPS.
>
> Earlier when I implemented HSTS on my webserver I did not realise HSTS
> preloading does not just apply to one subdomain but the whole domain,
> everything. I realised this too late.

wholesalesolar.com:
> We have decided to aggressively move our entire web and marketing
> infrastructure onto Hubspot's Marketing platform, COS (Content Optiimzation
> System).
> ...
> We have been informed by Hubspot that they are unable to support HSTS headers
> in conjunction with HTTPS due to Akamai's CDN network.

marquiseclub.se:
> Domain name has previously been used by another company. We do not need hsts,
> so please remove as soon as possible

mea.in.ua:
[Could not get a reason.]

BUG= 527947 
TBR=palmer@chromium.org

Review-Url: https://codereview.chromium.org/2825083004
Cr-Commit-Position: refs/heads/master@{#474497}

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

Sign in to add a comment