The English language version would like to enable range blocks for users with sysop status. I believe that all that needs to be done is to add $wgSysopRangeBans = true;" in LocalSettings.php. See Wikimedia article . If I'm not mistaken, this should take about one minute, so it would be much appreciated if this were done without too much delay. --Peter Talk 20:06, 2 May 2009 (EDT)
- As demonstrated again this evening (and ongoing even now), this would prove enormously useful on some occasions. It's already wasted quite a bit of time for at least four sysops today, so any update from the tech team would be appreciated. - Dguillaime 01:16, 3 July 2009 (EDT)
- I think on the French language version it might be also useful. --Rein N. 03:10, 15 January 2010 (EST)
- Unfortunately this request cannot be fulfilled. Please see this answer from Dick : As a rule, we don't allow the members of our sites to ban IP addresses, especially through the use of plug-ins that allow the banning of full IP ranges. In the past, we've had people a.) block our own network, b.) block entire countries, and c.) block google.
Blocking IP's is very rarely effective, and can potentially do a lot of harm. Therefore, anytime someone believe that an IP needs to be banned can make the case to me. My contact information is available on the IB page: 11. If we do have a problem like the case you've mentioned above, we have the ability to revert all edits by the offending use in bulk. IB-Dick 20:06, 10 February 2010 (EST)
Ibsteph 02:04 PM , 18 February 2010 (PST)
- Have you read the explanations below? It does not seem that either of you understand what is being requested in this feature request. --Peter Talk 20:28, 18 February 2010 (EST)
Swept in from the pub
- Erm, we are not asking you to block IP ranges, we are requesting opening of the very frequently used Mediawiki feature which allows us to temporarily block ip-ranges as a last resort to stop high volume vandalism. If you poked around a bit you'll see we have very restrictive guidelines on just regular ip user blocks (apart from spambots), and I can't really see anything this community has done to earn any distrust in this regard - so I'd really urge you to reconsider your one-size-fits-all policy on this one. Especially since we've never had any backup from you guys during previous high-volume attacks. Try looking up "Willy-on-wheels" and see how he single-handedly brought the Juggernaut that is Wikipedia to it's knees, and then consider what his copycat following can do to a small community like Wikitravel, with zero-ziltch-nada in the way of tech support, if they tried. sertmann 18:45, 10 February 2010 (EST)
- As a rule, we don't allow the members of our sites to ban IP addresses, especially through the use of plug-ins that allow the banning of full IP ranges. In the past, we've had people a.) block our own network, b.) block entire countries, and c.) block google.
- Blocking IP's is very rarely effective, and can potentially do a lot of harm. Therefore, anytime someone believe that an IP needs to be banned can make the case to me. My contact information is available on the IB page: []. If we do have a problem like the case you've mentioned above, we have the ability to revert all edits by the offending use in bulk. IB-Dick 20:06, 10 February 2010 (EST)
- Dick, we already block users, both registered and IP users; it's built-in to the MediaWiki software. And anyone with the ability to block can also unblock themselves, so there's no risk of us shutting out anyone important (though what Google has to do with anything I can't figure out). LtPowers 21:05, 10 February 2010 (EST)
- So, what's the problem? IB-Dick 13:18, 11 February 2010 (EST)
- Savvy vandals will change their ips rapidly to circumvent our blocks. Very short-term range blocks can deal with this easily by halting edits from their entire range, which is why other wikis like Wikipedia employ them. Please read Tech:Enable range blocks, which also explains how you can (quite easily) enable this feature. --Peter Talk 14:19, 11 February 2010 (EST)
- There is some confusion - we aren't talking about blocking READ access to pages, only EDIT privileges. Google and other spiders would not be affected in any way. In addition to the link Peter provided, see also en:Wikitravel:How to handle unwanted edits#User ban which is the current English Wikitravel's guidelines on when and how to block a user from editing. Blocking single users / IPs is effective most of the time, but in cases where a vandal is savvy enough to change IPs, being able to (temporarily) block the dynamic range that they are using would save enormous amounts of time. Wikitravel would collapse if there weren't editors spending huge amounts of time dealing with bad edits, so adding additional tools to make this work easier should be a no brainer. -- Ryan 14:36, 11 February 2010 (EST)
- Whilst it is good to finally hear from someone at IB after a yawning absence, there is a remarkable lack of understanding of both what is being requested, and of the extremely responsible manner in which the Wikitravel community has always conducted its affairs. As Ryan says, please just make an effort to make our work with Wikitravel a little bit easier. That is all we are asking. You never know, IB's ad income might even increase if you actually try to help with keeping the site in order. --Burmesedays 23:28, 11 February 2010 (EST)
Hi. I am in discussions with Tech over the range blocks issue. I cannot promise there will be movement, and our answer as given long ago ("will not do") still stands as of this moment. But the issue is back on the table. Any new data, use-cases, etc. that you can provide at this time would be very helpful as we mull this over. Please remember that I am neither a long-time WT curator nor a techie, so my understanding of issues like these is going to be somewhat limited compared to your own.--IBobi 19:54, 29 July 2011 (EDT)
- It is, I should emphasize, a feature that would be used very rarely, and correspondingly it's tough to pull most of the examples out of the recent changes history as they're well past the 30-day cutoff. (The event that initially triggered the request was one person using about thirty or forty addresses from a /24 block within a single day, as I recall.) However, today's mini-vandalism spree over on :en is perhaps an example -- blocking 126.96.36.199, 163, 164, and 166 in quick succession, and another three addresses in 95.154.230.* in the same time, is exactly the sort of quick-changing behavior that this feature would address, and just about meeting reasonable thresholds for using it. Simply being able to block anonymous edits (and nothing else!) from matching specific and narrow ranges for a few hours would have saved some cleanup time and hastened the vandals' departure. — D. Guillaime 16:02, 2 August 2011 (EDT)
- Regarding Range Blocks: there may be a way for us to give the WT community what it needs, if not what it has asked for. These tools you have requested are primarily spam-remediation features. Range blocks can be done, but it will likely remain a function that will have to be performed upon request to IB’s tech department. You can contact myself or IB-Dick directly in such cases. Our contact information is available on the IB WT page or my individual WT page. Please advise.--IBobi 20:54, 3 August 2011 (EDT)
- IBobi, that is basically useless, because a range block is only effective if it is enacted immediately, while the attack is ongoing. We all know that IB is not going to be standing by 24 hours a day ready to instantaneously do a range block the second we make a request. Go back and tell them that's not good enough-- it doesn't go a millimeter towards giving us what we are asking for. They should at least be able to give (to admins only) the ability to range block for a few hours to a day or two.texugo 22:09, 3 August 2011 (EDT)
- I worry that we still have a communication problem. This is not a request that requires any development work from the tech department, nor is it a request that significantly changes the operation of the site -- it is literally a one line configuration file change that enhances an existing, well-used site function. It is not so much a spam remediation tool, as it is a vandalism remediation tool: this distinction is why our usual anti-spam tools, like the blacklist, are ineffective in this specific instance. By the same token, as texugo explains, speed is essential to making the tool useful at all -- the typical block would most likely be in the 1-6 hour range, but if it's to have any chance of causing the vandal to get bored and wander away while minimizing the damage, it must be applied while the vandalism is in progress. Waiting until the next business day is utterly useless. -- D. Guillaime 23:29, 3 August 2011 (EDT)
- What kind fo time frame are we looking at where the response must occur (i.e. the block must be put into place) before it becomes useless? You are correct, we would likely not have a tech resource on call for such operations, but during business hours it could potentially happen quickly. Surely that would be an improvement over nothing?
- My second question is: how do you limit the time frame during which the block is active? Who determines that -- the person setting the block? I realize the *intent* may be to set a temporary one in order to deter a vandal, but how is the time limit actually enforced?--IBobi 13:10, 4 August 2011 (EDT)
- IBobi, can you take a look at en:Wikitravel:How to handle unwanted edits#User ban (in particular the bullet points on exceptions) to understand how user blocks currently works? As User:Dguillaime states, I think there is still confusion here. Out of the box, the Mediawiki software has capabilities for blocking users that we use on a daily basis to deal with vandals. However, to allow range blocks a Mediawiki configuration file must be updated by the server administrator to turn on that feature (as noted above, see ). All that we're asking is that IB update that config file - literally, a one minute change - to enhance the existing Mediawiki user block capability. -- Ryan 13:35, 4 August 2011 (EDT)
- Re:"What kind of time frame are we looking at?"-- The quicker the better. When that kind of attack is underway, every minute we wait can potentially mean another 1-100 vandalism edits we have to deal with. Waiting even 20 minutes can be too long. So no, leaving it to the tech team really isn't much better than nothing. We admins could really benefit from being able to do it ourselves. Any fears they might have about abuse or whatever are ridiculously unfounded. We need this. texugo 01:26, 5 August 2011 (EDT)
- Can you, or any other admin, share WT articles where enabling '$wgSysopRangeBans' would have been helpful? One of our fears is that RangeBans would be used in edit warring, say for Don't Tout, instead of non-confrontational remediation, and not to combat rampant advertisement for "BONER PILLS" or vandalism. While our fear is unfounded, your assertion isn't apparently supported either. Understand that this isn't failure to AGF, rather a step toward making an "exception to the rule". -- IBWes 18:45, 19 August 2011 (EDT)
- This isn't a problem with specific articles, nor would the tool be used for anything other than a temporary stop to high volume vandalism run by a vandalbot. This type of activity is not recorded by MediaWiki in a way that would make it easy to provide "an example," unless you were to participate in the cleanup concurrent with the vandalism. The bout that inspired this tech request was over the course of 2-3 days in 2009, when our administrators pretty much worked around the clock reverting hundreds of edits being run by a vandalbot. Eventually, as always, the vandals got bored and moved on, but this was a colossal waste of time, when we simply could have used a range block for 1 hour to get the attackers bored, and repeat as necessary. That was unusually high volume, and this tool would be useful for such unusual circumstances.
- That IB is concerned that admins would abuse this tool is profoundly disturbing. Wikitravel admins work via consensus, and we are more cautious and inclined towards open editing than with any other wiki project I am aware of. The idea that IB of all agencies, which has been nothing but derelict and borderline abusive, considers this community untrustworthy to run itself (which it does anyway) is both offensive and ridiculous. --Peter Talk 22:35, 19 August 2011 (EDT)
- Peter, thank you again for engaging so deeply on this issue. Just as a point of clarification, our concern isn't so much of deliberate abuse of the feature as it is the balance between the extraordinary power of the feature versus its *intended* use; it is intended to be used sparingly and for short periods of time, but there are no controls at all about how it *may* be used once it is in place. Reconciling handing over this level of site control to sysops who are largely unknown to IB, when IB is very rarely even in the practice of allowing control of *individual* range bans to our *paid* site leads is, to say the least, problematic. Surely you can see this. Even seasoned systems people make grievous errors with this type of feature from time to time. If I am to continue to go to bat over this with my tech and management teams on WT's behalf, as I have and am, there will need to be some community acknowledgement of the power of range bans and their potential for misuse.
- Also, with regard to the specific use case you mentioned, that could have been stopped as Dick suggested above, by requesting that IB put the ban into place; moment-to-moment or even hour-to-hour timing does not seem to have been the issue, as the vandalism was ongoing for days. Had IB been requested to place a range ban in place, the issue would have resolved in much the same way that it would have if sysops had been able to do so themselves.--IBobi 15:49, 23 August 2011 (EDT)
- Please understand that this community is self-policing: if someone accidentally applies a range block another admin will fix that action. Also, as has been pointed out elsewhere, there are fairly strict policies in place for when a block may be applied, and were any admin to abuse those policies (something that has never happened on Wikitravel) their admin rights would be revoked almost immediately.
- As to the comment that a request to IB could have solved the previous vandalism problem, with all due respect I think that the fact that it took six days to fix a serious bug with image permissions should be enough evidence to support the healthy skepticism the community has about that approach. Mediawiki software provides tools for a community to be self-policing, and that is clearly seen as the most effective way to go by those that use the site. -- Ryan 15:58, 23 August 2011 (EDT)
- Precisely. What is disturbing is the notion that IB thinks it should be policing/controlling Wikitravel users' behavior, as opposed to letting the community run itself as it always has done. It is this sort of thing that makes me think it is time for the community to abandon this relationship. --Peter Talk 17:00, 23 August 2011 (EDT)
- I take your point on the timing issue referencing the Image loading problem; provided you understand that there is a difference between enacting an IP ban (a quick procedure that is standardized and understood by our technicians) and identifying, investigating, and resolving an unknown technical issue that's been reported. I'd like to believe the timing would be different on those two occasions. But I take your point just the same.
- As the liaison between the WT community and IB, I am your advocate to IB as much as I am a conduit of information from IB. This is not about policing or controlling; this is a discussion thread about adding a new feature to help the community remediate spam and vandalism, and it is receiving serious consideration for the first time in a while. I understand it can be frustrating to try to make your points; but it behooves us all to keep this constructive, as this discussion has overwhelmingly been; I am more convinced than ever that it is in everyone's best interest to enable this feature. All I ask is as much backup as you can give me to make this happen, in the form of the facts and use cases presented here. I will again make the case this week, provided there are no technical hurdles. Thank you all for your continued participation.--IBobi 17:53, 23 August 2011 (EDT)
IBobi, to help you understand how administrators work with IP bans, I have added the administrator's handbook to shared. In short, an IP ban is usually very short (typically 2 hours) and it is the admin who puts the ban who decides its duration, based on experience and the vandal's "contribution". If the same address returns after the block has been automatically lifted, they get blocked again, this time a little longer, say 24 hours. If the IP comes back again, well, a new and longer block is assigned. This is the way it is done on Wikipedia and it is a *very* common thing to do. Any admin who abuses the tool will be sure to hear from other users. IP range block is used in the case a vandal keeps changing IP:s to bypass the problem. This works really well on Wikipedia and it sould work just as well on Wikitravel - the wiki world is used to it. So, it is not a dangerous tool to have, and the best thing about it is that if placed by mistake or in error, it can be reverted by any other admin. This is anoher example of how consensus and social control on Wikitravel works. Riggwelter 07:41, 9 August 2011 (EDT)
- Since we have a good discussion thread happening here, let's discuss how the spam/vandalism is appearing on the site. Do you find that most of the spam/vandalism is appearing via anonymous edits? And how do you feel about disabling that and just requiring registration in order to edit WT?
- Meantime, the range blocks discussion is ongoing internally. Thanks for all the clarifications, I'm sure we understand the implementation and typical usage issues.--IBobi 15:14, 9 August 2011 (EDT)
- PLEASE don't disable anonymous editing - barriers to contributing to a wiki are already high enough. Things that would be useful:
- Enable CAPTCHA for registration on all language versions. It is already enabled on English Wikitravel and (I think) a few others. This will prevent spambots from attacking the sites as they have been recently.
- Enable the spam blacklist on all language versions. It is already enabled on English Wikitravel and several others including shared. The blacklist provides a tool to prevent spamming.
- Enable range blocks. This is a tool that will help prevent vandalism by tech-savvy vandals.
- Ensure that there is an active admin on all language versions so that someone will have the abilities outlined in the administrator's handbook. This allows cleanup and prevention of spamming and vandalism.
- The Mediawiki software provides more than enough out-of-the-box capability to manage vandalism and spam, we're just asking that you (as the system administrators) enable it. -- Ryan 15:57, 9 August 2011 (EDT)
- I am adding your CAPTCHA and Blacklist requests to our internal tech queue. What do you consider a good approach to getting admins on the other language versions?--IBobi 18:06, 9 August 2011 (EDT)
- A few people have put their names on Wikitravel shared:Administrator nominations (Texugo on pt:, myself on ar:) to try to step in where we've lost the active admins. As outlined on that page, the normal process is to let nominations stand for two weeks for comment, after which we would need someone from IB to update the user permissions (since there are no active admins on the affected sites who could change permissions via Special:Userrights). I believe that IB has created an admin account on all sites with ability to change permissions - see the Special:Listusers/bureaucrat page for each site, which seems to have a "User:StormyBot" account. Assuming that IB can help with the technical side of things we can solicit volunteers for others sites that have become inactive - ideally having at least two active admins per site would provide some redundancy. -- Ryan 18:27, 9 August 2011 (EDT)
- And here's a big emphatic second to not blocking anonymous edits-- that's how most people get started here, and blocking it may very well just eliminate that many more potential contributors. And CAPTCHA for creating user accounts-- as I commented on the tech request page, we need it badly over on es: -- take a look at the deletion log on es: -- I have deleted hundreds of these fake, spammy user pages over the last several months, and there is no other way to stop it but CAPTCHA... texugo 03:46, 10 August 2011 (EDT)
- Oh, and there's been quite a string of them here on Shared too, if you hadn't noticed... texugo 06:20, 10 August 2011 (EDT)
Please, please, please all: let us keep the discussion on this page for the specific issue about enabling range blocks only. Whereas I really approve of the work IBobi and IB now seem to put into WT, as well as the initiative regarding new features, I strongly believe that we must keep the discussions where they belong:
If we try to be as disciplined as possible about where to keep the consensus talks, both WT as well as IB and the community will benefit. Riggwelter 08:08, 10 August 2011 (EDT)
- Hello. Admins and Bureacrats, Range Blocks has been enabled on Wikitravel.
- I want to thank everyone who participated in this discussion and enabled this to happen at long last. We hope this feature will be helpful in spam/vandalism remediation. It is a powerful tool and we trust that the admin/bureaucrat community will use it wisely and judiciously (and on an expiring, temporary basis); tools like this make it extra important that the community police not only the use of those tools but the very list of admins who are authorized to use them as well, if access to them is to be kept free and clear for all.
- There is an interesting discussion going on here about decommissioning inactive admins, and in my opinion it's something worth looking at, given this tool's activation: http://wikitravel.org/shared/Talk:Administrators
- Please see IB-Dick's test range block here, for an example of how to do this:
- Thanks again, Paul--IBobi 16:29, 24 August 2011 (EDT)
- Has anyone confirmed that this works? I can't seem to access the tool at all. --Peter Talk 00:10, 20 September 2011 (EDT)
- Looks like it works to me; I have a test block in that will expire in 2 hours. Administrators will need to create the necessary range using CIDR notation. -- D. Guillaime 00:15, 20 September 2011 (EDT)
- Great, I'll close the request. --Peter Talk 23:48, 20 September 2011 (EDT)
In trying to deal with the weekly Toronto spammer, the capability to implement a range block appears to have been revoked. -- Ryan 17:12, 5 April 2012 (EDT)
- Should be back on now. See my Pub note.--IBobi 14:26, 11 April 2012 (EDT)