-----BEGIN PGP SIGNED MESSAGE----- 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#QAandTe...
Sure,
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 possible.
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev