Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship
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_countr... 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.
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@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_countr...
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
Hello On Thu, Aug 30, 2018 at 3:25 PM grarpamp <grarpamp@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@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@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_countr...
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
Then assign a bad exit flag and let it middle relay. On Thu, Aug 30, 2018 at 5:58 PM Gary <jaffacakemonster53@gmail.com> wrote:
Hello
On Thu, Aug 30, 2018 at 3:25 PM grarpamp <grarpamp@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@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@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_countr...
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
On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy, <me@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!
Where do you put the limit? Various categories of websites are blocked in various countries either by ISPs or by content providers. For example should exits not be allowed to run in Germany due to https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany ? Or not allow exits in EU due to the number of US websites deciding to block all of EU IPs to not have to comply to GDPR?
That’s a website blocking Tor users. Not a Tor Exit blocking a website. On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan <pterjan@gmail.com> wrote:
On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy, <me@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!
Where do you put the limit?
Various categories of websites are blocked in various countries either by ISPs or by content providers.
For example should exits not be allowed to run in Germany due to https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany ? Or not allow exits in EU due to the number of US websites deciding to block all of EU IPs to not have to comply to GDPR?
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
A country's ISPs blocking some websites is not the exit blocking it and the result is the same than websites blocking the country, users of that exit can't access the websites just because the exit is in that country but doesn't do any filtering itself. On Thu, 30 Aug 2018, 16:14 Nathaniel Suchy, <me@lunorian.is> wrote:
That’s a website blocking Tor users. Not a Tor Exit blocking a website. On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan <pterjan@gmail.com> wrote:
On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy, <me@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!
Where do you put the limit?
Various categories of websites are blocked in various countries either by ISPs or by content providers.
For example should exits not be allowed to run in Germany due to https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany ? Or not allow exits in EU due to the number of US websites deciding to block all of EU IPs to not have to comply to GDPR?
_______________________________________________ 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
The exit is behind a filtered ISP. Opposed to a website blocking exits. That’s the difference. 1) The content provider causes the block. 2) The exit causes the block. In situation two a censored user may give up on Tor entirely. Should we allow exits in China or Iraq or Syria or Turkey or the several other countries. What if their governments who can afford it spin up 10,000 exits in an effort to censor the Tor Network. Will we sit idly by and allow it? On Thu, Aug 30, 2018 at 7:17 PM Pascal Terjan <pterjan@gmail.com> wrote:
A country's ISPs blocking some websites is not the exit blocking it and the result is the same than websites blocking the country, users of that exit can't access the websites just because the exit is in that country but doesn't do any filtering itself.
On Thu, 30 Aug 2018, 16:14 Nathaniel Suchy, <me@lunorian.is> wrote:
That’s a website blocking Tor users. Not a Tor Exit blocking a website. On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan <pterjan@gmail.com> wrote:
On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy, <me@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!
Where do you put the limit?
Various categories of websites are blocked in various countries either by ISPs or by content providers.
For example should exits not be allowed to run in Germany due to https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany ? Or not allow exits in EU due to the number of US websites deciding to block all of EU IPs to not have to comply to GDPR?
_______________________________________________ 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
Could this be mitigated with a detection addon in Tor Browser? Detect that the site may be blocked at the exit and offer to fetch a new circuit for the site? On Thu, Aug 30, 2018, 19:22 Nathaniel Suchy <me@lunorian.is> wrote:
The exit is behind a filtered ISP. Opposed to a website blocking exits. That’s the difference.
1) The content provider causes the block. 2) The exit causes the block.
In situation two a censored user may give up on Tor entirely. Should we allow exits in China or Iraq or Syria or Turkey or the several other countries. What if their governments who can afford it spin up 10,000 exits in an effort to censor the Tor Network. Will we sit idly by and allow it?
On Thu, Aug 30, 2018 at 7:17 PM Pascal Terjan <pterjan@gmail.com> wrote:
A country's ISPs blocking some websites is not the exit blocking it and the result is the same than websites blocking the country, users of that exit can't access the websites just because the exit is in that country but doesn't do any filtering itself.
On Thu, 30 Aug 2018, 16:14 Nathaniel Suchy, <me@lunorian.is> wrote:
That’s a website blocking Tor users. Not a Tor Exit blocking a website. On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan <pterjan@gmail.com> wrote:
On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy, <me@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!
Where do you put the limit?
Various categories of websites are blocked in various countries either by ISPs or by content providers.
For example should exits not be allowed to run in Germany due to https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany ? Or not allow exits in EU due to the number of US websites deciding to block all of EU IPs to not have to comply to GDPR?
_______________________________________________ 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
Matthew: Built in functionality, maybe, an addon, no. Also either solution is a bandaid to the actual problem that we're allowing an exit with no contact information to censor Tor users with impunity! On Thu, Aug 30, 2018 at 8:01 PM Matthew Glennon <matthew@glennon.online> wrote:
Could this be mitigated with a detection addon in Tor Browser? Detect that the site may be blocked at the exit and offer to fetch a new circuit for the site?
On Thu, Aug 30, 2018, 19:22 Nathaniel Suchy <me@lunorian.is> wrote:
The exit is behind a filtered ISP. Opposed to a website blocking exits. That’s the difference.
1) The content provider causes the block. 2) The exit causes the block.
In situation two a censored user may give up on Tor entirely. Should we allow exits in China or Iraq or Syria or Turkey or the several other countries. What if their governments who can afford it spin up 10,000 exits in an effort to censor the Tor Network. Will we sit idly by and allow it?
On Thu, Aug 30, 2018 at 7:17 PM Pascal Terjan <pterjan@gmail.com> wrote:
A country's ISPs blocking some websites is not the exit blocking it and the result is the same than websites blocking the country, users of that exit can't access the websites just because the exit is in that country but doesn't do any filtering itself.
On Thu, 30 Aug 2018, 16:14 Nathaniel Suchy, <me@lunorian.is> wrote:
That’s a website blocking Tor users. Not a Tor Exit blocking a website. On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan <pterjan@gmail.com> wrote:
On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy, <me@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!
Where do you put the limit?
Various categories of websites are blocked in various countries either by ISPs or by content providers.
For example should exits not be allowed to run in Germany due to https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany ? Or not allow exits in EU due to the number of US websites deciding to block all of EU IPs to not have to comply to GDPR?
_______________________________________________ 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
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
How is situation 1 different from 2 from the user perspective? In both cases the user doesn't have access because of the country where the exit is running. A lot of countries have various levels of blocky (for example torrent websites in UK). Is the solution to only run all exits in a few "good" countries with no filtering but maybe some strong surveillance/analysis? On Thu, 30 Aug 2018, 16:22 Nathaniel Suchy, <me@lunorian.is> wrote:
The exit is behind a filtered ISP. Opposed to a website blocking exits. That’s the difference.
1) The content provider causes the block. 2) The exit causes the block.
In situation two a censored user may give up on Tor entirely. Should we allow exits in China or Iraq or Syria or Turkey or the several other countries. What if their governments who can afford it spin up 10,000 exits in an effort to censor the Tor Network. Will we sit idly by and allow it?
On Thu, Aug 30, 2018 at 7:17 PM Pascal Terjan <pterjan@gmail.com> wrote:
A country's ISPs blocking some websites is not the exit blocking it and the result is the same than websites blocking the country, users of that exit can't access the websites just because the exit is in that country but doesn't do any filtering itself.
On Thu, 30 Aug 2018, 16:14 Nathaniel Suchy, <me@lunorian.is> wrote:
That’s a website blocking Tor users. Not a Tor Exit blocking a website. On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan <pterjan@gmail.com> wrote:
On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy, <me@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!
Where do you put the limit?
Various categories of websites are blocked in various countries either by ISPs or by content providers.
For example should exits not be allowed to run in Germany due to https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany ? Or not allow exits in EU due to the number of US websites deciding to block all of EU IPs to not have to comply to GDPR?
_______________________________________________ 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
So you are totally cool allowing Tor Exits to censor with impunity? Allowing this one Turkey exit risks losing new Tor users thinking the product doesn’t work after all. On Thu, Aug 30, 2018 at 8:30 PM Pascal Terjan <pterjan@gmail.com> wrote:
How is situation 1 different from 2 from the user perspective? In both cases the user doesn't have access because of the country where the exit is running.
A lot of countries have various levels of blocky (for example torrent websites in UK). Is the solution to only run all exits in a few "good" countries with no filtering but maybe some strong surveillance/analysis?
On Thu, 30 Aug 2018, 16:22 Nathaniel Suchy, <me@lunorian.is> wrote:
The exit is behind a filtered ISP. Opposed to a website blocking exits. That’s the difference.
1) The content provider causes the block. 2) The exit causes the block.
In situation two a censored user may give up on Tor entirely. Should we allow exits in China or Iraq or Syria or Turkey or the several other countries. What if their governments who can afford it spin up 10,000 exits in an effort to censor the Tor Network. Will we sit idly by and allow it?
On Thu, Aug 30, 2018 at 7:17 PM Pascal Terjan <pterjan@gmail.com> wrote:
A country's ISPs blocking some websites is not the exit blocking it and the result is the same than websites blocking the country, users of that exit can't access the websites just because the exit is in that country but doesn't do any filtering itself.
On Thu, 30 Aug 2018, 16:14 Nathaniel Suchy, <me@lunorian.is> wrote:
That’s a website blocking Tor users. Not a Tor Exit blocking a website. On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan <pterjan@gmail.com> wrote:
On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy, <me@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!
Where do you put the limit?
Various categories of websites are blocked in various countries either by ISPs or by content providers.
For example should exits not be allowed to run in Germany due to https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany ? Or not allow exits in EU due to the number of US websites deciding to block all of EU IPs to not have to comply to GDPR?
_______________________________________________ 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
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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@cni.net> 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@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_countr...
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 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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@lunorian.is> 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@cni.net> 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@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_countr...
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 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Anyone else getting nude photos and random links from Cynthia Coleman < cynthiacoleman843756@ru.irzum.com> attached to this (and other thread(s) lately? Spam obviously, but ugh. Matthew Glennon 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@rockenhaus.com> 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@lunorian.is> 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@cni.net> 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@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_countr...
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 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi, Yes I too got messages from Cynthia every few hours (wanting to meet) until I blocked the email address. Thanks On Fri, 31 Aug 2018, 22:52 Matthew Glennon, <matthew@glennon.online> wrote:
Anyone else getting nude photos and random links from Cynthia Coleman < cynthiacoleman843756@ru.irzum.com> attached to this (and other thread(s) lately? Spam obviously, but ugh.
Matthew Glennon
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@rockenhaus.com> 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@lunorian.is> 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@cni.net> 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@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_countr...
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 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
_______________________________________________ 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
What's the chances of switching to a mailing list system that doesn't expose your email address to everyone on the list when you reply? On Fri, Aug 31, 2018, 18:06 Gary <jaffacakemonster53@gmail.com> wrote:
Hi,
Yes I too got messages from Cynthia every few hours (wanting to meet) until I blocked the email address.
Thanks
On Fri, 31 Aug 2018, 22:52 Matthew Glennon, <matthew@glennon.online> wrote:
Anyone else getting nude photos and random links from Cynthia Coleman < cynthiacoleman843756@ru.irzum.com> attached to this (and other thread(s) lately? Spam obviously, but ugh.
Matthew Glennon
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@rockenhaus.com> 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@lunorian.is> 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@cni.net> 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@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_countr...
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 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
_______________________________________________ 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
On 01.09.18 00:12, Matthew Glennon wrote:
What's the chances of switching to a mailing list system that doesn't expose your email address to everyone on the list when you reply?
Oh boy. This question, followed by the line:
On Fri, Aug 31, 2018, 18:06 Gary <jaffacakemonster53@gmail.com> wrote:
That was inserted by your MUA, Mr. Glennon. Verbatim email address, top posting, full thread quote including all ML footers -- you're doing it completely wrong on your end and ask about the mailing list software? That's novel. :-D -Ralph
What's the chances of switching to a mailing list system that doesn't expose your email address to everyone on the list when you reply?
That was inserted by your MUA, Mr. Glennon. Verbatim email address, top posting, full thread quote including all ML footers -- you're doing it completely wrong on your end and ask about the mailing list software?
Anyone has a good resource (wiki, blog) for mailing good practice ? That would be helpful. -- regards, natus
On 08/31/2018 03:12 PM, I wrote:
Anyone else getting nude photos and random links from Cynthia Coleman <cynthiacoleman843756@ru.irzum.com <mailto:cynthiacoleman843756@ru.irzum.com>> attached to this (and other thread(s) lately? Spam obviously, but ugh. Matthew Glennon
Does she want to be the contact person for an unlimited exit run in Syria?
Maybe worth a try ;) But "she's" just a bot.
Anyone else getting nude photos and random links from Cynthia Coleman Matthew Glennon
Does she want to be the contact person for an unlimited exit run in Syria?
Maybe worth a try ;) But "she's" just a bot.
Then she's the perfect girl for those chaps in the Syrian Electronic Army.
On 08/31/2018 05:26 PM, I wrote:
Anyone else getting nude photos and random links from Cynthia Coleman Matthew Glennon
Does she want to be the contact person for an unlimited exit run in Syria?
Maybe worth a try ;) But "she's" just a bot.
Then she's the perfect girl for those chaps in the Syrian Electronic Army.
Go for it, dude :) I've looked off-and-on for mail lists that don't require authorization, but haven't found any :( And anyway, too easily blocked. So would abuse complaints have enough volume and diversity to be effective?
On 08/31/2018 02:51 PM, Matthew Glennon wrote:
Anyone else getting nude photos and random links from Cynthia Coleman < cynthiacoleman843756@ru.irzum.com> 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@rockenhaus.com> 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@lunorian.is> 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@cni.net> 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@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_countr...
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 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
_______________________________________________ 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
Conrad Rockenhaus dijo [Fri, Aug 31, 2018 at 04:00:30PM -0500]:
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
:-] This got a loud laugh out of me. "Cajones" means "drawers". "Cojones" means "balls" (in Spanish from Spain, we seldom use it in most of America). I am completely with you in sentiment. All of my respect to an exit node operator in Turkey!
participants (12)
-
arisbe -
Conrad Rockenhaus -
Gary -
grarpamp -
Gunnar Wolf -
I -
Matthew Glennon -
Mirimir -
Nathaniel Suchy -
Natus -
Pascal Terjan -
Ralph Seichter