[tbb-dev] Quo Vadis, Private Browsing Mode?

Sun Feb 1 21:37:40 UTC 2015

I've pointed the Mozilla dev-privacy list at this thread to see what
they think. See
https://groups.google.com/d/topic/mozilla.dev.privacy/o-1UVHwAlKk and
https://groups.google.com/d/msg/mozilla.dev.privacy/XQza_CmYDr4/7hemg2vtyUYJ

If you're not currently subscribed to dev-privacy, you may want to do so
now so you can weigh in: https://lists.mozilla.org/listinfo/dev-privacy

Georg Koppen:
> Hi all,
> 
> the discussion about how to handle our fingerprinting patches in the
> Private Browsing Mode (PBM) space we had on 01/12 made me think a bit
> more about the topic in general.
> 
> So, PBM currently is just meant to avoid saving information about the
> sites you visit. Nothing more and nothing less.[1] This basically maps
> to the disk avoidance requirement in the Tor Browser design document.[2]
> The question is now how to treat the other privacy relevant areas like
> cross-origin linkability or fingerprinting? Should we invent new
> modes and try to sell them to the user in addition to the Private
> Browsing Mode? And if so, how exactly do we relate all these things
> together given that there are now private windows and non-private
> windows coexisting in vanilla Firefox versions (thanks for bringing this
> complication up, Arthur)?
> 
> Here is what I think we should aim at: We should have one mode we sell
> as private browsing mode, call it Private Browsing Mode+ (PBM+) for now,
> that contains the different areas I mentioned above as they are all
> related to "privacy" in one way.
> 
> How should it work
> ------------------
> 
> If you look at the current privacy pane in your Firefox you see that
> there are already some foundations laid for that idea in that Mozilla
> seems to acknowledge that there are different angles to "privacy": there
> is the Tracking section that would roughly correspond to our
> cross-origin linkability area, then there is the History section which
> regulates the disk avoidance part and then there is the odd Location Bar
> section which is presumably there to optionally prevent people from
> looking over ones shoulder. No fingerprinting part. No proxy part (in
> case users are looking for location privacy).
> At the same time the privacy pane is highly confusing: What do third
> party cookie settings play for a role in the history section, for
> instance? And why are these settings deeply buried there and not visible
> in the Tracking section?
> 
> I am not talking here about how the privacy pane should look like in
> non-PBM(+) but if PBM+ got enabled the pane could by quite clean and
> show by default five checkboxes and one button like
> 
> [x] Enable Private Browsing Mode+
> 
>     [x] Don't remember history
>     [x] Prevent website tracking
>     [x] Prevent browser fingerprinting
>     [ ] Prevent location tracking (use a proxy)
> 
>                                [Show site data]
> 
> (We could think about checking the last checkbox, too, if a proxy is
> already configured)
> 
> Users would then
> 
> 1) easily see what kind of privacy related protections they have enabled
> without the need to dig down some obscure menus and fiddle with several
> settings.
> 2) be able to configure their mode according to their needs (yes, there
> are people that want their history being enabled (I am not of that sort
> btw) while all the other protections remain in place).
> 3) get a place where the improved privacy UI mentioned in our design
> document would have a good place (we might need to think about which
> relationship it has to the prevent-tracking-option above but that is
> just a detail): a "Show site data" button.
> 
> Why should it work that way
> ---------------------------
> 
> First if all, it is highly confusing for a user to have a bunch of modes
> to select from if she wants to get privacy on the web. "Enable Private
> Browsing Mode" somewhere in the menu or via a toolbar button should be
> enough. There is no need for her to know things about the different
> parts of the privacy concept.
> 
> Second, there is still a big part of users that see more than one angle
> with respect to privacy and include the linkability and fingerprinting
> part in their concept of a private browsing mode.[3] We should take care
> of them and incorporate that into the UI I think. This is especially
> important, I think, as the usual things that hit the mainstream press
> and thus have a chance to get seen by and influence normal users are
> linkability/fingerprinting related.[4][5]
> 
> What to do
> ----------
> 
> For the linkability related things we have a preference which makes it
> a) easier for Mozilla to merge our patches and b) makes it easier for
> the UI I outlined above. It might even make it easier for Mozilla to
> adapt such a UI as they could just flip a preference if they really
> think that cross-origin linkability has nothing to do with a Private
> Browsing Mode.
> 
> It might make sense to have a preference for the fingerprinting patches,
> too, then given the model above. Something like
> "privacy.fingerprinting.disable" maybe. This would allow Mozilla then
> again to leave the checkbox unchecked in a UI like the one above if they
> think fingerprinting does not belong into the Private Browsing Mode. It
> might make upstreaming patches easier, too.
> And, as a last point, we should not let us distract here from people
> framing the fingerprinting issue as a security related one being
> orthogonal to privacy concerns.[6]
> 
> Georg
> 
> [1]
> https://support.mozilla.org/en-US/kb/private-browsing-browse-web-without-saving-info
> [2] https://www.torproject.org/projects/torbrowser/design/#disk-avoidance
> [3] About 22% according to
> http://www.winlab.rutgers.edu/~janne/WPES14-privatebrowsing.pdf. But the
> data they collected is not as robust as I'd like to have it.
> [4] E.g.:
> http://www.mediapost.com/publications/article/155032/#axzz2JFJ5s8l1
> [5] E.g.:
> https://www.propublica.org/article/meet-the-online-tracking-device-that-is-virtually-impossible-to-block
> [6] See the FPDetective paper:
> https://www.cosic.esat.kuleuven.be/publications/article-2334.pdf
> sections 7.1 and 7.3 for examples
> 
> 
> 

> _______________________________________________
> tbb-dev mailing list
> tbb-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20150201/9ed8adc1/attachment.sig>