Gunes Acar: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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 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. :/ > 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 > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTUg4mAAoJEPb7JcMmVt4gQjwIALCsTOxvUFP3HY0N8Ap9fpKW > GD193EW32X80iH6VY54AIWA29wxKaKEM4vBJBVLkhYt8s68OAqaV1vMNtmEev26h > 2yg9us2HNYjBzaxFQpX7qhmDCiucpe3zVZZXq9T34OhjxscWc90JdvWA5D8Eiqto > exJzqi3k5djFU66apzfFAwYpk8E0Og582XFg5TOQFYGo6LvNyT69LH7+jlNsHL65 > atspVO47wKH4+0nhoG22tsMdZRzhmgSbSB1gx2a7Esf3dOBf+R0BBw+qcZptqq8Z > NPyobAecQzmV/SXgjDF4PaE12A4IkK4nCWUax7ksE6YbCNhAKBlcAt+/q2JeOt8= > =i+/g > -----END PGP SIGNATURE----- > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev