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".

--Paul Hoffman

_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec

Reply via email to