-----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:
On 4/19/2014 1:48 AM, Gunes Acar wrote:
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. 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.
-- Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun 20 Apr 2014 01:18:36 AM CEST, Michael Wolf wrote:
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?
Hopefully, the site will have enough fingerprinting tests to tell TBB users from others :) But, big, scary warnings will be definitely needed!
Gunes Acar:
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...
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. :/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon 21 Apr 2014 02:21:35 PM CEST, Mike Perry wrote:
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.
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.
Peter says he has some reluctance to open source the project
On Mon, 21 Apr 2014, Gunes Acar wrote:
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.
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. 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.
Does it sounds like something possible ?
Nicolas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/25/2014 02:12 PM, Nicolas Vigier wrote:
https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#QAandTe...
Hi Nicholas, I think it won't hurt to merge and I'd be just glad.
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.
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.
On Fri, 25 Apr 2014, Gunes Acar wrote:
Great!
Before merging your patch, a question about the license of your test scripts: is there a specific license you want to use ? 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon 05 May 2014 04:08:58 PM CEST, Nicolas Vigier wrote:
No, I'm fine with CC0 at the moment. Thanks
(sending this again as I accidentally removed Peter from CC)
On Mon, 21 Apr 2014, Gunes Acar wrote:
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.
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. 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.
Does it sounds like something possible ?
Nicolas
Gunes Acar:
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...
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/22/2014 10:35 AM, Georg Koppen wrote:
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).
Gunes Acar:
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"?
Sounds good to me.
Georg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/23/2014 10:15 AM, Georg Koppen wrote: [...]
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.
-
Georg Koppen -
Gunes Acar -
Michael Wolf -
Mike Perry -
Nicolas Vigier