Wikipedia:Edit filter noticeboard/Archive 10

This is an archive of past discussions about Wikipedia:Edit filter noticeboard. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current main page.

Archive 5

←

Archive 8

→

Set filter 1085 to disallow

Latest comment: 2 years ago6 comments2 people in discussion

1085 (hist · log) (private)

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)

Someone please take a look at my comment at Special:Permalink/1109276246#Someonefromohio. PhantomTech[talk] 23:45, 8 September 2022 (UTC)

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)

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)

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)

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)

"Chandler" mass attack/article hijacking

Latest comment: 2 years ago8 comments5 people in discussion

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)

Just FYI, there's a lot of history on that individual — TheresNoTime (talk • they/them) 22:21, 19 September 2022 (UTC)

@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)

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)

@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)

@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)

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)

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)

Filter Log Flooding, apparently EDU related?

Latest comment: 2 years ago3 comments2 people in discussion

Is there anything we can do to prevent this kind of flooding of the filter log, which is clearly all false positives related to something in the education program? Taking Out The Trash (talk) 20:23, 2 October 2022 (UTC)

@Taking Out The Trash do you have a more diverse sample (more than just this one user)? We could exempt those filters from something such as edit summary is equal to 'student training overdue'. — xaosflux ^Talk 00:46, 3 October 2022 (UTC)

This is the first time I've noticed such an occurrence, so no I don't have any other examples now, but it was obvious to me that these were FPs and there shouldn't be that many of them. Taking Out The Trash (talk) 21:47, 3 October 2022 (UTC)

Set filter 1222 to disallow

Latest comment: 2 years ago3 comments2 people in discussion

1222 (hist · log) (private)

Mandatory notice, another boring LTA. Should we either (A) drop (or refine) the "new filters set to disallow must be reported to EFN" rule, or (B) start yelling at people who don't follow the rule? Because I think I'm the only one left who does this.

Certainly, any disallowing filter targeting good-faith users should be discussed first. And one where this risk of FPs is high, but possibly justifiable. But a simple LTA or vandalism filter? There's nothing special about a "new" filter. I could have just tacked the same check onto an existing filter, and then there would have been no reporting requirement. Suffusion of Yellow (talk) 20:59, 14 October 2022 (UTC)

@Suffusion of Yellow does this one really need unique tracking, or would appending to another filter actually be better? — xaosflux ^Talk 22:08, 14 October 2022 (UTC)

I like to keep things separate at first; it saves the trouble of picking apart the log from a filter tracking 10 LTAs. Absolutely it can be merged later. Suffusion of Yellow (talk) 22:12, 14 October 2022 (UTC)

Set filter 1220 to disallow?

Latest comment: 2 years ago1 comment1 person in discussion

1220 (hist · log) ("Copypaste vandalism", private)

This was created to track a LTA (see the linked thread in the notes). It's picking up a mix of (1) edits from the LTA, e.g. Special:AbuseLog/33613571, (2) vandalism and test edits, e.g. Special:AbuseLog/33599279, (3) weird stuff like Special:AbuseLog/33616397. Any good-faith edits that it's catching tend to be the kind that are bound to be reverted anyway. I'm going to use MediaWiki:Abusefilter-disallowed-LTA as a friendlier message for those. I suppose we could use a custom message, but I'm not sure what it would say without tipping off the LTA. Suffusion of Yellow (talk) 22:19, 15 October 2022 (UTC)

Set filter 1223 to disallow

Latest comment: 2 years ago5 comments3 people in discussion

1223 (hist · log) (private)

Just set this to disallow without much testing, and now I need to step away from the screen for a bit. Attack/harassment underway as we speak. Probably needs adjusting; I had to wildly guess at certain parameters. If there are too many FPs, consider just setting to log-only, and monitoring. @Firefly and DatGuy:: You know what this is about... Suffusion of Yellow (talk) 21:00, 16 October 2022 (UTC)

@Suffusion of Yellow and others - see also my 1190. firefly ( t · c ) 21:10, 16 October 2022 (UTC)

And Special:AbuseFilter/1214. DatGuy^Talk_Contribs 08:49, 17 October 2022 (UTC)

@Suffusion of Yellow: I think 1223's conditions are way too wide. I prefer Firefly's or mine where there's some behavioural checks rather than totally environmental. DatGuy^Talk_Contribs 18:49, 17 October 2022 (UTC)

@DatGuy: I made a few changes to reduce FPs. IMO the level of harassment justifies such a broad filter. They modified their behavior several times yesterday already, and this filter is difficult to evade while still achieving their goal of harassing a specific user. Of course this is meant to be only temporary. Suffusion of Yellow (talk) 20:04, 17 October 2022 (UTC)

LTA \d\d\d\d

Latest comment: 2 years ago13 comments7 people in discussion

Would anyone else find it useful to have a (disabled) private filter which contains an abridged index of all these LTA \d\d\d\d filters that we now have? I think I would. I can't think of any disadvantages, barring the effort to make it. -- zzuuzz ^(talk) 22:56, 18 October 2022 (UTC)

Yeah, it's getting hard to keep track. Suffusion of Yellow (talk) 23:12, 18 October 2022 (UTC)

Yes please. firefly ( t · c ) 21:19, 19 October 2022 (UTC)

Sorry for sounding dumb, but what does "\d\d\d\d" mean? Taking Out The Trash (talk) 01:32, 20 October 2022 (UTC)
\d means "digit" in regex. So it probably means filters named "LTA ####", where # is the filter number. That seems to be their convention for naming filters that are tripped by WP:LTAs (long term abusers). –Novem Linguae (talk) 02:17, 20 October 2022 (UTC)
Indeed thanks. \d just means 'number' to any regular here. Technically it should be \d+, which means any string of numbers, but this title seemed to represent the problem better. We have a ton of filters with names like 'LTA 1181'. We also have filters like my personal favourite, 'private filter 986'. There was some talk a while ago about having private filter names, but I don't think that ever got resolved. I think I'll get around to trying this at some point. I'm thinking the index can go in the filter part, and there can be some instructions in the description part. I might try and wait for a catchy number. I see 1234 should be coming around soon, which seems appropriate. -- zzuuzz ^(talk) 05:05, 20 October 2022 (UTC)
There was some talk a while ago about having private filter names, but I don't think that ever got resolved. Sounds like a decent idea to me. A patch to make private filter names private except for folks with abusefilter-view-private could be a good solution. Then you can label them all properly, such as with the LTA's name. And you could program the public to just see "Private filter ####" for the title. Worth making a phab ticket? –Novem Linguae (talk) 06:43, 20 October 2022 (UTC)
The thing I was thinking of was this previous thread, which has a phab ticket, and a related phab:T309693. I'm still not really sure where I stand on all of that, all things considered, but this would fill in the inevitable gap. -- zzuuzz ^(talk) 12:08, 20 October 2022 (UTC)
Or possibly as a temporary solution until the phab ticket is unblocked, a toolforge hosted site which requires OAuth authentication. The current EF system is rather old. DatGuy^Talk_Contribs 12:52, 20 October 2022 (UTC)

I like this idea; we should perhaps even link to this index filter from interface messages. We should, however, remove it as soon as it has lost this one specific need. It might else be tempting to misuse the edit filter extension to build a kind of admin-only wiki behind the scenes. ~ ToBeFree (talk) 21:02, 21 October 2022 (UTC)

To be completely honest I'm not a fan of labeling filters as "LTA####"... it makes patrolling incredibly difficult for non-filter helpers/managers. Some filters have a link to the WP:LTA case page as their titles (thinking specifically of 667 and 937), which means that even though the filters are private, we can look at the case page and get a better idea of what kind of edits we are looking for should any slip through. It doesn't help troubleshoot false positives, but it's still something. Anonymizing four digit numbers? Completely useless. We don't display the filter title in the disallowed messages (contrary to the software default) so I would think that including the name of the LTA case page (when one exists) shouldn't be a big deal. Taking Out The Trash (talk) 01:26, 22 October 2022 (UTC)
Filter 1231 (hist · log) is in progress. -- zzuuzz ^(talk) 17:55, 26 October 2022 (UTC)

Consider filter 1231 open for business. I'm getting near the limits of my useful input. If anyone wants to add descriptions, alternate names, fill in any gaps... it's all yours. -- zzuuzz ^(talk) 13:42, 27 October 2022 (UTC)

Filter 614 individual cases

Latest comment: 2 years ago5 comments3 people in discussion

614 (hist · log) Same as the last time, but this time for 2022-11-08T01:48:11Z to 2021-11-09T17:20:25Z.

data dump

Case { src: "e+s+k+e+t+i+t", count: 0 } 
Case { src: "fetus\\s*deletus", count: 1 } 
Case { src: "you'?ve\\s*been\\s*gnomed", count: 1 } 
Case { src: "#sw[4ae]g", count: 3 } 
Case { src: "hit\\s*or\\s*miss[\\s,]*I\\s*guess", count: 3 } 
Case { src: "420\\s*b+l+a+z+e+\\s*i+t+", count: 4 } 
Case { src: "hard\\s+(?:pp|peepee)", count: 4 } 
Case { src: "#redirect\\s*\\[\\[donald[\\s_]trump\\]\\]", count: 4 } 
Case { src: "(?:f[u\\*][c\\*]k(?:ing?|ed|s)|sex\\s*with?)\\s*chickens?", count: 5 } 
Case { src: "#yolo", count: 6 } 
Case { src: "gucci\\s*gang[\\s,]*gucci\\s*gang", count: 7 } 
Case { src: "(?:pp|peepee)\\s+hard", count: 9 } 
Case { src: "tran?s?.?manian?\\b", count: 10 } 
Case { src: "ugandan\\s*knuckles", count: 10 } 
Case { src: "\\by+o+l+o[lo]+", count: 11 } 
Case { src: "\\bdat\\s* boi", count: 13 } 
Case { src: "y\\s*o\\s*[lo\\s]+s\\s*w\\s*[4ae]+\\s*g+", count: 15 } 
Case { src: "hitler\\s*did\\s*nothing?\\s*wrong", count: 17 } 
Case { src: "s+w+[4ae]+gg[g]+", count: 20 } 
Case { src: "chicken\\s*f[u\\*]?[c\\*]k(?:er|s|ing)?", count: 22 } 
Case { src: "epst(?:ei|ie)n\\W+did\\s*n.?t\\s+kill", count: 23 } 
Case { src: "bush\\s*did\\s*9.?11", count: 24 } 
Case { src: "rawr\\s*xd", count: 25 } 
Case { src: "(?:them'?s?|dems?|those\\s+are)'?\\s+(?:th[ea]|da)\\s+fa(?:cts|x)!?", count: 28 } 
Case { src: "\\s*i\\s*n\\s*t\\s*h\\s*[ae]\\s*p\\s*(?:(?:[@uv*]\\s*)+(?:[zs$*]\\s*)+|[zs$*]{2,})\\s*a*y+", count: 29 } 
Case { src: "ok(?:ay)?,? boomer", count: 29 } 
Case { src: "drumpf", count: 35 } 
Case { src: "dank\\s*meme", count: 50 } 
Case { src: "\\booo+f+\\b", count: 50 } 
Case { src: "sw[4ae]g\\s*(?:yolo|daddy|money|lord|master)", count: 57 } 
Case { src: "\\bnibb+a+\\b", count: 65 } 
Case { src: "absolute\\s*unit", count: 65 } 
Case { src: "\\bayyy", count: 70 } 
Case { src: "\\bt+r+o+l(?:o+l|ll)", count: 78 } 
Case { src: "\\bs+h+ee+s+h+\\b", count: 85 } 
Case { src: "\\bbruv+\\b", count: 87 } 
Case { src: "sub(?:scrib(?:e|es|ed|ing))?\\s*(?:to|2)\\s*(?:p(ew|ud|ue|uw|oo)|te*.?series)", count: 104 } 
Case { src: "\\b(?:ranboo|tubbo)", count: 124 } 
Case { src: "\\beats?\\s*ass\\b", count: 127 } 
Case { src: "\\br+eeeeee", count: 212 } 
Case { src: "b+o+iii", count: 219 } 
Case { src: "\\bg+a+yy(?:y|\\b)", count: 369 } 
Case { src: "\\bt+\\s*h+\\s*i+\\s*c\\s*c", count: 406 } 
Case { src: "chung[uea]s\\b", count: 429 } 
Case { src: "aviation\\s*,[\\s\\S]*?there\\s*is\\s*no[\\s\\S]*?bee[\\s\\S]*?be\\s*able\\s*to\\s*fly", count: 469 } 
Case { src: "\\by+ee+t+(?:e+(?:r+|d+))?\\b", count: 613 } 
Case { src: "lolo(?:lo)+", count: 737 } 
Case { src: "h+iiiii", count: 942 } 
Case { src: "quandale\\s*dingle", count: 946 } 
Case { src: "dQw4w9WgXcQ", count: 961 } 
Case { src: "\\bh+iii+\\b", count: 1018 } 
Case { src: "hehehe", count: 1523 } 
Case { src: "\\bbruh+\\b", count: 1664 } 
Case { src: "joe m[oa]m+a", count: 1728 } 
Case { src: "\\bl+m+f*a+o", count: 1783 } 
Case { src: "\\buwu\\b", count: 2004 } 
Case { src: "(?:69\\D*420|420\\D*69|(?:69\\D{0,50}){3,})", count: 3022 } 
Case { src: "(?:d[3e](?:[3e]+[sz]+|[sz][sz]*)e*|th[3e][zs$][3e])\\s*n+u+t+[zs$]", count: 5170 }

I see some candidates for removal here. 0xDeadbeef→∞ (talk to me) 05:16, 8 November 2022 (UTC)

Thanks for this. Any chance we can look at hits over a slightly longer period (a week or something would be ideal), or take another sample in a few days or a week? I don't know if a single 36 hour sample is enough to say certain patterns aren't observed much anymore? Although definitely some of those low hit ones I'd imagine to be low in prevalence now. ProcrastinatingReader (talk) 14:00, 8 November 2022 (UTC)

@ProcrastinatingReader: it is going back a year.. 0xDeadbeef→∞ (talk to me) 14:05, 8 November 2022 (UTC)

🤦 I missed the change in year (I'm awful at reading timestamps tbh) ProcrastinatingReader (talk) 14:07, 8 November 2022 (UTC)

Wouldn't have guessed the "winner" there; #2, though... [1]. OhNoitsJamie ^Talk 23:03, 9 November 2022 (UTC)

Filter 1216

Latest comment: 2 years ago8 comments6 people in discussion

I'm concerned about the way filter 1216 (hist · log) works and has now prevented a good-faith editor from doing something the filter incorrectly forbids. I'm not sure if this specific type of filtering may be set to "disallow" without being in conflict with WP:5P3. ~ ToBeFree (talk) 20:42, 21 October 2022 (UTC)

We could perhaps make the filter public to show the issue. I understand that doing so allows those targeted by it to evade it, but in this specific case, the filter code is of such a general nature that a) I'm concerned about the way it works and b) I see no reason not to publicly discuss its content. ~ ToBeFree (talk) 20:56, 21 October 2022 (UTC)

Was there any prior discussion about setting this to disallow? I couldn't immediately find anything in the archives. --Blablubbs (talk) 21:00, 21 October 2022 (UTC)

FYI I've removed the disallow action per not only this thread, but mainly the fact the filter hasn't had an LTA hit in about a month. I believe this filter was created in response to some rapid LTA disruption, during which we normally relax some filter guidelines in an effort to curtail the initial spike of disruption. — TheresNoTime (talk • they/them) 21:01, 21 October 2022 (UTC)

FYI, there was something at AN shortly before (not directly mentioning a filter), but mentioning the LTA. I've added the LTA detail to the filter description. It's been going on here throughout this year at least. Most of the targets of interest are semi'd, and there's at least one range block in place until March, though range blocks are not going to be a full solution. BTW, starting off a filter in disallow mode is not recommended. IMO, log only should be fine for now. -- zzuuzz ^(talk) 22:54, 21 October 2022 (UTC)

I set it to disallow since after some limited testing on a private filter there were no FPs, and the vandal's edits were very rapid and each required a RD1 revdel. I'm not sure the vandal is still active and unopposed to the log only change. DatGuy^Talk_Contribs 07:00, 22 October 2022 (UTC)

This hasn't had a true positive in more than a month. Do we still need this? Reaper Eternal (talk) 15:01, 28 October 2022 (UTC)

@Reaper Eternal: disabled. DatGuy^Talk_Contribs 15:20, 10 November 2022 (UTC)

EFH Permission request (Taking Out The Trash)

Latest comment: 1 year ago30 comments12 people in discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Request withdrawn. No matter how you connect the dots, even if a rough consensus were to emerge, this would be an incredibly controversial appointment and would probably generate some amount of unease, which is something that I don't feel I should be putting the community through if it can be avoided. I firmly stand behind what I have said previously regarding the alleged logged out editing, which is that I have never done so except for the one accidental edit that I have already taken responsibility for. I am someone who always advocates for the truth and the facts above anything else, and I can assure you (collective) that this is the absolute truth of the matter. I still do not see nor understand the correlation between the allegations of logged out editing and the evaluation of whether I am suited and have the competence needed to appropriately handle the private edit filters, and that's something that I acknowledge I may never recognize. Spicy's comments at the bottom of this discussion gave me great pause; I've always thought that the filters are made private simply to prevent LTAs and sockmasters from evading them, and that the conditions are otherwise general vandalism stuff. I never considered the possibility that there would be oversightable material in the filter logs, which brings me back to a point that I made in the discussion about whether or not EFH is being granted in the appropriate manner. If this permission would, even theoretically, grant access to information that would be deleted or oversighted if made public, I'd seriously wonder if it should be an NDA permission granted only by ArbCom (in a similar manner to CU and OS), or perhaps even abolished outright and the ability to view filters restricted to admins who are already trusted to view deleted material. At this time I plan to step back from the filter areas, at least for the time being, and reevaluate my "backstage" participation, hopefully finding a new niche area that I can dedicate my time and effort to without the need for sensitive permissions. I'll be taking a short wikibreak in order to accommodate this, but my talk page and email are still open if anyone has any further questions or comments. I thank everyone who participated here for their comments - I greatly appreciate them - and I look forward to seeing folks around other areas of the project in the near future. Respectfully submitted. Taking Out The Trash (talk) 03:40, 18 November 2022 (UTC)

Taking Out The Trash (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)}

I was hoping that the above discussions and reviews of the existing filters would result in some of the filters that I feel are unnecessarily private being made public, but it doesn't seem like that's going to happen. As such, I would like to request edit filter helper permissions. The ability to view the private filters (well, at least their logs) would greatly assist me as one of the people who regularly patrols WP:EFFPR and will allow me to handle reports based on private filters without having to constantly ping @Suffusion of Yellow: to go troubleshoot. Additionally, I am a prolific counter vandalism patroller who primarily focuses on the edit filter log. When I see mass flooding of the log that is exclusively from private filters, I have no idea if it is a false positive, or attempted vandalism. Finally, having to guess what exactly the filters are looking for just based on the title is far from ideal, and for many filters that are just "LTA" followed by an anonymizing four-digit number, that tells me nothing. I can't troubleshoot false positives, or determine which hits in the log require immediate attention and which ones don't, when I haven't a clue what exactly the filter is looking for. For full disclosure, I have requested this once before, and was rejected more or less on the grounds that my account was too new at the time. I don't believe that should be an issue anymore. I can confirm that I meet all of the criteria at WP:EFH. I'll answer any questions/address any concerns to the best of my ability. Thank you for your consideration. Taking Out The Trash (talk) 21:54, 11 November 2022 (UTC)

Previous discussion at Wikipedia:Edit filter noticeboard/Archive 9#Edit Filter Helper for Taking Out The Trash. GeneralNotability (talk) 22:06, 11 November 2022 (UTC)

