Suspicion based on personal experience. Have not verified exact behavior. Some of these might be worth considering, to mitigate this. - allow registered users over Tor, but do not allow new registrations - allow all users through Tor (probably not ideal) - provide hidden service for Tor access, with certain limits - protect users whose IRC nicks are in the phonebook from being autokicked [My IRC nick: StrangeCharm]
We actively have drones that connect using Tor, so when the drones are detected, they are banned (zlined). This sometimes catches other Tor users who are using the same Tor exit nodes as the drones in question. At the same time, my care level for people using Tor is extremely minimal, if any at all. We mask portions of the hostmask and all of the IP address, so your privacy is still in fairly good hands. Not sure it's worth the time/effort to actually support Tor users in the way that other networks such as freenode do.
I'm mostly with reed except for the bit about his care level for tor users ;) All the steps in comment #0 require some sort of patching to either the IRCd or services, neither of which we have time for at the moment. What we could look into is exempting your Nick from being klined, which from what I can see in the unreal docs isn't really possible either, ban exemptions are all based on hostmasks. I'm leaning towards we can't do much here at this point unless someone else has a nicer solution.
Since it seems like a lot of work, perhaps you could put fixing this on the backburner, and come back to it when there's more development time available?
Oh, context: The reason that I'm talking about this category of problem is the exciting world of captive portals and conference wifi which ban VPNs, IRC, and other useful things. Tor's anti-censorship technology is normally more-than-handy to deal with these barbarian access points, but that's no use if my pirate signal is blocked at the IRC server.
Assignee: server-ops → nobody
Component: Server Operations → Server Operations: Projects
OS: Linux → All
QA Contact: shyam → mrz
Hardware: x86_64 → All
Note that the script most often responsible for these gzlines is an irssi script of mine running on one of my machines. It could be modified to avoid a gzline if there's another user connected from that IP and instead use a more specific gline, or something like that. But that'd be more complicated than the current relatively dumb script (which I can't seem to access right now since SSH is busted for some reason).
Assignee: nobody → infra
Component: Server Operations: Projects → Infrastructure: Other
Product: mozilla.org → Infrastructure & Operations
QA Contact: mzeier → jdow
Hi there We don't explicitly prohibit tor users, but, we ban users by IP address. We have no way of distinguishing users who come from the same exit node. If a exit node is indeed banned you can try to force the use of a different node. Please see the 'StrictExitNodes' and 'ExitNodes' directives in your torrc.
Assignee: infra → bhourigan
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
Brian: setting `StrictExitNodes` and `ExitNodes` are generally a bad idea. They make your circuits more distinctive, and give rise to other sorts of problems. Tor generally recommends against using them. Since Tor users share IPs, IP-based band have disproportionate impact on Tor users. Many other IRC networks use more nuanced logic to reduce this impact. In particular grey-listing an IP, so that users coming from there have to authenticate with an existing account before messaging or joining channels, (and get disconnected after a short period if they don't) is a practice which balances spam-protection with accessibility over Tor.
:StrangeCharm I totally agree that the use of those parameters isn't ideal. Unfortunately we don't have any grey-listing ability today but we will certainly take it into consideration when we upgrade/re-architect our IRC network.
You need to log in before you can comment on or make changes to this bug.