page_first_contributor probably has the same issue.

@Titore thanks for filing this. Could you please provide links to some filters that are using this type of functionality (page_recent_contributors rlike '\n127.\0')?

In T379640#10343930, @kostajh wrote:

@Titore thanks for filing this. Could you please provide links to some filters that are using this type of functionality (page_recent_contributors rlike '\n127.\0')?

I use it here on itwiki to detect if some IP ranges of a logged-out LTA return to an article. It has helped me greatly to reduce false positives, since said LTA has been unpredictably disrupting lots of articles since years using crowded IP ranges. Here for an IP-hopping LTA known for edit-warring. Maybe a more straightforward example would be this one from enwiki.

I've had a look into how we could do this, to get an estimate of the technical work, and an idea of how the feature might work. See notes below.

Only the final section is technical - the rest should be readable by a non-technical audience who understands AbuseFilter.

Summary

Estimated effort: medium/large, if we go with the approach outlined below. We'd be wiring in 6 new variables, and implementing 2 new compute methods, which would involve lookups in the CheckUser tables. We'd need some product decisions about the scope of the variables (see Make new variables). Upper side of medium so far, but verging on large to account for anything that we may have missed here.

Current behaviour (user-facing)

page_recent_contributors contains the last 10 unique authors for a title. This includes IP authors, where their user name is their IP address.

It is used like: user_name in page_recent_contributors, which checks if a given user name is one of the last 10 unique authors.

user_name could be an IP address, so this can check if an IP was one of the last 10 unique authors.

Difference with temporary accounts (user-facing)

Example of a case that would change:

• Without temp accounts: an anon user is know to be problematic. Their name is their IP address. The filter can be used to filter that IP address. Further actions would be filtered out, as long as they kept the same IP.
• With temp accounts: a temporary user is known to be problematic. The filter can be used to filter that temporary user. If the user created a new temporary user, further actions would not be filtered, even if they kept the same IP.

Possible solutions (user-facing)

This is scoped to consider how to achieve parity with the current situation.

Use existing variables (problematic)

Update page_recent_contributors to contain the last 10 unique authors by user name, and additionally and IP addresses used by any temporary accounts who are in the last 10 authors. However, page_recent_contributors would then need to become a protected variable, so any filters that contain it would become protected. This might make some filters not visible any more to some users who maintain them.

Make new variables (preferred)

Add a new variable, something like page_recent_contributors_temp_ip (or a better name!). This would contain IP addresses used by any temp accounts who are within the last 10 unique authors of the title.

Note: there is a decision to be made here, about which IPs it should contain:

• Only the most recent IP used by each temp account?
• All the known IPs used by each temp account?
• Only the IPs used when editing this page, for each temp account?

Technical approach

• page_recent_contributors, moved_to_recent_contributors and moved_from_recent_contributors are calculated here.
• page_first_contributor, moved_to_first_contributor and moved_from_first_contributor are calculated here.
• We would need to make two analogous methods for the two sets of new variables.
• We would need to define the new variables to be protected variables, via the config AbuseFilterProtectedVariables.

I should add - any feedback on the proposed solution is welcome!

In T379640#10913649, @Tchanders wrote:

Use existing variables (problematic)

Update page_recent_contributors to contain the last 10 unique authors by user name, and additionally and IP addresses used by any temporary accounts who are in the last 10 authors. However, page_recent_contributors would then need to become a protected variable, so any filters that contain it would become protected. This might make some filters not visible any more to some users who maintain them.

I agree that this is problematic. It could also break some implicit assumptions, like the fact that the variable only contains <= 10 elements, and its consequences: for example, that page_recent_contributors[0] gives you the last contributor, page_recent_contributors[1] the previous contributor, etc. I have totally seen this multiple times in the past. I also ran a quick search for potentially affected filters, see P77954.

Make new variables (preferred)

Add a new variable, something like page_recent_contributors_temp_ip (or a better name!). This would contain IP addresses used by any temp accounts who are within the last 10 unique authors of the title.

Note: there is a decision to be made here, about which IPs it should contain:

• Only the most recent IP used by each temp account?
• All the known IPs used by each temp account?
• Only the IPs used when editing this page, for each temp account?

I had a slightly different idea in mind, but I don't know if it's feasible: make a page_recent_contributors_with_ips (naming things is hard...) variable, whose content is an ordered list of the last 10 unique contributors, identical to the normal page_recent_contributors, but with each temp account entry replaced by the corresponding IP used for that edit. It might be hard to deduplicate temp accounts by IP, though, and there'd be some minor semantic differences anyway (a temp account that only appeared once in the normal variable could appear multiple times in the IP variable if those edits used different IPs). So yeah, no preferences for me. But I do think it should only list IPs used when editing that page.

I have a suggestion should we create a protected variable to get IPs of page_recent_contributors:

How about we use the name unnamed_ip_recent_contributors?