subject:"\[tor\-dev\] Panopticlick summer project"

Re: [tor-dev] Panopticlick summer project

2014-05-06 Thread Gunes Acar

-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

2014-05-05 Thread Nicolas Vigier

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 ?
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



pgpxtiql6JZwC.pgp
Description: 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

2014-04-25 Thread Nicolas Vigier

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.

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



pgp1Y3HBdYJmN.pgp
Description: 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

2014-04-25 Thread Nicolas Vigier


(sending this again as I accidentally removed Peter from CC)

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.

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



pgpAYC4_jk46a.pgp
Description: 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

2014-04-25 Thread Gunes Acar


-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

2014-04-23 Thread Georg Koppen

Gunes Acar:
 On 04/22/2014 10:35 AM, Georg Koppen wrote:
 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.

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?

 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



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] Panopticlick summer project

2014-04-22 Thread Georg Koppen

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...

 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



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] Panopticlick summer project

2014-04-22 Thread Gunes Acar

-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

2014-04-21 Thread Mike Perry

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@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-dev

Re: [tor-dev] Panopticlick summer project

2014-04-21 Thread Gunes Acar

-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
 
 
 
 
 ___

Re: [tor-dev] Panopticlick summer project

2014-04-20 Thread Gunes Acar

-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

2014-04-19 Thread 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...

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

2014-04-19 Thread Michael Wolf

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.  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
___
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

2014-03-21 Thread Georg Koppen

Gunes Acar:
 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.

Sure, we can always write new code. That said, if you want to do that (I
am still not sure about it) it might be a good idea to write up a
proposal containing the requirements Mike mentioned in his email and how
you'd like to implement them. Additionally, it might be a good idea if
code could somehow be shared with tests needed for QA. Maybe the feature
extraction part could be modularized in a way that both can share, say,
the feature extraction part. Dunno if that works or is smart, though...

 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.

Oh, you have missed Yan Zhu's last email. I'll quote the relevant parts
for your convenience:

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.

Georg





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] Panopticlick summer project

2014-03-21 Thread Georg Koppen

Georg Koppen:
 code could somehow be shared with tests needed for QA. Maybe the feature
 extraction part could be modularized in a way that both can share, say,
 the feature extraction part.

That should have been

Maybe the tests could be modularized in a way that both can share, say,
the feature extraction part. *sigh*

Georg



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] Panopticlick summer project

2014-03-20 Thread Gunes Acar

-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://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprintingstatus=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.

Re: [tor-dev] Panopticlick summer project

2014-03-18 Thread Mike Perry

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


signature.asc
Description: Digital 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

2014-03-18 Thread Mike Perry

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://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprintingstatus=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

I am not sure this is helpful. In general, we only want to measure
fingerprintability *within* a specific browser version.

To determine the appearance of new APIs, it's probably best and simplest
to simply review Mozilla's Developer Documentation, ie:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/24

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.

Excellent.

More on my background relevant to fingerprinting and TBB code base:

Re: [tor-dev] Panopticlick summer project

2014-03-17 Thread Yan Zhu

(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.

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.

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-fingerprintingstatus=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.

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.

All of the above sounds fine.

Assuming that we can get Panopticlick open-sourced, I'm more than happy
to help you with any of these subprojects.

-Yan
(EFF Staff Technologist / HTTPS Everywhere maintainer)

___
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

2014-03-17 Thread Gunes Acar

-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.

This sounds greatly useful. Another good place to look is
Mozilla's bug tracker (https://bugzilla.mozilla.org/).

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-fingerprintingstatus=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.

All of the above sounds fine.

Assuming that we can get Panopticlick open-sourced, I'm more than
happy to help you with any of these subprojects.

-Yan (EFF Staff Technologist / HTTPS Everywhere maintainer)

___ 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/

iQEcBAEBAgAGBQJTJt9OAAoJEPb7JcMmVt4gYagH/1UXZvWk373q5itGGECA+9T/
NXh2lIQbTZE9GKpPELhkxNHxScQ74e5Wgu3OBnOT4v5qHChhu5IhyISLnQ1nIMoA
9q1WjlVKWOGGB7eem7FCyuat8If0ZukINcG2P6f5VoWPpkkOXqtM5LiDZkVWwDmQ
OFN4tYMgwJR4EgGDF7B79uQaYVNidpBtebsU8hK6ulTYKlyPRdtaCkNBqgTTRMqZ
FhyCl9KUmT7Z9zQKOnHLPZL7PKVyP18Mu0rzKp0rSC9yKahR7UZW+ax8hLAkvF5E
+chN7CPzujCQwd+WfzC9pJEHMeJhknjmGCjA6xgbfeRen6a1mu7siiUAEM9htGg=
=EVkv
-END PGP

Re: [tor-dev] Panopticlick summer project

2014-03-17 Thread Georg Koppen

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



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] Panopticlick summer project

2014-03-17 Thread Gunes Acar

-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

[tor-dev] Panopticlick summer project

2014-03-16 Thread Gunes Acar

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear All,