Wikipedia:Edit filter noticeboard/Archive 14

Archive 10

←

Archive 12

Archive 13

Archive 14

Archive 15

Update to filter 707

I recently made an update to the code that can potentially exclude users withdrawing their own report, here's what I made:

page_id == 26204397 /* False positives reports page */ &
!("confirmed" in user_groups) &
(
    (
        /* Prevent the removal or modification of [[WP:EFFPR]] headers */
        contains_any(
            removed_lines,
            "__NONEWSECTIONLINK__",
            "__NOINDEX__",
            "<noinclude>",
            "{{Wikipedia:Edit filter/False positives/Header}}",
            "{{shortcut|WP:EF/FP/R|WP:EFFPR}}",
            "</noinclude>"
        )
    ) | (
        /* Page blanking or report meddling from non-confirmed users */
        (
            new_size < 300 &
            old_size > 300 |
            edit_delta < -250
        ) &
        /* Allow users to withdraw their own report */
        !(
            user_name in removed_lines &
            user_name in page_recent_contributors
        )
    )
)

Any improvements or suggestions? Thank you. Codename Noreste 🤔 Talk 08:17, 8 October 2024 (UTC)

Moving !("confirmed" in user_groups) & down might make sense, as headers shouldn't be removed by other users either. Nobody (talk) 08:24, 8 October 2024 (UTC)

I like the idea, but I don't think there's really a lot of cases where a user would need to withdraw a report. Reports are responded to within a pretty decent amount of time, and archived fairly quickly after response anyways. EggRoll97 ^(talk) 15:45, 9 October 2024 (UTC)

Edit filter 1298

Going to just bring this one here in case there's any opinions about it, but Hey man im josh has brought up 1298 (hist · log) on my talk page as having flooded his log with false positives (ones in which he used Capricorn right after creating the redirect). Given the sheer number of false positives and the lack of much use of the edit filter to correct these uncategorized redirects, is there anyone who would object to disabling the filter? For context, see here for the discussion being referred to on my talk page. EggRoll97 ^(talk) 21:56, 11 October 2024 (UTC)

I feel like these kinds of log-only maintenance filters are often not a good idea. In my experience, these quickly ended up unmonitored and unused. I'm also personally wary of the edit filter being used for non-abuse related stuff much of the time. There are definitely legitimate use cases, but I think many requests at EFR for non-abuse related use cases were (are?) unnecessary. ProcrastinatingReader (talk) 22:40, 11 October 2024 (UTC)

I have 3 main issues with it.

1. Rcats are entirely optional. Would it be nice if people included them more? Absolutely, but a lack of them doesn't mean there's necessarily an issue. There's an implication based on this filter's existence, I believe, that a lack of rcats on the immediate creation of a redirect is a bigger sin than it really is.

2. The false positives. I often create a redirect and immediately tag it. I don't remember all the tags off the top of my head, I know the relevant ones that exist, but I don't know all the templates and I don't try to memorize them because I have tools to add the tags. I know where to find them in Capricorn and what to search in the page curation bar to add the tags. However the edit filter will still show these entries anyways.

3. If someone is looking for redirects to add tags to they'd be better served with a database query of some kind. Ideally something to the effect pages with redirects without rcats, sorted by target so that proper tagging can be done in batches.

Anyways, while I think there were good intentions with this filter, I don't believe it's actively used and helpful. It's more likely to drown out some relevant entries in an individuals abuse logs in my opinion. Hey man im josh (talk) 22:58, 11 October 2024 (UTC)

I know it was mentioned in the user talk discussion, but I'll re-mention it: This filter was created as a result of this request (permalink), which, disclaimer, I took part in.

Also pinging @Geardona as the original poster of the request (even if it was a request for a warn filter). – 2804:F14:80EB:C501:DD4E:2EFB:9ECB:8A56 (talk) 20:20, 12 October 2024 (UTC)

I sometimes patrol that filter log and add rcats where I'm sure, so I'd like the filter to stay enabled. Also I'm not sure if Josh knows this, but it's possible to add rcats while creating a redirect with Capricorn. If it's really that big an issue, then we can just add an exclusion for him (or the sysop user group for example) to the filter. Nobody (talk) 05:21, 14 October 2024 (UTC)

I mean, is a non-abuse filter with apparently 102,147 hits over the past six months really something that's practical to monitor? That's 500 new additions per day- when compared to other common non-abuse filters, we see it trips ten times as often as filter 1030 (URLs with tracking parameters) and 1,254(oops! you broke an sfn), and five times as often as 550 (nowiki tags). Again, with all due respect to people who do monitor it- I think there might be much more efficient solutions that don't clog up individual editor's filter log. GreenLipstickLesbian (talk) 06:13, 14 October 2024 (UTC)

I always thought that it would be better to have a tracking category for these redirects instead of a filter, but not sure if it's possible to get consensus for a tracking cat with possibly millions of redirects. Nobody (talk) 06:46, 14 October 2024 (UTC)

If there wouldn't be consensus for a tracking category, is getting around that by using an edit filter for something non-abusive really the better option? Hey man im josh (talk) 12:34, 15 October 2024 (UTC)

I think it's better than having nothing at all. Especially since it's easy to remove sysops or individual users from the filters. Nobody (talk) 14:40, 15 October 2024 (UTC)

@1AmNobody24: There are millions of redirects without rcats. This is not the way to address the problem, nor is it anywhere close to an efficient way to do so. By keeping a filter such as this active we're flooding the abuse log and reducing the effectiveness of it for a few individuals who would like to occasionally find redirects to add rcats to. If those individuals have that desire, I encourage them to instead join WP:NPP and patrol the massive redirect backlog we typically have. Hey man im josh (talk) 15:01, 15 October 2024 (UTC)

I agree that for new redirects NPP is better, it's one of the main reason I've considered applying for it. But at the same time there are millions of old redirects and ones from autopatrolled users that go unnoticed. I think there should be a way to track them. Be it a maintenance cat, a query, a filter or a external tool doesn't matter to me. Nobody (talk) 15:18, 15 October 2024 (UTC)

The old redirects, and this not being actually abusive in any sense of the word, is exactly why this edit filter doesn't make sense to keep in my opinion. Hey man im josh (talk) 15:20, 15 October 2024 (UTC)

I requested a quarry query (thank you Cryptic) to see how many uncategorized redirects we have. Based on this query, it appears we have 6,265,917 uncategorized redirects at the time of the run. They also provided a sample of 10,000 uncategorized redirects. A quarry query like this, in my opinion, would be far more useful for folks attempting to categorize redirects than flooding the logs. Pinging @1AmNobody24 and @Geardona, as they've been the only two I'm aware of who expressed interest in using this filter to tag redirects. Hey man im josh (talk) 18:00, 15 October 2024 (UTC)

That looks great, thanks for doing it. I'll probably ask Cryptic for some sorted querys then and start gnoming away. Given this, I have no objections to disabling the filter. Nobody (talk) 18:36, 15 October 2024 (UTC)

The missing datum here is that there's 11,150,454 total redirects in mainspace. So less than half are categorized. —Cryptic 18:48, 15 October 2024 (UTC)

 Done Given the Quarry query seems to alleviate all concerns, I've deleted the filter. EggRoll97 ^(talk) 19:19, 15 October 2024 (UTC)

graph links broken

The links to filter graphs from Special:AbuseFilter result in a page that says "Internal error". -- mikeblas (talk) 19:07, 20 October 2024 (UTC)

You mean https://ptwikis.toolforge.org/Filters:enwiki? Can confirm the error happens.

This seems like something that would also be a good fit for WP:VPT, if there's no immediate response here.

Last person to update that link was @WOSlinker in Nov 2020. – 2804:F14:80D7:A301:3134:44A8:18ED:5881 (talk) 19:35, 20 October 2024 (UTC)

The problem is that the replica database this tool uses doesn't have the `abuse_filter_log` table available anymore. Probably because of the new protected variables thingy? XXBlackburnXx (talk) 20:24, 20 October 2024 (UTC)

Most likely. There is a new box on edit filters saying "I understand that details of this filter will be hidden from users who cannot see protected variables", which likely shows up since global abuse filter helper now has abusefilter-access-protected-vars. I presume this new introduction may have broken it, though that's not necessarily the only reason. I've also raised this issue at WP:VPT. EggRoll97 ^(talk) 03:27, 23 October 2024 (UTC)

Request for Edit Filter Helper - Zippybonzo

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.

---

Zippybonzo (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)}

Zippybonzo (talk · contribs · count) • Heya all, I’m requesting Edit Filter Helper for 2 main reasons. Firstly, I’d like to be able to help out with private filters, I’ve got a decent level of experience with regex and the filter syntax, and secondly, when handling cases of vandalism, I have a script that shows filter hits in contributions, and quite frequently, they are private filters, which often add insight as to whether the user is potentially an LTA, which helps with my anti-vandalism work. It will also allow me to help process private filters false positives. Zippybonzo | talk | contribs (they/them) 16:12, 19 October 2024 (UTC)

• I don't really see that you have done much with filters recently. Xtools says that you've only made 112 edits to WP:EFFPR, when the average benchmark is around 500, and only 3 have been in the last 3 months. I don't really see you in the page history of WP:EFR suggesting regex or actual filters either recently and xtools says you have only made 1 edit to that page. On this very page, you haven't made any edits (besides this request) since february. I'm leaning oppose to granting this right to you for now until you can demonstrate that you are active in the area. Like many have said, this right is only given to the most trusted users and is similar to being granted sysop privileges. After one to two years of solid work in this area, I think you would be ready for this right. – PharyngealImplosive7 (talk) 18:00, 19 October 2024 (UTC)
• All I wanted to say is above, so oppose. Not enough recent contributions to EFFPR, nor enough at all. Your only contribution to EFR has been to suggest using the spam blacklist once. If you succeed in admin elections, which you are currently running in, this will be moot, though, since EFH is implicit in sysop. EggRoll97 ^(talk) 18:07, 19 October 2024 (UTC)

  @EggRoll97, the reason for requesting access was primarily to assist anti vandalism work, and the occasional handling of EFFP reports. Admittedly the whole request is moot atp, however I’m not expecting to succeed in AELECT because I’ve not been recently active enough, but I digress. It’s more that frequently when I come across disruptive editors tripping filters, they are private and it makes it a pain to handle said editors. The mention of EFFP was intended to come across as an, “as well it would mean I could” rather than a “that is why I am requesting”. Zippybonzo | talk | contribs (they/them) 18:28, 19 October 2024 (UTC)

  You satisfy the necessity for trust, but EFH is not generally given for anti-vandalism. This isn't meant as a slight against you, just that EFH is very rarely given, and I don't see much of a need here. The majority of filters are public filters (174 public filters, 157 private filters), and deal with most vandalism. Without a significant need past just anti-vandalism, I'm afraid my oppose remains. EggRoll97 ^(talk) 18:37, 19 October 2024 (UTC)

• Because of the concerns mentioned above, I oppose. The comment above is relevant, given that EFH is handed out to highly trusted users (comparable to holding either the administrator privilege or an advanced global permission) who want to help with filters, such as authoring either conditions that can track LTAs or somewhat complex regex to private filters. I would recommend helping on EFR and EFFPR for at least one whole year, then you might be ready to give a more solid explanation about your demonstrated need for this highly sensitive right. Codename Noreste 🤔 Talk 19:58, 19 October 2024 (UTC)
• The earliest closure has started, so could an admin close as not granted? – PharyngealImplosive7 (talk) 15:18, 28 October 2024 (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.

"Dumb premise"

Via Wikipedia:Administrators' noticeboard/Incidents#Vandalsock – yet another viral challenge. We appear to have a filter that intercepts social media and 'viral' nonsense, so please can someone add edits that include "dumb premise" and/or "bloodless series" to that filter? 81.2.123.64 (talk) 17:34, 23 October 2024 (UTC)

Which filter is this? EggRoll97 ^(talk) 04:40, 25 October 2024 (UTC)

I think they mean 614 (hist · log) Nobody (talk) 05:22, 25 October 2024 (UTC)

Hmm, perhaps any more evidence of further disruption, in addition to these two accounts mentioned on the ANI archive link? Codename Noreste 🤔 Talk 15:44, 25 October 2024 (UTC)

Seems fairly infrequent. I'm not necessarily eager to add the new terms without a bit more evidence of present disruption. EggRoll97 ^(talk) 22:32, 30 October 2024 (UTC)

Question about the 'Arbitration contentious topics alerts' filter

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.

---

• 602 (hist · log)

Maybe don't change the filter just to accommodate my unwillingness to create an account (again, like 707 at the top), but is there any reason for this filter to only go off for confirmed-or-up editors like it's currently setup? Is it just optimization? I have alerted people of contentious topics before (though, I think, only once: diff). – 2804:F1...88:7F3B (::/32) (talk) 22:09, 29 October 2024 (UTC)

By removing "confirmed" in user_groups, the filter should apply to ALL non-bot users, similar to 1016 (hist · log). Codename Noreste 🤔 Talk 17:38, 30 October 2024 (UTC)

I'm okay with removing the confirmed check (possibly replacing with !"bot" in user_groups instead? On the other hand, it's unlikely a bot would be tripping this filter). I'll leave it for a day or so in case anyone feels the need to comment regarding it with any objections. EggRoll97 ^(talk) 22:23, 30 October 2024 (UTC)

602 already excludes bots. Codename Noreste 🤔 Talk 23:06, 30 October 2024 (UTC)

You're right, it does. My bad. EggRoll97 ^(talk) 01:42, 31 October 2024 (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.

Request for Edit Filter Manager or Edit Filter Helper

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.

---

Z. Patterson (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)}

As a newly returned Wikipedian, I am interested in helping make or change edit filters to decrease the likelihood of disruptive editing. I was away from Wikimedia for several years, but I decided to come back. In 2024, I learned programming languages, and I also analyzed some edit filters before I came back. Thank you for your time and consideration. Z. Patterson (talk) 04:11, 2 November 2024 (UTC)

@Z. Patterson: Is this a request for EFM or for EFH? They are extremely different groups. See here for a description of edit filter managers and here for edit filter helpers. As a side note though, I will note that you don't appear to have any edit filter related contributions to your record, and generally those who successfully request either group have demonstrated a high level of experience. Can you point to any edit filter work you've done? EggRoll97 ^(talk) 05:10, 2 November 2024 (UTC)

See below. Z. Patterson (talk) 05:16, 2 November 2024 (UTC)

Welcome back to Wikipedia. The permission you are requesting is not given to users solely based on knowledge of regex and filter syntax; it is granted only to highly trusted users who have demonstrated need for it. I do not see any edits on edit filter-related pages, and this request is your only contribution to this noticeboard. This is also only your fourth edit since 2015. I would suggest spending one to two years reviewing edit filter false positive reports and suggesting changes to public filters before requesting EFH. – DreamRimmer (talk) 05:12, 2 November 2024 (UTC)

I understand now. Thank you. Z. Patterson (talk) 05:13, 2 November 2024 (UTC)

