W3C home > Mailing lists > Public > public-privacy@w3.org > April to June 2019

Re: Detecting incognito mode

From: Shivan Kaul Sahib <shivankaulsahib@gmail.com>
Date: Sun, 16 Jun 2019 13:29:04 -0700
Message-ID: <CAG3f7MhVSJOvQtuCrE=bNiJsL_N9Nx64-x2Yd3ia_JdFeb7=Lw@mail.gmail.com>
To: Nick Doty <npdoty@ischool.berkeley.edu>
Cc: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Thanks Nick.

A couple of IETFs ago at the f2f PING meeting, folks discussed building a "
Panopticlick <https://panopticlick.eff.org/> for Private Browsing Mode"
i.e. a web page that a user can navigate to while in private-browsing mode
and check if 1) they are detectable, 2) what guarantees their browser
provides them while in private-browsing (doesn't retain cookies, etc). It
would also be somewhat similar to the WebRTC Local IP Address leak page we
worked on last year (though I hope with prettier UI/marketing):

If there's interest and people are showing up for IETF next month in
Montreal, we could get a table at the hackathon, else async.

On Tue, Jun 11, 2019 at 12:55 PM Nick Doty <npdoty@ischool.berkeley.edu>

> This detection topic is coming up again; the TAG observation explicitly
> lists a goal that private browsing modes should not be detectable [0], and
> there is some recent activity from Chrome to disable some distinguishing
> signals [1] (the file system access API, as mentioned in this thread from
> last year).
> Some privacy modes are necessarily going to be detectable by sites,
> because they restrict access to certain requests (like Tracking Protection
> in Firefox, which blocks requests to a list of known trackers). But I do
> think making *local* privacy modes undetectable by the server seems like a
> worthy goal.
> I still think the containerization case is the important related goal. It
> might be entirely reasonable to have a privacy mode that is detectable by
> the site for cases where the user is explicitly opting in to a different
> set of functionality. The user may even directly want the site to know that
> they’re requesting a more private mode (for example, DNT: 1). But in
> addition, it would be useful if a user could have some confidence that
> activity in one container can’t trivially be connected to activity outside
> that container.
> Hard guarantees are difficult to provide, of course, because this comes
> down to browser fingerprinting, but I think it would be useful to list the
> issues that do provide these disclosures to servers and cut down on them.
> For example, it sounds like Safari is blocking access to localStorage in
> private mode, and that Firefox is blocking access to IndexedDB and Service
> Workers. The Boston Globe js (and other related detection scripts [2]) are
> a starting point, but almost certainly not an exhaustive list, since a
> detection script just needs a single reliable-for-now signal.
> —Nick
> [0] https://w3ctag.github.io/private-browsing-modes/
> [1] https://twitter.com/paul_irish/status/1138471166115368960
> [2] https://gist.github.com/kdzwinel/783df9b129ae5c8443dd96c0d4ed9723
> > On Apr 10, 2018, at 6:35 PM, Nick Doty <npdoty@ischool.berkeley.edu>
> wrote:
> >
> > On Mar 27, 2018, at 8:27 PM, Shivan Kaul Sahib <
> shivankaulsahib@gmail.com> wrote:
> >> Hi all, just remembered that at IETF 101 PING meeting we'd had a brief
> discussion about how websites can detect incognito mode. Did a quick Google
> search and a stack overflow answer came up.
> https://stackoverflow.com/a/27805491
> >>
> >> Basically try requesting the file system API and if it doesn't exist
> then you're in incognito mode. I'd imagine that to mitigate this one could
> patch some js on so that the call to check if file system API exists
> returns true but then you have an arms race where the only way to win is to
> reintroduce the API entirely in incognito mode.
> >
> > Hiding private browsing status is likely to be difficult, as you note,
> because if it has meaningful changes, those changes may be observable to
> the site.
> >
> > I think it might be more complicated than that simple Chrome-specific
> suggestion from a few years ago. A browser could provide the file system
> API and just make any files stored be separate from those accessible to
> other browser windows, etc. and I think browsers have done this with
> localStorage, for example. I'm not sure if there's a single source
> documenting the different models in each browser, but I suspect that user
> agents would typically like it not to be easy to detect private browsing
> mode, but that making it infeasible or impossible will be challenging.
> >
> > Mozilla's documentation suggests that they aren't generally successful
> at hiding all side effects:
> > https://wiki.mozilla.org/Private_Browsing
> >
> > Increasingly relevant would be site-side detection of when a user is
> within a limited container even if that container isn't considered
> "private" or "incognito", and I suspect that UAs would be interested in
> making that not accessible to the site. So if I browse Facebook in a way
> that all state mechanisms are isolated, can Facebook like buttons on other
> sites determine that I'm the same user? Or can Facebook see that I'm using
> the Facebook container plugin and try to discourage me when I'm in that
> mode?
> >
> > In the ultimate case, that might come down to the feasibility of
> mitigating browser fingerprinting.
> >
> > —Nick
Received on Sunday, 16 June 2019 20:28:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:49:38 UTC