Re: Detecting incognito mode

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