Based on this (and further discussion here, I'm strongly opposed. EFH requires a lot of trust. loutsocking is a major abuse of trust. GeneralNotability (talk) 22:16, 11 November 2022 (UTC)

Sigh... when will this nonsense end? This is all a giant red herring. I do not edit with any other account or IP address and have never intentionally done so. Anyone who says otherwise is either wrong, and/or doesn't know what a shared computer is. The edits in question were not made by me. I don't know how to make that any more clear. I also find it mildly concerning that an admin would link to a blatant personal attack made against me, especially one that was made almost a year ago. Taking Out The Trash (talk) 22:51, 11 November 2022 (UTC)

Where's the personal attack? DatGuy^Talk_Contribs 00:23, 12 November 2022 (UTC)

In the first diff. Implicitly calling me a liar. That's a personal attack. Taking Out The Trash (talk) 01:04, 12 November 2022 (UTC)

I'm assuming you're referring to TNT's saying [I find] your statements to Blablubbs nothing short of a barefaced lie in the fact of overwhelming evidence. It could be casting aspersions. That is, if it were done repeatedly and without proof. However, considering the second half of that sentence it appears not to be the case. Regarding the implicitness part, that sounds more like Joe Pesci in Goodfellas - all based on interpretation. On the other hand, I see rather combative behaviour by you in your reply, as well as flagrant wikilawyering in the sections linked above. I won't hold the latter part against you though since it took place nearly a year ago. DatGuy^Talk_Contribs 01:31, 12 November 2022 (UTC)

I apologize if my comments appeared to be combative - that was certainly not my intent. I am however frustrated and tired of having to refute this false allegation repeatedly. Heck, this is what led to my retirement from WP for several months. I just don't understand how and why other users, let alone admins, are being permitted to make false statements about me that have the potential to damage my reputation, refuse to provide public evidence to justify these serious allegations, call me a liar for refuting the false allegations, and then continue to hammer this over my head even almost a year later! Allowing privileged users to damage the reputation of less privileged users, seemingly without consequence or even a soft rebuke, is toxic behavior. This cannot be allowed to continue. <end rant>. Taking Out The Trash (talk) 02:21, 12 November 2022 (UTC)

I guess the apparent logging out editing at hand is here and here? Regardless of whether it is or isn't TOTT I don't think there's anything awfully problematic there. As for temperament: the relevant part is whether TOTT is collaborative, and IME (in the space of edit filters) he's been fine. I'm not worried about temperament otherwise as this isn't an RfA; it's a request to be able to see the patterns and logs of private filters, and EFH cannot make any onwiki actions. I'm not awfully convinced there's anything TOTT has done to show he's unsuited for this particular technical permission, and see a few ways in which it might lead to improvements on Wikipedia, so overall I remain not concerned about this passing. (as an aside: while there are definitely private filters that shouldn't be, I guarantee your perspective on whether certain filters need to be private will change if this passes, as did mine.) ProcrastinatingReader (talk) 15:54, 12 November 2022 (UTC)

@Suffusion of Yellow: @MusikAnimal: @Zzuuzz: @Tamzin: Thoughts problems questions concerns issues whining? 😂

In all seriousness, I'd value comments from you folks. As this has now been open 3 days, I'd like to avoid a "no consensus" result if at all possible - would like a definitive "yes" or "no". Thanks. Taking Out The Trash (talk) 23:02, 14 November 2022 (UTC)

Take heed, if you ask me for my opinion, you'll usually get one. I'm in the undecided camp, but I do lean towards potential support. Anyone who knows me may know it usually takes a high level of confidence to get my personal endorsement for anything, so not being opposed should be considered the good thing here. If GN stands where they stand, then you might just get that 'no consensus'. I'm undecided about the apparent logged out editing. I am a checkuser, but I can state that I didn't look closely at any of that at the time, so I have no idea whether you or anyone else is or was using that IP. The evidence is not unconvincing; yet your account was not blocked. I note that it was early in your editing history, but I also note that you've stated that your editing history extends beyond this account. Your previous account is a mystery meat as far as I'm concerned. I'm open minded, note your denials, and don't actually hold any of that against you.

Anything more recent? not that I know of. So, on the one hand, you seem to working with the filters and would have a use for EFH. On the other hand we need to look at the risks. My concerns about risk were well stated by Tamzin in your previous application. Where my concern would lie is whether you are naturally capable of maintaining the privacy of the filters, given your stated preference for transparency as well as some previous statements. When I say previous statements, I can point to your statement about filter 279 on the current version of this page, which says: "There is zero reason why this kind of filter needs to be private". I then provided a reason. This was followed by silence. That type of overconfidence is fairly common on Wikipedia, and I always find it concerning. However, I think with a strong enough commitment to the importance maintaining privacy, we could probably get over it. -- zzuuzz ^(talk) 05:11, 15 November 2022 (UTC)

For me, it really does come down to the loutsocking accusations. No, the edits weren't all that bad. But if those edits really were TOTT, lying about it (to Blablubbs), never apologizing for lying, and then calling the claim a "personal attack" would be a deal-breaker. What else is a lie? OTOH if TOTT is innocent, their supposed temperament issues aren't a problem. I'd be getting a bit testy, too, if I were wrongly accused of socking. Let's at least get on the same page:

@Taking Out The Trash:, are you specifically denying that you, as Special:Contributions/199.8.32.6, made any edits to Wikipedia talk:Arbitration Committee/Noticeboard and Wikipedia:Arbitration Committee/CheckUser and Oversight/2021 CUOS appointments/CU?

@GeneralNotability:, is your oppose based on your own examination of the evidence? Or are you merely repeating the claims of others?

@Blablubbs:, you wrote about conclusive evidence which I'm not allowed to disclose on-wiki per the outing policy that you used that exact IP address within the last few hours. I am happy to share it with any interested functionary if that is desired. This is mysterious. You weren't a CheckUser when you wrote that. Did TOTT email you from an external client, and leak their IP that way? If you're still as confident as you were then, can you share this evidence with zzuuzz?

I'll have more to say when these questions are answered. But please don't close this request yet; that would be unfair to TOTT. Suffusion of Yellow (talk) 23:09, 15 November 2022 (UTC)

@Suffusion of Yellow: Yes, I am specifically and unequivocally denying that I made any edits while logged out, under that IP address or any other, at any time, with the exception of this one, which was a complete accident and I didn't even notice I was logged out. Any other edits from that IP address or any other were 100% not made by me. Taking Out The Trash (talk) 23:49, 15 November 2022 (UTC)

Suffusion of Yellow, I have not seen the technical evidence (and given that we're now talking about specific IP addresses, I doubt anyone who has seen the technical evidence would be willing to comment), but I have nothing but confidence in TheresNoTime's abilities with the CU tool. And I can't speak for Blablubbs, but I'm guessing the evidence in question is something to the effect of "here's a behavioral tell that conclusively connects the IP to TOTT", and before his recent appointment as a CU, Blablubbs was an SPI clerk with solid experience at identifying behavioral connections. It wouldn't be exaggerating much to say that the two of them are some of the people I trust most on Wikipedia, and if both of them say that someone is editing logged-out, I am definitely inclined to believe them.

Now TOTT has acknowledged above that they made a logged-out edit from Special:Contribs/199.8.32.6, so I'll comment on that directly. That IP is an institutional IP belonging to the University of Indianapolis, so it's not implausible that there's more than one person behind it (can't say I'm familiar with their IP addressing scheme). However, around the time of the apparent loutsocking at CUOS2021 (+/- a month), there was definitely someone editing from that IP with a lot of behind-the-scenes knowledge (arbcom, CUOS appointments, edit filters)...and that knowledge and their interests sure sound like TOTT to me. The entire range (Special:Contribs/199.8.32.6/22) doesn't have a ton of other activity around that time, I only count two other IPs active, and both of them seemed to have fairly consistent interests (32.8 in particular seems consistently interested in reality TV over the course of a month). To me, that suggests a few things: IPs tend to be fairly static, there's not a lot of people editing logged-out, and the consistency elsewhere makes me think that IPs aren't shared that much. I freely admit that there's a lot of speculation and inferring here, I could be wrong, all of this could be coincidence. But to me, the sum of evidence sure looks like projsocking. GeneralNotability (talk) 01:26, 16 November 2022 (UTC)

To be completely honest, now that I've looked, I don't see any edit filter stuff in the linked range. The only "project" stuff that I see are ArbCom-related things (ACN and CUOS appointments, both of which I don't really have any interest in being part of) and one edit it looks like to Articles for Creation (pretty routine of any IP or new account). I also certainly don't have any keen interest in reality TV, either. Taking Out The Trash (talk) 02:20, 16 November 2022 (UTC)

Off topic but semi relevant TLDR

I should point out however, that geolocation and WHOIS data for Indy IP ranges is next to useless. 95% of the time the results that these tools will return will be at least partially incorrect. To use the range in question for example, yes it is "registered" to the University of Indianapolis, but its usage is not explicitly restricted to the university's internet connections. In fact, given the most recent edits it almost looks to me that it may currently being used by someone at or affiliated with Butler University, arguably one of UIndy's chief rivals. It seems rather unlikely that someone at UIndy would be editing articles related to one of their top opponents, when, with the exception of social interactions between the two mascots (both dogs), connections between the two schools are generally restricted to official and large-scale events (I am indeed a UIndy alum).

Finally, if you're wondering how I know all this, my previous job when I was still living in Indy was in a computer-based field and as such I learned quite a bit about the inner workings of the Indianapolis Internet Grid. I can say that unless things have dramatically changed in the ~11 months since I left the area, there were only about a dozen different IP ranges that encompassed all of Indy's public internet hotspots, from parks to cafes to guest networks at schools, you name it: everything was assigned within a limited number of ranges. This is ultimately was causes geolocation etc to be inaccurate, and also results in a ton of shared networks that might not otherwise be shared.

@Taking Out The Trash: The "edit filter stuff" is in Special:Diff/1041977607. Suffusion of Yellow (talk) 21:59, 16 November 2022 (UTC)

Ah. Though honestly that just looks like someone well versed in MediaWiki, not necessarily in the backstage areas of enwiki specifically. Taking Out The Trash (talk) 23:22, 16 November 2022 (UTC)

@Suffusion of Yellow: I've sent an e-mail to GN and zzuuzz. The information in question is not NDA'd, and indeed readily accessible by a large number of admins, but posting it publicly would still constitute OUTING. Also noting that I've removed some indentation in the collapsed section above because my reply refused to show up with otherwise. --Blablubbs (talk) 11:38, 16 November 2022 (UTC)

I've been pinged multiple times to chime in on this discussion. I've seen TOTT's work at WP:EF/FP and in my experience it seems great and shows a genuine need for EFH. On the surface I have no reason to oppose, but the concerns with possible loutsocking also concern me. Thus, I wouldn't mind seeing the info you have as well, @Blablubbs, if you don't mind sharing. I will try to investigate and draw my own conclusions. I myself was once wrongfully accused of socking, so I sympathize with the frustration TOTT might be experiencing in that regard. — MusikAnimal ^talk 23:45, 16 November 2022 (UTC)

If the information is not NDA'd, I'd ask that you please send it to me as well, with any private information that doesn't directly relate to me redacted as necessary. If I can review at least the gist of the evidence, I might grant permission for it to be posted publicly (thereby waiving any protections under OUTING), as I'm no longer living or working in the same place that I was when these events unfolded. Taking Out The Trash (talk) 15:06, 16 November 2022 (UTC)

So, SPI clerk hat on, the level of behavioral similarity with that IP is such that I would have made a tempblock if it had been reported to SPI in a timely fashion. I note that you later had IPBE revoked for cause, although the burden of proof for IPBE revocation is lower than for blocking. Now, hat off, as someone who's been not just falsely accused of socking but wrongly blocked for socking, and who's made hundreds of sockblocks, I constantly worry about "What if this user is the 0.1%? What if it's just the perfect storm of coincidences for them?" And I do worry that, in being relatively forgiving of people who own up to socking and relatively unforgiving of people who maintain their innocence, we create a perverse incentive for false confessions for those rare cases of people caught up in a series of improbably coincidences. Furthermore, while (pace two arbs' comments of late), editors are absolutely allowed to ask someone whether they edit from a given IP in the course of looking into abusive editing, admins cannot punish people for not answering (or at least that's how I interpret editors who have edited while logged out are never required to connect their usernames to their IP addresses on-wiki). Now, that doesn't directly apply here, but I do think it's, again, a bit of a perverse incentive to punish someone for being honest about their IP, when we wouldn't be allowed to punish them for not answering. (More broadly, if you ask me, we should repeal that clause of WP:SOCK, since editors always retain the RightToLeave and thus nothing an admin imposes really requires anyone to do anything, but as long as that's on the books, we should avoid situations that punish transparency.)
The upshot of that is... I'm willing to look past the still-IMO-probable loutsocking, given that there's been no recurrence, if you would otherwise meet the criteria for granting. But that's a big "if". The concern about your unstated previous account is independent from the loutsocking concern, and personally I couldn't see supporting without that in some way addressed. I recall that when Floquenbeam RfA'd, having abandoned a previous account for privacy reasons, he shared his old username with a functionary and had her give a broad summary of his previous editing patterns. Would you be open to doing that? -- Tamzin^{[cetacean needed]} (she|they|xe) 23:42, 16 November 2022 (UTC)
It might have been better to link directly to my RFA instead of ping me, because I have absolutely no understanding of what anyone is talking about here. ("LOUTSOCK" has always registered in my head as socking while acting like a lout, but apparently not) I dropped an old account with privacy issues, and created a new, normal, mortal account without telling anyone, as was my right. When I decided I wanted to run for admin, I felt - since it was probably obvious to everyone I had edited before, as the new account was kind of precocious - compelled to tell someone, so I first told a Checkuser (and later one Arb, and later one Crat, to appease people at the RFA), and proved it by emailing them from my old account too. Not so they could vouch for how wonderful I was when editing under the old account, but so they could vouch for there not being any skeletons in my closet. It was ultimately successful, but I was a little disappointed that all those people vouching for the old account was still not enough for a lot of people, and how much everyone seemed to think that the old account name was their business. I would imagine an Arb of your choosing might be willing to do the same. Personally, I wouldn't tell the whole committee if it's important to you: I'm not sure I'd consider the ArbCom mailing list 100% secure. If this trip down memory lane is useful info to anyone in this thread, I'll be pleasantly surprised. If more specific info is desired, let me know. Floquenbeam (talk) 00:07, 17 November 2022 (UTC)

So having now heard from everyone whom I wanted to hear from, plus one extra (thanks Floq), I'm getting a feeling that it might just be better to withdraw. Clearly I'm a controversial candidate, though I don't quite understand why. All this false sockpuppetry stuff is from over a year ago, and I don't see how any of it directly relates to my suitability and competence to work with the edit filters. That being said, I still would like to see for myself what "information" @Blablubbs: might have "against me" (since he has stated that it's not covered by the NDA) and, assuming there's nothing seriously compromising that could endanger my current job or link me to a real name or physical address or anything like that, I'd probably waive my protections under OUTING and allow it to be posted publicly so that everyone can see for themselves. But I'd have to see the information in question first, obviously with anything private that doesn't concern me redacted as appropriate. Additionally, in response to @Tamzin:, I don't see anything at WP:EFH that says identifying abandoned accounts/previous accounts before a WP:CLEANSTART is required for the granting of this permission (as opposed to, say, RFA or ACE where such a requirement is explicitly listed). If this is a requirement somewhere, I haven't seen it, and would have to ponder/consider the ramifications of doing such further before I could make a decision on that front. But I don't think it should be necessary. Taking Out The Trash (talk) 18:48, 17 November 2022 (UTC)
I found the conversation draining when we had it a year ago, and I don't want to have it again (nor do I wish to share my e-mail address); hence my staying out of this discussion. I've shared the information with interested functionaries; if one of them wants to pass it on, they should feel free to do so, but I'm out. --Blablubbs (talk) 18:57, 17 November 2022 (UTC)
I've seen the stuff, and I don't feel I'm in a position to disclose it further. But I can report on it. It all appears very intriguing, but it's not. In reality it merely supports what TOTT has told us, which is that certain IP address(es) were used by them at some point. We are back at square one, which is not exactly knowing whether more than one edit was made by TOTT using 199.8.32.6. That's about it, and that about all I foresee myself saying about it. I've said what I've said above. One last thing though: if TOTT decides they want to disclose their previous account(s) to me, in order for me to give a "broad summary", they can do that with absolute guarantees of confidentiality. Just email me to discuss the parameters. -- zzuuzz ^(talk) 19:52, 17 November 2022 (UTC)

It seems relevant to note that User:Taking Out The Trash has also been editing as Special:Contributions/47.227.95.73. This IP started editing prolifically a couple of months after User:Taking Out The Trash had supposedly stopped editing last year. In late August this year, the IP was criticised for incorrectly tagging things for speedy deletion, and stopped editing on 9 September. On 10 September, User:Taking Out The Trash returned with a particular interest in tagging things for speedy deletion. IP geolocates to Indianapolis, where the account is also known to have edited from. 109.144.214.144 (talk) 18:52, 17 November 2022 (UTC)

I don't see the necessary trust here. Private filters do a fair bit more than preventing people from replacing articles with swear words or putting pages "on wheels". There are a number of filters whose logs contain content that would be revdeled or oversighted if posted on-wiki (e.g. PII and libellous material). Because access to filter logs is not monitored, it's difficult to determine when or how the EFH right is abused. I am not saying that I believe this candidate, specifically, intends to use this right improperly, but I am saying that this concern necessitates a level of trust that is much greater than something like rollback or PCR, and as such a few months of responding {{Not done}} to vandals at EFFP isn't enough to overcome the doubts raised by others. The repeated agitation for making private filters public (mentioned by Zzuuzz above) adds to this concern IMO.
I don't know what "private evidence" is being referred to, and I don't have any interest in seeing it, but based on what I can see publicly (TOTT has acknowledged editing from 199.8.32.6 before; the IP has edited railfan topics that TOTT mentions on his userpage; the IP has displayed knowledge of projectspace that is unusual for an IP editor - and even most registered editors - but is consistent with TOTT's knowledge and interests) the denial of logged-out editing is frankly unconvincing. I also note that a checkuser revoked the editor's IPBE right based on technical evidence of IP socking [2].
As is mentioned above, TOTT admits to having a previous account that he doesn't want to disclose. That's fine and is permitted by WP:CLEANSTART. But considering TOTT's dedication to maintaining the privacy of his previous account, I would hope he could understand why people might be hesitant about granting a right that would - for example - allow someone to see every time an editor accidentally tried to link to C:\Users\Editor'sIRLName\Files\Example.JPG when they have reason to believe that the candidate is not being entirely transparent about their history (whether or not that is true). Spicy (talk) 20:10, 17 November 2022 (UTC)
- BTW, I started writing this before I saw the IP's comment above. None of my comments are in reference to the 47. IP. I've seen that IP around before and it seemed to have a distinctly different "vibe" from TOTT, although I haven't really looked into it and don't intend to do so. Spicy (talk) 20:13, 17 November 2022 (UTC)

I'll just say that the IPs comment is nothing but complete BS (no personal attack intended). There is absolutely no truth to that claim, and matter of fact, I had already left the Indianapolis area when I returned to editing in September. I continue to maintain that I have never edited logged out under any circumstance except for the one accidental edit that I've already claimed responsibility for, and will continue to maintain this position for the entire duration of my wiki career. Now, reading Spicy's comments almost makes me wonder if EFH should be an NDA permission, perhaps to be granted by ArbCom in the same way that CU and OS are. It just doesn't seem proper that a permission where numerous people are expressing concerns about access to private data can be assigned without technical limitation by administrators, who may or may not have signed the relevant agreements(s) since they're not required for RFA. Finally, I still don't see the correlation between "may have possibly edited while logged out a year ago" and "can be trusted not to leak the contents of private filters". Taking Out The Trash (talk) 21:21, 17 November 2022 (UTC)

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

Idea at WP:VPI: Enable the AbuseFilter blocking action

Latest comment: 1 year ago1 comment1 person in discussion

This is a continuation of the topic I brought up here a while back — your comments and suggestions are welcomed at this thread on WP:VPI. Many thanks — TheresNoTime (talk • they/them) 11:51, 29 November 2022 (UTC)

Lack of autocreateaccount on username filters

Latest comment: 1 year ago6 comments3 people in discussion

Is there any particular reason the log-only filters here only use createaccount instead of both createaccount and autocreateaccount? DatGuy^Talk_Contribs 20:05, 3 December 2022 (UTC)

Some of those say action contains "createaccount", which covers both possibilities of course. As to the others, I can't see any harm in logging autocreations. Suffusion of Yellow (talk) 20:11, 3 December 2022 (UTC)

I see, makes sense. I've updated the two remaining filters to 'contains' as well. DatGuy^Talk_Contribs 20:12, 3 December 2022 (UTC)

As an aside, I'm unsure about the effectiveness of Special:AbuseFilter/1196. It does indeed catch its target, but considering the type of target, wouldn't they just keep working until they find a username that isn't disallowed? DatGuy^Talk_Contribs 20:17, 3 December 2022 (UTC)

1196 was split out from 874 (hist · log) after this discussion. Personally I wish we had gone with my suggestion to throw some WP:TNT in the whole thing and start over. There might be an odd LTA whose only interest is impersonating other users. But usually impersonation is just one game they play, and they'll just continue disrupting, only under a less obvious username. Unless checkusers are actively monitoring the log, that is. @Zzuuzz: Do you (or any other CU) ever check the IPs of users tripping 1196 and related filters, to find out which username (if any) ended up getting through? Suffusion of Yellow (talk) 20:39, 3 December 2022 (UTC)

It's very uncommon, though it does happen. We usually pick up on their created accounts. Indeed they create other accounts and do disruption, but I don't think this negates preventing their preferred one. The further away their username is from the real one the better, IMO. -- zzuuzz ^(talk) 22:28, 3 December 2022 (UTC)

Set filter 979 to warn?

Latest comment: 1 year ago3 comments2 people in discussion

979 (hist · log) ("Accidental insertion of biomedical references", public)

See Wikipedia:Village pump (miscellaneous)/Archive 72#Paywalled 1970s biochemical articles used widely as references. I'm not sure what the warning should say, because I'm not totally certain why people are doing this in the first place. It's probably not intentional, because they never seem to cite PMID 69 or 420... But this covers the two most likely possibilities: (feel free edit)

An automated filter has identified this edit as citing an journal article with a very low PubMed ID (PMID). This is most commonly an error.

If you intended to cite a medical journal published in 1975 or 1976, please ignore this irrelevant message, and click "Publish changes" again.
If you did not intend this, please find and remove the citation before saving. If you are unable to find it, you can request assistance at the help desk.
Are you in visual editing mode?
If you are trying to add a new citation, note that citation numbers (^[1], ^[42], etc.) are created automatically. Do not put a number in the citation dialog. Instead, enter the URL of the source.

If you are trying to reuse an existing citation, first choose "Re-use" in the citation dialog, then select the citation from the list.
If this page contains no citations with low PubMed IDs, please click "Publish changes" again, and report this error.

I also suspect that this is going to be one of those filter where people say "Oh that warning isn't for me. It must be for that guy behind me." and click "publish" anyway. So maybe we should also consider the possibility of disallowing if this fails. Suffusion of Yellow (talk) 23:47, 29 November 2022 (UTC)

This looks good to me. Perhaps a link to the help desk or teahouse or something would be in order, but other then that it looks like it would help a lot - and having the filter set to log only means nothing if nobody's actually actioning on the log, does it? casualdejekyll 23:23, 5 December 2022 (UTC)

Noting that https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Citoid/+/864858/ has been merged. I think we should wait to see what effect that change has. IIUC correctly it should go live on enwiki next Thursday. Suffusion of Yellow (talk) 22:53, 9 December 2022 (UTC)

Add "ezproxy2" to proxy link filter

Latest comment: 1 year ago2 comments2 people in discussion

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)

Done ProcrastinatingReader (talk) 11:00, 11 December 2022 (UTC)

1202 cleanup

Latest comment: 1 year ago2 comments2 people in discussion

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)

1124 and unrelated occurrences of Among Us

Latest comment: 1 year ago5 comments3 people in discussion

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 [3][4][5][6] 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)

@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)

Should we add links to test filters in the header of WP:EFR?

Latest comment: 1 year ago2 comments2 people in discussion

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?

General test filters I found
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)

EFH request (Fehufanga)

Latest comment: 1 year ago7 comments6 people in discussion

Done per consensus below. — xaosflux ^Talk 00:52, 2 January 2023 (UTC)

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

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) (assign permissions)^{(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)}

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)

Support LGTM --DannyS712 (talk) 00:04, 2 January 2023 (UTC)

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

773 was temporarily set to disallow

Latest comment: 1 year ago1 comment1 person in discussion

due to an urgent need to prevent an active xwiki LTA. — TheresNoTime (talk • they/them) 06:39, 5 January 2023 (UTC)

A filter is blocking comments on SPI pages

Latest comment: 1 year ago2 comments2 people in discussion

Check my edit filter log. 2.97.25.205 (talk) 15:42, 25 January 2023 (UTC)

Wrong forum, and no it's not - try not blanking parts of the page when commenting.... — xaosflux ^Talk 16:21, 25 January 2023 (UTC)

Thank you for these filters!

Latest comment: 1 year ago1 comment1 person in discussion

Just saying, filters 894 and 1045 have been unreasonably effective at getting rid of bad sources via AWB regex. Kudos to anyone that has made these filters possible. CactiStaccingCrane (talk) 13:14, 14 January 2023 (UTC)

Filter 602 not alerting for non-first contentious topic alerts

Latest comment: 1 year ago4 comments2 people in discussion

There may be an issue in filter 602 when issuing the new non-first contentious topic alerts. While the filter triggers with the resulting system message when you use {{subst:alert/first|[topic code]}}, if you use the pre-existing method {{subst:alert|[topic code]}} you don't get the prompt to check the alerted user's talk page history.

Two diffs demonstrating this. In this edit, I issued three alerts using the {{subst:alert|[topic code]}}, not knowing the changeover to the updated template had happened, and received no prompt to check the talk page history. In this edit, I replaced the first alert from the previous edit with {{subst:alert/first|[topic code]}} and received the system message as I expected.

Code wise, this appears to be an issue with line 8 on the edit filter, which is only matching on templates that derive from /alert/first. Is this change in behaviour, where non-first alerts do not receive the system message intended? Footnote K on the new Contentious topics information page states that Editors should exercise caution before re-alerting an editor to the same contentious topic as a previous alert, as there is a presumption that an editor remains aware. which to me seems more onerous on the part of the alerting editor than was previously the case due to the lack of the system message after the first attempt at publishing an alert message, particularly as many editors will either archive or outright remove these messages, making searching for them difficult. The system message that was previously provided provides links to easily identify all of the previous alerts an editor has received via the filter log history.

If this is not intended, then the fix should be to add ctNonFirst := "-- Derived from Template:Contentious topics/alert --"; after current line 8, contains_any(lcase(added_lines), ctNonFirst, "subst:") after current line 12 (new line 13) , and change current lines 18+ (new lines 20+) to:

!( removed_lines irlike ctComment ) ) |
    ( added_lines_pst irlike ctNonFirst &
    !( removed_lines irlike ctNonFirst ) ) )

Sideswipe9th (talk) 20:40, 15 January 2023 (UTC)

Also just to note, at the time of writing these messages, the documentation for both Template:Contentious topics/alert and Template:Contentious topics/alert/first state that both templates should trigger filter 602 for logging/alerting. Sideswipe9th (talk) 20:57, 15 January 2023 (UTC)

@Sideswipe9th: Should be fixed now; see Special:AbuseLog/34251084. I just converted the whole thing to regex instead of adding another check. Let me know if there are any more issues. Suffusion of Yellow (talk) 22:59, 16 January 2023 (UTC)

Oooh, yeah a regex would do it! Looks good and having issued a warning earlier it does seem to be working. Thanks :) Sideswipe9th (talk) 00:03, 17 January 2023 (UTC)

Add new phrase to 614

Latest comment: 1 year ago2 comments2 people in discussion

The phrase "Waffle House found its new host": should be added to 614 since it's being used for WP:VD on especially the Waffle House page. I haven't seen this phrase anywhere else, although it may be a good idea to block this phrase from being added to pages by new and unregistered users. AKK700 02:11, 19 January 2023 (UTC)

If the phrase isn't used across multiple pages for vandalism, then it might be better to seek page protection (the page already semi-protected) or blocking of offending users instead. If you can provide examples of usage of this phrase in other articles then that would be great. 0xDeadbeef→∞ (talk to me) 03:24, 19 January 2023 (UTC)

Alternation in filter 935

Latest comment: 1 year ago2 comments2 people in discussion

I don't want to go into too much detail here because the filter is private, but there is an alternation in filter 935 that has been causing a number of false positives with a wiki-ed course. One of its conditions can be met by merely the letter "y," which seemed oddly broad to me. I asked TheresNoTime about it, but they don't seem to be available right now. Does anyone know why this condition exists and if it would be possible to refine or remove it? Feel free to email me the details if necessary. —Compassionate727 ^(T·C) 15:50, 21 January 2023 (UTC)

I've removed the stray y — that filter is fairly complex now, and might benefit from being split out — TheresNoTime (talk • they/them) 16:52, 21 January 2023 (UTC)

Condition limit

Latest comment: 1 year ago224 comments40 people in discussion

mw:Extension:AbuseFilter/Conditions

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)

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 ~~disabled~~ filters 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)

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)

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)

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)

Filter list

3

3 (hist · log) ("New user blanking articles", public)

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

5 (hist · log) ("User self-renaming or moving user talk pages into article talk space", public)

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

11 (hist · log) ("Warn and tag vandalism", public)

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

12 (hist · log) ("Replacing a page with obscenities", public)

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

29 (hist · log) ("New user removing speedy deletion templates", public)

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

30 (hist · log) ("Large deletion from article by new editors", public)

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

31 (hist · log) ("ASCII art", public)

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

33 (hist · log) ("Talk page blanking by unregistered/new user", public)

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 say Tweaking, 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 is page_namespace == 0 & ( /* N conditions */ ) and filter B is page_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)

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)

39

39 (hist · log) ("School libel and vandalism", public)

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

46 (hist · log) (""Poop" vandalism", public)

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

50 (hist · log) ("Shouting", public)

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

51 (hist · log) ("LTA username pattern hit (Oshwah)", private)

52

52 (hist · log) ("Edit summary vandalism II", private)

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

53 (hist · log) ("LTA edit summary or editing pattern hit (Oshwah)", private)

