[Webkit-unassigned] [Bug 41801] New: 'Tracking-Resistant' Browsing

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 7 14:19:28 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=41801

           Summary: 'Tracking-Resistant' Browsing
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: robert at webkit.org


There are a number of things WebCore could do differently to reduce the user's exposure to remote tracking mechanisms but which it is not necessarily desirable to implement as default behaviour. At first glance, some of these appear a good fit with 'Private Browsing' but really they're addressing a different problem. Private browsing's overriding objective is to ensure no trace of a browsing session is left on your disk, fingerprinting a user's browser and tracking that browser's visits presents a different set of challenges.

Here are some:

- Fuzzing the JS Date object to prevent fingerprinting based on 'typing cadence'.
  http://arstechnica.com/tech-policy/news/2010/02/firm-uses-typing-cadence-to-finger-unauthorized-users.ars
- The window.screen object is quite revealing.
  (https://bugzilla.mozilla.org/show_bug.cgi?id=418986)
- Enumerating fonts through calls to a flash plugin can provide quite distinctive results
- Enumerating plugins likewise
- Uniform user-agent headers and navigator object values.
- Third-party cookie handling needs to be stricter if you're in tracking-resistance mode

Tracking-resistance also requires a different type of 'state separation' than that entailed by private browsing. For example, you might not want to share SSL session ids from a tracking-resistant session with a normal session. That isn't really an issue with private browsing which is all about locally detectable traces rather than remotely detectable ones. Obviously this particular example isn't something WebKit could do much about but it's the kind of problem this option would encounter. 

There's a lot more besides and I intend to raise individual bugs for each under this master bug.

This sort of tracking-resistance fits with at least two use cases:

- Tor users who want the properties of their browser in 'anonymous' mode to be indisinguishable from other users of the same browser in 'anonymous' mode.
- Users of 'private browsing' who want an extra level of privacy from remote as well as local sources. 

This mode, in and by itself, does not intend to neutralize tracking of the user's browser. That's because there are a lot of things the client will need to implement itself to ensure success. The purpose of the mode is to take care of things that WebCore/WebKit can do relatively easily and which, otherwise, each client would be left attempting to enforce indivudally through JS hooking and other messiness (with the attendant risk of fragmenting users into smaller groups than necessary through different implementation choices across WebKit clients). So this isn't proposed as a fingerprinting kill-button. The idea is to identify and implement a set of behaviours that are under WebCore's control and make individual WebKit-based browsers indistinguishable from each other when in this 'tracking resistant' mode.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list