Page MenuHomePhabricator

Add abusefilter-access-protected-vars to enwiki EFM/EFH
Closed, ResolvedPublicRequest

Description

Please add the abusefilter-access-protected-vars right to the edit filter manager and edit filter helper groups on the English Wikipedia.

Local discussion:
https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter_noticeboard&oldid=1258473792#Protected_filters

Event Timeline

EggRoll97 triaged this task as Low priority.

Change #1092956 had a related patch set uploaded (by EggRoll97; author: EggRoll97):

[operations/mediawiki-config@master] enwiki: Add abusefilter-access-protected-vars to EFH/EFM

https://gerrit.wikimedia.org/r/1092956

Change #1092956 merged by jenkins-bot:

[operations/mediawiki-config@master] enwiki: Add abusefilter-access-protected-vars to EFH/EFM

https://gerrit.wikimedia.org/r/1092956

Mentioned in SAL (#wikimedia-operations) [2024-11-21T14:07:22Z] <sgimeno@deploy2002> Started scap sync-world: Backport for [[gerrit:1092956|enwiki: Add abusefilter-access-protected-vars to EFH/EFM (T380332)]]

Mentioned in SAL (#wikimedia-operations) [2024-11-21T14:11:37Z] <sgimeno@deploy2002> eggroll97, sgimeno: Backport for [[gerrit:1092956|enwiki: Add abusefilter-access-protected-vars to EFH/EFM (T380332)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-11-21T14:21:12Z] <sgimeno@deploy2002> Finished scap sync-world: Backport for [[gerrit:1092956|enwiki: Add abusefilter-access-protected-vars to EFH/EFM (T380332)]] (duration: 13m 50s)

This is now added to EFH and EFM on enwiki.

Cross-link T381722#10388748. Note edit filter helper is also given to users that is primarily editing other wikis (with advanced permissions), which may not necessary meet the edit count requirement of IP address reveal access. EFH/EFM can also be given to alternative accounts (which does not have reveal access by itself) of established users.

There is one user in EFM (ProcBot II) and one in EFH (Queen of Hearts mobile) not meeting requirement described in https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Access_to_Temporary_Account_IP_Addresses_Policy#Patrollers_and_other_users. Both are alternative accounts, but policy does not mention any current way to assign such access to alternative account (other than gaining them local admins - yeah, any crat can assign a brand-new user as sysop, even without discussion, and it will get IP reveal access immediately by policy), not even with community approval.

Previously, there are user in enwiki get EFM with less than 200 edits (before Global EFH exists, and now removed as redundant). If a user with 300- edits and no CU/OS (the user mentioned before was once a CU in another wiki) gets EFM or EFH, they will have access to protected variables, but not meeting the Wikimedia Access to Temporary Account IP Addresses Policy.

There is one user in EFM (ProcBot II) and one in EFH (Queen of Hearts mobile) not meeting requirement described in https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Access_to_Temporary_Account_IP_Addresses_Policy#Patrollers_and_other_users. Both are alternative accounts, but policy does not mention any current way to assign such access to alternative account (other than gaining them local admins - yeah, any crat can assign a brand-new user as sysop, even without discussion, and it will get IP reveal access immediately by policy), not even with community approval.

Previously, there are user in enwiki get EFM with less than 200 edits (before Global EFH exists, and now removed as redundant). If a user with 300- edits and no CU/OS (the user mentioned before was once a CU in another wiki) gets EFM or EFH, they will have access to protected variables, but not meeting the Wikimedia Access to Temporary Account IP Addresses Policy.

Given permissions are assigned to a person, not an account, would this even pose a problem (possibly more of a legal question than anything else)? ProcBot II has community consensus to run for a specific task, so it could feasibly make 300 edits into userspace to comply with the IP access policy and be completely fine. The QoH mobile seems far less complex, given the person operating the account is an admin, and so all of their accounts should qualify for any permission an admin has, since they're being run by the same person, but again, they could just make 300 useless edits into a userspace sandbox to fix this. I will note there is technically nothing in policy allowing the QoH mobile grant, though in a broader sense, this whole situation was caused by protected variables being rolled out sooner than they should've.