Page MenuHomePhabricator

Public Autoblock is not hidden on Special:BlockList after hideuser
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: major

Details

Reference
bz20267

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:51 PM
bzimport set Reference to bz20267.

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.

I think we'd be better off writing a separate system for autoblocks, it'd have more scope for this kind of thing.

pgrawehr wrote:

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.

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

pgrawehr wrote:

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

revvar wrote:

Patch

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.

Attached:

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.

sumanah wrote:

revvar@gmx.de, 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?

https://www.mediawiki.org/wiki/Patch#Posting_a_patch

Thanks.

sumanah_panixcom wrote:

content hidden as private in Bugzilla

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.

You can (now) use field ipb_parent_block_id to find these autoblocks on hide action.

@coren, this is one of the oldest tasks assigned to someone. Are you planning to work on it, and is its current priority correct?

I cannot currently reproduce this on my test wiki.

User:Saper sysop and bureacrat flag with $wgGroupPermissions['bureaucrat']['hideuser'] = true;

User:NormalAdmin is a "normal" sysop without hideuser

I have blocked EvilUser with hideuser and autoblock and also user Test1 without hideuser and autoblock

EvilUser's IP address got automatically blocked (with #2) and was not visible for User:NormalAdmin in Special:BlockList

Test1's block was visible. If both Test1 and EvilUser operate from the same IP address, visibility depends whose
autoblock was first - if EvilUser (hidden) was the reason, the block is hidden.
If Test1 (not hidden) was the first user blocked from the given IP, the autoblock is visible to all.

I have also tested post-factum autoblock and EvilUser's new IP address (block #13) is not visible on Special:BlockList to User:NormalAdmin. It can be seen by User:Saper

So it seems to me the current behaviour in trunk is correct.