This could be done via operations/mediawiki-config, or via a hook in AbuseFilter that allows other extensions to provide a list of additional variables

Given that the config $wgAbuseFilterProtectedVariables already exists, I think it makes sense to use that instead of adding a new hook that only has the purpose of extending an array held as a config variable.

I propose that we do either of the following:

• Hook into onRegistration and add the variables to the $wgAbuseFilterProtectedVariables config there, so that the variables by default are protected. We can't reliably use this as the config from AbuseFilter may not have loaded
• Define $wgAbuseFilterProtectedVariables to include the variables in operations/mediawiki-config to just hide them for WMF wikis

If we use a hook, it makes it pretty impractical for a wiki to decide that these variables should not be protected. Adding it to the config for just WMF wikis means that third-party wikis need to be aware and add the variable to the config if they want to prevent it's use in public filters.

In T380918#10361302, @Dreamy_Jazz wrote:

This could be done via operations/mediawiki-config, or via a hook in AbuseFilter that allows other extensions to provide a list of additional variables

Given that the config $wgAbuseFilterProtectedVariables already exists, I think it makes sense to use that instead of adding a new hook that only has the purpose of extending an array held as a config variable.

I propose that we do either of the following:

• Hook into onRegistration and add the variables to the $wgAbuseFilterProtectedVariables config there, so that the variables by default are protected. We can't reliably use this as the config from AbuseFilter may not have loaded
• Define $wgAbuseFilterProtectedVariables to include the variables in operations/mediawiki-config to just hide them for WMF wikis

If we use a hook, it makes it pretty impractical for a wiki to decide that these variables should not be protected. Adding it to the config for just WMF wikis means that third-party wikis need to be aware and add the variable to the config if they want to prevent it's use in public filters.

I would lean towards a simpler implementation and not make it possible to allow these variables to exist in public filters, ever--so, require them to be protected variables. If a third party wiki has a use case for using these variables in public filters, we could revisit, but I would worry that we'd be spending time and adding code to implement functionality that is unlikely to be used.

In T380918#10370218, @kostajh wrote:

I would lean towards a simpler implementation and not make it possible to allow these variables to exist in public filters, ever--so, require them to be protected variables. If a third party wiki has a use case for using these variables in public filters, we could revisit, but I would worry that we'd be spending time and adding code to implement functionality that is unlikely to be used.

Sure. I'll go with the approach of creating a hook to define these.

The one issue that I thought up of now is that a wiki could have IPReputation uninstalled. However, if this does occur I think that someone would see this and update the AbuseFilter config to include these variables.

Change #1100552 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/AbuseFilter@master] Add AbuseFilterCustomProtectedVariables hook

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

In T380918#10370218, @kostajh wrote:

In T380918#10361302, @Dreamy_Jazz wrote:

This could be done via operations/mediawiki-config, or via a hook in AbuseFilter that allows other extensions to provide a list of additional variables

Given that the config $wgAbuseFilterProtectedVariables already exists, I think it makes sense to use that instead of adding a new hook that only has the purpose of extending an array held as a config variable.

I propose that we do either of the following:

• Hook into onRegistration and add the variables to the $wgAbuseFilterProtectedVariables config there, so that the variables by default are protected. We can't reliably use this as the config from AbuseFilter may not have loaded
• Define $wgAbuseFilterProtectedVariables to include the variables in operations/mediawiki-config to just hide them for WMF wikis

If we use a hook, it makes it pretty impractical for a wiki to decide that these variables should not be protected. Adding it to the config for just WMF wikis means that third-party wikis need to be aware and add the variable to the config if they want to prevent it's use in public filters.

I would lean towards a simpler implementation and not make it possible to allow these variables to exist in public filters, ever--so, require them to be protected variables. If a third party wiki has a use case for using these variables in public filters, we could revisit, but I would worry that we'd be spending time and adding code to implement functionality that is unlikely to be used.

If we're doing this, should we remove the config $wgAbuseFilterProtectedVariables, and make user_unnamed_ip always be protected?

Blocked on conversations with Legal to figure out whether IPReputation variables should have a different privacy level.

Depends on T385687: Investigate: How should the AbuseFilter variable `user_unnamed_ip` be restricted to decide the approach to take, as the hook may need to be able to define additional requirements (such as additional rights etc.)

Moving this back to "In Progress". In T385687#10562909 we decided to use this hook to define the list of protected variables from other extensions, including additional restrictions (such as user rights and preferences that need to be enabled). The exact method of additional restrictions definitions is not yet decided, but I think we should be able to use some kind of callback mechanism for the time being. If that is disagreed with, we can revisit the idea of using an array structure to define requirements which are then parsed by AbuseFilter.

Change #1122136 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/AbuseFilter@master] Get list of protected variables from a service

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

Change #1122136 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] Get list of protected variables from a service

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

Change #1100552 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] Add AbuseFilterCustomProtectedVariables hook

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

For this ticket, I would suggest a regression test that verifies that the user_unnamed_ip variable is still only usable in protected abuse filters. Testing the hook will be done when we add MediaWiki-extensions-IPReputation protected AbuseFilter variables in other tickets.

QA regression testing is completed, the protected filter of user_unnamed_ip is still only usable in protected abuse filters.