Wikipedia:Edit filter/Requested/Archive 21

Furry convention page vandalism

• Task: This filter would filter out attacks on pages related to furry conventions. A good start would be to add it to members of Category:Furry conventions. Specifically the string "furries are queers" or variations of it would be what is filtered out.
• Reason: There have been several attacks on pages in this category in recent days. I noticed it today and instead of protecting these pages, a filter would make it so valid edits from users without extended confirmed protection could edit the page. Of course the filter may need to be a little more robust than just this string. Looking at the history of some these pages, this seems to have been going on for quite some time.
• Diffs: [1] [2] [3]

Philipnelson99 (talk) 21:05, 8 March 2023 (UTC)

Support with the option to expand the filter as new phrases are discovered. Furry hate is not new to this encyclopedia, and more phrases may be discovered over time. Jalen Folf (talk) 21:32, 8 March 2023 (UTC)

Speaking of, new phrases used: "They're weird and creepy" and "I dont like these people", as of the latest edits on affected pages. Examples: [4] [5] [6] [7] [8] Jalen Folf (talk) 22:18, 8 March 2023 (UTC)

This is an LTA that has demonstrated some degree of dexterity in evading filters. I'm not saying it isn't worth trying out a new filter or modifying an existing one as it may temporarily slow them down and may keep their preferred abuse from going live, but our primary tool is likely to remain ECP. 74.73.224.126 (talk) 14:07, 9 March 2023 (UTC)

I oppose the creation of the filter. I don’t see any reason why we can’t just extended-confirm protect the page. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 13:56, 26 March 2023 (UTC)

The box at the top of the page says:

Filters are applied to all edits. Problematic changes that apply to a single page are likely not suitable for an edit filter. Page protection may be more appropriate in such cases. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 13:58, 26 March 2023 (UTC)

This should probably be a LTA filter. I disagree with Illusion Flame since this applies to a set of articles. 0xDeadbeef→∞ (talk to me) 03:08, 27 March 2023 (UTC)

The filter would only apply to about 7 pages. I truly don’t see why we just can’t protect them.

However, you guys are also more experienced around here.

If we are going to make an LTA filter, I recommend discussion occurs over email per:

If you wish to discuss creating an LTA filter, or changing an existing one, please instead email details to wikipedia-en-editfilterslists.wikimedia.org - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:30, 27 March 2023 (UTC)

Hmm if there are only about 7 pages then I think regular admin actions should be sufficient. I didn't see the actual number of pages listed at that category and I assumed there would be more articles that the current actual count, Sorry! 0xDeadbeef→∞ (talk to me) 09:41, 28 March 2023 (UTC)

Transclusions of articles in templates

 Courtesy link: Wikipedia:Administrators' noticeboard/Incidents § Vandalized Preview Pop Ups for American cuisine and a Large Number of Related_Articles

There's been a spate of vandalism where editors have been transcluding articles on unpleasant subjects into templates, see 86.180.182.153 (talk · contribs · 86.180.182.153 WHOIS) or Rustyrivet (talk · contribs). Would it be sensible to disallow transclusions of articles in templates for new editors? There seem to be very few legitimate uses of this feature [9]. 192.76.8.84 (talk) 18:51, 31 March 2023 (UTC)

Testing. Galobtter (pingó mió) 21:43, 31 March 2023 (UTC)

 Done Galobtter (pingó mió) 23:03, 31 March 2023 (UTC)

Removal of fringe-theory keywords

• Task: Flag revisions in articles with word changes matching at least one of the following regex, case-insensitive:
  • alternative medic([a-z]*) → medic$1
  • fringe (scien[a-z]*|theor[a-z]*) → $1
  • medical quack[a-z]* → anything matching medic[a-z]*
  • pseudo[- ]?arch(a?e[a-z]*) → arch$1
  • pseudo[- ]?hist([a-z]*) → hist$1
  • pseudo[- ]?math([a-z]*) → math$1
  • pseudo[- ]?scien([a-z]*) → scien$1
  • pseudo[- ]?scholar([a-z]*) → scholar$1
  • quack[a-z]* → anything matching medic[a-z]*
  • A word matching any of the above regex, except quack[a-z]* not preceded by medical, is deleted entirely.
• Reason: Edits of this type are often promoting a fringe POV, which is common in articles about fringe theories. Makes it easier to catch and revert these edits on sight. See also Wikipedia:Fringe_theories/Noticeboard#Would_it_be_worthwhile/possible_to_get_a_filter_showing_removals_of_"pseudo".
• Diffs: changing pseudoarcheology to archeology; deleting pseudoscientific and pseudohistoric; deleting pseudoscientific, along with many other examples at the same article.

–LaundryPizza03 (dc̄) 19:51, 25 March 2023 (UTC)

I think this edit filter request is good and can be approved.

@LaundryPizza03: Would you want this filter to tag the edit or warn and tag the edit? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:41, 30 March 2023 (UTC)

Definitely tag the edits to allow the FTN editors to track them more closely. I will need to ask about warning users, however. –LaundryPizza03 (dc̄) 01:48, 31 March 2023 (UTC)

They are not opposed to issuing a warning to editors who trigger the filter. –LaundryPizza03 (dc̄) 09:17, 31 March 2023 (UTC)

Okay! Only edit filter managers are allowed to create edit filters, so I will ping some active ones to this discussion. @Galobtter: @Suffusion of Yellow: @TheresNoTime: - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:52, 31 March 2023 (UTC)

This should be tag only as, whilst I think the filter is a good idea, you are going to get an absolute s**tload of false positives. Black Kite (talk) 11:13, 31 March 2023 (UTC)

Warning users for their edits doesn’t disallow them. It merely warns them and asks if they want to continue with their edit. If they press publish changes, it will go through. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:09, 31 March 2023 (UTC)

We'll have to see how well the filter actually works, if it's possible to build a decent one; but for possibly good-faith edits, I'd like to see a proper consensus for warning, even if it allows edits to go through. Galobtter (pingó mió) 21:47, 31 March 2023 (UTC)

In theory, this means that if for example a vandal adds to Barack Obama the text "Obama is a pseudoarchaeologist", then the editor who goes to remove that will see a warning, but I suppose that sort of thing is an unlikely scenario. BD2412 T 22:19, 31 March 2023 (UTC)

We could only have it apply the warning to new or unregistered users. That might help fix the problem. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 13:17, 1 April 2023 (UTC)

Telephone numbers added to articles

• Task: To prevent the addition of personal telephone numbers (either of the editor adding them, or of their friends/enemies) to articles
• Reason: I've been going through all our Telephone numbers in [Countryname] articles and related subjects per this AN discussion, finding telephone numbers that have been added in the past 50 edits in the last 2 years and having them Oversighted. This is now more or less done, but as I've been removing them I've been watchlisting the articles and am therefore seeing new ones being added live. HJ Mitchell suggested an edit filter might work to block these in the first place, saving Oversighters a lot of work.

I've not worked with regex for some years, so I'm very rusty. The filter would be something like:

