Basically a global group with the same revoke ability as the local no-ipinfo group. Obviously something only for staff/stewards to manage.

I think this is going to need to be blocked upstream, 2 reasons:

1. Doesn't appear this functionality exists (ability to have a global group with "revoke" permissions)
2. Unclear on the governance model that would be needed for (1) - it appears the primary use case of this would be to override a local project's governance authority (who may or may not do what locally) - this may be necessary and appropriate for certain things on WMF wiki's

A feature request for #1 should be created for the general condition if this is going to be done via global groups with central auth.

Would it be possible to implement this without adding a new user right, please? User rights should not be used to revoke permissions.

In T337189#9252029, @MarcoAurelio wrote:

Would it be possible to implement this without adding a new user right, please? User rights should not be used to revoke permissions.

IMO I don't see any easy way to implement this without using $wgRevokePermissions, because:

• The revoking of the right via this user group means that the existing checks will not need to know that the user has the right revoked. Using any other method will require extra code that checks for revokes.
• I can't see an obvious way to achieve this without adding a new database table.

If you have any suggestions as to how an alternative method would work, I'd be all ears.

@Urbanecm_WMF @Dreamy_Jazz @Tchanders @kostajh I updated this task based on our conversation about this. Please review and update as needed.

We may need to consider how this system works if a user is renamed. Should we expect that users manually update the list or should this be done automatically?

In T337189#10941717, @Dreamy_Jazz wrote:

We may need to consider how this system works if a user is renamed. Should we expect that users manually update the list or should this be done automatically?

It's probably one of those extreme edge cases. Let's go with whichever one is easier/less effort technically.

The old version of ths task, the merged task T309992, T375992 and T375579 all describes one proposed feature: a kind of global partial block for IP reveal and IP info, so that stewards and staffs can block a user globally, potentially without local whitelist allowed, from IP reveal and IP info, for example for abusing IP reveal tool, no matter whether the user has IP reveal access in any local wiki. This would be a kind of global partial block (which currently does not exist). Logs of blocks / global blocks are public. This may be still useful together with the new version described below (since the use cases are different).

However, the new description propose a feature that is effectively a shadow ban that are private to other (non-steward and non-staff) user. The proposed solution (via a page) is currently not possible, given T230668: Fully implement read/view restrictions in mediawiki core (and also merged task). Using blocks (or global blocks) to shadow ban users is currently not a viable way either, given {T280413}. This can neither be accomplished by user group feature, since user groups can not be private.

The updated version actually unified two use cases by one solution (global partial block, which currently does not exist). One point to note is block can be seen as a kind of "bad record" (e.g. some voter eligibility guidelines requires users not be blocked globally or in multiple projects), but this is more like a social issue than a technical one.

Agreed with Bugreporter regarding the viability of hiding the list of users who want to not have access. Additionally:

1. The requirement to hide from everyone except staff and steward conflicts with the point that "CheckUser-UserInfoCard and other relevant places reflect that the user does not have access accurately", as a user could infer a user is on the list by seeing they have the user right but are not marked as having access
2. Adding this restricted viewing functionality would be very complicated and probably not feasible. The other methods we explored implicitly were public in nature

If we must make this list private, then we will need to go back to the drawing board on a solution to use.

In the interim I've removed the part about viewing restrictions.

user could infer a user is on the list by seeing they have the user right but are not marked as having access

This is not fully reliable, e.g. a sysop can have no access because they does not opt in or their access is revoked.

If we collect a list of usernames, it will break once a user is renamed.

In T337189#11004688, @Bugreporter wrote:

If we collect a list of usernames, it will break once a user is renamed.

Yes. The list should be manually updated if that happens since that is a quite rare occurrence.

@Xaosflux @MarcoAurelio @Three_Sixty @Vermont @hoo @Johannnes89 -- We are considering pushing back work on this task until we know for sure that there are users who would benefit from having this feature in place. If you or someone you know would appreciate having this feature, please let us know.

In T337189#11023257, @Niharika wrote:

@Xaosflux @MarcoAurelio @Three_Sixty @Vermont @hoo @Johannnes89 -- We are considering pushing back work on this task until we know for sure that there are users who would benefit from having this feature in place. If you or someone you know would appreciate having this feature, please let us know.

Fine with me. Most users (admins, temporary account IP viewer etc.) can disable their access by just disabling their user preference.
I can't imagine a user in one of the groups with automatic access (Stewards, Ombuds, U4C, and Staff; Checkuser and Oversighter) who really dosn't need temporary account IP access – and those groups have much more sensitive permissions (CU/OS...) which they can't disable either... I believe this task is more of a nice to have, but perhaps I'm missing something.

We still need a way to globally revoke IP reveal / IP info access if the user is abusing it. This may be a global partial block.

In T337189#11025317, @Bugreporter wrote:

We still need a way to globally revoke IP reveal / IP info access if the user is abusing it. This may be a global partial block.

That could also be done by removing the relevant user group? It's hard for me to imagine a scenario where someone abuses IP access but is still trusted with other higher level permissions.

That could also be done by removing the relevant user group

But this does not prevent local admins from adding it back. See also T375992#10384159. A global IP reveal-blocked user should not have any IP reveal right even if they are local sysops.