Context
In T354597: Record IP reputation data for account creations and edits we'll likely discover that there are combinations of IP reputation data that usually result in unwanted edits or account creations. We should allow AbuseFilter maintainers to be able to create filters targeting traffic using a subset of labels in the IP reputation data.
Decision record about implementation: https://www.mediawiki.org/wiki/Trust_and_Safety_Product/Decision_records/2025-02-04-IPReputation_AbuseFilter_variables_for_registered_users
Proposal
Introduce IP reputation AbuseFilter protected variables for things like risks (callback proxy, VPN), tunnel types, client concentration count, or simply being present in iPoid-Service's database. Based on spur.us documentation, some possibilities for variables:
- client.behaviors
- client.count
- client.countries
- client.proxies
- infrastructure
- risks
- services
- tunnels.anonymous
- tunnels.operator
- tunnels.type
Consequences
We would be able to define mitigations in AbuseFilter based on edits from IPs matching specific IP reputation variables.
Notes from L3SC discussion
Copying over some requirements from L3SC discussion:
[,,,] variables like tunnels.operator could narrow down user identification, especially if the VPN service is uncommon and the Abuse Filter has some overly narrow combinations of conditions. Even in that case, the risk would still be low since Abuse filters are under tight community scrutiny and filter maintainers are highly trusted volunteers who exercise care when crafting filter conditions. Additionally, with the guarantee, IP reputation AbuseFilter variables will only be restricted to AF maintainers, rather than making them visible to the wider public, there is an extra layer of precaution.
want to reiterate that we build in the right measures/controls to mitigate false positives, for eg editors from some countries often. use open proxies/shared ip addresses and may not necessarily have malicious intent and could be wrongly tagged in the abuse filter.
Conclusion:
- The variables need to be treated in the same way as user_unnamed_ip, in that they are considered "protected variables" and the filters and logs where they are used are accessible only to users with the right to view filters with protected variables.
Acceptance criteria
- AbuseFilter variables exist for a variety of IPReputation data
- These new variables work for actions performed by logged out users and temporary accounts
- These new variables work for account creations of permanent accounts when the account is created while logged out
- The new variables, their functionality, and recommendations for their use are communicated out to the community