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.

dodgy wrote:

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.

carbonite.wp wrote:

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?

who wrote:

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?

josh wrote:

(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?

ilyanep wrote:

(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.

alphasigmax wrote:

(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.

chris.mckenna wrote:

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]]

wiki.bugzilla wrote:

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.

p_simoons wrote:

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.

p_simoons wrote:

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.

nick_tarleton wrote:

Support throttling to something like 1 per 10 seconds - a reasonable balance.
Admins should be exempt. We really need this yesterday.

usenet wrote:

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.

WikiMan wrote:

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.

ayg wrote:

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.

ayg wrote:

*** Bug 6978 has been marked as a duplicate of this bug. ***

ayg wrote:

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?)

alphasigmax wrote:

(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.

blah wrote:

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

ayg wrote:

(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 . . .)

psychonaut wrote:

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. ***

koneko wrote:

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.

spacebirdy wrote:

(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.