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

[bugzilla-daemon at webkit.org]

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





--- Comment #7 from Robert Hogan <robert at webkit.org>  2010-07-14 12:37:09 PST ---
(In reply to comment #6)
> > 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
> 
> What are your approaches for solving/mitigating these issues?

The plan is to write up a wiki page elaborating each in detail. I hope to have the first draft up within a fortnight. Adam's link ( https://wiki.mozilla.org/Fingerprinting ) fleshes out quite a few of the implementation questions from a Firefox point of view.

My own thinking at the moment is that given the following considerations:

- Most of the problems cannot be solved without some measure of usability impact, great or small
- Some problems are outside WebKit's control and require client implementation

The first thing the wiki page will have to do is define what it can and cannot solve and decide whether the notion of a uniform fingerprint mode is still feasible or useful.

There may be a group of measures, like David Hyatt's fix to CSS history leaking, that can be implemented as default behaviour with little or no user impact.

There will be some measures like managing the Date() object or the plugins list that could generally be OK for day-to-day use but may adversely affect specialized use cases on some sites. This implies a performance trade-off and the page will need to define what, if any, trade off is acceptable.

There will be another group, such as managing the values returned by the navigator object, that can be partially solved by WebKit but which will rely on clients not undoing the work by customizing the user agent header for example.

Another group will contain measures that are not easily soluble and need to be fixed before the mode can make any claim to be helpful at all, such as the fact that plugins have largely unfettered access to the disk. 

So even at first glance it's apparent that most of the measures required would not be suitable for 'normal' browsing. Instead they are implementing behaviour that will be useful to browsers who want to implement an enhanced private or anonymous browsing mode and for whom it is not trivial, and even counterproductive, if they try to implement it themselves.

Unlike Firefox, a WebKit implementation cannot solve the problem in its own right. It can only solve the parts it shields from clients. So a big part of it will be defining the sort of things clients need to do themselves and the way to do it best in order to interoperate with what WebKit implements.

So to summarize: my approach at this point consists mostly of hot air.

> Sorting fonts and plugin lists is a possibility, but that only reduces entropy, so they are still useful for fingerprinting. Even if you remove the font list, an attacker could still have the browser render strings in popular fonts and test for the size of the corresponding elements in order to test whether the font is installed.

Sounds like meat for the wiki page!

You wouldn't remove the font or plugin list but decide on a list for the mode and stick to it. This means all WebKit clients would present the same list when in the mode and that would help satisfy the requirement to make all WebKit browsers indistinguishable from each other at least as fonts and plugins are concerned. There's no reason the list in either case has to be restrictive, and it does not have to conceal the fact that the client is fingerprinting-resistance mode. It just has to be large enough to support non-exotic browsing requirements and stable for long periods of time.

The brute force approach applies to plugins as well as fonts and is something that the mode would have to protect against by actually only supporting the fonts/plugins it says it does. This is a usability penalty.

Since plugins can retrieve the font list through actually walking the directory tree on disk, the major challenge here would seem to be intercepting these calls so that they can be safely manipulated. I don't know enough about the current method of sandboxing plugins in WebKit, if there is one, to allow something like this. Is this something that Chromium already has the potential to do in its own right?

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