Wikipedia:Edit filter noticeboard

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
Welcome to the edit filter noticeboard
Filter 1168 — Pattern modified
Last changed at 18:11, 27 September 2022 (UTC)

Filter 1219 (new) — Actions: none; Flags: enabled,private; Pattern modified

Last changed at 10:37, 26 September 2022 (UTC)

Filter 1014 — Pattern modified

Last changed at 23:21, 25 September 2022 (UTC)

Filter 1218 (new) — Actions: none; Flags: enabled,public; Pattern modified

Last changed at 22:42, 25 September 2022 (UTC)

This is the edit filter noticeboard, for coordination and discussion of edit filter use and management.

If you wish to request an edit filter, please post at Wikipedia:Edit filter/Requested. If you would like to report a false positive, please post at Wikipedia:Edit filter/False positives.

Private filters should not be discussed in detail here; please email an edit filter manager if you have specific concerns or questions about the content of hidden filters.

Click here to start a new discussion thread


Should there (or is there any?) be a filter to tag edits/page creations by new users that are made in Template, Category, Wikipedia (except AfD and SPI) namespaces? --Minorax«¦talk¦» 11:12, 25 July 2022 (UTC)Reply[reply]

Theoretically this should work:
!("confirmed" in user_groups) &
page_age == 0 & 
contains_any(page_namespace, 10, 14, 4) &
!(page_prefixedtitle in "^Wikipedia:(Articles for deletion\/.+|Categories for discussion\/Log\/\d{4} \w{3,9} \d{1,2}|Files for discussion\/\d{4} \w{3,9} \d{1,2}|Miscellany for deletion\/.+|Redirects for discussion\/Log\/\d{4} \w{3,9} \d{1,2}|Templates for discussion\/Log\/\d{4} \w{3,9} \d{1,2})$")
I don't have access to EFH, so I can't test it, but if an EFM could create a test filter for this, it would be much appreciated. 🐶 EpicPupper (he/him | talk) 03:29, 4 August 2022 (UTC)Reply[reply]
Here's a regex101 test: [1] 🐶 EpicPupper (he/him | talk) 03:36, 4 August 2022 (UTC)Reply[reply]
The middle 2 lines should be:
page_age == 0 & 
contains_any(page_namespace, 10, 14, 4) &
I'm not sure if there's a better way to do the title check. It can be done using substr but that won't be better than regex for accuracy and might not make a significantly beneficial performance difference, if any at all. PhantomTech[talk] 04:36, 4 August 2022 (UTC)Reply[reply]
I forgot to add SPI. It's in there now. 🐶 EpicPupper (he/him | talk) 04:40, 4 August 2022 (UTC)Reply[reply]
And thanks! 🐶 EpicPupper (he/him | talk) 04:40, 4 August 2022 (UTC)Reply[reply]
Err, on second thought, SPI probably shouldn't be included; I'm thinking this should be a create-type filter rather than edit. There would be too many good-faith pages where IPs/non-AC'ed users could edit (the Teahouse comes to mind, but excluding that I think there would be much more still). 🐶 EpicPupper (he/him | talk) 05:40, 4 August 2022 (UTC)Reply[reply]

!("confirmed" in user_groups) &
page_age == 0 & 
contains_any(page_namespace, 4, 10, 12, 14, 710, 828) &
!(page_prefixedtitle in "^Wikipedia:(Articles for deletion\/.+|Categories for discussion\/Log\/\d{4} \w{3,9} \d{1,2}|Files for discussion\/\d{4} \w{3,9} \d{1,2}|Miscellany for deletion\/.+|Redirects for discussion\/Log\/\d{4} \w{3,9} \d{1,2}|Templates for discussion\/Log\/\d{4} \w{3,9} \d{1,2})|Template:Did you know nominations\/.+$")
The above code checks if non-autoconfirmed users create a new page in the Wikipedia, Template, Help, Category, TimedText or Module namespaces. It excludes XfD and DYK. This filter should likely be a tag filter. TheresNoTime, can I ask you for a favor? 🐶 EpicPupper (he/him | talk) 22:25, 4 August 2022 (UTC)Reply[reply]
Testing at Special:AbuseFilter/1 (previous test promoted to filter) — TheresNoTime (talk • she/her) 22:31, 4 August 2022 (UTC)Reply[reply]
A few comments:
  • contains_any(page_namespace, 10) is not the proper way to check for namespaces; for example, it tests true for namespaces 100 and 101. Use equals_to_any(page_namespace, 10)
  • if you're checking for "Wikipedia:Articles for deletion/" PLUS "whatever", you might as well check for "Wikipedia:Articles for deletion/" alone; saves some processing time. Same for other strings, in most cases there's no need to be that specific unless you're gonna use the rest of the string for something.
  • "in" is not a regex operator, use rlike. When using ^ and $, what's in between needs to go inside a noncapturing group, "^(?: )$"
Documentation is here.
Ponor (talk) 00:29, 5 August 2022 (UTC)Reply[reply]
This is right, here's the modified filter
!("confirmed" in user_groups) &
page_age == 0 & 
equals_to_any(page_namespace, 4, 10, 12, 14, 710, 828) &
!(page_prefixedtitle rlike "^(?:Wikipedia:(?:Articles for deletion\/|Categories for discussion\/Log\/\d{4} \w{3,9} \d{1,2}$|Files for discussion\/\d{4} \w{3,9} \d{1,2}$|Miscellany for deletion\/|Redirects for discussion\/Log\/\d{4} \w{3,9} \d{1,2}$|Templates for discussion\/Log\/\d{4} \w{3,9} \d{1,2}$)|Template:Did you know nominations\/)")
PhantomTech[talk] 04:33, 5 August 2022 (UTC)Reply[reply]
Thanks for being speedy, a step ahead of me. @TheresNoTime could you tweak the filter? Sorry, this was my suggestion. 🐶 EpicPupper (he/him | talk) 04:38, 5 August 2022 (UTC)Reply[reply]
(GIF) The two methods of testing the page_prefixedtitle
Changes made (more fool me for only clicking "check syntax" and not properly reading it, given it was log-only.. will be a bit more careful next time) — the debugging tools in AbuseFilter is really useful for testing out things like this Face-smile.svgTheresNoTime (talk • she/her) 10:23, 5 August 2022 (UTC)Reply[reply]
To further simplify: while it doesn't hurt, forward slashes do not need to be escaped (\/). Use "rescape" function in debug console to see that. Ponor (talk) 08:57, 5 August 2022 (UTC)Reply[reply]
While it isn't a special character in regex and doesn't need to be escaped for the filters here, it is the default delimiter at regex101 for PCRE so I think that's why it is escaped. PhantomTech[talk] 09:22, 5 August 2022 (UTC)Reply[reply]

misc article/draft/talk LTA[edit]

False positives area seems to be getting a bit backlogged, and at a spot check all of the past few tripped this one 1 2 3 4. Now maybe I'm the only FP (I doubt that), but an EFM really needs to look closely at any recent changes to that filter to see if they're causing it to disallow innocuous edits. I understand this will need to be discussed in private, just wanted to bring it to everyone's attention. (talk) 15:32, 16 August 2022 (UTC)Reply[reply]

Bumping this section because the problem still seems to be unresolved – there are lots of unresolved reports for hits to this filter that aren't in obvious bad faith, and apparently no edit filter managers have been around to take a look at them. (Because it's a private filter, the non-edit-filter-managers who patrol EFFP can't do anything about these reports – we can't even see what the report submitter was trying to change. We also can't see whether the filter was fixed or not, but even if it has been, the existing reports will need examining.) --ais523 20:59, 17 August 2022 (UTC)Reply[reply]

It's not set to disallow so it shouldn't be causing any actual problems. PRAXIDICAE🌈 21:01, 17 August 2022 (UTC)Reply[reply]
Ah, this is probably filter 1202 mentioned below? In that case, the filter itself is probably OK at the moment, but there's still a backlog at WP:EFFP of edits that got caught in it while it was broken and set to disallow. --ais523 21:03, 17 August 2022 (UTC)Reply[reply]
I've gone and completely refactored and improved the conditions for filter 1202. I've temporarily disabled the disallow action so that we can watch for any unexpected fallout or false positive hits as a result of the changes I made. Any EFM is free to re-enable the disallow action if they feel that the changes I made did not result in any negative effects as a result. ~Oshwah~(talk) (contribs) 06:15, 8 September 2022 (UTC)Reply[reply]


Above, and reports elsewhere - removed disallow disabled due to throttling — TheresNoTime (talk • she/her) 15:37, 16 August 2022 (UTC)Reply[reply]

@Ohnoitsjamie: FYI — TheresNoTime (talk • she/her) 15:37, 16 August 2022 (UTC)Reply[reply]
Oops, thanks for shutting that off! I was trying to fix some false positives, I think I got some nesting wrong. OhNoitsJamie Talk 15:43, 16 August 2022 (UTC)Reply[reply]
Re-enabled (log-only), with a consistent indentation style, because I couldn't follow the logic either. @Ohnoitsjamie:, unless it's an emergency, whenever I make a non-trivial change to a disallowing filter, I either do a quick spot-check at Special:AbuseFilter/test, or, for complex changes, set the filter to log-only for about ten minutes or so. I realize that it can be it bit tedious to do this every time, but that was over 1500 false positives. Suffusion of Yellow (talk) 21:02, 16 August 2022 (UTC)Reply[reply]
Thanks for cleaning that up, I realize it was a bit incomprehensible; it covers a small handful of LTAs. OhNoitsJamie Talk 21:08, 16 August 2022 (UTC)Reply[reply]
@Ohnoitsjamie: NP. Let me use this opportunity to shamelessly plug some of my own tools:
Suffusion of Yellow - DAMN! Thanks for sharing these! I'm going to import them and check them out! Awesome! :-D ~Oshwah~(talk) (contribs) 06:22, 8 September 2022 (UTC)Reply[reply]
I've gone ahead and completely refactored and improved all of the conditions for filter 1202. I've temporarily disabled the disallow action so that we can watch for any unexpected fallout or false positive hits as a result of the changes I made. Any EFM is free to re-enable the disallow action if they feel that the changes I made did not result in any negative effects. If I did make any mistakes or cause issues, please let me know and I'll be happy to take a look. :-) Cheers - ~Oshwah~(talk) (contribs) 06:15, 8 September 2022 (UTC)Reply[reply]

Filters 887 and 890 and autocreateaccount[edit]

  • 887 (hist · log) ("Excessive repetition in usernames", public)
  • 890 (hist · log) ("Random typing in username", public)

@The Anome: Unless there is a consensus otherwise, I'm going to revert your recent changes to these filters. (Special:AbuseFilter/history/890/diff/prev/27523, Special:AbuseFilter/history/887/diff/prev/27522) Disallowing autocreation should be a last-resort measure for severe disruption. It's confusing and BITEy. First, if the user just follows an link, they're shown the logged-out view with no indication of what went wrong. They don't see the filter message unless it occurs to them to try to log in. And as I said at Wikipedia:Edit filter noticeboard/Archive 9 § We need to talk about filter 874, What are they supposed to do, create two accounts? Expose their IP on EF/FP/R? Ping an enwiki admin from meta? Given that these filters only stop mildly annoying, but often good-faith usernames, they should be limited to local account creation. That's not much more BITEy than being told "this username is already taken". Suffusion of Yellow (talk) 18:49, 24 August 2022 (UTC)Reply[reply]

