Page MenuHomePhabricator

IP range-blocks should not block trusted logged-in users (autopatrolled, bot, bureaucrat, checkuser, interface-admin, steward)
Open, Needs TriagePublic

Description

In short

IP range-blocks were designed to block some untrusted users (like untrusted fresh users / untrusted anonymous ...) and this is useful.

Problem: IP blocks also may interrupt the activity of highly trusted logged-in registered users, causing unnecessary bureaucracy to them.

Current consensus

There is probably insufficient consensus for the current implementation: for example, the fact that an interface-admin can be blocked by an IP range-block, is probably a good faith bug, and not a feature.

If you have some links describing this as a feature, instead of as a bug, thank you for sharing, for example in a comment.

Why we have IP blocks

IP-based blocks were designed to block anonymous spammers or new spammy users connecting from well-known IP addresses (opened proxies, server farms etc.) so they cannot create new users and they cannot edit and disrupt the projects. This goal is often achieved using global IP range blocks.

At the moment, as default, IP range blocks can block all of them as if they were the same thing:

  1. unregistered users
  2. freshly-registered users
  3. logged-in users with specific trusted flags ("veterans")

But these three scenarios are not the same things.

Note: this Task is only about discussing the point n. 3 - leaving the rest of the implementation as-is.

What are the trusted users that should not be blocked by default?

Here a list of trusted user groups that, at the moment, and as default, can be affected by IP blocks even if they are logged-in (and we want to change this).

Roles defined in Wikimedia without any IP-block exemption:

Roles defined in MediaWiki without any IP-block exemption:

All these user roles are trusted, and the origin of their Internet connection should have no impact in their operations.

Status

  • figure out what discussion led to blocking even checkusers, autopatrollers etc. from IP block ranges
  • Improve MediaWiki default permissions to trust these roles as default (and assure that also in Wikimedia are trusted)
    • autopatrolled
    • bot
    • bureaucrat
  • Improve Wikimedia family to trust these roles as default:
    • checkuser
    • interface-admin
    • steward

Emotional context

Some months ago, for the second time, the activity of one of my bots (authorized as bot by more than 3 communities) was blocked just because I was inside a global IP range-block (designed to block other anonymous spammers). I honestly was shocked and frustrated, since it seems going through a validation chain and obtaining a flag is usefulness and I was considered like a "random IP spammer". This honestly made me stop editing for quite some time, to then understand that there is a bureaucratic procedure to apply for a global-ipblock-exempt flag on my bot account. To be honest this made me even more sad and frustrated. BTW the community was awesome and approved my flag and I'm now exempted. Anyway I don't like to fix a bug just for me.

Users with the autopatrol flag (trusted contributors whose edits are automatically marked as patrolled), like all users with the bot flag (trusted technical contributors) at the moment are not considered trusted from the IP range perspective. So, autopatrolleds and bots have to manually triage their block and fill a request form (some are public, some are private, both are shared with someone) in order to be manually re-trusted, asking a global-ipblock-exempt flag (in addition of their role), and wait for approval, to then turn back operative normally again, just because a new IP range block affects their Internet origin.

This is bad for a number of reasons:

  • blocking logged-in trusted technical contributors with the bot flag is just never useful
    • reliability comes from their username, not the Internet behind them. Bot users should be able to always operate, using whatever private servers, VPN, proxy, etc. not just because we should assume they know what they are doing, but because we assume these advanced users are not spammers.
    • interrupting a trusted bot's work without a strong reason causes disruption of community services, instead of helping the community fighting spam
    • unblock requests from bot accounts waste Stewards' time as well, since all bot flags are false positives
    • if a bot starts doing vandalism you could just drop its flag
    • the physical location of some IT services is sometime best to be left undisclosed ("checkusers" aside obviously)
    • avoiding asking for forms with one's IP helps maintain a project with less unuseful sensitive information inside
    • a bot-flag community approval process is usually not fast and not funny. Having to redo more bureaucracy to work can be frustrating
  • blocking all trusted users with the autopatrolled flag is not sufficiently justified too
    • there is no evidence to show that autopatrolled users become spammers when they come from strange IPs. Therefore it seems a nonsense penalization.
    • If the user is spamming, just remove the autopatrolled flag.
    • moreover, autopatrollers may have not the technical skills or enough time to understand what a "range-block" is and why they are blocked, why they need to be re-trusted, how to do it. Again, this wastes volunteers' time and it doesn't help the project to fight spam.
    • Wikipedia was designed to protect the IP of all registered contributors, so there really must be a good reason to force the registered contributors to share their IP in whatever form.
    • decreasing unuseful unlock requests mitigates social engineering

And I could go on. But feel free to share a feedback.

Event Timeline

valerio.bozzolan added a subscriber: Niharika.

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.

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.

valerio.bozzolan renamed this task from Range IP blocks should not block trusted logged-in users (autopatrol, bot, sysop) to Range IP blocks should not block trusted logged-in users (checkuser, steward, bureaucrat, autopatrol, bot).Nov 9 2022, 9:47 AM
valerio.bozzolan updated the task description. (Show Details)

I think stewards are affected too BTW.

@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.

@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.
valerio.bozzolan renamed this task from Range IP blocks should not block trusted logged-in users (checkuser, steward, bureaucrat, autopatrol, bot) to IP range blocks and trusted logged-in users (autopatrolled, bot, bureaucrat, checkuser, interface-admin, steward).Nov 9 2022, 3:18 PM
valerio.bozzolan updated the task description. (Show Details)

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 renamed this task from IP range blocks and trusted logged-in users (autopatrolled, bot, bureaucrat, checkuser, interface-admin, steward) to IP range-blocks should not block trusted logged-in users (autopatrolled, bot, bureaucrat, checkuser, interface-admin, steward).Tue, Mar 7, 2:02 PM
valerio.bozzolan updated the task description. (Show Details)

@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.