-----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#QAandTesting 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTVSU2AAoJEPb7JcMmVt4gK5oH/2MxYxxjMIwAbGrpURgq8bQf TaNiFj+Kb0BPZWHTqF7956Q4iXhRc8Q4ZZEm6nz34uIhYKMisqn2A59aj8ozkXhF LBYEw4FT7yFXkhw8qTK2d/mwSDv6fUi6NcWYa3FDXzZzE7gRK9EChxagF/R6FtHy hqqRkwqp/pWOAJb4PCwKmaSSX8AhQvilF5FoGbr8Fvc/OxCyvCalk9RcMQy3p8PH U3zsSpSDK3iEF7aYhc53dBxLjepT4UXs/tMV9rK3lkS/y3MZ9HqxH4WON/8j43HD 6gU6LtER3H7MBYmrKegbACXD5uGANMzK3zrLAaFNFqe2dAXFPlWZzHaGqcTzmes= =nKUT -----END PGP SIGNATURE----- _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev