-----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
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
-----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
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#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. :/
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
-----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#QAandTe...
Sure,
I already have some questions noted down for him. But I must say the framework he set up is pretty easy to extend. I could add and run my tests in minutes.
With respect to the rest of it, my main immediate question is how we should separate the results by Tor Browser version. Tor Browser currently reports its user agent string as the Windows build of the Firefox ESR release it is based off of, with no minor version.
This likely means we want users who are comfortable submitting their results to the dataset to select their specific TBB version (which is visible in the upper-right corner of about:tor). However, if they get this wrong, it may bias results. :/
I'd prefer minimizing the user intervention. Maybe we can modify Torbutton to place a link to test suite on about:tor page that includes TBB version in the URL (or as a hidden form field). We may have the same link somewhere in the Torbutton drop down menu.
And if we want to link to the test suite from a web site, we may redirect users through about:tor?run=fptest to collect and pass the TBB version automatically. Or have a about:fingerprint page that does the same.
Still we may need some sanity checks to protect data from potential polluters (crafting URLs with the fake TBB version), if that's ever possible.
On 03/21/2014 11:39 PM, Peter Eckersley wrote:
I think we're fine with open sourcing under the Affero GPLv3.
On Tue, Mar 18, 2014 at 12:28:12PM -0700, Mike Perry wrote:
Yan Zhu:
On 03/17/2014 04:41 AM, Gunes Acar wrote: > Hi Yan, > > Glad that you're interested in the project. It'd be > very nice collaborate with you on this. > > Indeed, we've been corresponding with Peter for a > related project and I mentioned my intention to work as > a middleman between EFF and Tor. >
Great, it seems that Peter and I are both interested and willing to help.
Regarding https://trac.torproject.org/projects/tor/ticket/6119#comment:10,
Peter says he has some reluctance to open source the project
(not the data) because it might make it easier for some websites to track visitors without their consent.
This might have been a valid concern 5 years ago, but now it's just a joke. The tests on Panopticlick are ancient, widely known, easy to reproduce, and since then much more severe and invasive mechanisms of fingerprinting have since been developed/deployed in modern browsers.
Moreover, only 2 of the tests it performs actually apply to Tor Browser users.
Banks in particular have already deployed some of the techniques we've fixed that the EFF study entirely predates. And these techniques are far higher entropy than browser resolution (such as localhost open port enumeration, OS theme fingerprinting, and HTML5+WebGL canvas rendering+extraction+hashing).
Not only should we (as Tor) publicly provide tests and easy-to-deploy working PoC code for all of these vectors, we should also endeavor to detail cases where major browser vendors are ignoring or exacerbating this problem, and make it easy for everyone to test and observe this behavior themselves.
Not sure if that means the EFF now has a conflict of interest with this project for some ridiculous reason, but frankly any attempt at trying to "hide" these techniques is downright silly. They are too well known (most are publicly documented elsewhere, or at least on our bugtracker), and there's waaay too much money on the other side of the fence in terms of incentives to develop and deploy working attacks.
Further, starting the from EFF codebase might also be a hindrance to us. It is not designed for measuring the effects of defenses. In fact, its measurement mechanisms actively penalize any attempt at defense development (because any approach to alter browser behavior instantly makes you more unique than the previous userbase).
I actually think Panopticlick has of late done more to prevent browser fingerprinting defense development than to encourage it. I would really like to see it DIAF.
Here's hoping we can make something better!
-- Mike Perry
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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#QAandTe...
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
-----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#QAandTe...
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
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
-----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
(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#QAandTe...
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
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
-----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
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
-----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
-
Georg Koppen -
Gunes Acar -
Michael Wolf -
Mike Perry -
Nicolas Vigier