Jump to content

Wikipedia:Edit filter noticeboard/Archive 15

Add links
From Wikipedia, the free encyclopedia
Archive 10←Archive 13Archive 14Archive 15

Filter 1352 logging every edit

A recently created filter is logging seemingly every edit, please disable.
This filter: Special:AbuseFilter/1352 – 2804:F1...D5:9C2C (::/32) (talk) 23:03, 18 March 2025 (UTC)

@Tamzin – 2804:F1...D5:9C2C (::/32) (talk) 23:07, 18 March 2025 (UTC)
Also, why is it matching every edit? It doesn't seem, from the code, that it should be - clearly I'm missing something... – 2804:F1...D5:9C2C (::/32) (talk) 23:17, 18 March 2025 (UTC)
Constructing regex from strings is a sketchy practice. Using parentheses around "(restrictedusers + "$")" should work, as should just combining the $ into the first regex. In the current version it's ignoring the variable and just testing whether "$" is true, which it is. -- zzuuzz (talk) 23:38, 18 March 2025 (UTC)
I've updated the filter to that. In testing it matches 100% of edits by the one currently BER'd editor, except one to their usertalk (intended behavior), and 0% by anyone else. Nonetheless, leaving disabled for now pending discussion below. -- Tamzin[cetacean needed] (they|xe|🤷) 00:01, 19 March 2025 (UTC)
I've marked the filter as deleted and renamed it to "Most edits from 22:54 to 23:18, 18 Mar 2025". See 1008 (hist · log) (private) for precedent. No opinion (yet) on whether this filter (under a new ID) is a good idea, but seeing "subject to a balanced editing restriction" might be alarming to some users. Suffusion of Yellow (talk) 02:52, 19 March 2025 (UTC)
Totally fair, and makes it easier tool-side anyways. -- Tamzin[cetacean needed] (they|xe|🤷) 02:54, 19 March 2025 (UTC)
  • This is disabled already. This also seems like a pretty inappropriate use of abusefilters. — xaosflux Talk 23:23, 18 March 2025 (UTC)
    Ping to author: @Tamzin:. — xaosflux Talk 23:24, 18 March 2025 (UTC)
    Having dispute resolution committees trying to create technical solutions has historically been a big problem (see the super messy history of ECP). Abuse filters are not designed to be built around single editors. If an editor can't edit without consistently disrupting the project, block is right there. — xaosflux Talk 23:26, 18 March 2025 (UTC)
    @Xaosflux First of all, my apologies for whatever I did wrong here. I'm rereading the filter and still not seeing the issue, but clearly I ought to have tested it more. That said, I think you may misunderstand the filter's purpose. It is not built around a single editor, nor is it designed to quasi-block anyone. It's logging all edits by anyone who is subject to a BER (which currently happens to be one editor, but there's another at AE that I'll probably close that way soon if no one objects), for ease of keeping track of what namespace a page was in at time-of-edit. Sorry for not seeing this sooner; I was busy updating the code for n-ninety-five to use the new filter. -- Tamzin[cetacean needed] (they|xe|🤷) 23:37, 18 March 2025 (UTC)
    This is still a bad use of filters. abusefilter is a tool for bulk purposes, not individual user reporting. That it could be for 0.00000001% of users is too niche. — xaosflux Talk 23:47, 18 March 2025 (UTC)
    I modeled this after Special:AbuseFilter/1170, which also deals with a very small number of users. In a perfect world, I wouldn't want to use a filter for this, but it is by far the simplest way to keep track of something ArbCom has made the enforcement of a restriction contingent upon. And it only comes at the cost of, I think, about one condition? The BER wording gives the ArbCom clerk team full control of how it's implemented, so I'll ping @HouseBlaster as the only clerk to comment so far. -- Tamzin[cetacean needed] (they|xe|🤷) 23:55, 18 March 2025 (UTC)
    I have flagged this discussion for the clerk team. What Xaos and Daniel Quinlan are saying sounds reasonable, as does what you are saying. I realize that this is a non-answer: I don't have one yet (either my own opinion or for the clerks/ArbCom). Consider this a  Thinking and discussing with ArbCom... :) HouseBlaster (talk • he/they) 00:22, 19 March 2025 (UTC)
    Filter 1170 is also a pretty bad implementation. — xaosflux Talk 01:31, 19 March 2025 (UTC)
The MediaWiki API (mw:API:Usercontribs) is more than sufficient for this and a bot should handle this instead. It would also be better to have a configuration page that can be updated as users are added or removed, rather than requiring edits to an abuse filter.
Also, this should have been discussed here first because this is so different from how other filters are used. Daniel Quinlan (talk) 00:13, 19 March 2025 (UTC)
Well I apologize for not discussing it here first. To me it seemed pretty noncontroversial but apparently I was wrong. However, I disagree that the API is sufficient for this. To figure out the namespace a page was in at time of edit, you need to
  1. Go through every edit an editor has made in the last month
  2. Get the page history of each of those pages
  3. Work through the page history to figure out whether the page has been moved since the last edit
  4. Parse the namespaces for any moves that have occurred
