When a website that has HSTS enabled is cached due to not being preloaded in fx [1], that cache is shared between the default userContextID and all the other userContextID's. PB uses it's own separate cache which is cleared once the PB window is closed. We need to decide the following: * should the default behaviour for HSTS caching be global (current behaviour) or be compartmentalized for each container * should users be able to change this behaviour via a pref in about:config (similar proposal in bug # 1249348) Example: (assuming a brand new installation of m-c with containers enabled) * open http://www.linux.org.ru in a default container (should load via http://) * open http://www.linux.org.ru in a personal container (should load via http://) * open https://www.linux.org.ru in the default container (should load via https://) * open http://www.linux.org.ru in the banking container (uses the same cache and will load via https://) [1] https://dxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/nsSTSPreloadList.inc

I personally think that the risk of being MitM'd before the, err, trust-on-second-use happens is greater than the risk of history enumeration via HSTS timing attacks, especially given what an uphill battle that stuff always seems to be. So I am personally of the opinion that the default should be global HSTS caching. If we're really concerned about it leaking information between the two, could we induce some timing jitter and maybe inject a fake 301 redirect or something? While I don't think a preference is something that users would use terribly often, I do think having it there is a good thing. This especially holds true for things like the Tor Browser, which place a high degree of importance on preventing history sniffing.

This is a platform only bug for containers, but not needed for initial launch. Marking P3.

I think this could mitigate HSTS Super Cookies: http://www.radicalresearch.co.uk/lab/hstssupercookies For the case of SSLStrip site owners should implement preloaded HSTS anyway.

Could we generalize this bug to compartmentalize HSTS by OriginAttributes?

Here's Tor's work in progress bug: https://trac.torproject.org/projects/tor/ticket/17965

When implementing this bug, please make it Origin Attribute specific so that every OriginAttribute can later decide whether it wants to isolate or not.

(Might be convenient to isolate the HPKP cache here as well, because the code is very similar.)

(In reply to Tanvi Vyas [:tanvi] from comment #6) > When implementing this bug, please make it Origin Attribute specific so that > every OriginAttribute can later decide whether it wants to isolate or not. I don't quite follow this comment. What does "make it Origin Attribute specific" mean? Did you mean "No" to Arthur's question in comment 4? (Could we generalize this bug to compartmentalize HSTS by OriginAttributes?)

(In reply to Ethan Tseng [:ethan] from comment #8) > (In reply to Tanvi Vyas [:tanvi] from comment #6) > > When implementing this bug, please make it Origin Attribute specific so that > > every OriginAttribute can later decide whether it wants to isolate or not. > > I don't quite follow this comment. What does "make it Origin Attribute > specific" mean? > Did you mean "No" to Arthur's question in comment 4? > (Could we generalize this bug to compartmentalize HSTS by OriginAttributes?) Each individual Origin Attribute should be able to decide whether or not it wants to be separated by HSTS. The same is true for OCSP and Permissions. First Party Isolation will likely want to isolate for HSTS, as it does for OCSP. We should file a separate bug for that and keep this bug Containers specific. Ethan, can you do this? HSTS should not be isolated for Containers for now. However, we should implement HSTS for First Party Isolation in a way that is general to all Origin Attributes (the way we did for OCSP) and then set an appropriate policy for each Origin Attribute. Then in the future, we can easily change how a particular Origin Attribute chooses to handle HSTS cache. Please let me know if further clarification is required. Thanks!

Should this be closed as a duplicate of 1323664?

By which, of course, I mean Bug 1323644, as mentioned by :jhao.

(In reply to Richard Barnes [:rbarnes] from comment #10) > Should this be closed as a duplicate of 1323664? I opened the other bug on purpose because of what Tanvi said in comment 9. I'm not sure if she wants to close this one as a duplicate.

Bulk change per https://bugzilla.mozilla.org/show_bug.cgi?id=1401020

I think this is a WONTFIX, until we observe behavior that makes us revisit this decision. Should we close it as such? Or leave it around?

I think we can just leave it around as blocking the our ContextualIdentity meta bug. I'll make it a P5.