Hmmm, so these are usernames, that if they were to edit - we would be blocking for username violations? — xaosflux Talk 18:54, 24 August 2022 (UTC)Reply[reply]
Probably some, but not all. And almost never hardblocking. I can't see blocking "Malayalam Malayalam Malayalam" at all. But "Matttttttttttttttttttttttttttttttttttttttty" is kind of difficult to ping without cutting-and-pasting, so maybe they'd be at least strongly encouraged to change their username. Even if they were blocked, they'd get a clear talk page message about what to do next, and an opportunity to appeal with "Hey, I've been editing foowiki for years and nobody has objected, would you reconsider?". Since the filter disallows creation, they can't say anything on enwiki at all without exposing their IP or creating another account. Suffusion of Yellow (talk) 19:12, 24 August 2022 (UTC)Reply[reply]
@Suffusion of Yellow is the largest problem here that "filters that are triggered by autocreateaccount, do not present the disallow message"? Not sure where it would display though? What happens to these users when they try to click log in? — xaosflux Talk 20:06, 24 August 2022 (UTC)Reply[reply]
@Xaosflux: I just tried disallowing (1014 (hist · log)) the name "Suffusion of Yellow alt 9" here, then creating that account on testwiki. When I come back to enwiki, I just get the usual logged out view with no message explaining why (but an attempt to create the account is logged). When I try to log in, I do get the filter message, but that's not really helpful, because there's still no convenient way to report a FP on enwiki.
I suppose we could direct them to meta:Special:GlobalRenameRequest, but what if they don't want to change it? How do they say "hey, can I keep this name please?" Suffusion of Yellow (talk) 20:30, 24 August 2022 (UTC)Reply[reply]
@Suffusion of Yellow we could send them to WP:UTRS, the same admins that could unblock them could allow the creation. — xaosflux Talk 20:43, 24 August 2022 (UTC)Reply[reply]
I guess, but that seems like overkill for the problem these filters are trying to solve. What's the backlog at UTRS?
I also forgot, there's another problem with disallowing account creation: If they don't try to log in and just want to read pages, they never know they're being filtered and can end up flooding the log with hundreds of hits. Frankly that's even a bit creepy privacy-wise; the whole world can see when they're online! Suffusion of Yellow (talk) 20:50, 24 August 2022 (UTC)Reply[reply]
The current UTRS backlog is: 2 appeals within a few hours. — xaosflux Talk 20:53, 24 August 2022 (UTC)Reply[reply]
Wow I can't believe that phab:T21161 is 13 years old and still waiting.... — xaosflux Talk 20:55, 24 August 2022 (UTC)Reply[reply]
According to that task, it was exploited in the wild 13 years ago. Suffusion of Yellow (talk) 21:03, 24 August 2022 (UTC)Reply[reply]
I agree that disallowing autocreate should be a last resort. Is/was there a known issue the disallowing aims to solve? firefly ( t · c ) 20:23, 24 August 2022 (UTC)Reply[reply]

Response by filter author: Firstly, I've reverted my changes on both filters; filters this powerful should not be controversial. However, autocreation has been explicitly used by vandals to avoid some filters, and I made this change to close the loophole. — The Anome (talk) 21:04, 24 August 2022 (UTC)Reply[reply]

Thanks. For the record, I have no objection to any log-only (or tagging) filter tracking autocreations. It's only logged once and then the account is created. Suffusion of Yellow (talk) 21:18, 24 August 2022 (UTC)Reply[reply]

Set filter 1085 to disallow[edit]

This is intended to stop a certain thing that compromised accounts do when they come out of the woodwork. I can't be checking Wikipedia very frequently right now, so if there are any objections please adjust or disable as needed. Suffusion of Yellow (talk) 21:15, 8 September 2022 (UTC)Reply[reply]

Someone please take a look at my comment at Special:Permalink/1109276246#Someonefromohio. PhantomTech[talk] 23:45, 8 September 2022 (UTC)Reply[reply]
It's back to log-only, but the closest you'll find to a "consensus" is here . Without spilling any BEANS, I'll say this has nothing to do with preventing good-faith changes, though that's an obvious side-effect. Suffusion of Yellow (talk) 20:00, 9 September 2022 (UTC)Reply[reply]
To clarify all my comments about consensus were related to the specific edit being disallowed and directed at the editor attempting the edit who was claiming there was consensus for that edit. I had and have no issue with there being consensus for this specific filter. PhantomTech[talk] 20:25, 9 September 2022 (UTC)Reply[reply]
Sigh. Completely mis-read that link and thought you were asking me. Thanks for the clarification. Suffusion of Yellow (talk) 20:31, 9 September 2022 (UTC)Reply[reply]
Probably should also note that, that because of a dumb typo of mine, the filter was stopping a much larger class of users than intended. That's fixed, in case the filter needs to be set to disallow again. Suffusion of Yellow (talk) 21:04, 9 September 2022 (UTC)Reply[reply]

"Chandler" mass attack/article hijacking[edit]

