What are my options for disabling HSTS both for new sites and for those sites baked into the browser?
The use of HTTPS inspection inherently changes the thumbprint of a site by acting as a man in the middle; visiting a site previously visited without HTTPS inspection or one of the preloaded sites will result in an inaccessible site. What options - if any - do I have other then disabling inspection?
Here is an example, Gmail in Chrome with HTTPS inspection:
Background
I am setting up a new firewall and I'm trying to clean my HTTPS inspection rules. I really want to avoid adding sites to the list that may have user contributed content, such as mail.google.com / gmail.com.
Since the last time I did this HSTS / HTTP Strict Transport Security has become a lot more prevalent.
Note - I tried to keep this generic since this could be an issue for a lot of different setups. I'm hoping for a cross OS / cross browser method that would be applicable to any firewall product but that is asking a bit much. A focus on (IE, Chrome, Firefox) using Windows (7+) would be a great start. Methods centered on Group Policy would also be very useful.
You're conflating a few different things here, and I suspect it's leading you to some false conclusions.
Since HTTPS inspection is (unfortunately) a widely-deployed practice, the general practice amongst browsers is that certificate chains which end in a locally-installed root CA certificate are exempted from public key pinning checks. I've found a statement from Chrome's Adam Langley on Chrome's behaviour (the section "What about MITM proxies, Fiddler etc?"), but my experience is similar for other browsers.
I'm fairly confident that the problem indicated in your screenshot isn't that the browser is getting hung up on a pin, but rather that it is failing to recognise the certificate as chaining to a trusted CA certificate at all. That will trigger a HSTS failure, because "using HTTPS" is more correctly specified as "using properly-secured HTTPS including secure ciphers and a trusted certificate for authentication". I would suggest double-checking that the MitM proxy's root CA certificate is installed correctly and recognised as valid by the browser(s) in use.