MyWiki:Edit filter noticeboard/Archive 16

Archive 10

←

Archive 14

Archive 15

Archive 16

Setting 1381 to warn or disallow?

After being created on request on 24 August and having since recorded 5 hits and no false positives, I think we should set this filter to either warn or disallow. I'm not particularly versed on either, I thought it would be better to get a consensus on what option we should take. Aydoh8^{[what have I done now?]} 15:31, 15 September 2025 (UTC)

5 hits is not a particularly large amount of hits. I would prefer waiting for more hits rather than setting the filter to disallow now. – PharyngealImplosive7 (talk) 16:31, 15 September 2025 (UTC)

Interestingly Draft:Agrajeet Chowdhury doesn't seem to have any filter hits by this filter (when it was not deleted), seems like a false negative. Tenshi! (Talk page) 16:57, 15 September 2025 (UTC)

Interesting. I'm not a sysop so I can't see the deleted contribs; if any sysop reading this would be able to temporarily undelete or copy the diff so we can troubleshoot, that would be appreciated. (Please ping) Aydoh8^{[what have I done now?]} 04:41, 16 September 2025 (UTC)

@Aydoh8: This would likely be at Special:AbuseLog/42122172. See the old_wikitext generated variable for the text of the article. It appears it didn't hit since the user in question manually submitted with {{subst:submit}}, thus bypassing the edit summary check (by simply not leaving one), and bypassing the added_lines check by using "submit" instead of anything matching the "submission" string. EggRoll97 ^(talk) 05:09, 18 September 2025 (UTC)

I’ll have a look when I’m back on my computer. Thanks for the message. Aydoh8^{[what have I done now?]} 05:11, 18 September 2025 (UTC)

Of course. I will admit, this seems a bit of a roundabout way to get deleted history, and it seems like it would be easier to just add deletedtext/deletedhistory to EFMs, though I don't see that gaining consensus. EggRoll97 ^(talk) 05:13, 18 September 2025 (UTC)

I’m quite sure WMF once said that users should go through RfA or RfA-equivalent process in order to see deleted contributions. A09|(talk) 14:24, 19 September 2025 (UTC)

@EggRoll97: I've had a look, would you (or any EFM reading) be able to change submission := "\{\{afc(?:\ssubmission)?\|\|\|" to submission := "\{\{afc(?:\ssubmission)?\|\|\||\{\{(subst:)?submit\}\}"? That should fix that false negative, matching both {{subst:submit}} and the non-substituted {{submit}}. Aydoh8^{[what have I done now?]} 09:18, 18 September 2025 (UTC)

I'm getting a syntax error from that when I try to test it in /test. I believe there's a bracket missing in there, but I'll check later. EggRoll97 ^(talk) 06:12, 19 September 2025 (UTC)

@EggRoll97: Perhaps its because you forgot the semicolon at the end? With the semicolon, the code does not seem to give any errors. – PharyngealImplosive7 (talk) 13:38, 19 September 2025 (UTC)

@PharyngealImplosive7: You are correct, silly me. I've edited the filter accordingly. EggRoll97 ^(talk) 03:47, 20 September 2025 (UTC)

Looks like the decision to include {{subst:submit}} in the filter was a good one, since it has picked up 3 more hits in the past week all using the manual subst. Aydoh8^{[what have I done now?]} 18:03, 28 September 2025 (UTC)

Question

Does anyone know why Special:Diff/1313911692 seems to have triggered Filter 631, "Extraneous Toolbar Markup"? This filter usually catches test edits in main space, and when I saw the hit I reverted initially as an editing test, but then I noticed that it was actually a substantial addition of content, causing me to revert my previous revert. Why did an edit that in actuality was anything but a test edit trigger a filter used for catching test edits? Taking Out The Trash (talk) 19:49, 28 September 2025 (UTC)

See Special:Diff/1313914099, which is what triggered the filter. -- zzuuzz ^(talk) 19:52, 28 September 2025 (UTC)

Taking Out The Trash, 631 (hist · log) catches exact toolbar markup in articles (using rlike), but only if there is an addition or removal of content. On the other hand, 1300 (hist · log) is similar, but warns non-autoconfirmed users who only add exact toolbar markup and nothing else. Based on this, it seems that filter 631 is working as intended. Codename Noreste (talk) 02:46, 29 September 2025 (UTC)

Possible LTA filter FP

See this log. They're not tripping any public filter simultaneously so I have no idea what's going on/if this is indeed an LTA account or if it's an FP that needs to be fixed and the user properly welcomed. Either way needs eyes on it. Taking Out The Trash (talk) 21:45, 2 October 2025 (UTC)

Seems like a fine filter hit to me. I don't really see the point in what appears to be a bunch of promotional biographies. EggRoll97 ^(talk) 00:18, 3 October 2025 (UTC)

I agree with ER97, these are true positives. Codename Noreste (talk) 01:38, 3 October 2025 (UTC)

Request for Edit filter helper flag

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

---

The earliest closure has started. (refresh)

• Little Sunshine (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 · taiv)}

Hey! Having read Wikipedia:Edit filter helper, I found myself in the same scenario as the one specified in the second bullet of the common use cases.

I'm an administrator in the Portuguese Wikipedia (verify) and have dealt with several sock puppetry/LTA cases, admittedly never with a SPI-specific flag. I've also been working on bettering the existing local abuse filters, having imported a filter from here.

However, I noticed this wiki has LTA-specific abuse filters, and found the mere existence of them immensely interesting, so I'd like to request the flag to study them and potentially add similar filters back home.

I would also be studying many other filters, since I've taken great interest in them, but my biggest curiosity fell upon the LTA filters.

I'm open to any questions that you may have and will absolutely understand if you see this request as not fit for the flag.

Cheers, Little Sunshine ✉ call me 19:08, 1 October 2025 (UTC)

You've stated an interest in LTA filters, which seems like a fair enough rationale. I note that you have edited a private filter only once total on ptwiki. Would you be able to expand on your experience with LTA work? EggRoll97 ^(talk) 02:28, 2 October 2025 (UTC)

Regarding the one private filter edit, I've done most work in the later filters I've created in july/august, and only then began to look into false positive cases; it's a fairly recent endeavour, though I've began reading up on them early in my adminship.

For my LTA work, I've been working antivandalism since early 2024. Since then, I've come across many different LTA and sockpuppetry cases. I've created some SPI cases (CTRL+F "Pedidos a verificadores") and have dealt with many other obvious sockpuppets that required no investigation (CTRL+F "{{Fantoche").

I've had a request for the CheckUser flag that failed due to it being too soon after being approved as a sysop (which indeed it was), and it's something I plan on circling back to some time soon.

Until then, I want to better ptwiki's ability to handle LTAs. All administrative work on SPs now is done only after the fact, which is why I took great interest in LTA filters. Little Sunshine ✉ call me 12:09, 2 October 2025 (UTC)

Little Sunshine, why not apply for the global abuse filter helper permission (on Meta-Wiki) instead of edit filter helper? GAFH will allow you to view all filters in all wikis (including the English Wikipedia and Meta-Wiki's global filters), and it can allow you to also review reports regarding global filters. Codename Noreste (talk) 14:55, 2 October 2025 (UTC)

Hey, @Codename Noreste!

I might just do that, then. I wasn't aware of the global flag; I stumbled upon English Wikipedia's while perusing through the docs here. Thank you for the recommendation! In that case, I presume the request here will be cancelled?

Cheers, Little Sunshine ✉ call me 19:48, 2 October 2025 (UTC)

It's your choice, but I would recommend applying for GAFH per my stated reasoning. Codename Noreste (talk) 20:12, 2 October 2025 (UTC)

Done! Application is published. Thank you! Little Sunshine ✉ call me 20:14, 2 October 2025 (UTC)

@Little Sunshine: Since enwiki EFH is redundant to GAFH and your GAFH application is now live, could your EFH nomination be considered withdrawn? – PharyngealImplosive7 (talk) 01:44, 3 October 2025 (UTC)

Hi, @PharyngealImplosive7! Yes, I withdraw my nomination, thank you kindly. Little Sunshine ✉ call me 01:51, 3 October 2025 (UTC)

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

Add the abusefilter-modify-restricted right to 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.

---

This right allows for editing filters with restricted actions. With the current wiki configuration, the only restricted action is blocking autoconfirmed granting, and revoking if one already is autoconfirmed. It is worth noting that all EFMs can already restore autoconfirmed if it is revoked by a filter. I don't see any reason in which a filter should be uneditable by non-admin EFMs, considering anyone with the right has gone through a discussion/request to attain it, (or gone through RfA to gauge general competence, and has assessed themselves as competent enough to edit filters), and has proven their technical competence in filter editing, and it seems a good idea to simply grant the right to the main EFM group. EggRoll97 ^(talk) 18:18, 21 September 2025 (UTC)

I thought existing policy was that we don't write any edit filters here that blocks autoconfirmed? In that case there's no point to add that right. dbeef [talk] 02:06, 22 September 2025 (UTC)

Activating filters with blockautopromote is now being discussed at WT:PP and in the section above this, and nothing is necessarily written into policy to prevent it, though I had thought the same thing on us not writing these filters. EggRoll97 ^(talk) 02:48, 22 September 2025 (UTC)

My impression is that it's not used because it's not terribly helpful on its own for various reasons. I'm proposing on WT:PP that we use that functionality to make it more difficult to game extendedconfirmed. Daniel Quinlan (talk) 05:42, 22 September 2025 (UTC)

In that case such that a potential proposal is being considered, Support this proposal.

EFMs are already highly trusted. they can easily craft a filter that prevents someone from editing. Potential for abuse is very low. dbeef [talk] 14:44, 22 September 2025 (UTC)

@Dbeef: I've posted a revised proposal at Wikipedia talk:Protection policy § Revised proposal to improve extended confirmed grants which should address this issue independently of the above proposal. Daniel Quinlan (talk) 20:52, 22 September 2025 (UTC)

Also support this. Non-admin EFMs are already high trusted and we already can disallow edits. I see no problem with us having the ability to block autopromotion. – PharyngealImplosive7 (talk) 03:16, 23 September 2025 (UTC)

• Noting that this has been implemented in phab:T405999 and is currently live. Personally, I'm a bit skeptical about the level of support demonstrated by this discussion and have raised objections on the phab task regarding the site-wide change without a formal RFC (since I do think we should do a formal RFC for any modifying userrights), but thoughts on that are invited on that both here and on the phab task. -- Sohom (talk) 04:51, 3 October 2025 (UTC)

  Looks like the phab task has been closed and abusefilter-modify-restricted added to EFM. I tested creating a filter that blocks autopromotion at 1385 and the action went through, so this task probably could be closed? – PharyngealImplosive7 (talk) 13:36, 3 October 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.

[URGENT] Temporary filter needed to stop a BLP mass attack

See the recent hits to filters Special:AbuseFilter/1212 and Special:AbuseFilter/117. There's some sort of mas attack going on targeting various BLPs with unsourced claims of death, all with the exact same edit summary "Heaven gained another angel". We're going to need a filter probably to block these edits on that identical summary, as all of the IPs are different from one another and thus range blocks aren't going to work, and I haven't figured out if there's even any common denominator as to which articles are being targeted. Taking Out The Trash (talk) 18:53, 3 October 2025 (UTC)

Blocking that stuff doesn't work because then you get "Heaven gaint an angel" and "𝐻𝑒𝒶𝓋𝑒𝓃 𝑔𝒶𝒾𝓃𝑒𝒹 𝒶𝓃 𝒶𝓃𝑔𝑒𝓁" and "Some completely unrelated edit summary". ScottishFinnishRadish (talk) 18:58, 3 October 2025 (UTC)

Yeah I would specifically request we don't block these, as that will just make future efforts in dealing with them more difficult. It's way easier to play whack-a-mole—if it's set to deny, we force them to change their behavior to something less predictable. Perryprog (talk) 19:00, 3 October 2025 (UTC)

But how are we actually going to stop them? There's thousands upon thousands of IP addresses - we can't play whack-a-mole ad infinitum for hours on end. Taking Out The Trash (talk) 19:03, 3 October 2025 (UTC)

We're stopping them right now. Their edits are being reverted in literal seconds, and IPs may be cheap but they aren't free. Not to mention if this isn't a fully automated attack (which it definitely isn't), there's a human on their end who will get tired of this. Perryprog (talk) 19:09, 3 October 2025 (UTC)

Some of that managed to stay for a few hours. Children Will Listen (🐄 talk, 🫘 contribs) 19:11, 3 October 2025 (UTC)

That is unfortunate, but it's still trivial to find those once this was noticed. We really don't want to make it more difficult to find future instances by forcing this person to "evolve" the complexity of their vandalism. A person like this isn't going to be discouraged by an AbuseFilter saying "no"; they'll figure out what specific thing they're doing that's being triggered and then stop doing it. Perryprog (talk) 19:14, 3 October 2025 (UTC)

Well, yes, they're clearly not a new user. I noticed some of these proxies were blocked when ST47ProxyBot was still active, wonder if we can bring that back again. This is some vandalbot using LLMs (e.g. [1]) to rewrite article content. Children Will Listen (🐄 talk, 🫘 contribs) 19:22, 3 October 2025 (UTC)

Ooo, good catch on the LLM usage! That does make things make a lot more sense now. I also didn't realize that ST47ProxyBot was retired, that is too bad; I get why, though. Perryprog (talk) 19:31, 3 October 2025 (UTC)

I'm working from quarry:query/97676, but they're hitting a few existing filters as well. These are proxies and should be blocked for a long time. Children Will Listen (🐄 talk, 🫘 contribs) 19:10, 3 October 2025 (UTC)

Discussion at Wikipedia:Administrators' noticeboard § Addition of abusefilter-modify-restricted right to EFMs

File:Symbol watching blue lashes high contrast.svg You are invited to join the discussion at Wikipedia:Administrators' noticeboard § Addition of abusefilter-modify-restricted right to EFMs. Daniel Quinlan (talk) 09:24, 4 October 2025 (UTC)

Exception for 1,060

• 1060 (hist · log)
• {{Db-c1}} (linked redirects: {{Db-catempty}} and {{Db-emptycat}})
• {{Db-empty}}

Should we perhaps set Special:AbuseFilter/1060 to allow the removal of WP:C1 tags? I've had to help some other users who properly followed the instructions given in the tag only to not be able to remove the tag. Those tags specifically inform users to populate the categories and remove and it doesn't look like an area that is or will ever be prone to abuse. I'm not super familiar with coding so apologies if this can't be done and I'm wasting time. Lynch44 01:35, 10 October 2025 (UTC)

I've added some links above. I'll note that Db-empty is also mentioned at WP:C1 as an alternative that becomes a C1 tag if placed in a category or a WP:A3 tag if placed elsewhere, though it seems the filter already allows the removal of Db-a1,a2,a3 tags so it should be safe to exclude too? – 2804:F1...5F:868A (::/32) (talk) 18:23, 11 October 2025 (UTC)

Discussion at Wikipedia:Village pump (proposals) § RfC: Should edit filter managers be allowed to use the "revoke autoconfirmed" action in edit filters?

File:Symbol watching blue lashes high contrast.svg You are invited to join the discussion at Wikipedia:Village pump (proposals) § RfC: Should edit filter managers be allowed to use the "revoke autoconfirmed" action in edit filters?. – PharyngealImplosive7 (talk) 23:29, 28 October 2025 (UTC)

It sounds like that RFC will probably be closed given the overlap with the one on WT:PP, but thanks for the heads up. Daniel Quinlan (talk) 01:54, 29 October 2025 (UTC)

Implementation of user_unnamed_ip to filters, and suggestions for filters using only user_editcount/user_age as pre-filters

Given that temporary accounts are coming on November 4, 2025, I would suggest implementing user_unnamed_ip to filters that use ip_in_range(s) in advance. In addition to that, I have some suggestions for filters that should target registered users:

• Filters that rely on user_editcount as a pre-filter should probably be changed to (user_type != "named" | user_editcount < [value]), given that for temporary accounts, checking for user_type will evaluate to true for unregistered users as opposed to user_editcount which will no longer work after temp. accounts' edits reach a certain number of edits.
• Similarly, filters that use user_age for registered accounts should probably be wrapped with (user_type == "named" & user_age </<=/>/>= [value]).

Codename Noreste (talk) 20:18, 30 September 2025 (UTC)

Oh, I hadn't noticed that there's a dedicated noticeboard for Edit filter here! Moving my comment from WP talk:Edit filter:

There are just over 20 of them needing an update/verification. In T369611, you will find an instruction and the lists of filters. Because some are/may be private, only users with NDA access on Phab and subscribers can view the lists. If you'd like to help me, let me know and I will add you to the subscriber list. Thanks! SGrabarczuk (WMF) (talk) 22:53, 10 October 2025 (UTC)

@SGrabarczuk (WMF): Could I get added to those two pastes on Phab? I've been meaning to ask for a while now, but it slipped my mind until I saw your post here. EggRoll97 ^(talk) 05:31, 13 October 2025 (UTC)

@EggRoll97, thanks for raising your hand. Done! SGrabarczuk (WMF) (talk) 11:06, 13 October 2025 (UTC)

Daniel Quinlan, EggRoll97 and PharyngealImplosive7, now would be a good time to implement those changes as we are nearing that time. Codename Noreste (discuss • contribs) 13:22, 1 November 2025 (UTC)

The user_unnamed_ip changes should be fairly straightforward, but we should be cautious about updating any filter that uses user_editcount or user_age beyond the zero cases mentioned in T369611. @SGrabarczuk (WMF): Please add DanielQ to the two pastes. Daniel Quinlan (talk) 17:21, 1 November 2025 (UTC)

For user_unnamed_ip, I've emailed you a list of filters requiring that simple change. Codename Noreste (discuss • contribs) 19:31, 1 November 2025 (UTC)

WP:RSN Grokipedia

I can see some sort of consensus emerging at Wikipedia:Reliable sources/Noticeboard#Grokipedia to filtering out grokipedia.com. I am not well versed of this, seems some thing technical like to me. may be some one from this board can join or take stalk of ongoing discussion at Wikipedia:Reliable sources/Noticeboard#Grokipedia and give inputs there if possible. Bookku (talk) 11:44, 29 October 2025 (UTC)

Filters 869 and 1132 both now include Grokipedia. Note that they are not disallow filters. Daniel Quinlan (talk) 03:18, 31 October 2025 (UTC)

@Daniel Quinlan, For sample I checked only few hits of 869 if any of those are cached 'Grokipedia', I did not any.

Rather than checking hits in 1132 I found searching talk name space with Wikipedia search itself easier.

a) is their any easier way to understand filters have cached which specific edits for Grokipedia. How many instances have happened so far of inserting grokipedia.com in the article namespace despite warnings?

b) Whether any specific users who keep tracking most of these edits and I can get some feed back from them for discussing the details at WP:RSN and may be other places. Thanks. Bookku (talk) 08:07, 3 November 2025 (UTC)

user_type condition changes to various filters

Per this filter search and because temporary accounts were deployed today, there are some remaining filters whose user_type conditions should be changed to the following:

• user_type == "ip" to user_type != "named", or a similar condition for the latter.

This does not apply to private filter 53 (hist · log), in which I've notified Oshwah (as the filter maintainer) off-wiki. Thank you. Codename Noreste (discuss • contribs) 16:30, 4 November 2025 (UTC)

Done (except for two disabled filters and one private filter that should work fine as it is). Daniel Quinlan (talk) 17:42, 4 November 2025 (UTC)

Well, there was an edit conflict (private filter) with PharyngealImplosive7. 🤷 Codename Noreste (discuss • contribs) 17:54, 4 November 2025 (UTC)

Yes, I saw that, but it wasn't a big deal. The comment needed to be updated, though. You'd think the system would warn you if you are saving starting from an older version than the current version when you hit the save button, but it does not. Daniel Quinlan (talk) 18:00, 4 November 2025 (UTC)

This is when User:Suffusion of Yellow/filterDiff would come in handy. Codename Noreste (discuss • contribs) 18:02, 4 November 2025 (UTC)

Yeah, I generally just diff locally for anything non-trivial. I learned about that script shortly after I had created the other FilterDiff (which I wish I had named differently). Daniel Quinlan (talk) 21:42, 4 November 2025 (UTC)

