Last modified: 2014-09-23 22:58:22 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 T22267, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 20267 - Public Autoblock is not hidden on Special:BlockList after hideuser
Public Autoblock is not hidden on Special:BlockList after hideuser
Status: NEW
Product: MediaWiki
Classification: Unclassified
User blocking (Other open bugs)
All All
: Normal major with 2 votes (vote)
: ---
Assigned To: Marc A. Pelletier
: patch, patch-reviewed
Depends on:
Blocks: revdel SWMT
  Show dependency treegraph
Reported: 2009-08-15 18:24 UTC by Church of emacs
Modified: 2014-09-23 22:58 UTC (History)
15 users (show)

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

Patch (1.50 KB, patch)
2010-01-21 11:01 UTC, revvar

Description Church of emacs 2009-08-15 18:24:33 UTC
Consider the following scenario:
1. EvilUsername registers
2. EvilUsername is blocked by an administrator (autoblock is active). Special:BlockList now lists EvilUsername and #number, which is the autoblock of the (nonpublic) IP address. The latter contains the username in the summary ('Autoblocked because your IP address has been recently used by "EvilUsername".')
3. An Oversight user changes the block, adds hideuser (all user contributions are now hidden, as well as log entries containing the username). The block for EvilUsername is now hidden on Special:BlockList, but the autoblock remains public. Remember, that the autoblock on the list contains EvilUsername.

This scenario is not unrealistic, it actually happens quite often, because there are much more sysops than oversight users and it's generally a good strategy to block users with evil usernames as fast as possible, before they have a chance to edit pages (vandalism is usually reverted with rollback, which means that the revert summary contains the evil username and has to be hidden manually). Expecting sysops to wait for an oversighter to perform the block is a non-solution.

There are potentially two ways of solving this:
a) Add an option to hide blocks on Special:BlockList (not prefered, as oversighters must remove the block manually)
b) Automatically hide the autoblock on Special:BlockList after a block with hideuser (prefered solution, though it may be technically difficult to implement it). I don't see any reason for implementing a) if b) was implemented.
Comment 1 Church of emacs 2009-08-15 19:31:45 UTC
EvilUsername is stored as part of a system message in ipb_reason.
b) requires a schema change (a field ipb_autoblock_username or something like that has to be added) OR ipb_reason has to be searched for the evil username (that might be inefficient, but it only happens once, when a user gets blocked with hideuser).

The good thing is that we don't have to fix this problem retrospectively, as autoblocks expire quite fast. Until the problem is fixed, sysops can edit MediaWiki:Autoblocker so that it doesn't add the username to the autoblock comment.
Comment 2 Andrew Garrett 2009-08-15 19:39:07 UTC
I think we'd be better off writing a separate system for autoblocks, it'd have more scope for this kind of thing.
Comment 3 pgrawehr 2009-09-27 12:14:15 UTC
Just a related idea: Maybe it would limit the scope of the problem if only sysops could read the autoblock-log (or at least only they would get the username from it). Even though they're not technically oversighters it can probably be assumed that they won't do anything bad with "EvilUsername" - Someone has seen it, anyway. Personally, I don't see a reason why normal users should need to read the autoblock-log at all. 
Comment 4 Andrew Garrett 2009-09-29 19:40:52 UTC
(In reply to comment #3)
> Personally, I don't see a reason why normal users
> should need to read the autoblock-log at all. 

MediaWiki has the policy of "open by default". You're going to have to come up with better reasoning than that.

Comment 5 pgrawehr 2009-10-04 21:08:18 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Personally, I don't see a reason why normal users
> > should need to read the autoblock-log at all. 
> MediaWiki has the policy of "open by default". You're going to have to come up
> with better reasoning than that.

I know. The reason of course is not that users don't *need* to know this log, but that it may be of privacy concern. Besides the fact, that without this bug fixed, hidden usernames stay visible, this log can also be used to guess about User/IP relationships. This is sometimes really nice for blocking reocurring vandals as done by sysops, but not really something normal users need to worry about. 
Comment 6 revvar 2010-01-21 11:01:06 UTC
Created attachment 6999 [details]

The patch uses the ipb_auto field, to save a reference from all Autoblocks to the first block. Whenever the first block is modified the ipb_deleted field is updated in all Autoblocks.
Comment 7 Aaron Schulz 2011-10-07 00:50:05 UTC
I suppose we need a new ipb_parent_id field and an index so that we can track down spawned autoblocks and adjust them when the main block is alter to be suppressed.
Comment 8 Sumana Harihareswara 2011-11-16 01:23:39 UTC, thank you for your contribution, and  I'm sorry that it took so long for us to respond to your patch.  Could you rebase it against trunk and attach it as a patch per these instructions?

Comment 10 Marcin Cieślak 2012-03-28 21:46:02 UTC
Somehow I like the idea of re-using ipb_auto (this pertains the Gerrit change #3841

The filed could be changed from SMALLINT to INTEGER, given its own index and a foreign jkey constraint.

I don't think it should be removed from UNIQUE index (ipb_address,ipb_user,ipb_auto,ipb_anon_only)

This means that autoblocks resulting from different username block (two evil users sharing a connection:) would expire independently.
Comment 11 db [inactive,noenotif] 2012-10-02 18:39:58 UTC
You can (now) use field ipb_parent_block_id to find these autoblocks on hide action.

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