Re: [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

[Nathaniel Suchy]

What if a Tor Bridge blocked connections to the tor network to selective
client IPs? Would we keep it in BridgeDB because its sometimes useful?

On Thu, Aug 30, 2018 at 10:02 PM arisbe  wrote:

> Children should be seen and not herd.  The opposite goes for Tor relays.
> Arisbe
>
>
> On 8/30/2018 2:11 PM, Nathaniel Suchy wrote:
>
> So this exit node is censored by Turkey. That means any site blocked in
> Turkey is blocked on the exit. What about an exit node in China or Syria or
> Iraq? They censor, should exits there be allowed? I don't think they
> should. Make them relay only, (and yes that means no Guard or HSDir flags
> too) situation A could happen. The odds might not be in your favor. Don't
> risk that!
>
> Cordially,
> Nathaniel Suchy
>
> On Thu, Aug 30, 2018 at 3:25 PM grarpamp  wrote:
>
>> This particular case receiving mentions for at least a few months...
>> D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114
>>
>> The relay won't [likely] be badexited because neither it nor its upstream
>> is
>> shown to be doing anything malicious. Simple censorship isn't enough.
>> And except for such limited censorship, the nodes are otherwise fully
>> useful, and provide a valuable presence inside such regions / networks.
>>
>> Users, in such censoring regimes, that have sucessfully connected
>> to tor, already have free choice of whatever exits they wish, therefore
>> such censorship is moot for them.
>>
>> For everyone else, and them, workarounds exist such as,,,
>> https://onion.torproject.org/
>> http://yz7lpwfhhzcdyc5y.onion/
>> search engines, sigs, vpns, mirrors, etc
>>
>> Further, whatever gets added to static exitpolicy's might move out
>> from underneath them or the censor, the censor may quit, or the exit
>> may fail to maintain the exitpolicy's. None of which are true
>> representation
>> of the net, and are effectively censorship as result of operator action
>> even though unintentional / delayed.
>>
>> Currently many regimes do limited censorship like this,
>> so you'd lose all those exits too for no good reason, see...
>> https://ooni.torproject.org/
>>
>> https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country
>>
>> And arbitrarily hamper spirits, tactics, and success of volunteer
>> resistance communities and operators in, and fighting, such regimes
>> around the world.
>>
>> And if the net goes chaotic, majority of exits will have limited
>> visibility,
>> for which exitpolicy / badexit are hardly manageable solutions either,
>> and would end up footshooting out many partly useful yet needed
>> exits as well.
>>
>>
>> If this situation bothers users, they can use... SIGNAL NEWNYM,
>> New Identity, or ExcludeExitNodes.
>>
>> They can also create, maintain and publish lists of whatever such
>> classes of nodes they wish to determine, including various levels
>> of trust, contactability, verification, ouija, etc... such that others
>> can subscribe to them and Exclude at will.
>> They can further publish patches to make tor automatically
>> read such lists, including some modes that might narrowly exclude
>> and route stream requests around just those lists of censored
>> destination:exit pairings.
>>
>> Ref also...
>> https://metrics.torproject.org/rs.html#search/as:AS197328%20flag:exit
>> https://metrics.torproject.org/rs.html#search/country:tr%20flag:exit
>>
>>
>> In the subect situations, you'd want to show that it is in fact
>> the exit itself, not its upstream, that is doing the censorship.
>>
>> Or that if fault can't be determined to the upstream or exit, what
>> would be the plausible malicious benefit for an exit / upstream
>> to block a given destination such that a badexit is warranted...
>>
>> a) Frustrate and divert off 0.001% of Turk users smart enough to
>> use tor, chancing through tor client random exit selection of your
>> blocking exit, off to one of the workarounds that you're equally
>> unlikely to control and have ranked, through your exit vs one
>> of the others tor has open?
>>
>> b) Prop up weird or otherwise secretly bad nodes on the net,
>> like the hundreds of other ones out there, for which no badexit
>> or diverse subscription services yet exist to qualify them?
>>
>> c) ???
>>
>> Or that some large number of topsites were censored via
>> singular or small numbers of exits / upstreams so as to be
>> exceedingly annoying to the network users as a whole, where
>> no other environment of such / chaotic widespread annoyance
>> is known to exist at the same time.
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>
>
> ___
> tor-relays mailing 
> listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
> --
> One person's moral compass is another person's face in the dirt.
>
> 

