Should not be auto-promoted to any groups that give them the right(s) to reveal IPs

Alternatively we can have a global equivalent of $wgRevokePermissions (such feature does not yet exist), so even if users are in such groups, they can not use their reveal right. See also T337189: Add ability to centrally revoke IP reveal permissions from users who do not need them for safety reasons

In T375992#10186484, @Bugreporter wrote:

Should not be auto-promoted to any groups that give them the right(s) to reveal IPs

Alternatively we can have a global equivalent of $wgRevokePermissions (such feature does not yet exist), so even if users are in such groups, they can not use their reveal right. See also T337189: Add ability to centrally revoke IP reveal permissions from users who do not need them for safety reasons

Ping @Dreamy_Jazz @Urbanecm for their thoughts.

In T375992#10186484, @Bugreporter wrote:

Should not be auto-promoted to any groups that give them the right(s) to reveal IPs

Alternatively we can have a global equivalent of $wgRevokePermissions (such feature does not yet exist), so even if users are in such groups, they can not use their reveal right. See also T337189: Add ability to centrally revoke IP reveal permissions from users who do not need them for safety reasons

Let's not do that, please. Checking a new checkbox at Special:Userrights is (almost exclusively) used for granting new rights, the only exception being IP Info. Normally, we use Special:Block (or Special:GlobalBlock) for access revocation (or Special:UserRights, if we want to demote an user). I think we should keep those workflows, rather than introducing new ones.

In T375992#10186695, @Urbanecm wrote:

In T375992#10186484, @Bugreporter wrote:

Should not be auto-promoted to any groups that give them the right(s) to reveal IPs

Alternatively we can have a global equivalent of $wgRevokePermissions (such feature does not yet exist), so even if users are in such groups, they can not use their reveal right. See also T337189: Add ability to centrally revoke IP reveal permissions from users who do not need them for safety reasons

Let's not do that, please. Checking a new checkbox at Special:Userrights is (almost exclusively) used for granting new rights, the only exception being IP Info. Normally, we use Special:Block (or Special:GlobalBlock) for access revocation (or Special:UserRights, if we want to demote an user). I think we should keep those workflows, rather than introducing new ones.

+1 to this comment. We have received feedback from stewards that using a group to revoke rights is confusing. I'd rather extend the GlobalBlocking tools to support partial action blocks, such that stewards can globally partially block a user from the tool. This has been seen as much less confusing from a user point of view.

In T375992#10186731, @Dreamy_Jazz wrote:

In T375992#10186695, @Urbanecm wrote:

In T375992#10186484, @Bugreporter wrote:

Should not be auto-promoted to any groups that give them the right(s) to reveal IPs

Alternatively we can have a global equivalent of $wgRevokePermissions (such feature does not yet exist), so even if users are in such groups, they can not use their reveal right. See also T337189: Add ability to centrally revoke IP reveal permissions from users who do not need them for safety reasons

Let's not do that, please. Checking a new checkbox at Special:Userrights is (almost exclusively) used for granting new rights, the only exception being IP Info. Normally, we use Special:Block (or Special:GlobalBlock) for access revocation (or Special:UserRights, if we want to demote an user). I think we should keep those workflows, rather than introducing new ones.

+1 to this comment. We have received feedback from stewards that using a group to revoke rights is confusing. I'd rather extend the GlobalBlocking tools to support partial action blocks, such that stewards can globally partially block a user from the tool. This has been seen as much less confusing from a user point of view.

And we can also replace the no-ipinfo group too. Also,

• We need T355385: Allow marking global blocks not disablable by local wiki so that such block can not be disabled by local wikis.
• In some case we need to globally block the user for other reason, or if IP Reveal block and IP info block are two different types of blocks, block a user for both of them. So we also need global Multiblocks.

Stalled pending discussions with Stewards, which @Niharika will lead.

In T375992#10378231, @Niharika wrote:

I haven't heard any objections to using partial blocks for implementing this workflow from stewards over Discord. I think this can go into the design phase now. CC @KColeman-WMF

We can add an additional checkbox that says "Revealing an IP address" to Partial block radio button checkboxes.

@Dreamy_Jazz I can't see Global Block page so not sure where the checkbox would appear on that page. Happy for you to add it where you feel it makes most sense!

Could we scope this to local blocks, rather than adding a global block?

It becomes quite a big project if we need to make GlobalBlocking handle partial blocks. If we do need to do this, it would be more feasible to do it in time for rollout to all wikis than for major pilots.

In T375992#10381397, @Tchanders wrote:

Could we scope this to local blocks, rather than adding a global block?

It becomes quite a big project if we need to make GlobalBlocking handle partial blocks. If we do need to do this, it would be more feasible to do it in time for rollout to all wikis than for major pilots.

I do agree that this would be a project that would take a fair amount of time. However, I would note that it would make it difficult for stewards to revoke access for all wikis if we only implement it for a local block.

@Urbanecm and I talked through this one. Based on our conversation it makes sense to make global revocation a blocker to major pilots deployment.

Here's our thinking behind this decision: Without this feature, it would be very hard for stewards to handle cases of global abuse of IP Reveal access. A user may be active on several wikis (we saw the example of @Urbanecm's account which holds 300+ edits on 24 wikis). Without global revocation, a wiki-by-wiki revocation would need to be carried out. This could mean bringing the decision to the admins on some wikis which may even be rejected. Stewards will not be able to force-revoke access even if it is needed. This poses a risk of LTAs being free to abuse IP address access. An alternate stewards could resort to is to globally block the user, which is a much stricter measure than IP Reveal access and risks alienating users who have a chance at redemption.

In T375992#10381178, @KColeman-WMF wrote:

In T375992#10378231, @Niharika wrote:

I haven't heard any objections to using partial blocks for implementing this workflow from stewards over Discord. I think this can go into the design phase now. CC @KColeman-WMF

We can add an additional checkbox that says "Revealing an IP address" to Partial block radio button checkboxes.

@Dreamy_Jazz I can't see Global Block page so not sure where the checkbox would appear on that page. Happy for you to add it where you feel it makes most sense!

The GlobalBlock page looks like this, with no mention of partial blocks since they're not currently possible globally:

We could probably benefit from some help about how to display a partial block option, and whether to split these options into sections like Special:Block, etc.

Thanks for the additional context @Tchanders! My first thought is that yes, we should mirror Special:Block for consistency, so we would introduce block type (Sitewide or Partial).