@Oshwah: Since it had stopped working for temporary accounts and is needed as a filter, I updated filter 53 as well (I've made some updates to it before so it was a straightforward change). Daniel Quinlan (talk) 17:49, 4 November 2025 (UTC)

Daniel Quinlan - Ah, thank you! I meant to make that change today (I updated filter #53 on October 10 to use user_type in addition to user_editcount, since user_editcount would return neither 0 or null for temporary accounts), and just logged on to do so. I appreciate you for having my back! :-D ~Oshwah~^{(talk) (contribs)} 00:03, 5 November 2025 (UTC)

Filter blocking FP reports

I noticed Special:AbuseLog/42658810 in the log today. Since I can't see the filter I don't know for sure what's going on, but we absolutely should not be disallowing edits to EFFPR except in extreme circumstances. This leaves no way for a genuine FP to be reported. Taking Out The Trash (talk) 18:36, 5 November 2025 (UTC)

This was definitely a false positive. Codename Noreste (discuss • contribs) 19:33, 5 November 2025 (UTC)

That filter is intended to block a particular LTA; it just needed a small adjustment. OhNoitsJamie ^Talk 19:36, 5 November 2025 (UTC)

I understand, but reiterating what I've said above, it was adjusted so that this specific false positive does not happen again… Codename Noreste (discuss • contribs) 19:50, 5 November 2025 (UTC)

Final updates to filters for temporary accounts

I'm done working my way through the filter list to update filters using user_name to user_unnamed_ip for IP address conditions. This is discussed further at mw:Trust and Safety Product/Temporary Accounts/For developers. These updates did have the side effect of permanently changing some filters to protected status, but in several cases where the IP address conditions were no longer needed, I was able to make alternative changes. I also sent out some emails to EFMs about several of the somewhat more complex filters (Ohnoitsjamie, Ingenuity, King of Hearts, and Zzuuzz).

A few additional things about non-hidden filters I noticed along the way:

• Could 958 be merged into 1025 so we have a single WP:SIP filter?
• Is 862 still needed? It's not hitting much these days.

Also, I think we should consider throwing in the towel and updating 1201 and 1301 (the random sample filters) to include the IP reputation variables from 1363 as well as user_unnamed_ip. That will unfortunately make them protected filters, but 1201 and 1301 really need user_unnamed_ip to be useful. @Suffusion of Yellow: What do you think?

Finally, please feel free to review my changes and reach out if you spot any issues (email is probably best since many are hidden filters). Daniel Quinlan (talk) 02:07, 4 November 2025 (UTC)

(I changed my decision regarding the two sensitive IP/Congress filters.) As for filter 862, I'm fine with disabling that filter. Codename Noreste (discuss • contribs) 02:10, 4 November 2025 (UTC)

I'm having second thoughts about merging those filters because it would make something like https://bsky.app/profile/congressedits.bsky.social impossible if we combined the two tags. I also should have pinged TheresNoTime and MusikAnimal about whether 862 (hist · log) is still needed so doing that here. Daniel Quinlan (talk) 06:24, 4 November 2025 (UTC)

In theory, hits from 1363 should have all the same variables as from 1201, plus the ip_reputation ones. So anyone with TAIV rights can just ignore 1201 and use 1363 instead. I wouldn't object to adding user_unnamed_ip to 1363, so long as we think that's in compliance with foundation:Policy:Wikimedia Access to Temporary Account IP Addresses Policy#Use of temporary account IP addresses. Suffusion of Yellow (talk) 21:35, 5 November 2025 (UTC)

It looks like the variables are all there, but 1363 matches are a subset of 1201 right now so it's not as useful for general testing. I'd be easier if 1201 and 1301 just logged everything. We already log protected data for 26 enabled filters, adding two more filters shouldn't be an issue. If it turns out there's a need for a completely unprotected/unhidden random sample filter, we can always add one later. Regarding the policy, it's up to users to follow the policy for any use of temporary account IP address data. Daniel Quinlan (talk) 01:16, 6 November 2025 (UTC)

Implementation of closed RfC on extended confirmed grants

I have closed WT:PP#Revised proposal to improve extended confirmed grants (initiated by Daniel Quinlan) as having a consensus. It will need implementation by edit filter people and changes to site settings requested on Phabricator. I'll leave that to y'all unless you would like anything else from me as the closer. ~ Jenson (SilverLocust 💬) 19:29, 30 October 2025 (UTC)

Thank you. I'll be filing a ticket for point 1 which seems like it will require some code changes and I'll send an update on filter changes to the edit filter mailing list. Daniel Quinlan (talk) 19:37, 30 October 2025 (UTC)

@Daniel Quinlan: Have you filed the phab ticket yet? If so, could you please link to it here? Thanks, – PharyngealImplosive7 (talk) 15:46, 6 November 2025 (UTC)

Adding the abusefilter-access-protected-vars right to the temporary-account-viewer group

Would adding the abusefilter-access-protected-vars right to the temporary-account-viewer (TAIV) group make sense? This would allow TAIV group members to view these filters and logs as long as they aren't hidden. Now that so many filters are using the user_unnamed_ip variable or the IP reputation variables, I'm concerned that we've restricted too many trusted anti-vandals from the information they need to be effective. I'm not sure whether the WMF will have concerns or additional requirements, but I wanted to start a discussion here before initiating a broader discussion anywhere. Daniel Quinlan (talk) 02:54, 4 November 2025 (UTC)

We've had a similar discussion before, at Wikipedia:Edit filter noticeboard/Archive 15#TAIV and EFM/EFH rights. Besides that, I have no objection. Codename Noreste (discuss • contribs) 03:01, 4 November 2025 (UTC)

Perhaps we could start an RfC to see what the broader community thinks and also see if the WMF objects if the proposal gains support. – PharyngealImplosive7 (talk) 03:32, 4 November 2025 (UTC)

That's basically the plan if there's general agreement here. RFCs are pretty heavyweight so it's usually best to not jump straight into one. Daniel Quinlan (talk) 06:19, 4 November 2025 (UTC)

It's also worth noting that global temporary account IP viewers already have the proposed user right, so it makes sense to add to the local TAIV user group. Codename Noreste (discuss • contribs) 19:56, 14 November 2025 (UTC)

I suppose I have no objections, though I wouldn't say there's necessarily a lot of filters that would be accessible. Out of the currently enabled filters, only 5 (which are all tag or log-only) would become accessible to TAIV's if this were to pass. All other protected filters are private, and thus no change would occur. Again, no objections here, just seems like there wouldn't be a terribly big impact. EggRoll97 ^(talk) 05:15, 5 November 2025 (UTC)

Set filter 833 to warn and tag?

File:Purple arrow down.svg Moved from Edit filter/Requested.

The main reason why I am creating this request is because I feel like the filter just logging the edit isn't enough, like the filter's purpose is to match "New user adding unreferenced or improperly referenced material". If that is so shouldn't 833 warn the user first and then tag the edit? I originally made this request as 98.235.155.81 but closed it afterward, after 5 days with no recent activity. While this doesn't have to be done, this is just a suggestion on what to add to this disruption catching filter. ~2025-33631-56 (talk) 14:49, 15 November 2025 (UTC)

I've moved this here since it's probably more appropriate to discuss before implementing. As for the proposal itself, I suppose I'm not against it, but maybe a tag is more appropriate? EggRoll97 ^(talk) 03:03, 27 November 2025 (UTC)

Tag for Special:AbuseFilter/1057

Right now, filter 1,057 uses the "deprecated source" tag. I feel it should be something else so it can be easier to identify when someone is citing Wikipedia. I'm thinking something like "citing Wikipedia" or "self-citation (of Wikipedia)". — MRD2014 (talk) 21:47, 30 November 2025 (UTC)

That makes sense to me. I think tagging as "citing Wikipedia" would be the simplest and most accurate way to convey it. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 18:33, 2 December 2025 (UTC)

The AIV disruption filter

... may need an update to include this kind of circumvention . ~ ToBeFree (talk) 22:02, 6 December 2025 (UTC)

Fixed. Daniel Quinlan (talk) 22:58, 9 December 2025 (UTC)

"user_name == page_first_contributor" in several Articles for creation-related filters

What is the purpose of user_name == page_first_contributor in filters 1370, 1378, 1379 and 1381? Despite most drafts usually being worked on by a single person, that person doesn't necessarily "own" said draft. Also since the introduction of temporary accounts, the TA used to create a page may not be the same as one used later, which may happen if it is lost (i.e. cookies/browser data cleared), expires, or if another device is used. I find from my own personal experience that this often results in false negatives on said filters. Also note that I wrote most of 1381, though I wasn't the one that added that line. Aydoh8^{[what have I done now?]} 17:11, 6 December 2025 (UTC)

I assume it was added to reduce false positives. Exclusions like this shouldn't be interpreted as a statement about policies or guidelines. They're often just a reflection of statistics. @PharyngealImplosive7: You may want to take a look at these filters in case further changes for TAs are warranted. Daniel Quinlan (talk) 02:15, 10 December 2025 (UTC)

I agree with Daniel Quinlan: removing that condition would simply be unfeasible and lead to too many false positives. Those filters again aren't representative of wikipedia policy and anyways only log the edit. – PharyngealImplosive7 (talk) 05:30, 10 December 2025 (UTC)