Re: [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

[arisbe]

  
  
Children should be seen and not herd.  The opposite goes for Tor
relays.
Arisbe

On 8/30/2018 2:11 PM, Nathaniel Suchy
  wrote:


  
  So this exit node is censored by Turkey. That means
any site blocked in Turkey is blocked on the exit. What about an
exit node in China or Syria or Iraq? They censor, should exits
there be allowed? I don't think they should. Make them relay
only, (and yes that means no Guard or HSDir flags too) situation
A could happen. The odds might not be in your favor. Don't risk
that!


Cordially,
Nathaniel Suchy
  
  
  
On Thu, Aug 30, 2018 at 3:25 PM grarpamp 
  wrote:

This
  particular case receiving mentions for at least a few
  months...
  D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov
  185.125.33.114
  
  The relay won't [likely] be badexited because neither it nor
  its upstream is
  shown to be doing anything malicious. Simple censorship isn't
  enough.
  And except for such limited censorship, the nodes are
  otherwise fully
  useful, and provide a valuable presence inside such regions /
  networks.
  
  Users, in such censoring regimes, that have sucessfully
  connected
  to tor, already have free choice of whatever exits they wish,
  therefore
  such censorship is moot for them.
  
  For everyone else, and them, workarounds exist such as,,,
  https://onion.torproject.org/
  http://yz7lpwfhhzcdyc5y.onion/
  search engines, sigs, vpns, mirrors, etc
  
  Further, whatever gets added to static exitpolicy's might move
  out
  from underneath them or the censor, the censor may quit, or
  the exit
  may fail to maintain the exitpolicy's. None of which are true
  representation
  of the net, and are effectively censorship as result of
  operator action
  even though unintentional / delayed.
  
  Currently many regimes do limited censorship like this,
  so you'd lose all those exits too for no good reason, see...
  https://ooni.torproject.org/
  https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country
  
  And arbitrarily hamper spirits, tactics, and success of
  volunteer
  resistance communities and operators in, and fighting, such
  regimes
  around the world.
  
  And if the net goes chaotic, majority of exits will have
  limited visibility,
  for which exitpolicy / badexit are hardly manageable solutions
  either,
  and would end up footshooting out many partly useful yet
  needed
  exits as well.
  
  
  If this situation bothers users, they can use... SIGNAL
  NEWNYM,
  New Identity, or ExcludeExitNodes.
  
  They can also create, maintain and publish lists of whatever
  such
  classes of nodes they wish to determine, including various
  levels
  of trust, contactability, verification, ouija, etc... such
  that others
  can subscribe to them and Exclude at will.
  They can further publish patches to make tor automatically
  read such lists, including some modes that might narrowly
  exclude
  and route stream requests around just those lists of censored
  destination:exit pairings.
  
  Ref also...
  https://metrics.torproject.org/rs.html#search/as:AS197328%20flag:exit
  https://metrics.torproject.org/rs.html#search/country:tr%20flag:exit
  
  
  In the subect situations, you'd want to show that it is in
  fact
  the exit itself, not its upstream, that is doing the
  censorship.
  
  Or that if fault can't be determined to the upstream or exit,
  what
  would be the plausible malicious benefit for an exit /
  upstream
  to block a given destination such that a badexit is
  warranted...
  
  a) Frustrate and divert off 0.001% of Turk users smart enough
  to
  use tor, chancing through tor client random exit selection of
  your
  blocking exit, off to one of the workarounds that you're
  equally
  unlikely to control and have ranked, through your exit vs one
  of the others tor has open?
  
  b) Prop up weird or otherwise secretly bad nodes on the net,
  like the hundreds of other ones out there, for which no
  badexit
  or diverse subscription services yet 

Re: [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

[Pascal Terjan]

How is situation 1 different from 2 from the user perspective? In both
cases the user doesn't have access because of the country where the exit is
running.

A lot of countries have various levels of blocky (for example torrent
websites in UK). Is the solution to only run all exits in a few "good"
countries with no filtering but maybe some strong surveillance/analysis?

On Thu, 30 Aug 2018, 16:22 Nathaniel Suchy,  wrote:

> The exit is behind a filtered ISP. Opposed to a website blocking exits.
> That’s the difference.
>
> 1) The content provider causes the block.
> 2) The exit causes the block.
>
> In situation two a censored user may give up on Tor entirely. Should we
> allow exits in China or Iraq or Syria or Turkey or the several other
> countries. What if their governments who can afford it spin up 10,000 exits
> in an effort to censor the Tor Network. Will we sit idly by and allow it?
>
> On Thu, Aug 30, 2018 at 7:17 PM Pascal Terjan  wrote:
>
>> A country's ISPs blocking some websites is not the exit blocking it and
>> the result is the same than websites blocking the country, users of that
>> exit can't access the websites just because the exit is in that country but
>> doesn't do any filtering itself.
>>
>> On Thu, 30 Aug 2018, 16:14 Nathaniel Suchy,  wrote:
>>
>>> That’s a website blocking Tor users. Not a Tor Exit blocking a website.
>>> On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan  wrote:
>>>


 On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy,  wrote:

> So this exit node is censored by Turkey. That means any site blocked
> in Turkey is blocked on the exit. What about an exit node in China or 
> Syria
> or Iraq? They censor, should exits there be allowed? I don't think they
> should. Make them relay only, (and yes that means no Guard or HSDir flags
> too) situation A could happen. The odds might not be in your favor. Don't
> risk that!
>

 Where do you put the limit?

 Various categories of websites are blocked in various countries either
 by ISPs or by content providers.

 For example should exits not be allowed to run in Germany due to
 https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany
 ? Or not allow exits in EU due to the number of US websites deciding to
 block all of EU IPs to not have to comply to GDPR?

 ___
 tor-relays mailing list
 tor-relays@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

>>> ___
>>> tor-relays mailing list
>>> tor-relays@lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

[Nathaniel Suchy]

