[webkit-qt] API for Handling Browser Fingerprinting
lists at roberthogan.net
Sun Mar 27 05:46:16 PDT 2011
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:
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
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
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:
How Qt exposes this inspection to the client, so the client can ensure the
privacy strategy is where the API question comes in.
My initial thinking is at:
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?
More information about the webkit-qt