Re: Detecting incognito mode

Thanks Nick.

A couple of IETFs ago at the f2f PING meeting, folks discussed building a "
Panopticlick <> 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 <>

> 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]
> [1]
> [2]
> > On Apr 10, 2018, at 6:35 PM, Nick Doty <>
> wrote:
> >
> > On Mar 27, 2018, at 8:27 PM, Shivan Kaul Sahib <
>> 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.
> >>
> >> 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:
> >
> >
> > 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