Matthew: Built in functionality, maybe, an addon, no. Also either solution
is a bandaid to the actual problem that we're allowing an exit with no
contact information to censor Tor users with impunity!

On Thu, Aug 30, 2018 at 8:01 PM Matthew Glennon 
wrote:

> Could this be mitigated with a detection addon in Tor Browser? Detect that
> the site may be blocked at the exit and offer to fetch a new circuit for
> the site?
>
>
> On Thu, Aug 30, 2018, 19:22 Nathaniel Suchy  wrote:
>
>> The exit is behind a filtered ISP. Opposed to a website blocking exits.
>> That’s the difference.
>>
>> 1) The content provider causes the block.
>> 2) The exit causes the block.
>>
>> In situation two a censored user may give up on Tor entirely. Should we
>> allow exits in China or Iraq or Syria or Turkey or the several other
>> countries. What if their governments who can afford it spin up 10,000 exits
>> in an effort to censor the Tor Network. Will we sit idly by and allow it?
>>
>> On Thu, Aug 30, 2018 at 7:17 PM Pascal Terjan  wrote:
>>
>>> A country's ISPs blocking some websites is not the exit blocking it and
>>> the result is the same than websites blocking the country, users of that
>>> exit can't access the websites just because the exit is in that country but
>>> doesn't do any filtering itself.
>>>
>>> On Thu, 30 Aug 2018, 16:14 Nathaniel Suchy,  wrote:
>>>
 That’s a website blocking Tor users. Not a Tor Exit blocking a website.
 On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan 
 wrote:

>
>
> On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy,  wrote:
>
>> So this exit node is censored by Turkey. That means any site blocked
>> in Turkey is blocked on the exit. What about an exit node in China or 
>> Syria
>> or Iraq? They censor, should exits there be allowed? I don't think they
>> should. Make them relay only, (and yes that means no Guard or HSDir flags
>> too) situation A could happen. The odds might not be in your favor. Don't
>> risk that!
>>
>
> Where do you put the limit?
>
> Various categories of websites are blocked in various countries either
> by ISPs or by content providers.
>
> For example should exits not be allowed to run in Germany due to
> https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany
> ? Or not allow exits in EU due to the number of US websites deciding to
> block all of EU IPs to not have to comply to GDPR?
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
 ___
 tor-relays mailing list
 tor-relays@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

>>> ___
>>> tor-relays mailing list
>>> tor-relays@lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

[Matthew Glennon]

Could this be mitigated with a detection addon in Tor Browser? Detect that
the site may be blocked at the exit and offer to fetch a new circuit for
the site?


On Thu, Aug 30, 2018, 19:22 Nathaniel Suchy  wrote:

> The exit is behind a filtered ISP. Opposed to a website blocking exits.
> That’s the difference.
>
> 1) The content provider causes the block.
> 2) The exit causes the block.
>
> In situation two a censored user may give up on Tor entirely. Should we
> allow exits in China or Iraq or Syria or Turkey or the several other
> countries. What if their governments who can afford it spin up 10,000 exits
> in an effort to censor the Tor Network. Will we sit idly by and allow it?
>
> On Thu, Aug 30, 2018 at 7:17 PM Pascal Terjan  wrote:
>
>> A country's ISPs blocking some websites is not the exit blocking it and
>> the result is the same than websites blocking the country, users of that
>> exit can't access the websites just because the exit is in that country but
>> doesn't do any filtering itself.
>>
>> On Thu, 30 Aug 2018, 16:14 Nathaniel Suchy,  wrote:
>>
>>> That’s a website blocking Tor users. Not a Tor Exit blocking a website.
>>> On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan  wrote:
>>>


 On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy,  wrote:

> So this exit node is censored by Turkey. That means any site blocked
> in Turkey is blocked on the exit. What about an exit node in China or 
> Syria
> or Iraq? They censor, should exits there be allowed? I don't think they
> should. Make them relay only, (and yes that means no Guard or HSDir flags
> too) situation A could happen. The odds might not be in your favor. Don't
> risk that!
>

 Where do you put the limit?

 Various categories of websites are blocked in various countries either
 by ISPs or by content providers.

 For example should exits not be allowed to run in Germany due to
 https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany
 ? Or not allow exits in EU due to the number of US websites deciding to
 block all of EU IPs to not have to comply to GDPR?

 ___
 tor-relays mailing list
 tor-relays@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

>>> ___
>>> tor-relays mailing list
>>> tor-relays@lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

[Nathaniel Suchy]

The exit is behind a filtered ISP. Opposed to a website blocking exits.
That’s the difference.

1) The content provider causes the block.
2) The exit causes the block.

In situation two a censored user may give up on Tor entirely. Should we
allow exits in China or Iraq or Syria or Turkey or the several other
countries. What if their governments who can afford it spin up 10,000 exits
in an effort to censor the Tor Network. Will we sit idly by and allow it?

On Thu, Aug 30, 2018 at 7:17 PM Pascal Terjan  wrote:

> A country's ISPs blocking some websites is not the exit blocking it and
> the result is the same than websites blocking the country, users of that
> exit can't access the websites just because the exit is in that country but
> doesn't do any filtering itself.
>
> On Thu, 30 Aug 2018, 16:14 Nathaniel Suchy,  wrote:
>
>> That’s a website blocking Tor users. Not a Tor Exit blocking a website.
>> On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan  wrote:
>>
>>>
>>>
>>> On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy,  wrote:
>>>
 So this exit node is censored by Turkey. That means any site blocked in
 Turkey is blocked on the exit. What about an exit node in China or Syria or
 Iraq? They censor, should exits there be allowed? I don't think they
 should. Make them relay only, (and yes that means no Guard or HSDir flags
 too) situation A could happen. The odds might not be in your favor. Don't
 risk that!

>>>
>>> Where do you put the limit?
>>>
>>> Various categories of websites are blocked in various countries either
>>> by ISPs or by content providers.
>>>
>>> For example should exits not be allowed to run in Germany due to
>>> https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany ?
>>> Or not allow exits in EU due to the number of US websites deciding to block
>>> all of EU IPs to not have to comply to GDPR?
>>>
>>> ___
>>> tor-relays mailing list
>>> tor-relays@lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

[Pascal Terjan]

A country's ISPs blocking some websites is not the exit blocking it and the
result is the same than websites blocking the country, users of that exit
can't access the websites just because the exit is in that country but
doesn't do any filtering itself.

On Thu, 30 Aug 2018, 16:14 Nathaniel Suchy,  wrote:

> That’s a website blocking Tor users. Not a Tor Exit blocking a website.
> On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan  wrote:
>
>>
>>
>> On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy,  wrote:
>>
>>> So this exit node is censored by Turkey. That means any site blocked in
>>> Turkey is blocked on the exit. What about an exit node in China or Syria or
>>> Iraq? They censor, should exits there be allowed? I don't think they
>>> should. Make them relay only, (and yes that means no Guard or HSDir flags
>>> too) situation A could happen. The odds might not be in your favor. Don't
>>> risk that!
>>>
>>
>> Where do you put the limit?
>>
>> Various categories of websites are blocked in various countries either by
>> ISPs or by content providers.
>>
>> For example should exits not be allowed to run in Germany due to
>> https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany ?
>> Or not allow exits in EU due to the number of US websites deciding to block
>> all of EU IPs to not have to comply to GDPR?
>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Announcement: Relay operator meetings on IRC

[Colin Childs]

Hi Nusenu,

Yes, the current plan is to use MeetBot for the meetings. 

I will get a wiki page set up that the minutes / logs can be tracked on.

> On Aug 30, 2018, at 3:52 PM, nusenu  wrote:
> 
> Signed PGP part
>> Starting September 11th @ 1:00AM UTC, we will be piloting regular
>> relay operator meetings in #tor-relays on irc.oftc.net. 
> 
> 
> will you also use the meetbot like the other tor meetings do, so those that 
> can't join
> can read the log after the meeting?
> 
> 
> -- 
> https://twitter.com/nusenu_
> https://mastodon.social/@nusenu
> 
> 
> 

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Announcement: Relay operator meetings on IRC

[Colin Childs]

Hi Rob,

The idea behind the two times is to allow people from different timezones / on 
different schedules to attend during their non-working hours. 

Overseas was the wrong choice of words, anyone is welcome to attend the meeting 
that works best for them (or both, if they choose to).

After the first two meetings, the plan is to evaluate if the given times worked 
or if they should be adjusted; or if only one meeting time is necessary.

> On Aug 30, 2018, at 5:51 PM, I  wrote:
> 
> -Original Message-
> From: co...@torproject.org
> Hello Tor relay operators!
> Starting September 11th @ 1:00AM UTC, we will be piloting regular relay 
> operator meetings in #tor-relays on irc.oftc.net . 
> For everyone overseas, we will be hosting a second meeting on September 25th 
> @ 19:00 UTC.
> 
> It is a good idea.
> What is the difference?  Why distinguish one meeting as being for overseas?  
> Presumably you mean outside USA?  The timing can't be the reason given the 
> earth is round.
> 
> Rob
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

[Pascal Terjan]

On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy,  wrote:

> So this exit node is censored by Turkey. That means any site blocked in
> Turkey is blocked on the exit. What about an exit node in China or Syria or
> Iraq? They censor, should exits there be allowed? I don't think they
> should. Make them relay only, (and yes that means no Guard or HSDir flags
> too) situation A could happen. The odds might not be in your favor. Don't
> risk that!
>

Where do you put the limit?

Various categories of websites are blocked in various countries either by
ISPs or by content providers.

For example should exits not be allowed to run in Germany due to
https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany ? Or
not allow exits in EU due to the number of US websites deciding to block
all of EU IPs to not have to comply to GDPR?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

[Nathaniel Suchy]

Then assign a bad exit flag and let it middle relay.
On Thu, Aug 30, 2018 at 5:58 PM Gary  wrote:

> Hello
>
> On Thu, Aug 30, 2018 at 3:25 PM grarpamp  wrote:
>
>> This particular case receiving mentions for at least a few months...
>> D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114
>
>
> On Thu, 30 Aug 2018 at 22:11, Nathaniel Suchy  wrote:
>
>> So this exit node is censored by Turkey. That means any site blocked in
>> Turkey is blocked on the exit. What about an exit node in China or Syria or
>> Iraq? They censor, should exits there be allowed? I don't think they
>> should. Make them relay only, (and yes that means no Guard or HSDir flags
>> too) situation A could happen. The odds might not be in your favor. Don't
>> risk that!
>>
>
> Personally I think living with a small amount of country-by-country
> censorship is preferable to an "exitpolicy:exitsite" method, for example
> you are always going to get different areas/peoples thinking topics/sites
> things are acceptable while others dont think so. A tor user can simply
> change circuit and all will be fine.
>
> Also, if relay operators were able to produce a list of sites that they
> don't allow exits so, it would allow bad operators to game the system and
> perform correlation attacks.
>
> Even if a particular relay blocks exits to most .com's, it would still
> provide a valuable guard / middle service.
>
>
>>
>> Cordially,
>> Nathaniel Suchy
>>
>> On Thu, Aug 30, 2018 at 3:25 PM grarpamp  wrote:
>>
>>> This particular case receiving mentions for at least a few months...
>>> D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114
>>>
>>> The relay won't [likely] be badexited because neither it nor its
>>> upstream is
>>> shown to be doing anything malicious. Simple censorship isn't enough.
>>> And except for such limited censorship, the nodes are otherwise fully
>>> useful, and provide a valuable presence inside such regions / networks.
>>>
>>> Users, in such censoring regimes, that have sucessfully connected
>>> to tor, already have free choice of whatever exits they wish, therefore
>>> such censorship is moot for them.
>>>
>>> For everyone else, and them, workarounds exist such as,,,
>>> https://onion.torproject.org/
>>> http://yz7lpwfhhzcdyc5y.onion/
>>> search engines, sigs, vpns, mirrors, etc
>>>
>>> Further, whatever gets added to static exitpolicy's might move out
>>> from underneath them or the censor, the censor may quit, or the exit
>>> may fail to maintain the exitpolicy's. None of which are true
>>> representation
>>> of the net, and are effectively censorship as result of operator action
>>> even though unintentional / delayed.
>>>
>>> Currently many regimes do limited censorship like this,
>>> so you'd lose all those exits too for no good reason, see...
>>> https://ooni.torproject.org/
>>>
>>> https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country
>>>
>>> And arbitrarily hamper spirits, tactics, and success of volunteer
>>> resistance communities and operators in, and fighting, such regimes
>>> around the world.
>>>
>>> And if the net goes chaotic, majority of exits will have limited
>>> visibility,
>>> for which exitpolicy / badexit are hardly manageable solutions either,
>>> and would end up footshooting out many partly useful yet needed
>>> exits as well.
>>>
>>>
>>> If this situation bothers users, they can use... SIGNAL NEWNYM,
>>> New Identity, or ExcludeExitNodes.
>>>
>>> They can also create, maintain and publish lists of whatever such
>>> classes of nodes they wish to determine, including various levels
>>> of trust, contactability, verification, ouija, etc... such that others
>>> can subscribe to them and Exclude at will.
>>> They can further publish patches to make tor automatically
>>> read such lists, including some modes that might narrowly exclude
>>> and route stream requests around just those lists of censored
>>> destination:exit pairings.
>>>
>>> Ref also...
>>> https://metrics.torproject.org/rs.html#search/as:AS197328%20flag:exit
>>> https://metrics.torproject.org/rs.html#search/country:tr%20flag:exit
>>>
>>>
>>> In the subect situations, you'd want to show that it is in fact
>>> the exit itself, not its upstream, that is doing the censorship.
>>>
>>> Or that if fault can't be determined to the upstream or exit, what
>>> would be the plausible malicious benefit for an exit / upstream
>>> to block a given destination such that a badexit is warranted...
>>>
>>> a) Frustrate and divert off 0.001% of Turk users smart enough to
>>> use tor, chancing through tor client random exit selection of your
>>> blocking exit, off to one of the workarounds that you're equally
>>> unlikely to control and have ranked, through your exit vs one
>>> of the others tor has open?
>>>
>>> b) Prop up weird or otherwise secretly bad nodes on the net,
>>> like the hundreds of other ones out there, for which no badexit
>>> or diverse subscription services yet exist to qualify them?
>>>
>>> 

Re: [tor-relays] Abuse Complaints

[I]

> I've had a "discussion" with a WebIron employee once, where I patiently
> explained about Tor. It ended with him making stupid threats, and since
> that day I blacklisted W.I. on our mail servers. .
> 
> -Ralph

Would that be in USA?



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

[Gary]

Hello

On Thu, Aug 30, 2018 at 3:25 PM grarpamp  wrote:

> This particular case receiving mentions for at least a few months...
> D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114


On Thu, 30 Aug 2018 at 22:11, Nathaniel Suchy  wrote:

> So this exit node is censored by Turkey. That means any site blocked in
> Turkey is blocked on the exit. What about an exit node in China or Syria or
> Iraq? They censor, should exits there be allowed? I don't think they
> should. Make them relay only, (and yes that means no Guard or HSDir flags
> too) situation A could happen. The odds might not be in your favor. Don't
> risk that!
>

