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

Thu Aug 30 22:49:03 UTC 2018

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

> Hello
>
> On Thu, Aug 30, 2018 at 3:25 PM grarpamp <grarpamp at gmail.com> 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 <me at lunorian.is> 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 <grarpamp at gmail.com> 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 at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20180830/fda759a9/attachment-0001.html>