Last modified: 2008-03-24 20:53:38 UTC
Page moves should be throttled to say 1 per minute for non-admin users, to prevent page-move vandals from making rapid sequences of page moves which overwhelm admin reactions to block the user involved, and (very painfully) move the pages back and delete offensively-named or nonsense redirects created as a side-effect. This limit should be applied on a per-IP-address basis, to prevent the use of multiple sockpuppet accounts, or bots which automatically create accounts. This will also ameliorate the problem of page moves as a DOS attack.
Could someone PLEASE implement some sort of throttle? Sysops get tired of each Willy incarnation being able to move 50 pages in under 2 minutes: http://en.wikipedia.org/wiki/Special:Contributions/Vandalbot_on_wheels%21 http://en.wikipedia.org/wiki/Special:Contributions/SmarterChild3 http://en.wikipedia.org/wiki/Special:Contributions/FUCK_DAMN_CUNT_BITCH_HELL_SHIT_PUSSY http://en.wikipedia.org/wiki/Special:Contributions/Willie_on_Wheiels http://en.wikipedia.org/wiki/Special:Contributions/Vandalism_script_in_VB.NET http://en.wikipedia.org/wiki/Special:Contributions/Willypedia_-_The_Free_Encyclopedia http://en.wikipedia.org/wiki/Special:Contributions/So_two_Willys_walk_into_a_bar... ... Note that all the above examples cover less than a week.
That's actually just a hack, and a bad idea in the long term. It would be better if someone could rollback the past <n> hours of modifications by a specified user, including all page moves, renames, etc.
I agree that some sort of throttle should be put in place. One page move per minute sounds appropriate for non-admins. How often does someone need to move more than 60 pages/hr?
I agree with comment #2. Although the throttling is a good idea, the ability to rollback all or partial edits/moves of a particular user would be better for admins in fighting mass vandalism.
Page moves are already throttled to 2 in 120 seconds for new users.
(In reply to comment #5) > Page moves are already throttled to 2 in 120 seconds for new users. Ummmm, then how do you explain the dozens of moves in the logs I posted? Are you defining "new users" in some strange way that doesn't trap Willy?
(In reply to comment #2) > That's actually just a hack, and a bad idea in the long term. It would be better > if someone could rollback the past <n> hours of modifications by a specified > user, including all page moves, renames, etc. Both of these would be useful. I disagree that it's a bad idea in the long term; there is little justifiable reason for normal users to make high-speed page moves; bulk moves are rare, and if someone does need to do so, it's easy enough to ask an admin to do it (and any editor sophisticated enough to want to do it is sophisticated enough to ask for it.)
(In reply to comment #5) > Page moves are already throttled to 2 in 120 seconds for new users. Okay, I found the pingLimiter, but User::isNewbie relies only on the account's age (i.e. if it is in the most recent 1% of registered accounts). That is no good at all, since all Willy has to do is register a bunch of sleeper accounts, wait till they age up to not being newbies and then start a rampage. Since we have no way of looking at new account registrations, there is nothing we can do to spot the sleepers (see [[1628]]). Hell, he can even accelerate the process by registering lots more bogus accounts. How about adding "$this->edits() > 100" to isNewbie? You already have code for counting edits, how about expecting a certain level of site participation before opening up the smorgasbord of moves?
(In reply to comment #8) > (In reply to comment #5) > > Page moves are already throttled to 2 in 120 seconds for new users. > > Okay, I found the pingLimiter, but User::isNewbie relies only on the account's > age (i.e. if it is in the most recent 1% of registered accounts). That is no > good at all, since all Willy has to do is register a bunch of sleeper accounts, > wait till they age up to not being newbies and then start a rampage. Since we > have no way of looking at new account registrations, there is nothing we can do > to spot the sleepers (see [[1628]]). Hell, he can even accelerate the process > by registering lots more bogus accounts. > > How about adding "$this->edits() > 100" to isNewbie? You already have code for > counting edits, how about expecting a certain level of site participation before > opening up the smorgasbord of moves? s/>/< ?
(In reply to comment #9) > s/>/< ? Yeah. Okay, to be specific, change: return $this->isAnon() || $this->mId > User::getMaxID() * 0.99 && !$this->isAllowed( 'delete' ) && !$this->isBot(); to: return $this->isAnon() || $this->edits() < 100 || $this->mId > User::getMaxID() * 0.99 && !$this->isAllowed( 'delete' ) && !$this->isBot(); would be my suggestion.
Another idea: throttle the page moves until the user has done a number of page moves (for instance, 10 moves). This reduces the amount of damage a page move vandal can do while not inconveniencing the legitimate users much.
(In reply to comment #11) > Another idea: throttle the page moves until the user has done a number of page > moves (for instance, 10 moves). This reduces the amount of damage a page move > vandal can do while not inconveniencing the legitimate users much. That would mean that all Willy would have to do in future would be to create an account with a legitimate name, do some sandboxing to get the required edit count, do a dozen "innocent" page moves, and then inflict chaos as usual.
My suggestion is that page moves are limited to 2 per day for non administrators. This will unfortunately inconvenience some legitimate users, but if more than 2 are really needed they can request it at Wikipedia:Requested Moves. I can't think of many situations where more than 2 moves will be needed other than page move vandalism reversion and implementing a new naming convention which should have been discussed at WP:RM anyway. Even if the limit is 5 per day this will be infintely preferable to the current situation. See also [[bugzilla:3185]]
Why not restrict the ability to move pages to users with more than, let's say, 100 or 200 edits? This is certainly a very easy, comprehensible and effective way to deal with the well known problem and it will cause definitely less inconvenience than the other suggestions. I would therefore recommend to follow DFs proposal.
The trouble with that is that he could just make 100 or 200 bot edits to the sandbox and then go on his moving spree. I don't know if it is technically possible, but perhaps require 200 non-deleted article namespace edits before being allowed to move pages. If a user makes anywhere near that many nonsense edits they'll be blocked by RC patrolers before they can move a single page.
(In reply to comment #15) > The trouble with that is that he could just make 100 or 200 bot edits to thesandbox and then go on his moving spree.I don't know if it is technically possible, but perhaps require 200 non-deletedarticle namespace edits before being allowed to move pages. If a user makesanywhere near that many nonsense edits they'll be blocked by RC patrolers beforethey can move a single page. It is my understanding that it is also possible to throttle newbie edits as well as moves precisely for the purpose of trapping editting vandalbots, though I don't know if this is turned on or what the configuration is. Obviously it can't be a very strong throttle as it has to accommodate even new users who might edit fairly quickly. But even with a very weak limit, like one edit every 3 seconds, that would still translate to 5 minutes of nonsense edits before reaching a 100 edit threshold. Surely five minutes of nonsense edits would raise some eyebrows on RC patrol before it got to a page move spree. However, it would be nice if a dev could explain what the settings are and what options are possible.
Please restrict page moves to 2 per 120 seconds for all non-admins, not just the 1% new ones. The 1% thing is too easily gamable. Also, per comment #2, an "eradication" option that would automatically rollback (or even erase) all edits from one user made in the last day would be very useful against vandals. Restricting it to bureaucrats would work, or restrict it to admins and make it clear that abuse warrants an instant ban.
There is now a bot on en.wiki that automatically permablocks any non-admins that make too many page moves. This is somewhat controversial but should help alleviate the problem until a permanent solution is found.
Support throttling to something like 1 per 10 seconds - a reasonable balance. Admins should be exempt. We really need this yesterday.
We should be able to do this without any extra data structures, by just looking back over the move log. We can even do a leaky-bucket-like fix by doing something like: if number_of_moves_for_last_n_seconds(username, 60) > 2: generate_move_blocking_notice() return
Neil, we already have a move throttle.
What about requring a non-admin to solve a captcha before every page move. This would simultaneously block bots and it would requre a vandal to waste time accurately typing in the text. It also would be less likely to annoy non-vandals. Throttles should be set to at least 3 per time period so people could switch the location of two articles in one moment. Also realize that throttles could block good non-admins from helping to undo damage.
Anything stricter than three moves per three minutes or thereabout is going too far. Often three moves in a minute can be entirely legitimate, as BrokenSegue says.
*** Bug 6978 has been marked as a duplicate of this bug. ***
Allow me to quote Tim Starling and Timwi from a discussion a while back about this issue on wikitech-l: On 7/4/06, Timwi <timwi@gmx.net> wrote: > Tim Starling wrote: > > > > I'm surprised it hasn't been said yet, but the classic wiki solution to page > > move vandalism is not to put up barriers to making contributions, but rather > > to make vandalism easier to revert. > > I'm surprised (well, rather disappointed) that this even needs saying. > It implies that most people here don't know what wiki is all about. I've opened bug 6984 with suggestions as to how to make pagemove vandalism easier to revert. I encourage everyone to vote for that instead of this. There's no excuse here for restricting legitimate activity. (Actually, maybe a dev could WONTFIX this?)
(In reply to comment #21) > Neil, we already have a move throttle. It's too high. See http://en.wikipedia.org/w/index.php?title=Special:Log&type=&user=Willy+on+WheeLs&page=&limit=60&offset=0 - 55 page moves in under a minute, just 5 days after creating an account. If the move throttle is "55 per minute", it's too high... unless you're a bot or an admin.
Throttling should probably be per IP address, or even per address range (some statistics gathering would be needed first) rather than per user account, to prevent gaming using multiple sleeper accounts. If throttling by address range results in occasionally impairing a legitimate user's pagemoves, I think that's ok if it doesn't happen too often (they can ask for admin help and/or try again later). For example, I suspect the total number of pagemoves per day from non-admin AOL users is pretty low; I wonder if it's hard to find out. --Phr
(In reply to comment #27) > If throttling by address range > results in occasionally impairing a legitimate user's pagemoves, I think that's > ok if it doesn't happen too often (they can ask for admin help and/or try again > later). It's okay if it's the only option. Since it isn't, I don't think it's okay. (And by the way, people, please let the devs set priority. It's not really used anyway, but . . .)
I completely disagree with limiting page moves for all non-admins. I'm a non-administrator and I often move dozens of pages per minute when doing a batch of typo fixes (usually replacing hyphens with en-dashes in article titles with date ranges or noun–noun compounds). In fact, I once got wrongly blocked for this by a clueless admin who looked only at the number of page moves coming from my account and not at the actual reason for the page moves. If moves are going to be throttled, then either make the throttling apply only to new users (i.e., below a certain edit count), or set the limit at a rate which will block bots but not humans. A human using a web browser with multiple tabs can do about one move per second, so the limit shouldn't be higher than that.
*** Bug 11968 has been marked as a duplicate of this bug. ***
There are more and more cross-wiki vandalism attack using only page renaming, because they know it's what take us longer to revoke (rename the other way, deleting the redirect) if you want recent examples : http://quality.wikimedia.org/w/index.php?title=Special:Recentchanges&limit=250 http://advisory.wikimedia.org/w/index.php?title=Special:Recentchanges&limit=250 This si tiresome for the SWMT and the steward who help them. Is it possibly, even if not throttling yet, to restrict renaming page to autoconfirmed ? It'd be better than nothing.
(In reply to comment #31) > This si tiresome for the SWMT and the steward who help them. Is it possibly, > even if not throttling yet, to restrict renaming page to autoconfirmed ? It'd > be better than nothing. > For the latter please see [[bugzilla:12071]] Best regards
This has been done a while ago; see defaultsettings.php.
I'm resolving this as WORKSFORME since we have a limit, and have had a limit for a long, long time. Suggestions for new types of limit (cross-wiki, by IP group, etc) should go in new, specifically-targetted bugs.
