Then assign a bad exit flag and let it middle relay. On Thu, Aug 30, 2018 at 5:58 PM Gary <jaffacakemonste...@gmail.com> wrote:
> Hello > > On Thu, Aug 30, 2018 at 3:25 PM grarpamp <grarp...@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 <m...@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 <grarp...@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@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