Re: [tor-dev] Proposal 299: Preferring IPv4 or IPv6 based on IP Version Failure Count

2019-02-05 Thread teor
Hi Neel, Thanks for your initial draft code, and this proposal. On February 6, 2019 12:26:40 AM UTC, Neel Chauhan wrote: >Hi tor-dev@ mailing list, > >First off, thank you to Nick for making this an official proposal and >thank you again for marking it as open. I really appreciate this. Also,

Re: [tor-dev] The Tor project as a GSoC voucher for Whonix?

2019-02-05 Thread iry
Damian Johnson: > Thanks teor! Quite side note: it would be helpful if such questions > are broached earlier in the process. Google has been calling for org > applications for several weeks now. Asking roughly a day before the > deadline creates last minute confusion and reduces the chances of an

[tor-dev] Proposal 299: Preferring IPv4 or IPv6 based on IP Version Failure Count

2019-02-05 Thread Neel Chauhan
Hi tor-dev@ mailing list, First off, thank you to Nick for making this an official proposal and thank you again for marking it as open. I really appreciate this. Also, thank you teor for aiding me on my first proposal. My proposal is available on torspec here:

Re: [tor-dev] The Tor project as a GSoC voucher for Whonix?

2019-02-05 Thread Damian Johnson
Thanks teor! Quite side note: it would be helpful if such questions are broached earlier in the process. Google has been calling for org applications for several weeks now. Asking roughly a day before the deadline creates last minute confusion and reduces the chances of an affirmative response.

Re: [tor-dev] Proposal 300: Walking Onions: Scaling and Saving Bandwidth

2019-02-05 Thread teor
Hi Nick, Thanks for posting this initial draft. I enjoyed reading more of the details, after hearing about it last week. On February 5, 2019 5:02:50 PM UTC, Nick Mathewson wrote: >Filename: 300-walking-onions.txt >Title: Walking Onions: Scaling and Saving Bandwidth >Author: Nick Mathewson

Re: [tor-dev] Proposal 300: Walking Onions: Scaling and Saving Bandwidth

2019-02-05 Thread Michael Rogers
Argh, I'm really sorry, I thought I'd reached the end of the proposal but my questions were addressed further down. Sorry for the noise. Cheers, Michael On 05/02/2019 17:42, Michael Rogers wrote: > I'm very happy to see this proposal! Two quick questions about relay > selection: > > * Can a

Re: [tor-dev] Proposal 300: Walking Onions: Scaling and Saving Bandwidth

2019-02-05 Thread Michael Rogers
I'm very happy to see this proposal! Two quick questions about relay selection: * Can a client specify that it wants an exit node whose policy allows something unusual, e.g. exiting to a port that's not allowed by the default policy? If not, does the client need to keep picking exit nodes until

[tor-dev] Proposal 300: Walking Onions: Scaling and Saving Bandwidth

2019-02-05 Thread Nick Mathewson
Filename: 300-walking-onions.txt Title: Walking Onions: Scaling and Saving Bandwidth Author: Nick Mathewson Created: 5-Feb-2019 Status: Draft 0. Status This proposal describes a mechanism called "Walking Onions" for scaling the Tor network and reducing the amount of client bandwidth

Re: [tor-dev] The Tor project as a GSoC voucher for Whonix?

2019-02-05 Thread teor
Dear Whonix Community, On February 5, 2019 2:20:18 PM UTC, iry wrote: > > >teor: >> Dear Whonix Community, >> >> On February 4, 2019 11:52:44 PM UTC, iry wrote: >> Dear Tor Developers, >> >> Whonix is applying to be a Google Summer of Code organization this >> year. I am writing on behalf

Re: [tor-dev] tor relay process health data for operators (controlport)

2019-02-05 Thread Iain Learmonth
Hi All, On 04/02/2019 06:35, teor wrote: > If we add enough noise to protect most users, then we will have privacy by > design. I would argue that noise does not help here, as we would have to add enough noise to protect against a guard discovery attack, which is too much noise for the stats to

[tor-dev] Release: obfs4proxy-0.0.9

2019-02-05 Thread Yawning Angel
Hello all, I just tagged obfs4proxy-0.0.9. The main features of this release are primarily related to improving the behavior of the `meek_lite` transport. Since some of the changes are major, I will expand on them separately from the brief summary given in the ChangeLog. * A forked version[0]