Change #1101182 had a related patch set uploaded (by LD; author: LD):

[operations/mediawiki-config@master] T381722:Add abusefilter-access-protected-vars to frwiki EFM and remove it for sysops

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

Change #1101182 abandoned by LD:

[operations/mediawiki-config@master] T381722:Add abusefilter-access-protected-vars to frwiki EFM and remove it for sysops

Reason:

>wmf-config

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

Change #1101182 restored by LD:

[operations/mediawiki-config@master] T381722:Add abusefilter-access-protected-vars to frwiki EFM and remove it for sysops

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

I think this is unready to merge. Since abusefilter-access-protected-vars is essentially another kind of IP reveal process, it is protected by https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Access_to_Temporary_Account_IP_Addresses_Policy (and this is why check a preference to enable the feature). Abusefilter managers is not mentioned in policy and may be granted to users that otherwise has no IP reveal access. Therefore we need to check (if CheckUser is installed) whether the user has IP reveal access (and for user require an opt-in, choose to opt-in) in addition to abusefilter-access-protected-vars. Then the view agreement in AbuseFilter can be removed (see T381052: Investigate: Should we remove the preference check from AbuseFilter's protected variables implementation?).

By the way, it may be possible (though not required) that Wikimedia Access to Temporary Account IP Addresses Policy be revised so community can define other user group (e.g. "abusefilter managers" and "arbcom") to have IP reveal access without age and edit count requirement, and/or user can directly apply Global temporary account IP viewers (without having other groups like GR/GS/CU/OS) via community discussion. This require WMF legal approval and is obviously out of scope of this task.

Enwiki already has this config.

Em, that is T380332: Add abusefilter-access-protected-vars to enwiki EFM/EFH

T369610#10240941 suggests that this has not really been discussed with legal? @STran fyi

commit#1080244: we also need to clarify whether the default configuration, where the 'sysop' group has both abusefilter-access-protected-vars and abusefilter-protected-vars-log rights, should be transferred to those maintaining AbuseFilter locally or other groups in mediawiki-config.
Given that AbuseFilter is managed by the 'abusefilter' group on frwiki, should we:

• Remove both abusefilter-access-protected-vars and abusefilter-protected-vars-log rights from the 'sysop' group?
• Add both abusefilter-access-protected-vars and abusefilter-protected-vars-log rights to the 'abusefilter' group?

Same clarification is needed for T380332 where abusefilter-access-protected-vars is only given to 'checkuser' group.

Note I will suggest user require both normal IP reveal right (checkuser-temporary-account+optin or checkuser-temporary-account-no-preference) and abusefilter-access-protected-vars to access protected variables, so Legal approval is not needed.

This will make users with only abusefilter-access-protected-vars, such as alternative accounts and accounts mainly active in other wikis, no longer have access to protected variables. I am not sure whether it is in line with current policy if we need to also allow them to see protected variables.

"protected vars" here only means IP masking-level protection. In the future CU/OS level filter may be introduced, but they are out of scope of this task. Also abusefilter-protected-vars-log is another right that is only given to CU and global maintainer (T369610), also out of scope of this task. What I only concern is assigning abusefilter-access-protected-vars to a local user group that does not always have IP reveal access by policy.

From what I understand, if user_unnamed_ip variable (T364833) is added to frwiki, then abusefilter-access-protected-vars should be granted to local maintainers.
In the meantime, adding checkuser-temporary-account-no-preference to abusefilter group hasn't been discussed yet on frwiki (until now they discussed to grant it to rollbacker group).
It can be stalled until further clarifications, even if enwiki already has a similar config.

checkuser-temporary-account and checkuser-temporary-account-no-preference can not be granted to other user groups unless https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Access_to_Temporary_Account_IP_Addresses_Policy is amended, and there are no current way for user not meeting the requirement in policy to have access (even if approved by local consensus).

It seems to be being discussed this week (@sgrabarczuk).

Change #1101182 had a related patch set uploaded (by Pppery; author: LD):

[operations/mediawiki-config@master] frwiki: Add abusefilter-access-protected-vars to EFM, remove it from sysops.

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

In T381722#10388986, @LD wrote:

From what I understand, if user_unnamed_ip variable (T364833) is added to frwiki, then abusefilter-access-protected-vars should be granted to local maintainers.
In the meantime, adding checkuser-temporary-account-no-preference to abusefilter group hasn't been discussed yet on frwiki (until now they discussed to grant it to rollbacker group).

Granting checkuser-temporary-account-no-preference can only be for users which have automatic access per the temporary accounts IP reveal policy. Granting it to any other group is not something that can be done without consultation with WMF-Legal. This means that checkuser-temporary-account-no-preference cannot currently be given to the abusefilter group on frwiki.

This is also the same with the checkuser-temporary-account right. Users on frwiki get access through the normal process (meeting the minimum criteria defined at https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Access_to_Temporary_Account_IP_Addresses_Policy#Patrollers_and_other_users). This granting of access is only done when temporary accounts have been enabled on the wiki to avoid log spam.

While I suspect all users with the abusefilter group would meet the requirements for access, this may not always be the case. For example, on the English Wikipedia it's been noted that some users don't meet the requirements for access who are in a relevant abusefilter group (T380332#10389104).

Therefore, I suggest waiting to do this task until there has been time to discuss with WMF-Legal and check if this is okay to do. For example, the policy may need to be modified to allow the changes that are requested in this ticket.

It can be stalled until further clarifications, even if enwiki already has a similar config.

I'm not sure the enwiki config was properly discussed. I would prefer if this is not used as an example without there being a confirmation from WMF-Legal at the time that this was okay to do.

T&S decision said, on another matter (IPReputation AF variables), that:

We will implement IPReputation AbuseFilter variables for temporary accounts and anonymous users, using the existing protected variables mechanism.
[…] Access to the IPReputation AbuseFilter variables for temporary accounts and anonymous users will be granted to users in the sysop group, and then additionally abuse filter manager group and abuse filter group where these groups exist locally.

So it seems logic that protected variables rights should be given to relevant local AF groups, and not only sysops.

Yes. We intend to get back to this task soon after having talked with Legal on most of the issues, but need to consider whether we might protect the user_unnamed_ip variable by placing it behind a check to see if the user can view the IP addresses of temporary accounts.

@MMoss_WMF is working on a policy update related to this task.

An update for this task:

1. In a few weeks time (when wmf.24 or later is deployed to all wikis) it will be possible to merge the associated config patch as it stands
   1. This is because we have made access to user_unnamed_ip depend on having access to CheckUser IP reveal (checkuser-temporary-account).
   2. This change needs to be deployed via the train before we can merge this config patch
   3. I would expect that all users in the groups that maintain abuse filters will meet the requirements for IP reveal access, so will have access to user_unnamed_ip
2. For future config changes:
   1. You can assign the abusefilter-access-protected-vars right to any abusefilter maintainer group and remove it from sysops as desired
   2. You should not assign the checkuser-temporary-account or checkuser-temporary-account-no-preference right to any group not defined as having access in this policy.
3. At this time we will not be updating the this policy to give access to IP reveal for users in local abuse filter groups, as they would likely already be eligible for access through the "Patrollers and other users" section

Thanks for waiting while we resolved the legal / technical blockers.

Change #1101182 merged by jenkins-bot:

[operations/mediawiki-config@master] frwiki: Add abusefilter-access-protected-vars to EFM, remove it from sysops.

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

Mentioned in SAL (#wikimedia-operations) [2025-04-17T13:03:51Z] <dreamyjazz@deploy1003> Started scap sync-world: Backport for [[gerrit:1101182|frwiki: Add abusefilter-access-protected-vars to EFM, remove it from sysops. (T381722)]]

Mentioned in SAL (#wikimedia-operations) [2025-04-17T13:09:32Z] <dreamyjazz@deploy1003> dreamyjazz, wpld: Backport for [[gerrit:1101182|frwiki: Add abusefilter-access-protected-vars to EFM, remove it from sysops. (T381722)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-04-17T13:17:09Z] <dreamyjazz@deploy1003> Finished scap sync-world: Backport for [[gerrit:1101182|frwiki: Add abusefilter-access-protected-vars to EFM, remove it from sysops. (T381722)]] (duration: 13m 18s)