Last modified: 2014-09-23 22:58:22 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.
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.
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.
(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.
Created attachment 6999 [details] 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.
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.
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.
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.