Page MenuHomePhabricator

Allow wikis to be excluded from GIPBE
Closed, InvalidPublicFeature

Description

Feature summary (what you would like to be able to do and where):
The Global IP block exemptions (GIPBE) feature, administered by Stewards via Metawiki, allows users to use proxies on WMF projects even if the proxies are blocked globally <s>and/or locally.</s>

Stewards use their best judgement on assigning the GIPBE right by user request, but they don't know the nuances of each wiki. For certain wikis, this can cause challenges for the local CUs. Those wikis have local processes to determine which user should get local IPBE right and for how long. Stewards cannot honor these local preferences, as the GIPBE right overrides the local IPBE right. An attempt to set up a guideline for Stewards about this have failed.

This feature allows a certain wiki to be completely excluded from GIPBE. This means any user who needs IPBE must obtain it through the local process on those wikis.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

Persian Wikipedia (fawiki) is a classic example here. Most editors on this project are from Iran, where internet blockade is common. Therefore, many users tend to use proxies as they browse the internet. Local policy does not allow the use of proxies when editing fawiki. Local policy acknowledges that having to turn off the proxy for editing on Wikipedia and turning it on again for other internet browsing may be an inconvenience, but emphasizes that the negative impact of proxies on CheckUser data call for users to accommodate this inconvenience. There is a local process for IPBE and CheckUsers honor these requests from good faith users (including good faith cross-wiki users). However, fawiki users often evade this process altogether by obtaining GIPBE on Meta instead.

Benefits (why should this be implemented?):

  • CheckUser logs will not be filled with proxy data
  • There would not be an inequity, whereby users who know English and can navigate Meta would have a higher likelihood of getting around proxy blocks by way of GIPBE
  • Sockmasters won't be able to evade CU by way of their sleeper accounts by getting GIPBE before making local edits

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

You can use a (new) WikiSet to define a group of wikis where a user group should be active and use that WikiSet for the global user group.

Create the wiki set on https://meta.wikimedia.org/wiki/Special:WikiSets/0 as opt-out set.
Set the wiki set on the group: https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions/global-ipblock-exempt

I have no idea if there is a process on meta to request a new wiki set or any other policy to apply it.

This would work similiar to the global-sysop user group.
This solution use features of MediaWiki-extensions-CentralAuth and may not usable on all wiki farms, but it should work for wmf wikis.
It does not need a solution in GlobalBlocking

even if the proxies are blocked globally and/or locally.

GIPBE doesn't allow locally blocked IPs to edit. It applies solely to global blocks.

even if the proxies are blocked globally and/or locally.

GIPBE doesn't allow locally blocked IPs to edit. It applies solely to global blocks.

Correct. However, most proxy blocks are global. Barring importing all global proxy blocks to the local wiki (which is redundant and time consuming), the current state means GIPBE would allow editing with proxy in essentially all wikis.

You can use a (new) WikiSet to define a group of wikis where a user group should be active and use that WikiSet for the global user group.

Create the wiki set on https://meta.wikimedia.org/wiki/Special:WikiSets/0 as opt-out set.
Set the wiki set on the group: https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions/global-ipblock-exempt

I have no idea if there is a process on meta to request a new wiki set or any other policy to apply it.

This would work similiar to the global-sysop user group.
This solution use features of MediaWiki-extensions-CentralAuth and may not usable on all wiki farms, but it should work for wmf wikis.
It does not need a solution in GlobalBlocking

Thanks for the guidance. I left a request for Stewards to create and configure such a wikiset. If/when it is done, I will close this task as complete.

In a previous request at https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous/2022-09#h-Configure_a_Wikiset_to_opt_out_fawiki_from_GIBPE-Manual_requests-2022-01-19T01:25:00.000Z, it is mentioned that Chinese Wikipedia has an adminbot to block open proxies en masse. (There @Huji also describes a possibility to create a local bot that mirrors global blocks.)

Currently Chinese Wikipedia blocks the entire AS of most cloud providers, whether it is used by proxy or not.

In a previous request at https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous/2022-09#h-Configure_a_Wikiset_to_opt_out_fawiki_from_GIBPE-Manual_requests-2022-01-19T01:25:00.000Z, it is mentioned that Chinese Wikipedia has an adminbot to block open proxies en masse. (There @Huji also describes a possibility to create a local bot that mirrors global blocks.)

Currently Chinese Wikipedia blocks the entire AS of most cloud providers, whether it is used by proxy or not.

I used to run such a bot script until it stopped working for a combination of reasons (including the impact of temporary accounts on accessibility of IP blocks to bot scripts). However, I would still argue that replicating thousands of blocks from Meta into local wikis is wasteful. The only reason to do that is, truly, that GIPBE is circumventing the local wikis' ability to limit proxy use.

Note: Huji’s proposal to create a new “Opted-out of global IP block exemption” wikiset has been rejected.

Pppery subscribed.

There never was any change here that required new technical development, hence this never belonged on Phabricator. The only obstacles to this are social. Closing accordingly.