Z. Patterson Is it safe to assume the above comment is a withdrawal of this request? EggRoll97 ^(talk) 05:14, 2 November 2024 (UTC)

Yes. For now, I plan to withdraw this request and wait until I get more experience. Z. Patterson (talk) 05:15, 2 November 2024 (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.

Disable 1288?

1288 (hist · log)

In accordance with the process defined at Wikipedia:Edit_filter#Requesting_edit_filters, I propose the disabling of filter 1288 following concerns raised by Codename Noreste at EFFPR about false positives. I can't really describe this one, but EFHs/EFMs/sysops will be able to take a look. I have emailed the administrator who enabled the filter as of 19 days ago for clarification and discussion regarding the matter, but have received no response. In the filter results, I see a mix of common vandalism (which is either caught by other filters or would probably be caught immediately at RecentChanges) and false positives, but as far as I can tell, not a lot that actually matches the filter's intent. This is a cursory review, I'd welcome anyone setting me straight on it if I'm missing a large swathe of true hits. EggRoll97 ^(talk) 22:29, 30 October 2024 (UTC)

I can confirm that the target mentioned in the notes of filter 1288 aren't using any of the IP addresses in the ranges within the filter, and therefore, I strongly support this. Yes, they even know 1273 is for them. Codename Noreste 🤔 Talk 23:01, 30 October 2024 (UTC)

Sorry, been busy recently and haven't been able to respond much. Feel free to disable the filter. I don't expect to have the time to maintain it in the foreseeable future, unfortunately. —Ingenuity (t • c) 02:26, 3 November 2024 (UTC)

 Done Per consensus. EggRoll97 ^(talk) 02:34, 3 November 2024 (UTC)

Edit to 614

@Codename Noreste: suggested that we should modify the part of 614 (hist · log) that says (?:sean\s(?:\"?diddy\"?\s)?(?:(?:combs)|(?:john)))|(?:p?\s?didd(?:(?:y)|(?:ler)))|(?:puff\sdaddy)|(?:p\sdiddy) into sean\s?(?:\"?diddy\"?\s?)?(?:combs|john)|(?:p\s?)?didd(?:ler|y)|puff\s?daddy. As he said, this version of that code is less expensive in general. I have tested it thoroughly, and it seems to work about as well as the expanded code. – PharyngealImplosive7 (talk) 00:27, 4 November 2024 (UTC)

Request

My apologies but I am proposing a new crosswiki LTA filter, however, the request page explicitly states that such request be directed to wikipedia-en-editfilterslists.wikimedia.org, but to prevent possible outing, I refrain from doing so. I am willing though to send a Wikipedia email... ToadetteEdit (talk) 09:29, 4 November 2024 (UTC)

Feel free to send me the mail and I'll post it on the list for you. Nobody (talk) 09:43, 4 November 2024 (UTC)

Edit filter manager for Codename Noreste

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.

---

Codename Noreste (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)}

Hello, everyone. A few months ago, I was granted the edit filter helper right (as of July 13) and the global abuse filter helper right (as of September 6), and I am requesting the community to be granted the edit filter manager privilege as a non-administrator. My technical competence has improved significantly over the last few months when working with local and global filters as an EFH and a GAFH, and I have helped with the following filters: filter 707 (a previously disabled filter that currently stops disruption at EFFPR), a new private filter on the edit filter mailing list, and Meta filters 324, 344, 345, 360, 362, 365, 375, and 377.

Furthermore, if the permission was granted, I also plan to import some of Meta's private filters to here if needed, to fix any filter's regex or conditions if issues arise, to add or modify the conditions of local LTA filters that I have authored/maintained/edited on behalf on some edit filter managers (mainly 936, 1292, 1308, and parts of 1319), and to commit to reducing the current backlog of the edit filter mailing list by implementing suggestions.

I understand that this privilege is extremely dangerous if used on the wrong hands or with malicious intent, and I will use extreme caution and common sense when editing filters, especially when editing regex strings. I confirm that 2FA is already enabled on my main account, and I am available to respond to any feedback, questions, or concerns. Thank you for your consideration. Codename Noreste 🤔 Talk 05:00, 7 November 2024 (UTC)

Discussion

• Support. Extremely active on the edit filter mailing list. –Novem Linguae (talk) 07:41, 7 November 2024 (UTC)

  Courtesy links:

  • meta:Steward requests/Global permissions/2024-09#Global abuse filter helper for Codename Noreste
  • Wikipedia:Edit filter noticeboard/Archive 13#Edit filter helper for Codename Noreste (third nomination)
  • Wikipedia:Edit filter noticeboard/Archive 12#Edit filter helper request for 64andtim

  –Novem Linguae (talk) 07:46, 7 November 2024 (UTC)

• Procedural note: The administrator's noticeboard has been notified in accordance with WP:EFM at Special:Diff/1255917465. EggRoll97 ^(talk) 07:55, 7 November 2024 (UTC)
• Support. Despite a minor lingering concern over eagerness on overhauling filters, I will chalk this up to mainly a difference of opinion. I have no doubt as to their technical competency, and I haven't noticed anything majorly problematic. The comments by Daniel actually reminded me of multiple specific incidents in which I cautioned Codename Noreste via email about publicly talking about filters that were intentionally private. Because of that, I must oppose given I cannot trust in their discretion in good faith. EggRoll97 ^(talk) 08:00, 7 November 2024 (UTC)
• Support. Trusted and well experienced user. --TenWhile6 08:38, 7 November 2024 (UTC)
• Neutral On one hand, I know that they have made great contributions, especially to certain LTA filters, both here and on meta. On the other hand, there have been some discussion like this and this one which just didn't leave me with a good feeling. I've also seen comments by them that they intended to run for EFM next year or a year after they get EFH. What changed? Nobody (talk) 08:53, 7 November 2024 (UTC)

  (updated response) About the first discussion, I have changed my decision to run for EFM yesterday, and for Meta adminship, I decided not to run for that to avoid hat collecting. For the second discussion you mentioned, the CAPTCHA bypassed when I tested it with my alt/test account. An IP address mentioned that to me, and I told them there were no further replies to the task related to the CAPTCHA action after thanking them for the notification. For these two, I assumed good faith. Because of some very active LTAs, per the first sentence, that's what led me to run for EFM yesterday. I also have another filter targeting 1311's target in mind. Codename Noreste 🤔 Talk 15:13, 7 November 2024 (UTC)

  While I still don't understand what exactly happened in my CAPTCHA conversation, I didn't see it as anything to give a bad impression about, just some level of failure of communication.

  I won't vote, but I guess the only thing I'd ask of you, Codename Noreste, because it's recent, is what your thought process was behind revealing vague details about the LTA filter 1288 - I know of course that you're not the first to talk about some aspect of a private filter in vague terms, but I still want to know how you approach this. – 2804:F1...EF:A81F (::/32) (talk) 03:10, 8 November 2024 (UTC)

  I apologize for these two mistakes that I may have done, but as I said before regarding filter 1288, see here. Codename Noreste 🤔 Talk 03:33, 8 November 2024 (UTC)

  I meant revealing that the filter was focused on specific ranges of IPs, obviously that LTA would know about 'filter 1273', considering that was the public name of the now disabled filter 1288 ('LTA 1273'), as well as the public name of other filters targeting them. Was it because they weren't using those IPs anymore, so you felt that that information wasn't useful anymore, or what? I just want to understand how you decide if a detail like that is fine to talk about in public or not. – 2804:F1...EF:A81F (::/32) (talk) 03:47, 8 November 2024 (UTC)

  I did not mention what are the specific ranges used within the filter, but we should not discuss further about the vandal, and let's continue with my self-nomination for EFM. Codename Noreste 🤔 Talk 04:33, 8 November 2024 (UTC)

• I do not see anything significant to oppose, and 1AmNobody24's diffs do not appear to be significant. I do wonder whether this user is ramping up too fast though. Leaderboard (talk) 11:50, 7 November 2024 (UTC)
• Support per above. I've made filters with CN before, and fully trust him with this right. Changed to neutral because I don't know about these concerns but because they seem significant. – PharyngealImplosive7 (talk) 15:42, 7 November 2024 (UTC)
• CN seems to be a trustworthy user and I don't doubt their abilities; I'm sure they will do good work if they become an EFM. The request seems a little on the early side to me though. CN only registered 17 months ago and this is a flag that is sometimes considered more sensitive than sysop. I'm good either way, but just want to be cautious. Ternera (talk) 16:59, 7 November 2024 (UTC)
• Oppose. Codename Noreste has previously revealed private filter information on multiple occasions (in addition to the above example) in a way that has likely damaged the effectiveness of several filters, and I remain concerned about their discretion with sensitive data. It often seems like the point is to demonstrate their access to private information rather than necessity. They are also very persistent about low priority changes, which does not inspire confidence in how they might approach an expanded role. I am also concerned their approach could lead to filters becoming more complex and difficult to maintain. Combined with a persistent and unnecessarily urgent focus on acquiring permissions, I am concerned that they lack the caution and restraint essential for an EFM. Regretfully, I am closer to recommending a review of their EFH status than supporting this promotion to EFM. Daniel Quinlan (talk) 11:24, 8 November 2024 (UTC)
• Oppose for now per the above, and discussion on the mailing list. — TheresNoTime (talk • they/them) 14:17, 8 November 2024 (UTC)

Because of the ongoing criticism and concerns, I officially withdraw this. Codename Noreste 🤔 Talk 15:03, 8 November 2024 (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.

1178 was temp. disallow

Just a FYI that I quickly set 1178 to disallow for a while just now due to an active LTA at Wikipedia:Teahouse — I was actively monitoring & making changes as needed. It is no longer set to disallow. — TheresNoTime (talk • they/them) 21:22, 12 November 2024 (UTC)

EFFPR

Just noting that EFFPR was semi protected for 48 hours about ~16 hours ago. Seems kind of long. – 2804:F1...B0:60FE (::/32) (talk) 02:19, 13 November 2024 (UTC)

Yeah I know, but I guess you have to deter the socks somehow. – PharyngealImplosive7 (talk) 02:22, 13 November 2024 (UTC)

Not that I expect anyone to do this, but it seems surprisingly possible to create better system (temporarily activated when needed) by creating a filter that disallows every non-autoconfirmed edit at EFFPR (with an appropriate banner telling them that their report is saved pending a bot check) and also create a bot that checks each disallowed edit to see if it's a new report and then checks if the IP/account that made the report triggered an LTA filter (or any filter at all) recently, and if it looks okay (criteria of your choice) the bot then adds the report... but that's like, a crazy idea.

-

But I digress, semi protection is fine too, I just think it's useful for people who frequent EFN to know if a longer-than-usual protection was done.

So there, you have been informed. – 2804:F1...B0:60FE (::/32) (talk) 03:10, 13 November 2024 (UTC)

That all makes sense, but it might be quite difficult to implement such a system for such a niche purpose. – PharyngealImplosive7 (talk) 14:37, 13 November 2024 (UTC)

Set filter 1318 to warn/tag?

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.

---

• 1318 (hist · log) (Possible projectspace redirect vandalism, public)

Judging by the hits, it appears to be ordinary vandalism, and we want this type of junk off our project redirects. If set to warn, rename it to Projectspace redirect vandalism. Codename Noreste 🤔 Talk 20:43, 11 November 2024 (UTC)

Oppose until set to warn for at least a short period. I don't think there's any big hurry here. It doesn't get a lot of hits, and warn filters do sometimes scare off the opportunistic disruptors. EggRoll97 ^(talk) 20:49, 11 November 2024 (UTC)

I'll change this to only warn and tag instead of disallow. Codename Noreste 🤔 Talk 20:56, 11 November 2024 (UTC)

Now modified. Codename Noreste 🤔 Talk 21:03, 11 November 2024 (UTC)

Support Setting to warn/tag. EggRoll97 ^(talk) 21:26, 11 November 2024 (UTC)

Support setting the filter to warm/tag after analyzing the filter hits. Also support the name change. – PharyngealImplosive7 (talk) 22:59, 11 November 2024 (UTC)

Support The filter currently has a less than 2% false positive rate (around 1 hit per month on average). I've been looking to expand it's scope to other non-article namespaces based on past edits and possible false positives, but this change should not impact that. Nobody (talk) 06:18, 12 November 2024 (UTC)

Comment. Per my comments at Archive 13, before testing is considered over and any actions are taken, could someone please change "added_lines irlike break | new_size > old_size & !added_lines irlike rcat" to represent its true intentions and be less ambiguous? Mixing booleans is an increasing trend that I have a problem with, and I don't think I'm alone. According to the documentation, this is going to be evaluated as "(added_lines irlike break | new_size > old_size) & !added_lines irlike rcat". If that's the intention, please say that. While I'm here I'll note the redundant regex on line 11. Not sure why we're checking both removed_lines and old_wikitext, but then I haven't managed to fully parse the filter as of yet. -- zzuuzz ^(talk) 13:34, 12 November 2024 (UTC)

Your right, I wrote it with the intention of X & (A | (B & !C)), but it currently is X & (A | B & !C) which doesn't have the same result, according to the documentation. But I don't think line 11 is redundant. Line 9 gets hits like this, while line 11 is for hits like this. I don't think this can be made easier. Nobody (talk) 13:59, 12 November 2024 (UTC)

Thanks for the examples. What I meant was that the regular expression on lines 1, 9, and 11 is currently identical, but lines 9 and 11 are written very differently. -- zzuuzz ^(talk) 14:07, 12 November 2024 (UTC)

I see what you mean, why line 11 isn't old_wikitext irlike redirect & right? I'm not sure why I left it that way, probably a leftover from testing. Nobody (talk) 14:14, 12 November 2024 (UTC)

I've updated the code and added 2 new namespaces that haven't shown any false positives while checking recent changes. Code is here. Nobody (talk) 07:59, 13 November 2024 (UTC)

This is updated in the filter code. EggRoll97 ^(talk) 00:50, 15 November 2024 (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.

Edit filter helper for PharyngealImplosive7

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.

---

PharyngealImplosive7 (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)}

The earliest closure has started. (refresh)

Hello everyone. I am running for EFH today because I believe that I can extend my regex and filter-creating skills to helping and improve private filters. I have tried to reflect on my failed previous nominations, and since then, have tried to keep being active in pages like WP:EFFPR, WP:EFR, and WP:EFN.

I have just under ~1200 edits to WP:EFFPR (see xtools, [1]) and have tried to be very careful when clerking these reports. I have made edits to numerous filters including: 54, 614, the disabled filters 1323 and 1298 (now disabled, but I guess they both still show my competence with edit filters). I have also worked on the private filters 1161 (to enforce WP:DADASAHEB, a private filter to target an LTA on meta with User:Codename Noreste (courtesy ping to @Codename Noreste: to our conversation over email), and am also making another filter to track another very persistent LTA also with User:Codename Noreste. I am also currently suggesting a filter on WP:EFR that tracks changes to hurricane categories without a source (now 1324).

I understand the gravity of this permission, which is on par on sysop, and promise to not disclose any information about private filters to anyone without admin, EFH, or EFM privileges. I also have signed the Wikimedia Foundation's Confidentiality Agreement for Nonpublic Information.

In conclusion, I believe that I should receive this very permission because of my numerous technical contributions, whether on WP:EFFPR, on WP:EFR, or on WP:EFN. Thank you for your consideration. – PharyngealImplosive7 (talk) 23:39, 10 November 2024 (UTC)

Discussion

Note: Past requests: 1, 2. Nobody (talk) 06:17, 11 November 2024 (UTC)

• Neutral Oppose Pros: Active involvement with LTA filters, consistent involvement with edit filters; Cons: Generally low activity (xTools), implementing edits with errors Diff; TL;DR: Given the fact they've made only around 150 filter related edits since the last request, there's not much to look at. And while it looks like they've done some decent regex since the last request, the low general activity doesn't strike me as they'd make a huge impact with the right. Nobody (talk) 09:51, 11 November 2024 (UTC)
• Neutral, but leaning oppose, no prejudice to a future request. I also don't see much, but the low activity combined with a fairly non-descriptive edit summary (just "per EFFP", when there are tools like EFFPHelper from SoY that give a more descriptive summary) don't inspire confidence. Again, don't let this stop you in the future, I think these are really minor concerns, but while I think you're trustworthy, I don't think there's a demonstrated need yet. EggRoll97 ^(talk) 20:54, 17 November 2024 (UTC)
• Due to very minimal participation here, and the fact that you have emailed me various times about creating a private edit filter with regex and all, I am only willing to strongly support this (with no objections from me) if you actually take the following into consideration: learn from my mistakes and do not learn the hard way like I did here (please only use the mailing list when discussing about private filters), and keep up a semi-active level of activity including non-technical related contributions. As long as you stay on learning the easy way, then you have my full trust for this highly sensitive permission. Cheers, Codename Noreste 🤔 Talk 23:20, 17 November 2024 (UTC) Because of another vote change, I have made the difficult decision to strike out my vote and to switch to neutral. I would still recommend keeping up a high level of activity including non-technical contributions, and to never learn the hard way like I have done, unfortunately. Codename Noreste 🤔 Talk 12:00, 18 November 2024 (UTC)

---

• A consensus for access did not emerge. — xaosflux ^Talk 15:17, 18 November 2024 (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.

Removal of EFH from AFHs

If you compare Edit filter helper#Criteria for revocation and Abuse filter helpers#Removal it makes sense that anyone (other than self-requested) who loses Abuse filter helper should probably also not have Edit filter helper anymore. Based on that, I think the Edit filter helper right should be removed from Abuse filter helpers. This currently would apply to four of our Edit filter helpers: Praxidicae, Fehufanga, Codename Noreste and 1997kB. Thoughts? Nobody (talk) 12:51, 19 November 2024 (UTC)

Don't think this is necessary, besides the components of an external global group could be modified externally - so no need to tie these together. — xaosflux ^Talk 13:11, 19 November 2024 (UTC)

Are you saying Codename Noreste had abuse filter helper revoked? Can you link to a log entry for that please? I'm not seeing it at meta:Special:GlobalUserRights/Codename_Noreste –Novem Linguae (talk) 13:17, 19 November 2024 (UTC)

No. I'm saying that anyone who has AFH removed should have EFH removed and due to that it's redundant for AFHs to also have EFH. Nobody (talk) 13:19, 19 November 2024 (UTC)

Huh? Anyone who has AFH removed should have EFH removed? That seems completely ridiculous, there are many reasons why an AFH could have the group removed, but that may not be linked to their work here. Additionally, someone may wish to step down as an AFH, and if they didn't have EFH on enwiki but wished to retain it, it causes some issues IMO, and I don't see how redundancy is relevant really. Zippybonzo | talk | contribs (they/them) 17:06, 19 November 2024 (UTC)

The only reasons that someone has AFH removed are: misuse, inactivty, giving it up or getting another role that has it included. In any of these cases having EFH isn't needed and I even mentioned in the first comment other than self-requested. And wish to step down as an AFH, and if they didn't have EFH on enwiki but wished to retain it wouldn't work that way, as they'd have to go through an EFH request. Nobody (talk) 18:14, 19 November 2024 (UTC)

Ah, so apparently this sentence from WP:EFH makes sense, for anyone who's wondering: Abuse filter helpers and abuse filter maintainers can view private filters on all wikis, and by extension the English Wikipedia, and hence do not need to request this right here. Codename Noreste 🤔 Talk 20:19, 19 November 2024 (UTC)

Yes that’s my point. If you already have EFH locally, and wanted to step down from AFH but retain EFH here it wouldn’t work if you didn’t have EFH anymore. It’s a solution looking for a problem. Zippybonzo | talk | contribs (they/them) 20:26, 19 November 2024 (UTC)

I don't think that's really necessary. Technically, the EFH group is used for access to the mailing list (I may be mistaken, but I don't think GAFHs get access to the enwiki edit filter list). Outside of that, though, EFH implies a high level of community trust. If someone has passed a consensus discussion (the overwhelming majority of EFHs here), they should be permitted to keep the local rights. We don't revoke rollback for global rollbackers, how is this any different? EggRoll97 ^(talk) 20:57, 19 November 2024 (UTC)

Filter 1325

• 1325 (hist · log)

I created this filter based on this version of WP:WPAIC/C to capture potentially AI-generated material. This is my first time trying to make a filter and I want to have it tag eventually. I received some syntax help from @Codename Noreste, but would like someone more experienced than me to verify that there aren't any issues. Also, how long should I wait to rename it from "test filter" and set up tagging? Thanks charlotte ^👸♥ 01:30, 18 November 2024 (UTC)

It appears that it's in your public test filter, so if there are mostly true positives, you can split it to a new filter that should have its own log. Also, new_wikitext checks for text that is already on the page (when a user makes an edit to that page), so added_lines is definitely recommended here. The filter will eventually catch false positives, so it's best for the filter not to tag any edits at all during its testing phase. Codename Noreste 🤔 Talk 01:40, 18 November 2024 (UTC)

Checking added_lines without checking removed_lines is the check for some text being in the edited section (whether it existed previously or not). Think of added_lines and removed_lines as being what's shown in a diff. new_wikitext is a check of the whole page, and not just the part being edited. You could look at an example such as 345 for what I think you're probably attempting. I'd think about leaving at least a week before thinking about tagging. IMO, a broad filter like this will likely generate many false positives. -- zzuuzz ^(talk) 02:14, 18 November 2024 (UTC)

If that is the case, I have a redesign of filter 1325 using a variable and some simplified syntax, and have somewhat simplified the regex a little bit:

stringy := "(?:(?:stand|serve)s? as|is) a testament|play(?:ed|s) a (?:vital|significant) role|it is (?:important to note|worth noting)|rich (?:cultural heritage|history)|as of my|as (?:an AI|a large) language model|I hope this helps|must-(?:visit|see)|stunning natural beauty";

equals_to_any(page_namespace, 0, 118) &
!contains_any(user_groups, "extendedconfirmed", "sysop", "bot") &
added_lines irlike stringy &
!(removed_lines irlike stringy)

Codename Noreste 🤔 Talk 02:34, 18 November 2024 (UTC)

I don't think extendedconfirmed should be in the list of excluded user groups, as I've seen extended-confirmed users add likely AI-generated content before. Chaotic Enby (talk · contribs) 17:38, 18 November 2024 (UTC)

I haven't, but I'll take your word for it.  Removed charlotte ^👸♥ 19:53, 18 November 2024 (UTC)

If you want, a user right that could be more relevant to filter out is autopatrolled, as we usually trust them with content. Chaotic Enby (talk · contribs) 20:26, 18 November 2024 (UTC)

What about excluding manually assigned user groups, and not just autopatrolled users? Also, are there any diffs of extended confirmed users posting AI-generated content? Codename Noreste 🤔 Talk 21:01, 18 November 2024 (UTC)

For examples of an EC user creating (multiple) AI-generated articles, this comes to mind: Wikipedia:WikiProject AI Cleanup/List of uses of ChatGPT at Wikipedia#Articles created by Coin945. Also Special:Diff/1135438246. They're much rarer than for non-EC users, so I understand the rationale for excluding them, but we can adjust it depending on the amount of false positives we get. Chaotic Enby (talk · contribs) 21:21, 18 November 2024 (UTC)

I might suggest using user_editcount or a similar function, since the current setup of the filter (with no usergroup exclusions) will evaluate every edit made ever to the encyclopedia's main and draft namespaces. If extended-confirmed users are part of the intended target of the filter, perhaps something like user_editcount > 2000? EggRoll97 ^(talk) 21:02, 19 November 2024 (UTC)

Also, here are a few relevant articles I've read about identifying AI keywords:

• The telltale words that could identify generative AI text (Ars Technica)
• TechScape: How cheap, outsourced labour in Africa is shaping AI English (The Guardian)

Chaotic Enby (talk · contribs) 17:54, 18 November 2024 (UTC)

Protected filters

It seems we can now add the 'Protected' flag to a filter, which seems to irreversibly activate abusefilter-access-protected-vars for that filter. Apparently using user_unnamed_ip in a filter automatically protects the filter (part of the temporary accounts thing), but this flag can also be set manually. As I understand it, with our current rights setup, this prevents the filter from being viewed by (local) EFH and EFMs. Some of this seems a bit iffy to me, but in particular I'm sure we don't have a policy about any of it. Am I missing something? Do we have any thoughts? -- zzuuzz ^(talk) 22:23, 8 November 2024 (UTC)

A few days ago, Ohnoitsjamie protected 1165 (hist · log), but 1033 (hist · log) would also be a good candidate for protection. We could add information about protected filters) to the edit filter project page regarding this. I believe this might require consensus on the mailing list or somewhere to mark a filter as protected. Codename Noreste 🤔 Talk 23:08, 8 November 2024 (UTC)

Weird - I did not intend to protect that (wasn't even aware that was a thing), must have been an accidental click. It's odd that it can't be undone. My intention is that all of my filters should be accessible and viewable by edit filter helpers and managers, but hidden otherwise, as they mostly target LTAs who are always looking for ways around them. OhNoitsJamie ^Talk 18:28, 9 November 2024 (UTC)

Ohnoitsjamie, I've sent you another email, with more reasons that should never be discussed on public. Codename Noreste 🤔 Talk 23:36, 9 November 2024 (UTC)

These filters are already private. You are saying, with our current rights, that we should disallow local EFM and EFH from viewing these filters and their logs? Actually I'd disagree. But it's weird that global AFH have this right, but not local groups. If we give this right to local groups then I don't see any benefit to protecting a filter (other than the benefit of irreversibility). Also, I'm not on the mailing list (and don't have a good opinion of off-wiki consensus). -- zzuuzz ^(talk) 23:25, 8 November 2024 (UTC)

I didn't say we should not allow non-administrator EFMs and EFHs to view/edit protected filters. They can, but they might want to sign the confidentiality agreement for personal information first. Codename Noreste 🤔 Talk 23:37, 8 November 2024 (UTC)

The current effect is that they won't be able to view the filters or their logs. Moreover, as I understand it signing an NDA does not grant this right. I doubt global AFH have to sign an NDA, yet they have this right, and for the record I have signed an NDA but only the checkuser version and nothing related to temporary accounts (though whether I'm relevant is debatable). -- zzuuzz ^(talk) 23:47, 8 November 2024 (UTC)

I brought it up at T369610#10233370 last month to Tran (WMF), since I assumed there would be some inpact for us even before temporary accounts came to enwiki. I believe it should be possible to determine per local consesus to give access to EFM and EFH before temporary accounts come are enabled here Nobody (talk) 07:18, 10 November 2024 (UTC)

It doesn't seem there's been any discussion about 'abusefilter-access-protected-vars' before on enwiki[2] (about who should have the right anyways).

The documentation also says that the logs generated by a protected filter are only visible to people with a different right (abusefilter-protected-vars-log, mw:diff, added 4 days ago) which, if I'm to believe Special:ListGroupRights, is currently only given by default to checkusers (not even admins)? Is this correct? (*edit: if the phab is correct, this is not what this right is) – 2804:F1...37:F619 (::/32) (talk) 23:38, 8 November 2024 (UTC) *edited 00:19, 9 November 2024 (UTC)

Only administrators of this project have this right. As for the CheckUser thing, I am not sure. Codename Noreste 🤔 Talk 23:39, 8 November 2024 (UTC)

I think you're right. So let's compare EFH, Global AFH, some random non-EFM admin, EFM admin, and me, checkuser. -- zzuuzz ^(talk) 00:00, 9 November 2024 (UTC)

I did some searching and I think the current 'default' state of things is coming from this phab: T369610.

Seems mostly to be adjusting for Legal's decisions. – 2804:F1...37:F619 (::/32) (talk) 00:02, 9 November 2024 (UTC)

Apologies, per phab:T369610#10240941, by the same person who wrote the documentation in my diff, 'abusefilter-protected-vars-log' is not a right that allows people to view the logs generated by protected abusefilters, but instead a right that gates access to the audit/usage logs of when someone views information around protected variables - the same right that lets people edit protected filters let them view the filter logs.

Basically, pretty much irrelevant to working with protected filters themselves - if it's just some meta-logs. – 2804:F1...37:F619 (::/32) (talk) 00:18, 9 November 2024 (UTC)

Well to begin with filters shouldn't be applied irreversible protections as was done to Special:AbuseFilter/1165, especially since it was needless as it does not make use of user_unnamed_ip. This is a temporary accounts-related privacy change. Filters that most likely do need protection (and migration) include Special:AbuseFilter/847, for instance. I'm still not quite sure what abusefilter-protected-vars-log does though. DatGuy^Talk_Contribs 00:40, 9 November 2024 (UTC)

If I finally understood, that just lets checkusers see logs like these(phab, gerrit), but specific to viewing protected filter logs/vars.

The documentation is just confusing. – 2804:F1...37:F619 (::/32) (talk) 00:50, 9 November 2024 (UTC)

As I understand it, migration (when it happens) should automatically trigger the protection and it won't need adding manually. So the documentation is inconsistent, and the rights will probably be changing at some point. At this time I maintain that protecting a filter prevents any access from EFHs and EFMs. Whether this will be true in the future is unknown, but in any case there seems to me to be dubious benefits to manually adding protection. Either people viewing private filters are going to be allowed protected access, or we choose to deny their access through protection based on other aritrary criteria. I'd suggest we just don't allow it to be manually added (through policy and signposting) at this time. Or at least agree that we don't encourage it. We might need to have further discussions at some point about adding user_unnamed_ip around migration time, since it will apply that irreversible protection. -- zzuuzz ^(talk) 01:00, 9 November 2024 (UTC)

We could always get ahead of the game, technically, and form a consensus to add abusefilter-access-protected-vars to EFH and EFM. Everyone in those groups (with the exception of SPI clerks) is in there by some form of consensus, so I doubt the WMF would object given I don't see anyone with less than 6 months tenure and 300 edits (the criteria for access to temporary account IPs) being an EFH, much less an EFM. EggRoll97 ^(talk) 02:50, 9 November 2024 (UTC)

Only commenting on the last part of what you said, note that some bots have EFH and EFM, but may not meet those specific criteria. For example, ProcBot II has EFM and does not have 300 edits. Daniel Quinlan (talk) 03:33, 9 November 2024 (UTC)

Fair, though its operator meets the criteria, and I imagine the bot would just be judged by the operator's eligibility. EggRoll97 ^(talk) 04:21, 9 November 2024 (UTC)

So realistically I'm thinking we shouldn't be protecting any filters at all unless the software blocks saving a filter absent a protection. With not every EFH and EFM being necessarily able to access protected filters, we shouldn't be using the toggle, given it's basically just a glorified and irreversible action of setting a filter private, but named differently. EggRoll97 ^(talk) 02:50, 9 November 2024 (UTC)

Note: There's phab:T377765 and phab:T378553 about warning/preventing irreversible protections if no PII variables like user_unnamed_ip are used. Johannnes89 (talk) 09:18, 10 November 2024 (UTC)

I'll also recommend this feature to be temporarily enabled on all projects (except projects that will get Temporary accounts...soon). This is to avoid confusion, and allowing the feature to be piloted without affecting other projects. Task is phab:T379503. Protected variables are not needed except for dealing with Temporary accounts. Best, Martin Urbanec (talk) 20:19, 10 November 2024 (UTC)

Given the confusion, it would probably be a good idea to allow some select group, e.g stewards, to mark a filter "un-protected". Otherwise we're one fat finger away from disappearing the whole log of 384 (hist · log). Suffusion of Yellow (talk) 22:11, 10 November 2024 (UTC)

If the solution at T377765 is implemented to make it impossible to protect a filter unless it uses protected variables is implemented, the fat-fingering problem will be resolved. If not, yeah, there probably should be a right added to the steward group like abusefilter-unprotect to remove that protection. EggRoll97 ^(talk) 23:58, 10 November 2024 (UTC)

Related: phab:T378551. There are like 5 open tasks related to this specific issue <shrugs>. XXBlackburnXx (talk) 10:44, 11 November 2024 (UTC)

FTR: I've talked to the Trust and Safety Product team (that is responsible for this feature) and we went through the tasks. The issue should be resolved within a couple of weeks at most. The feature would be temporarily disabled on projects where it is not yet needed. The checkbox should be also changed to a warning system (allowing filter managers to only protect a filter if it actually needs to be protected). Unprotection will be possible via a Phabricator task, given it is unlikely this would be ever needed again. If you have any questions, I'm happy to answer them. Martin Urbanec (talk) 23:14, 11 November 2024 (UTC)

Protected variables access for EFH/EFM

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.

---

Tracked in Phabricator
Task T380332
Resolved

So given this has already become a problem once, it seems like a good idea to add abusefilter-access-protected-vars to edit filter helpers and edit filter managers. I'm assuming we probably need some form of consensus to ask the devs to add it to the groups, and I'll go ahead and just bite the bullet and propose it here. Is there anywhere this should be advertised, or is EFN enough? EggRoll97 ^(talk) 23:58, 10 November 2024 (UTC)

• Support as proposer. EggRoll97 ^(talk) 23:58, 10 November 2024 (UTC)
• Note: this has now been advertised at the technical village pump. Codename Noreste 🤔 Talk 00:21, 11 November 2024 (UTC)
• Anyway, support access to allow non-admin EFHs and EFMs to view (and if appropriate, edit) protected edit filters. Codename Noreste 🤔 Talk 00:21, 11 November 2024 (UTC)

Support per everyone else above. – PharyngealImplosive7 (talk) 00:40, 11 November 2024 (UTC)

• Support. This seems like the only logical option. — Red-tailed hawk _(nest) 03:13, 11 November 2024 (UTC)

Support seems sensible. Galobtter (talk) 04:19, 11 November 2024 (UTC)

• Support This makes sense. Nobody (talk) 06:12, 11 November 2024 (UTC)
• Support. It seems obvious to me as a global AFH that anything on enwiki I can see, local EF[HM]s should also be able to see. -- Tamzin^{[cetacean needed]} (they|xe) 08:34, 11 November 2024 (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.

1178 disallowing

Similar to above, but I'm going to leave it on disallow for a bit — TheresNoTime (talk • they/them) 23:05, 19 November 2024 (UTC)

Why is the filter set to both warn and disallow? Codename Noreste 🤔 Talk 16:26, 20 November 2024 (UTC)

Probably just forgot to uncheck "warn" — either way, it's no longer disallowing — TheresNoTime (talk • they/them) 18:53, 20 November 2024 (UTC)

1094 is probably broken

I've notified Ohnoitsjamie, it's catching around 30% of all filters caught rn, I don't know what's happening (I'm not an EF helper). Myrealnamm (💬Let's talk · 📜My work) 19:39, 23 November 2024 (UTC)

Fixed. Jamie, please ensure it works as intended now. DatGuy^Talk_Contribs 19:50, 23 November 2024 (UTC)

Courtesy ping @Ohnoitsjamie Myrealnamm (💬Let's talk · 📜My work) 19:52, 23 November 2024 (UTC)

It's  fixed now. Codename Noreste 🤔 Talk 00:17, 24 November 2024 (UTC)

Resurrect ST47ProxyBot?

I've created a phab ticket to discuss possibly resurrecting ST47ProxyBot. phab:T380917. –Novem Linguae (talk) 21:15, 26 November 2024 (UTC)

Wikidata changes and the edit filter

Is it known that edits at Wikidata can generate an invisible edit action here on Wikipedia, if there is an existing page associated with that data? (assumption)
For example, these are the variables generated by the Edit Filter for d:Special:Diff/2279185334. It's an edit action with an empty edit_diff - I wonder if it's ever not empty? (kinda hard to find these, they don't show up the examine list for me, just like the minor edits don't).
I guess what I'm getting at is:

• Is this intended? Is this known? (is this correct?)
  • If not, then does this affect anything?
    

Obviously I'm only asking a response from what you feel you should/can answer, if it's not known but it affects something private (unlikely) then I'm fine with just pointing it out so you can consider if it does and how. I just found this unexpected, didn't find it in the documentation (and in a basic search of noticeboards).
Edit: I'll add a description of facts, to not make things confusing with my assumptions:

• An an user edited the Wikidata item d:Q3331189 (d:Special:Diff/2279185334, Wikidata's /examine: d:Special:AbuseFilter/examine/2347391270)
  • that item is associated with Edition (book) here on Wikipedia
• This generated an /examine for an 'edit' action here on Wikipedia (Special:AbuseFilter/examine/1844633861)
  • the page shown in the /examine's page_prefixedtitle is Wikipedia:Featured articles in other languages/Russian
• This did not appear to cause any filter hits (on enwiki and on wikidata) and did not generate any visible edits (on enwiki).

– 2804:F1...E8:775A (::/32) (talk) 18:51, 24 November 2024 (UTC) *edited: 19:59, 24 November 2024 (UTC)

There 's no related data on enwiki. I don't know why there would be, but then I don't know of any invisible edit action on wikidata that generates anything here. The last filter hit for Edition (book) (on this wiki) was in March this year. -- zzuuzz ^(talk) 19:07, 24 November 2024 (UTC)

I hadn't noticed that, the examine says the page that the edit action happened was Wikipedia:Featured articles in other languages/Russian, not even Edition (book).

Now I understand it even less. – 2804:F1...E8:775A (::/32) (talk) 19:31, 24 November 2024 (UTC)

Looking at the AF source code, it looks like this might be a bug with /examine or /test. Wikidata edits shouldn't normally go through the abuse filter of other projects. XXBlackburnXx (talk) 21:15, 24 November 2024 (UTC)

Another example: Special:AbuseFilter/examine/1844717211 shows an edit from Jevansen to Category:Politics and government work group articles, even though Jevansen never made any edits to that category. ¯\_(ツ)_/¯ XXBlackburnXx (talk) 21:55, 24 November 2024 (UTC)

This edit seems to be the cause (the diff matches, it's the correct timestamp too)... but where did that edit summary come from?

Perhaps there really are invisible 'edit' actions, caused by other changes, one being Wikidata changes? – 2804:F1...E8:775A (::/32) (talk) 23:27, 24 November 2024 (UTC)

If you really want to figure out what's going on there you'd probably have to ask on Wikipedia:Phabricator. Nobody (talk) 06:09, 25 November 2024 (UTC)

Wait, I decided to search for the edit summary of the non-visible category edit, found out it's the message MediaWiki:Recentchanges-page-added-to-category, searched for that I found out:

- These are recent changes related, they do indeed exist and are tracked here on Wikipedia!

- The non-visible category edits (that @XXBlackburnXx found) are here: Type of change: Category changes (they don't really have diffs)

- The non-visible Wikidata edits (that I found) are here: Type of change: Wikidata edits (don't have diffs either, they just link to the Wikidata diff)

These are intentional. So yeah, apparently the filter can see them, they're just perceived as edits... thinking really deeply about it, I'm pretty sure this does not have any unintended effects on any filter... well there IS a good amount of them per minute(both). – 2804:F1...F1:29EC (::/32) (talk) 21:09, 25 November 2024 (UTC)

Though that makes me curious... what happens if a filter disallows/warns/captchas one of these? – 2804:F1...F1:29EC (::/32) (talk) 21:26, 25 November 2024 (UTC)

Back in 2013 they wanted to have Wikidata changes show in article's histories (phab:T42358)... the idea is that a change in Wikidata (ex: changing the description of a page or adding/removing a language link, etc.) can affect the Wikipedias - this does not answer the question of what even happens if an enwiki filter disallows one. – 2804:F1...F1:29EC (::/32) (talk) 21:54, 25 November 2024 (UTC)

This is a bug in the /examine page, as I said earlier. The /examine page retrieves data from the `recentchanges` table in the database, and attempts to generate variables as accurately as possible, but it also unintentionally checks CategoryMembershipChanges and Wikidata edits. These actions are never processed by the AbuseFilter. XXBlackburnXx (talk) 23:09, 26 November 2024 (UTC)

Oh, well then, sorry for misunderstanding you. I found it very interesting, but sorry for wasting people's times. – 2804:F1...1F:8749 (::/32) (talk) 23:41, 26 November 2024 (UTC)

Active filters that should have the extendedconfirmed condition modified

• 782 (hist · log)
• 833 (hist · log)

Per Wikipedia:Edit filter/Traps and pitfalls#user_rights, please change !("extendedconfirmed" in user_rights) to !contains_any(user_groups, "extendedconfirmed", "sysop", "bot"), as user rights when using a bot password or an OAuth application may be limited. Thank you. Codename Noreste 🤔 Talk 03:31, 28 November 2024 (UTC)

 Done EggRoll97 ^(talk) 00:08, 29 November 2024 (UTC)

Setting 174 to disallow

Follow up from this discussion.

Are there any objections to setting 174 (hist · log) (New user removing XfD template) to disallow? This would hopefully help curb a fair amount of disruption and should have very few false positives. C F A 22:49, 24 November 2024 (UTC)

This makes sense to me and I don't see a problem with it. Ternera (talk) 17:30, 25 November 2024 (UTC)

 Done; I've tried to add wording for good faith non-XCON editors trying to close XfDs to MediaWiki:Abusefilter-disallowed-removing-xfd-notice, feel free to suggest improvements. charlotte ^👸♥ 05:17, 1 December 2024 (UTC)

I have a couple of suggestions, one for the message and one for the filter itself:

For the message, I have this suggestion that should appear less bitey and included so it has been disallowed as well as some grammar fixes:

{{edit filter warning
| filter = 174
| action = disallow
| friendly = yes
| text = An automated filter has detected that you are attempting to remove an [[Wikipedia:Articles for deletion|Articles for deletion]] or [[Wikipedia:Miscellany for deletion|Miscellany for deletion]] notice from this page, so it has been disallowed. Please understand that removing it will not stop the discussion from taking place, and discussions should only be closed by experienced users. If you oppose the deletion, please comment at the respective page instead. If you did not remove any such notice, please [[Wikipedia:Edit filter/False positives|report this error]].
}}

Message preview

As for the filter itself, I would suggest this modification to reduce the condition limit a little, just below:

xfdRegex := "\{\{(?:AfD[M1]|Article for deletion|mfd)";

equals_to_any(page_namespace, 0, 2) &
!contains_any(user_groups, "extendedconfirmed", "sysop", "bot") &
removed_lines irlike xfdRegex &
!(added_lines irlike xfdRegex)

Please also remove the tag from the filter, as edits that are disallowed by filter 174 are never going to be tagged when prevented. Thanks. Codename Noreste 🤔 Talk 06:07, 1 December 2024 (UTC)

 Done charlotte ^👸♥ 19:29, 1 December 2024 (UTC)

Thanks. C F A 15:35, 3 December 2024 (UTC)

Filter hit missed?

Why didn't this edit get hit by 1318 (hist · log)? Nobody (talk) 06:54, 9 December 2024 (UTC)

It doesn't match because of the !(new_html rlike 'class="new" title="') condition. It looks like the most recent change added that condition. EggRoll97, could you please take a look? Daniel Quinlan (talk) 21:40, 9 December 2024 (UTC)

I've updated the code with the fix. Thanks Daniel for pointing it out. Nobody (talk) 06:07, 10 December 2024 (UTC)

That is a bit more of a logic change than I was expecting. I updated the filter. Daniel Quinlan (talk) 07:04, 10 December 2024 (UTC)

Thanks, was already out for the night when I got that ping. EggRoll97 ^(talk) 16:37, 10 December 2024 (UTC)

Implement my suggestion to filter 707?

Courtesy link from October: Wikipedia:Edit filter noticeboard/Archive 14#c-Codename Noreste-20241008081700-Update to filter 707.

See the following log entries for edit filter 707 that are users who tried to withdraw their own reports, but were prevented:

• Special:AbuseLog/39450648
• Special:AbuseLog/39427289
• Special:AbuseLog/39249126
• Special:AbuseLog/39122043

Therefore, I would propose the following update for 707:

New filter code for 707

page_id == 26204397 /* [[WP:EFFPR]] */ & !("confirmed" in user_groups) & ( ( /* Prevent the removal or modification of headers */ contains_any( removed_lines, "__NONEWSECTIONLINK__", "__NOINDEX__", "<noinclude>", "{{Wikipedia:Edit filter/False positives/Header}}", "{{shortcut|WP:EF/FP/R|WP:EFFPR}}", "</noinclude>" ) ) | ( /* Page blanking or report meddling from non-confirmed users */ ( new_size < 300 & old_size > 300 | edit_delta < -250 ) & /* Allow users to withdraw their own report */  !( user_name in removed_lines & user_name in page_recent_contributors & edit_delta > -1500 ) ) )

Any questions or concerns regarding the new filter code? Thank you. Codename Noreste 🤔 Talk 04:18, 11 December 2024 (UTC)

Like I said in the initial thread, I don't think users are going to be removing their reports very often. One of those is absolutely not a false positive, the others have abuse logs that show disruption to the encyclopedia, so there's not really a benefit to allowing these vandals to withdraw their report. Frankly, I don't see much of a point here. EggRoll97 ^(talk) 19:20, 11 December 2024 (UTC)

And your code also has the ability to let users remove their title and potentially other reports, which is still a form of vandalism. I agree with EggRoll97 here that this change would probably be not needed. – PharyngealImplosive7 (talk) 20:29, 11 December 2024 (UTC)

I officially withdraw my filter suggestion. Codename Noreste 🤔 Talk 21:31, 11 December 2024 (UTC)

Anyway, keep in mind that this was my attempt to exclude duplicate EFFPR reports made by legitimate users while disallowing unexplained removals by vandals. However, for now it's not the time to implement this experimental code. Codename Noreste 🤔 Talk 02:09, 12 December 2024 (UTC)

LTA check

Hey, would an EFM familiar with the LTAs being handled by filter 1094 give their input on whether this edit is likely the LTA being addressed with that condition? —Compassionate727 ^(T·C) 21:16, 13 December 2024 (UTC)

It's just the addition of a filter-blacklisted source, and no it's not intended for any LTA. Codename Noreste 🤔 Talk 21:52, 13 December 2024 (UTC)

Redundant filter check

Line 73 of filter 1242 seems to check for the same string twice. Not going to be more specific than that because of the filter being hidden, but I assume this was unintended and can be fixed. —Compassionate727 ^(T·C) 19:57, 25 December 2024 (UTC)

•  Done — xaosflux ^Talk 22:30, 25 December 2024 (UTC)

Preventing unauthorized changes to edit filter configuration

Inexperienced users should not be making changes to Template:DatBot filters related to filters they may not be able to view, especially new or experimental filters that aren't stable, and there's potential for abuse by disruptive users. This is something I've been concerned about for a while. Generally, we would solve this with template protection or full protection, but that would prevent EFMs and EFHs from modifying the page, so I instead added a filter at 484 (hist · log). While this is a bit of a corner case right now, the runtime cost is very low, and I think there may be some similar use cases in the future. Daniel Quinlan (talk) 22:46, 26 November 2024 (UTC)

I talked with DatGuy earlier, keeping him in the loop here. Daniel Quinlan (talk) 22:53, 26 November 2024 (UTC)

I mean, feasibly template protection could work, the only problem that would be run into would be that all the (10?) non-admin EFMs would likely immediately request the template editor permission, which isn't a...bad idea (I've mentally floated proposing editinterface to eliminate the need for edit requests for filter messages, but frankly I don't have the confidence to put it up for an RfC given it would likely fail pretty badly, given it includes all the MediaWiki pages, not just the ones adding it would fix). Theoretically the granting guidelines are merely guidelines, and I can't think of a much better substitute for proof of technical experience than a community consensus showing such. EggRoll97 ^(talk) 23:37, 26 November 2024 (UTC)

Yeah, adding the templateeditor right to EFMs is another option. However, it's not worth proposing based on a single example (the proposal would also likely fail), especially when we have a workaround that addresses the immediate need. Daniel Quinlan (talk) 00:01, 27 November 2024 (UTC)

Most people don't edit that page, and the edit request process is always available too. — xaosflux ^Talk 17:41, 28 November 2024 (UTC)

I wondered in the past if it would make sense that: Those who can't see private filters, can't add them to {{DatBot filters}}. I guess Daniel had the same idea. Nobody (talk) 06:23, 27 November 2024 (UTC)

And FYI, there are no users that disruptively moved that edit filter configuration page, but it's better to be safe than sorry. Codename Noreste 🤔 Talk 21:19, 27 November 2024 (UTC)

The page has been indefinitely fully move protected for several years. Daniel Quinlan (talk) 21:31, 27 November 2024 (UTC)

I'll also just note that why we need to enforce pseudo-edit protection that goes beyond EC users (that do not hold edit filter privileges) is because of Special:Diff/1259682905. Codename Noreste 🤔 Talk 16:59, 28 November 2024 (UTC)

A single unwanted edit? That's what revert is for. — xaosflux ^Talk 18:20, 28 November 2024 (UTC)

No. That user added a private filter while they can't see private filters. Codename Noreste 🤔 Talk 19:02, 28 November 2024 (UTC)

And? This section starts with the exciting title that this is needed to secure the "edit filter configuration" - this is a bot's page, it is not the configuration of the abusefilter. — xaosflux ^Talk 11:35, 2 December 2024 (UTC)

• I don't think we should be using the abusefilter as page protection for a single page. — xaosflux ^Talk 17:39, 28 November 2024 (UTC)

  Do you mean this as in "We shouldn't use an abusefilter for pseudo page protection" or "We shouldn't have a abusefilter for one specific page"? Nobody (talk) 18:42, 28 November 2024 (UTC)

  Both, but especially the later. Using it for an entire very broad class of pages is sometimes OK (e.g. the one against base userpages). — xaosflux ^Talk 10:48, 2 December 2024 (UTC)

  I agree with the later. With the former I'm not sure, since there isn't some kind of edit filter protection level. (And I don't think there will be, since a RfC about that would probably end with a bunch of "just become an admin and full protect it.") Nobody (talk) 11:59, 2 December 2024 (UTC)

  Yes, there are some very specific use cases where this could make sense- and that one that applies to 48 million+ pages is an example. — xaosflux ^Talk 13:38, 2 December 2024 (UTC)

  If we had a way to allow edits by EFMs (see above), I would be inclined to agree. Without this filter in place, the risk is too high. We're dependent on DatBot to report abuse to AIV and there's significant history of disruptive editors modifying configuration (in the last year: User:DatBot/Filter reporter/Run, User:MDanielsBot/AIVStop, User:Lowercase sigmabot III/Shutoff, User:ClueBot NG/AngryOptin, User:GreenC bot/button, and User:Yapperbot/kill/FRS). Some specific LTAs will similarly remove, or attempt to remove, page protection requests. I also don't believe this will limited to a single page in the future. I think we can let it grow organically, though. Daniel Quinlan (talk) 20:27, 28 November 2024 (UTC)

  In fairness, those are quite uncommonly abused. So long as there are editors which notice the bot isn't running (there will usually be, if the bot is doing a useful task) they should reactivate. The shutoff pages should be quite accessible so any editor can turn it off if something goes wrong - autoconfirmed/extendedconfirmed are decent barriers to abuse IME.

  Immediately, like xaosflux, I don't see any issues in the history of Template:DatBot filters to suggest ECP isn't working. (If there were, I would prefer to use templateeditor protection on the page, and give the TE userright to the very few non-admin EFMs that don't already have it.) ProcrastinatingReader (talk) 10:44, 2 December 2024 (UTC)

  This edit was an extended-confirmed user adding a private and experimental filter to the configuration (i.e., they had no idea what the filter did), while the filter was still being changed frequently. And nobody watching the page even blinked. Also, autoconfirmed is definitely not enough based on the history of those filters. For example, GreenC bot has been shut off twice recently by both an autoconfirmed user and an extended-confirmed user. Daniel Quinlan (talk) 17:12, 16 December 2024 (UTC)

Per discussion above, I'd like to suggest disabling the filter and continuing to rely on ECP (or TE, if necessary) protection. Would that be OK with you, Daniel Quinlan? ProcrastinatingReader (talk) 10:19, 16 December 2024 (UTC)

Maybe with an edit notice that warns users, that only those who can see private filters, should modify private filter listings and misuse can get them page blocked? Nobody (talk) 12:20, 16 December 2024 (UTC)

Let me spend some time pursuing a user right solution. I've been occupied with some other edit filter priorities the last several weeks. Daniel Quinlan (talk) 16:55, 16 December 2024 (UTC)

I concur that using an edit filter to enforce a kind of ghost protection for a specific page is a bad idea. * Pppery * _{it has begun...} 21:38, 27 December 2024 (UTC)

• @Daniel Quinlan: I'm not seeing consensus above that this blocking filter is supported - any comments? — xaosflux ^Talk 23:24, 27 December 2024 (UTC)

  I think there are more pages that could be usefully covered by this filter, but I haven't had time to work on this more. I've disabled it. Daniel Quinlan (talk) 03:44, 28 December 2024 (UTC)

Filter 602 and {{Welcome-arbpia}}

I think that it would be natural to log the {{Welcome-arbpia}} under filter No. 602, since it's a sort of a contentious topics notification that makes users aware of the topic area as well as restrictions within it. Currently, someone who checks the filter logs would miss when somebody is assigned the template, which could lead to redundant notifications. If we log this, it would be improved.

(Courtesy ping to ScottishFinnishRadish, who created the template.)

— Red-tailed hawk _(nest) 05:06, 27 December 2024 (UTC)

I think this would have to go through ArbCom because only {{Contentious topics/alert}} and {{Contentious topics/alert/first}} count as the "official" standardized awareness notices (i.e. simply using the welcome template does not make the user formally "aware") IIRC. C F A 05:28, 27 December 2024 (UTC)

I had thought that they got rid of the super formal requirements for "awareness" when we moved from DS to CTOP. But looking at the language in CTOP, there is still some strictness for the first CTOP alert. Maybe it's worth a WP:ARCA to see if ArbCom is OK with this sort of thing. — Red-tailed hawk _(nest) 05:57, 27 December 2024 (UTC)

Probably not a bad idea. C F A 15:01, 27 December 2024 (UTC)

That's why I normally drop the alert/first along with it, but that does work against the purpose of not BITING and flooding the talk page with a bunch of legalese. ScottishFinnishRadish (talk) 15:03, 27 December 2024 (UTC)

In my mind, the obvious obstacle to it being considered sufficient for awareness is that it only mentions one of the three restrictions active in the area. —Compassionate727 ^(T·C) 20:29, 27 December 2024 (UTC)

That's fair. — Red-tailed hawk _(nest) 19:51, 28 December 2024 (UTC)

I think we should stick with considering that template an informal introduction. Perhaps /alert/first could be transcluded into the Welcome-arbpia template, so it's presented at the same time, which would allow it to be considered a CTOPS formal alert? That would satisfy the requirement that the specific template be used, and still present a summary picture of CT procedures, rather than legalese alone. EggRoll97 ^(talk) 02:39, 28 December 2024 (UTC)

Filter 869 and checkyourfact.com

I think that checkyourfact should be removed from line 3, given that the recent RfC closed with the source being deemed generally reliable (see: WP:CHECKYOURFACT). I would ordinarily do this myself, though I participated in the discussion, so I'm asking someone else to do it. — Red-tailed hawk _(nest) 22:22, 31 December 2024 (UTC)

Courtesy link: 869. JJP_Master (she/they) 22:40, 31 December 2024 (UTC)

 Done. -- zzuuzz ^(talk) 23:05, 31 December 2024 (UTC)

user_rights variable unavailable on edit filter log entries on this project

For now, unlike Meta and other projects, there are only the user_groups variable available on enwiki. Because of this, I have listed some various filters that might need a temporary workaround until user_rights can be brought back here:

• 51 (hist · log) and 54 (hist · log) (line 2)
• 102 (hist · log) (line 76)
• 425 (hist · log) (line 3)
• 579 (hist · log) (line 2)
• 887 (hist · log) and 890 (hist · log) (line 2)
• 1156 (hist · log) (line 16)

Any comments, suggestions or thoughts? Thank you. Codename Noreste (talk) 03:12, 1 January 2025 (UTC)

Anyone know the technical reason that enwiki doesn't have this? Is this something we can change with a #wikimedia-site-config phab ticket? Is there a reason we turned it off? –Novem Linguae (talk) 06:26, 1 January 2025 (UTC)

user_rights exists if you visit Special:AbuseFilter/examine - at least it does for me and my recent edits. And this example. The filter has always had these weird context-sensitive variables that don't reliably show up in the log details, and I wonder if this is one of those. -- zzuuzz ^(talk) 09:54, 1 January 2025 (UTC)

We definitely used to have it. I remember seeing it pop up in filter hits before. I wonder if it was disabled as part of IP masking? EggRoll97 ^(talk) 22:02, 1 January 2025 (UTC)

User_rights is a lazy loaded variable, meaning it only loads whenever a filter asks for it. This helps conserve computing resources. XXBlackburnXx (talk) 15:17, 3 January 2025 (UTC)

Yep, this was caused by these three changes back in August. All those changes are "correct" (see WP:EF/TP#user_rights), but combined they have the side effect of removing user_rights from most hits (though the filters listed above will continue to work fine). If anyone wants it back (for testing purposes), we can create a filter like "user_rights; /* and other variables we want */; false;" to force its generation. Compare filter 1201 (hist · log). Suffusion of Yellow (talk) 19:04, 3 January 2025 (UTC)

Are you saying that user_rights will show up in the details of every filter log as long as a filter is always checking its value?

It makes sense as an optimization, it's just surprising that it's shown at all in the logs of filters that don't use it (before, after).

Is this only for lazy loaded variables? No risk of a filter checking an IP and causing the variable to be shown in a public log? – 2804:F1...B4:2F7D (::/32) (talk) 00:08, 4 January 2025 (UTC)

Correct; there's one variable dump shared by the all the log entries from a single action. Non-lazy-loaded variables just appear in every hit. Not sure about IP addresses, but based on a few minutes of checking on testwiki, it looks like user_unnamed_ip is replaced with a placeholder if viewed without the appropriate rights. With the "Enable revealing IP addresses for temporary accounts in AbuseFilter" option unchecked in my preferences, I can still view testwiki:Special:AbuseLog/105182 but user_unnamed_ip is an empty string. With the option checked, the full IP does show even though testwiki:Special:AbuseFilter/94 isn't checking it. Suffusion of Yellow (talk) 01:42, 4 January 2025 (UTC)

Exclude pages that have "emoji" in their title from filter number 680

Those articles are about emojis themselves, and preventing people from inserting emojis on articles about emojis limits collaboration and defeats said articles' purpose. Therefore i kindly request that all users should be free to insert emojis on articles that have the word "emoji" or "emojis" in their title, for example Eggplant emoji and Pile of Poo emoji. 67.209.130.188 (talk) 08:14, 9 January 2025 (UTC)

I think we could just add a line to the code: !(page_title irlike emoji), which should solve the problem. – PharyngealImplosive7 (talk) 18:32, 9 January 2025 (UTC)

What about changing the last line from:

• !(new_wikitext irlike "\bastro|category:unicode blocks")

to:

• !(new_wikitext irlike "\bastro|category:unicode blocks|category:individual emoji")?

While the IP proposed the creation of an article where the title is emojis, that doesn't seem to be common. – 2804:F1...48:45EA (::/32) (talk) 20:09, 9 January 2025 (UTC)

Looking at the articles in the category (few that there are) to see how often this is a false positive vs disruptive edits, I only found a single false positive (log) vs a handful of disruptive ones. I mean that's admittedly not a lot of disruption, but it's still some.

Are there more articles about emojis that aren't in the category? – 2804:F1...48:45EA (::/32) (talk) 20:19, 9 January 2025 (UTC)

Regarding that false positive (as well as the page title exclusion), that's why !(old_wikitext rlike emoji) (instead of removed_lines) should solve that specific problem, if such FPs happen often.

Regarding the articles in the category, what category are you talking about? Codename Noreste (talk) 02:49, 10 January 2025 (UTC)

The words the category are a link to Category:Individual emoji, that's the category both example pages are part of (and the one my speculative change added).

Like Daniel I also checked the past filter hits, though for the whole category, and only found the one good attempted edit - that's why I was asking if there were more example articles, as if this is it then the filter is way more likely to stop bad edits than not, by not excluding emoji articles. – 2804:F1...BA:8B28 (::/32) (talk) 15:28, 10 January 2025 (UTC)

But the problem is that emoji is a variable for the emoji regex, and there are only Unicode blocks for emojis. For now, regarding the page title exclusion, I agree with Daniel. Codename Noreste (talk) 02:40, 10 January 2025 (UTC)

I reviewed the last 4 matches of filter 680 on Eggplant emoji and Pile of Poo emoji and 3 out of 4 are bad edits. I don't think it makes sense to exclude emoji articles from this filter. Daniel Quinlan (talk) 01:54, 10 January 2025 (UTC)

I echo what Daniel said above. Status quo seems best here. EggRoll97 ^(talk) 10:46, 11 January 2025 (UTC)

Yes, now that I think about it, I agree with the others. Keeping the filter the same seems good here. – PharyngealImplosive7 (talk) 17:17, 11 January 2025 (UTC)

Add EADaily to deprecates sources

Could someone add eadaily.com to filter 869, per WP:RSP#EADaily? Thanks. Aaron Liu (talk) 19:40, 12 January 2025 (UTC)

 Done. –Novem Linguae (talk) 21:36, 12 January 2025 (UTC)

Disabling filter 1238 (private)

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.

---

Based on the filter hits I don't think the filter needs to be enabled anymore. Thoughts? Nobody (talk) 06:25, 13 January 2025 (UTC)

It would probably be better to continue on the edit filter mailing list. Codename Noreste (talk) 08:17, 13 January 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.

Filter 614 and 'low taper fade'

• 614

I've seen quite a bit of recent vandalism involving the term 'low taper fade', 'imagine if Ninja got a low taper fade' and other similar variants. Seems to be coming from an Internet meme, so could this be added to filter 614? Entranced98 (talk) 18:37, 14 January 2025 (UTC)

 Done –Novem Linguae (talk) 05:55, 15 January 2025 (UTC)

Discussion at Wikipedia talk:Large language models § LLM-generated content

 You are invited to join the discussion at Wikipedia talk:Large language models § LLM-generated content. Chaotic Enby (talk · contribs) 11:25, 31 January 2025 (UTC)

Should have probably cross-posted this at WP:EFR instead, my bad. Chaotic Enby (talk · contribs) 23:19, 1 February 2025 (UTC)

Add Geni.com to deprecated source

Could someone add *.geni.com, *genealogy.eu, and *.genealogy.euweb.cz to Special:AbuseFilter/869 per Wikipedia:Reliable sources/Noticeboard/Archive 465#RfC: Geni.com, MedLands, genealogy.eu? Thanks in advance. Aaron Liu (talk) 14:09, 5 February 2025 (UTC)

Possible regex could be geni\.com|genealogy\.eu(?:web\.cz)?. – PharyngealImplosive7 (talk) 14:45, 5 February 2025 (UTC)

PharyngealImplosive7, your regex suggestion looks great, but the only modifications I made was that I escaped the . (periods) with backslashes. Without the backslash, the period would match any character or letter. Codename Noreste (talk) 18:18, 5 February 2025 (UTC)

Oh yes, I forgot to add the delimiters. Thanks for that. – PharyngealImplosive7 (talk) 18:55, 5 February 2025 (UTC)

Y Done EggRoll97 ^(talk) 05:40, 9 February 2025 (UTC)

Implement my suggestion to filter 707 from WP:EFR?

• 707 (hist · log)

Pinging 1AmNobody24 and PharyngealImplosive7 per WP:EFR, Special:Diff/1274183006 is why we should implement my suggestion to filter 707 that can disallow additions to EFFPR with more than 2500 bytes or more. I have decided to cross-post it to here due to minimal responses other than myself and those users who participated in the EFR thread. Codename Noreste (talk) 23:21, 5 February 2025 (UTC)

I think your suggestion looks good. You just forgot the !(summary irlike "^(?:revert|rv|undid)") at the end of the filter but otherwise it looks fine. We might need to make a custom message so people understand why their edit was disallowed also. – PharyngealImplosive7 (talk) 23:59, 5 February 2025 (UTC)

Filter 707 already has a custom message, MediaWiki:Abusefilter-disallowed-EFFPR, but you meant that we should modify that message as your suggestion. What should we add to the message, should we enact your suggestion (and to add | friendly = yes)? Codename Noreste (talk) 00:18, 6 February 2025 (UTC)

And to top it off, I added your suggestion (revert exclusions) to my filter suggestion. Codename Noreste (talk) 00:22, 6 February 2025 (UTC)

So right now the message is fairly vague, and I think we should add the | friendly = yes parameter also. Here is my suggestion:

{{edit filter warning
| filter   = 707
| action   = disallow
| friendly = yes
| text     = <center>An automated filter has identified this edit as potentially unconstructive. Please be aware that meddling with this page's headers and/or false positive reports will result in [[Wikipedia:Blocking policy|revocation of your editing privileges]]. Also, please note that you do not need to paste the content of your attempted edit here, as it is visible to others in the [[Special:AbuseLog|edit filter log]]. If this edit was disallowed in error, please make a new section on the same page you were editing.</center>
| fplink   = no
}}

What do you think? – PharyngealImplosive7 (talk) 01:39, 6 February 2025 (UTC)

Here is how this template would actually look, so here is a sample edit with the proposed code above: Special:Diff/1274211623. – PharyngealImplosive7 (talk) 01:47, 6 February 2025 (UTC)

I modified the suggested message above, and I believe meddling might be less bitey than disrupting. I also changed other users' with false positive, added attempted before the word edit here, and removed on this page as it applies to the EFFPR page itself, not just other users' reports. Codename Noreste (talk) 02:12, 6 February 2025 (UTC)

The syntax/code seems fine. Not sure about the message, specifically the text. Personally I'd use:

| text     = <center>An automated filter has identified this edit as potentially unconstructive. If you are attempting to change the page's headers, please gather consensus beforehand on [[WP:EFN|the edit filter noticeboard]]. There should generally be no reason to edit another user's false positive report. Also, please note that you do not need to paste the content of your attempted edit here, as it is visible to others in the [[Special:AbuseLog|edit filter log]]. If this edit was disallowed in error, please make a new section on the same page you were editing.</center>

EggRoll97 ^(talk) 06:05, 10 February 2025 (UTC)

The thing is, you removed the mention about that people should not meddle with or blank other users' reports on EFFPR, which is also disruptive (and should be disallowed). Codename Noreste (talk) 17:05, 10 February 2025 (UTC)

Should be fixed in the above. EggRoll97 ^(talk) 17:41, 10 February 2025 (UTC)

Looks good so far. Codename Noreste (talk) 19:25, 10 February 2025 (UTC)

Yeah, these changes to the message also seem fine in my opinion. If you guys are fine with it, I could put in an edit request to the MediaWiki file after you modify the filter. – PharyngealImplosive7 (talk) 23:13, 10 February 2025 (UTC)

Y Done and MediaWiki message change has an edit request filed here. EggRoll97 ^(talk) 04:58, 11 February 2025 (UTC)

Improving Filter 894

I looked at Filter 188 on the Japanese Wikipedia and noticed that users who cite FC2 blogs will trigger that filter. If we generally do not cite blogs, I suggest we add FC2 to Filter 894 (hist · log) on the English Wikipedia. Z. Patterson (talk) 05:49, 16 February 2025 (UTC)

Do you have any diffs of people adding unreliable blogs to enwiki. I'm asking because it's easier to make regex with sample edits we know should be disallowed. – PharyngealImplosive7 (talk) 15:19, 16 February 2025 (UTC)

@PharyngealImplosive7: I have a list of search results that mention "blog.fc2.com" here. Z. Patterson (talk) 16:37, 16 February 2025 (UTC)

Regex to add to the filter (specifically to the selfpuburl variable): blog\.fc2\.com. – PharyngealImplosive7 (talk) 20:58, 16 February 2025 (UTC)

@PharyngealImplosive7: That could work. Alternatively, we could write blog[0-9]*\.fc2\.com in the selfpuburl variable. Z. Patterson (talk) 22:18, 16 February 2025 (UTC)

Purpose of Filter 1093

What is the purpose of Filter 1093 (hist · log)? The filter aims to address new users writing JavaScript in their userspace. Apparently, new users have a duty to not write their own JavaScript code? I wonder if this filter exists because of the possibility of a new user trying to write malware or write vandalbots. However, if a new user is knowledgeable about programming and wishes to contribute constructively, that would be different. Z. Patterson (talk) 01:05, 14 February 2025 (UTC)

I believe the filter was created for catching socks, given that both AmandaNP and GeneralNotability were active at SPI during that time. Nobody (talk) 06:35, 14 February 2025 (UTC)

Because of page_title irlike ".*\.js", it would also trip on JSON pages (and the filter's title obviously says javascript, so it must be limited to .js pages). Therefore, I might have suggestions to improve the filter.

• Limit to userspace only, e.g. page_namespace == 2.
• Should we limit to non-autoconfirmed users only, or log users with less than 50 edits?
• The page title check should be page_prefixedtitle rlike "^User:.*\.js$".

Thoughts? Codename Noreste (talk) 15:26, 14 February 2025 (UTC)

Reasonable suggestions, but I'm not convinced this filter is currently serving any useful purpose. I'd agree the filter was probably written to catch socks, but it's not a very reliable tell, and with Amanda and GN both relatively inactive, and the information obvious from contribs, I doubt anyone's really watching it. -- zzuuzz ^(talk) 15:47, 14 February 2025 (UTC)

+1 charlotte ^👸♥ 19:07, 14 February 2025 (UTC)

I think unless anyone has any objections, it may be best to just disable the filter. It's probably not doing much, but I don't see much point in keeping a filter without much purpose around anymore. EggRoll97 ^(talk) 05:17, 21 February 2025 (UTC)

@EggRoll97: I agree that we should disable this filter, as that does not serve much purpose in enforcing policies and guidelines and does not have a solid reason behind enforcement. If an edit filter is designed to enforce a duty, and duties have to have reasons, it would make sense to keep a filter enabled. However, because there seems to be little reason for the existence of this filter besides to catch sockpuppets, sockpuppeteers are strategic in their actions, and nowhere in WP:SIGNS do I see anything about sockpuppeteers writing user scripts, I think this filter would discourage new users from creating user scripts to edit more efficiently and more accurately, and it would discourage them from learning computer programming, let alone JavaScript, within Wikipedia. Also, sockpuppeteers typically choose more underhanded ways to achieve their goals. Therefore, I agree we should disable Filter 1093 (hist · log). Z. Patterson (talk) 16:39, 22 February 2025 (UTC)

I'm all for disabling a filter not doing much, but I'm not sure how it discourages anything at the moment, given that the filter takes no actions other than logging. Most users would have no idea it has even flagged their edits. FozzieHey (talk) 17:41, 22 February 2025 (UTC)

If nothing else, it shaves some hits away from the filter log, and saves a condition on the condition limit. It's fine to have a filter that doesn't do much (the impact is negligible, it's 1.6 conditions out of the 2,000 limit), but we probably shouldn't keep useless filters around. EggRoll97 ^(talk) 19:12, 22 February 2025 (UTC)

I'm OK with turning the filter off. Codename Noreste (talk) 20:22, 22 February 2025 (UTC)

Seeing as no one has objected to disabling, Amanda hasn't responded to a ping, and GN is sadly inactive, I've gone and disabled. charlotte ^👸♥ 20:41, 22 February 2025 (UTC)

Concern about Filter 614

I've noticed filter 614 (which disallows disruptive edits related to Internet slang etc.) doesn't seem to be working at all since it was last modified. This once-active filter's log completely dried up after this modification, and vandalism I would expect it to block has started going live. (For example, this rubbish should have been stopped by the filter for containing the word 'gyatt'.) Could the issue please be investigated? Entranced98 (talk) 01:15, 15 February 2025 (UTC)

Entranced98, the problem was that (?!\skong) was left behind after EggRoll97 removed the Diddy meme regex from the filter, but they forgot to remove that negative lookahead. Because of this, the filter is stealth disabled, meaning that it doesn't disallow meme/slang vandalism on articles. Codename Noreste (talk) 03:53, 15 February 2025 (UTC)

I'm fixing it. I'm cleaning up the filter so it'll take me more than a moment. Daniel Quinlan (talk) 05:37, 15 February 2025 (UTC)

Thanks for that. Looks far better with it separated by line in the string. EggRoll97 ^(talk) 15:43, 15 February 2025 (UTC)

@Entranced98: It should be working again. Thanks for the report. Daniel Quinlan (talk) 06:29, 15 February 2025 (UTC)

Thanks for sorting it out, much appreciated! Entranced98 (talk) 07:15, 15 February 2025 (UTC)

The new split-up pattern looks much better, I appreciate it. Codename Noreste (talk) 14:01, 15 February 2025 (UTC)

Would it be possible to add the term "goofy ahh brainrot" as well to prevent edits like these: [3]? Ca ^{talk to me!} 22:58, 17 February 2025 (UTC)

Filter 614 only triggers for users who are not autoconfirmed. – 2804:F1...D4:2EE1 (::/32) (talk) 01:43, 18 February 2025 (UTC)

@Ca: An expression for "brain rot" looks like a solid addition so it's been added. I am also testing out matching on more users with a low edit count (e.g., under 50 edits), but we want to be careful about keeping the false positive rate low. Daniel Quinlan (talk) 20:56, 23 February 2025 (UTC)

Set filter 1163 to warn and tag?

• 1163 (hist · log)

Looking at the filter's hits, they are mostly vandalism and other unconstructive edits, so we can use the default warning message for that. Any thoughts or suggestions? Codename Noreste (talk) 04:38, 18 February 2025 (UTC)

I agree, looking at the filter hits the majority of them are clear vandalism. There are a few edits that add quite a lot of text (where repeats are more likely to occur) and aren't clearly vandalism, but are probably unconstructive, for example Special:AbuseLog/40017576. If we want to be sure that this doesn't affect large constructive edits, could we perhaps add a condition to the filter to check that no (or very little) ref tags are added in the edit? I think that'd be a clear distinction between large unconstructive edits and large constructive edits and vandals are unlikely to add refs. FozzieHey (talk) 23:30, 18 February 2025 (UTC)

I hesitantly support warn and tag. I suppose I don't see anything wrong with doing so, but I'm also under the impression many of the problematic edits it catches would be caught by another filter. EggRoll97 ^(talk) 05:15, 21 February 2025 (UTC)

I've gone through a few of the filter logs, and while most users do trigger other filters, there are a few which only trigger this one. I'm sure the tag does help counter vandalism, and if we're not seeing much false positives then enabling warning is a benefit. Even if other filters match the same edits, those filters might not necessarily have tagging or warning enabled, so I don't really see much of a downside to turning it on here. FozzieHey (talk) 17:51, 22 February 2025 (UTC)

Also support warn and tag per everyone above. – PharyngealImplosive7 (talk) 04:40, 24 February 2025 (UTC)

Viewing filter logs by IP range

Is there a way to check filter logs by IP range? For example, when an IPv6 user reports a false positive like here and nothing shows up in the filter log, I assume that they've triggered the filter on a different IP within the same range. So I tried to look up the /48 for that announced prefix, but nothing showed up, and the "filter log" button doesn't appear on the IP range's contributions page. Other than checking the global filter log manually for the prefix (I couldn't find anything there either, so we might just have to skip this specific report), is there a way to do this? FozzieHey (talk) 18:13, 25 February 2025 (UTC)

There is T256823 for this (with a patch set attached, so we hopefully shouldn't have to wait too long!), just wondering if anyone has a workaround with a script or similar in the meantime as I imagine it's an issue others have come across. FozzieHey (talk) 18:30, 25 February 2025 (UTC)

Minor Change to 614

@Daniel Quinlan: You recently changed 614 (hist · log) so that it filters edits made by accounts with fewer than 50 edits or less than one week of age. I think it makes sense to also change the exception to the filter to reflect this change (though this is a minor, low-priority change):

−

/* exceptions for autoconfirmed users */ !("autoconfirmed" in user_groups & ( rcount("\{\{[Cc]ite\b", added_lines) > rcount("\{\{[Cc]ite\b", removed_lines) ) )

+

/* exceptions for users with fewer than 50 edits or less than one week of age */ !( (user_editcount < 50 | user_age < 604800) & ( rcount("\{\{[Cc]ite\b", added_lines) > rcount("\{\{[Cc]ite\b", removed_lines) ) )

– PharyngealImplosive7 (talk) 18:12, 24 February 2025 (UTC)

I also think that \broblox\b might be causing too many false positives, and we should remove some Hawk Tuah regex from private filter 1094, as it's already added to 614. Codename Noreste (talk) 18:38, 24 February 2025 (UTC)

I'll look at 1094. I'm monitoring "Roblox" hits with 614, but I think we'll need a bit more log data from after that was added before it's worth refining that part of the rule. Also, it would be appreciated if you could default to avoiding bringing up private filters in public, given the previous discussions about this. Daniel Quinlan (talk) 19:50, 24 February 2025 (UTC)

I haven't taken a deep look into 614, but most of the "roblox" related edits reported to EFFPR that I've seen are either vandalism, or unconstructive edits that I would have reverted myself (like adding non notable entries to lists). If it does turn out to be a problem, then I think it'd be worth splitting it out into a separate filter to take any false positive patterns into account, as I do find it useful for filtering out problematic edits. FozzieHey (talk) 17:56, 25 February 2025 (UTC)

I have noticed slightly more FP reports relating to this sort of vandalism, and some are good faith edits, by most are unsourced anyways, so I think that this should stay for now. I second the idea of creating a new filter to make the regex more sophisticated though. – PharyngealImplosive7 (talk) 21:57, 25 February 2025 (UTC)

Every edit that reaches that point of the logic meets the (user_editcount < 50 | user_age < 604800) condition. This means that condition will always be true so it doesn't make sense to repeat it.

Regardless, I looked at a version of the exception without the autoconfirmed requirement, but it would cause a loss of some true positives. There are some vandals that will add an (often silly or irrelevant) citation to their edit, but they tend to be non-autoconfirmed users. I added the exception because historical data showed it would address a small number of false positives due to the broadened scope of the filter.

Anyhow, if we see a false positive that would have been avoided with a slightly broader exception for citation additions such as (user_editcount >= 25 & user_age >= 432000), we can consider updating it. Daniel Quinlan (talk) 18:45, 24 February 2025 (UTC)

Ok, sounds good to me. – PharyngealImplosive7 (talk) 16:47, 25 February 2025 (UTC)

Filter 54 edit request

Per WP:EF/TP, !('override-antispoof' in user_rights) in 54 (hist · log) should be replaced with !(contains_any(user_groups, "sysop", "bureaucrat", "accountcreator")). JJP_Master (she/they) 04:50, 26 February 2025 (UTC)

Noting here that there was a previous discussion that the 'user_rights' variable was and is currently not available at the moment. Codename Noreste (talk) 05:02, 26 February 2025 (UTC)

I thought that discussion concluded that we did still have access to user_rights, but as it's lazy loaded, you wouldn't see it unless that filter actually used the variable? FozzieHey (talk) 09:49, 26 February 2025 (UTC)

Special:AbuseFilter/1345

Noting that if continued testing of this filter over the next hour or so continues to produce no false positives, I plan to set this filter to Disallow. Sam Walton (talk) 09:25, 27 February 2025 (UTC)

They've evolved. ScottishFinnishRadish (talk) 18:06, 27 February 2025 (UTC)

At this point, we should stop and then continue on the edit filter mailing list. Codename Noreste (talk) 14:17, 28 February 2025 (UTC)

Since I made this filter, I guess now is an appropriate time to ask this question – how do I get on the mailing list? charlotte ^👸♥ 00:35, 1 March 2025 (UTC)

WP:EFMAILING. Daniel Quinlan (talk) 11:50, 1 March 2025 (UTC)

EF1199

We are seeing a surge of rapid edit vandalism by IPs to articles. These are being logged by EF1199. Would it be possible for the EF to report IPs to AIV? — Malcolmxl5 (talk) 14:42, 1 March 2025 (UTC)

Good idea. It looks like CFA has already done this. Daniel Quinlan (talk) 18:23, 1 March 2025 (UTC)

Deprecate Wen Wei Po

Please add wenweipo.com to Special:AbuseFilter/869 per with clear consensus|this RfC. Thanks. Aaron Liu (talk) 23:07, 25 February 2025 (UTC)

Sample regex: wenweipo\.com. – PharyngealImplosive7 (talk) 00:05, 26 February 2025 (UTC)

 Done charlotte ^👸♥ 00:40, 1 March 2025 (UTC)

@Queen of Hearts: I think you accidentally added this before the ?, meaning that genealogy.eu no longer matches in the regex. It also seems like there's a stray ) earlier in the regex as well (after eadaily\.com) from when @EggRoll97 edited the filter last. I think the last section of the regex should be changed to:

|eadaily\.com|geni\.com|genealogy\.eu(?:web\.cz)?|wenweipo\.com) FozzieHey (talk) 12:00, 1 March 2025 (UTC)

Derp, fixed. charlotte ^👸♥ 18:21, 1 March 2025 (UTC)

Trying to maintain that long of an pattern on a single line is just asking for trouble. I did the standard clean up since it's reached that point. Daniel Quinlan (talk) 18:54, 1 March 2025 (UTC)

Suggested change to filter 1325

• 1325 (hist · log)

I re-worked the filter's logic and have made some fixes to the regex (as of my has resulted in some false positives because it was not surrounded with word boundaries). However, should we exclude every manually assigned user group except users who only have the extended confirmed user group? I am pinging Chaotic Enby here as they suggested the removal of the extended confirmed check, but here is the code below:

equals_to_any(page_namespace, 0, 118) &
!contains_any(user_groups, "sysop", "bot") &
(
    stringy := "(?:(?:stand|serve)s? as|is) a testament|in (?:conclusion|summary),?|underscor(?:es|ing) the importance|it is (?:important to note|worth noting)|rich (?:cultural heritage|history|tapestry)|\bas of my\b|as (?:an AI|a large) language model|I hope this helps|must-(?:visit|see)|stunning natural beauty|here(?:[’']s| is) (?:a|the) corrected version";
    
    added_lines irlike stringy &
    !(removed_lines irlike stringy) &
    !(summary irlike "^(?:restore|revert|rv|und(?:id|o))")
)

Thank you. Codename Noreste (talk) 15:21, 7 March 2025 (UTC)

Cc @Sohom Datta, who's been working on this lately. charlotte ^👸♥ 03:10, 8 March 2025 (UTC)

I've implemented most of the changes since they look good on a superficial reading. I'm going to hold off on adding additional caveats and exceptions for advanced user-rights (like excluding sysops or other groups) since this is log-only filter and I think casting a wider net is more beneficial in catching egregious AI usage. (Anecdotally, we have had auto-patrolled users use AI in their writing so "exclude every manually assigned user group" would require more justification). Sohom (talk) 03:30, 8 March 2025 (UTC)

Tagging of table parameters by n°1248

As already discussed in 2024, the edit filter should ignore changes in row and column spans as this pollutes the the log. However, the problem is not resolved yet. See here. 212.221.45.21 (talk) 10:39, 9 March 2025 (UTC)

Inactive EFM (user:Someguy1221)

Per Wikipedia:Bureaucrats' noticeboard#Inactive admins for March 2025, edit filter manager Someguy1221 has been desysopped for inactivity and it was suggested that their EFM right (self-granted in 2009) should be reviewed on the same grounds. WP:EFM implicitly defines inactivity as 12 months with no edits or logged actions, Someguy1221 has made three edits in the last 12 months (one each in September, October and November 2024) so they do not qualify for automatic removal. Their last edit regarding edit filters seems to have been December 2022 and their last logged action regarding edit filters seems to have been August 2019. Thryduulf (talk) 12:51, 1 March 2025 (UTC)

While the policy doesn't specifically address this situation, it's clear they are inactive with respect to edit filters. I have no objection to removing EFM. If they become active again, they can request reinstatement of EFM as allowed by the policy.

It might make sense to add or from any desysopped administrator who has not logged edits or actions regarding edit filters for a similar period or perhaps for two years to the policy if there is consensus to do so. Daniel Quinlan (talk) 18:21, 1 March 2025 (UTC)

I don't object to amending the policy, but I'm not sure it's needed for something that doesn't occur particularly frequently? Thryduulf (talk) 19:02, 1 March 2025 (UTC)

I'm fine with leaving it unchanged unless we see it happening often enough to justify a change. WP:IAR is more than enough to handle this case. Daniel Quinlan (talk) 19:11, 1 March 2025 (UTC)

IAR doesn't come into it. WP:EFM explicitly states that a discussion about revocation of the right can be held at this noticeboard if discussion doesn't resolve concerns. I skipped the discussion (given that they haven't edited at all in several months, including not responding to notices about the pending change to their admin status, I don't think that would be worthwhile) but aside from that this is following the rules not ignoring them. Thryduulf (talk) 19:56, 1 March 2025 (UTC)

If I'm looking at the same passage, that provision is for misuse rather than inactivity. Daniel Quinlan (talk) 19:59, 1 March 2025 (UTC)

I don't think this is a particularly rare case. The majority of EFMs are admins, and some of those will eventually become inactive. I've just been through the list of non-admin EFMs and found two other cases of users being desysoped due to inactivity, but keeping EFM - Jarry1250 and NaomiAmethyst (I haven't checked too deeply into their edit filter contributions, this is just an example). It would be good to take this into account at the time of desysopping, whether or not that needs an extra line added to WP:EFM or somewhere else I'm not too sure. FozzieHey (talk) 20:36, 1 March 2025 (UTC)

I was granted EFM prior to my sysop, and as such it should remain after the inactivity desysop. — Naomi Amethyst 06:25, 2 March 2025 (UTC)

Hi NaomiAmethyst. Looking at the edit filter history, you made one filter change in 2017 and the previous change before that one was in 2009. Could you clarify why you still need the EFM right? Thanks. Daniel Quinlan (talk) 06:40, 2 March 2025 (UTC)

As one of the authors of ClueBot NG, I find read access to the hidden edit filters to be useful -- though perhaps Editfilter Helper is a sufficient group for that. I do also occasionally find things that are more properly handled at the edit filter rather than in an antivandalism bot. — Naomi Amethyst 06:57, 2 March 2025 (UTC)

Makes sense, thanks. EFH should be sufficient if you're not modifying filters these days. I don't think anyone is planning on doing anything right now, but it sounds like we might be headed towards doing some maintenance on EFM user rights for inactive users. Daniel Quinlan (talk) 08:01, 2 March 2025 (UTC)

I'm pretty sure this can be revoked unilaterally – east718 had EFM removed after he was criteria 2 desysopped, even though he was not inactive for a full year – but yes, I support revocation. charlotte ^👸♥ 19:08, 1 March 2025 (UTC)

I support, though perhaps we should have it in policy that EFM be revoked from anyone who is desysopped automatically unless they gained EFM through a consensus discussion. Basically, if they self-granted as an admin, I feel it should be revoked if they are no longer an admin for reasons that are not their resignation. EggRoll97 ^(talk) 21:15, 1 March 2025 (UTC)

I agree with this - if an admin self-grants EFM, then losing admin should result in losing EFM, unless otherwise specified. Sam Walton (talk) 22:05, 1 March 2025 (UTC)

That seems like a reasonable policy adjustment. Adding something like and former administrators desysopped due to inactivity if they self-granted the user right to WP:EFM would be very simple to evaluate. I don't think there's any reason to make a change broader than that, though. Daniel Quinlan (talk) 22:44, 1 March 2025 (UTC)

I think what would be clearest would be splitting the "Criteria for revocation" section into something similar to the following:

• Misuse: If an edit filter manager is misusing the user right, the concern should first be raised with them directly. If discussion does not resolve the issue, a request for discussion or removal of the user right may be made at the edit filter noticeboard.

• Inactivity: Any administrator may revoke the right in either of the following circumstances:

  • The edit filter manager has made no edits or logged actions for 12 consecutive months
  • The edit filter manager is a former administrator desysopped due to inactivity and their EFM right was self-granted. This does not apply if they explicitly request to retain the right at the edit filter noticeboard.

Other circumstances: A request for discussion or removal of the user right may be made at the edit filter noticeboard if discussion with the edit filter manager has not or would not resolve the issue. The edit filter manager must be informed of the discussion on their talk page.

The first bullet is unchanged, other than the addition of the bullet and "Misuse:"; the first bullet of inactivity just makes it explicit what total inactivity means without changing the meaning at all. The second bullet of inactivity is based on this discussion, the final bullet just makes it clear what should happen in a situation that doesn't fit any of the bullets. Thryduulf (talk) 00:00, 2 March 2025 (UTC)

That is easier to read. I'd suggest changing the last bullet to:

• Noticeboard requests: A request for discussion about revoking the user right may be made at the edit filter noticeboard for conduct or edit filter misuse issues that cannot be handled through direct discussion. The edit filter manager must be informed of the discussion on their talk page.

That would allow the first bullet to be dropped and it covers general conduct issues that rise to the point where someone is concerned about a user's EFM rights. Daniel Quinlan (talk) 00:53, 2 March 2025 (UTC)

I like the idea of combining the first and third bullets, but I'd title it "other circumstances" rather than "noticeboard requests" ("other" being in contrast to inactivity) . It also shouldn't be limited to conduct or misuse (e.g. it could be someone who is minimally active but not contributing in relation to edit filters)

• Other circumstances: A request for discussion about revoking the user right may be made at the edit filter noticeboard for issues, e.g. relating to conduct or edit filter misuse, that cannot be handled through direct discussion. The edit filter manager must be informed of the discussion on their talk page.. Thryduulf (talk) 01:21, 2 March 2025 (UTC)

Makes sense. Slightly reworded for flow:

• Other circumstances: A request for discussion about revoking the user right may be made at the edit filter noticeboard for issues such as misconduct or edit filter misuse, but direct discussion should be tried first in most cases. The edit filter manager must be informed of the discussion on their talk page. Daniel Quinlan (talk) 03:45, 2 March 2025 (UTC)

That's generally good but I don't like "such as" because it could be read as limiting to issues similar to those listed (which effective but not total inactivity is not). I can't immediately think of anything better though. What first comes to mind is using "including" rather than "such as", but then I want to add commas which takes us back to the flow issues of my previous suggestion. Thryduulf (talk) 03:54, 2 March 2025 (UTC)

Perhaps we could add a bullet to inactivity if that's the main concern you have? It's better to use a crisp definition for inactivity.

• The edit filter manager has no activity related to edit filters for 24 consecutive months and is not an administrator or former administrator.

If someone has done nothing related to edit filters for that long of a period, EFH would be more appropriate if they have a valid reason for needing read access. I added "former administrator" due to administrators being resysopped often enough. Daniel Quinlan (talk) 04:30, 2 March 2025 (UTC)

I think you've misunderstood what I was trying to say - I was just using that situation as an example. My concern is that there will be situations where it is desirable to review someone's EFM right for reasons not specifically listed (and we should not attempt to list every conceivable reason) and the policy should be clear about what to do when such a situation arises. Basically I think there should be two bullets, the first about inactivity, the second for all other matters including but not limited to abuse and misuse. Thryduulf (talk) 04:50, 2 March 2025 (UTC)

Roger. I think "such as" isn't limiting if that helps. Daniel Quinlan (talk) 04:53, 2 March 2025 (UTC)

Is this really necessary? We have admins who haven't used their EFM bit in 15+ years, why start treating former admins different then current ones? Nobody (talk) 07:39, 3 March 2025 (UTC)

Current administrators can self-grant the right so there's no point in removing it. But removing it from administrators desysopped due to inactivity is good security practice. Daniel Quinlan (talk) 14:24, 3 March 2025 (UTC)

Don't get me wrong I think it's a great idea to deal with inactive EFMs, it just seems like barking up a small tree, when instead we could just say in general Any administrator may revoke the right if the edit filter manager has no activity related to edit filters for 5 consecutive years. That might affect more admins then you'd like, but thats what I'd consider good security practice. Nobody (talk) 14:39, 3 March 2025 (UTC)

Removing it from current administrators doesn't significantly improve security. It takes 10 seconds to self-grant the right. Daniel Quinlan (talk) 16:51, 3 March 2025 (UTC)

Asking the question is reasonable; we rarely grant EFM to non-admins (only 17 non-admins have it), so asking if the admin still requires the perm isn't necessarily a waste of time. Primefac (talk) 17:21, 3 March 2025 (UTC)

For quite a while I've held the belief that the EFM perm for admins should frankly be fairly easily removed, given they can just add it right on back if they still need it. I also would wager a guess that most of the 148 EFMs are probably not involved in edit filters, and assigned it to themselves for a one-off occasion. Hell, This, that and the other was assigned the EFM right without a consensus discussion to troubleshoot a bug (which has long since been resolved), and has been inactive in edit filters generally speaking since 2016. EggRoll97 ^(talk) 19:41, 4 March 2025 (UTC)

Perhaps we should state that the EFM permission will be removed from everybody who has not made at least one edit and/or logged action related to edit filters in the last 12 months. Admins whose permission is removed in this manner can re-grant it to themselves if they have a need. Non-admins can request it again here subject to the usual requirements. Thryduulf (talk) 19:59, 4 March 2025 (UTC)

I see no problems with this. WP:EFM already allows for re-granting the right upon the request of a former edit filter manager who has had the right removed on their own request or for inactivity and the right was removed under uncontroversial circumstances. Seems like it would be fairly trivial to grant back on request (it'd operate fairly similarly to resysopping), and we can clean out the EFM right from some who haven't used it in ages. If nothing else, the benefit here would be having said admin or non-admin EFM re-confirm that they still have a need for the right and that they still have a good enough working understanding of filters not to break things. EggRoll97 ^(talk) 21:11, 4 March 2025 (UTC)

I don't think the change is necessary or beneficial.

• Removing EFM from sysops wouldn't meaningfully improve security because they can self-grant the right in seconds.
• It would incentivize inactive administrators to make trivial edits to filters.
• Adding unnecessary friction and discussions for every future removal would be an inefficient use of time.
• Many other Wikipedias, including Spanish and German, grant the abusefilter-modify permission to sysops by default because it's a routine part of administrative work.

A more practical approach is to review EFM when an administrator is desysopped due to inactivity because there is actually a significant security benefit and it's less frequent. I have no objections to suggesting that administrators not using the EFM right consider self-revoking it, though. Daniel Quinlan (talk) 22:03, 4 March 2025 (UTC)

I don't see how it would incentivize trivial edits to filters. Administrators nearing the threshold for inactivity can easily just make any edit at all to any edit filter related page, for example, responding to a false positive report, or commenting on anything on this very noticeboard. Even if the right is removed, they can simply add it back, meaning it becomes a trivial matter to simply re-grant it to themselves. EggRoll97 ^(talk) 02:58, 5 March 2025 (UTC)

I agree with EggRoll that this wouldn't incentivise any edits to filters (trivial or otherwise).

I don't understand why you (@Daniel Quinlan) think it would add unnecessary friction or discussions? The only discussions it would generate would be from a non-admin who wants to return to edit filter work after more than a year of no involvement at all, which is never going to be a large number of people, and it's not going to add any friction as there is explicitly no controversy or prejudice in an inactivity removal. Admins in that situation can self-grant the right so there is no discussion needed. Discussion wouldn't be needed for inactivity removal either.

I don't know how edit filters work on other projects, but on en.wp modifying them is not a routine part of admin work for the vast, vast majority of admins. There are 846 admins but only 148 edit filter managers (not all of whom are admins, and not all of those who are admins are active).

The main benefit is not security, but of ensuring that those with access are actually engaged with edit filters. Thryduulf (talk) 22:29, 8 March 2025 (UTC)

That's not a benefit. That's a tautology. If some administrators have EFM revoked, fewer administrators will have EFM. As to no discussion needed, I never said a discussion would be necessary. I said that unnecessary discussions would be the likely result. Daniel Quinlan (talk) 02:15, 9 March 2025 (UTC)

Interface admins regularly have the bit revoked for even short bouts of inactivity related to interface work, and we still manage to have a fairly consistent number of IAdmins. I also wouldn't say it's necessarily that hard to get it granted back, either, so it's not as though having fewer of something is a bad thing. I suppose we'll need to disagree on whether more discussion is a bad thing, but I would say if someone is so utterly inactive with edit filters that the right is revoked under a fairly easy-to-meet bar (unless one completely abandons edit filter work entirely, or goes on a very long wikibreak, it's almost certainly impossible to not have any edit filter-related work for a full year), then needing to pop in quickly here at the noticeboard or go through the trivially-easy process of self-granting the right again is a pretty easy step to fulfill. EggRoll97 ^(talk) 02:41, 9 March 2025 (UTC)

Administrators can't self-grant interface administrator. Daniel Quinlan (talk) 03:23, 9 March 2025 (UTC)

Which means that there is even less likelihood that there will be too few EFMs. I don't understand why you say ensuring that EFMs are engaged with edit filters is not a benefit. I see no tautologies in my comment, where are you seeing one? What unnecessary discussions? Why are discussions a bad thing? Thryduulf (talk) 04:05, 9 March 2025 (UTC)

Returning to the original question...

There is a lot of good and useful discussion above about potentially changing the EFM inactivity/removal parameters, but the original question seems to have fallen by the wayside. Given their desysop for inactivity, low edit filter-related activity anyway, and what some would call a retirement message, is anyone strongly opposed to removing EFM from Someguy1221's account, with no prejudice towards re-granting if they ask for it in the future? Primefac (talk) 12:42, 9 March 2025 (UTC)

I believe that's an appropriate action in the circumstances. I assume you're volunteering and will leave a note? -- zzuuzz ^(talk) 12:53, 9 March 2025 (UTC)

I don't mind doing it if there's consensus (or at the very least a lack of opposition). Primefac (talk) 13:07, 9 March 2025 (UTC)

No objection from me. Thryduulf (talk) 13:36, 9 March 2025 (UTC)

No objection. Makes sense. Daniel Quinlan (talk) 17:09, 9 March 2025 (UTC)

No objections here, supporting. EggRoll97 ^(talk) 21:56, 9 March 2025 (UTC)

 Done, per no objections in eight days (even if most of those eight days were spent on a tangent). charlotte ^👸♥ 22:01, 9 March 2025 (UTC)

Edit filter false positive reports missing page, description, and comment

The intent of 1349 (hist · log) is to flag non-autoconfirmed users smashing buttons in response to the edit filter. It catches about 3 or 4 edits each day right now, but I think we could expand it somewhat to include some abusive reports. The vast majority of users with edits matching this filter do not follow up with a corrected report, or anything helpful, generally. It's only logging right now. I'd like to hear what people think about adding a CAPTCHA, a custom warning, or both a CAPTCHA and a custom warning. I'm leaning towards starting with just a CAPTCHA to see whether it helps reduce the number of these kinds of reports. Daniel Quinlan (talk) 00:18, 8 March 2025 (UTC)

Regarding include some abusive reports, I can send examples of them to the edit filter mailing list (for a new filter). And I don't object to using the CAPTCHA when the new filter picks up true positives for a few days. Codename Noreste (talk) 00:55, 8 March 2025 (UTC)

It catches about 3 or 4 edits each day right now, [...]

Do you mean in testing? Filter 1349 shows 0 hits so far. – 2804:F1...46:B7AB (::/32) (talk) 17:59, 8 March 2025 (UTC)

Well, with a hit rate that low, there will be days without any hits. In this case, I made a mistake. Fixing it now. Daniel Quinlan (talk) 18:54, 8 March 2025 (UTC)

Thank you for fixing that filter, and the first hit is at Special:AbuseLog/40197820. Codename Noreste (talk) 00:52, 9 March 2025 (UTC)

Re both a CAPTCHA and a custom warning, apparently, that's equivalent to disallow. I set 1147 (hist · log) to warn+showcaptcha, and I was just bounced back and forth between the edit filter warning and the captcha request, with no apparent way to save my edit. Suffusion of Yellow (talk) 01:55, 9 March 2025 (UTC)

Great catch. That sounds like an issue with the new feature (not that we couldn't find a use case for it). I believe only 1178 (hist · log) has had both of those options set at the same time in the past, but we'll need to be careful until it's fixed. Daniel Quinlan (talk) 02:40, 9 March 2025 (UTC)

I'm not sure I necessarily mind those reports. Some (not necessarily a significant amount, but some) are fine, and some aren't. The workload at false positives is still fairly low. That said, I think a CAPTCHA is fine, as it's fairly unintrusive, but anything past that I would likely oppose. EggRoll97 ^(talk) 05:05, 9 March 2025 (UTC)

I'm going to let the current filter run for a short while before adding a CAPTCHA, perhaps a week or so. I want to have enough data for a basic before vs. after analysis. Daniel Quinlan (talk) 06:56, 10 March 2025 (UTC)

WP:EFR Archive size

In 2023 EEng changed the size of the archiving from 100k to 900k, which I think is too much. Even the most active Noticeboard (ANI) only has a archive size of 800k. Archive size should be based on the amount of activity a page gets. Looking at other noticeboards FRN gets more traffic than EFR, but is set to 250k. There's also a possible issue with performance if the archive gets that big. Based on all this, I think the archive size should be less than 500k. Nobody (talk) 10:02, 10 March 2025 (UTC)

Let's see ...

• Archive size should be based on the amount of activity a page gets – Huh? What does that have to do with anything?
• There's also a possible issue with performance – , and see WP:PERFORMANCE.

The smaller the size limit for archive pages, the harder it becomes to find stuff, and in particular, to follow the story of an issue that's popped up repeatedly over time. At EFN that's particularly important. You're fussing about a non-problem, and trying to fix something that's not broken by making a useful thing less useful. EEng 15:31, 10 March 2025 (UTC)

I'm not in favor of smaller archives. WP:RFPP has even larger archives and that's generally made them more helpful, not less helpful. Daniel Quinlan (talk) 18:01, 10 March 2025 (UTC)

I don't think that comparison is fair. RFPP has monthly archives that have the ~400 requests it gets. EFR Archive 21 is currently 54% filled and goes back 2 years with 124 requests.
Anyone who knows how to correctly use the advanced search options at Special:Search will have no difficulty to search the archives, no difference if 20 or 40 archives are there. Nobody (talk) 06:20, 11 March 2025 (UTC)

Considering the extent of Archive 21, I would be okay with a decrease. If we stick with size-based archiving, I would prefer to stay at 400k or 450k. I'm also fine with switching to year-based archives which would result in smaller sizes. That actually seems like a better approach for slower-paced noticeboards. Daniel Quinlan (talk) 01:30, 12 March 2025 (UTC)

I agree that yearly archives would be better. Nobody (talk) 14:57, 14 March 2025 (UTC)

I think it's generally sort of fine as is. Archives 11, 12, and 13 have around 60 or so threads, and seem to load fairly well. I wouldn't say it's really become a problem necessarily. EggRoll97 ^(talk) 00:32, 11 March 2025 (UTC)

Those archives predate the change Nobody is talking about. Only archive 21 is affected, currently.

Probably 100k is too small, and 900k too high. Accumulating something like an archive a year or two seems like the right kind of pace to me. Currently it's an archive page every four years. ProcrastinatingReader (talk) 17:51, 11 March 2025 (UTC)

Ah, I see. I absolutely must have blanked and thought this was about WP:EFN, not WP:EFR. I've looked at the right archive now, and yikes. Archive 21 isn't even at 500,000 and it has 124 threads, and caused a noticeably higher load time to get into the archive page. I'd be supportive of 250k as proposed, though I have no objections to anything lower than about 350k. EggRoll97 ^(talk) 23:08, 11 March 2025 (UTC)