[webkit-dev] API for Handling Browser Fingerprinting

[Robert Hogan]

Hi,

I am trying to build a set of requirements for an anti-fingerprinting API in 
WebKit. I have a wiki page where I've started dumping all the things such 
an API needs to worry about:

https://trac.webkit.org/wiki/Fingerprinting

From an implementation point of view I've started by looking at two primary 
sources for leaking distincitive information about the user: DOM objects 
and CSS Style sheets. Even though these are hard to solve, by the standards 
of the other items they are the nearest to low-hanging fruit and the shape 
of the solution required is relatively straightforward.

At the moment, WebKit doesn't offer a dedicated mechanism for managing the 
information exposed by DOM objects. However it is possible to use something 
of a side-channel to manage the objects that JSCore does not consider read-
only, e.g. Navigator and Screen (since 
https://bugs.webkit.org/show_bug.cgi?id=41802). In Qt's case, I'm referring 
to 
QWebFrame::addToJavaScriptWindowObject(), which allows a client to add a 
custom object to the DOM and by a happy side-effect also allows you to 
overload replaceable built-in objects. 

This approach comes unstuck for read-only objects in JSCore, namely 
document, window and history. The properties exposed by these objects are 
mostly stored internally by WebCore or inspected directly from the user's 
application environment. The same goes for CSS.

It seems a good thing, in it's own right, for WebCore to pass this sort of 
inspection through WebKit so that ports can decide the level of client 
delegation required, e.g. through FrameLoaderClient or ChromeClient. I've 
submitted patches for this at:

https://bugs.webkit.org/show_bug.cgi?id=56274 (DOM)
https://bugs.webkit.org/show_bug.cgi?id=56482 (CSS)


Note that I'm talking primarily about a client-facing API rather than 
a web-facing API that can be used by extensions. This is a product of my 
own use-case - which is a browser that implements an anti-fingerprinting 
policy itself. A web-facing API faces inherent problems with sites 
circumventing it maliciously - see 
https://www.torproject.org/torbutton/en/design/#jshooks and the links to 
side-stepping overloading firefox's window object there. I'm not saying this 
is a problem that exists in WebKit too, but it is a problem to which 
client-facing API is much less vulnerable.

So can you guys give me some feedback on this?  Am I going the right way 
about exposing the user's environment information to the port and client in 
56274 and 56482?

Thanks,
Robert




-----------------------------------------