[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship
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.
> 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!
> 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 126.96.36.199
>> The relay won't [likely] be badexited because neither it nor its upstream
>> 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,,,
>> 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
>> 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...
>> 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
>> 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...
>> 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 mailing firstname.lastname@example.org://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-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to