^[\+]?[(]?[0-9]{2,4}[)?[-\s\.]?[0-9]{3,4}[-\s\.]?[0-9]{4,6}$

but not where the digits are consecutive (123456789, 2345678, 0123456 etc) and not when the digits are repeating 5 or more times (0800 1111111, 1-333-333-3333 etc) as these are both valid "example of number formatting" edits. That's where I get stuck!

• Diffs: Recent diffs in question have been revdelled, but older ones include [10] [11] [12] and this edit summary — Trey Maturin™ 17:53, 18 December 2022 (UTC)

  I regularly undo the addition of strings which are probably phone numbers in some country or other, and also see them in edit summaries where they're harder to remove. Some are obviously commercial (contact 012345789 to order), others more cryptic (probably the author's own number). Blocking this for everyone would produce lots of false positives, but it might be reasonable to stop IPs from adding (\d[- \d]{7,12}\d), where the capture contains either 5+ consecutive digits or 9+ total digits. That would allow ISO dates (2022-12-18) and year ranges (1998 - 2001) even if poorly punctuated. Multi-digit amounts, such as large sums of money, generally contain comma or dot. Certes (talk) 21:20, 18 December 2022 (UTC)

Bumping thread for 14 days. 137a (talk) 13:12, 9 January 2023 (UTC) 137a (talk) 13:12, 9 January 2023 (UTC)

A minor issue would be that the filter log entries would still need to be oversighted anyway, which would then push the task of finding and reporting such log entires solely onto EFHs, EFMs and sysops. Unless just keeping the filter private would be enough? Mako001 (C)  (T)  🇺🇦 04:40, 8 February 2023 (UTC)

I’d see the filter as preventing the edit happening at all (once the testing and refinement period is over). I’m not sure what kind of information the system logs: if it logs the text of the edit, then yes, the log would need to be trusted-users only (sysops as a minimum, oversighters-only as an ideal). This may need discussion with (or by) those very trusted users — that’s above my pay grade! — Trey Maturin™ 09:26, 8 February 2023 (UTC)

Filters log basically anything you can see from a diff, even when set to disallow. If made private, they still show it to several thousand more users besides oversighters (namely, EFHs, EFMs, sysops). So, yes, the logs would contain oversightable material, and it would still (at least technically) need oversight requested anyway. Mako001 (C)  (T)  🇺🇦 13:43, 8 February 2023 (UTC)

It would be up to oversighters to say if this was more or less convenient than having me emailing them manually for the 250 most-telephone-number-attracting articles on my watchlist, but it doesn't sound like it, does it? Bum. — Trey Maturin™ 13:47, 8 February 2023 (UTC)

Well, in one rather extreme case of something later oversighted which was known to a lot of users, User:CheeseDreams password was avaliable on User talk:Rienzo up until March last year. OK, someone had logged in and changed it since, but... it had been up there for over eighteen years after they posted it there.

Regarding your question, probably not, since someone would still have to request oversight, but unless you become an EFH, you wouldn't be able to. So, it would still be just as much work, only it would fall on editors who may be more busy with other stuff, like keeping edit filters running smoothly, and general admin stuff. Setting it to warn would probably be a problem too, since the effect would be much the same, with "successful" warnings (where they didn't make the edit) still leaving a oversightable log entry behind (as much as disallow), and "unsuccessful" warnings (where they did make the edit) leaving two log entries and an edit to be oversighted. Mako001 (C)  (T)  🇺🇦 13:58, 8 February 2023 (UTC)

It might be feasible to make a bot that oversights everything the filter catches automatically (or, when I think about it, skip the middleman and just use a bot). Snowmanonahoe (talk) 12:59, 7 March 2023 (UTC)

We've had Special:AbuseFilter/247 which blocks addition of emails for quite a while. Surprised the equivalent for phone numbers doesn't already exist. I think having a private filter would reduce visibility quite a lot in practice by not allowing phone numbers into articles, since no one really looks at log entries and they are functionally automatically revdelled (EFHs and non-admin EFMs are trusted and they are the only non-admins who can see). So I think I'll see if I can test something decent. Also per Special:PermaLink/1093966130#EF_247 having a filter to stop oversightable stuff does seem to help oversighters. Galobtter (pingó mió) 03:43, 25 March 2023 (UTC)

If this filter is created it needs to apply to Talk pages. I've seen far more personal phone numbers added to them than to articles. - X201 (talk) 10:44, 27 March 2023 (UTC)

It would be extremely useful for dealing with the Nigerian phone scam, although that has not been active recently, and the Kenyan phone scam although that produced several ways to get round the filter. - Arjayay (talk) 10:59, 27 March 2023 (UTC)

Testing what Certes suggested basically at Special:AbuseFilter/1244. I think references will often cause false positives so we'll have to see what can be done about that. Galobtter (pingó mió) 09:09, 31 March 2023 (UTC)

Ah yes, you might have to allow some 10- and 13-digit numbers, perhaps only with a certain check digit or when accompanied by a certain keyword. Certes (talk) 09:26, 31 March 2023 (UTC)

I filtered down to small edits that don't add urls. Hopefully that works well - based on the diffs given, the phone number additions are generally pretty small edits. Galobtter (pingó mió) 09:29, 31 March 2023 (UTC)

I started a discussion at Wikipedia_talk:Oversight#Edit_filter_to_block_additions_of_phone_numbers about the filter. Galobtter (pingó mió) 21:04, 5 April 2023 (UTC)

Talk page junk

Is there anything we can or should do to deter brief talk page additions such as this? They're quite frequent and, whilst rarely a serious problem, clog up the page and waste editors' time finding and reverting them. Many consist (in heading or content or both) of a phone number, e-mail, social media account or similar spam, which are addressed elsewhere, but there's still plenty of plain nonsense. Such contributions may or may not be signed. Certes (talk) 12:35, 30 March 2023 (UTC)

I feel that the scope of this proposed filter is quite unclear. The diff you linked is just a 1 character test addition to a user talk page, but in your request you want a filter for emails, phone numbers, etc. We currently have a filter to detect emails, and we are working on one for phone numbers. (See above) If you would like a filter, I suggest you be much more specific on what strings you want to prevent and the actions you want the filter to take. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:38, 30 March 2023 (UTC)

Yes, it's an idea rather than a specification at this stage. If there's a more appropriate forum for that, or it's simply unwelcome, that's fine. Certes (talk) 21:37, 30 March 2023 (UTC)

You want WP:VPIL, most likely. –LaundryPizza03 (dc̄) 09:38, 31 March 2023 (UTC)

I think it's fine to make general suggestions here for discussion but it's not really possible to make a useful filter without a specific pattern of edits to be blocked and multiple diffs showing how to design a filter to block those specific diffs. Galobtter (pingó mió) 11:54, 31 March 2023 (UTC)

Something like the following may be possible:

!("confirmed" in user_groups)
& (page_namespace == 1 | page_namespace == 3)
& added_lines rlike "^\s*=+\s*\S{0,2}\s*=+\s*\S{0,2}\s*(?:\[.*\(UTC\))?\s*$"
& length(removed_lines) == 0

