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 ----------------------------------------- _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev