Wikipedia talk:Blocking policy/Tor nodes

Tor nodes

I currently have a list of Tor exit nodes, amassing about 24 pages in Microsoft Word at the moment. I am prepared to parse through this list and use a script to hardblock these IPs such that the TOR nodes will be rendered useless on the English Wikipedia. Should I proceed, and if so, how long should the blocks be?—Ryūlóng (竜龍) 02:49, 8 January 2008 (UTC)

How complicated would it be to check back, and see if the IPs are still Tor exit nodes? <eleland/talkedits> 02:50, 8 January 2008 (UTC)

I don't know. Presumably, once the blocks are in fact done, a review of my block log of the IPs in question will show what the IPs are, and (if the MediaWiki page does not change), the "TOR check" link should work. For example, I randomly checked an IP on the list, and found that it is currently not an exit node, and I will be removing it from the list.—Ryūlóng (竜龍) 02:58, 8 January 2008 (UTC)

I've done that by hand before. I'm glad someone is using a script to do it.

TOR exit nodes are open proxies, and can be fully blocked (both anon and logged-in) indefinitely. Raul654 (talk) 02:51, 8 January 2008 (UTC)

Raul. Short blocks for static IP's, a year an length. Nothing INDEF because IP's will change, static and dynamic. And no more than a month or so for Dynamics, they will change surely. This makes the most technical sense IMHO. M-ercury at 02:52, January 8, 2008

I usually block open proxies for 5 years at the most. Less in the case of proxies that were not intended to be open. Mr.Z-man 02:59, 8 January 2008 (UTC)

Didn't someone previously report that most Tor exit node IPs ceased to be exit nodes after 6 months or so, hence very long-term blocking was counter productive. Unless someone has a comprehensive program to review exit node blocks over time, it makes sense to set a not-too-distant expiration time. Dragons flight (talk) 03:14, 8 January 2008 (UTC)

According to w:nl:Gebruiker:RonaldB/Open proxy fighting (see User:RonaldBot), the average lifetime of a Tor node is around one week. I have seen other studies with similar results. -- zzuuzz ^(talk) 03:23, 8 January 2008 (UTC)

The vast majority of Tor nodes are no longer Tor nodes after just a few days. Some are even Tor nodes for a month or two. The proportion which remain Tor nodes for more than a year is absolutely minimal. If you intend running a blocking script, please keep the blocks short and also continue to run a matching unblocking script. -- zzuuzz ^(talk) 03:06, 8 January 2008 (UTC)

Agree here, "Once a tor, always a tor" is not correct. Anyone can download a tor script, and run it on almost any platform. Get bored, and uninstall it. IP's will also shift, especially true for dynamic IP's. Let us be wise when we do this. Short blocks, and do rechecking, if you must block. M-ercury at 03:10, January 8, 2008

• Pre-emptively blocking is a pretty bad idea. --jpgordon^∇∆∇∆ 03:08, 8 January 2008 (UTC)
  • Agree M-ercury at 03:10, January 8, 2008
    • Who said it was pre-emptive? Tor has been used by all sorts of bad editors. Raul654 (talk) 03:14, 8 January 2008 (UTC)

Pre emptive would be loading all 2500 IP's from the master list and blocking them en mass. We can not ignore the above comments regarding how long a node is really a node. Let us think technically about this and block accordingly if we block. Respectfully, M-ercury at 03:18, January 8, 2008

1300 IPs.—Ryūlóng (竜龍) 03:32, 8 January 2008 (UTC)

Thank you :) It is variable. Regards, M-ercury at 03:41, January 8, 2008

No, pre-emptive would be blocking TOR before it was ever used for vandalism. That time has long since passed. It is a very well established network for vandals. The fact that the exit nodes change often simple means that when we block the master list often - preferably using a script. As for unblocking, if someone wants to automate that too, fine, but I'm not going to lose any sleep over the possibility that someone might run a TOR exit node, get his IP blocked, and then want to edit later. Raul654 (talk) 03:22, 8 January 2008 (UTC)

You can automate the block, and block the master list often. Set the block for a week, and re run the master every week. That is fine. But what about the possibility that someone might run a TOR exit node, get his IP blocked, then the dynamic IP is reassigned. Multiply that by one third to one half (sometimes three QTRS) of the master list. This will not work. Regards, M-ercury at 03:24, January 8, 2008

Is there any way to mark the dynamic IPs and soft block them? If it were run weekly and dynamic IPs were soft blocked, the potential for collateral damage is limited. --B (talk) 03:51, 8 January 2008 (UTC)

Usual would be a 5 year hardblock. If you wind up updating it frequently, that would be even better. Dynamic IPs must be dealt with in some way. Prodego ^talk 03:55, 8 January 2008 (UTC)

Any idea how many times a dynamic is reassigned in a five year period? This is far too long for dynamic. As for updating frequently, could you clarify? Regards, M-ercury at 04:00, January 8, 2008

If someone's willing to go through the list I have and find the dynamic IPs, I'll gladly remove them from the list and make a second one.—Ryūlóng (竜龍) 04:03, 8 January 2008 (UTC)

All IPs are dynamic, it's just a question of timing. All Tor nodes should also be considered dynamic, since most of the static IP Tor nodes will no longer be Tor nodes by the time most of the dynamic IPs have changed hands. I'd like to ask you to come back in a week and tell us how many of the IPs in your list are still exit nodes. I'll bet it is down 10% today alone (For an illustration of the problem please take a look at today's WP:OP page[1] - probably all of these IPs were running Tor within the last few weeks, now less than half are). Leaving aside the question of whether it is even a good idea, it is ineffective to run a one-off script to block all current IPs running exit nodes. Whatever process being used needs to be regularly synchronised to the Tor directory to have any effect, and to prevent enormous collateral. But then I don't really think that's such a good idea either. -- zzuuzz ^(talk) 05:11, 8 January 2008 (UTC)

Could y'all take this discussion over to a policy page, perhaps Wikipedia:Blocking/TOR nodes where you can work out a plan, or edit war, or whatever? This question gets asked so often, isn't it about time we figured out a standard answer and saved it? Jehochman ^Talk 04:16, 8 January 2008 (UTC)

Jehochman, your statement was appeared out of line and read of bad faith (edit warring?). Please be more careful and contribute constructively. Thanks, M-ercury at 04:18, January 8, 2008

I want to know if someone goes over all these blocked tor nodes and open proxies to see if they are indeed still such. 1 != 2 04:56, 8 January 2008 (UTC)

Well, none of the list is blocked, yet.—Ryūlóng (竜龍) 05:16, 8 January 2008 (UTC)

If we do go ahead and block them all, perhaps we should allow account creation to minimize unintended consequences. Bovlb (talk) 05:21, 8 January 2008 (UTC)

ABSOLUTELY NOT. That would defeat the purpose of account-creation blocking IPs from known sockpuppetteers to deplete their supply of sockpuppets. Raul654 (talk) 05:28, 8 January 2008 (UTC)

Feh. Hardblock, 3 to 6 months minimum. I have periodically run through the list, blocking all that were not already blocked (by hand, unfortunately) and after a year of doing so have been contacted by maybe 5 IPs asking to be unblocked. After verifying, I always due. By the way, this came up out of a checkuser that was run for me. The number of vandals and sleepers was quite large, all using tor. If we are serious about stopping vandalism (as opposed to getting barnstars for reverting it) we will block all tor exit nodes we find. The harm to the encyclopedia will be much less from a few inconveniently blocked IPs than from the vandalism and sleeper socks. Thatcher 05:59, 8 January 2008 (UTC)

