On the internet, when you send and receive data, your data gets handled by a lot of different people. In the old days, anybody who handled your data could tamper with it or impersonate anybody else. Cryptography to the rescue.
Suppose "Alice" and "Bob" want to send secret messages to each other, without allowing "Eve" the eavesdropper to read them, even if Eve can intercept the messages.
Traditional cryptography is "symmetric," where both Alice and Bob must share a secret before they can communicate. Symmetric cryptography won't suffice over the internet, because if Alice and Bob had a secure way of sharing secrets, they wouldn't need internet cryptography in the first place.
So the internet relies on public-key cryptography, where Alice and Bob each have a pair of keys (a "key pair"), one "public" key that everyone can see, even Eve, and one "private" key that has to be kept secret. Alice can encrypt a message using Bob's public key that can only be decrypted using Bob's private key.
At first, it might seem like public-key crypto solves the problem completely, but it creates a new problem: how will Alice get Bob's public key? If she asks Bob for his public key over an unencrypted public channel, Eve can intercept it and offer her own public key, acting as a "man in the middle" (MITM).
Luckily, public-key cryptography has one more trick up its sleeve. If you "encrypt" a message using a private key, it can be "decrypted" using the public key. Only Bob (the owner of Bob's private key) can encrypt messages that can be decrypted with Bob's public key, so anything Bob encrypts that way is
effectively "signed" by Bob.
If Alice and Bob trust a third party, Charlie, Charlie can sign a message saying: "This is Bob's public key: 12345" and another message saying "This is Alice's public key: 23456". Eve can't impersonate Charlie without his private key. We call Charlie a "certificate authority." (CA)
When you visit an HTTPS website, the site presents a certificate signed by a CA. Your browser trusts a ton of CAs all over the world, many of them run by governments that you may not really want to trust; any of them can use their private keys to impersonate any site on the internet. This is a hard social problem as much as a technical problem.
High-value websites like Gmail, Facebook, or banks may want to say "Here's our certificate, but don't just trust any certificate authority about that. You should only trust Charlie's signature." That's called "pinning" the public key to a certificate authority.
It's a nice idea, but how will Gmail convey that message to its users? If Eve is a hostile government who intercepts messages and owns a trusted CA, they can impersonate Gmail, saying "Oh, you don't need to trust Charlie exclusively. You can trust any CA, even me."
Chrome comes with a static, hard-coded list of pinned keys for high-value sites, but that can't scale. They had the idea of allowing anybody on the internet to pin their keys, "dynamic" pinned keys or HTTP-based key public key pinning (HPKP).
The problem is, if you pin your public key and you need to change it for some reason, or if you need to switch certificate authorities for any reason, you're in big trouble. People have used HPKP and brought their site down, unable to bring it back up again, because browsers don't trust their new valid key.
As a result, very few sites used HPKP, so the Chrome team is planning to remove it.
Surprisingly to me, they even plan to remove the static list of pinned keys, in favor of "Certificate Transparency" where it's publicly obvious which CAs are signing which certificates. Rogue CAs would then have to reveal that they've gone rogue, at which point browsers could revoke their automatic trust in them.