Hi @Niharika (Sr. Product Manager, Anti-Harassment Tools team)

What do you think about this?

The simplest way to implement this idea for Wikimedia wikis would be to add the 'ipblock-exempt' right to the Bots, Autopatrollers, and Administrators groups (or their local equivalents in the given wiki). This actually could be done as a local wiki decision as well without a movement wide decision/recommendation from the Foundation.

In T309328#8284341, @bd808 wrote:

The simplest way to implement this idea for Wikimedia wikis would be to add the 'ipblock-exempt' right to the Bots, Autopatrollers, and Administrators groups (or their local equivalents in the given wiki). This actually could be done as a local wiki decision as well without a movement wide decision/recommendation from the Foundation.

Probably. Anyway the part that registers ipblock-exempt should consider these better defaults, considering that blocking logged-in & trusted users is clearly a good faith mistake, not a design choice.

This is not a technical matter but rather a *very wide* policies-related change which requires proper discussion on the relevant projects.

@Vituzzu: Yeah but also blocking autopatrol-flagged and bot-flagged users from an IP-block-range would also merit a proper discussion, which I have not found.

I think stewards are affected too BTW.

In T309328#8382082, @valerio.bozzolan wrote:

@Vituzzu: Yeah but also blocking autopatrol-flagged and bot-flagged users from an IP-block-range would also merit a proper discussion, which I have not found.

FYI: https://meta.wikimedia.org/wiki/NOP

@Vituzzu before rollbacking my changes in the Task I created, can you be so kind to explain why you don't agree with that assertion? The assertion was: Open proxies are blocked to fight spam, from anonymous users, as well from users with just the e-mail self-verified.

In T309328#8382746, @valerio.bozzolan wrote:

@Vituzzu before rollbacking my changes in the Task I created, can you be so kind to explain why you don't agree with that assertion? The assertion was: Open proxies are blocked to fight spam, from anonymous users, as well from users with just the e-mail self-verified.

You wrote " this paper [sic] supports this proposal...range-blocks were designed". Which is definitely out of the policy letter and ratio:

1. we are not dealing with rangeblocks but a set of blocks done according to NOP
2. the purpose is to counter the effect of "[open proxies allowing] users to completely circumvent administrators."
3. the policy states that "While this may affect legitimate users, they are not the intended targets and may freely use proxies until those are blocked. Tor editing, on the other hand, is automatically prevented." (emphasis is mine) which is quite different from most of the subsequent claims
4. Editors can be permitted to edit by way of an open proxy with the IP block exempt flag. This is granted on local projects by administrators and globally by stewards. is the most important point: usage of open proxies and similars is subject to community approval, which can't be circumvented through mw configs changes.

Nobody is trying to open wikis to open proxies. Simply, if Jimmy Wales is logged in, it shouldn't matter if he's from his home or from a strange IP. He's still Jimmy Wales, so no reason to stop him from editing.

I also think that, at the moment, "WMF Support and Safety" and "WMF Office IT" can be affected by IP-based block on Meta-wiki. This seems a bit too risky to me.

I agree with Vituzzu. This is not a technical matter. It should be discussed in global RFC etc instead of here. Thanks.

I agree that a discussion is necessary.

But the question is: where is the current consensus about blocking authorized bots and autopatrollers?

Hi @RAdimer-WMF! Thank you for your help again. I've I searched again... and found no consensus on the current implementation of the IPBlock: I was not able to figure it out why bureaucrat(s), (trusted-)bot(s) and autopatrolled (people whose changes are automatically marked as verified), and maybe more trusted users, are affected as default by IPBlock. Are you also concluding on this result? Thank you

@valerio.bozzolan Hi! Sorry for my late reply. I agree with @Vituzzu and @SCP-2000 that this needs to go through a community approval process before it can be implemented. I'm sorry, I know that isn't a very satisfying answer. I have studied the problem of IP blocks and understand the extent of the impact. However this is a community decision ultimately.

Oh sorry me @Niharika, I actually did not want to presume to ask a systemic change from you.

However I think that your help is absolutely precious in gathering some details about the current consensus, that led to the current implementation.