This can easily take dozens of API requests (particularly if any of the pages someone has edited are heavily-edited pages like AIV, requiring many continuation requests), and is inaccessible to anyone trying to count manually or to make their own tool.
On the other hand, dividing the number of #1,339 hits by the number of #1,352 hits is straightforward, less prone to error, and more transparent for anyone counting by hand or making their own tool.
Or if you mean getting a bot to log edits in real time, then the system is dependent on that bot's uptime, and again it means there's no transparent on-wiki log of which edits qualify toward the denominator. -- Tamzin[cetacean needed] (they|xe|🤷) 00:25, 19 March 2025 (UTC)
I appreciate the work you've put into this, but I think using an edit filter for BER was a problematic constraint that didn't really belong in an ArbCom motion. I have a strong sense that a bot would be a better solution and I think it would be helpful to reopen the discussion elsewhere to figure out a better approach. This seems like it's headed toward an end result that won't be good for either the users under the restriction or the administrators enforcing it. Daniel Quinlan (talk) 01:01, 19 March 2025 (UTC)
Why a bot? Bots are for making edits. The goal here is to log something, and the easiest way to log things is with an edit filter. I mean you're welcome to file at WP:ARCA if you disagree, but you could you explain the harm you envision with the current approach? All we're doing is counting one thing (edits to PIA-tagged pages), counting another thing (all edits in the four qualifying namespaces), and dividing the first by the second. -- Tamzin[cetacean needed] (they|xe|🤷) 01:09, 19 March 2025 (UTC)
And isn't that whole house of cards also being dependent on an external single volunteer project as well? (i.e. a toolforge page) — xaosflux Talk 01:34, 19 March 2025 (UTC)
No, as long as there's a filter logging time-of-edit namespaces, someone can count manually. If they install the CSS that numbers log entries, it can be quite fast, even. On the other hand, if someone needs to manually do the steps I described above in order to be certain that a BER violation has occurred, that's incredibly tedious, to the point that people just won't do it. -- Tamzin[cetacean needed] (they|xe|🤷) 01:43, 19 March 2025 (UTC)
I'm a bit surprised by the assertion that Bots are for making edits. They're also used for other tasks including the ones needed for BER. The harm here is a poor user experience, the requirement for someone to manually update an edit filter for user additions and removals, and introducing a special case into the abuse filter system. Daniel Quinlan (talk) 01:50, 19 March 2025 (UTC)
What is the poor user experience? -- Tamzin[cetacean needed] (they|xe|🤷) 01:58, 19 March 2025 (UTC)
I think they mean the need to constantly keep updating the list of users, but I may be wrong. – PharyngealImplosive7 (talk) 02:07, 19 March 2025 (UTC)
That'd just be a single step after AE-logging, for something that probably will happen once or twice a month. A bot could be made to add to the filter based on the AE log, but it would require admins to use consistent syntax when logging, which is currently not the case. Still, it's a negligible burden either way. -- Tamzin[cetacean needed] (they|xe|🤷) 02:13, 19 March 2025 (UTC)
The solution is poorly designed at multiple levels: it relies on a Lua hack, one overly broad edit filter alongside another that's too narrow, and requires manual updates to an edit filter to maintain the user list. Even adding the first user did not go smoothly. User checks are entirely manual and require running a separate tool, manual determinations of compliance, there are no automated reports, and there is no feedback for affected users. The motion creating this restriction put the cart before the horse. It would have been better to start with a bot request or a VPT discussion outlining use cases. Daniel Quinlan (talk) 06:53, 19 March 2025 (UTC)
To be fair, I do agree that there is a lot we could improve upon with regards to UX. Now, I'd rather have 20 BERs in their current state than a single pre-PIA5 trip to PIAland, and BER is supposed to be a tool to help make these things better. I agree that in an ideal world a something (bot which logs stuff in its userspace?) would exist and magically log all edits in the PIA5 area by BERers, do the division for us, output it into a fancy color-coded wikitable (yellow meaning "watch out, you're getting close to the limit"; red meaning further edits are a violation), etc. Compared to that platonic ideal, I will readily concede that the current system looks... less than fantastic (through no fault of anyone, least of all Tamzin). Best, HouseBlaster (talk • he/they) 07:13, 19 March 2025 (UTC)
100% agree that dispute resolution committee's shouldn't be dictating technical mechanisms in isolation. — xaosflux Talk 01:33, 19 March 2025 (UTC)
The remedy has a clause saying clerks [...] may make any necessary changes in the technical implementation of this remedy in the future. If that means "ditch the filter and use a bot", then we can do that. HouseBlaster (talk • he/they) 03:19, 19 March 2025 (UTC)
I'm a bit hesitant to point out more things as I don't want to distract from the above, but this does seem to have become the place to do so, so have some thoughts:
  • An edit filter can generate logs for 'edits' even if another filter has disallowed it (meaning no edit was actually made).
    There are admittedly considerably less disallow filters that affect extended confirmed users, but it's presumably possible.
  • You could, presumably, setup the tool to check if there is an edit/diff associated with the log... but if the page is deleted or the revision is deleted, there will be no diff either (there is a diff if the revision/page was moved, thankfully - ex.: [1])
Is this cause for concern? – 2804:F1...D5:9C2C (::/32) (talk) 04:07, 19 March 2025 (UTC)

Request for the Edit filter manager right

 Not done support for this has not been established. — xaosflux Talk 18:53, 21 March 2025 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I like to go on vandalism-fighting sprees, and see edits that would warrant an edit filter themselves, so I would like to request this right to advance my vandalism-fighting. Thanks! Faster than Thunder (talk | contributions) 02:41, 14 March 2025 (UTC)

I have suggested a LTA edit filter via email, but it has not been approved within a day. Faster than Thunder (talk | contributions) 02:28, 15 March 2025 (UTC)

The earliest closure has started. (refresh)

You aren't currently an edit filter helper, and you don't need EFM to suggest improvements to filters, especially not just for anti-vandalism ones. Elli (talk | contribs) 02:45, 14 March 2025 (UTC)
You don't seem to have enough edit filter related activity for EFH or EFM. It looks like just using EFR will be a good start for what you intend to do. Nobody (talk) 06:08, 14 March 2025 (UTC)
Oppose: Doesn't seem to have much experience with edit filters. As others have said, you don't need to be an EFM to suggest filters. – PharyngealImplosive7 (talk) 13:36, 14 March 2025 (UTC)
Oppose Same as others. EggRoll97 (talk) 20:59, 14 March 2025 (UTC)
Oppose for both. The edit filter manager permission can be dangerous when used by a malicious user (due to the ability to abuse or misconfigure edit filters), and for the edit filter helper permission, I don't see enough EFR/EFFPR-related activity as others have pointed out. One more note, you do not need to view private filters and their logs (at the very least) when patrolling for vandalism or spam as well. Codename Noreste (talk) 04:17, 15 March 2025 (UTC)
The earliest closure has started, could an uninvolved admin close as not successful please? – PharyngealImplosive7 (talk) 18:35, 21 March 2025 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

About filter 1170...

  • 1170 (hist · log) ("Non-clerk/CU/bot editing SPI archives")

About filter 1170 that was mentioned above.. why do 'we' not use equals_to_any instead of regex in this filter? On Tamzin's filter above it makes sense since it has to be reused, but in this filter it isn't reused. Feels like it would be easier to maintain too, not having to escape some usernames. – 2804:F1...D5:9C2C (::/32) (talk) 00:11, 19 March 2025 (UTC)

I would leave filter 1170 just as is, because if it's not broken, we shouldn't fix it. Codename Noreste (talk) 00:16, 19 March 2025 (UTC)
I disagree that that is a principle usually applied to filters, filter optimizations are not rare. – 2804:F1...D5:9C2C (::/32) (talk) 00:41, 19 March 2025 (UTC)
Balanced with the potential costs - mistakes, testing, time, etc.. I've converted this filter to this format. -- zzuuzz (talk) 01:11, 19 March 2025 (UTC)
I think 1157 (hist · log) uses the previous username regex format. Also, what I said on my second reply here was my opinion. Codename Noreste (talk) 01:21, 19 March 2025 (UTC)
  • Not sure how we got to the point where we need to make super-protection for a special manual list of users for some pages. — xaosflux Talk 01:35, 19 March 2025 (UTC)
    I can see how people arrive at that from "we also need to exclude clerks from being warned/logged by these filters, but clerk isn't a role".
    I'll avoid joining a discussion on what is a better way for now, though. – 2804:F1...D5:9C2C (::/32) (talk) 01:52, 19 March 2025 (UTC)
    You know, I tend to agree. Everyone seemed to agree that a special protection filter for DatBot's TB2 filter page was a bad thing, but here we are with a filter that does basically the exact same thing (AbuseFilter hack-protection) to SPI archives, and it's a-okay. EggRoll97 (talk) 22:44, 21 March 2025 (UTC)
    This whole concern may lend support to Daniel Quinlan's idea in the thread below of using bots. – PharyngealImplosive7 (talk) 22:51, 21 March 2025 (UTC)
    Well, I planned to use that filter more broadly for other configuration pages.
    Ultimately, there are a set of use cases that swirl around the need for a more lightweight method to maintain user groups (or tags or whatever) and the ability to connect those groups to functionality in edit filters and page protection. It's broader than one group. It's SPI clerks, non-sysop bot maintainers, the AWB user list, restricted users (like BER), ArbCom members, ArbCom clerks, and probably more. Sometimes we use template protection as a workaround, sometimes we use an icky edit filter, and sometimes we cross our fingers and hope for the best. Daniel Quinlan (talk) 01:27, 22 March 2025 (UTC)

Suggested changes to filter 113

Hello, everyone. I am here to suggest a fix to filter 113.

  • Current lines 3 and 7 are both lcased and use rlike, but it doesn't make sense when you can use irlike without lcase.
  • On line 6, because the contains_any condition uses lcase(added_lines), I lowercased Target page name as that condition must use lowercase letters only.
  • Due to the two major conditions not being surrounded with parenthesis for the boolean order predecence (lines 5-6 and 9-11), only the filter will exclude autoconfirmed users when it matches with lines 5 to 6. Because of an OR operator (|) in line 7, the autoconfirmed user exclusion would not reach up to lines 9 to 11, and in theory, will affect all users (regardless when autoconfirmed or not).

This is the fix for filter 113 that I am suggesting below: 

!("confirmed" in user_groups) &
page_namespace == 0 &
added_lines irlike "#\s?REDIRECT" &
(
  (
    !contains_any(lcase(added_lines), "{{subst:rfd", "{{db-r2}}", "{{db-r3}}", "target page name") &
    !(new_wikitext irlike "(?:^#|\n[#*]+)\s?REDIRECT")
  ) |
  (
    malformed := "\#\s?redirect(?:ed|ing|ion|s)?\W*\[\[\s*(?:(?:\&\w+\;)?<\w+.*?>|\#\s?redirect|\]\]|\{\{)";
    added_lines irlike malformed &
    !(removed_lines irlike malformed)
  )
)

Thanks. Codename Noreste (talk) 22:12, 21 March 2025 (UTC)

I just saw this. Since I made the addition that caused today's false positives for Hey man im josh, someone pinged me on Discord earlier so I fixed it then (one condition needed to use added_lines_pst). After that, I refactored the filter because it needed work and there were several more redirect mistakes to cover. Some notes:
  • I removed Target page name as an exception because it wasn't needed and it hadn't worked for a long time. I actually added the string to the pattern for bad targets.
  • Nesting the malformed checks under the first added_lines would have been more efficient, but it was written and tested to run on all users, not just non-confirmed. The refactored version wraps everything in a shared set of conditions for better performance and to reduce potential false positives given the extent of the changes, but it now matches on more users and in more namespaces. (I tested the revised filter, of course.)
If the updated filter works well over time, I'll update it to match more users. Daniel Quinlan (talk) 02:33, 22 March 2025 (UTC)
Appreciate the fix for me. Really helps to be able to use substitutions, like {{title year}}, when creating sets of redirects that are specific to a year. Hey man im josh (talk) 16:36, 22 March 2025 (UTC)
Josh, you're just built different! Seriously, thanks for the help yesterday with my questions. Daniel Quinlan (talk) 02:31, 23 March 2025 (UTC)

Improving the balanced editing restriction solution

The current solution for enforcing BER on ARBPIA articles has several issues. It requires two edit filters that log very broadly, manual updates to the user list in one of the edit filters, and checking compliance is cumbersome. There is also a troubling lack of feedback to users under the restriction.

Some rough use cases:

  • Compliance statistics need to be accurate.
  • Users monitoring BER compliance need an efficient way to check compliance.
  • Users under the restriction need a way to easily check their status.
  • Administrators should be able to easily and safely add or remove users from the BER list.
  • The solution should avoid excessive resource usage.
  • The solution should be easy to maintain with minimal downtime.
  • Any downtime should have no long-term impact on other use cases.

Proposal:

  1. We replace the current BER-related edit filters with a single filter that only logs edits to PIA pages made by BER users.
  2. We shift the rest of the solution to an administrator bot:
    • The bot will count edits and deleted edits for BER users and combine those with filter hits to calculate accurate statistics.
    • The bot will maintain a public summary page with statistics for each user. This will allow both those monitoring BER users and the users under restriction to view the current statistics.
    • The bot will automatically update the user list in the filter based on a JSON configuration page listing BER users. The JSON configuration page can be updated by any administrator placing or removing the restriction on a user. Some level of page protection is probably a good idea. If the JSON configuration is broken or inaccessible, the bot can post a notice for resolution.

The filter and summary could be either private or public. I believe public is better for transparency and auditing, but I wanted to mention that a private filter is possible. If we want to keep everything private, the statistics summary could be stored in the filter notes, but then I think the bot would need to communicate feedback directly to BER users, and the implementation gets more complex.

Any minor downtime for the bot shouldn't be a major issue because the information it uses is permanently stored and it only needs to produce statistics for the last month. The main downsides of this solution are the continued reliance on the Lua hack and using edit filters in a way that isn't ideal, but this approach is less problematic than the current solution.

The filter itself will be simple to implement and I'll make the required filter updates it if there's consensus for this approach and agreement from the clerks. I don't need to be the person implementing the bot, but I'm willing to submit a WP:BRFA and code up the bot. Daniel Quinlan (talk) 22:52, 19 March 2025 (UTC)