0xDeadbeef→∞ (talk to me) 07:02, 2 April 2023 (UTC)

Thank you; that looks like a good pattern to at least try. I'd raise the maximum word length from 2, but I'm not sure how far it can go without false positives. Beware of catching something like ==XY== A link near the start of a useful comment. [signature], which I think matches the expression above. Certes (talk) 11:16, 2 April 2023 (UTC)

@0xDeadbeef Now running something similar at Special:AbuseFilter/1245. Seems to be pretty good at catching junk as per testing vs Special:AbuseFilter/1014 helpfully being run by Suffusion of Yellow :) Galobtter (pingó mió) 04:38, 4 April 2023 (UTC)

Judging by edits like [13], I don't think the word count can be expanded any further beyond 2. Galobtter (pingó mió) 04:40, 4 April 2023 (UTC)

Nice! Thanks for revising and creating the test filter. 0xDeadbeef→∞ (talk to me) 05:02, 4 April 2023 (UTC)

Thank you! That seems to be catching one every few minutes, ranging from content-free to generic insult to slightly disturbing with no obvious false positives. Certes (talk) 13:06, 4 April 2023 (UTC)

See Wikipedia:Edit filter noticeboard#Setting 1245 to disallow?. Galobtter (pingó mió) 19:47, 5 April 2023 (UTC)

 Done the filter has been set to disallow. Galobtter (pingó mió) 04:19, 6 April 2023 (UTC)

Interstate 20 spam link