54

54 (hist · log) ("Promotional, group, organization, or company username (Oshwah)", public)

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

58 (hist · log) ("Long-term pattern abuse", private)

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

59 (hist · log) ("New user removing templates on image description", public)

61

61 (hist · log) ("New user removing references", public)

68

68 (hist · log) ("Pagemove throttle for new users", private)

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

79 (hist · log) ("New user removing reference grouping tags", public)

80

80 (hist · log) ("Link spamming", public)

98

98 (hist · log) ("Creating very short new article", public)

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

102 (hist · log) ("Abusive account names", private)

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

113 (hist · log) ("Misplaced #redirect in articles", public)

117

117 (hist · log) ("removal of Category:Living people", public)

132

132 (hist · log) ("Removal of all categories", public)

135

135 (hist · log) ("Repeating characters", public)

139

139 (hist · log) ("Fixed position vandalism", private)

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

148 (hist · log) ("Users creating autobiographies", public)

149

149 (hist · log) ("User adds link containing username", public)

164

164 (hist · log) ("Possible cut and paste moves", public)

172

172 (hist · log) ("Section blanking", public)

174

174 (hist · log) ("New user removing XfD template", public)

180

180 (hist · log) ("Large unwikified new article", public)

189

189 (hist · log) ("BLP vandalism or libel", public)

220

220 (hist · log) ("Adding external images/links", public)

225

225 (hist · log) ("Vandalism in all caps", public)

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:[7][8][9][10][11][12][13][14][15][16][17] Mako001 (C) (T) 🇺🇦 06:23, 26 November 2022 (UTC)

231

231 (hist · log) ("Long string of characters containing no spaces", public)

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

242 (hist · log) ("Redirecting a substantial existing page - new user throttle", private)

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. Java Hurricane 06:39, 3 November 2022 (UTC)

247

247 (hist · log) ("Adding emails in articles", public)

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

249 (hist · log) ("New user conducting large scale reverts", public)

260

260 (hist · log) ("Common vandal phrases", public)

264

264 (hist · log) ("Specific-page vandalism", private)

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

279 (hist · log) ("Repeated attempts to save edit", private)

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

294 (hist · log) ("Personal attacks", private)

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

316 (hist · log) ("Subtle changes to articles", private)

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

320 (hist · log) (""Your mom" Vandalism", public)

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

323 (hist · log) ("Undoing anti-vandalism bot", public)

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 as genderqueer), non-binary (also spelled nonbinary), and neopronouns (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)

345

345 (hist · log) ("Extraneous formatting from browser extension", public)

346

346 (hist · log) ("Large non-English contributions", public)

351

351 (hist · log) ("Text added after categories and interwiki", public)

354

354 (hist · log) ("Promotional text added by user to own user(-talk) page", private)

364

364 (hist · log) ("Changing the name in a BLP infobox", public)

365

365 (hist · log) ("Unusual changes to featured or good content", public)

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

380 (hist · log) ("Multiple obscenities", public)

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

384 (hist · log) ("Addition of bad words or other vandalism", public)

391

391 (hist · log) ("Changing height/weight in an infobox", public)

397

397 (hist · log) ("Userpage vandalism", private)

420

420 (hist · log) ("Large removal of talk page content by IP", public)

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

425 (hist · log) ("Magic/astrology spambots", private)

432

432 (hist · log) ("Starting new line with lowercase letters", public)

464

464 (hist · log) ("Possible open proxy", private)

466

466 (hist · log) ("Userspace & talk page spamming", private)

Can probably merge and optimise this, 794 (hist · log) and 974 (hist · log) ProcrastinatingReader (talk) 03:42, 30 October 2022 (UTC)

478

478 (hist · log) ("Talk page abuse", private)

491

491 (hist · log) ("Edits ending with emoticons or !", public)

499

499 (hist · log) ("Possible spambot or promotional username", private)

547

547 (hist · log) ("LTA 547", private)

550

550 (hist · log) ("nowiki tags inserted into an article", public)

554

554 (hist · log) ("top100 blog charts", public)

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

559 (hist · log) ("archive.is additions", private)

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

579 (hist · log) ("Possible sockpuppet account creations", private)

597

597 (hist · log) ("Europefan", private)

600

600 (hist · log) ("Possible template vandalism", private)

602

602 (hist · log) ("Arbitration discretionary sanctions alerts", public)

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

614 (hist · log) ("Memes and vandalism trends", public)

627

627 (hist · log) ("Promotional text added by user to draft in own user(-talk) page or in draft namespace", public)

630

630 (hist · log) ("New users de-userfying pages", private)

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)

631

631 (hist · log) ("Extraneous toolbar markup", public)

633

633 (hist · log) ("Possible canned edit summary", public)

636

636 (hist · log) ("Unexplained removal of sourced content", public)

639

639 (hist · log) ("persistent block evasion", private)

642

642 (hist · log) ("VRT template added by non-VRT member (global)", public)

643

643 (hist · log) ("Persistent sockpuppetry", private)

655

655 (hist · log) ("Large plot section addition", public)

657

657 (hist · log) ("Adding an external link to a disambiguation page", public)

664

664 (hist · log) ("Test edits", public)

667

667 (hist · log) ("Wikipedia:Long-term abuse/Best known for IP", private)

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

680 (hist · log) ("Adding emoji unicode characters", public)

686

686 (hist · log) ("New user adding possibly unreferenced material to BLP", public)

694

694 (hist · log) ("Moves to or from the Module namespace", public)

702

702 (hist · log) ("Warning against clipboard hijacking", public)

711

711 (hist · log) ("Dead link replacement", public)

712

712 (hist · log) ("Possibly changing date of birth or death", public)

716

716 (hist · log) ("New user tagging or de-tagging article as FA/GA", public)

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)

718

718 (hist · log) ("Prolific socker III", private)

733

733 (hist · log) ("New user creating a page in someone else's userspace", public)

735

735 (hist · log) ("Vandalising sport infobox", public)

738

738 (hist · log) ("Frequently blocked user", private)

739

739 (hist · log) ("User talk vandal", private)

This could probably be part-merged (somewhere?) and disabled. -- zzuuzz ^(talk) 05:57, 28 October 2022 (UTC)

752

752 (hist · log) ("Possible spamming of references", private)

753

753 (hist · log) ("wikilinks removed by a new user or IP", public)

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

762 (hist · log) ("TV/Movie spammer", private)

766

766 (hist · log) ("Alt-right labeling", public)

767

767 (hist · log) ("Prophecy spam", private)

768

768 (hist · log) ("AIV disruption", private)

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

777 (hist · log) ("End date present vandal", public)

782

782 (hist · log) ("Content Translation Edits", public)

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 check new_html on every edit, or at least every edit that adds a template. Suffusion of Yellow (talk) 22:32, 28 October 2022 (UTC)

788

788 (hist · log) ("IP removing report from RFPP", public)

793

793 (hist · log) ("Common spam/scam phone numbers", private)

794

794 (hist · log) ("Userspace spam", private)

797

797 (hist · log) ("Synth LTA", private)

798

798 (hist · log) ("Possible copyvio for image upload", public)

803

803 (hist · log) ("Prevent new users from editing other's user pages", public)

Created after this RFC. No obvious optimizations. Suffusion of Yellow (talk) 22:32, 29 October 2022 (UTC)

806

806 (hist · log) ("New account suspicious activity", private)

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

809 (hist · log) ("Possible SPI disruption", private)

812

812 (hist · log) ("Unreasonably large addition of content", public)

815

815 (hist · log) ("TV vandal", private)

826

826 (hist · log) ("Image flag vandal", private)

828

828 (hist · log) ("Redirecting talk page", public)

833

833 (hist · log) ("Newer user possibly adding unreferenced or improperly referenced material", public)

835

835 (hist · log) ("Temporary vandalism II", private)

837

837 (hist · log) ("Removal of disambiguation templates by new users", public)

846

846 (hist · log) ("LTA tracking", public)

847

847 (hist · log) ("The Sandbox Troll (WP:LTA/SBT)", private)

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

850 (hist · log) ("New user moving page to project space", public)

856

856 (hist · log) ("Non-admin or patroller removing copyvio templates", public)

862

862 (hist · log) ("Arabic string spam", public)

864

864 (hist · log) ("Kargbo Spammer", private)

867

867 (hist · log) ("Large creations by inexperienced user", public)

868

868 (hist · log) ("Template vandalism", private)

869

869 (hist · log) ("Adding deprecated source to articles", public)

871

871 (hist · log) ("Sock Filter", private)

874

874 (hist · log) ("LTA username creations", private)

878

878 (hist · log) ("New user removing COI template", public)

881

881 (hist · log) ("LTA 881", private)

885

885 (hist · log) ("LTA 885", private)

887

887 (hist · log) ("Excessive repetition in usernames", public)

889

889 (hist · log) ("Persistent PA", private)

890

890 (hist · log) ("Random typing in username", public)

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

891 (hist · log) ("Predatory open access journals", public)

892

892 (hist · log) ("RS linked through proxy", public)

894

894 (hist · log) ("Self-Published Sources", public)

901

901 (hist · log) ("Possible Drumpf plugin", public)

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

906 (hist · log) ("All namespace abuse", private)

909

909 (hist · log) ("Cutler Vandal", private)

916

916 (hist · log) ("LTA #916", private)

917

917 (hist · log) ("Prevent the addition of Daniel C. Boyer", private)

@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)

921

921 (hist · log) ("Suspicious claims of nazism", public)

923

923 (hist · log) ("Possible Nigerian phone scams", private)

Might be able to be merged with 793? Mako001 (C) (T) 🇺🇦 07:13, 26 November 2022 (UTC)

926

926 (hist · log) ("Image vandalism II", private)

927

927 (hist · log) ("LTA 927", private)

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

928 (hist · log) ("Transclusion of userpages", public)

930

930 (hist · log) ("Prevent indexing userspaces by newer users", public)

935

935 (hist · log) (""ntsamr"-pattern spambot filter", private)

936

936 (hist · log) ("LTA 936", private)

937

937 (hist · log) ("Qwertywander long-term abuse", private)

942

942 (hist · log) ("Log edits to protected pages", public)

