- From: Shivan Kaul Sahib <shivankaulsahib@gmail.com>
- Date: Sun, 16 Jun 2019 13:29:04 -0700
- To: Nick Doty <npdoty@ischool.berkeley.edu>
- Cc: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
- Message-ID: <CAG3f7MhVSJOvQtuCrE=bNiJsL_N9Nx64-x2Yd3ia_JdFeb7=Lw@mail.gmail.com>
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): https://ntblk.github.io/webrtc-privacy/ 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> wrote: > 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