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 _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