Last night there was an obviously coordinated mass attack (I suspect related to something off wiki) where numerous articles were hijacked and replaced with content about someone named "Christine Weston Chandler", who had nothing to do with any of the articles into which their biography was inserted. At first it was just articles related to the names "Chandler" and "Chris" but soon ventured out into completely unrelated articles (including Commonwealth realm and other geographic items). The attack was being carried out by multiple different IP addresses (no registered accounts as far as I know) and as soon as one IP was blocked, another one started hijacking the exact same content into a different page (this shows that the attack was coordinated between multiple people in some way... MediaWiki blocks Tor exit nodes and there is no way that any other ISP would allow rapid changing of IP addresses like that). I didn't actually read the biography of the person, because the mere fact that it was being hijacked into unrelated articles made it inappropriate regardless of the merits, and therefore I have no idea as to whether or not the subject is notable or not. However, most of the hijacking edits were subsequently deleted, so I'd guess that there was something objectionable in the content and would draw into question the notability of the subject. All this is essentially a TLDR to ask whether there is/could be a filter to prevent this sort of coordinated mass attack in the future? I'd think that it wouldn't have to be limited to this specific biography... perhaps some sort of filter to prevent against article hijacking altogether? (No idea if that's possible, just floating ideas). I would think that there'd also be a way to throttle the rapid speed of this kind of attack, and maybe start disallowing things after a certain limit is hit regardless of what content is actually being thrown around. Thoughts? Taking Out The Trash (talk) 22:09, 19 September 2022 (UTC)Reply[reply]

Just FYI, there's a lot of history on that individual — TheresNoTime (talk • they/them) 22:21, 19 September 2022 (UTC)Reply[reply]
@Taking Out The Trash, TheresNoTime, and ProcrastinatingReader: See 1217 (hist · log) (private, disallow + auto-report). Nearly revery recent hit from 1159 (hist · log) (public) was reverted, disallowed by another filter, or revdeleted, so I don't see the need for throttle right now. The few FPs can be dealt with. Suffusion of Yellow (talk) 22:02, 20 September 2022 (UTC)Reply[reply]
Not sure why I'm being pinged to view the details of a private filter, when the folks have explicitly said that they don't want me doing that. Though I wonder why this filter needs to be private? It's targeting one specific thing (I assume), and it's fairly obvious that the users involved had the hijack content saved somewhere else and were just copy and pasting, since applying revision deletion didn't stop the speed or scope of the most recent attack. If the offenders have the content saved off wiki anyway, what's the point in hiding the filter? Taking Out The Trash (talk) 23:43, 20 September 2022 (UTC)Reply[reply]
@Taking Out The Trash If someone understands how to read filter conditions, even to a small extent, and has access to those conditions it can be very easy to evade a filter. I think generally any filter targeting a specific person assumes that there's a likelihood that person is willing to put the effort in to evading the filter as they've already show they're willing to put the effort in to create a situation where a targeted filter is needed. As for why you were pinged, I assume it was as a courtesy to ensure you were aware of the rest of the reply, and possibly because SoY may not have known if you were an admin/EFM/EFH or not. PhantomTech[talk] 00:43, 21 September 2022 (UTC)Reply[reply]
@Taking Out The Trash: I was mostly alerting you the existence of 1159, which is public. If you enable email, I'll tell you what 1217 is doing. Honestly, I'm not sure if this is one person, or a raid of some sort. If it's many people, then possibly the filter can be made public; everyone will try the obvious thing, and then get bored and stop. But I want to see what's going on first. Suffusion of Yellow (talk) 02:21, 21 September 2022 (UTC)Reply[reply]
I've never really given much thought about email, because the reality is that I don't actually have an email address other than my work email. While I'm technically allowed to use my work account for personal business, I'm hesitant to do that, as it would increase my inbox traffic significantly and I don't want to miss important things. As I noted above, this has got to be several people engaged in an off-wiki coordinated attack (or "raid" as you put it). There's no way that one individual could change IP addresses as quickly as what was happening the other night, since MediaWiki blocks Tor exit nodes and even the most sophisticated VPN will have at least 30 seconds of lag time when changing "locations". The IPs were literally changing in 10 seconds - as soon as one was blocked, up popped another one to hijack the same content into a different page. That's also why I'm pretty certain that at least some of the people involved have the hijacked content saved off wiki somewhere, because the fact that revisions were being deleted didn't slow the speed of the attack at all. Taking Out The Trash (talk) 21:58, 21 September 2022 (UTC)Reply[reply]
Taking Out The Trash, I know of at least one another LTA who can switch IPs (mostly S. American and African providers) within seconds. Hijacked computers acting like proxies? Talking about hundreds of different addresses that got caught by my filters. Sounds scary, I know, but we should be ready for more of that. Ponor (talk) 06:07, 22 September 2022 (UTC)Reply[reply]