Hardblock up to six months or so. Under no circumstances softblock. Better would be to use a bot that checks the Tor status once per day and does the blocking / unblocking automatically. Kusma (talk) 08:47, 8 January 2008 (UTC)

A few things need to be kept in mind when mass/auto-blocking Tor:

• The Tor directory is not authoritative on which address traffic will exit from - traffic is allowed to exit from a completely separate address than the one advertised in the directory.
• Some Tor node operators explicitly set their exit policies to disallow exiting traffic to WP by blocking access to Wikimedia's IP range, so that local users who share the same IP locally can still edit WP without collateral damage.
• And of course, the problem of dynamic IPs. Some Tor nodes always operate from a consistent address and can safely be blocked for a long period of time; some, however, are dynamic and jump all over the place, and each IP will probably get reassigned to another customer at any time.

If a block-bot were to operate, it should preferably be robust enough to handle these cases (it is possible, however). krimpet✽ 09:13, 8 January 2008 (UTC)

If a blockbot were to do all that and periodically unblock IPs which are no longer Tor exit nodes, would that allay some concerns? east.718 at 11:35, January 8, 2008

If a similar process can check for unblocking, why not block indefinitely? No matter what length we choose, we have to check for unblocking anyway because some only last a few days. If we don't block indefinitely, then we have to check for re-blocking as well (in the case of static IPs). —Wknight94 (talk) 12:51, 8 January 2008 (UTC)

Indefinate it a block and forget mentality. Too much risk for collateral damage. M-ercury at 13:05, January 8, 2008

I think that would be fine. Ideally, a block bot would load a master list and block for a week, then reload and block every week and so on. Please mind Krimpet's words as far as the TOR Node Authority and or directory reporting things other than what is actual. Regards, M-ercury at 13:05, January 8, 2008

I will say this again since Mercury, not appreciating my sense of humor, dismissed my request. Please reduce this discussion to a written process and save it somewhere so we can reference this information in the future. For a long time we have been getting conflicting instructions on how to handle TOR nodes. Repeating the same arguments over and over again is unproductive. Jehochman ^Talk 13:09, 8 January 2008 (UTC)

I favor blocking for a long time, and unblocking when proven that they are no longer TOR nodes. If we can write a script to block and place them in a category, we can also write another script to periodically check all IPs in the TOR node category and unblock those that are no longer TOR. The idea of repeatedly blocking for a week is silly. Jehochman ^Talk 13:13, 8 January 2008 (UTC)

It is difficult to assume a sense of humor, and good faith, when you attack other ideas as silly. Please rephrase.

Sense of humor is sometimes not conveyed properly here with a text only environment. With regards to your proposal, would you like to take the lead, then we can cross post to ANI, VPP, VPT, T:CENT, and Wiken-L. Regards, M-ercury at 13:16, January 8, 2008

If you're willing to run your script regularly, surely it would make most sense to block indefinitely when identified as a Tor exit node, with a good clear message as discussed below, and then unblock when a future run of the script identifies that the IP address is no longer running Tor? --Stormie (talk) 02:54, 9 January 2008 (UTC)

I do not see any good reason to pre-emptively block tor nodes. Block ip addresses that cause problems. Block users that cause problems. Avoid paranoia. --Blue Tie (talk) 13:23, 8 January 2008 (UTC)

I'd suggest using the list as a checklist for checkusers to investigate and block as abuse is found - David Gerard (talk) 13:31, 8 January 2008 (UTC)

Respectfully, preemptive checkuser on the TOR list is not a good idea. We don't do things this way. Remember the policy states"While this may affect legitimate users, they are not the intended targets and may freely use proxies until those are blocked". M-ercury at 13:35, January 8, 2008

Of course. However, while pursuing a vandal last night with the help of a checkuser we found a bunch of tor nodes, some of which had been blocked as such months ago but were still active. We uncovered some suspicious-looking possible sleeper accounts, at least one admin, and some vandals and trolls. (I intend to keep the names of the suspicious accounts private until and unless they show up on ANI or something.) It is certainly not the case that all, or even most, tor nodes are short-lived. Thatcher 16:28, 8 January 2008 (UTC)

I would definitely support pre-emptive blocking (for a period of three months or so) of any Tor nodes. Fnagaton 16:11, 8 January 2008 (UTC)

Does anyone keep any data on how many vandals use Tor exit nodes? (e.g. if tomorrow we were forbidden to block Tor exit nodes how large would the problem be?). Do only checkusers have this kind of info? EdJohnston (talk) 22:18, 8 January 2008 (UTC)

Propose policy change

With the data located at this place and the above technical data, and comments, I propose we limit TOR node blocking to one week. The rationale being, if the average span of a node is one week, but we keep blocking nodes, and the master directory with indef, the affected foot print will grow larger and larger. Thanks, M-ercury at 13:29, January 8, 2008

In my experience, this is a bad idea. I see them stay active as TOR nodes for ages. When I checkuser TOR nodes, I typically see abusers on them going back months - David Gerard (talk) 13:31, 8 January 2008 (UTC)

Is there any good data you can redact and show us to counter the proposed change to policy? M-ercury at 13:48, January 8, 2008

I also think this is not a good idea (though admins are welcome to do it, some do already). We should definitely reduce the number of indef-blocks, unless the IP has a long history of being Tor (most of the long term exit nodes are indef-blocked, normally by checkusers). I tend to block for a year to make sure, though 6 months is a reasonable option which I'm leaning towards based on experience, and a month would also be quite reasonable. Initial blocks shouldn't really be any longer than a year. It's really the insta-indef blocks and multi-year blocks that are the problem. -- zzuuzz ^(talk) 13:47, 8 January 2008 (UTC)

I think I could go with a year, as a max. M-ercury at 13:48, January 8, 2008

Once again, nobody but you actually supports this. Raul654 (talk) 15:19, 8 January 2008 (UTC)

Are you saying that I'm all alone? Raul, look around, there is enough support for a non -indef solution to warrent a discussion and a plan. Please be helpful in this discussion. Let us not personalize this. Regards, M-ercury at 18:01, January 8, 2008

Since the list of TOR nodes are published why can't they be blocked, but monitored by a bot to see if they are still being used as such. A bot can report when it is no longer a node. I ran a TOR node once, so that people in China and other places can use the internet, if I found out that got me booted from WP I would probably shut it down, but then how long would I wait? If we just block and forget then we end up with a long list of blocked IPs that are not proxies. 1 != 2 17:05, 8 January 2008 (UTC)

I thought the plan was to block indef but still check all of them on a regular basis and unblock the ones that are no longer exit nodes. If we block for a week and a Tor node is operating for a year, all we're going to do is block the same IP 52 times. If we block indef and its only an exit node for a week, we unblock after a week; if its an exit node for a year, we unblock after a year. If a script checks all the current blocks when it runs, there is no reason to use such short blocks. Mr.Z-man 20:58, 8 January 2008 (UTC)

• TOR nodes could be allowed, but anon-only, account creation blocked for a set period and not indefinitely - with people having to request an account via the unblock-en-l mailing list if they wish to edit?? Fair suggestion?? Thanks, --Solumeiras ^talk 21:54, 9 January 2008 (UTC)

Template suggestion

Template:Torblock

(Do we have a page with instructions for exit node operators to disable editing wikipedia?) —Random832 14:32, 8 January 2008 (UTC)

Most exit node operators have probably never heard of Wikipedia. This template basically duplicates information which is already in {{tor}}, specifically the link to Wikipedia:Open_proxies and m:WikiProject on open proxies/Help:blocked, though I accept the linked help instructions need to be improved. -- zzuuzz ^(talk) 14:40, 8 January 2008 (UTC)

In addition to below:

When pre-emptively blocking via the bot on nl:w, I don't place templates on the talk page. Instead I provide a clickable link in the remark/comment line, that refers to a page telling the user why this IP has been blocked. I.e. this one for TOR. - Rgds RonaldB-nl (talk) 14:42, 8 January 2008 (UTC)

So you know, a template placed in the comment line will appear fully expanded when the user attempts to edit. There are a number of templates on en.wiki specifically for this purpose. —Random832 14:50, 8 January 2008 (UTC)

Them not having heard of wikipedia isn't a problem; they'll only see the template if they attempt to edit wikipedia. And those who don't care about editing wikipedia (and thus won't do this) can stay blocked. And the reason for duplicating this information is that if this is on their talk page and (ideally) the block summary, they're more likely to see it. —Random832 14:49, 8 January 2008 (UTC)

What I was saying is that the number of exit node operators who try to edit is probably miniscule. The template {{tor}} already serves the purpose you mentioned. I use it as the block reason (it's already in the dropdown), and on the talk page. -- zzuuzz ^(talk) 15:04, 8 January 2008 (UTC)

Blocking policy applied at nl:w

I keep a list of a.o. TOR exit nodes in a database containing also date info, such as date acquired, date lastconfirmed. That db is updated daily (if I'm not on holidays).

Analysis of the entries has learned me the following: There are long living TOR exit nodes, short(er) and very short living ones. Apparently people are trying, so the IP appears for a while in the reporting and others run consistently an exit node.

Since I learned that, I apply the following blocking policy on nl:w (and on invitation the same on he:w):

• Hard block if the IP appears for more than 2 days in the list. That allows people to experiment with TOR without being blocked immediately
• Unblock if the blocked IP does not appear as exit node anymore for a period of two months.
• If an IP that has been unblocked earlier and appears again as exit node, then it is blocked again (btw SQL recently fixed).

Due to the statistical nature of TOR that seems adequate as can be seen from this.

The automated batch process is run 1-2 times per week. The result is that at any moment in time approximately 3000 IP's are blocked. See the current list of blocked TOR exit nodes and view the history to get a feel for the dynamics.

Btw: I'm observing that the TOR network is rapidly growing. It has more than doubled in size in a year, from some 1200 to more than 2500 nodes (all, i.e. onion and exit nodes together).

A similar blocking policy is applied for so called exit nodes, i.e. the end-node of a cascade of ordinary open proxies. Those exit-nodes are generally used by multiple open proxies as can be found on the internet and hence behave more or less similar as TOR. These can only be found by scanning, i.e finding confirmation whether a published IP is indeed an open proxy or not. That's what I'm doing 7/24.

A third category that is pre-emptively blocked are the IP's used by anonymizers. Although proxy.org publishes some IP's, my scanner finds more IP's. For the time being IP's found this way are indefinitely blocked, as they appear to be predominantly IP's used by hosting providers.

Rgds RonaldB-nl (talk) 14:33, 8 January 2008 (UTC)

That seems utterly sensible. I don't run bots myself but hopefully one of the concerned admins who posted above will bring your system online here. Thatcher 16:24, 8 January 2008 (UTC)

As a member of WP:BAG I request that you file a WP:BRFA but dont file a WP:RFA. Since I know that this will bring every wacko that uses tor out against you, I am going to see if I can just get a B-crat to do this. β^_command 16:57, 8 January 2008 (UTC)

See here for an earlier approved bot-status. Is currently taking care of Wikipedia:Open proxy detection. - RonaldB-nl (talk) 17:48, 8 January 2008 (UTC)

Id like another BRFA for automatic blocking/unblocking. β^_command 18:05, 8 January 2008 (UTC)

Why bother? The community is going to stomp on it just like every other adminbot. east.718 at 22:57, January 8, 2008

I suppose I should make a comment here but I find it all very depressing. There are some pages on wikipedia I can only load using Tor, and I'm not in mainland China or anything. I suspect the Tor fighters all have very nice, expensive internet connections. I'm not expecting the group think to move, but you would have thought from reading WP that Tor had no benefits whatsoever. I presume from one of the comments above that if I connect via Tor I'll be accused of being some loser's sockpuppet. Sometimes I really wish a lousy internet connection on some of you people.. Secretlondon (talk) 01:21, 9 January 2008 (UTC)

Also please note that we are not preventing TOR users from reading wikipedia. All that we are doing is preventing them from editing not reading. β^_command 02:24, 9 January 2008 (UTC)

As a bureaucrat, the blocks on the nodes will not affect you whatsoever, but I understand the issue that you raise.—Ryūlóng (竜龍) 02:09, 9 January 2008 (UTC)

I don't: what pages exist that can only be edited using Tor for some users? Why? Kusma (talk) 09:43, 9 January 2008 (UTC)

I would assume in Secretlondon's case, some of the pages that take longer times to load would be an issue for users with poor internet connections. However, I understood that the blocks may harm people who require Tor to access Wikipedia (it is the primary reason that they all haven't been blocked in the past).—Ryūlóng (竜龍) 11:06, 9 January 2008 (UTC)

How is the issue of editing pages through Tor connected to poor internet connections? Kusma (talk) 13:11, 10 January 2008 (UTC)

Tor can help with DNS issues, because the hostname is resolved by the Tor server (via SOCKS 4a) instead of the user's normal ISP. It's not a very effective solution, but it can help a lot with flaky ISP DNS servers. -- zzuuzz ^(talk) 13:54, 10 January 2008 (UTC)

I agree with something like the NL solution, although I'd go with unblocking after they've been a non-exit node for less time than two months, personally. Also, I would suggest that account-holders be allowed to edit throughout the block; account creation I am ambivalent about. Also also, there is the issue of Tor nodes which disable editing of Wikipedia, which are safe for us. I should note that I consider an NL-like solution to actually be a valid use of indefinite blocks (since the time interval required is indefinite) that doesn't equate to "permanent". I could help with writing a bot for this if needed, although I doubt that's the real bottleneck here.

Whatever solution we come up with and agree on, I also agree with the sentiment that we can't let good editors from China and other places get hurt by it. If we can at least have a link to Wikipedia:Advice to users using Tor to bypass the Great Firewall when notifying users about being blocked due to Tor, that might help them a little. As User:Gmaxwell rightly points out, we aren't overrun with vandals coming through Tor, and User:rspeer is likewise correct that we should try to accomodate these disadvantaged users. The advice on the above-linked projectspace page seems to provide Chinese users with a workable, if complex, way of getting in and doing some good editing. So, it seems like the main problems with vandals are anonymous (IP) editing and the capcaity to mass-create accounts? Let's make those the restrictions on Tor proxies, then, and any vandal accounts that slip through regardless can be dealt with in the usual manner. Failing that, the Wikipedia:IP block exemption proposal would achieve basically the same effect, yes? All that would be necessary to add to the "Great Firewall" advice is that the person getting your account setup for you needs to request that hardblock exemption flag also, I guess.

I'm starting to ramble a bit now, so I'll shut up. :-)

--_{tiny plastic} Grey Knight ⊖ 13:09, 25 January 2008 (UTC)

Options

There have been a few suggestions as far as timed blocking, and a few suggestions for a bot. I encourage the bot maker to go ahead and do the appropriate approval request. That would be great.

As far as timed blocks, there appear to be more suggestions for that as opposed to indef blocking without the bot. Lets throw some times out there and see if we can come to a consensus. Any ideas? M-ercury at 23:14, January 8, 2008

Flat out question

In the next 24 hours, I plan on running the script I have on the list of Tor exit nodes. My plan of attack is as follows:

• Hard block (anon only off)
• Block length: Five years
• Block reason: {{tor}}

Honestly, if the IPs are no longer Tor nodes, then we can expect a handful of {{unblock|This is not a Tor node. Please unblock this IP.}} showing up. This seems to be the simplest option, instead of programing a bot to check for exit nodes or blocking this list every week or every month.

Should I go through? Should the blocks be longer? Should the template be different?—Ryūlóng (竜龍) 02:21, 9 January 2008 (UTC)

Where is your data source for the nodes? M-ercury at 02:24, January 9, 2008

I have Proxy.org's list of exit nodes.—Ryūlóng (竜龍) 02:29, 9 January 2008 (UTC)

Why don't you get them directly from the up to date directory? M-ercury at 02:43, January 9, 2008

Meaning?—Ryūlóng (竜龍) 02:54, 9 January 2008 (UTC)

The TOR authoritative directory server has the most up to date tor exit node information for the tor clients to use. Why not use the data they are publishing. If we are blocking based on a list, then it needs to be from TOR, and not from a third party. M-ercury at 03:03, January 9, 2008

I do not know where this data is. The list I have is the only list I have found that was easy to copy and paste.—Ryūlóng (竜龍) 03:20, 9 January 2008 (UTC)

It is easy to find, should start at this place for how tor works, and it should lead you to finding the authoritative directory. I am questioning the reliability of your data. There is no consensus here for your method however, and I urge you not to do this thing, at least until a consensus is generated. M-ercury at 03:32, January 9, 2008

This one [2], and this one [3] both give 1092 IPs --Stephen 04:57, 9 January 2008 (UTC)

The last time this was discussed (with a lot more participants, I note), at WT:NOP, there was about a dead-even split between whether hardblocks or softblocks should be applied to TOR nodes, let alone whether preemptive blocking should occur. I do not agree to this change without resolution of that question, there seemed at that point no consensus that hardblocks should be applied to nodes not being currently and actively used for vandalism at all. The best resolution, perhaps, would be to see ipblock-exempt as a permission that admins or crats could grant to regular users, but until that happens, I do not support preemptive blocking of all TOR nodes. This needs a bot approval and a real RfA if it is to go forward, with full explanation of what it is intended to do. This will not go through the back door. Seraphimblade ^{Talk to me} 07:16, 9 January 2008 (UTC)

What bot would be necessary? There is already a script that had been written for these circumstances (similar, but not exactly the same) that I have used in the past when I found lists of open proxies, and have been used in the past by other users. There is no preemptive blocking, as we know that there have been exit nodes that were abused. Is there a reason to not block Tor because it's preemptive or because there are individuals who use it in good faith?—Ryūlóng (竜龍)

Also, this was not originally going to be a "back door" thing as you accuse it. I had posted this on WP:AN until it was moved here and the conversation continued without having been contacted.—Ryūlóng (竜龍) 07:33, 9 January 2008 (UTC)

No. I would also urge you not to do this. I would suggest that you spend a little time learning something about the Tor directory - it's one of the most dynamic and short-lived lists of open proxies on the Internet. Just take a look at the data here, and notice the uptime. These are a completely different thing from web-hosted proxies. The idea that we should block a shed-load of dynamic IPs for five years and wait for unblock appeals is not what we do here. I also echo some of Seraphimblade's concerns - although I disagree completely about using softblocks, I do agree that there is no consensus for a total ban of any use of Tor to edit. I would go further and say that such an idea has been soundly rejected. Any blocking bot should also get community approval as it would be a fundamental shift in policy. There's no big 24 hour rush here, we can afford to consider the best way forward, not the simplest to script. -- zzuuzz ^(talk) 10:15, 9 January 2008 (UTC)

This is like jailing the Japanese in the US during World War II. Not that they did anything wrong... but hey, they look funny and they MIGHT do something bad. And then I see, above, that someone wants to do it though a process that avoids community review and consensus, even though wikipedia supposedly runs by consensus. This whole thing is just a really bad idea in principle. --Blue Tie (talk) 10:32, 9 January 2008 (UTC)

That is in my opinion a really poor analogy. Tor nodes have been abused in the past. Open proxies have been abused in the past. If abuse can be prevented, why not do it? The only reason that these blocks may be harmful is to the Chinese who require Tor to edit. I was seeking consensus here (or rather, in my initial posting at WP:AN). Right now its split on "how long?" and "how should it be checked?" I've submitted the list I had to another administrator, and another administrator will be supplying me with a list of static exit nodes to work with. There is also nothing to suggest that the list of IPs I have are all dynamic IPs. All the list contains are exit nodes, prepared to go through a script that was written explicitly for this purpose (blocking several IPs for being open proxies). I can see now that there is a slim chance that anyone would be given any go ahead. I just have everything prepared, and in the end, the task would more than likely be delegated to several users (at the default setting in the script the blocks would take more than two hours to complete). I have run this script in the past on lists of open proxies, and there have only been a few issues that I later corrected after correspondence with the users affected.—Ryūlóng (竜龍) 11:04, 9 January 2008 (UTC)

Poor analogy? Let's see. Tor nodes have been abused in the past. Pearl Harbor was bombed in the past. Open proxies have been abused in the past. American Freedom has been abused in the past by Japanese spies. If abuse can be prevented why not do it? If Japanese evil can be prevented by locking them all up, why not do it?

Yep, hard to see any way that the thinking is similar. --Blue Tie (talk) 11:14, 9 January 2008 (UTC)

I would like to point out Ryulong, that you have indefinitely blocked two Tor nodes in the last two days - 219.112.19.106 (talk · contribs · block log) and 217.80.223.164 (talk · contribs · block log). Please now check them again. Neither of these IPs is running Tor any more. With the ability to block comes the responsibility not to block unnecessarily. -- zzuuzz ^(talk) 16:51, 9 January 2008 (UTC)

Both of those IPs were Tor nodes at the time and were being abused (their edits show that). I get it now, and I don't give a damn about my plans anymore. If you want to still do this, fine. I'm going to delete the list from my personal files. If Wikipedia doesn't want to prevent abuse, then so be it.—Ryūlóng (竜龍) 22:21, 9 January 2008 (UTC)

Since Tor uses both hosted servers on static IPs and personal routers on dynamic IPs, a bot that runs regularly (every 24h or week) would be better than a script run on a "whenever I feel like it" basis. A bot could issue indef blocks to all Tor nodes it finds, but check all current blocks when it runs so that IPs that are no longer Tor nodes can be unblocked. Mr.Z-man 21:14, 9 January 2008 (UTC)

As I've described here, the approach I've adopted takes care of dynamic IP's (as well as trial exit nodes). Before I implemented this refinement, we have got one complaint on OTRS-nl regarding an IP which had been used as exit node, but since then as an onion node only (which I could verify). Since then zero.

Be careful with defining what the most authorative list is. If the one I'm using is down/stuck for a couple of days, which I've noticed twice or three times in a year time, all other lists I've found on the internet are frozen as well. If that happens I start my scanner to acquire new exit nodes, but I must admit that this is a cumbersome and time consuming process. - RonaldB-nl (talk) 01:05, 10 January 2008 (UTC)

I think your approach is the most sensible. -- lucasbfr ^talk 13:04, 10 January 2008 (UTC)

First do no harm

My suggestions:

1. Any initiative to start blocking many IPs based on a list of Tor nodes should be start with a pilot project blocking perhaps just 50 to 100 IPs until we know more about what we're doing.
2. Tor nodes don't vandalise, vandals vandalise. There are many legitimate reasons to be using Tor. In investigating certain really bad sites for WP:SPAM, I've used Tor for an extra layer of anonymity.
3. The person running a script, a bot, or doing this by hand must commit to checking the list every two days and unblocking all inactive nodes.
4. The checking, blocking and subsequent rechecking and unblocking all needs to be logged on some centralized pages so the community can review how the experiment is running.
5. Editors with accounts should still be able to edit through these nodes pending broader community consensus on editing through Tor nodes.
6. Once we have some experience, then we can decide whether to expand this initiative to all Tor nodes.

--A. B. ^(talk) 03:49, 10 January 2008 (UTC)

New to the discussion but I agree with point 5 above. Users with an account shouldn't be blocked from editing through a tor node, just like with blocked IPs. However, account creation should be blocked. Think outside the box 13:47, 10 January 2008 (UTC)

Sounds fine to me. But I'm new to the discussion too. --Puchiko (Talk-email) 19:20, 11 January 2008 (UTC)

Per #2, remember that blocking doesn't prohibit you from reading pages, just editing. Per #5, blocking anon only would not work for a few reasons, but I've yet to see much opposition to creating an ip-block-exempt usergroup (to allow users to edit from a blocked IP address) so I can't imagine that getting consensus for that would be hard. (Harder would be convincing a sysadmin to do the change after the drama from the rollback group) Mr.Z-man 21:13, 11 January 2008 (UTC)

"Want to move the world, first move yourself." If Wikipedia wants there to be human rights (which isn't clear from its core principles), let Wikipedia establish it on their own site before worrying about aiding in breaking the law in foreign governments, even if such governments are corrupt. Zenwhat (talk) 23:04, 12 January 2008 (UTC)

I agree that we need to be cautious in implementing something like this. Any process that is implemented should be sure not to block Tor nodes that have disabled editing Wikipedia. We've heard before from people who edit Wikipedia (because they're interested in giving the world access to knowledge) and run a Tor node (because they're interested in giving the world access to knowledge); we should not punish these people for their consistency, especially if they're responsible enough to make sure that Tor and WP don't mix.

On a larger scale, I think some Wikipedians need to rethink their knee-jerk position on Tor. There's Wikipedia vandalism, and there's large-scale government censorship, and I know which one I'd rather see prevented. rspeer / ɹəədsɹ 10:11, 13 January 2008 (UTC)

"large-scale government censorship" = Red herring fallacy. Fnagaton 11:11, 13 January 2008 (UTC)

I don't see the fallacy. Governments like China's censor the Internet, particularly Wikipedia. Tor works around censorship of the Internet.

If we want to prevent Tor from working around Wikipedia blocks -- which is a much smaller issue than the problem Tor solves -- we should find a way to do it that does not involve blocking all IPs containing Tor exit nodes. Presumably we edit Wikipedia because we want others throughout the world to read it, so we shouldn't fight the tool that allows them to, we should work with it. rspeer / ɹəədsɹ 02:05, 15 January 2008 (UTC)

请问，你们跟华人有什么仇?

请问，你们跟华人有什么仇? —Preceding unsigned comment added by 219.112.19.106 (talk) 09:08, 8 January 2008 (UTC) ==

(free translation: May I ask, what is your problem with/hatred against Chinese people?) Please write in English. This is not about whether people in China should edit here. It is about blocking an easy access to an infinity of sockpuppet accounts. That Internet users in China can only use Tor to read and not to write is collateral damage that seems unavoidable. Kusma (talk) 09:16, 8 January 2008 (UTC)

Of course it's avoidable. Softblock Tor, get faster about blocking disruptive users (whether they're socks or not, then it won't matter, act up a few times and you're gone not to come back.) I think rspeer said it above—when given the choice between "enabling repressive governments" and "enabling Wikipedia vandals and sockpuppeteers", bring on the footwear hordes anyday. Seraphimblade ^{Talk to me} 20:46, 13 January 2008 (UTC)

Uh, no. As someone who has spent more time than anyone else manually recursing through checkuser to block people who register dozens or hundreds of sockpuppets (including about a dozen hours this week tracking down three particularly problem sockpuppeteers - [4][5][6]-- the last thing that should happen is that they are given access to a fresh source of account registration. If I see these TOR nodes come up, I *will* be blocking them indefinitely. Raul654 (talk) 20:56, 13 January 2008 (UTC)

Then you will be going against consensus and subjecting yourself to dispute resolution to include arbitration if RFC does not work. M-ercury at 20:58, January 13, 2008

No, I will not be, because (a) policy still supports blocking them indefinitely, and (b) because desipite all your attempts otherwise (such as trying to change the subject from Ryulong's original question of how to go about blocking them into a referendum of whether or not to do it) the fact remains that you have not achieved consensus, or anything near it, to change policy. Raul654 (talk) 21:01, 13 January 2008 (UTC)

Consensus was achieved here to not block Tor proxy indef, and the blocking policy has been updated to that affect. This discussion was also crossposted to Wiken-L Foundation-l AN VPP VPT and a couple of other places. Dispite your disagreement, we do have consensus here to that affect. Sorry. Regards, M-ercury at 21:05, January 13, 2008

This is Wikipedia, not fantasy land. Claiming consensus does not make it so. Raul654 (talk) 21:07, 13 January 2008 (UTC)

No, fantasy land would be saying something like this when clearly there were supporters to the discussion. M-ercury at 21:10, January 13, 2008

Supporters for what, exactly? This discussion is so confused - mostly due to you, personally - that it difficult to see what you are talking about. You wanted to limit blocks to a week - that idea went down in flames (both David Gerard and Zzzz explicitely spoke out against it). You wanted to limit pre-emption, and Thatcher, myself, etc rejected it. So what exactly are you claiming consensus for, and who supported it? Raul654 (talk) 21:29, 13 January 2008 (UTC)

There is considerable consensus for not indefinitely blocking IP addresses. There has been for a long time. -- zzuuzz ^(talk) 21:32, 13 January 2008 (UTC)

Claiming a lack of consensus does not make it so either. —Random832 21:10, 13 January 2008 (UTC)

If an ip-block-exempt usergroup is ever implemented (not sure what we're still waiting on, local policy perhaps?) or Wikipedia:WikiProject on closed proxies is expanded to aid legitimate users who must use a proxy, this would almost be a non-issue. Mr.Z-man 00:37, 14 January 2008 (UTC)

Raul, when someone says "I'm about to make a bot to perform an action on an unnecessarily large scale that goes against the goals of many Wikipedians", turning the discussion into a referendum on whether to do it is the right thing to do. rspeer / ɹəədsɹ 02:12, 15 January 2008 (UTC)

I've set up and added a proxy at WP:WikiProject on closed proxies. I'm kind of surprised I'm the only one ... Celarnor ^{Talk to me} 16:47, 3 April 2008 (UTC)

Stop the madness! / Technical solutions?

We recently had a rollback debate that over 500 users participated in. Afterward, one of the sysadmin's comments was: how is possible that you can find 500 people to comment on rollback and not a single person to code a compromise solution?

That's the crux of the issue here as well. We're focusing on blocking policy and how to stop all Tor uses. Instead, why can't we focus on possible solutions to the greater issue?

WS: As a follow-up, Raul654 asks, Roger Dingledine, inventor of TOR, has said that if Wikipedia implemented a trust metric, this would effectively solve the problem of proxies. Have you considered adding such a feature?

JW: It is not up to me, but that avenue of approach seems viable. I think we should only soft-block Tor anyway.

Jimmy also made a comment on his blog, vague but simple: here.

I can't write code, but I know that there are tens of developers who are able to. I also know that there are other developers outside of Wikipedia who could help. If we spent half the energy toward a solution that we put toward this blocking policy, we would have an answer.

I'm not trying to say that we should defer to Jimbo, and going even further, I'm making no comment on what blocking policy should be with regards to Tor nodes. Personally, I don't use Tor, so I simply don't care. What I am saying this is: why can't we find a better way, a way that's more in line with our values and the community's values? --MZMcBride (talk) 21:40, 13 January 2008 (UTC)

I'd code something but it would be a system that soft-blocks any IP that appears on a Tor list and only unblocks once the IP is off the Tor list. Fnagaton 22:27, 13 January 2008 (UTC)

Unfortunately softblocks are useless because vandals create accounts. Bugzilla:9862 has been proposed as a solution. -- zzuuzz ^(talk) 22:30, 13 January 2008 (UTC)

What about the trust metric? What is that and how could it be implemented? Or, if the trust metric system isn't the right direction, what about a bot to softblock IPs? (These blocks should be impersonal if done.) --MZMcBride (talk) 00:01, 14 January 2008 (UTC)

FWIW, I've got a list up, updated hourly, of non-blocked tor nodes. User:SQL/Unblocked TOR. SQL^{Query me!} 03:58, 14 January 2008 (UTC)

Btw, those tor nodes don't necessarily *need* blocking. They're all exit nodes (to the best of my ability to figure that out), but, not all allow wiki editing. I meant the list for statistical use only, not as a block-checklist... SQL^{Query me!} 04:11, 14 January 2008 (UTC)

policy proposed

talk page — Preceding unsigned comment added by Mercury (talk • contribs)

A possible trust system

I have been semi-following the discussion here, and while I understand the tor issue, I also understand the problem with hard-blocking the tor exit nodes (the Chinese, registered users ip addresses being not too private, etc.). User:MZMcBride suggested above a trust system as a possible solution. I thought about it, and concluded that it might be a good idea. Here is a possible trust meter system that I thought of:

A user's (anons included) trust is measured as a real number between 0 and infinity. Anons in the same subnet share the same trust meter. Newly registered users start with the trust level of the ip address they register with. Anons start with a trust level of 1. Administrators have a trust level of infinity (or NaN).

A user's trust level changes as follows: for every day of constructive editing a user's trust level increases by 1. A constructive day is a day in which the user edited wikipedia, and did not receive a warning from a more trusted user (possible problem: null edits. possible solution: null edit warnings). If a user is blocked (for any duration), his trust level is cut in half. If the blocked user is a registered user, his ip address trust level is also cut in half (in a similar style as auto-blocks).

In this system, an article being semi-protected would mean that users are required to have trust level of more than 3 (or some other number) in order to edit the article. This (partially) solves the sleeper accounts problem as an account is required to not only be registered for 3 or more days before it can edit semi-protected articles, the account also needs to be used in these days in a positive manner. Another, optional, page-protection method can be "auto-protection", in which articles which are actively edited are auto-protected, requiring users to have a trust level of more than 1 before they can edit the article. Actively edited articles can be defined as articles having more than 4 editors working on them during the past 2 days. Auto-protection makes sense as active articles are more likely to be targeted by sock-puppets and random vandalism. Also collateral damage would be kept to a minimum as an article having 5 or more editors actively edit it is unlikely to need edits from a not-so-trusted editor.

From a technical perspective (as far as I can tell, as I don't know how wikipedia is implemented, and I don't have any real experience developing large scale websites) this system can be implemented by scanning the editors of the past 24 hours every 12 hours, and adding 0.5 trust points to the user if he has edited sometime between [currenttime-24h] and [currenttime-12h] and has not been warned in the past 24 hours (again, only AFAIK).

This system should be most effective when the trust level is mostly hidden from the users (access granted only to administrators, or bureaucrats, or checkusers).

Any comments? Thoughts? Suggestions? Rami R 19:42, 15 January 2008 (UTC)

I don't know that a trust system would work with TOR users, as, nearly every edit (even from the same IP) has the potential to be by a different user. SQL^{Query me!} 20:46, 15 January 2008 (UTC)

Trivial to game. Just edit nicely for a while. Since the metric is so simple you could even have a bot do the work. And if the user's proxy is blocked, then how will they build trust? Use their non-proxy IP? Okay, but it defeats any anonymity purpose of using the proxy. --Gmaxwell (talk) 21:09, 15 January 2008 (UTC)

Also, a "warning" is near impossible to determine technically unless we were to totally redo the warning system by building it into the software. Most template warnings have hidden text which indicates what they are, but a handwritten warning would not and there is no technical difference between a warning edit and any other edit. And like Gmaxwell said, all you would have to do is fix a typo a day for 4 days and you could edit a semi protected article, this would basically be like the current autoconfirm system, but with an edit count restriction of 4 instead of 0. Also, the auto-protection thing is backward IMO. The articles that should be auto-protected, if any, are the obscure articles where vandalism might stick around for days or weeks. Active articles have people watching for vandalism and other abuse and attract more new users to editing Mr.Z-man 02:45, 16 January 2008 (UTC)

Please do not reinvent the wheel

First, make sure you see my comments at Wikipedia_talk:Blocking_exemption_policy#Evidence_that_the_world_won.27t_end.2C_and_a_counter_argument. There I point out that TOR is (mostly) not currently blocked. Any proposal to exempt or allow Tor, if coupled with systematic software driven soft-blocking would almost certantly reduce vandalism from Tor. That Tor is not effectively blocked and yet we live is an important perspective.

I'm seeing all these ideas for allowing proxies.. Trust metrics, approval systems, etc... But there is already a good (and cryptographically strong) solution which should meet our goals (block bad guys, avoid one person having a zillion accounts but only one IP) without excessively compromising the pseudonomity of proxy using editors: See User:Lunkwill/nym. --Gmaxwell (talk) 21:09, 15 January 2008 (UTC)

Soft-blocking is useless for TOR nodes, as has been shown time and again. I'm astonished to see people still suggesting soft-blocking proxies. Policy is to hard block, period. Jayjg ^(talk) 03:40, 17 January 2008 (UTC)

I'm not very familiar with the topic, so I'd be glad to see evidence of soft-blocking being useless for most TOR nodes.
Everyone here knows the policy, and it's why they want to change it (if it had clear consensus we wouldn't be discussing it here). This is Wikipedia, you don't just say "This is policy. Period". You evaluate the policy, and see if it makes sense, and if it helps the ultimate goal (build a free encyclopedia). If it doesn't you change it or ignore it-depending on the situation. Puchiko (Talk-email) 21:30, 1 March 2008 (UTC)

A solution

Why don't reduce the life of blocks and create a Special:Recentchanges/TOR page for patrolling that edits? --Emijrp (talk) 22:08, 1 February 2008 (UTC)

We aim to limit the block length to the length of time the proxy is open, and there's a reason the blocks are not shorter. We can monitor the Tor recent changes at Wikipedia:Open proxy detection. People using Tor will usually change IP address every few minutes (or faster), which means by the time they have been blocked (or unblocked) they have a new IP address. Blocking a single IP address used for vandalism or sockpuppetry simply doesn't work - it's completely punitive and not preventative. The prevention happens by limiting the number of IP addresses the vandals can use, whether that be through blocking them all with a bot, or just blocking the ones we happen to notice. To reduce the vandalism for Tor you don't need to block them faster after they have vandalised by watching the recent changes, instead you need to block more of them from editing in the first place. Unfortunately, the more you block, the more legitimate editors are affected. -- zzuuzz ^(talk) 22:39, 1 February 2008 (UTC)

Blocking indiscriminately

By proposing a total TOR block you are potentially aiding countries in denying their citizens uncensored internet access, this seems like a backwards step. Perhaps rather than auto blocking the node any TOR proxy requires them to register and then monitors their edits, perhaps flagging them up if they start editing lots of documents quickly or re-editing a lot with a similar checksum Silent52 (talk) 03:22, 27 February 2008 (UTC)

I think it's a terrible idea to indiscriminately block what is effectively the last way for Wikipedians to evade censorship and ensure pviacy. Even now, if an established editor uses TOR as a proxy and for whatever reason they get a checkuser run on them, other editors see that as a red flag. For Wikipedians who value both their privacy and their anonymity on the internet, this is a very bad thing. We should be going in completely the other direction, trying to find ways to help editors use proxies. Celarnor ^{Talk to me} 06:53, 3 April 2008 (UTC)

I think we should not do anything indiscriminately when we have chosen our admins for their discretion. _(1 == 2)^Until 13:46, 3 April 2008 (UTC)

Is this done/over?

With Wikipedia:IP block exemption now policy (and presuming that it's been implemented by developers), is the discussion on this page now concluded? Or is there something further to discuss? (For example, there doesn't seem to be a consensus about standardising length of such blocks.) - jc37 18:24, 18 April 2008 (UTC)

There are two related issues on this page: preventing vandalism from Tor while allowing constructive edits, and avoiding collateral from Tor blocks when the IP is no longer Tor. IP block exemption will not help with the latter. If I can boldly summarise the consensus: Tor blocks should not extend beyond the life of the Tor node. In many cases it is only a few days, because IPs can be dynamically reassigned and Tor is a program which can be (and often is) closed down after testing it. In a few cases they can be open for years. Because the lifetime of Tor nodes is variable there cannot be standardisation in block lengths, but initial blocks under a year will suffice in the overwhelming majority of cases.

Additionally, the issue of whether to systematically and/or automatically block every Tor IP has no consensus, and may need to be revisited after the implementation of IP block exemption or quite possibly m:Global blocking. -- zzuuzz ^(talk) 10:18, 19 April 2008 (UTC)

Looks like a good enough summary to me. So we should probably archive the page as "done". (And possibly note the "result" somewhere.) - jc37 18:28, 19 April 2008 (UTC)

Can be done with a simple shell request

This can be done using MediaWiki's support for DNS blacklists. It is silly to block all of them at once when we can just use a DNS blacklist for the purpose, which will automatically update. This is a two-line shell request. — Werdna talk 03:49, 22 April 2008 (UTC)

This is not over.

I completely disagree with everything. I have run a Tor node a few times, once for a week and the other times for a few days. I would dare to step out on a limb and suggest this to be perhaps typical of casual users or those simply wanting to give it a test run. I was surprised to find myself blocked from Wikipedia because of this. After reading the rationale, I am almost disgusted. I understand the need to protect WP against vandalism, but this is practically a witch hunt against everyone who is running Tor.

With terminology used in this discussion such as "plan of attack", you are clearly taking an offensive that yields considerable collateral damage by blocking all Tor exit nodes. Let me introduce a new aspect here. I wasn't even allowing HTTP to leave my node! Since your inferior technology cannot even determine what the exit policies of the various nodes are, your indiscriminate blocking of them all is a violation of free speech, protection of individuals suffering from oppression and basic human rights.

Furthermore, I find the very fact that you are doing obtrusive scanning (or subscribing others who do) flat out appalling. All of this is playing into the hands of oppressive governments, whose bidding you are doing. I detest Wikipedia supporting totalitarian regimes. Where is Wikipedia going with this outright hatred, the on-going censorship practice and questionable editing policy? You are shooting yourself in the leg. My distrust has certainly skyrocketed. --84.249.164.59 (talk) 03:42, 17 March 2009 (UTC)

Collateral damage from Tor blocks

Like most people in Singapore, I use SingNet as my ISP, and SingNet's proxy system means that my outward IP changes (almost) every time I edit. At some point a few weeks back, some admin hard blocked one (or more) of SingNet's proxies somewhere in the 220.255.7.xxx range, meaning that every SingNet user is, pretty much randomly, intermittently blocked from editing whenever their edits go via that proxy.

My specific complaints:

1 -- Obviously, hard blocking the SingNet proxy was in error, and the block should be rescinded and the admin at fault slapped with a trout.

2 -- Worse though, is that the block message (MediaWiki:Torblock-blocked) is uninformative, useless and partly incorrect. Here it is in entirety:

You have been blocked, because it has been detected that you are using the Tor anonymising service, or you or somebody sharing your IP address is running a Tor exit node.

Editing pages from tor exit nodes is disabled due to abuse. In order to edit through tor and from IP addresses running tor exit nodes, you need to request an account and then request block exemption. Please note that this will only be granted in exceptional circumstances.

Please note that some Internet service providers may use a single IP address for a large number of users. If one of those users runs a Tor exit node, then all of them will be blocked.

Note that this a) does not give the blocked IP or any way to deduce it, b) does not give the blocking admin or any reason he left, c) gives incorrect instructions (I already have an account and am using it to edit), and d) does not provide any sensible way to work around the block (IP block exemptions for all SingNet users in Singapore is not sensible).

Suggestion: Adopt the text from MediaWiki:Blockedtext. I'm not sure, though, how many of the arguments passed into Blockedtext (eg. IP address, blocking admin) are available from MediaWiki:Torblock-blocked.

For the specific case of SingNet, there is an immediate workaround: manually set the browser to use proxy.singnet.com.sg:8080, which then routes all requests through 220.255.4.30. But it took me days to figure that out... Jpatokal (talk) 11:25, 6 May 2009 (UTC)

See Wikipedia talk:SGpedians' notice board#On SingNet and getting hit with Tor block notices lately? for reports of other Singaporean editors getting slammed by this. Jpatokal (talk) 03:31, 7 May 2009 (UTC)

This was an error of an administrator that blocked a (likely former) tor node (auto blocks for tor nodes are based on a regularly updated IP list provided by Tor itself), while it's only a transparent proxy at this moment. Problems like these are a side effect of the usage of proxies by ISPs. As the Tor template clearly explains: "Please note that some Internet service providers may use a single IP address for a large number of users. If one of those users runs a Tor exit node, then all of them will be blocked." A common problem with ISPs that are running out of IP addresses, but unfortunately, not something that Wikipedia can solve. These ISPs are using the internet in a way it was not designed for, and as such, it's users should expect problems. Said ISPs are welcomed to enable XFF headers and it's users can request wikimedia to trust those XFFs, which makes it easier for wikimedia to identify individual users behind the proxy. Something else those ISPs can do, is to develop IPv6 structure for themselves and Wikipedia.

People may not like it, but this is a technical issue that is difficult to solve, which combined with an error of an administrator (who assumed a proxy was a tor node, because it had been before), resulted in a problem for many Signet users. It's life, in such large projects as Wikipedia. User errors cannot be avoided and the world (of technology) is not perfect. Advocate with your ISPs to be provided with non-proxied IP addresses and at least one error won't affect a large set of users.

The damage trough Tor nodes has been so severe, that it cannot be tolerated as it has been before. We have blockexempt for people who want to truly contribute. It is clearly stated in the template. Perhaps a more friendly message might be an idea however: "If you have no idea what Tor is, you may request a "blockexemption" here...

So to summarize:

1. Don't use ISPs who proxy
2. If you have to, request they enable XFF, and inform wikimedia about these XFF headers.
3. Fight for IPv6 in the long run.
4. Make the block message easier to understand for people without technical skills.
5. Accept that administrators can make mistakes on such complicated cases.

—TheDJ (talk • contribs) 12:11, 7 May 2009 (UTC)

Also, always NOTE the IP that has been blocked, user reports without the IP information are somewhat pointless, because we cannot take further action upon them. —TheDJ (talk • contribs) 12:26, 7 May 2009 (UTC)

That's exactly what I'm bitching about -- how can users getting hit with that message report their IPs, since the block message does not give any way of finding out the IP!? Fixing this is the single biggest step you can take to solving this problem.

This is something we could look into. —TheDJ (talk • contribs) 16:08, 7 May 2009 (UTC)

I've now added the IP address to the torblock message.[7] -- zzuuzz

^(talk) 16:42, 7 May 2009 (UTC)

Yay! Thank you. Jpatokal (talk) 01:47, 8 May 2009 (UTC)

No, block exemptions are not a sensible way of solving this; as the message itself says, they're granted "only in exceptional circumstances". I've been editing Wikipedia since 2003, and when I asked for a block exemption, it was refused by another admin who failed to understand what was going on despite my repeated attempts to do so.

At least now you have it. I'll look into it further however. —TheDJ (talk • contribs) 16:08, 7 May 2009 (UTC)

And finally, SingNet is already listed at XFF as a trusted supporting ISP... Jpatokal (talk) 14:48, 7 May 2009 (UTC)

It seems singtel/net has changed the IP range they are using. The XFF list has "165.21.154.0/24" whereas the ip's reported are in the range: 20.255.7.xxx —TheDJ (talk • contribs) 16:08, 7 May 2009 (UTC)

There's been, I suspect just the one, Tor exit node on SingNet which exits in the 220.255.7.x range. These IPs will have been automatically blocked on a rotating basis for about the last month. It seems SingNet has the whole /16, but the Tor proxy's only been on the /24. -- zzuuzz ^(talk) 16:25, 7 May 2009 (UTC)

Yup you are right I think. The current list of tor exit nodes contains several 220.255.7.xxx IPs it seems. I still haven't been able to confirm the usage of XFF headers however. —TheDJ (talk • contribs) 16:44, 7 May 2009 (UTC)

Domas has now enabled XFF for 220.255.7.* Though the singtel range is larger, he is not entirely sure where the range of XFF enabled IPs begins and ends, so he is playing it safe. But the accesslogs of the webservers did confirm that at least this range uses XFF headers. —TheDJ (talk • contribs) 16:53, 7 May 2009 (UTC)

Please add proxy.singtel.com.sg (220.255.4.26) to the XFF list; it's presently autoblocked and stopping all the users using it. Jpatokal (talk) 07:12, 20 May 2009 (UTC)

In the future, you can mail such requests for "extension" of this block of XFF addresses directly to xff AT wikimedia DOT org. I have now done so myself. —TheDJ (talk • contribs) 09:28, 20 May 2009 (UTC)

Suggestion

I think that TOR nodes that are not exits should be blocked as well. By running a TOR node, even a non-exit one, you are actually helping vandals by providing them a anonymous encrypted path to a TOR exit node.

By blocking ALL TOR-nodes, even non-exit ones, we discourage usage of TOR. A block time of 1 week is suitable, and then a recheck. If its still a TOR node, extend the block by 1 week and recheck.

So the block time of 1 week the gets as a punishment for node operators for running a TOR node and helping vandals. Its like selling weapons to criminals.

Sebastiannielsen (talk) 02:07, 28 November 2010 (UTC)

We are not bothered at all if someone operates a Tor node to help people with their anonymity elsewhere on the Internet. We are not interested in discouraging Tor, only preventing abusive edits to Wikipedia. If we're only concerned about preventing vandalism, all we need to do is block the exit nodes which can exit to Wikipedia -- zzuuzz ^(talk) 08:44, 28 November 2010 (UTC)

Another suggestion

After reading through this years-long blog it seems to me as an IT-consultant, that it may be summarized like this:

• WP faces problems with vandalism and sockpuppetry, but so far there seem to be no quantitative informations about the frequency and size of these problems
• some of these problems are caused by bots, some by humans, but also here, we lack quantitative information
• some of the problems are produced through WP-access via TOR or other anonymous access methods (like the several free WiFi initiatives) hiding the originators IP-address (again, no absolute numbers nor percentage are presented)
• the only or main counter-measure used so far seems to be the blocking of IP addresses of open proxies and TOR nodes for editing, regardless of the authors being anonymous or logged in

While anonymity belongs to the range of basic human rights (at least in Germany), vandalism and sockpuppetry, though certainly a nuisance, possibly a crime, are not of comparable account. Blocking IP addresses is technically easy, but a very big gun and not at all a specific solution for the problems. Its collateral damage is not only the inhibition of all legitimate anonymous authors as well as logged-in WP authors, but also the implicit discrimination of all anonymous access projects of the civil society and the suspicion of vandalism or sockpuppetry for all of their users, while what we want is fighting actual vandals and sockpuppets, regardless of how they access WP.

So, why don't we concentrate on a more thorough analysis of the problem and, as far as adequate, the development or use of more specific counter-measures?

• To prevent vandalism using bots, why don't we use something like captcha?
• To prevent vandalism by humans, we may think about intelligent content-evaluation.
• Having the same or different IP-addresses is not decisive for the recognition of sockpuppets. Several providers change IP-addresses daily, some use proxies with NAPT and use one IP-address for thousands of users. Here, other characteristics have to be found. In the end, I believe, even without technical means, honest human authors will by their vast majority win any fight against human sockpuppets wherever relevant.

--G-u-t (talk) 18:37, 11 May 2014 (UTC)

How to honor allow anonymous editing policy when IP tracking is 100%

at 2014-10-19

• I guess that allow user to edit wikipedia anonymous is agreed within the group.
• But since some police states such as China are have 100% IP to actual person record, even you are at public spot such as net cafe, or WIFI "you need to put down your ID first".
• please recommended ways to prevent such things happen.
• We all agree that no one should got arrest when editing wikipedia, right ?

183.178.222.177 (talk) 13:18, 19 October 2014 (UTC)

Trying to answer:

* point 1 is agreed.
* that's shocking
* we can stop it as long as we would show you IP address.
* point 4, we agree it, but sometime everything comes with sacrifice, and in current system, your edit may be deleted even if you got death sentence for it, we have no way to prevent it. So, you probably ask a friend in foreign edit it for you.  — Preceding unsigned comment added by 183.178.222.171 (talk) 15:41, 9 November 2014 (UTC)