• Task: Prevent insertion of i20accidents.com/i20-accidents into the Interstate 20 article
• Reason: Several IPs from the same general range of addresses in Bangladesh keep adding a link to a website ostensibly run by a law firm seeking clients related to vehicle accidents on I-20. Once the link was added to the external links section, but typically it is inserted as a reference even though it is clearly not an RS nor does it reference the content of the article.
• Diffs:
  • [[Special:Diff/1142971753 March 5, 2023], 37.111.245.208
  • [[Special:Diff/1140262032 February 19, 2023], 37.111.244.118
  • February 19, 2023, 37.111.246.48
  • February 19, 2013, 37.111.246.48
  • February 17, 2023, 37.111.245.233
  • February 17, 2023, 37.111.243.86

Imzadi 1979 → 19:08, 5 March 2023 (UTC)

@Imzadi1979: Is the spam blacklist talk not a superior venue for this report? – dudhhr ^talk _contribs (he/they) 16:11, 9 March 2023 (UTC)

Request moved there, thanks! Imzadi 1979 → 19:54, 9 March 2023 (UTC)

Prevent removal of talk page headers

• Task: Identify when an editor removes all items in a talk page header or removes a portion in a way that breaks a template
• Reason: It's not uncommon for inexperienced editors to remove a talk header while trying to use a talk page. Many of these edits go undetected for a long time.
• Diffs: Special:Diff/1105054073, Special:Diff/1136030142, Special:Diff/1084946475

Thebiguglyalien (talk) 00:34, 23 February 2023 (UTC)

Monitoring removal of all WikiProject banners at Special:AbuseFilter/953; let's see what's going on and what can be done. There might be some potential for a filter similar to Special:Abusefilter/957. I think really this is a mobile UX bug, where it is really easy to edit the first section of a page by hitting the edit button at the top. Galobtter (pingó mió) 03:24, 25 March 2023 (UTC)

Seems to catch a decent bit, so now testing at Special:AbuseFilter/1243. Galobtter (pingó mió) 08:16, 31 March 2023 (UTC)

 Done. Set to disallow per Wikipedia:Edit_filter_noticeboard#Set_1243_to_disallow?. Galobtter (talk) 05:23, 13 April 2023 (UTC)

Bad words to possibly add

"trann(y|ie)", "libtard": rarely seen in legitimate edits from new users. Requested previously but got no response. 137a (talk • edits) 18:00, 12 April 2023 (UTC)

Also, is this still an issue?137a (talk • edits) 18:02, 12 April 2023 (UTC)

do you have diffs of those being used? Galobtter (talk) 22:32, 12 April 2023 (UTC)

"Libtard" seems to have dimished quite a lot recently. I suspect the hard of thinking have just moved on to calling everything they don't like "woke", a bit like 10-year-old kids in the early 2000s calling everything "gay". Black Kite (talk) 07:16, 13 April 2023 (UTC)

I am struggling to find edits where these words are used, can you link some diffs @137a? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 01:49, 15 April 2023 (UTC)

Idea is not well explained No reply. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 23:17, 8 May 2023 (UTC)

Reverting administrator filter

• Task: This filter would apply to all pages in all namespaces. It would be a tag only filter for non-confirmed users undoing edits by an administrator.
• Reason: This would help users who use edit filters to identify vandalism to find users reverting administrators edits. This will allow them to review the edit as it is probably problematic.
• Diffs: I couldn’t find any specific diffs, but this is a clear and obvious vandalism tag-only filter.

- 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 23:42, 8 May 2023 (UTC)

I don't like this. Non-confirmed users can still get in perfectly reasonable disputes with administrators. Admins are trusted to perform administrative actions, but it's impossible to be perfect with editing content, even if someone is an administrator. 0xDeadbeef→∞ (talk to me) 00:02, 9 May 2023 (UTC)

I agree with all the concerns you have raised, especially the part that administrators are fallible. In 95% of cases, you shouldn’t revert an administrators edits if you are not confirmed, and if you do this filter will only tag, so I don’t see a problem. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:13, 9 May 2023 (UTC)

It goes well beyond just content issues, +sysop does not immunize you from fat-fingered mistakes, I've reverted a number of sysops over the years and some even thanked me for it. If your looking for a reason though, tag filters have a cost in editor time and unless they are catching something that is otherwise slipping through, that editor time is going to be more efficiently used monitoring other things, or if they aren't monitored just push us closer to the condition limit for no reason.

I would need to see some clear examples of edits that this filter would catch but are not already being caught by other means before I'd consider supporting this. 74.73.224.126 (talk) 03:21, 9 May 2023 (UTC)

As others have pointed out, this is problematic in general. One specific case is where an administrator adds a message to a new user or IP's talk page, then the recipient notes and deletes it quite properly. Certes (talk) 14:22, 9 May 2023 (UTC)

I tend to agree with those above, but mainly I wish to raise the meta point that the edit filter can't determine much about who is being reverted, except sometimes their username, and having a filter containing all 859 admin usernames is not reasonable. Technically, it's a non-starter. -- zzuuzz ^(talk) 14:36, 9 May 2023 (UTC)

And this sort of thing already exists (or should exist) for anti-vandal scripts and tools. Having used Huggle when reviewing an edit the history does give different icon color to different user groups so that should be fine. I think we should also look at how ORES looks at those edits and maybe ORES will generally rate them as more problematic than others. 0xDeadbeef→∞ (talk to me) 14:41, 9 May 2023 (UTC)

 Request withdrawn per the concerns above. Great points everyone! - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:19, 9 May 2023 (UTC)

Flag of Indian Kashmir

Please review your content that is totally incorrect. 49.36.184.190 (talk) 12:17, 12 May 2023 (UTC)

You tried to add a nonexistent file, which triggered an edit filter set to warn. – dudhhr ^talk _contribs (he/they) 18:30, 12 May 2023 (UTC)

Edit summary indicates possible use of ChatGPT or a similar large language model

• Task: Eventually, tag edits by IP editors and non-(auto)confirmed editors with an edit summary that suggests use of a large language model, e.g. by including text like "ChatGPT", "human-like AI", "GPT-4" or "Large Language Model" in the edit summary with something like "Possible use of Large Language Model". Probably should start out as logging to see how widespread it even is vs. the number of false positives (like edits to subject-relevant articles & reverts of AI-edits)
• Reason: Most ChatGPT/LLM/AI-written edits (especially those by editors unfamiliar with the standards of Wikipedia) need reverting, and the rest of them still needs a thorough check due to the potential pitfalls of AI-generated content. While nowhere near all of them indicate the use of a LLM in the edit summary, being able to easily find at least a portion of them is still an improvement.
• Diffs: Due to the inability to search for edit summaries, I only have a single sort-of example at hands, which shows the type of edit summary I mean, even if the actual edit was a different kind of problematic edit: GPT-spam. AddWittyNameHere 03:06, 16 May 2023 (UTC)

  Could probably do something like:

  !("confirmed" in user_groups) &

  (

  bad_word := "GPT”

  match := get_matches(bad_word, summary);

  match[0] & !(match[0] in old_wikitext)

  )

  Make changes as nessesary. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:18, 18 May 2023 (UTC)

  From what I understand of it (writing edit filters isn't something I've got any experience in), seems to do about what I'm looking for, yeah (other than the GBT part which I assume is a typo for GPT) AddWittyNameHere 10:22, 18 May 2023 (UTC)

   Self-trout because I can’t spell GPT. We may want to add something like: page_name ! contain “GPT” to avoid false positives. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:34, 18 May 2023 (UTC)

  Maybe exclude anything in Category:Large language models too, to cut down on false positives? Even on those not actually named GPT-something, there'd be plenty of situations in which GPT in the edit summary would be perfectly relevant, I guess. (If that's possible—I'd assume so—and not too expensive compared to its benefits—no clue, I'll leave that to y'all edit filter experts) AddWittyNameHere 11:06, 18 May 2023 (UTC)

  edit filters have no knowledge about categories. 0xDeadbeef→∞ (talk to me) 12:23, 18 May 2023 (UTC)

  Oops, it can still check for a category link (in the wikitext) but not for categories added by templates and etc. 0xDeadbeef→∞ (talk to me) 12:23, 18 May 2023 (UTC)

  Can you create the filter @0xDeadbeef? I have supplied some basic REGEX code to start and @AddWittyNameHere has made some suggestions. Whenever you get a chance, please go ahead and create it because I have also seen the editing AWNH speaks of. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:13, 19 May 2023 (UTC)

  I personally agree with Suffusion of Yellow's sentiment below and I think this should be created if there is a consensus to do so. 0xDeadbeef→∞ (talk to me) 18:30, 20 May 2023 (UTC)

  Let's ask the obvious question: Do we want to tag these edits? Seems kind of like detecting paid editing by looking for "paid editing" in the edit summary. Only the "honest" people are going to do that. And if you start tagging their edits, they might become less honest. AFAIK, the only way to reliably detect AI-written content is another AI. This seems almost like a desperation measure. See also evil bit. Suffusion of Yellow (talk) 00:23, 19 May 2023 (UTC)

  @Suffusion of Yellow Yes, this won't catch deliberately-deceptive, or maliciously-LLM-using (e.g. deliberate hoaxing) people, barring the occasional exceptionally sloppy case of it. But catching those was also not really my aim in proposing this filter.

  I think, for the type of edit(or)s I'm hoping to catch with this filter, a better comparison than paid editing is the history of issues we had on en.wiki with the content translation tool before it was disabled for non-EC editors: people using a tool with the best of intentions, but without the necessary knowledge to understand its limitations, pitfalls, or what additional measures and considerations need to be taken into account when using it. Ignorance, rather than deception or malice.

  Plenty of those folks will, once told that the way they're using the tool is not compatible with the rules of this place, happily stop doing so, because they were trying to improve the encyclopedia even if in effect they made it worse; and some might actually become productive editors. But that does mean someone needs to actually tell them, and for that someone needs to notice them first. Sure, an edit filter like this will only catch a portion even of the well-meaning editors. But correcting a portion of them early on can still mean a fair bit of effort saved down the line.

  Or at least, that's my view and intention in proposing the filter.AddWittyNameHere 05:45, 19 May 2023 (UTC)

  @AddWittyNameHere How does the inclusion of phrases like "ChatGPT" in the edit summary show that the edit was produced by ChatGPT? The two things seem almost unrelated to me. LLM output does not include those phrases by default, so I don't know why it would be a good idea to look for them - they probably won't exist. I imagine the false positive ratio would be astronomical, you're far more likely to see an edit summary like "removing ChatGPT generated rubbish" than "This edit was written by ChatGPT".

  This seems a bit like trying to populate an "edit made from a windows PC" tag by looking for edit summaries that contain the words "Microsoft" or "Internet explorer".

  I do agree that we're going to have a big problem with LLM generated content in the future, I've seen the problems with the output it generates and I've noticed sockpuppets using it to avoid detection, but I think this is the wrong approach. I think a much better approach would be either updating mw:ORES to look for AI generated content or creating a standalone tool to look for AI generated edits, in the style of WP:CopyPatrol. There are bits of software that claim to be able to detect AI generated text, though it's not clear what the false positive ratio would be. 192.76.8.64 (talk) 00:11, 21 May 2023 (UTC)

  If you are concerned about false positives, this would be a tag only filter, probably, and we could make it only apply to non-autoconfirmed users. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:14, 21 May 2023 (UTC)

  @Illusion Flame I don't see how restricting this to autoconfirmed editors fixes the fundamental problem - the edit filter is looking for something that probably won't exist in the edits it is supposed to be tagging.

  If you ask ChatGPT to write an article on something then copy and paste its output into Wikipedia the edit will not include any of phrases mentioned in the op, nor will it contain any other kind of specific content we could look for. As I said, this is like trying to figure out which editors are using Microsoft Windows by looking for people using the words "Internet Explorer"

  The tag this would produce would be pointless, because the thing the filter is looking for is essentially unrelated to the condition in the filter. You would end up incorrectly tagging massive amounts of edits from people editing about/discussing LLM's while missing a load of AI generated articles.

  Integrating something like GPTZero into the recent changes feed via ORES or building a tool around it allowing people to review suspicious edits seem like much better options to me. 192.76.8.64 (talk) 00:28, 21 May 2023 (UTC)

  Think about this scenario: A users asks ChatGPT to write an article about cats. They then paste it onto the page about Cats. They use the edit summary “chatgpt wrote this”. This is what the filter is hoping to track. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:33, 21 May 2023 (UTC)

  Yes, I understand that. Have you read what I've been saying - I mention this in my first comment here.

  The point is that a massive proportion of people using AI models will not use edit summaries like this, and these kind of phrases do not appear in the LLM output - this makes this an extremely poor detection method. I've seen quite a few cases of editors using LLMs to edit ending up at noticeboards now and I can't recall a single one of them admitting what they were doing in the edit summary. There will, however, be a massive number of people using edit summaries like "removing ChatGPT generated content", "adding a section on using ChatGPT" or "Tagging article for deletion as an AI generated hoax" - you are going to end up with a tag that is almost entirely false positives. 192.76.8.64 (talk) 00:43, 21 May 2023 (UTC)

  N Denied per 192.76.8.64 above. Most users won’t have it in their edit summary, lots of false positives. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:47, 21 May 2023 (UTC)

  Yeah, guess you're right. Pretty sure I've seen a few cases that would've been caught by a filter like this (but pretty much impossible to find those back because of the lack of ability to search on edit summaries alone), but I guess 192.76.8.64 certainly does have a fair point about false positives. AddWittyNameHere 02:09, 21 May 2023 (UTC)

  I have also seen a few cases, but not as many to justify creating a filter to tag them. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:10, 21 May 2023 (UTC)

"Za" vandalism

• Task: This filter is supposed to prevent the addition of, or replacement of words or phrases in an article with "Za".
• Reason: Recently, numerous IPs (likely same editor using multiple IPs) have begun adding and replacing parts of an article with "Za" in the Article and WP: namespaces. Such edits are disruptive and should be prevented.
• Diffs: The first diff I came across with this vandalism. Initially mistook it for a test edit, until it continued. Later, the vandalism became more widespread, beginning to break templates, and extending into the WP: namespace.

ChrisWx (talk - contribs) 00:58, 22 May 2023 (UTC)

Did you see any instances of that vandalism outside of this this range? If not, a rangeblock should suffice. OhNoitsJamie ^Talk 01:07, 22 May 2023 (UTC)

I haven't, and you're right, a rangeblock would likely be best for this situation. ChrisWx (talk - contribs) 01:11, 22 May 2023 (UTC)

If vandalism does continue outside of this range, this filter will be requested again, but for the time being,  Request withdrawn per Jamie's rangeblock. ChrisWx (talk - contribs) 01:12, 22 May 2023 (UTC)

Adding broken harvnb-sfn cites

Now, there probably isn't a way to do this that doesn't involve creating false positives. However, I do think this is worth discussing and maybe testing out.

Basically, I want to combat against good faith edits like this which add material from another article but which introduce harv errors. It's pretty time-consuming to fix these because only the author really knows what source they were trying to cite. However, if they could be warned before they publish their edit that the footnote's link is broken, they could be prodded into fixing it themselves. Otherwise, folks like me have to fix it by going through the entire edit history to try and (hopefully) see where the citation was copied from to finally be able to put the source into the article properly.

An editor filter which theoretically checked new text to see it includes a harv/sfn template and then checks to see if it matches an expected ref on the page, would greatly aid bringing down Category:Harv and Sfn no-target errors for the future. –MJL ‐Talk‐^☖ 21:19, 26 May 2023 (UTC)

@MJL: This might be possible. I'm gathering some data at 1014 (hist · log), which I'll use to test some ideas once there are enough hits. Some quesitons:

• Are "multiple target" errors really common enough to worry about? There are only 10 page in Category:Harv and Sfn multiple-target errors right now. "No target" errors seem easier to check for.
• What's more common? People adding a {{sfn}} template, with no associated {{cite}}? Or people removing a {{cite}}, not realizing that there's still a {{sfn}} pointing to it? Suffusion of Yellow (talk) 18:47, 27 May 2023 (UTC)

@MJL: Now a more refined filter at 1254 (hist · log). Both no-target and multiple-target errors are detected. But the filter has a few limitations: If there's already a broken {{sfn}} on the page, it will only detect a new one being added if it's before the old one. And it doesn't detect problems caused by removing or altering the {{cite}}. Incidentally, I highly recommend User:Nardog/CatChangesViewer. Suffusion of Yellow (talk) 18:51, 28 May 2023 (UTC)

@Suffusion of Yellow: Awesome! Thank you for both the script recommendation and the filter!

To answer you question, multiple-target errors certainly occur but are very infrequent as you might have guessed.

I would say people adding {{sfn}} templates with no associated {{cite}} templates are much more common than people removing {{cite}} templates with still existing {{sfn}} templates. The latter generally only occurs when the reference the {{sfn}} is pointing to is also a footnote in another section of the article (which gets removed at some point). That's very much not as common as just placing the {{cite}} template at the bottom of the page.

Your work is very much appreciated! –MJL ‐Talk‐^☖ 19:24, 28 May 2023 (UTC)

I'll be watching/monitoring the filter, and if I notice anything that could be improved in a few months, I'll post to WP:EF/N with recommendations. Cheers, –MJL ‐Talk‐^☖ 19:26, 28 May 2023 (UTC)

Filmcompanion

Trivial construct (maybe, add a case to an existing filter?):

• Disallow addition of any links from the domain filmcompanion.in by non-confirmed users.

See consensus at at this thread. Thanks, TrangaBellam (talk) 16:10, 20 May 2023 (UTC)

I've created Special:AbuseFilter/1252, but have not enabled it since an admin should be responsible for assessing the consensus over there, and also a custom disallow message should be created (or used from somewhere else that I can't find where). 0xDeadbeef→∞ (talk to me) 18:42, 20 May 2023 (UTC)

@0xDeadbeef: Thanks. There should be no harm in leaving that enabled, in log-only mode. I generally don't worry about consensus for log-only filters (just BRD like anything else); for disallowing filters leaving a message at WP:EFN for a week or so should be sufficient. Suffusion of Yellow (talk) 19:42, 20 May 2023 (UTC)

The link in question is blacklisted as of now; this EF is a compromise to allow established editors add links from the site but prevent link spamming. So, we can probably waive off the usual one-week-requirement for disallowing filters. TrangaBellam (talk) 10:07, 21 May 2023 (UTC)

Any updates? TrangaBellam (talk) 11:02, 29 May 2023 (UTC)

The filter is supposed to be working correctly. But since the link is still in the spam blacklist, it's not going to catch any edit (I think? or does spam blacklist run after filters). 0xDeadbeef→∞ (talk to me) 11:39, 29 May 2023 (UTC)

Huh. A few years ago, at least, adding a blacklisted link and tripping a filter would create an entry at both the filter log and spam blacklist log. But not any more, it would seem. There's no filter hit corresponding to [14]. I don't know whether to call that a bug or a feature. And yes, people are trying to add the link; just CTRL-F at [15]. Suffusion of Yellow (talk) 20:43, 29 May 2023 (UTC)

@Black Kite: The filter is all set. So, please proceed with the removal of the domain from Blacklist? TrangaBellam (talk) 18:54, 31 May 2023 (UTC)

@TrangaBellam and 0xDeadbeef: Someone still needs to post at WP:EFN with the proposed "disallowed" message, unless you don't mind letting all editors add these links while the filter is under discussion. Examples at Special:Prefixindex/MediaWiki:Abusefilter-disallowed and Special:Prefixindex/MediaWiki:Abusefilter-warning. Suffusion of Yellow (talk) 01:15, 1 June 2023 (UTC)

Slavic profanity

Have seen a bit of this sort of thing around lately. The particular term here is "ХУЙ" (KHUY), which is Russian for "FUCK". Mako001 (C)  (T)  🇺🇦 00:07, 14 May 2023 (UTC)

Instead of creating a filter for this purpose, why don’t we add “ХУЙ” as a hit for a current profanity filter. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 23:47, 14 May 2023 (UTC)

@Illusion Flame: Perhaps I should have said so, but that was the intention. No need to push us even closer to the condition limit for something that an existing filter can handle. Mako001 (C)  (T)  🇺🇦 04:37, 5 June 2023 (UTC)

Thanks for suggesting a change, but this page is for filter creation requests only. Please make a request on the Edit filter noticeboard suggesting an addition to the profanity filter. Thanks! - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:21, 5 June 2023 (UTC)

Prevent or warn on Use of nowiki tags around URLs in refs

• Task: The filter would warn or disallow activate on the use of nowiki tags around URLs in references. It would apply to all users.
• Reason: Whilst such edits are not themselves harmful (although they do make it harder to access the URL), this is used to bypass other filters that look at the "links-added" parameter, including the "RS linked through proxy" filter, the spam blacklist, and the "unreliable/predatory source" filter.

I cannot think of any legitimate need to use this sort of formatting in the ref, if you need to use such sites in the references, then that is what the whitelists are for. Some editors seem to frequently use this sort of formatting for all refs, and this is obviously an issue, as when they add a blacklisted link or add a proxy URL, they are completely oblivious. However, in some cases below, the users spam blacklist logs, as well as other evidence, suggests that they are aware that a filter or blacklist would prevent the addition of the link, but intentionally bypass it anyway. Most of these edits were tagged as "nowiki added", but finding these problematic additions amongst the noise of other nowikis being added isn't really an option. I have also seen URLs within citation templates nowiki-ed, so a filter would need to take that into account as well.

At best, putting a ref URL in nowiki tags makes the url difficult to navigate to and impedes accessibility. At worst, it slips blacklisted and proxy URLs into the article almost unnoticed, impacting verifiability and leaving content sourced to garbage sources, or making it inaccessible to almost all readers.

• Diffs: adds link to predatory journal, adds proxy link, adds proxy link, adds proxy link, adds proxy link, adds proxy link, adds proxy link, adds proxy link, adds proxy link, adds blacklisted link, adds blacklisted link, adds blacklisted link, adds blacklisted link, adds blacklisted link, adds blacklisted link, adds blacklisted link, adds blacklisted link, and I can find a lot more too.

Mako001 (C)  (T)  🇺🇦 06:36, 5 June 2023 (UTC)

I am neutral about the filter creation itself, but I don’t think the filter should disallow/warn users. There could be good faith newer editors incorrectly trying to add references that become discouraged upon having their edit disallowed. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:19, 5 June 2023 (UTC)

It could be set to tag-only, but it is a pain if it is used to bypass blacklisting and add proxy URLs, especially since those who do so often hit another filter first, then put the URL in nowiki tags to avoid it. Any sort of potential warning would be a very softly-worded one. That said, tag or log-only would be far better than nothing at all, so I've amended the request accordingly. Mako001 (C)  (T)  🇺🇦 00:10, 11 June 2023 (UTC)

Okay. I’ll ping some Edit filter managers to help get this expedited: @Suffusion of Yellow: and @0xDeadbeef: - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 01:07, 11 June 2023 (UTC)

pen1s vandalism filter

Task: Block edits by non-confirmed users or IPs which contain the word "pen1s"
Reason: The word "pen1s" has been used by multiple IPs to vandalize seemingly random articles. May want to put this in a related filter (e.g. one relating to genitalia)
Diffs: On USS Newport News, On Phobia (Breaking Benjamin album)
Capsulecap ^{(talk • contribs)} 20:01, 16 June 2023 (UTC)

Looks good to me. I’ll ping @0xDeadbeef and @Suffusion of Yellow for comments and addition. This will probably just be added to an existing filter, if that’s alright. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:15, 18 June 2023 (UTC)

I've already added this to the misc LTAs filter. — Ingenuity (talk • contribs) 00:19, 18 June 2023 (UTC)

Okay, although this would probably be a better fit for the bad word or other vandalism filter. It isn’t really an LTA issue, I don’t think @Ingenuity. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:30, 18 June 2023 (UTC)

Eh, doesn't really matter. If someone wants to move it that's fine with me. — Ingenuity (talk • contribs) 00:41, 18 June 2023 (UTC)

I guess you’re right, it doesn’t matter that much. I just like to be very organized :) - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:43, 18 June 2023 (UTC)

