User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36 Steps to reproduce: 1. Open a site with HPKP enabled (e.g. https://cyph.im). 2. Switch to Private Browsing mode. 3. Open the same site. Actual results: The TLS public key from step #1 remains pinned in Private Browsing mode. For reasons explained here — http://cyph.team/hpkpincognito and/or https://www.reddit.com/r/encryption/comments/4027ci/how_2_spacex_alums_are_using_encryption_for_good/cyywmc8 — because the AppCache is (obviously/rightfully) not carried over to Private Browsing mode in this manner, in our case this leaves our users stuck with a scary and unhelpful "invalid pinned TLS public key" error screen. Expected results: TLS key pins should be treated with the same level of isolation while in Private Browsing as any other state (AppCache, history, cookies, etc.). Even if we decide that we don't care about not breaking Cyph in Private Browsing mode, the fact that this can be exploited to create a "super cookie" that de-anonymises Private Browsing users seems pretty serious.

See also bug 1232961 which is basically the exact opposite, but with HSTS.

Interesting. Re: the "privacy" vs "security"/confidentiality debate, my opinion is that the threat model of Private Browsing / incognito should be 100% geared toward the former. The entire promise of incognito is an isolation from state, after all. As a contrived example, I probably don't care if an active MitM captures data I'm sending to bestiality.org while incognito, but I will care if every website I visit from then on can detect that I've been there. Not saying confidentiality doesn't matter, but it makes no sense to compromise on a promise explicitly made to users for the sake of something that's eventually unrelated.

*essentially (Also, some alternate examples: SecureDrop, internal CIA site, etc.)

Data captured in private mode should definitely not leak to regular mode. Assume you are on secret-site.com in private mode and that site had HPKP. The site should not be pinned in regular mode and no one should be able to detect that you went to that site in private mode. On the other hand, assume you visit not-so-secret-site.com in regular mode and it has HPKP. Now you go to private mode. Do we use the HPKP data from regular mode? That depends on what the bigger threat is - are we more worried about an attacker using a spoofed cert for that domain or are we more worried about a supercookie detecting what sites we have been to in regular mode?

More information so it's all in the same place: (In reply to Tom Ritter [:tjr] from bug 1311745 comment #0) > In nsSiteSecurityService::GetKeyPinsForHostname (around > https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/ > nsSiteSecurityService.cpp#1164 )it appears that the stores are checked: > Persistent, Private, Preload. > > It seems to me the correct order should be: > > For Private Browsing: Private, (maybe) Persistent, Preload. (There are > arguments to be had on both sides of the 'maybe') > > For 'Normal' browsing: Persistent, Preload. > > See also #1242226