On Wed, Nov 9, 2011 at 10:04 AM, Paul Hoffman <[email protected]> wrote: > On Nov 9, 2011, at 9:03 AM, Adam Barth wrote: >> On Wed, Nov 9, 2011 at 8:38 AM, Steingruebl, Andy >> <[email protected]> wrote: >>>> -----Original Message----- >>>> From: Adam Barth [mailto:[email protected]] >>>>> We battled this problem with HSTS as well. I think what Mozilla settled >>>>> on >>>> (and I don't remember the Chrome solution) is to use a different storage >>>> mechanism when HSTS is *set* during private browsing mode, and clear on >>>> exit from private browsing. >>>> >>>> It's been a while since I wrote that code, but I'm pretty sure that's how >>>> it >>>> works in Chrome too. There's a separate memory-only HSTS store that's >>>> used for incognito. That's consistent with how we handle other >>>> host-specific >>>> data stored by the network layer, such as cookies. >>> >>> Is this documented anywhere? Where should it be? Maybe add a section to >>> the browser security handbook, if nowhere else, so at least we all have it >>> written down what the browsers have implemented? >> >> I don't believe it's documented anywhere. >> >>> And, since we decided these specifics don't belong in the IETF HSTS spec, >>> where could we document them for real? >> >> Typically, incognito mode hasn't been standardized anywhere. The >> general concept is that it should follow all the other standards, but >> act as a short-lived user agent. For example, you can imagine that >> the user agent is created when the user enters incognito and destroyed >> when the user leaves incognito. >> >> If we were to standardize the mode, we'd probably do it in a working >> group similar to http://www.w3.org/2006/WSC/. However, I'm not sure >> how much interest there is around that task. > > Another option is a short Internet Draft that would become an independent > submission RFC that says "here is how a few browser vendors define the > problem and solve it, at the time that this is published". That is *exactly* > what the independent submission RFCs are good for. No wide IETF review, no > need to listen to anyone who thinks you should do it differently; just "here > is what we do, and why".
That sounds like a reasonable plan. Collin Jackson has written up a detailed analysis of the current state of affairs in this paper: http://www.collinjackson.com/research/private-browsing.pdf Adam _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
