Last modified: 2008-03-24 20:53:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3454, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1454 - Page moves should be throttled to say 1 per minute for non-admin users
Page moves should be throttled to say 1 per minute for non-admin users
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.6.x
All All
: Normal enhancement with 13 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 6978 11968 (view as bug list)
Depends on:
Blocks: 6513
  Show dependency treegraph
 
Reported: 2005-02-02 21:24 UTC by Neil Harris
Modified: 2008-03-24 20:53 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Neil Harris 2005-02-02 21:24:53 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.
Comment 2 Invalid Account 2005-08-25 17:22:38 UTC
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.
Comment 3 Carbonite 2005-08-25 17:33:29 UTC
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?
Comment 4 Brian Laura 2005-08-25 17:34:45 UTC
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.
Comment 5 Brion Vibber 2005-08-25 18:48:01 UTC
Page moves are already throttled to 2 in 120 seconds for new users.
Comment 6 Robert Rohde 2005-08-25 19:23:29 UTC
(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?
Comment 7 jpgordon 2005-08-25 19:27:27 UTC
(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.) 
Comment 8 Robert Rohde 2005-08-25 21:05:50 UTC
(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?
Comment 9 Ilyanep 2005-08-25 21:22:13 UTC
(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/>/< ?
Comment 10 Robert Rohde 2005-08-25 21:33:55 UTC
(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.
Comment 11 Cesar Eduardo Barros 2005-08-25 21:38:16 UTC
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.
Comment 12 Alphax 2005-08-26 13:28:16 UTC
(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.
Comment 13 Chris M 2005-08-26 15:09:23 UTC
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]]
Comment 14 bdk 2005-08-26 15:32:33 UTC
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. 
Comment 15 Chris McKenna 2005-08-26 19:37:21 UTC
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. 
Comment 16 Robert Rohde 2005-08-26 21:36:33 UTC
(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.
Comment 17 p_simoons 2005-08-30 17:34:42 UTC
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.
Comment 18 p_simoons 2005-09-01 10:35:41 UTC
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.
Comment 19 Nick Tarleton 2005-09-04 03:29:02 UTC
Support throttling to something like 1 per 10 seconds - a reasonable balance.
Admins should be exempt. We really need this yesterday.
Comment 20 Neil Harris 2005-09-04 08:17:59 UTC
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


    
Comment 21 Brion Vibber 2005-09-04 22:23:23 UTC
Neil, we already have a move throttle.
Comment 22 BrokenSegue 2005-09-18 16:08:51 UTC
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. 
Comment 23 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-04-09 03:43:42 UTC
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.
Comment 24 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-11 18:09:03 UTC
*** Bug 6978 has been marked as a duplicate of this bug. ***
Comment 25 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-11 18:20:29 UTC
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?)
Comment 26 Alphax 2006-08-12 08:39:35 UTC
(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.
Comment 27 blah 2006-08-13 02:40:39 UTC
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
Comment 28 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-13 03:18:17 UTC
(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 . . .)
Comment 29 Tristan Miller 2006-10-21 00:27:50 UTC
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.
Comment 30 Filip Maljkovic [Dungodung] 2007-11-16 10:59:12 UTC
*** Bug 11968 has been marked as a duplicate of this bug. ***
Comment 31 Darkoneko 2007-11-23 09:46:26 UTC
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.
Comment 32 spacebirdy 2007-11-23 11:32:25 UTC
(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

Comment 33 Aaron Schulz 2008-03-24 20:51:56 UTC
This has been done a while ago; see defaultsettings.php.
Comment 34 Brion Vibber 2008-03-24 20:53:38 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links