Personally I think living with a small amount of country-by-country
censorship is preferable to an "exitpolicy:exitsite" method, for example
you are always going to get different areas/peoples thinking topics/sites
things are acceptable while others dont think so. A tor user can simply
change circuit and all will be fine.

Also, if relay operators were able to produce a list of sites that they
don't allow exits so, it would allow bad operators to game the system and
perform correlation attacks.

Even if a particular relay blocks exits to most .com's, it would still
provide a valuable guard / middle service.


>
> Cordially,
> Nathaniel Suchy
>
> On Thu, Aug 30, 2018 at 3:25 PM grarpamp  wrote:
>
>> This particular case receiving mentions for at least a few months...
>> D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114
>>
>> The relay won't [likely] be badexited because neither it nor its upstream
>> is
>> shown to be doing anything malicious. Simple censorship isn't enough.
>> And except for such limited censorship, the nodes are otherwise fully
>> useful, and provide a valuable presence inside such regions / networks.
>>
>> Users, in such censoring regimes, that have sucessfully connected
>> to tor, already have free choice of whatever exits they wish, therefore
>> such censorship is moot for them.
>>
>> For everyone else, and them, workarounds exist such as,,,
>> https://onion.torproject.org/
>> http://yz7lpwfhhzcdyc5y.onion/
>> search engines, sigs, vpns, mirrors, etc
>>
>> Further, whatever gets added to static exitpolicy's might move out
>> from underneath them or the censor, the censor may quit, or the exit
>> may fail to maintain the exitpolicy's. None of which are true
>> representation
>> of the net, and are effectively censorship as result of operator action
>> even though unintentional / delayed.
>>
>> Currently many regimes do limited censorship like this,
>> so you'd lose all those exits too for no good reason, see...
>> https://ooni.torproject.org/
>>
>> https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country
>>
>> And arbitrarily hamper spirits, tactics, and success of volunteer
>> resistance communities and operators in, and fighting, such regimes
>> around the world.
>>
>> And if the net goes chaotic, majority of exits will have limited
>> visibility,
>> for which exitpolicy / badexit are hardly manageable solutions either,
>> and would end up footshooting out many partly useful yet needed
>> exits as well.
>>
>>
>> If this situation bothers users, they can use... SIGNAL NEWNYM,
>> New Identity, or ExcludeExitNodes.
>>
>> They can also create, maintain and publish lists of whatever such
>> classes of nodes they wish to determine, including various levels
>> of trust, contactability, verification, ouija, etc... such that others
>> can subscribe to them and Exclude at will.
>> They can further publish patches to make tor automatically
>> read such lists, including some modes that might narrowly exclude
>> and route stream requests around just those lists of censored
>> destination:exit pairings.
>>
>> Ref also...
>> https://metrics.torproject.org/rs.html#search/as:AS197328%20flag:exit
>> https://metrics.torproject.org/rs.html#search/country:tr%20flag:exit
>>
>>
>> In the subect situations, you'd want to show that it is in fact
>> the exit itself, not its upstream, that is doing the censorship.
>>
>> Or that if fault can't be determined to the upstream or exit, what
>> would be the plausible malicious benefit for an exit / upstream
>> to block a given destination such that a badexit is warranted...
>>
>> a) Frustrate and divert off 0.001% of Turk users smart enough to
>> use tor, chancing through tor client random exit selection of your
>> blocking exit, off to one of the workarounds that you're equally
>> unlikely to control and have ranked, through your exit vs one
>> of the others tor has open?
>>
>> b) Prop up weird or otherwise secretly bad nodes on the net,
>> like the hundreds of other ones out there, for which no badexit
>> or diverse subscription services yet exist to qualify them?
>>
>> c) ???
>>
>> Or that some large number of topsites were censored via
>> singular or small numbers of exits / upstreams so as to be
>> exceedingly annoying to the network users as a whole, where
>> no other environment of such 

Re: [tor-relays] Abuse Complaints

[Ralph Seichter]

On 30.08.18 22:07, Andrew Deason wrote:

> For what it's worth, webiron has actually responded to my replies to
> their reports before. I'm not saying it's a great use of time arguing
> with them, but the replies are actually read by a human (at least,
> sometimes).

I've had a "discussion" with a WebIron employee once, where I patiently
explained about Tor. It ended with him making stupid threats, and since
that day I blacklisted W.I. on our mail servers. I think I posted about
this experience here on the mailing list some years ago.

-Ralph
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

[Nathaniel Suchy]

So this exit node is censored by Turkey. That means any site blocked in
Turkey is blocked on the exit. What about an exit node in China or Syria or
Iraq? They censor, should exits there be allowed? I don't think they
should. Make them relay only, (and yes that means no Guard or HSDir flags
too) situation A could happen. The odds might not be in your favor. Don't
risk that!

Cordially,
Nathaniel Suchy

On Thu, Aug 30, 2018 at 3:25 PM grarpamp  wrote:

> This particular case receiving mentions for at least a few months...
> D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114
>
> The relay won't [likely] be badexited because neither it nor its upstream
> is
> shown to be doing anything malicious. Simple censorship isn't enough.
> And except for such limited censorship, the nodes are otherwise fully
> useful, and provide a valuable presence inside such regions / networks.
>
> Users, in such censoring regimes, that have sucessfully connected
> to tor, already have free choice of whatever exits they wish, therefore
> such censorship is moot for them.
>
> For everyone else, and them, workarounds exist such as,,,
> https://onion.torproject.org/
> http://yz7lpwfhhzcdyc5y.onion/
> search engines, sigs, vpns, mirrors, etc
>
> Further, whatever gets added to static exitpolicy's might move out
> from underneath them or the censor, the censor may quit, or the exit
> may fail to maintain the exitpolicy's. None of which are true
> representation
> of the net, and are effectively censorship as result of operator action
> even though unintentional / delayed.
>
> Currently many regimes do limited censorship like this,
> so you'd lose all those exits too for no good reason, see...
> https://ooni.torproject.org/
>
> https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country
>
> And arbitrarily hamper spirits, tactics, and success of volunteer
> resistance communities and operators in, and fighting, such regimes
> around the world.
>
> And if the net goes chaotic, majority of exits will have limited
> visibility,
> for which exitpolicy / badexit are hardly manageable solutions either,
> and would end up footshooting out many partly useful yet needed
> exits as well.
>
>
> If this situation bothers users, they can use... SIGNAL NEWNYM,
> New Identity, or ExcludeExitNodes.
>
> They can also create, maintain and publish lists of whatever such
> classes of nodes they wish to determine, including various levels
> of trust, contactability, verification, ouija, etc... such that others
> can subscribe to them and Exclude at will.
> They can further publish patches to make tor automatically
> read such lists, including some modes that might narrowly exclude
> and route stream requests around just those lists of censored
> destination:exit pairings.
>
> Ref also...
> https://metrics.torproject.org/rs.html#search/as:AS197328%20flag:exit
> https://metrics.torproject.org/rs.html#search/country:tr%20flag:exit
>
>
> In the subect situations, you'd want to show that it is in fact
> the exit itself, not its upstream, that is doing the censorship.
>
> Or that if fault can't be determined to the upstream or exit, what
> would be the plausible malicious benefit for an exit / upstream
> to block a given destination such that a badexit is warranted...
>
> a) Frustrate and divert off 0.001% of Turk users smart enough to
> use tor, chancing through tor client random exit selection of your
> blocking exit, off to one of the workarounds that you're equally
> unlikely to control and have ranked, through your exit vs one
> of the others tor has open?
>
> b) Prop up weird or otherwise secretly bad nodes on the net,
> like the hundreds of other ones out there, for which no badexit
> or diverse subscription services yet exist to qualify them?
>
> c) ???
>
> Or that some large number of topsites were censored via
> singular or small numbers of exits / upstreams so as to be
> exceedingly annoying to the network users as a whole, where
> no other environment of such / chaotic widespread annoyance
> is known to exist at the same time.
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Announcement: Relay operator meetings on IRC

[nusenu]

> Starting September 11th @ 1:00AM UTC, we will be piloting regular
> relay operator meetings in #tor-relays on irc.oftc.net. 


will you also use the meetbot like the other tor meetings do, so those that 
can't join
can read the log after the meeting?


-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Announcement: Relay operator meetings on IRC

[Colin Childs]

Hello Tor relay operators!

Starting September 11th @ 1:00AM UTC, we will be piloting regular relay 
operator meetings in #tor-relays on irc.oftc.net. These meetings will be an 
opportunity to introduce yourself to the operator community, make new contacts 
and provide updates to the group on the status of your relays. This will also 
be an opportunity to have questions answered by a group of dedicated relay 
operators, community members and Tor Project staff. 

For everyone overseas, we will be hosting a second meeting on September 25th @ 
19:00 UTC.

After these initial two meetings, we will evaluate if these dates / times need 
to be adjusted, as well as how frequently these meetings should be run. I will 
send a follow-up email at the end of September with the results of that 
evaluation. 

On the Monday of meeting weeks, I will send a reminder on this list with the 
channel, date and time.

I look forward to seeing you all there, and thank you for running relays! 

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Abuse Complaints

[Andrew Deason]

On Wed, 29 Aug 2018 14:48:33 +0200
Ralph Seichter  wrote:

> Automated complaints are a different matter. I don't feel the need to
> converse with Fail2ban or WebIron bots.

For what it's worth, webiron has actually responded to my replies to
their reports before. I'm not saying it's a great use of time arguing
with them, but the replies are actually read by a human (at least,
sometimes).

-- 
Andrew Deason
adea...@dson.org

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

[grarpamp]

This particular case receiving mentions for at least a few months...
D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114

The relay won't [likely] be badexited because neither it nor its upstream is
shown to be doing anything malicious. Simple censorship isn't enough.
And except for such limited censorship, the nodes are otherwise fully
useful, and provide a valuable presence inside such regions / networks.

Users, in such censoring regimes, that have sucessfully connected
to tor, already have free choice of whatever exits they wish, therefore
such censorship is moot for them.

