<div dir="ltr">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?</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 30, 2018 at 10:02 PM arisbe <<a href="mailto:arisbe@cni.net">arisbe@cni.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Children should be seen and not herd. The opposite goes for Tor
relays.<br>
Arisbe</div><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<div class="m_-4825012735173418909moz-cite-prefix">On 8/30/2018 2:11 PM, Nathaniel Suchy
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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!
<div><br>
</div>
<div>Cordially,</div>
<div>Nathaniel Suchy</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Thu, Aug 30, 2018 at 3:25 PM grarpamp <<a href="mailto:grarpamp@gmail.com" target="_blank">grarpamp@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This
particular case receiving mentions for at least a few
months...<br>
D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov
185.125.33.114<br>
<br>
The relay won't [likely] be badexited because neither it nor
its upstream is<br>
shown to be doing anything malicious. Simple censorship isn't
enough.<br>
And except for such limited censorship, the nodes are
otherwise fully<br>
useful, and provide a valuable presence inside such regions /
networks.<br>
<br>
Users, in such censoring regimes, that have sucessfully
connected<br>
to tor, already have free choice of whatever exits they wish,
therefore<br>
such censorship is moot for them.<br>
<br>
For everyone else, and them, workarounds exist such as,,,<br>
<a href="https://onion.torproject.org/" rel="noreferrer" target="_blank">https://onion.torproject.org/</a><br>
<a href="http://yz7lpwfhhzcdyc5y.onion/" rel="noreferrer" target="_blank">http://yz7lpwfhhzcdyc5y.onion/</a><br>
search engines, sigs, vpns, mirrors, etc<br>
<br>
Further, whatever gets added to static exitpolicy's might move
out<br>
from underneath them or the censor, the censor may quit, or
the exit<br>
may fail to maintain the exitpolicy's. None of which are true
representation<br>
of the net, and are effectively censorship as result of
operator action<br>
even though unintentional / delayed.<br>
<br>
Currently many regimes do limited censorship like this,<br>
so you'd lose all those exits too for no good reason, see...<br>
<a href="https://ooni.torproject.org/" rel="noreferrer" target="_blank">https://ooni.torproject.org/</a><br>
<a href="https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country</a><br>
<br>
And arbitrarily hamper spirits, tactics, and success of
volunteer<br>
resistance communities and operators in, and fighting, such
regimes<br>
around the world.<br>
<br>
And if the net goes chaotic, majority of exits will have
limited visibility,<br>
for which exitpolicy / badexit are hardly manageable solutions
either,<br>
and would end up footshooting out many partly useful yet
needed<br>
exits as well.<br>
<br>
<br>
If this situation bothers users, they can use... SIGNAL
NEWNYM,<br>
New Identity, or ExcludeExitNodes.<br>
<br>
They can also create, maintain and publish lists of whatever
such<br>
classes of nodes they wish to determine, including various
levels<br>
of trust, contactability, verification, ouija, etc... such
that others<br>
can subscribe to them and Exclude at will.<br>
They can further publish patches to make tor automatically<br>
read such lists, including some modes that might narrowly
exclude<br>
and route stream requests around just those lists of censored<br>
destination:exit pairings.<br>
<br>
Ref also...<br>
<a href="https://metrics.torproject.org/rs.html#search/as:AS197328%20flag:exit" rel="noreferrer" target="_blank">https://metrics.torproject.org/rs.html#search/as:AS197328%20flag:exit</a><br>
<a href="https://metrics.torproject.org/rs.html#search/country:tr%20flag:exit" rel="noreferrer" target="_blank">https://metrics.torproject.org/rs.html#search/country:tr%20flag:exit</a><br>
<br>
<br>
In the subect situations, you'd want to show that it is in
fact<br>
the exit itself, not its upstream, that is doing the
censorship.<br>
<br>
Or that if fault can't be determined to the upstream or exit,
what<br>
would be the plausible malicious benefit for an exit /
upstream<br>
to block a given destination such that a badexit is
warranted...<br>
<br>
a) Frustrate and divert off 0.001% of Turk users smart enough
to<br>
use tor, chancing through tor client random exit selection of
your<br>
blocking exit, off to one of the workarounds that you're
equally<br>
unlikely to control and have ranked, through your exit vs one<br>
of the others tor has open?<br>
<br>
b) Prop up weird or otherwise secretly bad nodes on the net,<br>
like the hundreds of other ones out there, for which no
badexit<br>
or diverse subscription services yet exist to qualify them?<br>
<br>
c) ???<br>
<br>
Or that some large number of topsites were censored via<br>
singular or small numbers of exits / upstreams so as to be<br>
exceedingly annoying to the network users as a whole, where<br>
no other environment of such / chaotic widespread annoyance<br>
is known to exist at the same time.<br>
_______________________________________________<br>
tor-relays mailing list<br>
<a href="mailto:tor-relays@lists.torproject.org" target="_blank">tor-relays@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br>
</blockquote>
</div>
<br>
<fieldset class="m_-4825012735173418909mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
tor-relays mailing list
<a class="m_-4825012735173418909moz-txt-link-abbreviated" href="mailto:tor-relays@lists.torproject.org" target="_blank">tor-relays@lists.torproject.org</a>
<a class="m_-4825012735173418909moz-txt-link-freetext" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a>
</pre>
</blockquote>
<br>
</div><div text="#000000" bgcolor="#FFFFFF"><pre class="m_-4825012735173418909moz-signature" cols="72">--
One person's moral compass is another person's face in the dirt.</pre>
</div>
_______________________________________________<br>
tor-relays mailing list<br>
<a href="mailto:tor-relays@lists.torproject.org" target="_blank">tor-relays@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br>
</blockquote></div>