Re: [tor-dev] Make Tor Browser Faster GSOC Project
On 17/03/17 20:18, Tom Ritter wrote: > Anyway, the topic on the website is a bit ambiguous, so I've attempted > to flesh out the project more here: > > https://storm.torproject.org/shared/URdVCz8eCbBfQzYwG3gaR-KuCvMTIS3zU7emq3AF7A3 > > I'd welcome input from the rest of the tor community on this as well. > > -tom Hi Tom, I added some comments and questions to the proposal: https://storm.torproject.org/shared/URdVCz8eCbBfQzYwG3gaR-KuCvMTIS3zU7emq3AF7A3 Best, Gunes ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [GSoC 2016] Exitmap Improvements Project - Status Report #1
On 2016-06-05 19:31, meejah wrote: > Mridul Malpotra writes: > >> As suggested in the proposal, using Selenium seems like the right >> choice. I have read about the RC and WebDriver and have decided to go >> forward with the latter [..] > > +1 on this choice, WebDriver is the newer (and better) API. > I think RC will be removed in the upcoming Selenium 3, so another +1 for the WebDriver. FWIW, we've been developing a Python WebDriver library to automate Tor Browser: https://github.com/webfp/tor-browser-selenium TBB nightly tests used to include Selenium tests before moving to Marionette. Could be useful to check them as well: https://gitweb.torproject.org/boklm/tor-browser-bundle-testsuite.git/tree/selenium-tests?id=a434afd98d9a2b0c02f7d60382e1470667adb7b2 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GSoC'16 proposal: the Torprinter project (a Panopticlick-like website)
Hi Pierre, On 2016-03-16 11:58, Pierre Laperdrix wrote: > Hi Gunes, > > Thanks a lot for the feedback! > > On 03/16/2016 03:30 PM, gunes acar wrote: >> Hi Pierre, >> >> Thanks for the very well thought proposal! >> >> I'm curious about your ideas on the "returning device problem." EFF's >> Panopticlick and AmIUnique.org use a combination of cookies and IP >> address to recognize returning users - so that their fingerprints are >> not "double-counted." >> >> Since these signals will not available anymore (unless the user opt-ins >> to retain the cookie), I wonder what'd be your ideas to address this issue. > > This one is a really interesting question but a tricky one because we > can't really rely on the cookies+IP combination with the Tor browser. > My answer here is simple: it all depends on the goal we set for the website. > I think the original goals were to understand the fingerprint distribution and to measure the effect of introduced defenses (e.g. by measuring the uniqueness/entropy before vs. after the defense). I agree with you that guaranteeing no double-counting may not be possible, especially if we consider a determined attacker. A more realistic goal could be to filter out double-submissions from benign users. Let me point out an idea raised in the previous discussions: One option to enroll users for the tests was to have a link on the about:tor page similar to "Test Tor Network Settings" link. The fingerprint link could also include (e.g. as URL parameters) TB version, localization and OS type to establish ground truth for the tests. I wonder, if the same link can be used to signal a fresh fingerprint submission to the server. This may require keeping a boolean state (!) on the client side which may mean "already submitted a fingerprint with the current TB version." This state can be kept in TorButton's storage, away from the reach of non-chrome scripts. The fingerprinting site could then use this parameter to distinguish between fresh and recurrent submissions. An alternative can be to present a fresh submission link on the "changelog" tab, which is guaranteed to be shown once after each update - right when we want to collect a new test from users. Perhaps we should be cautious about keeping any client-side state, and be clear about the limitations of these approaches. But I feel like the way we enroll the users can be used to prevent pollution, at least by the well-behaving Tor users. Just wanted point out this line of thought, no doubt you can come up with better alternatives. Best, Gunes > Do we want to learn how many different values there are for a specific > test so that we can reduce diversity among Tor users? In that case, the > site would not store duplicated fingerprints or it could be > finer-grained and not store duplicated values for each test. > > Or do we want to go further and know the actual distribution of values > among Tor users so that it may guide the development of a potential > defense? In this case, the site must identify returning users and it is > a lot harder to do here. The only method that comes to mind and that > would be accurate enough to work in this situation would be to put the > test suite behind some kind of registration system. The problem is that > a mandatory registration goes in the complete opposite direction of what > Tor is about and it would greatly limit the number of participating > users (or even render the site useless before it is even launched). A > solution in the middle would be not to store duplicated fingerprints but > I really don't know how much it would affect the statistics in the long > run. Would it be marginal and affect like 2/3/4% of collected > fingerprints or would it be a lot more and go above 20% or else? > > Finally, I thought about using additional means of identification like > canvas fingerprinting but I don't think there would be enough diversity > here to identify a browser. > > >> >> Please find other responses below. >> >> Best, >> Gunes >> >> On 2016-03-15 04:46, Pierre Laperdrix wrote: >>> Hi Tor Community, >>> >>> - How closed/private/transparent should the website be about its tests >>> and the results? Should every tests be clearly indicated on the webpage >>> with their own description? or should some tests stay hidden to prevent >>> spreading usable tests to fingerprint Tor users? >> >> I think the site should be transparent about the tests it runs. Perhaps >> the majority of the fingerprinting tests/code will run on the client >> side and can be easily captured by anyone with necessary skills (even if >> yo
Re: [tor-dev] GSoC'16 proposal: the Torprinter project (a Panopticlick-like website)
Hi Pierre, Thanks for the very well thought proposal! I'm curious about your ideas on the "returning device problem." EFF's Panopticlick and AmIUnique.org use a combination of cookies and IP address to recognize returning users - so that their fingerprints are not "double-counted." Since these signals will not available anymore (unless the user opt-ins to retain the cookie), I wonder what'd be your ideas to address this issue. Please find other responses below. Best, Gunes On 2016-03-15 04:46, Pierre Laperdrix wrote: > Hi Tor Community, > > My name is Pierre and I'm really interested in participating in a GSoC > project this year with the Tor organization. Since I've been working on > browser fingerprinting for the past two years, I'd love to build a > Panopticlick-like website to improve the fingerprinting defenses of the > Tor browser. > > I've included below my proposal in case anyone has ideas or suggestions, > especially on the technical section or on some of the open questions > that I have. (It should be noted that the Torprinter name is subject to > change). > > > ** > > Summary - The Torprinter project: a browser fingerprinting website to > improve Tor fingerprinting defenses > The capabilities of browser fingerprinting as a tool to track users > online has been demonstrated by Panopticlick and other research papers > since 2010. The Tor community is fully aware of the problem and the Tor > browser has been modified to follow the "one fingerprint for all" > approach. Spoofing HTTP headers, removing plugins, including bundled > fonts, preventing canvas image extraction: these are a few examples of > the progress made by Tor developers to protect their users against such > threat. However, due to the constant evolution of the web and its > underlying technologies, it has become a true challenge to always stay > ahead of the latest fingerprinting techniques. > I'm deeply interested in privacy and I've been studying browser > fingerprinting for the past 2 years. I've launched 18 months ago the > AmIUnique.org website to investigate the latest fingerprinting > techniques. Collecting data on thousands of devices is one of the keys > to understand and counter the fingerprinting problem. > For this Google Summer of Code project, I propose to develop the > Torprinter website that will run a fingerprinting test suite and collect > data from Tor browsers to help developers design and test new defenses > against browser fingerprinting. The website will be similar to AmIUnique > or Panopticlick for users where they will get a complete summary with > statistics after the test suite has been executed. It can be used to > test new fingerprinting protection as well as making sure that > fingerprinting-related bugs were correctly fixed with specific > regression tests. The expected long-term impact of this project is to > reduce the differences between Tor users and reinforce their privacy and > anonymity online. In a second step, the website could open its doors to > more browsers so that it could become a platform where vendors can > implement significant changes in their browsers with regards to privacy > and see the impact first-hand on the website. With the strong expertise > I have acquired on the fingerprinting subject and the experience I have > gained by developing the AmIUnique website, I believe I'm fully > qualified to see such a project through to completion. > > Website features > The main feature of the website is to collect a set of fingerprintable > attributes on the client and calculate the distribution of values for > each attribute like Panopticlick or AmIUnique. The set of tests would > not only include known fingerprinting techniques but also ones developed > specifically for the Tor browser. > The second main feature of the website would be for Tor users to check > how close their current fingerprint is from the ideal unique fingerprint > that most users should share. A list of actions should be added to help > users configure their browser to reach this ideal fingerprint. > The third main feature would be an API for automated tests as detailed > by this page : > https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#helper-fingerprint > . This would enable automatic verification of Tor protection features > with regard to fingerprinting. When a new version is released, the > output of specific tests will be verified to check for any > evolution/changes/regressions from previous versions. > The fourth main feature I'd like to include is a complete stats page > where the user can go through every attribute and filter by OS, browser > version and more. > The inclusion of additional features that go beyond the core > functionnalities of the site should be driven by the needs of the > developers and the Tor community. > Still, a lot of open questions remain that should be addressed during > the bonding period t
Re: [tor-dev] GSOC: Panopticlick
Hi Akito, On 2016-03-11 03:43, - - wrote: > Hello! > > My name is Akito Ono. I'm a computer science student in Japan and very > intrested in participating in GSoC this year. > I read docs about projects and I was particularly intrested in Panopticlick > project. > And I have some questions about Panopticlick. > > > Is this project based on Libre-Panopticlick( > https://github.com/qqTYXn7/browserprint) or building from scratch? > EFF recently updated and open-sourced the Panopticlick code, perhaps this can be a better starting point: https://github.com/EFForg/panopticlick-python Also relevant: https://github.com/DIVERSIFY-project/amiunique https://browser-fingerprint.cs.fau.de/ > Is programming language used in project designated? > > > Best regards! > > > > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Project Idea | GSOC 2015 | Panopticlick | fake fingerprint
Hi Rohit, Please check the ticket #11949 and the comment by Georg: https://trac.torproject.org/projects/tor/ticket/11949#comment:1 TL;DR research on the advantages of randomization over the current approach (making everyone look like same) may be useful before starting with the actual implementation. Also, please check this thread on the limitations of JS hooks: https://lists.torproject.org/pipermail/tbb-dev/2014-June/73.html You can fool some fingerprinters by spoofing browser properties but more advanced scripts can easily uncover the real browser/device attributes by checking specific functionality [1] or using "side-channels" [2]. [1] see, "Evolution of functionality" subsection on https://seclab.cs.ucsb.edu/media/uploads/papers/sp2013_cookieless.pdf#page=10 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=418986, see, esp. Camillo's test vectors. Gunes On 02/12/2015 06:12 PM, l.m wrote: > Hi, > > For anonymous scraping it could certainly be useful. This poses a > problem as far as making Tor Project look as if it supports autonomous > anonymous scraping of web data. Ultimately this impression could lead to > even more blocking of Tor exits. Another problem with the idea of a > randomized fingerprint is that it breaks useability. It might be great > for scraping but web sites rely on knowing some of those parameters for > proper display. Finally it's worth mentioning that the goal of TBB > fingerprinting is to reduce entropy within TBB's user base. A random > fingerprint violates this constraint. > > I'm not commenting on gsoc eligibility +1 --just that it's an edge case > which will lead to blocking of Tor's exits. If more exit get blocked > then you cannot scrape. > > --leeroy > > > ___ > 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
Re: [tor-dev] Panopticlick summer project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon 05 May 2014 04:08:58 PM CEST, Nicolas Vigier wrote: > On Fri, 25 Apr 2014, Gunes Acar wrote: > >> >>> >>> And this looks like a very good start! If you think that's ready, I can >>> merge your patch (fp_tests.patch) so we start running those tests on >>> the next releases / nightly builds. >> Hi Nicholas, >> I think it won't hurt to merge and I'd be just glad. > > Great! > > Before merging your patch, a question about the license of your test > scripts: is there a specific license you want to use ? No, I'm fine with CC0 at the moment. Thanks > The testsuite is currently under CC0. If you want your tests to be under > a different license, they should mention the license in the headers. > > Nicolas > > > > ___ > 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/ iQEcBAEBAgAGBQJTaNRgAAoJEPb7JcMmVt4gsogH/1yic9mFI/yhw92fYkdyQTEp DgomC4YsRRnBGDJs+bIaOMXPesB8MFPpnmyljGX1CNHSkH5fvFHD6yXqQiPAFgkz hfYQPOSZT0Aw/GGQOekQnqbhnSTqfXT3XcpndCHrL2DcVfH+jmm9TfcBlowSe63F l8O5moI4jAm0FjV90mrOCIW9L3A7ds11SgOc1chUQ4TrmBarvoqFSPLWT4Lnq6Fn MYZh+3JAVufXTLrcP7f6KNTQfjoRC7qSqnYz6C85ppIz6xPMjlPJsYPOujNDbX7S AMOonz+Lb2NzpSlSMs+59xFVGeF2QUmsFngBurRHDKw867rFStN0n2O4n4+cvPs= =stj1 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/25/2014 02:12 PM, Nicolas Vigier wrote: > On Mon, 21 Apr 2014, Gunes Acar wrote: > >> -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. > Hello, > > I have been looking at your git repository with selenium tests: > https://github.com/gunesacar/tbb-fp-tests > > And this looks like a very good start! If you think that's ready, I can > merge your patch (fp_tests.patch) so we start running those tests on > the next releases / nightly builds. Hi Nicholas, I think it won't hurt to merge and I'd be just glad. > > After reading your proposal about this new Panopticlick project, > something I'm wondering is if it would be possible to split this tool > in two differents parts: > > - the part that generate a profile of the browser visiting the page(s) >using all known fingerprinting techniques, and save this profile in a >file (in json, yaml or any other format that is easy to read from an >other program) > > - the part that takes this profile and adds it to a central database, >and compute a uniqueness score to display it to the user > > The reason I'm thinking about this is that it could allow us to share > the first part between the panopticlick website and the test suite. Yes, indeed this is exactly how I imagine it. And that's why I was reluctant to submit the patchmentioned above, as it doesn't follow this architecture. But sure, it can be easily updated once I start working. > > I've been thinking about making the test suite start a local web server > that would be used to host some pages to be used by tests, and this > fingerprinting website could be one of thoses. That'd be great. Maybe we can start with client side tests but in the end we'd need to run server side (to check HTTP headers etc.) > > Does it sounds like something possible ? Sure, indeed. > > > Nicolas > > > ___ > 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/ iQEcBAEBAgAGBQJTWnIcAAoJEPb7JcMmVt4gFFoIAMc+DXIJgXrzdFv1aMFGh1AK NMi/CNqiTtk1L8C0LvMDwqtdXoU7Ip0iuysb9oO45j4MTkbMz3g7FUpuSGNxumnT OLDQDTDFYYi22YqE0U9SHmMJBv5F3EGI/WeVo4xVjiQeEPtsM4S7O988hfUBzCm7 MO06m+U+Kava8eb3XPU8xutEV8pZLXBmMvGTSMlBiAXpKtQjPTJDdcs33E/R2qlh Lz9aQZFaC+bTEPhsGZkLC+3/LqE9x3VtIecFV/TTTCYDnTq5BRSaNHCAwETTOpx0 tWjS0h3o22MJhWSvkXHAsw8NUocwLvp7zRfupYRdLjdsMVLyDMTWFPc/Q3ZS1tM= =E+pu -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 10:15 AM, Georg Koppen wrote: [...] > Okay, sounds reasonable. What is the fallback plan for the case the > code is not getting open-sourced during the time you are working on > the topic? Do you have an "internal" deadline like: "If I/we don't > have the code by XXX I'll start an implementation from scratch"? Peter kindly confirmed that I'll be able to access the code (even if it doesn't get published by then.) But, assuming the worst case, I'd start worrying on mid-July. > >> Also what is missing in the timeplan is my intention to >> implement ~everything except the backend a part of the QA >> process, and then reuse the code in the ultimate website (your >> suggestion). In addition to the new tests, I'll be working on the >> machine readable output, entropy calculation and submitting test >> machine fingerprints to a central database as a part of (2). >> >> Let me know if that makes sense or I can revise the timeplan >> (e.g. leave (3) to the end). > > Sounds good to me. > > Georg > > > > ___ 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/ iQEcBAEBAgAGBQJTWABKAAoJEPb7JcMmVt4gXIYIAJdKJoC3h6rj9mTMkejzuzns 9PO/cxZ3ZB3tvX6CIYrfglgdfnh2SmdlId+kXv0eNhfN3Rz9pAp2QpLBH5CUcQGp ETZIj3/WzlCZNqTcNZv7qge0uL3yiLynEgnqwY2P4TQRnpjC7heVgWD0f2y+IR5s 6H3/NDnK5dGXXl+T+xKqPswPrtgkgYXTl4pkG5YPL52vrGLPRsLYXizovryT3aJ5 LC7ozLjGLCuV1ToAu1/JVON1Qla66UBGGwuiD39+/A6sIJSptSRT6epkOJaWPy7D pClD2whSggnl4nLg2hOPzxpnX/tM08vyPRCSPx4xNezm0KO0BY0kUs3k3E21cYM= =x2jO -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2014 10:35 AM, Georg Koppen 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... > > I am happy with getting 1), 2) and 3) done in that order but am a > bit wondering why that does not match your suggestion in the > timeline. There you plan doing something like 2) (+ maybe the > "Implement fingerprinting tests" from 1)), 3) and 1). Is there a > reason for this? I am asking as porting the Panopticlick and > getting something live to use seems to be the most tricky part of > your proposal (I might be wrong here, though). Having this as the > last item to work on contains the nonnegligible risk that it won't > get finished which would we sad... > Sorry for putting it in a confusing way. The reason was that there is a strong chance that after August I'll be able to access the Panopticlick data (and probably the code), as an EFF volunteer/contractor. I thought it might be a better idea to work after that, assuming Peter may give some valuable advices on the process too. If code gets published before August, I can start to work earlier. Also what is missing in the timeplan is my intention to implement ~everything except the backend a part of the QA process, and then reuse the code in the ultimate website (your suggestion). In addition to the new tests, I'll be working on the machine readable output, entropy calculation and submitting test machine fingerprints to a central database as a part of (2). Let me know if that makes sense or I can revise the timeplan (e.g. leave (3) to the end). >> On 03/21/2014 11:39 PM, Peter Eckersley wrote: >>> I think we're fine with open sourcing under the Affero GPLv3. > > Wow. I almost missed that one in all the quoted emails and it did > not make it to tor-dev. But good to hear that we have something to > build upon. Thanks, Peter. > > Georg > > > > ___ 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/ iQEcBAEBAgAGBQJTVou+AAoJEPb7JcMmVt4ggu8H/j/ELTPqgWZkIVjOVxCw6SH6 TvsQvLD5IK1g2sQ1wC9GNK65rRXZCQBJeX1AS9dC8iyyCDsQ5yXy1lnBikSF4yHp nyMUqgs9k2xE/g5mWLex3fg7/2VGxN58F+gOi8SUTLNr028Mp61ayjxOj1GVB4pQ Awz4c1HWqx9PvgoAka8HvT2Wi7YKP7hFUF1UQBnFg+EmT67ploMdNeVPDGU2OJUO f00630cS6/4n8Z8X77rWNDknwMz30ZM2T9bGf0sSnn1zneRbdtUEZUBd8Yyns4UP f0dyeyyL1W7NXLNu4FdtyxIACFkUV1IoFDCJuu8OC1QPChPJby4LJZ1c5FvgEVY= =NiSt -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
-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
Re: [tor-dev] Panopticlick summer project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun 20 Apr 2014 01:18:36 AM CEST, Michael Wolf wrote: > On 4/19/2014 1:48 AM, Gunes Acar wrote: >> 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... > > I don't see it mentioned anywhere specifically so I'll ask: Since this > is targeting Tor users, shouldn't this be implemented as a hidden > service? You'd still have to deal with and filter tor2web users, of > course. Actually, I don't see any reason to hide the service. We'll be keeping the fingerprints along with the TBB versions, so having other visitors shouldn't hurt. Anything I miss? > As a bonus, a hidden service will make obvious which visitors > are using non-TBB browsers with Tor, and you can give big scary warnings > to these people. Hopefully, the site will have enough fingerprinting tests to tell TBB users from others :) But, big, scary warnings will be definitely needed! > > > -- Mike > ___ > 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/ iQEcBAEBAgAGBQJTVA2gAAoJEPb7JcMmVt4gKtcH/3AczgvGLNCTVEXuD6CbpKlw 7GPZuLcTnHvqgRYKa8BnjeA+Ui9hnozFa6sdhJuOqos9mD+JA9ugNNjyb647CyFO cGsCbsFaDZ4TTwenXzKWIlfEp4cY0IULvqbxNor5r9eOilKavuQ57fnQZh98yMLP MJ4wF/p1USrk6VMunXoHCotsr+SEtfRyAyoObp4vi9kvQKNQV8+nKGHvOrAjQn9M W0V4SKb+SPZ6h6IRcnPfvQcglZCdcmxne7E8ULl2UV8BCbUTod58MhWA1BoPpZRG qRqJoJQ9X9BS7H7QJ8WFjC6jF03vHz+n2grb+YiVvRHCR9A7j8fRFzHo84VKGy0= =39v/ -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
-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... 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for all the feedback Mike, I'll be in touch with you and Georg on the Tor side. For the other discussion: I don't think open-sourcing Panopticlick is critical for this work. Rather, it's Panopticlick data that may inform the information-theoretic evaluation of TBB's countermeasures (e.g. to get a sense of font distribution to evaluate font limits: Can I pick/probe 10 fonts to identify all Tor users?) Actually we've been planning to publish the aggregated Panopticlick data with Peter and this may be the perfect time to do it. Frankly, I don't think EFF was reluctant to collaborate with you, rather I guess they simply had no time. That's why I'm very glad to hear from Yan who seem to be able to dedicate more time. I hope that'd work for everybody - me dedicating some of my time (1-2 weeks) to work on the analysis of Panopticlick data. Best, Gunes On Wed 19 Mar 2014 04:14:05 AM CET, Mike Perry wrote: > Gunes Acar: >> 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: >> >> 1) 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?) >> >> 2) Add machine-readability support outlined in Tor Automation >> proposals: >> https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#helper-fingerprint >> >> a) which one(s) should we implement? JSON, YAML, XML? >> >> 3) 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 good. We already have a fix for #1 though, but > verification can't hurt (the canvas should come back as all white > unless the user allows it). > > We also have a couple fixes for CSS-based fingerprinting (fonts > and system colors) that are entropy-reduction efforts only. > Actually measuring the amount of entropy reduction here would be > useful. > >> 4) 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) > > Great. > >> 5) Backport new "attacks" found in 3 & 4 to EFF's Panopticlick in >> case they consider an update. > > Unfortunately, the EFF has been reluctant to work with us in any > way to improve or re-deploy Panopticlick for our needs, hence the > frustrated tone of my other mail in this thread. It also seems that > the EFF would not permit your resulting work to be open source, > which I believe is a violation of the GSoC rules. I guess since you > are not intending to actually apply to GSoC, this is a moot point > though. It's just also a sore one for me, so I figured I'd poke it > once more ;). > > However, as I also said in my other mail, I actually think we may > be better served by developing something independent of > Panopticlick. We need per-TBB version breakdowns of all the > statistics we record, so we can measure the change in entropy as we > deploy fixes and improvements to our defenses, without previous > datapoints biasing the distribution. > > Other than some helper functions to store data and calculate > entropy, and one (or maybe two) simple fingerprinting tests, we > should not need any of the Panopticlick code for this project. It's > also likely that our DB schema will end up radically different, due > to the need to segment data by browser version (which may be input > by the user), and the need for many more (and more varied) tests > than they have. > >> 6) Convert fixed FP-related bugs into regression tests. >> https://tra
Re: [tor-dev] Panopticlick summer project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Georg, I plan to dedicate the 3 months, full time, from early June to early September. But I'm flexible with the dates. I admit that doing all these might be unrealistic, maybe we can assign priorities to different tasks. Best, Gunes On Mon 17 Mar 2014 03:44:50 PM CET, Georg Koppen wrote: > Hi, > > Gunes Acar: >> 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: > > thanks for your interest! That is a lot of stuff to do for one summer. > :) I am happy to help you with whatever you choose to work on but, > personally, I'd like to see the Panopticlick project get into shape as > outlined in the link you referred to. As you are not applying for the > GSoC what time frame do you have in mind for working on these things? > > Georg > > > > ___ > 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/ iQEcBAEBAgAGBQJTJxJCAAoJEPb7JcMmVt4g6X4H/i2/kziOV5Mu99RSSv2IJNFV 3B8ATINqUu7EGV73E1Y6hMV2lFGrD/8d4+0bYatRMtDU77ijW1bl9UimI4RAkB9U Nb6lLh7c0WiJY0Xgc3hN794fH/CQbyCSftIZrjgaRZyzTgf8avkkKo3UNCpWkxa2 n6v92QlyDuR72tqGYLllw2d92+GbUGQDiDfVwYSfcVYYk3T8Swru7H/Ehj8vUGQ8 TsKsebMa5+btueThymJX1K3NZ3be1Aj8nElfdYGUqc6evHRzkp3OlDAOAnMHJA21 8LlFLrswagOYQszoVJTMYj6pu0eHAXDM03G1gGGxzPDs02p1tCbamrxaFfMWggk= =4Wyp -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
-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. >> >>> >>> 1) 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. >> >>> >>> 2) Add machine-readability support outlined in Tor Automation >>> proposals: >>> https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#helper-fingerprint >>> >>> a) which one(s) should we implement? JSON, YAML, XML? >> >> No input here. >> >>> >>> 3) 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/). >> >>> 4) 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. >> >>> 5) 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. >> >>> 6) Convert fixed FP-related bugs into regression tests. >>> https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting&status=closed >>> >>> >>> 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 >>> >>> 8) Work on potential fingerprinting bugs that ESR31 may bring. >>> >>> 9) 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.html#helper-fingerprint >>> >>> >>> 10) Evaluate the font-
[tor-dev] Panopticlick summer project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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: 1) 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?) 2) Add machine-readability support outlined in Tor Automation proposals: https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#helper-fingerprint a) which one(s) should we implement? JSON, YAML, XML? 3) 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.) ... 4) 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) 5) Backport new "attacks" found in 3 & 4 to EFF's Panopticlick in case they consider an update. 6) Convert fixed FP-related bugs into regression tests. https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting&status=closed 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 8) Work on potential fingerprinting bugs that ESR31 may bring. 9) 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.html#helper-fingerprint 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. More on my background relevant to fingerprinting and TBB code base: We recently published a paper called "FPDetective: Dusting the Web for Fingerprinters" (CCS'13) to measure the prevalence of browser fingerprinting on the Internet. As a part of this study, we built instrumented browsers from Chromium and PhantomJS source code and developed a framework to detect fingerprinting (https://github.com/fpdetective/). I also got my hands dirty with the TBB source code to seek vulnerabilities in FP countermeasures. Two ways I found to circumvent existing font limits were as follows: https://trac.torproject.org/projects/tor/ticket/8270#comment:2 https://trac.torproject.org/projects/tor/ticket/5798#comment:13 Other pointers: My website: http://www.esat.kuleuven.be/cosic/?page_id=126 FPDetective website: https://www.cosic.esat.kuleuven.be/fpdetective/ My (first & only) Tor patch: https://trac.torproject.org/projects/tor/ticket/10472 My Tor FAQ profile: http://tor.stackexchange.com/users/731/gacar Looking for your comments, Cheers, Gunes N.B.: I won't be applying to GSoC. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTJmUiAAoJEPb7JcMmVt4g4jAH/2JLUKPGo52JpfsHeMtLZgQm JVoEELKuNVjwJ5KqgO4OhIqpS6yl/cggLsUe19fNrC5I++5w5lGWM3JRqCU/T5OV PLwRrs1lc1wU2zWkcKN/uvZyFys1xAsA2NzyYRZdKOjoGiDI8a3wgYM/o8a5PSt0 +wTJ6OdtRpFuXk9CrxUScx6kbLEYCoQeGcAmQe+ZIUWo6CzeQr/3yP8Jz7B3Uyqq ccSJACFuif2naQFiCDqyuQLIZu/9jMFGbYMg81OhZeeOWhmq4FwCjZOR8bzj8zqV i3N8hFXTRSYLjOg5AWVX+JMsCWJAX3rTrYe6X5GKA/tIm1gMJhwtedfaE38eHOM= =2stA -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
