[tor-dev] Panopticlick summer project

Gunes Acar gunes.acar at esat.kuleuven.be
Mon Apr 21 14:03:34 UTC 2014

Hash: SHA1

On Mon 21 Apr 2014 02:21:35 PM CEST, Mike Perry wrote:
> Gunes Acar: Sorry everyone for the long pause.
> I wrote down a proposal (and some code) to address issues raised
> by Mike and George: 
> https://securehomes.esat.kuleuven.be/~gacar/summer_2014.pdf
> Looking for your comments and critics...
>> This proposal looks like quite a good start. With respect to
>> automated testing, you should definitely discuss this with
>> Nicolas Vigier, who is our lead automation engineer. He has begun
>> writing TBB automation tests, and can help you integrate your
>> tests into that framework. You can see a few links to the
>> existing testing infrastructure at in the QA and testing section
>> of the TBB hacking doc: 
>> https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#QAandTesting

I already have some questions noted down for him.
But I must say the framework he set up is pretty easy to extend.
I could add and run my tests in minutes.

>> With respect to the rest of it, my main immediate question is how
>> we should separate the results by Tor Browser version. Tor
>> Browser currently reports its user agent string as the Windows
>> build of the Firefox ESR release it is based off of, with no
>> minor version.
>> This likely means we want users who are comfortable submitting
>> their results to the dataset to select their specific TBB version
>> (which is visible in the upper-right corner of about:tor).
>> However, if they get this wrong, it may bias results. :/

I'd prefer minimizing the user intervention. Maybe we can modify
Torbutton to place a link to test suite on about:tor page that
includes TBB version in the URL (or as a hidden form field). We may
have the same link somewhere in the Torbutton drop down menu.

And if we want to link to the test suite from a web site, we may
redirect users through about:tor?run=fptest to collect and pass the
TBB version automatically. Or have a about:fingerprint page that does
the same.

Still we may need some sanity checks to protect data from potential
polluters (crafting URLs with the fake TBB version), if that's ever

> On 03/21/2014 11:39 PM, Peter Eckersley wrote:
>>>> I think we're fine with open sourcing under the Affero
>>>> GPLv3.
>>>> On Tue, Mar 18, 2014 at 12:28:12PM -0700, Mike Perry wrote:
>>>>> 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!
>>>>> -- Mike Perry
>> _______________________________________________ tor-dev mailing
>> list tor-dev at lists.torproject.org 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> _______________________________________________ tor-dev mailing
> list tor-dev at lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the tor-dev mailing list