Re: Automatic private browsing upgrades

>  <>On Wed, Sep 2, 2015 at 11:58 PM, Francois Marier <francois@mozilla.com <mailto:francois@mozilla.com?Subject=Re%3A%20Automatic%20private%20browsing%20upgrades&In-Reply-To=%3CCAOAcki9CqkuCe1wePw7iReP_PLSiKhy1uRa7tFeSSvNJg5eSTA%40mail.gmail.com%3E&References=%3CCAOAcki9CqkuCe1wePw7iReP_PLSiKhy1uRa7tFeSSvNJg5eSTA%40mail.gmail.com%3E>>
> wrote:
> 
> > I'd like to propose something that was suggested by François Légaré on
> > the W3C Privacy list [1].
> >
> > The short description of it is: a mechanism for an author to tell the
> > browser that their site should only be viewed in Private Browsing /
> > incognito mode.
> 
> Well, this immediately runs into the problem that there's no specification
> of what Private Browsing / Incognito mode actually does.  Even when it
> comes to basic things like cookie lifetime, there are different behaviors
> among browsers.  There has been some effort to clean this up, but AFAIK,
> not much progress.
I'm not sure this functionality requires a complete definition of private browsing mode standardized across browsers. The spec could simply state a particular requirement of the mode. I think in this case it would be that the browser will make a best effort not to persist data on the client that indicates that the user visited the site or local storage from the site.
That is, it could be the list of eight pieces of data in http://www.w3.org/TR/2015/WD-clear-site-data-20150804/#goals <http://www.w3.org/TR/2015/WD-clear-site-data-20150804/#goals> plus "history information that indicates that the user has previously visited the site".
It seems like a private browsing mode description/standardization documents will try to divide up the approach into those that protect against local history and those that try to increase security against network attackers, site attackers or other tracking mechanisms. That will be a useful division, but in the meantime it seems like the use cases for private browsing upgrades are mostly motivated by the local history scenario specifically.
> > The long description (with mock-ups) is here:
> > https://wiki.mozilla.org/Security/Automatic_Private_Browsing_Upgrades <https://wiki.mozilla.org/Security/Automatic_Private_Browsing_Upgrades>
> >
> > The above is a draft intended to start a discussion, but the main things
> > I'm wondering about are:
> >
> > - Does it fit within our working group charter?
> > - Is CSP the right delivery mechanism?
> > - Should this be rolled into the clear-site-data spec instead?
At first I thought this was definitely a case for the proposed clear-site-data response header/JavaScript API, but I actually think the use case works better with a header indicating the mode change rather than an imperative indication from the site that data should at that moment be cleared. The site doesn't know when the visitor will leave the site, and doesn't want to constantly clear data on every request in the meantime.
> > Francois
> >
> > [1]
> > https://lists.w3.org/Archives/Public/public-privacy/2015JulSep/0087.html <https://lists.w3.org/Archives/Public/public-privacy/2015JulSep/0087.html>

Thanks for taking the PING discussion and turning it into a mockup and more detailed proposal!
-- Nick