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

[Mirimir <mirimir@xxxxxxxxxx>]

On 08/31/2018 02:51 PM, Matthew Glennon wrote:
> Anyone else getting nude photos and random links from Cynthia Coleman <
> cynthiacoleman843756@xxxxxxxxxxxx> attached to this (and other thread(s)
> lately? Spam obviously, but ugh.
> 
> Matthew Glennon

Sure am ;) Somebody could find the abuse contact and post it :)

> Want to make sure only I can read your message? Use PGP!
> (Then paste the encrypted text into an email for me to receive!)
> https://keybase.io/crazysane/
> https://pgp.key-server.io/pks/lookup?op=get&search=0x92E43A8A9EF85EB4
> 
> 
> On Fri, Aug 31, 2018 at 5:01 PM Conrad Rockenhaus <conrad@xxxxxxxxxxxxxx>
> wrote:
> 
>> Good God every conversation, now. Anyway.
>>
>> This exit isn’t bad exit material. Turkey has been known to block Tor
>> though, I’m actually proud of this guy for having the cajones (also known
>> as balls to those of you who don’t habla espanol) to operate an exit in
>> country such as Turkey, which absolutely hates freedom inducing
>> technologies such as Tor. Let’s give this guy (or gal) the atto-boy by
>> marking the exit as a bad-exit just because stuff gets blocked in
>> autocratic regimes that this operator has no control over. None, absolutely
>> none. They screw with the DNS servers over there, that’s why during the
>> last uprising they were tagging “8.8.8.8” on the walls.
>>
>> Now they’re doing things a little more sophisticated. Either way, this guy
>> gives us a window to see what is blocked and what isn’t blocked within the
>> Turkish thunderdome.
>>
>> -Conrad
>>
>>> On Aug 30, 2018, at 9:24 PM, Nathaniel Suchy <me@xxxxxxxxxxx> wrote:
>>>
>>> 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 <arisbe@xxxxxxx> 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 <grarpamp@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
>>>>> 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.
>>>>
>>>> _______________________________________________
>>>> tor-relays mailing list
>>>> tor-relays@xxxxxxxxxxxxxxxxxxxx
>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>>
>>> --
>>> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
>>> To unsubscribe or change other settings go to
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>>
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> 
> 
> 
> _______________________________________________
> tor-relays mailing list
> tor-relays@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays