Wikipedia:Edit filter noticeboard: Difference between revisions
Someguy1221 (talk | contribs) →1000: re |
Someguy1221 (talk | contribs) →1000: re; indent |
||
Line 901: | Line 901: | ||
{{re|Someguy1221}} Is this still needed? It's not clear which LTA this is tracking. A very quick spot check suggests the usual mix of good-faith and bad-faith edits typical of IPs and new users. In any case, no hits in about a year, though I'm not sure if that's because of any active blocks. [[User:Suffusion of Yellow|Suffusion of Yellow]] ([[User talk:Suffusion of Yellow|talk]]) 21:35, 9 November 2022 (UTC) |
{{re|Someguy1221}} Is this still needed? It's not clear which LTA this is tracking. A very quick spot check suggests the usual mix of good-faith and bad-faith edits typical of IPs and new users. In any case, no hits in about a year, though I'm not sure if that's because of any active blocks. [[User:Suffusion of Yellow|Suffusion of Yellow]] ([[User talk:Suffusion of Yellow|talk]]) 21:35, 9 November 2022 (UTC) |
||
{{re|Suffusion of Yellow}} It looks like the two most active ranges for the LTA were blocked last year. There's probably no need for the filter anymore. [[User:Someguy1221|Someguy1221]] ([[User talk:Someguy1221|talk]]) 10:00, 31 December 2022 (UTC) |
:{{re|Suffusion of Yellow}} It looks like the two most active ranges for the LTA were blocked last year. There's probably no need for the filter anymore. [[User:Someguy1221|Someguy1221]] ([[User talk:Someguy1221|talk]]) 10:00, 31 December 2022 (UTC) |
||
===1001=== |
===1001=== |
Revision as of 10:00, 31 December 2022
Welcome to the edit filter noticeboard |
---|
Filter 384 — Pattern modified
Filter 1320 (new) — Actions: none; Flags: enabled,private; Pattern modified
Filter 1319 (new) — Actions: none; Flags: enabled,private; Pattern modified
Filter 54 — Pattern modified
Filter 1120 — Actions: tag
This is the edit filter noticeboard, for coordination and discussion of edit filter use and management. If you wish to request an edit filter, please post at Wikipedia:Edit filter/Requested. If you would like to report a false positive, please post at Wikipedia:Edit filter/False positives. Private filters should not be discussed in detail here; please email an edit filter manager if you have specific concerns or questions about the content of hidden filters. There are currently 333 enabled filters and 47 stale filters with no hits in the past 30 days. Filter condition use is ~1024, out of a maximum of 2000. ( ). See also the profiling data and edit filter graphs. |
Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13 |
This page has archives. Sections older than 10 days may be automatically archived by Lowercase sigmabot III. |
Condition limit
I'm not liking the look of this graph (live view). If that line touches 1000, then some of time, some filters (probably the highest-numbered ones) won't be active on every edit. I've already pruned out a few of "my" filters and will look for more. But now would be a good time to check "your" filters. Suffusion of Yellow (talk) 21:26, 18 October 2022 (UTC)
- Thanks for the heads up. I do think we should be culling more of the filters. Excluding anything edited in the last couple of months, I see there are active 'test' filters 'owned' by ProcrastinatingReader (
2), King of Hearts (201), TheresNoTime (1&773), Crow (861), Cyp (898), Cyberpower678 (915), ST47 (1019), QEDK (1027), Blablubbs (1166). Unless they step forward to claim them, I'll disable them. -- zzuuzz (talk) 22:11, 18 October 2022 (UTC)- Disabled 1 (as the last person to touch the main public test filter) and 773 — TheresNoTime (talk • they/them) 22:14, 18 October 2022 (UTC)
- @TheresNoTime: Mind moving it to another filter as it's relatively useful in catching erroneous pages or those that are in the wrong ns. --Minorax«¦talk¦» 08:11, 23 October 2022 (UTC)
- @TheresNoTime: <bump> --Minorax«¦talk¦» 04:50, 1 November 2022 (UTC)
- @TheresNoTime: Mind moving it to another filter as it's relatively useful in catching erroneous pages or those that are in the wrong ns. --Minorax«¦talk¦» 08:11, 23 October 2022 (UTC)
- Thanks for the ping. I've disabled mine. --Blablubbs (talk) 22:17, 18 October 2022 (UTC)
- It looks like Crow is inactive. 861 disabled. -- zzuuzz (talk) 22:28, 18 October 2022 (UTC)
- @Tamzin, 'TeZt' filter
1206. -- zzuuzz (talk) 22:40, 18 October 2022 (UTC) - Disabled mine (and marked
disabledfilters above). Κσυπ Cyp 07:43, 19 October 2022 (UTC) - Disabled mine as well (thanks for the ping). --qedk (t 愛 c) 10:58, 19 October 2022 (UTC)
- Thanks, I've disabled the remainding test filters. We should still review any others. -- zzuuzz (talk) 18:57, 20 October 2022 (UTC)
- Disabled 1 (as the last person to touch the main public test filter) and 773 — TheresNoTime (talk • they/them) 22:14, 18 October 2022 (UTC)
- Eyeballing the graph linked above (or just counting the |s by hand), it looks like 1094 (hist · log) (@Ohnoitsjamie:) is using about 60-90 conditions in the worst case. Most of that is from checks targeted at a few pages each. I've usually declined requests for single-page filters, because, well, if we have too many of them, we'll run out of conditions. Now you could reduce condition usage on most pages with a redundant check at the start:
equals_to_any(page_id, 1, 2, 3, 4, ...) & ( (equals_to_any(page_id, 1) & added_lines irlike ...) | (equals_to_any(page_id, 2, 3) & added_lines irlike ...) | (equals_to_any(page_id, 4) & added_lines irlike ...) ... )
- But that still could trip the condition limit on any the targeted pages. I have to wonder if protection (at some level) is a better choice for most of these pages. It's been my view that single-page filters should be used only if there's really a good reason to keep a page unprotected. Suffusion of Yellow (talk) 23:01, 18 October 2022 (UTC)
- I pruned a bunch of LTA conditions that seem to be dormant; also disabled another entire filter, which will hopefully help. OhNoitsJamie Talk 23:14, 18 October 2022 (UTC)
- @Suffusion of Yellow and Zzuuzz: Unsure if it'll be helpful, but I've got a bot job which could keep User:TNTBot/abusefilter-conditions up to date with the most recent condition usage (currently paused) — perhaps a template could be shown here/on Special:AbuseFilter if it approaches 1000 again? — TheresNoTime (talk • they/them) 12:46, 19 October 2022 (UTC)
- @TheresNoTime: Nice! If it's not too much trouble for you to maintain, might as well transclude it all the time. Suffusion of Yellow (talk) 20:54, 19 October 2022 (UTC)
- @TheresNoTime: can we not just implement that in AbuseFilter itself? Legoktm (talk) 21:57, 19 October 2022 (UTC)
- I was thinking it'd make a somewhat useful magic word... I've stopped the bot and I'll take a look at that tomorrow
— TheresNoTime (talk • they/them) 22:03, 19 October 2022 (UTC)
- The condition count is very dynamic and IMO a poor fit for a magic word that ends up getting parser cached, etc. I just meant having Special:AbuseFilter show a warning if you're close to the condition limit (like 80% or 90%). Legoktm (talk) 22:05, 19 October 2022 (UTC)
- Ah, makes sense, yes — TheresNoTime (talk • they/them) 22:09, 19 October 2022 (UTC)
- The condition count is very dynamic and IMO a poor fit for a magic word that ends up getting parser cached, etc. I just meant having Special:AbuseFilter show a warning if you're close to the condition limit (like 80% or 90%). Legoktm (talk) 22:05, 19 October 2022 (UTC)
- I was thinking it'd make a somewhat useful magic word... I've stopped the bot and I'll take a look at that tomorrow
- Would it be worth checking through the currently enabled filters, sorted by lowest hit count, to find any that are consuming conditions but not actually getting any hits? Though I can't see the private filters, there seems like there might be some low hanging fruit there in the public filters. For example, #1213 has never had a hit as far as I can tell but according to its statistics entry it consumes 2.2 conditions on average despite this.
- The other suggestion I'd have would be to look for duplicate filters. For example from the titles, it looks like filters #1159 and #1217 are tracking the same disruption. I can't confirm if this is the case beyond the titles however as 1217 is a private filter. Sideswipe9th (talk) 21:15, 19 October 2022 (UTC)
- See User:MusikBot/StaleFilters/Report. Unfortunately some filters get just enough hits (often entirely or mostly FPs) to avoid being listed there. E.g. 860 (hist · log), which I've just disabled. Not sure what's going with 1213; either that was never really an issue, or there's a typo in filter somewhere. If no one can spot anything wrong with it, I'll disable. 1159 and 1217 have different actions enabled, and are dealing with some active ongoing harassment, so I'll leave those for now. Suffusion of Yellow (talk) 03:03, 22 October 2022 (UTC)
- For 1213 the regex looks fine, it validates OK, and there's no spelling mistakes in the listed categories I can easily see. We could test the filter on testwiki if you want, and manually add those categories to a sample page to see if it gets a hit. But otherwise aside from the report that lead to its creation, it doesn't seem to have happened since. Sideswipe9th (talk) 22:52, 22 October 2022 (UTC)
- The stale filters report has one interesting entry that I can't see. Filter #729 hasn't had a hit in just under 7 years. Unfortunately it's a private one so I dunno how many conditions its consuming. Description says it's tracking a specific set of vandalism, so either that vandal has stopped or they've changed editing patterns? Sideswipe9th (talk) 23:00, 22 October 2022 (UTC)
- See User:MusikBot/StaleFilters/Report. Unfortunately some filters get just enough hits (often entirely or mostly FPs) to avoid being listed there. E.g. 860 (hist · log), which I've just disabled. Not sure what's going with 1213; either that was never really an issue, or there's a typo in filter somewhere. If no one can spot anything wrong with it, I'll disable. 1159 and 1217 have different actions enabled, and are dealing with some active ongoing harassment, so I'll leave those for now. Suffusion of Yellow (talk) 03:03, 22 October 2022 (UTC)
You know what? This haphazard approach is duplicating effort. Let's review them all! Leave your findings below: Suffusion of Yellow (talk) 02:19, 23 October 2022 (UTC)
- For some of the log-only ones (which we doubt anyone is monitoring), I'm inclined to disable and see if anyone complains? I know some people watch filters using MusikBot on IRC, but otherwise, the tooling to monitor edits that hit a log-only filter is shabby, and I get the feeling that only so many editors use it, such that many of these are entirely unmonitored (except perhaps if they're tagged and people are monitoring tags, or DatBot is reporting to AIV). ProcrastinatingReader (talk) 12:01, 23 October 2022 (UTC)
3
Obviously useful, no obvious optimizations. Leave it alone. Suffusion of Yellow (talk) 02:32, 23 October 2022 (UTC)
- Agreed. I can't see any way to optimise it. Sideswipe9th (talk) 18:08, 23 October 2022 (UTC)
5
Short-circuits at first line unless action=="move". Appears to still be a fairly common newbie mistake. Leave it alone. Suffusion of Yellow (talk) 02:32, 23 October 2022 (UTC)
11
48 of the last 50 edits that saved were reverted. Should this be merged into a disallowing filter, e.g. 260 (hist · log)? Something to consider. Suffusion of Yellow (talk) 02:32, 23 October 2022 (UTC)
12
Reordered the conditions a bit. Overlaps with other "bad words" and blanking filters, but considering how common both swearing and blanking are, probably justified. Suffusion of Yellow (talk) 02:57, 23 October 2022 (UTC)
- @Suffusion of Yellow: Is this supposed to be log-only? Last I checked I thought this was a disallowing filter (and IMO it should be). Taking Out The Trash (talk) 03:09, 26 October 2022 (UTC)
- @Taking Out The Trash: Yes, I sometimes switch filters to log-only when I've edited them and want to do something other than monitor the log for FPs, and I forgot to switch it back. That said zero hits have save successfully so far; everything has been stopped by another filter. So maybe it's not needed after all. I'll leave it log-only for now. Suffusion of Yellow (talk) 04:30, 26 October 2022 (UTC)
29
Overlaps a bit with 1060 (hist · log) ("Disallow CSD tag removal by page creator"), but it's helpful to have a tagging filter as a fallback in case of socks, etc. No obvious optimizations. Suffusion of Yellow (talk) 03:02, 23 October 2022 (UTC)
30
Not really sure what the best condition order is there, but should SC on most edits at the first line. Probably useful as a warn+tag fallback for less clear-cut cases than 12 (hist · log). Suffusion of Yellow (talk) 03:09, 23 October 2022 (UTC)
31
Pruned out a whole lot, which doesn't save conditions but at least improves readability and maintainability. Might regexify the rest. Were it not for the {{routemap}} exception this could be merged somewhere. Suffusion of Yellow (talk) 03:39, 23 October 2022 (UTC)
- My only concern about regexing the remaining lines would be that lines 10, 11, and 12 would require a lot of escape characters, which would I think impact on maintainability? Sideswipe9th (talk) 17:30, 23 October 2022 (UTC)
- With regex, it could be merged into 614 (hist · log). I'd probably remove lines 10-12 in that case; they only account for a handful of hits. I suspect ASCII art is less common these days; the people who remember Usenet are the parents of today's vandals. Suffusion of Yellow (talk) 22:40, 23 October 2022 (UTC)
33
This one possibly overlaps with #34, but that one is private so I cannot confirm. #33 tracks blanking in any talk page by a new or unregistered user. Unless there's something specific in #34, could these be merged? Sideswipe9th (talk) 17:45, 23 October 2022 (UTC)
- Aside from this, I'd maybe swap lines 2 and 3 so that we detect the page namespace immediately after we determine if it's a low edit count user. And then do the same composite condition as in filter #3 to detect blanking, just so that we have a consistent definition of what blanking is across filters. You could also maybe swap the total edit count check on line 1 with a user_groups check, though that could also widen the filter's initial check because of how autoconfirmed is granted. Sideswipe9th (talk) 17:51, 23 October 2022 (UTC)
- @Sideswipe9th: I put the namespace check first. In general any filter that only targets non-mainspace edits should do this; it will never use more than one condition on a mainspace edit (where most filters are using up conditions). After that, there isn't much point in micro-optimizing a non-mainspace filter. There's no overlap with 34 since 33 is specifically excluding user talk pages. Merging might be a bit tricky since the checks in 34 are very different, but it's something to consider. Let's first decide if we want to make 34 public (see next section). Suffusion of Yellow (talk) 22:53, 23 October 2022 (UTC)
- Interesting! I would have thought that the low user_editcount check would have had a lower hit rate than the page_namespace check.
- On the merge, if you check the notes the original intent of this filter was
Filter to prevent blanking of talk pages by non-registered users, except to their own user talk page
. That would account for line 5 which gets a hit if the name of the user making the edit is in the page title. However the notes also sayTweaking, user talk covered by filter 34.
This accounts for line 6, which explicitly excludes the User Talk namespace. So at one point, filters 33 and 34 duplicated each other and the duplication was removed by the filter creator. This raises two interesting points. One is to do with the merge as that could be a reason to support or oppose merging them, and the other is two possible optimisations we could make. - If the intent of this filter is to check against all talk page edits, except those in the user talk namespace, then should the second check not be to exclude user talk (namespace 3)? Or in other words, should line 6 not be moved to line 2? That way your first two conditions are "is talk namespace and is not user talk namespace". Alternatively if moving line 6 to line 2 would result in more hits, then it seems as though line 5 may be extraneous to the check, as it looks like the intent of that check is to ensure that a new/unregistered user blanking their own talk page is not caught by this filter. In theory, a user name should not appear outside of namespace 2 or 3 (user and user talk) right? Or do we have vandals/LTAs who create usernames that match article titles? Sideswipe9th (talk) 23:58, 23 October 2022 (UTC)
- re
I would have thought that the low user_editcount check would have had a lower hit rate than the page_namespace check
. To be clear, I'm talking about total worst-case usage, not the usage of any specific filter. If filter A ispage_namespace == 0 & ( /* N conditions */ )
and filter B ispage_namespace != 0 & ( /* M conditions */)
then the worst combined usage is 1 + max(N, M). Suffusion of Yellow (talk) 02:20, 24 October 2022 (UTC)- Aaaah! Got that now! Sideswipe9th (talk) 02:22, 24 October 2022 (UTC)
- re
- @Sideswipe9th: I put the namespace check first. In general any filter that only targets non-mainspace edits should do this; it will never use more than one condition on a mainspace edit (where most filters are using up conditions). After that, there isn't much point in micro-optimizing a non-mainspace filter. There's no overlap with 34 since 33 is specifically excluding user talk pages. Merging might be a bit tricky since the checks in 34 are very different, but it's something to consider. Let's first decide if we want to make 34 public (see next section). Suffusion of Yellow (talk) 22:53, 23 October 2022 (UTC)
34
- 34 (hist · log) ("New or unregistered user blanking someone else's user or user talk page", private)
Comment: Why is this filter private but 33 is public? That makes no sense... they're targeting the same type of behavior (just 33 is looking at main space and 34 is looking at userspace). Unless there's some sort of anti-harassment issue that necessitates the userspace filter being private, I would think that it should be made public or merged with 33. Taking Out The Trash (talk) 19:09, 23 October 2022 (UTC)
- I recall asking the same thing myself once, but now I can't remember the answer. This was created way before my time and none of the major maintainers have edited in months. There are a few exceptions that a LTA might exploit, but the same could be said about almost any public filter. I'll ping NawlinWiki (who marked it private) in case they're still lurking. Also pinging zzuuzz and MusikAnimal who might have some memory of why this is private. Suffusion of Yellow (talk) 22:58, 23 October 2022 (UTC)
- This dates back to the LTAs of Hamish Ross and Grawp (etc), with all their death threats and stuff, and the fact that they gamed the filters. That's its primary purpose: threats and gaming. Hamish still surfaces occasionally, and Grawp is busy with other things, but these LTAs are relatively inactive in this department at this time. Is it stopping other problems? I don't rightly know. Could it be public or merged? probably. I think it is usually a bad idea to make the history and logs of a filter which has been private, public. -- zzuuzz (talk) 23:18, 23 October 2022 (UTC)
- Also note that 294, 478 and 739 are somewhat related. -- zzuuzz (talk) 23:51, 23 October 2022 (UTC)
- If the concern is making the history of a private filter public, would merging the still relevant parts of the private filter that are not otherwise sensitive into a related public filter that does not have the same history, and then disabling the private filter not be a suitable alternative? That way the history that needs to be private remains so, and the active parts of the filter are merged elsewhere hopefully reducing the number of conditions used. Sideswipe9th (talk) 00:42, 24 October 2022 (UTC)
- Yes, that's what I meant. If it's decided to go public, it could even be posted here. -- zzuuzz (talk) 07:04, 24 October 2022 (UTC)
- This dates back to the LTAs of Hamish Ross and Grawp (etc), with all their death threats and stuff, and the fact that they gamed the filters. That's its primary purpose: threats and gaming. Hamish still surfaces occasionally, and Grawp is busy with other things, but these LTAs are relatively inactive in this department at this time. Is it stopping other problems? I don't rightly know. Could it be public or merged? probably. I think it is usually a bad idea to make the history and logs of a filter which has been private, public. -- zzuuzz (talk) 23:18, 23 October 2022 (UTC)
- I recall asking the same thing myself once, but now I can't remember the answer. This was created way before my time and none of the major maintainers have edited in months. There are a few exceptions that a LTA might exploit, but the same could be said about almost any public filter. I'll ping NawlinWiki (who marked it private) in case they're still lurking. Also pinging zzuuzz and MusikAnimal who might have some memory of why this is private. Suffusion of Yellow (talk) 22:58, 23 October 2022 (UTC)
39
- Logic wise this one looks OK to me. Not seeing any obvious optimisations that could be made. Were it not for the need to specifically track a subset of page titles, and that there are some non offensive but still contextually libellous words in the pattern, I'd suggest looking at merging it with a similar obscenity filter like #380. You could potentially merge with 189 though, as it also tracks libel, but for a different subset of pages? Sideswipe9th (talk) 18:33, 24 October 2022 (UTC)
46
- Can't see any obvious optimisations to the logic, unless line 3 is extraneous? This only tracks a single type of vandalism however, would it be worth merging the pattern into another filter like 614? Or is there a reason to track this separately from other common vandal terms? Sideswipe9th (talk) 19:07, 24 October 2022 (UTC)
50
It's not clear why the length(rmwhitespace(added_lines)) > 12
is there. Testing (at 1014 (hist · log)) if it can be removed safely. Suffusion of Yellow (talk) 22:42, 28 October 2022 (UTC)
51
52
I recently did a bit of a cleanup here. I'm looking to merge the remainder elsewhere (or find where it's already merged). This is a useful filter to have around for occasional problems, but I'd like to see it disabled at this time. -- zzuuzz (talk) 18:57, 25 October 2022 (UTC)
- Actually, I might just re-task it to the current issue. Anyway, consider this one under active review. -- zzuuzz (talk) 19:17, 25 October 2022 (UTC)
- This one should be public as a general vandalism filter. Or, if it's not a general vandalism filter looking at edit summaries for vandalism across the board, it should be renamed. Taking Out The Trash (talk) 03:10, 26 October 2022 (UTC)
- From its origin to this day, this filter has been tracking/blocking a small number of filter-aware LTAs, beginning with Grawp. In its current form it's highly specialised, not general. Renaming it to 'LTA edit summary vandalism' would probably be more accurate (but really?). It's not a good candidate for being public (though like I say I'd like to see some of it merged). -- zzuuzz (talk) 03:22, 26 October 2022 (UTC)
- I'm a huge stickler for having filter names being as accurate as possible without revealing private information, especially for hidden filters, as it makes patrolling for non-EFHs ten times easier if the filter titles are accurate. If a filter is targeting specific LTA behavior, the title should have "LTA" in it (though not just a random four digit number afterwards - actually a basic description of the behavior being targeted). So in this case, "LTA edit summary vandalism" would be a perfect name for the filter. Unless a given filter is targeting specific and active LTA behavior, it should be made public (or at least disabled/deleted). Since EFH permissions aren't being given out as freely as I think was envisioned based on the history of WP:EFH, the least we can do is to limit the number of private filters and only hide them when absolutely necessary. Taking Out The Trash (talk) 23:02, 27 October 2022 (UTC)
53
54
- I think this one is largely OK. It'd be worth checking though if this one duplicates anything in filter 499, which I can't check. There's a coding style niggle I have, where if I were to write this one I'd put line 3 into a set of parentheses with line 9, so that the variable is only declared when the first and second conditions get a hit. It's not a condition limit problem, but instead I'm fairly certain this will be creating unnecessary garbage for the garbage collector when condition 1 is true and condition 2 is false, as that variable will need to be disposed of even in circumstances where it's not evaluated. Sideswipe9th (talk) 19:35, 24 October 2022 (UTC)
58
Took out some voodoo that was claiming to prevent "Wikipedia" from "hanging" on large edits. Suffusion of Yellow (talk) 03:06, 24 October 2022 (UTC)
59
61
68
Is this one really even necessary anymore? I'd guess that this dates back to the days when autoconfirmed wasn't required to move pages, and also when page-move vandalbots were a thing (I think the ability for the filter to revoke autoconfirmed status dates back to around the same time). But seeing that new users haven't been able to move pages at all for many years now, and page move vandalbots aren't really a thing anymore, I'd wonder if this is still required (can't make any firm conclusions since the filter is private). Taking Out The Trash (talk) 03:13, 26 October 2022 (UTC)
- I'll just say it goes beyond autoconfirmed. Page move vandals are unfortunately still a thing. Take Special:Contributions/Grasshopper49058 for example. -- zzuuzz (talk) 03:27, 26 October 2022 (UTC)
- That's not a "page move vandal" though - that's a compromised account that just happened to engage in page move vandalism. What I'm talking about are the (semi-)automated page move vandalbots that would disruptively move dozens if not hundreds of pages within a short time frame, back when autoconfirmed wasn't required to move pages. I think that's when the ability for the filter to revoke autoconfirmed status had its heyday, but I was under the impression that this type of automated attack wasn't really a thing anymore since there is now a software restriction on moving pages. Taking Out The Trash (talk) 23:06, 27 October 2022 (UTC)
79
80
98
Does this serve a purpose anymore? WP:ACPERM has cut down on the mainspace crud. Special:NewPagesFeed and Special:NewPages both list the article size. Special:NewPages even has a max size option. Suffusion of Yellow (talk) 03:26, 24 October 2022 (UTC)
- I still find it useful to help identify potential WP:A1 situations, and it also will often catch things like malformed redirects. Whenever I see hits for this filter, I put the page on my watchlist to see if it is expanded, and, if not, will tag it for deletion. It seems to be 50-50 as to whether it actually gets deleted or gets moved to draftspace and the redirect deleted, but regardless it gets the incomplete stub out of the main space. Taking Out The Trash (talk) 03:16, 26 October 2022 (UTC)
102
Why is this private? Seems like another general vandalism filter, though in this case looking for vandalism in usernames rather than edits. Having the general username filters (as opposed to specific filters targeting the individual username patterns of LTAs) hidden makes it difficult for any non-admins who work UAA and/or patrol the logs for inappropriate usernames. IIRC the instructions at the bottom of the UAA header even told patrollers to monitor the logs of this filter and several other private username filters for many years, until this was finally fixed fairly recently. Taking Out The Trash (talk) 03:22, 26 October 2022 (UTC)
- Renamed to "LTA account names". There are a few probably) non-LTA terms in there, but it seems to be mostly LTA-related. Suffusion of Yellow (talk) 23:01, 28 October 2022 (UTC)
113
117
132
135
139
What exactly is "fixed position" vandalism? Is this a type of LTA behavior? Or is it a type of vandalism in general? If the latter, the filter should be made public. If the former, it could probably be left as is - I think the title is descriptive/accurate enough. Taking Out The Trash (talk) 23:08, 27 October 2022 (UTC)
- You could class this as LTA behaviour. -- zzuuzz (talk) 05:21, 28 October 2022 (UTC)
148
149
164
172
174
180
189
220
225
- Seems like this would be best merged to 384. Unless there is some specific reason not to? Logs of users who have tripped the filter recently:[1][2][3][4][5][6][7][8][9][10][11] Mako001 (C) (T) 🇺🇦 06:23, 26 November 2022 (UTC)
231
Why is there a question mark at the end of stringy := "[\p{L}\p{N}]{50,}?";
and shouldn't finding the first 50 be enough, i.e. {50}
(if it makes any difference performancewise)? Ponor (talk) 07:14, 31 October 2022 (UTC)
- @Ponor: I doubt it makes a difference in performance. But
{50}
is more readable, so I've made that change. Suffusion of Yellow (talk) 23:19, 25 November 2022 (UTC)
242
How common is this type of disruption/vandalism? Is this something that routine drive-by vandals will engage in? Or is this a specific LTA filter? If the latter, the title needs pruning/adjusting, because right now it reads like a general filter targeting a specific type of vandalism that any random drive-by troll could engage in. If the former, this should be made public as a general vandalism filter that's not targeting any specific LTA case(s). Taking Out The Trash (talk) 23:12, 27 October 2022 (UTC)
- At least a couple LTAs I'm familiar with still do this sort of nonsense, including to impersonate sysops and other established users. JavaHurricane 06:39, 3 November 2022 (UTC)
247
Why should there be both a "warn" and "disallow" function? AKK700 03:01, 31 October 2022 (UTC)
- Good catch, see edit request at MediaWiki talk:Abusefilter-disallow-email. (Ping Primefac.) Suffusion of Yellow (talk) 04:07, 31 October 2022 (UTC)
249
260
264
Do we really need an edit filter to track vandalism to specific pages? Isn't that what page protection is for? Taking Out The Trash (talk) 02:30, 28 October 2022 (UTC)
279
And here we have yet another general vandalism filter that's private which shouldn't be. This one is tracking a very common sign of vandalism, namely the action of repeatedly attempting to save a page despite an edit filter warning or disallowment. I've actually seen this quite a bit - deliberately triggering the edit filter over and over again with the goal of flooding the log seems to be one common type of vandalism across the board. Hits from this filter raise a red flag over users who may be engaging in this type of disruption. There is zero reason why this kind of filter needs to be private - anything LTA-specific currently in this filter should be migrated into whichever private filter is relevant to the LTA in question anyway. Taking Out The Trash (talk) 02:33, 28 October 2022 (UTC)
- There is about a 50% chance that the edit is being prevented by a private filter. Hence private information would become public if this filter was public. See archive. Publicly visible logs are still available for these edits. -- zzuuzz (talk) 05:15, 28 October 2022 (UTC)
294
Could probably be merged into one of the other filters that already targets inappropriate language/bad words across multiple namespaces. Taking Out The Trash (talk) 17:40, 30 October 2022 (UTC)
- May be an LTA filter. If so, can this be reanmed to something more appropriate? Mako001 (C) (T) 🇺🇦 06:50, 26 November 2022 (UTC)
316
There are numerous good reasons why a subtle change to an article would be necessary. Of course, this is also a common method of sneaky vandalism. Nonetheless, it seems to be a common enough vandalism pattern that I don't think it's specifically LTA related. A wide variety of drive-by vandals will try to fly under the radar by being sneaky about what they are vandalizing instead of making it painfully obvious. Taking Out The Trash (talk) 17:39, 30 October 2022 (UTC)
- That appears to be a narrowly targeted LTA filter, actually. But the SPI page of the user mentioned at the beginning of the notes hasn't had a sock reported since 2010. Disabled. Suffusion of Yellow (talk) 03:10, 31 October 2022 (UTC)
320
This one should be expanded to include usernames... there have been several cases of inappropriate account creations containing "Your Mom" vandalism that I thought the filter would've stopped but didn't. Taking Out The Trash (talk) 17:37, 30 October 2022 (UTC)
- Example from tonight, usernames like Special:Contributions/Urmumisgay20001 should be blocked by this filter. Taking Out The Trash (talk) 23:06, 14 November 2022 (UTC)
- I think that it is generally best to avoid having filters on usernames unless absolutely necessary. It makes it easier for admins to decide to block a vandal if the username is enough to block on sight. If they try to create "Urmomisadouche69" get told that it isn't acceptable, so create "Newuser582", that makes everyones life harder, not easier. If the username is just a nondescript generic username, AGF and not BITE-ing them means that they tend to waste more patroller and admin time than if they were using names like "Amongus69420urmom", where the username makes their intent clear. By using such obvious usernames, they do everyone a favour. Mako001 (C) (T) 🇺🇦 06:48, 26 November 2022 (UTC)
323
This one is obvious. I don't see anything to do here. -- zzuuzz (talk) 05:48, 26 October 2022 (UTC)
339
- 339 (hist · log) ("Claims of homosexuality, bisexuality, or transexuality in a BLP", public)
- This edit filter should probably be renamed to
Claims of sexual orientation or gender in a BLP
and probably broadened (include more identities) or tightened (remove terms like bisexuality that probably aren't common among vandals) as needed. –MJL ‐Talk‐☖ 04:36, 28 October 2022 (UTC)- Agree, at the very least because I've never heard of "transexuality" (did the EFM who create it mean transgender?) casualdejekyll 00:58, 6 December 2022 (UTC)
- @Casualdejekyll: These times they are a-changing. Anyway, fixed the filter to match the more common spelling of "transsexual", and changed the title to MJL's suggestion. @MJL: Since this is a tag-only filter, I'd rather include a few more words than remove the uncommon ones. Any ideas? Suffusion of Yellow (talk) 23:06, 9 December 2022 (UTC)
- @Suffusion of Yellow (Appreciate the ping) It depends on the goal. If you want to include terms that could be abused while also being descriptive;
Queer
(also known asgenderqueer
),non-binary
(also spellednonbinary
), andneopronouns
(This is meant for BLPs where someone says "X uses neopronouns"). If you want just an exhaustive list of identities that are semi-likely to come up, I can also provide that. –MJL ‐Talk‐☖ 05:13, 10 December 2022 (UTC)
- @Suffusion of Yellow (Appreciate the ping) It depends on the goal. If you want to include terms that could be abused while also being descriptive;
- @Casualdejekyll: These times they are a-changing. Anyway, fixed the filter to match the more common spelling of "transsexual", and changed the title to MJL's suggestion. @MJL: Since this is a tag-only filter, I'd rather include a few more words than remove the uncommon ones. Any ideas? Suffusion of Yellow (talk) 23:06, 9 December 2022 (UTC)
- Agree, at the very least because I've never heard of "transexuality" (did the EFM who create it mean transgender?) casualdejekyll 00:58, 6 December 2022 (UTC)
- This edit filter should probably be renamed to
345
346
351
354
364
365
- I think this one fits an important niche between other filters, even if most of what it picks up is straightforward blanking. It's well optimised. -- zzuuzz (talk) 19:29, 25 October 2022 (UTC)
380
- Noting this before I've done a check on the logic. I've got a suggestion for improving the regex on this filter. On line 3 swap
\bPEDO(?:PH|F)ILE
for\bPA?EDO((?:PH|F)ILE)?
. This will allow the filter to detect both the British variant of paedophile, and also the commonly used contraction of the word. Spotted this when looking at 39 which matches on both spelling variants. There may be other string matches that could be improved in the regex as well, I've not done an exhaustive look. Sideswipe9th (talk) 18:47, 24 October 2022 (UTC)- Thanks, I've made that change. No comment on the rest of it. -- zzuuzz (talk) 05:09, 26 October 2022 (UTC)
384
391
397
420
About 3/4 of hits also trip 33 (hist · log); only "independently" stopped 15 hits edits this month. This can't be merged with 33 because of the throttle. Set to log-only to see if the throttle was really needed after all. Suffusion of Yellow (talk) 04:54, 26 October 2022 (UTC)
- Oh, forgot that 33 is warn-only and this is disallow. Still, worth seeing if the throttle is needed. Suffusion of Yellow (talk) 04:55, 26 October 2022 (UTC)
425
432
464
466
Can probably merge and optimise this, 794 (hist · log) and 974 (hist · log) ProcrastinatingReader (talk) 03:42, 30 October 2022 (UTC)
478
491
499
547
550
554
This shouldn't exist. AFAIK the community only allows blocking sources per the Wikipedia:Spam blacklist process. Filters are used for warning on their use after the deprecation process or if they're self-published. I previously made a request to get it added to the spam blacklist but that never happened. Going to disable this filter and re-make the request to add to spam blacklist. ProcrastinatingReader (talk) 11:38, 23 October 2022 (UTC)
- Yeah that's a good call I think. Could you take a look at 559 and 1141? They're both private filters, so I can't see em, but 559 is titled "archive.is additions", and 1141 is "OpenSea spam links". I suspect 559 is tracking specific set archive.is URLs that the blocklist can't handle, however for 1141 I believe OpenSea is already on the spam blocklist. Unless that's tracking a specific subset of OpenSea URLs, it might be redundant?
- I also took a glance at the public filters 54, 1030, 1043, 1045, and 1132 as those have similar titles to 554's actions. Those all appear to be OK, as they're just tracking, warning, and/or tagging edits. I suspect 1016 is also probably fine, even if it's a blocking filter (it's private so I can't confirm), because my understanding is that the spam blocklist only blocks http/s URIs and not others like file. Sideswipe9th (talk) 01:22, 24 October 2022 (UTC)
- Forgot to reply here too, but I'd disabled 559 and 1141 and made them both public (noted in their sub-sections). Thanks for the note. ProcrastinatingReader (talk) 11:03, 11 December 2022 (UTC)
559
Disabled - don't see this having any purpose now. c.f. the filter notes, also per notes it seems any useful purpose has been taken over by the spam blacklist. I also think this could be made public but haven't done that. ProcrastinatingReader (talk) 21:37, 26 October 2022 (UTC)
579
597
600
602
Required for various ArbCom/DS purposes, particularly tracking whether a user has been given a DS alert. ProcrastinatingReader (talk) 21:43, 26 October 2022 (UTC)
- Would be nice if we could set this one not to warn. I don't find the warning helpful. Just adds extra clicks, and messes up user scripts. On the off chance that someone does warn someone twice in a year instead of once, doesn't seem like a huge deal. –Novem Linguae (talk) 06:58, 28 October 2022 (UTC)
- That would probably need to be discussed over at ArbCom, though I agree that it can be a pain. Mako001 (C) (T) 🇺🇦 06:37, 26 November 2022 (UTC)
614
627
- 627 (hist · log) ("Promotional text added by user to draft in own user(-talk) page or in draft namespace", public)
630
No obvious optimizations. No opinion on how useful this is, but does it really need to be private? I can't imagine anyone gaming the check on line 2 just to avoid a tag. Suffusion of Yellow (talk) 23:12, 29 October 2022 (UTC)
- For what my $0.02 is worth, if all the filter is doing is tagging new users moving user pages to mainspace, the "gaming" potential is clearly and obviously low casualdejekyll 01:49, 6 December 2022 (UTC)
- Marked public. By "gaming" I was referring to the
user_editcount < 200
check, but that just seems like too much trouble. We can always change it to extendedconfirmed if needed. Suffusion of Yellow (talk) 22:41, 9 December 2022 (UTC)
- Marked public. By "gaming" I was referring to the
631
633
636
639
642
643
655
657
664
667
Renamed to "WP:LTA/BKFIP". Otherwise, no changes. I check this one regularly; while most edits are FPs, the ones that aren't often lead to a new sock busily stirring up drama at ANI. Suffusion of Yellow (talk) 21:46, 7 November 2022 (UTC)
680
686
694
702
711
712
716
- Is there any reason why this isn't at least set to like, tag or something? I can't see any valid reason for an unconfirmed account to perform such an action. casualdejekyll 01:59, 6 December 2022 (UTC)
- Bumping, pinging @Suffusion of Yellow. Virtually every hit that does get saved ends up reverted. This should at least be a warn+tag filter 137a (talk) 15:23, 12 December 2022 (UTC)
- @Casualdejekyll and 137a: FWIW only 7 of the last 500 hits were adding the templates, and the rest were removing the templates. And it looks like most of the removals were just generic vandalism, where the vandal incidentally blanked out the part or all of the lead section. One concern with a disallowing filter is that it will make it impossible for non-autoconfirmed editors to revert anyone who slips past the filter (e.g. because of the
edit_delta
. Added a tag for now. Suffusion of Yellow (talk) 22:05, 16 December 2022 (UTC)
- @Casualdejekyll and 137a: FWIW only 7 of the last 500 hits were adding the templates, and the rest were removing the templates. And it looks like most of the removals were just generic vandalism, where the vandal incidentally blanked out the part or all of the lead section. One concern with a disallowing filter is that it will make it impossible for non-autoconfirmed editors to revert anyone who slips past the filter (e.g. because of the
- Bumping, pinging @Suffusion of Yellow. Virtually every hit that does get saved ends up reverted. This should at least be a warn+tag filter 137a (talk) 15:23, 12 December 2022 (UTC)
718
733
735
738
739
This could probably be part-merged (somewhere?) and disabled. -- zzuuzz (talk) 05:57, 28 October 2022 (UTC)
752
753
The math here is off by a factor of 2:
edit_delta == -( rcount("\[\[", removed_lines) + rcount("\]\]", removed_lines) ) &
rcount("\[\[", removed_lines) > rcount("\[\[", added_lines)
We're tagging edits which remove exactly half of the wikilinks on the touched lines. That can't possibly have been the intention.
This could be fixed with:
edit_delta < 0 &
edit_delta == 2 * (rcount("\[\[|\]\]", added_lines) - rcount("\[\[|\]\]", removed_lines))
If this was a recent error, I'd just fix it. But no one, including me, noticed this in six and half years! So I don't think anyone cares much about tracking this kind of edit. And I suspect the "fix" will create lots of AbuseLog spam. Disabled, until someone objects. (Courtesy ping MusikAnimal) Suffusion of Yellow (talk) 04:48, 26 October 2022 (UTC)
- I think my involvement with this filter was solely to make optimizations. No objection to disabling, and thanks for starting this cleanup effort! Note also (in case you/others didn't know) the stale filters report. — MusikAnimal talk 10:08, 26 October 2022 (UTC)
762
766
767
768
I think this filter is used to prevent unregistered users from removing reports from AIV, in the same way that filter 788 filters out IPs removing reports from WP:RFPP/I to avert page protections and prevention of vandalism. This filter is private and the RFPP filter is not. Is this filter or 984 targeted at LTAs or sock puppets of blocked or banned users? AKK700 18:46, 31 October 2022 (UTC)
- Yes, there's some LTA stuff going on there, and there are many vandals who would like to vandalise AIV, including anyone who finds themselves on it. It's a bit more complicated than the RFPP filter. AIV also requires a high degree of resilience, in a different league to even RFPP. One LTA in particular - one of the filter's primary subjects - has been seen recently. But having said that, it probably needs to be looked at a bit closer. Now you mention it, it's possible there could be a merge with 984, but then that may be overly complicated. 984 covers some other pages, and although there are some things in common, it would probably still need rules per page - which gets messy in a hurry. -- zzuuzz (talk) 22:37, 2 November 2022 (UTC)
777
782
783
- 783 (hist · log) ("Adding Template:Persondata", public)
- Is this still worth tracking? I know it still gets hits, but it uses 3.9 conditions right now. –MJL ‐Talk‐☖ 04:56, 28 October 2022 (UTC)
- Disabled. According to the notes, this is to prevent
old school users from readding {{persondata}}
. What it's actually tripping on is people reverting biography pages to ancient revisions (for many reasons, but often to remove copyvios or accumulated spam). That's probably going to reintroduce all sorts of deprecated crud, so I don't see the need to single out this one template. I suppose we could create a new filter warning about redlinked templates in general, but that might be expensive, as it would need to checknew_html
on every edit, or at least every edit that adds a template. Suffusion of Yellow (talk) 22:32, 28 October 2022 (UTC)
- Disabled. According to the notes, this is to prevent
- Is this still worth tracking? I know it still gets hits, but it uses 3.9 conditions right now. –MJL ‐Talk‐☖ 04:56, 28 October 2022 (UTC)
788
793
794
797
798
803
Created after this RFC. No obvious optimizations. Suffusion of Yellow (talk) 22:32, 29 October 2022 (UTC)
806
Renamed "New account unusual activity" because good-faith editors aren't going to like being called "suspicious". Tidied a bit. Otherwise not seeing much to do. Definitely LTA-related so should stay private. Suffusion of Yellow (talk) 22:28, 29 October 2022 (UTC)
- I've ever only seen this filter trip under two circumstances: when a user is trying to game autoconfirmed or extended confirmed by making rapid-fire pointless edits in their userspace, and when a brand-new user creates personal JavaScript/CSS pages before being autoconfirmed. Other than those two circumstances - the first of which is worthy of monitoring, the second of which is more often than not a false positive, I don't think I've ever seen any hits from this filter. Taking Out The Trash (talk) 16:33, 4 November 2022 (UTC)
809
812
815
826
828
833
- 833 (hist · log) ("Newer user possibly adding unreferenced or improperly referenced material", public)
835
837
846
847
This LTA is still active and the filter useful. I think it's optimised OK, but you're welcome to review that. -- zzuuzz (talk) 21:53, 23 October 2022 (UTC)
850
856
862
864
867
868
869
871
874
878
881
885
887
889
890
This is one of many filters where we're saying
(
user_rights ? /* T230256 workaround */
!('override-antispoof' in user_rights) :
true
)
instead of just
!('override-antispoof' in user_rights)
This doesn't use any extra conditions, but it's an ugly hack. If I'm reading phab:T230256 correctly, the workaround is no longer needed; the change that caused this problem was reverted and user_rights
will just be null
for logged-out account creations. I plan on removing this workaround code from all the filters, but double-checking first with @Daimona Eaytoy: if that's a good idea. Suffusion of Yellow (talk) 23:57, 29 October 2022 (UTC)
- @Suffusion of Yellow: Yes, it should be possible to remove it. --Daimona Eaytoy (Talk) 13:11, 1 November 2022 (UTC)
891
892
894
901
Disabled. "Drumpf" is stopped by 614 (hist · log); this was just to give a friendlier message to those who installed the "Drumpfinator" browser extension. But most recent attempts look deliberate to me. I can't even find the original extension in the Chrome Store, though a few knockoffs exist. Suffusion of Yellow (talk) 02:33, 24 October 2022 (UTC)
906
909
916
917
@Cyberpower678: You previously objected when I merged this into a log-only filter. Any objection if I merge it into a disallowing filter instead? He might notice that we've disabled this filter, but he'll still get the same old message if he tries to add his name. Suffusion of Yellow (talk) 21:39, 9 November 2022 (UTC)
- Given the fairly low hit rate, I think this can actually made log-only. —CYBERPOWER (Chat) 21:44, 9 November 2022 (UTC)
- Are we sure the low hit rate isn't just because he knows there's a filter? Suffusion of Yellow (talk) 21:56, 9 November 2022 (UTC)
- Actually, you know what, the false positive rate is really low, so let's just keep it to disallow and merge it.—CYBERPOWER (Around) 16:18, 10 November 2022 (UTC)
- Are we sure the low hit rate isn't just because he knows there's a filter? Suffusion of Yellow (talk) 21:56, 9 November 2022 (UTC)
921
923
- Might be able to be merged with 793? Mako001 (C) (T) 🇺🇦 07:13, 26 November 2022 (UTC)
926
927
LTA still (barely) active, though it's clear no one is monitoring the log as none of the users are blocked. (Or are those FPs...?) @Kuru: Any objection if I merge this into 579 (hist · log). Or if those really are FPs, just disable it? Suffusion of Yellow (talk) 00:13, 30 October 2022 (UTC)
- @Suffusion of Yellow: Some of those appear to be positive positives, but they don't appear to be particularly active. I can't even remember the long lost grudge here, so this is an opportunity to disable and cover with a thin layer of soil. Sam Kuru (talk) 22:51, 2 November 2022 (UTC)
- @Kuru: Thanks, disabled. Didn't merge, but you do can that if you want. Suffusion of Yellow (talk) 21:49, 7 November 2022 (UTC)
928
930
935
936
937
942
What's the reason for this? Is this still being monitored? DatGuyTalkContribs 20:28, 13 November 2022 (UTC)
- Its main purpose is related to checking individual admin activity, in relation to inactivity de-sysops. @Xaosflux: to opine about its usefulness. -- zzuuzz (talk) 20:34, 13 November 2022 (UTC)
- I still use it as well, also allows easy transparency for anyone to ensure that admins are following the protection policy and only editing through protection when appropriate. — xaosflux Talk 20:48, 13 November 2022 (UTC)
954
Disabled, LTA seems to have been inactive for the last two years or so. Courtesy ping JJMC89 and Galobtter. (zzuuzz I think you're already watching...) Suffusion of Yellow (talk) 00:27, 30 October 2022 (UTC)
957
958
960
961
Disabled. Looking at only the edits with saved changes, there's a clear spree from the LTA in October 2019 but after that nearly everything has been disallowed by other filters. Courtesy ping @Crow and Beyond My Ken:. Suffusion of Yellow (talk) 21:36, 7 November 2022 (UTC)
963
- 963 (hist · log) ("LTA 963", private)
- I check this one regularly and find it useful. Spicy (talk) 12:41, 23 October 2022 (UTC)
964
965
Although not strictly an LTA filter, it does prevent some LTAs, so should remain private. ProcrastinatingReader (talk) 15:04, 7 November 2022 (UTC)
970
971
973
974
979
980
981
982
984
Effective, optimised, relevant, and worthwhile. No FPs worth bothering about. (though it's slightly misnamed). -- zzuuzz (talk) 05:58, 23 October 2022 (UTC)
986
I claim this filter and check it regularly. It's still generating relevant hits over a relevant time period. I can't think how it can really be optimised. But you're welcome to review it anyway. -- zzuuzz (talk) 04:54, 23 October 2022 (UTC)
987
989
994
996
LTA is bordering on inactive at this time, though they're called 'long' for good reason. MO check is pretty much optimised with no FPs. Possible candidate for disabling. -- zzuuzz (talk) 05:10, 23 October 2022 (UTC)
1000
@Someguy1221: Is this still needed? It's not clear which LTA this is tracking. A very quick spot check suggests the usual mix of good-faith and bad-faith edits typical of IPs and new users. In any case, no hits in about a year, though I'm not sure if that's because of any active blocks. Suffusion of Yellow (talk) 21:35, 9 November 2022 (UTC)
- @Suffusion of Yellow: It looks like the two most active ranges for the LTA were blocked last year. There's probably no need for the filter anymore. Someguy1221 (talk) 10:00, 31 December 2022 (UTC)
1001
This is part of MusikAnimal's bot, so should be left enabled even if no one is checking the log. Suffusion of Yellow (talk) 21:28, 9 November 2022 (UTC)
- That bot died a while back and I haven't gotten around to fixing it. I think it's only me that's using it anyway, so I've disbaled the filter for now. However I do intend to fix the bot, as well as make it usable by others (similar to User:MusikBot/AbuseFilterIRC), so I do intend to re-enable this eventually. — MusikAnimal talk 22:03, 9 November 2022 (UTC)
1007
Noting that ST47 has disabled this. Suffusion of Yellow (talk) 21:26, 9 November 2022 (UTC)
1011
1012
I look at this periodically. * Pppery * it has begun... 01:44, 24 October 2022 (UTC)
1014
1015
1016
@Sideswipe9th: This one is only private to keep the log private; it sometimes contains links like file://c:/users/my_real_name/foo.html
. The filter is:
equals_to_any(page_namespace, 0, 2, 118) &
(
link := "file://";
added_lines irlike link &
!(removed_lines irlike link)
) &
!("bot" in user_groups) &
!(summary irlike "^(?:revert|restore|rv|undid)") &
!("URI scheme" in new_wikitext)
Don't see any obvious improvements, and with over 3000 hits, it's serving a purpose. The spam blacklist can't be used here; MediaWiki doesn't even recognize these as links, and its log is semi-public. Suffusion of Yellow (talk) 03:43, 24 October 2022 (UTC)
- Yeah that makes sense. I figured the spam blocklist couldn't handle file URIs after checking its documentation, and I'd forgotten that a lot of those sorts of links would contain a computer username that may or may not also be someone's real name. I'm also not seeing any obvious changes that we could make. Sideswipe9th (talk) 03:50, 24 October 2022 (UTC)
1017
1020
1022
1025
1030
Optimized to not generate added_links
every time someone edits a line containing a link. @ST47: Would it be a good idea to do something with this besides log? I haven't checked for FPs but I suppose we could add a warning, though that might deter people from adding references at all. Or, maybe just fix these links with a bot? In that case, would the bot even need the filter to find the links to fix? Suffusion of Yellow (talk) 01:14, 29 October 2022 (UTC)
- @Suffusion of Yellow: There used to be a bot. one is inactive and the other is an AWB task, meaning that it is run intermittently and only if primefac remembers. I don't know if warning is the right thing to do here - the idea was to see if there are any spammers who are using these kinds of URLs often, not to simply get rid of these (mostly-meaningless) parameters. However, there's too much noise to really do anything with the results of this filter. It should probably be disabled. ST47 (talk) 02:48, 10 November 2022 (UTC)
1031
1032
- 1032 (hist · log) ("Adding URLs with characters that decompose or case-fold to ASCII characters", private)
Was checking added_links
on every single edit! Was a bit non-intuitive to fix that. Might tidy the regex further. (Ping ST47) Suffusion of Yellow (talk) 04:18, 1 November 2022 (UTC)
1033
1034
1035
1037
1039
There are, um, privacy concerns, with discussing this one here. I've a made a change and emailed someone. Others are invited to review. Suffusion of Yellow (talk) 04:44, 1 November 2022 (UTC)
1043
1045
1048
- 1048 (hist · log) ("Possible spam", public)
- I check this one frequently. OhNoitsJamie Talk 14:28, 23 October 2022 (UTC)
1051
1052
1053
1055
1057
1058
1059
@ToBeFree: Is this still serving a purpose? Only 50 hits in over two years, and the recent few I checked look like weird cut-and-paste fails and not from any one LTA. Suffusion of Yellow (talk) 22:45, 9 November 2022 (UTC)
- Hi Suffusion of Yellow, thanks for asking – I think this can be removed and/or made public. Or, if the 50 hits are precisely capturing bad edits well enough, perhaps merged into an existing and public filter. ~ ToBeFree (talk) 23:27, 9 November 2022 (UTC)
- Filter disabled ~ ToBeFree (talk) 23:30, 9 November 2022 (UTC)
1060
The MediaWiki:Abusefilter-disallowed-remove-csd message used by the filter should contain an indication that the edit was prevented, like most of the other messages used by filters that disallow problematic edits. AKK700 03:06, 31 October 2022 (UTC)
1062
Why does this filter exist when there's edit filter 614 that automatically prevents rickroll vandalism? AKK700 03:10, 31 October 2022 (UTC)
- Perhaps this contains more links and prevents more cases. 0xDeadbeef→∞ (talk to me) 00:19, 10 November 2022 (UTC)
1067
This LTA is active and the filter is effective with no FPs. No obvious optimisations. -- zzuuzz (talk) 17:15, 26 October 2022 (UTC)
1070
Simplified the logic a bit. @Wugapodes: Is this still a problem? I'm not familiar with this LTA. Suffusion of Yellow (talk) 20:27, 29 October 2022 (UTC)
1073
1074
1075
Large crossover with filter 1135. -- zzuuzz (talk) 20:36, 13 November 2022 (UTC)
1076
1081
1082
This filter is the same as filter 828, except this one is private. Is there a need for creating a private copy of an already existing filter? AKK700 05:27, 1 November 2022 (UTC)
- @AKK-700 and ST47: Well they're not exactly the same. But they're similar enough, so I've merged this into 828 (hist · log). I'm not marking this one public because there are some BEANsy suggestions in the notes. Suffusion of Yellow (talk) 22:15, 25 November 2022 (UTC)
1084
1086
1088
1089
@GeneralNotability: Merged with 1037 (hist · log). No hits since April 2021. But see the Commons account I linked in the notes. Not totally sure they've given up. Suffusion of Yellow (talk) 22:32, 25 November 2022 (UTC)
1090
Made a few tweaks to reduce FPs. This should set to at least warn+tag. Suffusion of Yellow (talk) 23:13, 10 November 2022 (UTC)
1093
1094
- 1094 (hist · log) ("miscellaneous LTAs", private)
- Actively in use for LTAs; should remain private. OhNoitsJamie Talk 14:25, 23 October 2022 (UTC)
1102
1106
1107
1109
Fairly valuable for catching a certain type of account. If possible, I'd like to keep this one around. --Blablubbs (talk) 09:46, 23 October 2022 (UTC)
- @Blablubbs: One line sticks out as obviously outdated. -- zzuuzz (talk) 10:55, 23 October 2022 (UTC)
- @Zzuuzz: Line #3? --Blablubbs (talk) 11:00, 23 October 2022 (UTC)
- 6 :) -- zzuuzz (talk) 11:01, 23 October 2022 (UTC)
- Ooh, good call – removed, thanks. :) --Blablubbs (talk) 11:04, 23 October 2022 (UTC)
- 6 :) -- zzuuzz (talk) 11:01, 23 October 2022 (UTC)
- @Zzuuzz: Line #3? --Blablubbs (talk) 11:00, 23 October 2022 (UTC)
1112
- 1112 (hist · log) (""Notable people" disruption", public)
- Useful for catching graffiti/vanity efforts. OhNoitsJamie Talk 14:29, 23 October 2022 (UTC)
1119
1120
1121
1122
1124
This is another filter that only tracks a single type of meme, whereas edit filter 614 is a filter dedicated to catching many popular memes. Why should we have one filter for a singular meme and another for all other memes when we probably should merge this filter into 614 for a filter that catches all meme vandalism? AKK700 02:58, 31 October 2022 (UTC)
- @AKK-700: Some of what's in 614 was probably in another filter at some time. Memes, as Richard Dawkins taught us, evolve, and it's helpful to keep the log for an "active" meme separate because making changes to a "combined" filter is dangerous; no one is going to sift through the log checking for FPs. Eventually, this can be merged somewhere. But right now the
edit_delta
logic makes that difficult. As this loses popularity, we can probably stop filtering on plain "among us" (which is a fairly common term) and stick with the always bad faith stuff like "impostor is sus", etc. Suffusion of Yellow (talk) 04:27, 31 October 2022 (UTC)
1125
1129
1130
1132
1133
1135
1140
1141
Disabled and made public per note in filter. ProcrastinatingReader (talk) 21:46, 26 October 2022 (UTC)
1145
1151
1152
1153
@ArbCom Clerks: Is this still required? As there's a large editnotice on that page already, and per filter logs it seems the users file their request anyway, so not sure the warning is having its intended purpose. ProcrastinatingReader (talk) 21:43, 26 October 2022 (UTC)
- I don't see a real reason to keep it, but I will defer to DJ -- Guerillero Parlez Moi 21:45, 26 October 2022 (UTC)
- This was in response to a number of new editors filing arbitration requests that were declined as premature. At the time I thought a warning which makes them stop and read the message may be useful. However, looking at what has happened there has been no occasion where an editor has seen the warning and the not continued to file the request. As such, I've disabled it as likely not being useful enough. Dreamy Jazz talk to me | my contributions 22:45, 26 October 2022 (UTC)
1154
1155
Some of this (whichever parts don't have many FPs) can probably be merged into 965 (hist · log) and the filter disabled overall. ProcrastinatingReader (talk) 15:04, 7 November 2022 (UTC)
1156
1157
Useful for a multitude of reasons – not sure if we have to keep it private, though. --Blablubbs (talk) 11:09, 23 October 2022 (UTC)
- I think this can be made public. I've optimised it a bit, and fixed the last line. -- zzuuzz (talk) 11:43, 23 October 2022 (UTC)
1159
Active problem, but probably only one of this or 1217 (hist · log) needs to stay. ProcrastinatingReader (talk) 11:38, 23 October 2022 (UTC)
- If possible I'd prefer the public one to remain. I monitor it every so often, particularly when we see a spate of activity on this pattern. But I do understand if the private one needs to be the active one. Sideswipe9th (talk) 19:40, 24 October 2022 (UTC)
1160
Active LTA ProcrastinatingReader (talk) 11:38, 23 October 2022 (UTC)
1161
1162
1163
1168
1169
1170
1171
No hits since September, but I doubt they've gone away. Merged with 906. Suffusion of Yellow (talk) 21:18, 10 November 2022 (UTC)
1174
1175
1176
1177
1178
1181
1182
1183
1188
1193
1194
1195
1196
1197
1199
1200
Smaller edits that inappropriately change pronouns have been slipping through this filter. (see India Willoughby for examples). A rework may be needed. Pinging @Firefly: 137a (talk) 15:26, 12 December 2022 (UTC)
- @137a this one is more @Tamzin’s work than mine :) firefly ( t · c ) 11:09, 24 December 2022 (UTC)
- @137a and Firefly: Yeah I'd been thinking about lowering the threshold to warn. The fundamental problem is there's no efficient way to distinguish between, say, maliciously changing "she" to "he" once in a trans woman's article, and removing a sentence in that article that has a "she" in it and adding an unrelated one with a "he", so we can really only infer malicious intent from the number of pronoun changes, which at lower numbers is bound to incur false positives. Even edit_delta isn't much help because the exact kind of FP-prone edit in question often has a small net change to bytecount. I'm testing a 5-pronoun-change cutoff in my test filter, log-only. I'll give that 72 hours or so and see how many FPs we get. Since it's a warn filter, we can tolerate a slightly higher number than on a disallow. -- Tamzin[cetacean needed] (she|they|xe) 19:52, 24 December 2022 (UTC)
1201
This is my workaround for phab:T102944. By capturing every variable at the time of the edit, we can test against a "real" log hit, instead of the "simulated" hit generated by Special:AbuseFilter/test. If you have User:Suffusion of Yellow/batchtest-plus installed, note the new "FP check" button in filter interface, next to "Save filter".
I expect this might be a bit slow (@MusikAnimal:: How slow?) for the unlucky 1 in 1000 non-autoconfirmed users, but it doesn't use many conditions. Suffusion of Yellow (talk) 21:52, 23 November 2022 (UTC)
1202
- 1202 (hist · log) ("misc article/draft/talk LTAs", private)
- This is currently use to track several persistent LTAs across several pagespaces; should remain private. OhNoitsJamie Talk 14:25, 23 October 2022 (UTC)
1204
This should have some sort of warning, once I get the FPs low enough. It's remarkable how many people seem to think there's nothing wrong with calling a living person the "perpetrator" of a crime, when they have not in fact been convicted of that crime. Suffusion of Yellow (talk) 20:53, 20 November 2022 (UTC)
1205
1207
1208
- 1208 (hist · log) ("Possible claims of racism", public)
- This probably can
be combined withabsorb Special:AbuseFilter/921 ("Suspicious claims of nazism"). –MJL ‐Talk‐☖ 04:43, 28 October 2022 (UTC)
- This probably can
1209
Disabled, merged into 58 (hist · log). Also partially covered by several other filters. Suffusion of Yellow (talk) 02:09, 1 November 2022 (UTC)
1210
@Locke Cole, PhantomTech, Mako001, and Xaosflux:. Disabled and part-merged into disallowing filter 828 (hist · log). I did not merge the check for user pages (only user talk pages). A redirect from the user page seems silly, but not really all that disruptive. Suffusion of Yellow (talk) 22:12, 25 November 2022 (UTC)
- Ultimately the biggest concern with 1210 was disallowing redirects to Main Page because that specific page suppresses the "Redirected from ..." text, which makes it difficult to get to a vandals user page on most devices. If you want to make it more specific I'd not object as the other redirects aren't nearly as big an issue. I would enable it for user pages though as this was the biggest issue (clicking on a user name in an edit history took you straight to Main Page with no indication of what was going on). —Locke Cole • t • c 23:28, 25 November 2022 (UTC)
- In the past four months, there has been only been one user who has attempted to redirect any user page to the MP. I'm not sure that's a common enough problem to have a filter for. Suffusion of Yellow (talk) 23:59, 25 November 2022 (UTC)
- It's not so much that it's common, it's that it's a vector for abuse. I initially sought to get a bot to look for user/user talk page redirects to Main Page but was advised an edit filter would be better and could stop them from being created altogether. —Locke Cole • t • c 00:35, 26 November 2022 (UTC)
- Given that the only other user who has recently (like, over 12 months ago) redirected their user talk to mainspace was me, and since this this filter hasn't had any hits for that problem, it might even be best to remove it per BEANS. Mako001 (C) (T) 🇺🇦 07:07, 26 November 2022 (UTC)
Given that the only other user who has recently (like, over 12 months ago) redirected their user talk to mainspace was me
No, as Suffusion of Yellow indicated just before my reply, there was an editor who did it (see Special:Contributions/The Number Line), promptly did something bad and was ultimately blocked. I'm not going to fight to maintain this. I've done as much as I can do, if other editors disagree and want to leave us open to this kind of abuse, so be it. —Locke Cole • t • c 05:37, 30 November 2022 (UTC)
- Given that the only other user who has recently (like, over 12 months ago) redirected their user talk to mainspace was me, and since this this filter hasn't had any hits for that problem, it might even be best to remove it per BEANS. Mako001 (C) (T) 🇺🇦 07:07, 26 November 2022 (UTC)
- It's not so much that it's common, it's that it's a vector for abuse. I initially sought to get a bot to look for user/user talk page redirects to Main Page but was advised an edit filter would be better and could stop them from being created altogether. —Locke Cole • t • c 00:35, 26 November 2022 (UTC)
- In the past four months, there has been only been one user who has attempted to redirect any user page to the MP. I'm not sure that's a common enough problem to have a filter for. Suffusion of Yellow (talk) 23:59, 25 November 2022 (UTC)
1211
@ToBeFree: Any objection if I disable this? The last true positive was on 23 August. The meme seems to have died a natural death. Suffusion of Yellow (talk) 23:37, 20 November 2022 (UTC)
- Thanks Suffusion of Yellow, no objections and
Done. There would be no objections to making it public from my side either. ~ ToBeFree (talk) 23:46, 20 November 2022 (UTC)
1212
1213
- Already discussed above. @Ahecht and EpicPupper: No hits at all. This doesn't appear to be a common enough problem for a filter. Disabled. Suffusion of Yellow (talk) 04:20, 31 October 2022 (UTC)
1214
1215
1216
- No true positive since late September, disabling for now. DatGuyTalkContribs 15:20, 10 November 2022 (UTC)
1217
1218
Disabled. Uses close to zero conditions, but pointless unless a warning is added, and not worth the trouble of maintaining. As mentioned before, jpgordon if you find a large number of requests that this filter is missing, let me know. Suffusion of Yellow (talk) 20:46, 29 October 2022 (UTC)
1219
1220
Mostly catching drive-by vandalism and should be a public filter, but I'm not sure if there's anything in the log that should stay private. Disabled this one, and created public filter 1233 (hist · log) with nearly the same conditions. Suffusion of Yellow (talk) 23:51, 3 December 2022 (UTC)
1221
1222
1223
1224
@Suffusion of Yellow: seems like this could be renamed and made public. DatGuyTalkContribs 15:10, 8 November 2022 (UTC)
- @DatGuy: There might be some stuff in the log that shouldn't be public. If this is to be a public filter, it's probably best to move it to new filter ID. I'm not sure if it's valuable enough to keep around, though. Suffusion of Yellow (talk) 21:19, 9 November 2022 (UTC)
1225
Disabled for now. Might disable some other related filters soon. Suffusion of Yellow (talk) 23:31, 28 October 2022 (UTC)
1227
Disabled; too much clutter in the log to be worth checking. Suffusion of Yellow (talk) 23:08, 20 November 2022 (UTC)
1229
1230
- The LTA seems to have gone away. I would like to give it another week before we disable it in case they come back --Guerillero Parlez Moi 21:47, 26 October 2022 (UTC)
Add "ezproxy2" to proxy link filter
Found at Music of South Asia ("https://www-jstor-org.ezproxy2.library.drexel.edu/stable/3394138?sid=primo&seq=1#metadata_info_tab_contents") * Pppery * it has begun... 23:27, 29 November 2022 (UTC)
1202 cleanup
Cross-post: Wikipedia:Administrators' noticeboard § Help needed rescuing edit filter false positives -- Tamzin[cetacean needed] (she|they|xe) 05:48, 12 December 2022 (UTC)
- FWIW, for all EFMs, Suffusion's userscript User:Suffusion of Yellow/batchtest-plus-core.js can help catch things like this before saving. There's a "FP check" button which runs against a random sample of non-autoconfirmed edits. Most filters should probably have few or no matches here. ProcrastinatingReader (talk) 10:59, 12 December 2022 (UTC)
Should we add links to test filters in the header of WP:EFR?
I made a list of filters that are here for testing purposes (excludes deleted filters and filters meant for use by one person such as 1014 (hist · log)). I don't know how it should be included, but I think this will be useful when someone wants to find the right filter to test stuff. Should we be adding this?
Filter number | Description |
---|---|
1 (hist · log) | General test filter |
2 (hist · log) | Test filter: for testing private filters (private) |
398 (hist · log) | Test filter 398 (private) |
839 (hist · log) | Bad word test |
844 (hist · log) | Test filter (private) |
848 (hist · log) | Large contributions test filter |
877 (hist · log) | test filter 4 (private) |
1019 (hist · log) | LTA Username Testing Filter (private) |
1147 (hist · log) | Message tests |
1186 (hist · log) | Test filter 1186 (private) |
137a (talk) 13:19, 21 December 2022 (UTC)
- @137a: I don't think that's needed. AFAIK there is zero performance penalty from a disabled filter, so if someone ends up creating a new filter instead of reusing an old one, there's no harm done. Suffusion of Yellow (talk) 00:35, 31 December 2022 (UTC)
1124 and unrelated occurrences of Among Us
In reviewing a bot report at AIV, I saw that edits by 2601:547:cc00:4620:d567:cf4d:e0cc:38c0 were disallowed by filter 1124 because they reference a TV episode with "Among Us" in the title, A Brat Walks Among Us!, that has nothing to do with the game or meme. I don't believe the filter should be catching this or any similar instances.
Not sure if the correct place to report this is here or at Wikipedia:Edit filter/False positives/Reports, seeing as I am not the user who made these edits. Complex/Rational 21:24, 21 December 2022 (UTC)
- Note that [12][13][14][15] are all vandalism edits within one day of this post that used "Among Us". 0xDeadbeef→∞ (talk to me) 17:02, 22 December 2022 (UTC)
- I was only wondering if it's technically possible to make an exception somewhere in the regex for legitimate occurrences of the phrase. Complex/Rational 23:26, 22 December 2022 (UTC)
- I don't think it would be possible beside whitelisting specific titles, which wouldn't help much. We will have to see if we should disable matching the "among us" phrase if many more false positives come up. 0xDeadbeef→∞ (talk to me) 05:23, 23 December 2022 (UTC)
- I was only wondering if it's technically possible to make an exception somewhere in the regex for legitimate occurrences of the phrase. Complex/Rational 23:26, 22 December 2022 (UTC)
- @ComplexRational: I lower the
edit_delta
check, to 200 from 500. That's not a perfect solution but should prevent some FPs on substantial edits like these. Suffusion of Yellow (talk) 00:32, 31 December 2022 (UTC)
EFH request (Fehufanga)
- Fehufanga (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)
Hello, I am requesting edit filter helper permissions. I am an active administrator at the Simple English Wikipedia and I help out with the edit filters over there. I am also active on the English Wikipedia in anti-vandalism activities. Having EFH here would help me identify some of the returning customers that frequent English Wikipedia and Simple English Wikipedia. Thank your for your consideration. —*Fehufangą (✉ Talk · ✎ Contribs) 04:27, 27 December 2022 (UTC)
- Support per criteria #3 - active admin w/ filters on Simple English Wikipedia. ProcrastinatingReader (talk) 07:55, 27 December 2022 (UTC)
- Support — TheresNoTime (talk • they/them) 08:21, 27 December 2022 (UTC)
- Note, simplerfa (simple:Wikipedia:Requests for adminship/Fehufanga) was ~3 months ago, appears to be active. — xaosflux Talk 13:27, 27 December 2022 (UTC)
- Support no concern for EFH. --Assyrtiko (talk) 06:21, 29 December 2022 (UTC)