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:

• (mediawiki · meta-wiki) checkuser
• (mediawiki · meta-wiki) interface-admin
• (mediawiki · meta-wiki) steward

Roles defined in MediaWiki without any IP-block exemption:

• (mediawiki · meta-wiki) autopatrolled
• (mediawiki · meta-wiki) bot
• (mediawiki · meta-wiki) bureaucrat

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
  • https://meta.wikimedia.org/wiki/No_open_proxies (it does not mention why logged-in autopatrollers should be affected by this block, etc.)
  • https://meta.wikimedia.org/wiki/Talk:No_open_proxies/Unfair_blocking (it only mentions complaints from blocked users and some of them are trusted autopatrollers)
  • ...
• 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.