[tor-dev] Panopticlick summer project

Wed Mar 19 03:14:05 UTC 2014

Gunes Acar:
> My name is Gunes Acar, a 2nd year PhD student at Computer Security and
> Industrial Cryptography (COSIC) group of University of Leuven.
> 
> I work with Prof. Claudia Diaz and study online tracking and browser
> fingerprinting. I'd like to work on "Panopticlick"
> (https://www.torproject.org/getinvolved/volunteer.html.en#panopticlick)
> summer
> project and other fingerprinting related issues which I tried to
> outline below:
> 
> 1) Collaborate with Peter at EFF to port/open-source Panopticlick:
> https://trac.torproject.org/projects/tor/ticket/6119#comment:4
> a) implement necessary modifications - e.g. we won't be having cookies
> or real IP addresses to match returning visitors.
> b) consider security implications of storing fingerprints (e.g. what
> happens if someone gets access to fingerprint database?)
> 
> 2) Add machine-readability support outlined in Tor Automation
> proposals:
> https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#helper-fingerprint
> a) which one(s) should we implement? JSON, YAML, XML?
> 
> 3) Survey the literature for fingerprinting attacks published since
> Panopticlick. Implement those that may apply to TBB:
> a) Canvas & WebGL fingerprinting (Mowery et al.) - make sure the patch
> at #6253 works
> b) JS engine fingerprinting (Mulazzani et al.)
> c) CSS & rendering engine fingerprinting, (Unger et al.)
> ...

This sounds good. We already have a fix for #1 though, but verification
can't hurt (the canvas should come back as all white unless the user
allows it).

We also have a couple fixes for CSS-based fingerprinting (fonts and
system colors) that are entropy-reduction efforts only. Actually
measuring the amount of entropy reduction here would be useful.

> 4) Check with realworld fingerprinting scripts to see if they collect
> anything that is not considered before. Check if TBB's FP
> countermeasures work against them. (We can use data from FPDetective
> study to find sites with fingerprinting scripts)

Great.

> 5) Backport new "attacks" found in 3 & 4 to EFF's Panopticlick in case
> they consider an update.

Unfortunately, the EFF has been reluctant to work with us in any way to
improve or re-deploy Panopticlick for our needs, hence the frustrated
tone of my other mail in this thread. It also seems that the EFF would
not permit your resulting work to be open source, which I believe is a
violation of the GSoC rules. I guess since you are not intending to
actually apply to GSoC, this is a moot point though. It's just also a
sore one for me, so I figured I'd poke it once more ;).

However, as I also said in my other mail, I actually think we may be
better served by developing something independent of Panopticlick. We
need per-TBB version breakdowns of all the statistics we record, so we
can measure the change in entropy as we deploy fixes and improvements
to our defenses, without previous datapoints biasing the distribution.

Other than some helper functions to store data and calculate entropy,
and one (or maybe two) simple fingerprinting tests, we should not need
any of the Panopticlick code for this project. It's also likely that our
DB schema will end up radically different, due to the need to segment
data by browser version (which may be input by the user), and the need
for many more (and more varied) tests than they have.

> 6) Convert fixed FP-related bugs into regression tests.
> https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting&status=closed
> 
> 7) Build test cases to check the severity of fingerprinting related
> open tickets, e.g.:
> https://trac.torproject.org/projects/tor/ticket/8770
> https://trac.torproject.org/projects/tor/ticket/10299
> 
> 8) Work on potential fingerprinting bugs that ESR31 may bring.
> 
> 9) ESR transitions seem to create a lot of FP-related issues that need
> to be checked manually (e.g. #9608). Consider developing a tool that
> iterates over the host objects of two browsers to compare them
> automatically (e.g. to pinpoint new objects, new methods, updated
> default values, etc.). Similar to "diff tool" mentioned here:
> https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#helper-fingerprint

I am not sure this is helpful. In general, we only want to measure
fingerprintability *within* a specific browser version.

To determine the appearance of new APIs, it's probably best and simplest
to simply review Mozilla's Developer Documentation, ie:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/24

> 10) Evaluate the font-limits of TBB by checking the average # of fonts
> Top 1 Million sites use. We can either collect fresh data with
> FPDetective or use the existing (~1 year old) data.

Excellent.

> More on my background relevant to fingerprinting and TBB code base:
> 
> We recently published a paper called "FPDetective: Dusting the Web for
> Fingerprinters" (CCS'13) to measure the prevalence of browser
> fingerprinting on the Internet. As a part of this study, we built
> instrumented browsers from Chromium and PhantomJS source code and
> developed a framework to detect fingerprinting
> (https://github.com/fpdetective/).
> 
> I also got my hands dirty with the TBB source code to seek
> vulnerabilities in FP countermeasures. Two ways I found to circumvent
> existing font limits were as follows:
> https://trac.torproject.org/projects/tor/ticket/8270#comment:2
> https://trac.torproject.org/projects/tor/ticket/5798#comment:13

Right. A proper fix for #5798 will address this, as documented in the
bug. I would not get distracted leveraging implementation bugs like this
in your data collection, especially if we're aware of them and simply
haven't had the development capacity to fix them.

Actual shortcomings of a defense in an information-theoretic sense (such
as 10 fonts being too many, or our screen resolution leaking too much
entropy) are better areas of focus, given the time.

However, if you also want to write any TBB patches to fix any
implementation bugs (known or newly discovered), you will be my new
hero. :)

> Other pointers:
> My website: http://www.esat.kuleuven.be/cosic/?page_id=126
> FPDetective website: https://www.cosic.esat.kuleuven.be/fpdetective/
> My (first & only) Tor patch:
> https://trac.torproject.org/projects/tor/ticket/10472
> My Tor FAQ profile: http://tor.stackexchange.com/users/731/gacar
> 
> Looking for your comments,
> Cheers,
> Gunes
> 
> N.B.: I won't be applying to GSoC.

Oh wow. Ok. I suppose that settles the GSoC Open Source snafu, and
in a way that doesn't cause a legal disagreement with the EFF. Hurray!
;)

Please keep me updated of your progress and plans, in any case!

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140318/ec09467a/attachment.sig>