What's the reason for this? Is this still being monitored? DatGuy^Talk_Contribs 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

954 (hist · log) ("LTA 954", private)

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

957 (hist · log) ("Removal of article lead", public)

958

958 (hist · log) ("CongressEdits", public)

960

960 (hist · log) ("Log edits to other user's scripts", public)

961

961 (hist · log) ("Disruptive Category Removal", private)

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

964 (hist · log) ("AfC unsourced submissions", public)

965

965 (hist · log) ("Indo-Aryan expletives", private)

Although not strictly an LTA filter, it does prevent some LTAs, so should remain private. ProcrastinatingReader (talk) 15:04, 7 November 2022 (UTC)

970

970 (hist · log) ("Possibly inaccurate edit summary", public)

971

971 (hist · log) ("Additions of missing files", public)

973

973 (hist · log) ("New or unregistered user modifying talk page archives", public)

974

974 (hist · log) ("Link-Spam catch", private)

979

979 (hist · log) ("Accidental insertion of biomedical references", public)

I'm not sure why this is still getting hits. The Visual Editor misfeature was fixed weeks ago with phab:T198456. Are people relying on VE's auto-save feature, and taking a long time to publish? Suffusion of Yellow (talk) 20:29, 6 January 2023 (UTC)

980

980 (hist · log) ("LTA 980", private)

981

981 (hist · log) ("Common vandal summaries", public)

982

982 (hist · log) ("Labelling of nationality as Jewish", public)

984

984 (hist · log) ("AIV disruption 2", private)

Effective, optimised, relevant, and worthwhile. No FPs worth bothering about. (though it's slightly misnamed). -- zzuuzz ^(talk) 05:58, 23 October 2022 (UTC)

986

986 (hist · log) ("Private filter 986", private)

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

987 (hist · log) ("Empty edit request", public)

989

989 (hist · log) ("Edits to other user's edit and email notices", public)

994

994 (hist · log) ("Article created as template", public)

996

996 (hist · log) ("LTA 996", private)

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

1000 (hist · log) ("Sydney days-of-the-year vandal", private)

@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)

Thanks,

Done. Suffusion of Yellow (talk) 20:26, 6 January 2023 (UTC)

1001

1001 (hist · log) ("Image changes by new users", private)

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

1007 (hist · log) ("Refspam detection", private)

Noting that ST47 has disabled this. Suffusion of Yellow (talk) 21:26, 9 November 2022 (UTC)

1011

1011 (hist · log) ("LTA 1011", private)

1012

1012 (hist · log) ("Wikidata page titles", public)

I look at this periodically. * Pppery * _{it has begun...} 01:44, 24 October 2022 (UTC)

1014

1014 (hist · log) ("Suffusion of Yellow public test filter", public)

1015

1015 (hist · log) ("long-term IP-hopping vandal detection", private)

1016

1016 (hist · log) ("file:// links", private)

@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

1017 (hist · log) ("LTA 1017", private)

1020

1020 (hist · log) ("LTA Europeanhaematology", public)

1022

1022 (hist · log) ("Vandal 1022", private)

1025

1025 (hist · log) ("SensitiveIPEdits", public)

1030

1030 (hist · log) ("Adding URLs with tracking parameters", public)

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

1031 (hist · log) ("New user editing mass message list", public)

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

1033 (hist · log) ("US politics BLP issue", private)

1034

1034 (hist · log) ("WikiLeaks", public)

1035

1035 (hist · log) ("Possible dead link replacement", public)

1037

1037 (hist · log) ("Sporadic LTAs", private)

1039

1039 (hist · log) ("privacy concerns", private)

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

1043 (hist · log) ("Social media spam", public)

1045

1045 (hist · log) ("Self-published (blog / web host)", public)

1048

1048 (hist · log) ("Possible spam", public)
- I check this one frequently. OhNoitsJamie ^Talk 14:28, 23 October 2022 (UTC)

1051

1051 (hist · log) ("India IP topic rangeblock", private)

1052

1052 (hist · log) ("Template substitution vandalism", private)

1053

1053 (hist · log) ("Personal attack on user or user talk page", private)

1055

1055 (hist · log) ("Unusual user talk page activity", private)

1057

1057 (hist · log) ("Citing Wikipedia", public)

1058

1058 (hist · log) ("LTA 1058", private)

1059

1059 (hist · log) ("LTA 1059", private)

@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

1060 (hist · log) ("Disallow CSD tag removal by page creator", public)

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

1062 (hist · log) ("Rickroll vandalism prevention", private)

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

1067 (hist · log) ("LTA 1067", private)

This LTA is active and the filter is effective with no FPs. No obvious optimisations. -- zzuuzz ^(talk) 17:15, 26 October 2022 (UTC)

1070

1070 (hist · log) ("LTA 8F0", private)

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

1073 (hist · log) ("Contest and editathon tracking", public)

1074

1074 (hist · log) ("Vandalism to Number Pages", public)

1075

1075 (hist · log) ("LTA 1075", private)

Large crossover with filter 1135. -- zzuuzz ^(talk) 20:36, 13 November 2022 (UTC)

1076

1076 (hist · log) ("Draftified article more than 180 days old", public)

1081

1081 (hist · log) ("Unreliable source added by revert, script or bot", public)

1082

1082 (hist · log) ("New user creating a user talk page redirect", private)

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

1084 (hist · log) ("Large non-free image uploads", public)

1086

1086 (hist · log) ("Disruptive edit summaries", public)

1088

1088 (hist · log) ("Added Facebook links", public)

1089

1089 (hist · log) ("LTA 1089", private)

@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

1090 (hist · log) ("Linking to draftspace or userspace from mainspace", public)

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

1093 (hist · log) ("New user modifying javascript in userspace", public)

1094

1094 (hist · log) ("miscellaneous LTAs", private)
- Actively in use for LTAs; should remain private. OhNoitsJamie ^Talk 14:25, 23 October 2022 (UTC)

1102

1102 (hist · log) ("Rapid disruption", private)

1106

1106 (hist · log) ("Caliphate disruption", private)

1107

1107 (hist · log) ("LTA 1107", private)

1109

1109 (hist · log) ("Possible promotional edit", private)

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)

1112

1112 (hist · log) (""Notable people" disruption", public)
- Useful for catching graffiti/vanity efforts. OhNoitsJamie ^Talk 14:29, 23 October 2022 (UTC)

1119

1119 (hist · log) ("Excerpt or labeled section transclusion removal", public)

1120

1120 (hist · log) ("Sneed/Chuck meme", private)

1121

1121 (hist · log) ("Climate color vandal", private)

1122

1122 (hist · log) ("LTA 1122", private)

1124

1124 (hist · log) (""Among Us" meme", public)

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

1125 (hist · log) ("proc private filter", private)

1129

1129 (hist · log) ("WP:DOYCITE", public)

1130

1130 (hist · log) ("LTA 1130", private)

1132

1132 (hist · log) ("Adding deprecated source to article talk pages", public)

1133

1133 (hist · log) ("LTA 1133", private)

Disabled, all FPs and (possibly) expensive. LTA apparently doing other things right now. Suffusion of Yellow (talk) 22:24, 8 January 2023 (UTC)

1135

1135 (hist · log) ("LTA 1135", private)

1140

1140 (hist · log) ("Rapid disruption II", private)

1141

1141 (hist · log) ("OpenSea spam links", private)

Disabled and made public per note in filter. ProcrastinatingReader (talk) 21:46, 26 October 2022 (UTC)

1145

1145 (hist · log) ("Removal of Turkish lang templates", public)

1151

1151 (hist · log) ("Projectspace blanking", public)

1152

1152 (hist · log) ("createaccount tracker", private)

@Zzuuzz, Billinghurst, MusikAnimal, and HelenDegenerate: So it looks like this was kept separate from the private LTA filters so that Helen could monitor the log, but then marked private anyway? In any case, no hits since 26 October and only 49 over the life of the filter. Any objections to merging with 579? Suffusion of Yellow (talk) 22:17, 8 January 2023 (UTC)

See history :) No objections here. Note some of it is already there. It's a bit of a long term meme - we could probably eventually end up in 874, if still necessary later. -- zzuuzz ^(talk) 23:03, 8 January 2023 (UTC)

It would have been of the moment. No issue. — billinghurst sDrewth 11:56, 9 January 2023 (UTC)

1153

1153 (hist · log) ("Arbitration Case Requests filed by new users", public)

@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

1154 (hist · log) ("Possible ARBPIA issue", public)

1155

1155 (hist · log) ("LTA 1155", private)

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

1156 (hist · log) ("LTA 1156", private)

1157

1157 (hist · log) ("Non-clerk/admin/CU tagging sock", private)

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

1159 (hist · log) ("Chris Chan monitoring", public)

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

1160 (hist · log) ("LTA 1160", private)

Active LTA ProcrastinatingReader (talk) 11:38, 23 October 2022 (UTC)

1161

1161 (hist · log) ("LTA: editor shopping by globally banned user", private)

1162

1162 (hist · log) ("Non-admin placing block templates", public)

1163

1163 (hist · log) ("Repeated text", public)

1168

1168 (hist · log) ("Misuse of Unicode mathematical or letterlike symbols in usernames", public)

1169

1169 (hist · log) ("Addition of tel links", public)

Disabled, recent hits don't look unrelated to the Safari bug that prompted this is the first place. It seems spammers only very rarely do this intentionally, so I don't think it's worth filtering. Suffusion of Yellow (talk) 22:07, 8 January 2023 (UTC)

1170

1170 (hist · log) ("Non-clerk/CU/bot editing SPI archives", public)

1171

1171 (hist · log) ("LTA 1171", private)

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

1174 (hist · log) ("WPTC", private)

1175

1175 (hist · log) ("LTA 1175", private)

1176

1176 (hist · log) ("WP:NOTWALLOFSHAME reminder", public)

1177

1177 (hist · log) ("LTA 1177", private)

1178

1178 (hist · log) ("Harassment pattern (TNT)", private)

1181

1181 (hist · log) ("LTA 1181", private)

1182

1182 (hist · log) ("LTA 1182", private)

1183

1183 (hist · log) ("Log uses of INDEX and NOINDEX", public)

1188

1188 (hist · log) ("Ukraine/Russia logging", public)

1193