During the Wikimedia Hackaton 2023 in Athens I had some interesting discussion about this topic.

In a moment, I played a small game to some closest friend. I "blocked" (jokingly) some of these friends nearby a specific exit door (among many other available doors). Saying in a very kind way:

Uh :) Hello logged-in Mario Rossi with <sysop / ...> privilege! Even though I know you are an trusted user registered since 2001, even if I know that you had 1 billion positive contributions in this wiki, since you are trying to exit from this specific door (that unfortunately is used by many other untrusted spammers), please perform the unblocking procedure using the following indications, for SECURITY REASONS. Or, exit from another door if you want to continue your work. I hope you will understand that, if you exit from this door, we cannot rely you anymore for SECURITY REASONS.

Everyone looked at me like

:( Come on, Valerio, this has no sense. You know it's me. Let me exit from this door. I'm already here. I don't want to go the long way around, at night, which is less safe to me.

That was really a joke, but is just to say: the current situation seems to make sense, but when it happens to you as logged-in, it is clear that it doesn't make much sense.

I think that all interface admins, CUs and bureaucrats usually (if not always) are admins, no? Perhaps it’d be redundant to include IPBE in those groups, then.

What do you suggest @Frostly?

Premising that, as far as I understand, the community of CheckUsers very much like the current "bug" that "blocks everyone in the damn planet including registered users, including autopatrolleds, including ...". So, while the situation could be improved (that is not acceptable honestly to me as-is) as compromise we should think about how to still give to our dear CheckUsers the ability to monitor the situation of registered users (so, CU should be able to "spy" whatever sysop that is exiting from non-predictive Internet nodes like "open proxies", for whatever is their weird legitimate investigative reason to explain such invasive eye on trusted "coworkers"...)

In T309328#9058415, @Frostly wrote:

I think that all interface admins, CUs and bureaucrats usually (if not always) are admins, no? Perhaps it’d be redundant to include IPBE in those groups, then.

At some site, no, like nlwiki (cu)

In T309328#9058626, @valerio.bozzolan wrote:

Premising that, as far as I understand, the community of CheckUsers very much like the current "bug" that "blocks everyone in the damn planet including registered users, including autopatrolleds, including ...". So, while the situation could be improved (that is not acceptable honestly to me as-is) as compromise we should think about how to still give to our dear CheckUsers the ability to monitor the situation of registered users (so, CU should be able to "spy" whatever sysop that is exiting from non-predictive Internet nodes like "open proxies", for whatever is their weird legitimate investigative reason to explain such invasive eye on trusted "coworkers"...)

Hi Valerio. This is not a bug. Autopatrolled users are intentionally affected by IP blocks.

I'm also quite confused on what you mean by "such invasive eye on trusted 'coworkers'".

Autopatrolled users are intentionally affected by IP blocks.

I imagine but can you please link a community discussion (pre-implementation) that states so? That would be useful.

I'm also quite confused on what you mean by "such invasive eye on trusted 'coworkers'".

I tried to say that surely I can understand that CU users could have a "whatever ... weird legitimate investigative reason" to monitor "trusted wiki coworkers", like bureaucrat or interface admins etc.

But, the current implementation has overkill parameters.

The root Problems

1. ✅ mitigate spam in Wikimedia Project
   • 100% consensus on that. This explains why new users and IP should be impacted.
2. 🔶 identifying logged-in trusted accounts that may be just "ninja sock-puppets of long-term problematic blocked users"
   • this deserves a clear explanation. Again, a link pointing to an old discussion would be useful. Since this has surely the most controversial side-effects if described in the wrong way.

Even if we agree on both problems, we SHOULD agree that the current implementation is a problematic solution:

🔴 Blocking everyone, including trusted users, seems that can be used to find "ninja sock-puppets of long-term problematic blocked users" but it just blocks them from that Internet node. So, they leave no edit track, we simply lose activity information that could be potentially useful for check users. In the meanwhile the "malicious user with trusted flags" continue to operate for a very long-time, unnoticed, using other pathways. Since, of course, if the malicious user detects the block, we cannot supposed that it's stupid enough to fill a range block exception request, to the attention of the most privileged and skilled users in the website.

→ This anti-sockpuppet workflow is too much invasive for crazy benefits.

Actionable Things

Imagine a world where check users receive alarms based on "edit coming from logged-in user, with trusted flags, from open proxy" and so can further investigate, eventually allowing to drop any trusted flag, and/or block that user.

This could be implemented with an edit Tag called "Edit from Open Proxy" or something similar.

This would of course allow to immediately re-tune the range-blocks, to only affects IPs, and non-autopatrolleds.

So probably this is actionable:

• untrusted accounts (not logged-in / freshly registered) are blocked (AS-IS)
• trusted accounts (autopatrolleds) are blocked just tagged. If the user has the IPBE flag, the user is also untagged.

The best next step would be to open a global RFC gaining consensus for what user groups should include the ipblock-exempt flag (and/or sfsblock-bypass and torunblocked).

The best next step would be to open a global RFC

Nice idea.

But have you any clue about where the current implementation was originally discussed?

I'm not able to find that as supposed sub-page 🤔

https://meta.wikimedia.org/w/index.php?title=Special:Search&limit=500&offset=0&ns0=1&sort=create_timestamp_desc&search=ip+range+blocks+subpageof%3A%22Requests+for+comment%2F%22&sort=create_timestamp_desc&advancedSearch-current={%22fields%22:{%22subpageof%22:%22Requests%20for%20comment/%22}}

I gave this ticket a more thorough read, and there are some points I would like to clarify.

It is not accurate to say that certain user groups are not considered trusted, simply because they are affected by IP blocks. It is more accurate to say that IPBE is bundled with the admin toolkit, because they can grant that userright. In other words: IPBE is not given out to every user group considered "trusted"; it is a fundamentally separate user right from the others.

If a user is affected by an IP block, they can request an exemption. Each project has different processes and criteria for these exemptions, as well as globally, and many projects do not give it out without legitimate reason. The "reason for still blocking" you, as you put it, is that you don't have IPBE. Ask an admin for it. If they say no, you have your answer both for your own contributing and for your proposal here.

Your argument is functionally the same as: why should an interface-admin not be able to review pending changes? (if they don't have the pending changes reviewer right) The answer: they are two separate rights. There is no conspiracy to prevent interface admins from reviewing pending changes. They just have to make a separate request.

Wikimedia projects overwhelmingly distribute rights on a basis of need: if someone needs a user group for their work, they can request it from elected community members, who can grant it. Wikimedia projects do not operate on a binary yes/no trust basis, i.e., there is no "trusted users" cohort like you mention in your initial proposal. Rather, people are trusted for specific things; if someone is trusted for editing through a VPN, an admin can grant them the requisite user right.

I initially wrote a rather long paragraph here about your comments regarding the CheckUser tool, process, and relation to IP blocks. To focus on the IPBE question, I've removed it. The short version is that your comments significantly mischaracterize the intent, function, and result of CheckUser actions and range blocks. I believe this misunderstanding explains why you believe CUs use the tool to spy on people, and would urge you to read more into CU policy and process before writing off some of the most trusted and dedicated users on Wikimedia as bad faith. If these concerns stem from a specific incident regarding CU tool usage, it may be pertinent to report it to the Ombuds Commission, who enforces the relevant policies.

As for steps forward: If you want to make this into an RfC, it should be local, not global. Proposing a global rights change of this size is not going to work, because of the sheer amount of participation that would be needed to make a change like this. If there is local consensus to add IP block exemption to some user groups, then that might work.

Thank you for your help in understanding the current requirements from a "wiki admin" perspective.

I have nothing against CU users. I was never involved in that AFAIK.

I'm just against: bulk-blocking registered users without any strong reason and context not included in:

1. user created spam
2. user created copyright issue
3. user is a sock-puppet of a blocked user
4. user insults
5. .....

And, "the registered InterfaceAdmin / BotAuthorized / ... / used a VPN" it's just a borderline super-nonsense reason to block somebody from editing.

People are trusted for specific things

Exactly. Autopatrolleds are trusted for editing while logged-in. And we block them now.

There is surely an historical good faith reason, but where? We have not found any RFC and any discussion about that. And reading that discussion would be somehow a must before opening another one.