User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce: Note that Firefox' HPKP implementation exists and works. :) Expected results: For the reasons given in https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/he9tr7p3rZ8, Chrome is removing (dynamic) HPKP. (But not pre-loaded pins.) We are getting close to removing our implementation (https://chromium-review.googlesource.com/c/chromium/src/+/1277963 and https://bugs.chromium.org/p/chromium/issues/detail?id=779166). The existence of HPKP in a major browser poses risks (hostile pinning, self-bricking) even to sites that do not use HPKP. Since adoption has proven infinitesimal, we strongly believe that the risks of HPKP outweigh its benefits. For sites that really want to pin, pre-loading is still possible and provides the benefit without as much risk (thanks to manual vetting by browser engineers).

> or sites that really want to pin, pre-loading is still possible and provides the benefit without as much risk But you still want to remove these too in the future, which is even more ridiculous as you now say "it's still possible" and likely in a few months you say (as already shown in the linked discussions) "we remove that too". And this, as you say, posing NO risks. Nothing compared to HPKP, as pins are, as you said, manually vetted. As for HPKP removal, also better not follow Google's claim here. The mentioned "hostile pinning" risk is still 100% theoretical and "self-bricking" is a risk web admins can easily mitigate by properly deploying HPKP. (e.g. only pinning root CA)