For everyone else, and them, workarounds exist such as,,,
https://onion.torproject.org/
http://yz7lpwfhhzcdyc5y.onion/
search engines, sigs, vpns, mirrors, etc

Further, whatever gets added to static exitpolicy's might move out
from underneath them or the censor, the censor may quit, or the exit
may fail to maintain the exitpolicy's. None of which are true representation
of the net, and are effectively censorship as result of operator action
even though unintentional / delayed.

Currently many regimes do limited censorship like this,
so you'd lose all those exits too for no good reason, see...
https://ooni.torproject.org/
https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country

And arbitrarily hamper spirits, tactics, and success of volunteer
resistance communities and operators in, and fighting, such regimes
around the world.

And if the net goes chaotic, majority of exits will have limited visibility,
for which exitpolicy / badexit are hardly manageable solutions either,
and would end up footshooting out many partly useful yet needed
exits as well.


If this situation bothers users, they can use... SIGNAL NEWNYM,
New Identity, or ExcludeExitNodes.

They can also create, maintain and publish lists of whatever such
classes of nodes they wish to determine, including various levels
of trust, contactability, verification, ouija, etc... such that others
can subscribe to them and Exclude at will.
They can further publish patches to make tor automatically
read such lists, including some modes that might narrowly exclude
and route stream requests around just those lists of censored
destination:exit pairings.

Ref also...
https://metrics.torproject.org/rs.html#search/as:AS197328%20flag:exit
https://metrics.torproject.org/rs.html#search/country:tr%20flag:exit


In the subect situations, you'd want to show that it is in fact
the exit itself, not its upstream, that is doing the censorship.

Or that if fault can't be determined to the upstream or exit, what
would be the plausible malicious benefit for an exit / upstream
to block a given destination such that a badexit is warranted...

a) Frustrate and divert off 0.001% of Turk users smart enough to
use tor, chancing through tor client random exit selection of your
blocking exit, off to one of the workarounds that you're equally
unlikely to control and have ranked, through your exit vs one
of the others tor has open?

b) Prop up weird or otherwise secretly bad nodes on the net,
like the hundreds of other ones out there, for which no badexit
or diverse subscription services yet exist to qualify them?

c) ???

Or that some large number of topsites were censored via
singular or small numbers of exits / upstreams so as to be
exceedingly annoying to the network users as a whole, where
no other environment of such / chaotic widespread annoyance
is known to exist at the same time.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] log "Is your outbound address the same as your relay address?"

[Logforme]

"Your relay has a very large number of connections to other relays. Is 
your outbound address the same as your relay address? Found 12
connections to 8 relays. Found 12 current canonical connections, in 0 
of which we were a non-canonical peer. 4 relays had more than 1 
connection, 0 had more than 2, and 0 had more

than 4 connections."
Quick google found this ticket: 
https://trac.torproject.org/projects/tor/ticket/24841

Looks like you can ignore this.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] log "Is your outbound address the same as your relay address?"

[Tim Kuijsten]

Hi,

I just setup a new relay[0]. One of the messages I got is the following:

"Your relay has a very large number of connections to other relays. Is 
your outbound address the same as your relay address? Found 12
connections to 8 relays. Found 12 current canonical connections, in 0 of 
which we were a non-canonical peer. 4 relays had more than 1 connection, 
0 had more than 2, and 0 had more

than 4 connections."

When I had setup another relay last week[1] I got the same message, and 
it didn't reappear so I assume this is about starting up a new relay and 
is nothing to worry about. I just thought I'd let you know.


The hostnames of both machines matches the public dns and reverse dns 
names. Furthermore each machine has only one public ipv4 address, which 
is also set in it's local /etc/hosts file. At one machine I had set 
"Address" in the torrc as well, but this didn't avoid getting this 
message once.


Kind regards,

Tim

[0] tosk B183A69592D2E8C8C487C054D0849E3C9561DC11
[1] kali 2C76951164C5184A3B8B7CC1914B34E4622B225F
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Test bed in MyFamily?

[teor]

> On 30 Aug 2018, at 16:03, Totor be  wrote:
> 
> That's what I've done, but what is the rationale if I may ask ?
> Personally, I prefer not to see a relay than seeing one down, but this is 
> extremely subjective!

MyFamily exists to protect users from end-to-end correlation.
(And relay operators from requests to provide end-to-end correlation data.)

It's shown on Relay Search as a convenience to operators and other users.

T



signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Test bed in MyFamily?

[Totor be]

Hi Ian

That's what I've done, but what is the rationale if I may ask ?
Personally, I prefer not to see a relay than seeing one down, but this is
extremely subjective!

Thanks

On Wed, Aug 29, 2018 at 10:11 PM Iain Learmonth  wrote:

> Hi,
>
> On 29/08/18 13:16, Totor be wrote:
> > This 4th relay will be fully operational, but will only be started from
> > time to time, when updates are available
> > After the updates are installed, I plan to leave it running for half a
> > day or so until it appears in Tor Metrics
> > Question: should I include this test bed relay in MyFamily or leave it
> > completely stand alone?
> > What would you recommend?
>
> Yes, please include family for all of your relays.
>
> Thanks,
> Iain.
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays