W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2015

Re: Automatic private browsing upgrades

From: Mike West <mkwst@google.com>
Date: Mon, 14 Sep 2015 10:34:11 +0200
Message-ID: <CAKXHy=ejEted3VgzPNPtdcoiM7UESMkHJt_qaxERTM6qBvP_AA@mail.gmail.com>
To: Nick Doty <npdoty@w3.org>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Francois Marier <francois@mozilla.com>, Richard Barnes <rbarnes@mozilla.com>
On Mon, Sep 14, 2015 at 8:56 AM, Nick Doty <npdoty@w3.org> wrote:

> > The long description (with mock-ups) is here:
> > 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.
>
> I agree with this analysis. That said, what is the intended scope of the
feature? That is, I imagine that the site the user lands on is only half
the story: they almost certainly got to that site via a series of
suspicious searches, links, etc. The current proposal doesn't do much to
clear those tracks, and I worry that we'd end up providing a feeling of
security that didn't really exist. If abusive partners are crawling through
my browsing history, they'll see the searches, even if they don't see me
landing on the protected website itself.

Would we need to offer a "Clear the last X minutes of browsing history!"
feature to websites? Could we do that in a way that we're comfortable with?

-mike
Received on Monday, 14 September 2015 08:35:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:15 UTC