- From: Steven Englehardt <ste@CS.Princeton.EDU>
- Date: Sun, 1 Nov 2015 11:25:45 -0500
- To: "Lukasz Olejnik (W3C)" <lukasz.w3c@gmail.com>
- Cc: Nick Doty <npdoty@ischool.berkeley.edu>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
- Message-ID: <CAMnnYSKBXby2SU7mDxmKtcQ8VHb=pa9WBvs6a539W0WOVkz9Nw@mail.gmail.com>
Lukasz, Great suggestion! We had to do just that for our canvas fingerprinting measurements. Gunes wrote a Firefox patch to record access to StrokeText, FillText, etc as well as grabbing the current javascript context/calling location. If hooks for this were already present, it would make things much easier...both for the initial study and for ongoing measurements. Best, Steve On Thu, Oct 29, 2015 at 7:12 PM, Lukasz Olejnik (W3C) <lukasz.w3c@gmail.com> wrote: > Dear Nick, Steve, > > Thanks for your input. I realize we know both of these works by now (and > thanks to all of their authors)! > > So the actionable insight might be: to compel browsers to count particular > uses of APIs and function calls. This is providing great and rich context, > which could then be: > - either interpreted by a browser privacy UI. > or > - interpreted by an extension > > But the point is to have standard hooks to make the data easily available. > > Another point is to provide even more context by marking what calls (and > how many times) were made by specific scripts (i.e. make the script URL > easily available). > > It does not necessarily need to be a matter of making it easier to detect > fingerprinting - one could imagine this to be part of a side > standard/note/recomendation. > > Kind regards > Lukasz Olejnik > > 2015-10-29 9:55 GMT+00:00 Nick Doty <npdoty@ischool.berkeley.edu>: > >> With Steve's permission, sharing these comments/suggestions for the >> Fingerprinting Guidance document. I believe this academic work supports the >> notion that designing APIs to facilitate detection of fingerprinting can >> make a large difference. >> >> I've started an issues list with these and some other comments received >> on Github: >> https://github.com/w3c/fingerprinting-guidance/issues >> >> Feedback is still welcome on this mailing list; I'm just using Github as >> a working mechanism to keep track. You can also comment or raise issues >> directly on Github if you prefer. Pull requests welcome! >> >> Cheers, >> Nick >> >> Begin forwarded message: >> >> *From: *Steven Englehardt <ste@CS.Princeton.EDU <ste@cs.princeton.edu>> >> *Date: *September 10, 2015 >> *Subject: **Fingerprinting Guidance Spec* >> >> Hello Nick, >> >> Great work on the fingerprinting guidance spec, I believe it will help >> reduce the fingerprinting surface of future APIs. There are two additional >> papers that I think are helpful to reference. >> >> The first paper is The Web Never Forgets: Persistant Tracking Mechanisms >> in the Wild <https://securehomes.esat.kuleuven.be/~gacar/persistent/>, a >> paper I co-authored. In it, we show how prevalent canvas fingerprinting, >> cookie respawning, and cookie syncing are on the web and evaluate the >> implications of the use of three three vectors in combination with each >> other. >> >> It is helpful as an example of detectability by academics, which you >> address several times in the spec. In general, it's a solid example of >> large scale measurement of two fingerprinting vectors, and of the impact a >> measurement study can have on the use of these APIs for fingerprinting. The >> two largest canvas fingerprinters stopped after we released our paper. >> Addressing issue #2 in Section 5.3, it's an example of how the design of >> the canvas API allowed us to detect the use of canvas for fingerprinting >> very accurately. >> >> The second is The Leaking Battery: A privacy analysis of the HTML5 >> Battery Status API <https://eprint.iacr.org/2015/616.pdf>. This paper >> shows how the design of the Battery Status API on Linux enabled >> fingerprintability. It highlights the importance of consistency across user >> agents (Section 5.2 Issue #1). It also shows that API designers should take >> care to expose the minimum amount of precision necessary for operation of a >> feature, a point that I think can be strengthened in the report. >> >> Thanks for your work on this! >> >> -Steve >> >> >
Received on Sunday, 1 November 2015 21:14:27 UTC