Users, developers, and applications expect end-to-end security on their secure channels, but some secure channels are not meeting the expectation.

If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk).

In this case, the advertised identity must match one of the elements in the pinset.

A host or service's certificate or public key can be added to an application at development time, or it can be added upon first encountering the certificate or public key.

The former - adding at development time - is preferred since preloading the certificate or public key out of band usually means the attacker cannot taint the pin.

You should pin anytime you want to be relatively certain of the remote host's identity or when operating in a hostile environment.

Since one or both are almost always true, you should probably pin all the time.

If you are working for an organization which practices "egress filtering" as part of a Data Loss Prevention (DLP) strategy, you will likely encounter Interception Proxies.

I like to refer to these things as "good" bad guys (as opposed to "bad" bad guys) since both break end-to-end security and we can't tell them apart.

In this case, do not offer to whitelist the interception proxy since it defeats your security goals.