Modification to '#WPWP (throttle)' filter

• Task: Filter: 1158
• Reason: I'd like to request for modification to this filter on behalf of the #WPWP contest organizers.

Based on evaluation of previous campaigns and issues raised on this wiki, we have made new changes to the campaign rules this year and one of the changes is specifically regarding participation on English Wikipedia. Eligibility rules now require a user to be extended-confirmed (WP:XC) before participating on this wiki. So Instead of uniform throttling edits for all users, we'd like it to request for help in enforcing this new eligibilty rule by disallowing edits from users who are not extended-confirmed and raising the daily limit to 100 edits (from current 25).

I'd like to note that when this filter was introduced in 2021 the campaign allowed brand-new editors to participate which led to most of the issues due to lack of experience. This is no longer the case. We have already changed that since last year (see my comment here [16]) to require having account for at least a year to allow participants gain real editing experience prior to the campaign proper and assimilate community values. With the last years' changes we have seen improvements and significant decrease in abuse and competency-related issues. This year we would like to further make this change to allow experienced users participate more freely while preserving the intent of the filter for the inexperienced users.

• Diffs:

– Ammarpad (talk) 17:04, 14 June 2023 (UTC)

This page is for requesting new filters only. Please request filter changes on the WP:Edit filter noticeboard. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 18:30, 14 June 2023 (UTC)

