Page MenuHomePhabricator

HideUser : Admin-view level
Open, LowPublicFeature


Author: oversight-wp

HideUser could use the Admin-view permission level, which is currently available on RevisionDelete but not HideUser. Currently usernames can only be suppressed, including from admin-view, which presents a problem of all-or-nothing when it comes to dealing with abusive usernames and policy matters.

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:54 PM
bzimport set Reference to bz21097.
bzimport added a subscriber: Unknown Object (MLST).
  • Bug 21129 has been marked as a duplicate of this bug. *** wrote:

Copying my comment from #21229:

Usernames are the only place on the wiki where the choice is ignore or fully suppress.

As a result, faced with severely offensive "trolling" usernames being set up, a liberal stance is being followed across a range of projects (I'm told) whereby these are being full-suppressed. This isn't just enwiki, it should be noted.

Suppression is a very extreme action. Right now if those posts were anywhere else, they'd be admin-deleted or admin-level RevDeleted by those with access to such tools.

Admin-level username hiding would match the rest of RevisionDelete which includes in every other function, both admin- and oversight- level removals, so that suppression can be kept once again to its tightly limited remit, and not be used on mere "offensive posts". wrote:

It looks like HideUser information is actually duplicated: a "hiddenname" flag
is set in the block log, and the ipb_deleted field is also set. However, it
doesn't *look* like that field has been repurposed as a bitfield yet; it easily
could be, although there wouldn't be the 'usual' stuff to selectively

There is no need to waste time prettifying user lists by hiding usernames. This wasn't designed for that.

lar wrote:

Um.... user names can contain PII serious enough that they need to not be visible at all, even to admins. This bug is asserting that user names can also contain things that are bad enough that the general population should not see them, but not so bad that admins cannot. This is analogous to all other types of information that now is hideable, there are three classes of visibility. Therefore I don't think RESOLVED WONTFIX is a good resolution.

Re-opening. Not saying this should be a high priority, but I don't think it's a "never gonna happen so stop asking" thing.

oversight-wp wrote:

What's happening here is that we have vandals who are trying to test the borders of the policy. Therefore they are deliberately creating usernames that would not have technically passed the border but harass editors who then come to us with the problem, in some cases with several edits being scattered around.

thatcher131 wrote:

A. The stewards, and some enwiki oversighters, have used suppression EXTENSIVELY to hide vandal user names. If you have oversight permission, go to special:listusers and look for "MONGO"; there are 100+ hidden user names. Or "SlimVirgin" (20+), "Voice of All" (5), "FT2" (about 15). Or parse the last thousand or so entries in the suppression log. Some of these names contain personal information and are correctly suppressed, many do not.

B. Enabling HideUser for all admins would expose hidden user names that contain personal information to all admins rather than restrict that information to oversighters. If HideUser is going to be made available to admins, it must be a two-tiered system.

C. Even if enwiki Arbcom and Auditcom enforce stricter standards over enwiki oversighters, we have no control over the stewards. The current use of suppression to hide attack user names is far outside the written Meta:Oversight policy.

D. Rather than implement a technical solution, change the policy to reflect how suppression and HideUser are really being used. If there are strong objections to HideUser being used so liberally, stewards and oversighters would have a responsibility and a duty to listen to the community and stop doing it. If no one objects, then there is no reason to stop and no reason to open it up to admins.

kudu wrote:

(In reply to comment #8)

C. Even if enwiki Arbcom and Auditcom enforce stricter standards over enwiki
oversighters, we have no control over the stewards. The current use of
suppression to hide attack user names is far outside the written Meta:Oversight

Not so. The use of local oversight by stewards *is* within ArbCom's jurisdiction.

To follow the existing schema, the new rights should be "hideuser" (admin) and "suppressuser" (oversighter / old hideuser).

Came here looking for a bug on this. I'm startled to see that one was filed in 2009 and hasn't even been commented on since 2011.

The first 500 items of Special:ListUsers on enwp should demonstrate why this needs to be implemented.

Rxy moved this task from Backlog to ToDo on the User-Rxy board.
Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:01 AM
Aklapper removed a subscriber: TBolliger.

I know that this feature request is old, but I'd like to poke this request and add that I truly believe that this should get another set of eyes and some attention and consideration. :-)

MarcoAurelio added a subscriber: aaron.

Tagging MediaWiki-Blocks (since this is what is being requested here: a new blocking option) and adding Anti-Harassment team tag as code stewards per Developers/Maintainers. Revision deletion doesn't seem to have any code steward but it has @aaron listed as maintainer there.

To avoid repetition, I find that arguments above in support of this option are sound and persuading, and as administrator and steward it would be benefitial to have an intermediate approach to deal with usernames that, without being so egregious to warrant full suppression, are still bad enough to merit being hidden and visible only to administrators.

Thank you.

Thinking out loud, probably the current hideuser permission assigned to local oversighters should be renamed to suppressuser (or other more suitable name to be decided) and use hideuser for this, to properly differentiate between the two levels of hidding if this feature gets built. Thanks.

+1 MarcoAurelio. I always found the name hideuser very confusing. (Same for Abusefilters logs suppress right, which is named abusefilter-hide-log…)

The feature proposed in this Task is part of a current 2023 Community Wishlist proposal too.