(resending to tor-dev because the original message didn't go through)
On 03/16/2014 11:52 PM, Yan Zhu wrote:
On 03/16/2014 07:59 PM, Gunes Acar wrote:
Dear All,
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:
Hi Gunes,
I think all of these projects below would primarily be with EFF, not Tor directly. Peter and/or I would be your point of contact; I'm not familiar enough with Panopticlick at this time to give you much feedback on the ideas below, so I cc'ed Peter.
- 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?)
Peter, what's the blocker on this? It sounds like Tor folks really want it to happen soon, so I'm happy to take the lead on helping get this open-sourced from the EFF side.
- Add machine-readability support outlined in Tor Automation
proposals: https://people.torproject.org/~boklm/automation/tor-automation-proposals.htm... a) which one(s) should we implement? JSON, YAML, XML?
No input here.
- 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 greatly useful. Another good place to look is Mozilla's bug tracker (https://bugzilla.mozilla.org/).
- 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)
Same as above.
- Backport new "attacks" found in 3 & 4 to EFF's Panopticlick in case
they consider an update.
Yes, I'm happy to get those updates into EFF's instance.
- Convert fixed FP-related bugs into regression tests.
https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting&...
- 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
Work on potential fingerprinting bugs that ESR31 may bring.
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.htm...
- 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.
All of the above sounds fine.
Assuming that we can get Panopticlick open-sourced, I'm more than happy to help you with any of these subprojects.
-Yan (EFF Staff Technologist / HTTPS Everywhere maintainer)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Yan,
Glad that you're interested in the project. It'd be very nice collaborate with you on this.
Indeed, we've been corresponding with Peter for a related project and I mentioned my intention to work as a middleman between EFF and Tor.
In addition to Peter, it'd be very nice to hear what Tor side thinks, especially the potential mentors Nicolas, Mike and Georg.
Cheers, Gunes
On 03/17/2014 11:44 AM, Yan Zhu wrote:
(resending to tor-dev because the original message didn't go through)
On 03/16/2014 11:52 PM, Yan Zhu wrote:
On 03/16/2014 07:59 PM, Gunes Acar wrote:
Dear All,
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:
Hi Gunes,
I think all of these projects below would primarily be with EFF, not Tor directly. Peter and/or I would be your point of contact; I'm not familiar enough with Panopticlick at this time to give you much feedback on the ideas below, so I cc'ed Peter.
- 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?)
Peter, what's the blocker on this? It sounds like Tor folks really want it to happen soon, so I'm happy to take the lead on helping get this open-sourced from the EFF side.
- Add machine-readability support outlined in Tor Automation
proposals: https://people.torproject.org/~boklm/automation/tor-automation-proposals.htm...
a) which one(s) should we implement? JSON, YAML, XML?
No input here.
- 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 greatly useful. Another good place to look is Mozilla's bug tracker (https://bugzilla.mozilla.org/).
- 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)
Same as above.
- Backport new "attacks" found in 3 & 4 to EFF's Panopticlick
in case they consider an update.
Yes, I'm happy to get those updates into EFF's instance.
- Convert fixed FP-related bugs into regression tests.
https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting&...
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
Work on potential fingerprinting bugs that ESR31 may bring.
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.htm...
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.
All of the above sounds fine.
Assuming that we can get Panopticlick open-sourced, I'm more than happy to help you with any of these subprojects.
-Yan (EFF Staff Technologist / HTTPS Everywhere maintainer)
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 03/17/2014 04:41 AM, Gunes Acar wrote:
Hi Yan,
Glad that you're interested in the project. It'd be very nice collaborate with you on this.
Indeed, we've been corresponding with Peter for a related project and I mentioned my intention to work as a middleman between EFF and Tor.
Great, it seems that Peter and I are both interested and willing to help.
Regarding https://trac.torproject.org/projects/tor/ticket/6119#comment:10, Peter says he has some reluctance to open source the project (not the data) because it might make it easier for some websites to track visitors without their consent.
-Yan
Yan Zhu:
On 03/17/2014 04:41 AM, Gunes Acar wrote:
Hi Yan,
Glad that you're interested in the project. It'd be very nice collaborate with you on this.
Indeed, we've been corresponding with Peter for a related project and I mentioned my intention to work as a middleman between EFF and Tor.
Great, it seems that Peter and I are both interested and willing to help.
Regarding https://trac.torproject.org/projects/tor/ticket/6119#comment:10, Peter says he has some reluctance to open source the project (not the data) because it might make it easier for some websites to track visitors without their consent.
This might have been a valid concern 5 years ago, but now it's just a joke. The tests on Panopticlick are ancient, widely known, easy to reproduce, and since then much more severe and invasive mechanisms of fingerprinting have since been developed/deployed in modern browsers.
Moreover, only 2 of the tests it performs actually apply to Tor Browser users.
Banks in particular have already deployed some of the techniques we've fixed that the EFF study entirely predates. And these techniques are far higher entropy than browser resolution (such as localhost open port enumeration, OS theme fingerprinting, and HTML5+WebGL canvas rendering+extraction+hashing).
Not only should we (as Tor) publicly provide tests and easy-to-deploy working PoC code for all of these vectors, we should also endeavor to detail cases where major browser vendors are ignoring or exacerbating this problem, and make it easy for everyone to test and observe this behavior themselves.
Not sure if that means the EFF now has a conflict of interest with this project for some ridiculous reason, but frankly any attempt at trying to "hide" these techniques is downright silly. They are too well known (most are publicly documented elsewhere, or at least on our bugtracker), and there's waaay too much money on the other side of the fence in terms of incentives to develop and deploy working attacks.
Further, starting the from EFF codebase might also be a hindrance to us. It is not designed for measuring the effects of defenses. In fact, its measurement mechanisms actively penalize any attempt at defense development (because any approach to alter browser behavior instantly makes you more unique than the previous userbase).
I actually think Panopticlick has of late done more to prevent browser fingerprinting defense development than to encourage it. I would really like to see it DIAF.
Here's hoping we can make something better!
-
Gunes Acar -
Mike Perry -
Yan Zhu