Regardless, if an EF manager is passing by, can you edit 1158 for extended-confirmed only? That would sort the main problem straight away. Black Kite (talk) 19:02, 14 June 2023 (UTC)

@Illusion Flame, sorry, I misread this. It looked like it says If you wish to request an edit to filter, please post at Wikipedia:Edit filter/Requested. I should have read better. I'll leave it here now per Black Kite.– Ammarpad (talk) 21:10, 14 June 2023 (UTC)

That’s fine! Just so you know for the future. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 21:15, 14 June 2023 (UTC)

Pinging recent editors of the filter: @ProcrastinatingReader and Firefly: . – Ammarpad (talk) 08:00, 19 June 2023 (UTC)

@Black Kite and others - have implemented the extended-confirmed restriction in Special:AbuseFilter/1258 so as not to overwrite 1158 if it turns out we still need it. I have not yet enabled 1158 (the throttle filter). Will flag all this at AN as 1158 was created to implement a community decision. firefly ( t · c ) 09:40, 2 July 2023 (UTC)

Flagged at AN firefly ( t · c ) 10:09, 2 July 2023 (UTC)

Prevent non-AfC reviewer from declining or accepting AfC submission

• Task: This filter is used to prevent non-AfC reviewer from accepting or declining draft submmisions by if the filter matches with the string {{AfC submission|D}}, {{AfC submission/declined}}, {{AfC submission/rejected}}, {{AfC submission|reject}}, and {{AfC submission/created}} it then triggers a message to prevent users from doing that action. This filter only applies to drafts and userspaces and to the user who are not extended-confirmed and administrators which includes confirmed/autoconfirmed user(s), new user(s), and unregistered/IP/anonymous editor(s).
• Reason: Because the criteria to become an AfC reviewer is from the excerpt that the criteria required to become AfC reviewer is:

