-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for all the feedback Mike,
I'll be in touch with you and Georg on the Tor side.
For the other discussion: I don't think open-sourcing Panopticlick is
critical for this work. Rather, it's Panopticlick data that may inform
the information-theoretic evaluation of TBB's countermeasures (e.g. to
get a sense of font distribution to evaluate font limits: Can I
pick/probe 10 fonts to identify all Tor users?)
Actually we've been planning to publish the aggregated Panopticlick
data with Peter and this may be the perfect time to do it. Frankly, I
don't think EFF was reluctant to collaborate with you, rather I guess
they simply had no time. That's why I'm very glad to hear from Yan who
seem to be able to dedicate more time.
I hope that'd work for everybody - me dedicating some of my time (1-2
weeks) to work on the analysis of Panopticlick data.
Best,
Gunes
On Wed 19 Mar 2014 04:14:05 AM CET, Mike Perry wrote:
> 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@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
