Wikipedia:Edit filter noticeboard

"WP:EFN" redirects here. For information on the {{efn}} template, see WP:EXPLNOTE.

Welcome to the edit filter noticeboard

WATCH Recent filter changes (): Filter 1326 (new) — Actions: none; Flags: enabled,private; Pattern modified Last changed at 00:13, 21 November 2024 (UTC) Filter 1178 — Actions: warn Last changed at 18:52, 20 November 2024 (UTC) Filter 225 — Pattern modified Last changed at 16:50, 20 November 2024 (UTC) Filter 1325 (new) — Actions: none; Flags: disabled,public; Pattern modified Last changed at 02:04, 20 November 2024 (UTC) Filter 1318 — Actions: tag,warn; Pattern modified Last changed at 08:37, 17 November 2024 (UTC) This is the edit filter noticeboard, for coordination and discussion of edit filter use and management. If you wish to request an edit filter, please post at Wikipedia:Edit filter/Requested. If you would like to report a false positive, please post at Wikipedia:Edit filter/False positives. Private filters should not be discussed in detail here; please email an edit filter manager if you have specific concerns or questions about the content of hidden filters. There are currently 328 enabled filters and 48 stale filters with no hits in the past 30 days. Filter condition use is ~1027, out of a maximum of 2000. (). See also the profiling data and edit filter graphs. Click here to start a new discussion thread

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.

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[1] (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

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.

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, [2]) 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.

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.

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)

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)

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)

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)