Criteria:

AfC reviewers must have:

• a Wikipedia account at least 90 days old.
• a minimum of 500 undeleted edits to articles (this is not the same as total number of edits).
• thoroughly read and understood the reviewing instructions.
• a demonstrated understanding of the policies and guidelines mentioned in the reviewing instructions, including the various notability guidelines.
• reasonable evidence of understanding the deletion policy (experience in areas such as CSD/AfD/PROD or page curation, while not mandatory, are beneficial).
• a willingness and ability to respond in a timely manner to questions about their reviews.

— Notice to prospective Articles for Creation reviewers, Wikipedia:WikiProject Articles for creation/Participants

• Diffs: Diff 1159819666.

Vitaium (talk) 14:54, 19 June 2023 (UTC)

Needs wider discussion Currently AFC only strongly discourages non-afc reviewers from reviewing drafts. It doesn’t completely disallow it. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:10, 20 June 2023 (UTC)

Vitaium proposes that only non-EC users should be disallowed by the filter. Extended-confirmed non-AFC reviewer users would be unaffected (and, on the technical side of things, AFC review is checked through a Wikipedia page rather than a user-right, which I believe is harder to implement into a filter's conditions). – dudhhr ^talk _contribs (he/they) 03:00, 20 June 2023 (UTC)

I know, but I still think wider discussion is needed to make the change. And you’re right, I hadn’t even considered that it will be very difficult to create the filter because there isn’t a user right that comes with AFC reviewing. I don’t now how this would work myself, so this would be Impossible unless someone else has another idea. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:54, 20 June 2023 (UTC)

Yeah, agreed, the lack of an official MediaWiki permission for AFC reviewers probably means a filter can't be created for this. –Novem Linguae (talk) 09:09, 29 June 2023 (UTC)

Consensus on whether or not this ought be mandatory aside, I don't think a filter to help with this is impossible per se.

1. One could exempt admins and NPRs from the filter and then simply hardcode a list of non-admin, non-NPR reviewers into it. If one then checks the user_name variable against that hardcoded list, it could technically be possible. My concerns with this approach are that it would require unusually active maintenance for an edit filter and would drive up the condition count as a result of the long, hard-coded list (there's about 150 users with access to the AfC script that have neither NPR nor admin).
2. An alternative could be to write a filter that disallows users who are not extended-confirmed the ability to do this sort of thing. Since AFC reviewers are 90+ day-old accounts with >500 undeleted edits, all of them have to be extended-confirmed at minimum. The downside of this approach is that it would allow through edits from ECP'd accounts w/o permission to use the AfC script.

Neither of these are perfect, but these sorts of approaches could be a way forward if the community wants something like this. — Red-tailed hawk _(nest) 00:35, 1 July 2023 (UTC)

If this is done, I’m leaning towards opinion 2 that @Red-tailed hawk provided. I still think that wider discussion is needed before either filter is created. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:13, 1 July 2023 (UTC)

I also would lean that way. Might be worth creating a tracking filter along the lines of #2, to better understand the frequency of this sort of thing, before opening a discussion on whether or not to disallow/warn users for doing this. If we're dealing with something that happens once per fortnight, the extent of damage may be so low as to not even warrant an active tracking filter. If this is happening all the time, and only with particularly spammy drafts, then having that data might also better inform future discussions. — Red-tailed hawk _(nest) 04:52, 3 July 2023 (UTC)

Anecdotally speaking, we're pretty good about nipping this in the bud, and while I don't have any numbers to support the idea that this isn't an issue, I would be surprised if it requires an edit filter to stop folks from doing it. Primefac (talk) 14:18, 3 July 2023 (UTC)

#1 wouldn't be a good maintenance to value ratio. The list of AFC reviewers that aren't NPPs or admins is updated frequently. –Novem Linguae (talk) 05:47, 3 July 2023 (UTC)

@Novem Linguae: Would the following work?

/** user is not EC or admin **/
!contains_any(user_groups, "extendedconfirmed", "sysop") &
/** namespace is User or Draft **/
equals_to_any(page_namespace, 2, 118) &
/** syntax added when a draft is reviewed **/
contains_any(lcase(added_lines), "{{afc submission|d|", "{{afc submission/declined", "{{afc submission|reject", "{{afc submission/rejected", "{{afc submission/created")

– dudhhr ^talk _contribs (he/they) 06:43, 3 July 2023 (UTC)

I'm not sure Template:AfC submission/created is needed. I also think we should pause and get consensus from WT:AFC before proceeding further. Seems odd to make an edit filter affecting AFC without asking them. I'll drop a note. Note that I am neutral on this so far and was just providing some technical advice. Note that WP:AFCP states Editors whose usernames are not on the list are strongly cautioned not to review AfC submissions which is not an absolute prohibition on non-AFCers reviewing drafts, although I wouldn't mind tightening that. In the event that there is not consensus to block these edits, having a tag and a log could be useful. –Novem Linguae (talk) 07:37, 3 July 2023 (UTC)

Thanks for notifying AFC. I agree that we should consult them first. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:28, 3 July 2023 (UTC)

dudhhr, your example is problematic; if for example a new user blanks their (declined) draft, and then decides to restore it, they would be prohibited from doing so, because they would be "adding a decline notice". Primefac (talk) 14:21, 3 July 2023 (UTC) With apologies to bradv who pointed this out to me... I replied before he could... soz...

@Primefac: Thanks. All of the draft declines that I looked at in my afc log change the page size by <400. Maybe add an edit_delta < 400 condition to prevent unblanking from triggering the filter? – dudhhr ^talk _contribs (he/they) 15:42, 3 July 2023 (UTC)

Then the filter could be easily circumvented simply by adding a comment. I'm struggling to see the benefit of this filter – unless someone can demonstrate that unauthorized declines is a significant problem, the downside risk of usability errors introduced by the filter is likely too high. – bradv 15:54, 3 July 2023 (UTC)

I too struggle to see the benefit. If a decline by a non-reviewer is bad, it can just be reverted by a recent changes patroller. – dudhhr ^talk _contribs (he/they) 16:45, 3 July 2023 (UTC)

Warn on talk page creations for AfD entries

• Task: When a new user attempts to create a talk page under an AfD entry, give them a notice stating that any discussion should take place on the main AfD entry.
• Reason: To hopefully push people in the right direction when it comes to AfD contributions.
• Diffs: Only one, which is here. There might be more cases that I'm not aware of.

Deauthorized. ^(talk) 18:32, 17 July 2023 (UTC)

Maybe this would be a better job for edit notices? I haven’t noticed this as a huge issue, so I’m not sure a filter would be necessary. Definitely would like to hear other’s opinions. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:40, 18 July 2023 (UTC)

@Illusion Flame: Apparently group notices are a feature, which extends edit notices to every sub-page within a page. Perhaps one for Wikipedia talk:Articles for deletion would work. Though I'm sure I'd have to propose it somewhere. Deauthorized. ^(talk) 06:13, 19 July 2023 (UTC)

Yes, I think this is probably better than an edit filter, which applies to all edits. Maybe start a discussion on WT:AFD. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:29, 19 July 2023 (UTC)

Nazi flag LTA

• Task: Edit filter for image vandalism
• Reason: Abuse of widely-used images that can't reasonably be blacklisted by LTA, via proxies. If there's a suitable existing EF that this can be added to, so much the better.
• Diffs: [17], many nearly identical edits like this [18]

Acroterion (talk) 01:52, 2 August 2023 (UTC)

Enabled 684. -- Tamzin^{[cetacean needed]} (she|they|xe) 03:33, 2 August 2023 (UTC)

Addition of external links by new users

This would make it easier to detect spam. As far as I can tell, no such filter currently exists. Partofthemachine (talk) 23:31, 28 June 2023 (UTC)

It would also make it harder to add citations. How do we tell the difference? If certain sites are a problem, we have a spam blacklist and a CAPTCHA system. Certes (talk) 08:29, 29 June 2023 (UTC)

I get the impression this would be a log-only filter, but maybe I am misreading. Partofthemachine, can you clarify? –Novem Linguae (talk) 09:06, 29 June 2023 (UTC)

Idea is not well explained. Please follow the format at the top of this page. Some diffs of the issue, along with specifics of what you mean by “new users” and what actions you believe the filter should take would be great. We currently have a filter for new users adding links containing their username, which helps stop a lot of spam. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 13:47, 29 June 2023 (UTC)

Yes, it would be log-only, and only apply to external links outside of a IP edit replacing contents.

AlphaBetaGamma (Talk/Report any mistakes here) 00:54, 1 March 2024 (UTC)

I personally don't think this a good candidate for an edit filter because while it's sometimes disruptive this can be contextually dependent and should probably not be disallowed automatically. Philipnelson99 (talk) 01:07, 1 March 2024 (UTC)

@Philipnelson99I see. Where should this belong then? AlphaBetaGamma (Talk/Report any mistakes here) 01:37, 1 March 2024 (UTC)

I mean you're in the right place to request an edit filter, I'm just not sure this would be a good edit filter. If restricted to IPs/non-autoconfirmed that might reduce false positivess but I'm not convinced that would eliminate false positives altogether since it's hard to say if all replacements are disruptive. Happy to hear other opinions on it and it's really up to an EFM to decide to implement it. Philipnelson99 (talk) 01:47, 1 March 2024 (UTC)

This is 1154 (hist · log). Note that it logs both Israel -> Palestine and Palestine -> Israel. As Philipnelson99 points out, setting this sort of filter to disallow would be a bad idea, and even warning might open up a can of worms. Suffusion of Yellow (talk) 02:59, 1 March 2024 (UTC)

Suffusion of Yellow thanks for pointing out the logging filter, didn't realize it existed. I think logging is really the only reasonable course of action here. If an edit is indeed an issue, it will likely be reverted speedily. Setting a filter to warn when there's a chance that the edit was good faith and not intentionally disruptive seems unproductive to me. Philipnelson99 (talk) 03:09, 1 March 2024 (UTC)

Maybe tagging would work, as any good faith edits wouldn't be reverted but bad faith ones would be easier to see and thus revert? – PharyngealImplosive7 (talk) 14:41, 1 March 2024 (UTC)

I don't think tagging these filter hits is necessary. Philipnelson99 (talk) 17:31, 1 March 2024 (UTC)

Why do you think that? And I'm just curious that's all. – PharyngealImplosive7 (talk) 18:48, 1 March 2024 (UTC)

I’d like them tagged. I see these changes frequently, usually from IPs. Doug Weller talk 19:19, 6 April 2024 (UTC)

What would you suggest the tag be @Doug Weller? Something like Possible ARBPIA issue maybe? My concern with tagging is the area is a contentious topic and tagging these edits as a possible ARBPIA issue may need consensus elsewhere. Philipnelson99 (talk) 13:44, 9 April 2024 (UTC)

Possible a-i issue would be better. It seems obvious enough that I wouldn't think it needed consensus. I wouldn't mention ARBPIA as that's probably too strong. Doug Weller talk 13:52, 9 April 2024 (UTC)

Gotcha, as long as the tag isn't too strongly worded then I'm okay with tagging these. Just don't want someone to get the wrong idea that every filter hit has a problem. Philipnelson99 (talk) 14:09, 9 April 2024 (UTC)

References

Block "Billy Flowers" edits

• Task: For the last few days I've found various IPs adding material about a Billy Flowers(see [19]) Examples are "(the Quora user who is a big rival of Billy Flowers}", "Billy Flowers, the world famous debunker of atheism, attended this university.", "He has engaged in debates with [https://www.quora.com/profile/Billy-Flowers-21 Billy Flowers before, such as when he created a YouTube video with a response to Billy Flowers's famous question about skydiving wit, h a Christian baby.", "* Billy Flowers  – (born 1990), the man who debunked atheism"," Billy Flowers  – (born 1990), the man who debunked atheism". See also the edit susmmaries, link to two IPs below.
• Reason: to block the spam
• Diffs: See [[20]]. Unfortunately I didn't keep samples from other IP addresses. ALso found [21].

Doug Weller talk 12:26, 2 April 2024 (UTC)

Another IP. The usual plus a serious BLP violation. [[[Special:Contributions/70.33.148.202]] Doug Weller talk 20:46, 2 April 2024 (UTC)

Maybe we should add this to 614 (hist · log), with the regex billy?\sflowers, but the amount of false positives might be high due to legitimate uses of the name, so I would suggest that we test this out first on log only in a test filter to see how common these edits are and if the amount of false positives is manageable. – PharyngealImplosive7 (talk) 00:48, 3 April 2024 (UTC)

@PharyngealImplosive7 Now from Special:Contributions/70.33.148.202 Doug Weller talk 17:48, 3 April 2024 (UTC)

Yeah. It’s clear to me at this point that this needs to be filtered. – PharyngealImplosive7 (talk) 20:46, 3 April 2024 (UTC)

I've sent an email to the private abuse filter email list about this. Philipnelson99 (talk) 14:07, 9 April 2024 (UTC)

Thanks. Doug Weller talk 14:15, 9 April 2024 (UTC)