1193 (hist · log) ("LTA 1193", private)

1194

1194 (hist · log) ("Track UPE links", private)

1195

1195 (hist · log) ("Template image vandalism", private)

1196

1196 (hist · log) ("LTA targeted username", private)

1197

1197 (hist · log) ("Excessive exclamation marks", public)

1199

1199 (hist · log) ("Unusual rate of edits from new user or IP", public)

1200

1200 (hist · log) ("Potential pronoun disruption", public)

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)

@Tamzin: I don't know if you have already thought about this, but I imagine most true positives on this filter should have an extremely predictable edit_delta: +1 per pronoun changed when converting from "he" to "she", -1 per pronoun changed when going from "she to he," and so on for the other possible changes. Would it be possible to capture the number of times a pronoun was changed and what that change was, then calculate the expected edit_delta if that was all the edit was doing, and check if that was actually the edit_delta? It would make the filter much longer, but it would probably make it possible to push the number of changes necessary before the filter trips much lower. —Compassionate727 ^(T·C) 02:34, 25 January 2023 (UTC)

@137a: No FPs on 1206 after 9 days with a threshold of 5 changes; now live on 1200. -- Tamzin^{[cetacean needed]} (she|they|xe) 12:33, 2 January 2023 (UTC)

1201

1201 (hist · log) ("Random sample of non-autoconfirmed edits", public)

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

1204 (hist · log) ("WP:BLPCRIME monitoring", public)

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

1205 (hist · log) ("LTA 1205", private)

1207

1207 (hist · log) ("Turkey -> Türkiye", public)

1208

1208 (hist · log) ("Possible claims of racism", public)
- This probably can ~~be combined with~~ absorb Special:AbuseFilter/921 ("Suspicious claims of nazism"). –MJL ‐Talk‐^☖ 04:43, 28 October 2022 (UTC)

1209

1209 (hist · log) ("Monkeypox vandalism", private)

Disabled, merged into 58 (hist · log). Also partially covered by several other filters. Suffusion of Yellow (talk) 02:09, 1 November 2022 (UTC)

1210

1210 (hist · log) ("Redirecting base user or talk page to other namespace", public)

@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)

1211

1211 (hist · log) ("Recession disruption", private)

@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

1212 (hist · log) ("Possibly claiming death of article subject", public)

1213

1213 (hist · log) ("Manual addition of automatic mediawiki categories", public)

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

1214 (hist · log) ("DatGuy's private test filter", private)

1215

1215 (hist · log) ("Rapid disruption III", private)

1216

1216 (hist · log) ("LTA 1216", private)

No true positive since late September, disabling for now. DatGuy^Talk_Contribs 15:20, 10 November 2022 (UTC)

1217

1217 (hist · log) ("Chris Chan disruption", private)

1218

1218 (hist · log) ("Empty unblock request", public)

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

1219 (hist · log) ("LTA 1219", private)

1220

1220 (hist · log) ("LTA 1220 (and others)", private)

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

1221 (hist · log) ("LTA 1221", private)

1222

1222 (hist · log) ("LTA 1122", private)

Merged with 906. No sign of them going away, but they seem like a low-effort LTA, or maybe even a bot. Suffusion of Yellow (talk) 21:49, 8 January 2023 (UTC)

1223

1223 (hist · log) ("LTA 1223", private)

1224

1224 (hist · log) ("LTA 1223", private)

@Suffusion of Yellow: seems like this could be renamed and made public. DatGuy^Talk_Contribs 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)

Disabled for now. Too many FPs, though I suppose targeting a narrower set of users might help. Suffusion of Yellow (talk) 21:01, 8 January 2023 (UTC)

1225

1225 (hist · log) ("LTA 1223", private)

Disabled for now. Might disable some other related filters soon. Suffusion of Yellow (talk) 23:31, 28 October 2022 (UTC)

1227

1227 (hist · log) ("Account monitoring", private)

Disabled; too much clutter in the log to be worth checking. Suffusion of Yellow (talk) 23:08, 20 November 2022 (UTC)

1229

1229 (hist · log) ("LTA 1223", private)

1230

1230 (hist · log) ("LTA 1230", private)

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)

FP with 1238

Latest comment: 1 year ago3 comments2 people in discussion

Got a blatant FP with 1238 today, see Special:AbuseLog/34305881. I have no clue what caused it; I'm barely a novice at regex, so this filter is way beyond my ability to read easily. Dropping a note here because I know most of you don't watch EF/FP very closely. —Compassionate727 ^(T·C) 01:57, 25 January 2023 (UTC)

Seems this was resolved just before you posted this. ProcrastinatingReader (talk) 11:39, 25 January 2023 (UTC)

Wonderful, thanks. —Compassionate727 ^(T·C) 13:01, 25 January 2023 (UTC)

Disallow egregious BLP vandalism

Latest comment: 1 year ago1 comment1 person in discussion

Please see Special:Contributions/73.60.157.32 (admin and oversight only). The filter should be blocking this kind of egregious BLP vandalism. However, the existing "BLP vandalism or libel" filter has too many false positives to be set to disallow. I suggest that a narrower/more specific filter should be used to disallow the addition of this kind of severe libel that could have legal ramifications. Taking Out The Trash (talk) 22:12, 26 January 2023 (UTC)

Requesting EFH: Red-tailed hawk

Latest comment: 1 year ago11 comments7 people in discussion

Granted per consensus below. — xaosflux ^Talk 23:29, 26 January 2023 (UTC)

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

Red-tailed hawk (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)}

Earliest closure has started. (refresh)

Hello. I'm Red-tailed hawk, an editor primarily active on EnWiki and Commons, as well as an administrator on the Uyghur Wikipedia (verify), a small wiki. I've recently been involved in reverting the vandalism associated with the Special:AbuseFilter/1238-related LTA. Generally, the LTA requires a number of people to handle at any one instance, and I would like to use my skills with regular expressions to help with debugging the abuse filter and proposing modifications should attacks become more sophisticated. I understand that this role would not grant me edit access directly; I would have to work with edit filter managers to implement any changes, but it's my hope that this would take off some of the burden from the users with more advanced permissions (such as oversighters and stewards) who are also dealing with this LTA.

With respect to access to nonpublic information, I am also a member of the Volunteer Response Team (verify) and I have signed the VRTS Users Confidentiality Agreement. Two-factor authentication is enabled on my account. — Red-tailed hawk _(nest) 21:21, 23 January 2023 (UTC)

On the one hand, I don't think we've generally endorsed EFH requests for single-filter use cases. OTOH, I'm not fully on board with the aforementioned stance, because ones 'ability to be useful' can expand once they have the permissions (and hence can see other private filters). Plus I remember Red-tailed hawk's name only in positive contexts, and think they're trustworthy. So I'd feel inclined to support, especially if Red-tailed hawk intends to be active with abuse-related issues in the future. @TheresNoTime, Tamzin, and AmandaNP: as active editors of 1238 (hist · log) in case you have any comments? ProcrastinatingReader (talk) 13:21, 24 January 2023 (UTC)

Thanks for the ping, Proc. I've known RTH for some time, on-wiki and off-. I've heard his voice, seen his face, and can vouch that he's an all-around trustworthy person, one of the most deeply principled Wikipedians I know. While we haven't talked much about regex in particular, I know him to be very technically competent, including having a good sense of his own competence in various technical fields. He's also not afraid to ask questions when he doesn't know something, and has no shortage of people in his orbit to discuss regex and filter syntax with. He and I do have this habit of disagreeing in basically every discussion we're in on-wiki, but that just makes me all the more pleased to have found one we can be on the same side of. Support. -- Tamzin^{[cetacean needed]} (she|they|xe) 17:00, 24 January 2023 (UTC)

Red-tailed hawk has been helping out with it for sure. I would prefer to have them as EFM so they could manage the filter themselves while I and others handle the oversight side of things in these stupid attacks, but I know I can't get everything I want. Red-tailed hawk has shown even more engineering stance that I have in being able to direct the best ways to add things to the filter. Them having the EFH permission would help, as they could see what is existing, suggest additions, and catch any errors we make with the filter because we are tired. -- Amanda (she/her) 14:30, 25 January 2023 (UTC)

Of the requirements I think the only thing that is really at question here is if there is a demonstrated need for access or not. Not quite sure if this is present; @Red-tailed hawk: assuming you get this flag, what are some actions you expect to take that you can not do now? — xaosflux ^Talk 18:07, 24 January 2023 (UTC)
Assuming I get this flag, I will be able to more effectively debug why certain edits are filter misses and will be able to propose more efficient fixes to the filter than I currently can. At the current moment, I cannot view the private filter, which is a significant hindrance to assisting in debugging the regex. I've privately proposed additions to the filter that have been previously implemented into it, but in doing so I've been working without visibility into the underlying filter when doing so. This lack of visibility both prevents me from helping EFMs to debug subtler regex issues and creates a risk that my proposed fixes would run up the condition count unnecessarily by being partly redundant to existing parts of the filter.

To also respond to ProcrastinatingReader's concern above, I would be happy to patrol WP:EFFP from time to time to respond to false positive reports. My motivating reason in requesting is to focus on debugging and helping improve private anti-abuse filters, but I would be more than happy to help clear that noticeboard should it become backlogged with requests that relate to private filters. — Red-tailed hawk _(nest) 18:33, 24 January 2023 (UTC)
To clarify, I did not mean helping out at EFFP necessarily (although any hands there are always appreciated!) I was largely getting at debugging and helping improve private anti-abuse filters in general (i.e. that your use of EFH in future will hopefully not be limited to this one filter, as single-filter LTAs are often transient), and not expecting any commitment to any particular task.

But with your note that you'd possibly be interested in helping out with other filters and/or EFFP in the future, and Tamzin's comments above, I'd be happy to support also. ProcrastinatingReader (talk) 11:36, 25 January 2023 (UTC)
Support. —Compassionate727 ^(T·C) 02:17, 25 January 2023 (UTC)
Support. I would have echoed xaosflux's concern above wrt demonstrated need but Red-tailed hawk's reply makes a reasonable case — TheresNoTime (talk • they/them) 01:44, 26 January 2023 (UTC)
Done — xaosflux ^Talk 23:29, 26 January 2023 (UTC)

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