Last modified: 2012-08-03 13:52:58 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 T4879, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 2879 - Enforce/encourage upper limits for block times per IP range
Enforce/encourage upper limits for block times per IP range
Status: NEW
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.5.x
All All
: Low enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Special:...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-16 11:46 UTC by Joost R. Meerten
Modified: 2012-08-03 13:52 UTC (History)
3 users (show)

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


Attachments

Description Joost R. Meerten 2005-07-16 11:46:45 UTC
On [http://en.wikipedia.org/wiki/Special:Blockip], a list of IP ranges is given
where blocks should not last more than 15 minutes, because these ranges contain
rotating proxies that may lock out many more users than the original blockee.

Manual enforcement of this constraint has shown to be ineffective. Legitimate
users are getting blocked on a daily basis by careless admins who slap lengthy
(or even indefinite) blocks on people without checking, no matter how bold and
obnoxious the warnings are.

This restriction ought to be implemented in software, similar to the spam black
list, where admins could specify upper limits for block times per IP range. A
simple two-column text file would do. The software could then display a big fat
warning and require another confirmation before allowing any block that exceeds
the limit.
Comment 1 Toby Bartels 2005-08-04 18:59:01 UTC
There is some documentation of the repeated collateral damage to one user (which
this would fix) at [[w:en:User:WBardwin/AOL_Block_Collection]].
Comment 2 Chad H. 2009-07-01 14:45:22 UTC
Suggest WONTFIX (especially enforcement of such a limit). There are certainly cases when indef-blocking an IP address is legitimate. Many wikis might adopt a more hardline approach to indef-blocking, and throwing an error/warning message on every attempt at indef-blocking seems to be more annoying than helpful.

I would suggest that enwiki A) Customize their block page info to include a note about indef-blocking IPs--if they don't, I haven't read it in awhile, and/or B) Perhaps put in some site JS to enforce/encourage such a limit.
Comment 3 Toby Bartels 2009-07-01 15:51:02 UTC
I don't understand Chad's reasoning.  If a wiki doesn't want to use this feature, then it wouldn't have to.  Although I didn't write the original request, I don't read it as hard-coding the IP ranges into the software; instead, the administrators of the wiki would add IP ranges to a wiki-specific list with suggested upper limits for block times.  Those wikis that wish to allow indefinite blocking of all IPs without warning could still do so.  And of course, even the English Wikipedia would allow indefinite blocking of most IPs, even if this were to be fully implemented there.

It is true that [[Special:Block]] at that wiki no longer has text about 15-minute limits; I'm not sure that any of those apply anymore.  Instead, there is some even more serious text about alerting the Wikimedia Foundation when blocking government IPs!  A feature that allowed wikis to include warning messages when blocking certain IPs for certain lengths of time would be very useful for that as well (as it could throw up the warning for blocking these IPs for any length of time whatsoever).
Comment 4 Chad H. 2009-07-01 15:56:43 UTC
I missed the part about using a list of IPs, I read it as "enforce some arbitrary upper limit on all IP blocks." I didn't have my caffeine this morning :-\

Still not terribly convinced of the usefulness, however.

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


Navigation
Links