HSTS preload list removals for Chrome 55.

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

Committed: https://chromium.googlesource.com/chromium/src/+/bf314ad606b8153e52f64068e5550c61a320cdb3

[lgarron, 2016-10-06 20:31:41]

Description was changed from

==========
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:
> I cannot support HTTPS on the following subdomains:
>
> • home.svallee.fr (many services, not all with HTTPS available)

BUG=527947
==========

to

==========
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.

BUG=527947
==========

[lgarron, 2016-10-06 20:34:29]

Description was changed from

==========
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.

BUG=527947
==========

to

==========
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.
==========

[lgarron, 2016-10-06 20:40:36]

Description was changed from

==========
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.
==========

to

==========
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
==========

[commit-bot: I haz the power, 2016-10-06 21:13:27]

Description was changed from

==========
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
==========

to

==========
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

Committed: https://crrev.com/bf314ad606b8153e52f64068e5550c61a320cdb3
Cr-Commit-Position: refs/heads/master@{#423678}
==========

[commit-bot: I haz the power, 2016-10-06 21:13:28]

Patchset 4 (id:??) landed as
https://crrev.com/bf314ad606b8153e52f64068e5550c61a320cdb3
Cr-Commit-Position: refs/heads/master@{#423678}

[lgarron, 2016-10-06 21:16:19]

Description was changed from

==========
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

Committed: https://crrev.com/bf314ad606b8153e52f64068e5550c61a320cdb3
Cr-Commit-Position: refs/heads/master@{#423678}
==========

to

==========
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

Committed:
https://chromium.googlesource.com/chromium/src/+/bf314ad606b8153e52f64068e555...
==========

[lgarron, 2016-10-06 21:16:21]

Committed patchset #4 (id:60001) manually as
bf314ad606b8153e52f64068e5550c61a320cdb3 (presubmit successful).