UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce the problem:
Trying to enforce HTTPS in intranet environments via HSTS may fail with current approach. Organizations won't be willing to add their intranet domains in a public list. The overhead of having users manage intranet sites via chrome://net-internals/#hsts is too large.

What is the expected behavior?
Having a configurable list of *additional* HSTS entries. This should either be configurable/packageable via customized install/central policies or an configurable to be downloadable from an authoritative URL.

What went wrong?
Currently HSTS are hard-coded to what's public or users can enter additional domains manually.

Did this work before? No 

Chrome version: 62.0.3202.94  Channel: stable
OS Version: OS X 10.13.1
Flash Version: 

This is loosely related to issue 451295. However, since we are talking about intranet pages here, there is a potential to have everything under control and no assumptions how the site owner behaves have to be made.

Having such a feature would allow organizations migrate to https-only in their intranet more quickly:
- on an site-by-site base enable https
- add the site to the custom HSTS preload list
- regardless how the site is access (typed without scheme, from bookmark from an old link), the request is made to https directly
- site access via http can be safely disabled