[webkit-qt] 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). 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. 

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)

How Qt exposes this inspection to the client, so the client can ensure the 
returned values meet the privacy policy of the user or the browser's own 
privacy strategy is where the API question comes in.

My initial thinking is at:

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

A note on V8: QtWebKit will eventually allow bind to V8 as well as JSCore. 
V8 seems to allow greater flexibility for overloading all DOM objects. One 
option is to wait and see what happens in that direction. However V8 won't 
solve CSS, and the great disadvantage of overloading DOM objects is that 
you end up having to manage both CSS and DOM separately.  Ensuring 
consistency between the two seems best achieved by making WebCore get the 
information it needs from the same place for both: 
FrameLoaderClient/ChromeClient or some other client-facing interface.

Also 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? Can you comment on the API 
in 56678 above? Am I going the right way about exposing the user's 
environment information to the port and client in 56274 and 56482?

Thanks,
Robert