I'm still thinking about your proposal, but I have noticed a few (potential) technical issues. How a bot could update a list that is directly used in an edit filter? The two possible ways this could work that I have thought of (there may be more) either require an EFM bot (to directly modify the list on the filter) or a way for a filter to read from an external list (that the bot edits) and continuously update itself. However, I may be missing something.
Besides the potential technical issues for any implementation, the proposal seems fine, and I agree that if implemented, it would improve the BER solution. – PharyngealImplosive7 (talk) 01:41, 20 March 2025 (UTC)
There's no way for a filter to import a list of users from an external list. Bots in the edit filter manager group can update edit filters. ProcBot II does that, for example. Daniel Quinlan (talk) 05:25, 20 March 2025 (UTC)
Interesting. I didn't know that there were bots that modified edit filters. – PharyngealImplosive7 (talk) 13:42, 20 March 2025 (UTC)
Back to the same problem, we should not be running filters for individual users. It's just bad practice. That dispute resolution wants something super complicated doesn't mean it is a good technical solution. — xaosflux Talk 01:56, 20 March 2025 (UTC)
We also don't need to make some super complicated remedy that arbcom invented "easy". — xaosflux Talk 02:02, 20 March 2025 (UTC)
More problems with that, building a workflow that is dependent on future actions of an editor (in this case a bot operator) is a bad idea. — xaosflux Talk 02:05, 20 March 2025 (UTC)
Ideally, there would be a built-in way to manage user lists suitable to this purpose. For some reading this, user groups might seem like the obvious solution and we certainly have many filters doing that, but since adding a user group requires server-side configuration changes, it's not exactly something Wikipedia does every day. English Wikipedia also doesn't have any user groups that add zero additional permissions, so it might raise a lot of objections. It's also unusual to have a user group that ultimately limits a user's rights, but that's the intent of BER, whether we like it or not.
Storing a list on a page is the next and most plausible option which is why I proposed it. A JSON page like Wikipedia:AutoWikiBrowser/CheckPageJSON or Template:DatBot filters seems best, but any parseable format would work. I realize the proposal has some downsides which is why I noted them myself. I think it's still a better solution than the current approach. Daniel Quinlan (talk) 06:07, 20 March 2025 (UTC)
Using a usergroup for a tiny handful of people just to track them with a filter is also a sloppy hack, and the idea is still dependent on future contributions by bot operators. WP:BER doesn't seem to dictate making reports, dashboards, etc - this seems like a lot of scope creep and work for an immensely small number of problematic disruptive editors. — xaosflux Talk 09:17, 20 March 2025 (UTC)
We have other filters with lists of users. That we have to edit a filter to add or remove users from those lists is worse than sloppy.
It only seems like scope creep because the motion was drafted and passed without involving edit filter managers or the BAG, and no use cases (or anything remotely resembling use cases) were defined until now. Expecting this restriction to be enforced through manual queries in some separate tool, with no built-in feedback for affected users, isn't just impractical, it's unreasonable and unfair. That being said, nobody is forcing you to write a bot, and I'd prefer to hear solutions or proposals rather than just objections. Right now we still have multiple problematic filters for BER and the plan is to have people manually updating them to enforce this restriction. While I say that, I'll admit my enthusiasm for contributing has waned after the clerks' response. Daniel Quinlan (talk) 16:26, 20 March 2025 (UTC)
I didn't read every active filter, but a quick search only popped up 1170, which I also noted above is a problem. We certainly have ones that use user_name, but they are mostly matching fixed regex's against that field, not maintaining a manual list of whitelisted/blacklisted registered account names. — xaosflux Talk 23:56, 20 March 2025 (UTC)
Just noting that there also is 1157 (hist · log) that uses a list of usernames. – PharyngealImplosive7 (talk) 01:27, 21 March 2025 (UTC)
Thank you, and yup that is a sloppy filter too. — xaosflux Talk 11:14, 21 March 2025 (UTC)
Time to create Wikipedia:Editing restrictions/Balanced editing restriction. Nobody (talk) 09:58, 20 March 2025 (UTC)
Speaking for myself – the clerk team is still discussing with ArbCom – a bot seems like a better solution. Thank you, Daniel Quinlan, for putting this together. To Xaosflux's point about filters targeting disruption from specific users, I see it as little different to the LTA filters which largely target individuals. I get that hard-coding names is ugly. But it decreases the noise in the filter log and saves conditions.
ArbCom has decided that BER shall exist, so we have to enforce it somehow. I also don't see relying on a bot to be that bad a concept; we already rely on bots to do several things which are a royal pain in the rear to do manually. I think that Tamzin's toolforge tool is also great for getting a spot-check "on demand". If you feel strongly that BER should not exist (either at all or in its current form), WP:ARCA is thataway; as a clerk I have zero authority to change the fact that the remedy exists.
I wouldn't object to using a bot to do all of the counting, either. It would have to be careful to avoid a full API ban; I think a JSON page is acceptable. Or maybe even something like what we do for the redirect autopatrolled list, which saves admins from touching JSON (JSON isn't that hard, but it sounds scary).
If people need anything else from the clerk team/ArbCom, please let me know; I have flagged this thread for them. Best, HouseBlaster (talk • he/they) 02:04, 21 March 2025 (UTC)
LTA filters largely target IP ranges, content, and occasionally regex's of patterns - not lists of named users. Regarding the statement "we have to enforce it somehow", well I suppose arbcom can dismiss or replace their clerks - but they can't force administrators to not volunteer to do something.
I have no problem with the idea of creative remedies to combat disruption, nor have a specific problem with using some external tools, that is just a caution along those same lines (these things tend to break when a volunteer leaves or gets bored with it). We certainly have much higher visibility examples of this (I'm looking at you geohack). — xaosflux Talk 11:14, 21 March 2025 (UTC)
I understand that the means by which we target different users is different, but LTA filters exist to primarily target disruption from individual editors. I don't see the BER filter as different in spirit to that. Best, HouseBlaster (talk • he/they) 18:30, 21 March 2025 (UTC)
I guess a BER remedy is one thing, sustainable technical solutions to implement it are another. As I think you allude to, I think you could use a bot patrolling recent changes to implement this. Any account with the bot flag (thus higher rate limits) could do this, and for a non-abuse logging workload like this one, it feels like the correct implementation to me. ProcrastinatingReader (talk) 12:54, 24 March 2025 (UTC)
An administrator bot wouldn't need to check all recent changes. It's sufficient to check the edits and deleted edits of the users under the restriction. The more I think about the requirements for BER, the more I think that using edit filters and requiring module changes (the Lua hack) were not the way to go. Daniel Quinlan (talk) 15:31, 24 March 2025 (UTC)
Yeah, that would more than suffice, with periodic polling. Probably a regular bot could do it too. It wouldn't see deleted revisions but that's a good approximation nonetheless, and arguably fairer since AFAIK a user can't keep track of how many deleted edits they made to ARBPIA pages. ProcrastinatingReader (talk) 19:36, 24 March 2025 (UTC)
Deleted revisions' metadata is public through the API, unless oversighted. N95 currently generates its denominator based on contribs plus deleted revisions. We certainly shouldn't be switching to a system that gives a less accurate number, just to avoid a usually-smaller source of inaccuracy (i.e. most people will have more edits to deleted pages than to cross-namespace-moved pages, I'd think). -- Tamzin[cetacean needed] (they|xe|🤷) 19:39, 24 March 2025 (UTC)
I guess it depends on the details. I suggested recent changes originally since it'd be instantaneously correct, and at the time of the edit, probably in the form of a bot listening to wikitech:Event Platform/EventStreams HTTP Service. IIUC, N95 has the issue that it can only give compliance for 30 days from the time of check, and the checks need to be done manually. I presume it's not too hard for you to switch that to periodic polling, but nonetheless it seems like it would always be reactive, and thus an approximation? ProcrastinatingReader (talk) 01:16, 25 March 2025 (UTC)

Suggestions to filter 1339

Moved from Wikipedia talk:Arbitration Committee/Clerks/archive 12#Suggested update to filter 1339

Hello, everyone. From a technical point of perspective (and to raise a suggestion here instead of the edit filter noticeboard), I am suggesting a change to edit filter 1339.

  • Currently, on lines 3 to 5, the OR logic must be surrounded with both parenthesis, in which my suggested code has implemented.
  • Per filter 1341, I placed the new_html check before the major conditions wrapped in parenthesis.
  • Rather than the current conditions wrapped in parenthesis, for the new code, it will check whether the WP:BER edit was made on article/draft talk pages with no protection, or if it was done on the main article/draft page AND the page_restrictions_edit condition. Both conditions will either be checked only if the pages were under ARBPIA restrictions.
  • Instead of "extendedconfirmed" in page_restrictions_edit, I used page_restrictions_edit[0] == "extendedconfirmed". If you simply use page_restrictions_edit == "extendedconfirmed", it will not work at all because it must use an array index after page_restrictions_edit ([0]).
action == "edit" &
contains_any(user_groups, "extendedconfirmed", "sysop") &
!("bot" in user_groups) &
(
    equals_to_any(page_namespace, 1, 119) |
    (
        equals_to_any(page_namespace, 0, 118) &
        page_restrictions_edit[0] == "extendedconfirmed"
    )
) &
new_html contains "This page is subject to the extended confirmed restriction related to the Arab-Israeli conflict."

Thank you. Codename Noreste (talk) 20:22, 19 March 2025 (UTC)

Update, Daniel Quinlan suggested that I'd move my suggestion to here as EFMs need to be aware of edit filter proposals and changes, CC to SilverLocust. Codename Noreste (talk) 20:22, 19 March 2025 (UTC)
Thanks for moving the discussion. I think we can hold off on changes until there is consensus on the solution (see above and below). If it weren't for that, I would suggest placing the new_html check last because that variable is very large (it might be worth trying it both before and after the namespace checks, or perhaps just put a check for any of 0, 1, 118, 119 up top). I'd also swap the ordering of the two user_groups checks. Daniel Quinlan (talk) 23:12, 19 March 2025 (UTC)
@Daniel Quinlan: To be clear, decisions of the Arbitration Committee are exempt from consensus, including the creation of this edit filter and delegation of the implementation system for WP:BER to the clerks. But I think shifting at least parts of the implementation to a bot would likely be better. More thoughts later. JensonSL (SilverLocust) 00:49, 20 March 2025 (UTC)
It's surprising to see the Arbitration Committee invoked as pushback against someone offering to help. I was going by the statement in the BER motion that clerks may make any necessary changes in the technical implementation of this remedy in the future. That said, the Arbitration Committee's scope is not unlimited and any technical implementation will always benefit from input and consensus among edit filter managers and the Bot Approvals Group. I also prefer to work on a solution that has the community's support. Daniel Quinlan (talk) 02:15, 20 March 2025 (UTC)
This wasn't pushback on offered help, and I'm not opposed to the proposals (the filter changes in this section and your proposal for a bot below), I was just noting that it isn't necessary to "hold off on changes until there is consensus on the solution" regarding implementation of this arbitration remedy. JensonSL (SilverLocust) 02:07, 24 March 2025 (UTC)
@SilverLocust: Please respond to the entirety of my comment. It's important. Daniel Quinlan (talk) 03:51, 24 March 2025 (UTC)
What did you want me to respond to? I don't disagree with anything else in your comment. JensonSL (SilverLocust) 03:57, 24 March 2025 (UTC)
I believe that is clear from my question, but very well. Can you clarify whether you believe that the Arbitration Committee and its clerks are able to override consensus on matters outside of their documented scope and responsibilities? Your previous statement seems like a wild take on the policy and I think you need to clarify your position, especially since you're involved in adding filters and modifying modules for a technology solution that should be disabled, reconsidered, and redesigned from scratch. You also seem to be taking the position that we need to press forward with the current plan regardless of these problems (even if there is consensus against doing so). It's also important that we understand whether this matter needs to be discussed elsewhere. Daniel Quinlan (talk) 04:38, 24 March 2025 (UTC)
Yeah I'm kinda sceptical about the appeal to ArbCom. When implementing technical measures, I see no reason why any edit filters aren't subject to the normal procedures for edit filters, even if their purpose would be to enforce an arbitration remedy. Same as if ArbCom wants a bot, it needs to comply with WP:BOTPOL unless it's operating within a BOTPOL exemption. Both these things are to prevent harm to the project due to problematic technical implementations. ProcrastinatingReader (talk) 00:55, 25 March 2025 (UTC)
No, in citing WP:CONEXEMPT I am not claiming (and I don't believe) that ArbCom can take action outside its "scope and responsibilities" (quoting CONEXEMPT). Rather, I believe WP:PIA5 counts as a "binding decision" that is within its "scope and responsibilities" such that the exemption applies. Part of the decision in that case is this remedy, which says it "will be determined by an edit filter" (WP:BER). If you believe that part of the remedy goes beyond the Arbitration Committee's legitimate scope, you can ask it to reconsider that decision at WP:ARCA. (Beyond asking the Arbitration Committee to amend or clarify a decision, the formal means for checking ArbCom are by annual elections or by a referendum to amend the arbitration policy.) But I have no reason to believe the Arbitration Committee wouldn't be fine with changing to a new implementation using a bot.
To reiterate, I am favorable to using a bot to implement this remedy and in no way took the position that we "need to press forward with the current plan". I posted changes below not instead of a new implementation, but rather as improvements to the filter while it remains in use for its current purpose. - JensonSL (SilverLocust) 02:47, 25 March 2025 (UTC)

How about this: 

action == "edit"
/* moves do not generate new_html, so they could never hit this filter */
& contains_any(user_groups, "extendedconfirmed", "sysop", "bot") 
/* leave "bot" since this function call is cached from other filters */
& !contains_any(user_groups, "bot")
/* this excludes admin bots */
& (
    ( equals_to_any(page_namespace, 0, 118)
    & page_restrictions_edit[0] == "extendedconfirmed" )
    | equals_to_any(page_namespace, 1, 119)
)
& "This page is subject to the extended confirmed restriction related to the Arab-Israeli conflict." in new_html

(The replacement of !"bot" in user_groups with !contains_any(user_groups, "bot") is for the reason noted in #Repeated function calls and the condition limit: It avoids adding to the condition count. Note that equals_to_any(page_namespace, 0, 118) (article/draft) is cached from use in other filters, page_restrictions_edit[0] == "extendedconfirmed" doesn't contribute to the condition limit, and discussion page edits are less common, which is why I've left those two conditions before equals_to_any(page_namespace, 1, 119) (talk/draft-talk). The parentheses before | are redundant because A&B|C is equivalent to (A&B)|C, but I've included them just for clarity.) – JensonSL (SilverLocust) 02:09, 24 March 2025 (UTC)

Repeated function calls and the condition limit

Should !("bot" in user_groups) be replaced with !contains_any(user_groups, "bot") in each filter that uses it?

Each time in is used, it contributes 1 condition toward the condition limit. By contrast, when a function like contains_any() is used multiple times with the exact same parameters (within one filter or across different filters), it only counts as 1 condition in total. (That is why, for example, Special:AbuseFilter/1338 averages 0.4 conditions. The first condition is a function call used by several filters.)

!("bot" in user_groups) is used in several filters (with or without parentheses), so that would reduce the number of conditions used. Would changing those be a good idea? JensonSL (SilverLocust) 21:25, 23 March 2025 (UTC)

Yeah that sounds like a good idea, and This might not be the best way to save conditions, as others have pointed out. I guess that could be extended to !("confirmed" in user_groups), !("autoconfirmed" in user_groups), !"steward" in global_user_groups, among others.
The public filters that use one of these: 3 (hist · log), 11 (hist · log), 30 (hist · log), 31 (hist · log), 39 (hist · log), 46 (hist · log), 50 (hist · log), 59 (hist · log), 61 (hist · log), 79 (hist · log), 117 (hist · log), 132 (hist · log), 135 (hist · log), 172 (hist · log), 220 (hist · log), 225 (hist · log), 231 (hist · log), 249 (hist · log), 260 (hist · log), 323 (hist · log), 339 (hist · log), 345 (hist · log), 346 (hist · log), 351 (hist · log), 364 (hist · log), 365 (hist · log), 380 (hist · log), 384 (hist · log), 391 (hist · log), 432 (hist · log), 491 (hist · log), 550 (hist · log), 602 (hist · log), 614 (hist · log), 631 (hist · log), 636 (hist · log), 655 (hist · log), 664 (hist · log), 680 (hist · log), 686 (hist · log), 702 (hist · log), 707 (hist · log), 711 (hist · log), 712 (hist · log), 716 (hist · log), 735 (hist · log), 766 (hist · log), 803 (hist · log), 828 (hist · log), 869 (hist · log), 891 (hist · log), 894 (hist · log), 921 (hist · log), 942 (hist · log), 957 (hist · log), 970 (hist · log), 973 (hist · log), 981 (hist · log), 982 (hist · log), 994 (hist · log), 1031 (hist · log), 1034 (hist · log), 1035 (hist · log), 1043 (hist · log), 1045 (hist · log), 1048 (hist · log), 1074 (hist · log), 1081 (hist · log), 1086 (hist · log), 1088 (hist · log), 1112 (hist · log), 1119 (hist · log), 1132 (hist · log), 1151 (hist · log), 1157 (hist · log), 1159 (hist · log), 1163 (hist · log), 1183 (hist · log), 1188 (hist · log), 1197 (hist · log), 1199 (hist · log), 1200 (hist · log), 1201 (hist · log), 1208 (hist · log), 1212 (hist · log), 1233 (hist · log), 1243 (hist · log), 1245 (hist · log), 1248 (hist · log), 1272 (hist · log), 1285 (hist · log), 1291 (hist · log), 1294 (hist · log), 1296 (hist · log), 1297 (hist · log), 1300 (hist · log), 1318 (hist · log), 1339 (hist · log), 1340 (hist · log), 1344 (hist · log), 1348 (hist · log), and 1349 (hist · log).
That's a lot of filters, and it took a while to search for that stuff, so there might be some mistakes or omissions. – PharyngealImplosive7 (talk) 00:16, 24 March 2025 (UTC)
I don't know if that's such a good idea. It's doubtful that this would decrease the time taken by the filter, given that it's such a trivial comparison. If there were repeated occurrences of new_wikitext irlike "someexpensiveregex", that would be another matter. The condition limit is just a rough proxy for the cost of the filter, and in this case it's wrong. If we start running closer to the limit again, I think it would be better to look for unneeded or forgotten filters, or the really expensive stuff, rather than make these "fixes". Suffusion of Yellow (talk) 00:38, 24 March 2025 (UTC)
I don't argue that it would significantly improve performance, just that the current usage causes overcounting relative to how mw:Extension:AbuseFilter/Conditions notes that "function calls are cached, so they only add to the condition count the first time a specific function result is asked for". JensonSL (SilverLocust) 01:09, 24 March 2025 (UTC)
I'd argue that the overcounting is a minor bug or misfeature in the AbuseFilter extension. The only difference between an infix operator and a two-argument function is syntax. There's no reason for only one type to be cached, other than "no one got around to it." Given that the bug is not presently causing any problems, I don't see a good reason to work around it.
Now, if people think that contains_any is also more readable, that's another matter. I don't see a big difference, though I suppose it saves a few keystrokes if you later decide to add a second user group. Suffusion of Yellow (talk) 01:28, 24 March 2025 (UTC)
On the readability aspect, I'm not sure I personally would see much of a difference in the two. As for the overall question itself of whether it's a worthwhile idea to replace all of these, I don't really see the point of it. I guess if it makes it more readable, sure, but even if we started running close to the condition limit and absolutely couldn't part with any filters, it's not as if we haven't asked for an increase to the limit before. EggRoll97 (talk) 21:41, 25 March 2025 (UTC)

Filter 942: Log edits by administrators to fully protected pages

Does it make sense for 942 (hist · log) to include administrators adding the protection template to the page? It seems like we could remove those matches, but I wanted to ask before changing the filter because I'm not sure how this is being used. @Xaosflux: Pinging you as the original author. Thanks. Daniel Quinlan (talk) 00:02, 26 March 2025 (UTC)

It's a filter to see if an administrator is "using" their administrative access for activity reasons (in this case by editing through protection), also can be used by the community to check that when admins are editing through protection they are following the protection policy. So - it shouldn't skip some of the times they edit through protection. — xaosflux Talk 00:19, 26 March 2025 (UTC)
That makes a lot of sense, thanks for explaining. I added a note just in case anyone else has the same question in the future. Daniel Quinlan (talk) 00:44, 26 March 2025 (UTC)

About filter 174

Hi everyone, I'm looking for some solutions to improve this filter. The filter is preventing new users from removing XfD templates (including AfDM, mfd, Article for deletion, afd1), however in some cases where AfD nominators withdraw their nominations, they're allowed to remove the AfD template they added themselves. A false positive has been reported here.

I propose a solution as follows:

Step 1: Add a variable to AFD template to get the nominator name:

nominator = {{<includeonly>subst:</includeonly>REVISIONUSER}}

REVISIONUSER returns the last person who changed the article, in this case it returns the nominator's name at the time they added the AfD template to the article. The PROD template is using this method to get the nominator name.

Proposing to add a variable to get the nominator name

Step 2: Add a condition(s) to the filter, such as:

& !(removed_lines irlike user_name) or & !(user_name in removed_lines)

removed_lines contains "nominator = NominatorName" so the filter won't be triggered when the nominator removes the template, since their username matches NominatorName.

I'm not sure if this solution is feasible and it also requires modifying the AfD template. Hopefully someone has a better solution. Annh07 (talk) 00:12, 26 March 2025 (UTC)

If you use this approach, I think it would work best to use get_matches to extract the nominator name from the template in removed_lines so it can be compared directly to user_name. You will also want to make sure you can detect someone changing the username (to prevent someone changing it to their own username so they can subsequently remove the notice without triggering the filter). Daniel Quinlan (talk) 00:32, 26 March 2025 (UTC)
I also thought about that case, the proposed solution is to prevent new users from editing the AfD template if their username isn't in the template. Specifically, when a nominator adds an AfD template, their name is set in the template as "nominator = NominatorName", and they're the only one in the new users group allowed to edit/remove the template (without triggering the filter).
The filter currently only prevents new users from removing templates, it doesn't prevent them from editing the template, so if they change/add/remove any characters the template won't work properly. For example, if they remove the curly bracket at the end, the template will break, or they can vandalize by changing the page name to something else.
So I think there should be a filter to prevent new users (except the nominator) from editing the AfD template. Annh07 (talk) 02:22, 26 March 2025 (UTC)
Expanding the filter or adding a new filter to prevent new users from editing deletion templates sounds good to me. If feasible, I would try to add the functionality to 174 because they can share several early conditions. How broadly are you thinking we would define "new" for disallowing modifications?
By the way, it might be worth posting a link to this discussion on the template talk page. Daniel Quinlan (talk) 03:50, 26 March 2025 (UTC)
I think the original conditions should be kept. This would extend the filter from preventing new users from removing templates to preventing new users from editing and removing templates.
Currently, new users aren't allowed to remove AfD templates, however there's no reason to allow them to edit them either, the only exception is to fix bugs, but this rarely happens because if the template isn't working properly the nominator can quickly spot it and fix it.
As you suggested, I started a discussion on the template talk page. Annh07 (talk) 17:08, 26 March 2025 (UTC)

Random sample of all edits

I created filter 1301 (hist · log) to log a random sample of all edits to help with filter development and testing. I kept running into cases where 1201 (hist · log) logs were insufficient for developing filters that also match on non-autoconfirmed users.

It includes two additional terms to avoid multiple log entries at the same timestamp for page creations (where page_id == 0) since there will be more page creations with this filter. (There are some minor page creation clumps in the 1201 log with timestamps ending in "420" so it might be worth adding these terms to 1201.)

It only logs 1 in 10,000 edits so the effect on log size will be negligible. It will take some time to build up enough data to be useful, of course. Daniel Quinlan (talk) 19:13, 30 March 2025 (UTC)

Request to become edit filter helper

Withdrawn by candidate. –Novem Linguae (talk) 06:32, 1 April 2025 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

ScrabbleTiles (talk) 16:39, 31 March 2025 (UTC)

Oppose due to very low experience in helping out with edit filters (has made only five edits to EFFPR), and the OP has been active since December 2024, which I consider too early to apply for this very sensitive permission. Codename Noreste (talk) 19:23, 31 March 2025 (UTC)
(edit conflict × Codename Noreste) Strong Oppose and suggest a withdrawal: due to very little activity to filter-related pages, and the OP being a relatively new account. Most of the time, seeing private edit filters do not help when fighting vandalism, so I don't see much of a demonstrated need either. – PharyngealImplosive7 (talk) 19:28, 31 March 2025 (UTC)
Oppose Far below what would generally be considered requisite experience in the area. I'd encourage helping out more at EFFP and coming back with far more significant contributions to edit filters. EggRoll97 (talk) 01:17, 1 April 2025 (UTC)
Alright then, I see I have come too early. I will withdraw and help more in other edit filter areas. ScrabbleTiles (talk) 05:55, 1 April 2025 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Add Heritage Foundation to filter 869

Please add heritage.org to Special:AbuseFilter/869. Closure review of Heritage RfC closed as amended with "also deprecated". Please talk care to not harm heritage.org.nz or english-heritage.org or any other stuff.
Yes, they were blacklisted, but I think we'd forget if it were unblacklisted but not undeprecated. Aaron Liu (talk) 01:26, 27 March 2025 (UTC)

The added regex would be \b(?:(?<!english-)heritage\.org(?!\.nz))\b. Codename Noreste (talk) 01:32, 27 March 2025 (UTC)
That would exclude every heritage.org link. / and . are non-space characters. The filter currently relies on wrapping domains with \b which is generally okay although false positives are possible from "something-" before the match or ".tld" after the match (e.g., the examples Aaron Liu gave). I looked at this briefly when I updated the filter recently and it didn't look like a major issue, but out of paranoia, I'm going to review the last 100,000 hits to see if the regex needs to be more paranoid about those cases. Daniel Quinlan (talk) 07:55, 27 March 2025 (UTC)
There was one significant issue with "-rt.com" being the ending to some domains unrelated to "rt.com". That's fixed now. Daniel Quinlan (talk) 09:25, 27 March 2025 (UTC)
I've just fixed the regex that I noted (removed the negative lookbehind and lookahead for \S), opting to exclude said examples that Aaron Liu gave. Codename Noreste (talk) 14:15, 3 April 2025 (UTC)
I don't think it's a good idea to add blacklisted domains to the filter. It's already complex enough. If the domain is ever removed from the blacklist, adding it to an edit filter will almost certainly be part of the discussion. Daniel Quinlan (talk) 07:32, 27 March 2025 (UTC)

EFH for PharyngealImplosive7

SUCCESSFUL
EFH granted. Daniel Quinlan (talk) 02:03, 9 April 2025 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The earliest closure has started. (refresh)

Hello everybody. I'm presenting myself here to request the EFH right today. I've been thinking for some time whether to make this request go live or wait some more time, but EggRoll97's encouragement swayed me to go for it. I mainly want EFH to help author private filters and to help respond to false positive reports involving private filters at WP:EFFPR. It's been a few months since my last failed nomination, but since then, I've tried to address your concerns including increasing my activity overall and generally continuing to participate here.

EFH is a high-trust role, some would say on par with sysop, and whether it is granted to a user often depends on trust. I know the permission has significant repurcussions if abused, as it contains sensitive data used for fighting LTAs among other things. In terms of trust, I am identified to the Wikimedia Foundation (see m:Special:Diff/26090536) and am a pretty active user here.

In terms of my contributions to filters, I have made over 1400 edits to WP:EFFPR (see [2]) and have proposed numerous additions to filters both public and private. I believe that I have a strong understanding on the technical side of things (including regex), and some examples of where I've help create code for filters are shown below:

I would like to emphasize again that I understand that this is a very sensitive permission, and that I will only discuss the details of private filters with EFHs, EFMs, and sysops if granted this right. Finally, in terms of account security, I currently use a strong password, and although I don't have 2FA enabled right now, I am open to enabling it if this right is granted to me. Thank you for your consideration, and I'm open to any questions if you have them. – PharyngealImplosive7 (talk) 01:10, 2 April 2025 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Question regarding 1347

Regarding Special:AbuseFilter/1347, why did Special:Diff/1284477127 trigger it? Myrealnamm (💬Let's talk · 📜My work) 20:42, 7 April 2025 (UTC)

They pasted the entire content of the article (including the {{pp-vandalism}} template) inside a {{subst:trim}} template on the (unprotected) talk page. Most of that was substed away, except for one line from a table. The filter checks added_lines not the (supposedly slower) added_lines_pst, so it "saw" the pp- template even though it wasn't saved in the end. Suffusion of Yellow (talk) 21:06, 7 April 2025 (UTC)
Gotcha. So if an editor puts, say, gibberish, on an article inside a subst trim, then the filter would catch it. Ok, understand. Myrealnamm (💬Let's talk · 📜My work) 21:11, 7 April 2025 (UTC)
Yep, but there's nothing special about {{subst:trim}} here. That just removes leading and trailing whitespace. The problem was that they used table syntax inside a template argument, and the |s looked like extra arguments. Suffusion of Yellow (talk) 21:59, 7 April 2025 (UTC)
We should be able to add a check of added_lines_pst on line after the first added_lines without a significant performance impact (also changing the subsequent checks to use added_lines_pst). I went ahead and made that change. I'll double check the performance impact after it's been running for a while (it's at 0.12 ms and 2.7 conditions after 178,000 actions). Daniel Quinlan (talk) 00:12, 8 April 2025 (UTC)
The updated filter seems to be working fine and it was already down to 0.13 ms and 3 conditions after 29,000 actions. I realized the second added_lines_pst prefilter was unnecessary as long as we use added_lines_pst in the subsequent checks. I made some other improvements to bring the condition count down to 1 and improved the sandbox exception. We'll see how the performance numbers level out once it's been running long enough. Daniel Quinlan (talk) 05:54, 8 April 2025 (UTC)
After 95,000 actions, it's at 0.14 ms and it consumes 0.8 conditions, barely slower than the original 0.12 ms (could just be noise) and 0.8 conditions is definitely better than 2.7. Daniel Quinlan (talk) 18:32, 8 April 2025 (UTC)
Just a quick note that I added a warning to the filter since it seems accurate enough. It's at MediaWiki:Abusefilter-warning-protection-unprotected. @Queen of Hearts: Keeping you in the loop as the original author. Daniel Quinlan (talk) 19:59, 9 April 2025 (UTC)

Update regarding the temporary account option in GlobalPreferences and protected filters

Just a heads up regarding the Temporary account IP reveal option on Special:GlobalPreferences (for GAFHs and AFMs, or admins on some wikis): if you can view private and protected filters on a wiki (e.g. on Meta-Wiki or Test Wikipedia), and when the temporary accounts option is disabled in your global preferences, you may not view a protected filter nor its hit log until you enable that option.

Regarding the latter (and for example, on Meta-Wiki), this is what you will see when the temporary account option is disabled and you attempt to view a protected filter:

You may not view details of this filter, because it uses protected variables and is hidden from public view.

The same thing applies when attempting to view a protected filter's hit log:

One or more of the filter IDs you specified are protected. Because you are not allowed to view details of protected filters, these filters have not been searched for.

Note that this does not apply to the English Wikipedia or some other wikis that still have the AbuseFilter option in local preferences. Codename Noreste (talk) 01:49, 10 April 2025 (UTC)

Does this change affect local EFHs and EFMs as well? – PharyngealImplosive7 (talk) 02:31, 10 April 2025 (UTC)
Because temporary accounts are not yet enabled here, and because the AbuseFilter tick option is still available on the local preferences, the answer is probably no. Codename Noreste (talk) 02:50, 10 April 2025 (UTC)
The easiest fix here I think would be to improve the error message. Filed phab:T391549. On Phab, please feel free to click "Edit Task" and fix if I misunderstood something. –Novem Linguae (talk) 04:55, 10 April 2025 (UTC)
I haven't looked deeply into the issue, but that phab ticket seems to be requesting a change to MediaWiki:Abusefilter-edit-denied-protected-vars. We can do that here. You can usually find these system messages at [3] (or thereabouts). -- zzuuzz (talk) 05:54, 10 April 2025 (UTC)
I think it more likely needs a new message specific for AFH/Ms, EFH/Ms and sysops (any group that has abusefilter-access-protected-vars). Nobody (talk) 06:26, 10 April 2025 (UTC)
Agreed. Looks like MediaWiki:Abusefilter-edit-denied-protected-vars covers two situations. Modifying it to apply to situation 2 would make it wrong for situation 1, and vice versa. –Novem Linguae (talk) 07:04, 10 April 2025 (UTC)
Another heads up: per phab:T380920, the AbuseFilter tick option has been merged with the global temporary accounts IP reveal option, and T391549 has been closed as a duplicate of phab:T389640. Codename Noreste (talk) 02:53, 11 April 2025 (UTC)

Exclude Wikipedia:Files for upload from 1197

Exclamation marks come preloaded with a template, so please fully exclude Wikipedia:Files for upload, thanks. Codename Noreste (talk) 02:46, 18 April 2025 (UTC)

I would just add page_id != 9176046 to the filter. – PharyngealImplosive7 (talk) 13:32, 18 April 2025 (UTC)
 Done. I used !equals_to_any(page_id, 9176046, 26204397). Since I was in there, I also replaced the unnecessary rlike with contains and reordered things a bit. Daniel Quinlan (talk) 23:16, 18 April 2025 (UTC)

Idea: Allow EFHs to enable 2FA

EFH is a user-group with access to fairly sensitive data, so in my opinion, it makes sense for EFHs to have the ability to enable 2FA (which would require the oathauth-enable right) without going through SRG. I'm not sure if this would require a phab ticket, but I'd like to understand all of your opinions relating to this before taking any concrete action. – PharyngealImplosive7 (talk) 23:19, 20 April 2025 (UTC)

If you want 2FA just hop over to meta:Steward_requests/Global permissions#Requests for 2 Factor Auth tester permissions - it is pretty much given out on demand. — xaosflux Talk 00:37, 21 April 2025 (UTC)
I have to echo what xaosflux is saying here. While there's not really a downside to it, it's also not like there's any questions asked past "did you actually read the instructions?", and I can't remember the last time I saw a denied request for any reason other than not answering that question. EggRoll97 (talk) 01:01, 21 April 2025 (UTC)
Yeah, you both are probably right that it's not that much work just to go to SRG. – PharyngealImplosive7 (talk) 01:32, 21 April 2025 (UTC)
Especially as this is such a niche group with only a handful not having that access elsewhere, adding custom config here for it is a bit of a waste. — xaosflux Talk 23:13, 21 April 2025 (UTC)
This is largely the problem I had with Wikipedia:Village_pump_(proposals)/Archive_217#Should_other_groups_be_able_to_use_2FA_by_default?, and while there's actually some more merit (at least security-wise) in the proposal of automatic 2FA access for EFHs, it still runs into the same problem of "why not just ask the stewards?" in every case. EggRoll97 (talk) 00:32, 22 April 2025 (UTC)
I've been assuming that EFH's will get forced to use 2FA as part of T150898. Nobody (talk) 05:37, 22 April 2025 (UTC)

Encyclopedia Metallum for filter 869

Moved from Wikipedia:Edit filter/Requested/Archive 21 § Encyclopedia Metallum for filter 869

Encyclopedia Metallum, a.k.a. the Metal Archives, was deprecated by unanimous consensus in a 2025 RfC as a site rife with user-generated content and thus no hope of reliability. Because of the extensive use of the source in heavy metal and adjacent topics as discussed in the RfC, I believe this should be added to edit filter 869 along with the deprecation. Thanks! – Sparkle and Fade (talk • contributions) 05:33, 24 April 2025 (UTC)

Probably we could just add metal-archives to the .com section of 869. – PharyngealImplosive7 (talk) 18:02, 24 April 2025 (UTC)
Y Done at Special:AbuseFilter/history/869/diff/prev/35824. EggRoll97 (talk) 22:39, 24 April 2025 (UTC)
Thanks! – Sparkle and Fade (talk • contributions) 22:42, 24 April 2025 (UTC)

Filter 1358

1358 (hist · log) This filter looks a bit confused to me. I just thought I'd point out that most WMF accounts aren't in the staff group, and I assume this filter is checking for basically all WMF accounts (meta:Category:Wikimedia_Foundation_staff). All WMF accounts for the past several years are trailed with '-WMF', and before that ' (WMF)'. Anything containing 'WMF' is restricted in the global title blacklist, however, it seems older accounts with this string were grandfathered. Plus there's WMFOffice of course, who is in the staff group. Maybe a combination of those two endings, _or_ the staff group, would satisfactorily cover this filter's intentions? ('staff' in global_user_groups or user_name rlike '[\(-]WMF\)?$') (untested). Pings@Sohom Datta and Daniel Quinlan: -- zzuuzz (talk) 23:22, 25 April 2025 (UTC)

I was going to make a post or ask Sohom Datta, but you beat me to the punch. One of my main concerns with the regex approach was older accounts. I think it will be safe to use a regex on the username (and nothing else) if we exempt a complete list of any grandfathered accounts at the end. We can also exempt WMFOffice.
I should mention that I'm not entirely sure that we need this filter. Daniel Quinlan (talk) 23:47, 25 April 2025 (UTC)
I do agree with your concern about the raw WMF regex, and your last point. -- zzuuzz (talk) 00:06, 26 April 2025 (UTC)
Well, there were some grandfathered accounts (credit to this query by AntiCompositeNumber), but none have edited in a decade. Nevertheless, I occasionally see a long dormant account become active again so I included them as exceptions. It's basically free to put them at the end of the filter. Daniel Quinlan (talk) 00:42, 26 April 2025 (UTC)
I think it's a nice to have, especially for folks who have dual roles (both as a community member and a WMF employee) and the catalyst was Seddon mentioning on Discord that they had accidentally edited a normal article through their staff account. Sohom (talk) 00:07, 26 April 2025 (UTC)
The original vision was only for the article-space (for context). Sohom (talk) 00:08, 26 April 2025 (UTC)
I reviewed edits by staff members. Based on those edits, I think it's also worth warning for edits to several other namespaces so I expanded the filter to cover several namespaces in addition to article space. If that looks okay to everyone, I'll update the warning template as well. Daniel Quinlan (talk) 00:47, 26 April 2025 (UTC)
It might be worth it to also change the warning message (and move the mediawiki page): currently it just mentions the mainspace, since the filter has been expanded to other namespaces. – PharyngealImplosive7 (talk) 00:52, 26 April 2025 (UTC)
I think that's what I just said? Anyhow, I'll go ahead with those changes. We can always revise the template text later. Daniel Quinlan (talk) 00:56, 26 April 2025 (UTC)
Yeah. I had an edit conflict, so I didn't really read your response. Sorry. – PharyngealImplosive7 (talk) 00:59, 26 April 2025 (UTC)
No worries. Daniel Quinlan (talk) 01:15, 26 April 2025 (UTC)
I wonder if this is such a good idea. If they're removing links to CSAM, or something else we can all agree is oversight-worthy, they have to now remember to oversight their own filter log entry, too, or the material will still be available in old_wikitext. I see there's an exception for summaries such as "office action" and WMFOffice, but are such removals always made with those summaries, or that account? Suffusion of Yellow (talk) 19:12, 26 April 2025 (UTC)
This, but I'm also not sure WMF staff should really need a reminder that they should be using their volunteer accounts for non-official actions. Are WMF staff not trained not to use official accounts for volunteer actions? This seems like foisting a lack of sufficient Foundation training onto the community. EggRoll97 (talk) 19:24, 26 April 2025 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter_noticeboard/Archive_15&oldid=1290098522"