Page MenuHomePhabricator

rate limit edits and moves
Closed, DeclinedPublic

Description

Author: William.Allen.Simpson

Description:
So, for example, we see see "User:Thing that goes on feet"
create a new user on 2006-06-20 07:38:17, make no contributions
for over a week, and suddenly do nearly 100 moves from 2006-07-01
13:46:01 to 13:52:55.

That's right, as many as 4 moves per second!

So, I propose 2 things:

No bot or editor or administrator should be able to do more than
1 move per minute. Just reject them. That should be easy to do
in software.

No bot or editor should be able to do more than 1 edit per 20
seconds. Just queue the edit until the time has elapsed. Of
course, administrators should be able to go faster, as they
may be hurrying to fix a problem.

Heck, these days I often have to wait half a minute to see the
response anyway. But I've noticed "edits" at a rate of 2-3 per
second from "normal" editors at times, and when confronted they've
claimed they aren't using a bot. Maybe not, but slow them down
enough that others can notice the changes and react in human time
frames.


Version: unspecified
Severity: enhancement

Details

Reference
bz6513

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:16 PM
bzimport set Reference to bz6513.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

There's support for rate limiting various actions in the code, but I was
informed that, somewhere along the line, it was switched off on Wikimedia wikis
due to incompatibilities with our shared memory caching system/opcode cache. If
this is correct, then we're going to need to look into a complete rewrite of
most of it.

robchur wrote:

I've been advised that the rate limiting code works. Requests to alter the
thresholds should be made in the same vein as other configuration requests.