We've had some issues here with WP:EFH requests, where any EFH would have access to all private filters, and their entire history as well. That usually results in excess caution when considering whether requests should be granted. Since many of our important filters are private, this makes it more difficult for people doing anti-vandalism tasks without EFH. It also adds a burden to WP:EFFP where only a select number of active EFMs are dealing with private filter FPs, and often they go archived without resolution if one of us aren't around.

I've two ideas that could help:

1. More fine-grained permissions in the AbuseFilter extension (ping Daimona Eaytoy). Allow viewing private filter logs and seeing log details, without seeing the filter regex. This could then be added into some right like rollbacker.
2. A Toolforge tool that uses OAuth to authenticate an editor, and for any appropriately permissioned users (e.g. rollbackers), shows the filter logs and log details for most private filters (excl some privacy ones etc).

Thoughts? ProcrastinatingReader (talk) 11:57, 8 September 2021 (UTC)

1. is already possible, see available rights. You could assign the abusefilter-log-private right instead of abusefilter-view-private. --Daimona Eaytoy (Talk) 12:06, 8 September 2021 (UTC)

• I think assigning abusefilter-log-private is a good idea. It could be handed out relatively liberally compared to EFH, however, I'm not convinced it should be bundled with rollback which IMO often has too low of a bar. Private filters can be used to prevent some pretty damaging edits which we don't want to be widely visible and we'd probably want people to sign up for. -- zzuuzz ^(talk) 18:04, 8 September 2021 (UTC)

  That's fair, but it also gets a bit confusing when we have too many user rights. Maybe EFH could be repurposed for this? EFH is (afaik) mainly composed of SPI clerks and trusted editors who only really use the logs, so a repurpose seems fine, and those that regularly need to craft filters (examine interface etc) could just request EFM. ProcrastinatingReader (talk) 18:16, 8 September 2021 (UTC)

  Another idea is a general 'trusted' user right that bundles together various restricted permissions for occasional usage (PCR, the hypothetical 'IP masking user right', etc). ProcrastinatingReader (talk) 18:17, 8 September 2021 (UTC)

  A trusted user right would be useful, as we do have a fair few rights like that, but I'm not sure what else would go in that toolkit. Maybe it could take a couple of less risky permissions currently in the admin toolkit?Jackattack1597 (talk) 20:58, 11 September 2021 (UTC)

• Comment In my opinion the problem is that we have too many private filters, which hinders routine anti-vandalism patrol via the filter log (which is primarily what I do, along with some new page patrol that often coincides). It is my belief (and I have no idea if I'm alone on this or not) that the only filters that should be private are the ones targeting specific long-term abuse or vandalism cases, or are otherwise intended to catch a certain specific user. Things like 34, 52, 68, 102, 242, 247, 279, 294, and 316 really don't need to be private IMO, since based on their titles they are targeting general everyday vandalism, disruption, and other common abuse. Many general anti-vandalism filters are public, so I don't see why these anti-vandalism filters that don't appear to be specific to a particular LTA can't be as well. Note that this list is just from the first page of Special:AbuseFilter, with deleted and disabled filters hidden from the query, as of 20:35, 12 September 2021 (UTC). There are definitely dozens more examples. I should note that I am actively considering applying for edit filter helper at some point in the future (probably pending the outcome of this discussion) due to the sheer number of private filters that are hindering both filter log countervandalism work and also clearing false positives. However, I have a feeling that I wouldn't be granted the rights because this is a clean start account, which brings me back to the primary point here which is that fewer filters should be hidden. Taking Out The Trash (talk) 20:35, 12 September 2021 (UTC)

I imagine 247 (hist · log) is private to protect the privacy of users who accidentally paste in email address. And 279 (hist · log) was public for a long while, but it was marked private because it very often trips when someone is hammering away at one of the private filters, so it effectively exposes the log of those filters. I'm not really sure why 34 (hist · log) is private, now that you say it. As to the others, well, not all LTA filters say "LTA" in the title.

To your second point, well since you brought it up, saying to an EFH applicant "Whose sock are you?" is casting WP:ASPERSIONS (Go ahead EEng. Do your thing.), but thinking it isn't, nor is mumbling something about "demonstrated need". ;-) Suffusion of Yellow (talk) 21:40, 12 September 2021 (UTC)

@Suffusion of Yellow: If people don't know why 34 is private, it probably shouldn't be. It seems odd that 33, which is essentially the same thing but in mainspace (standard talk pages) is public, warn, and tag, but 34 which is in user space is private and disallow. Additionally, my point was that the only filters that should be private are the ones targeting specific LTA cases, and therefore would have "LTA" in their titles. Things like edit summary vandalism and inappropriate usernames (52 and 102) are generic anti-vandalism filters that don't need to be private. I note that 102 is linked from WP:UAA as something patrollers should monitor... except they can't unless they are an admin or an EFH/EFM. Same goes for redirect abuse (242) - again, that's a general anti-vandalism filter as inappropriate redirects can be done by any drive-by vandal. Taking Out The Trash (talk) 18:16, 13 September 2021 (UTC)

Filters 52, 102, 294 are targeted at a surprisingly large number of specific LTAs, and not much else. Filters 34, 68, 242, 316 were created especially for one or more specific LTAs. They were made private to prevent these LTAs (who are familiar with filters) working around them. These filters also pre-date the current naming conventions by a long way. -- zzuuzz ^(talk) 19:41, 13 September 2021 (UTC)

@Zzuuzz: Considering that our most recent filters have IDs in the thousands, clearly these filters are very old. I'd be curious if it is known whether or not the original LTAs that the filters were created for are still active? Or have these filters over time gradually turned into general anti-disruption filters? Taking Out The Trash (talk) 17:52, 14 September 2021 (UTC)

I divided the filters into two groups. The former are targeted almost exclusively at current LTAs, the latter group includes current LTAs, at least some of whom are relevant to the creation of the filter(s). If there are candidates for seeding a new thread requesting a review of filters, I'd say the latter group, minus 68, which is probably the poster child for why some filters are private. I also think it's probably better practice to create new filters rather than turn what has been private public. -- zzuuzz ^(talk) 19:07, 14 September 2021 (UTC)

• (ec) I agree that rollbacker is too low a bar. What about this?
  1. Take away the abusefilter-view-private right from edit filter helpers, but keep abusefilter-log-private
  2. Send a mass message to all current EFHs: If they want to view private filters (or use Special:AbuseFilter/test) they can agree to not modify any filters and they'll grandfathered into EFM. No formal request or 7-day wait or anything like that; a note on their own talk page will do.
  3. Make getting EFH easier (but not as easy as rollback). Maybe a right a WP:PERM, or a "24 hours with no objections" here at EFN.
  4. If /test is ever split out as a separate right, assign that to EFH also.
• I'm not opposed to going with a third right ("edit filter helper light") instead, but it seems kind of silly when we have so few EFHs, I also like the idea of a "trusted user" group if anyone thinks such a RFC could ever succeed. Suffusion of Yellow (talk) 21:21, 12 September 2021 (UTC)
• Meh, EFH is already quite a low-bar - don't think we need a sub-efh. — xaosflux ^Talk 22:25, 12 September 2021 (UTC)
  • The success rate for EFH applications is like sub-20% (per archives) last time I crunched the numbers. I wouldn't say it's a low bar. ProcrastinatingReader (talk) 09:24, 18 September 2021 (UTC)
• Also, on general principle, it's stupid to impose social restrictions on technical permissions like Suffusion of Yellow proposed above; if you want there to be, socially, three levels of trust (can view private logs, can view private filters, can modify filters), then there's no good reason to shoehorn two of them into the same technical user group. * Pppery * _{it has begun...} 01:40, 13 September 2021 (UTC)
• Oppose To be frank, being able to see the logs of private filters without seeing the filter itself is useless in handling false positives or trying to do countervandalism from the edit filter log. Even if you can see the logs, if you can't see the filter you still don't know what exactly the filter was looking for, and therefore can't be certain if it's an FP or if it's revert-worthy. The same is true in reverse - being able to see filters but not their logs is also pointless, since even if you know what the filter is looking for you wouldn't be able to see the hits to investigate. To be useful, any permission short of actually modifying filters would need to include the ability to view both the filter conditions and the logs. Taking Out The Trash (talk) 18:16, 13 September 2021 (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 · fm · mms · npr · pm · pcr · rb · te)}

Okay, I recognize off the bat that this request is a bit unusual, but please hear me out and don't automatically oppose due to the (seemingly) young age of my account, as that is incredibly misleading. This is my second account on Wikipedia, and is a clean start. My previous account has been inactive since 2017. Under my previous account I attempted to do some content work, but just wasn't any good at it. As such, under this account I've decided to dedicate the vast majority of my efforts to countervandalism work. Most of my CV efforts are done in the form of patrolling the filter log looking for vandalism that slips through the filters, and reverting it accordingly. Additionally, I will also monitor accounts or IP addresses that are repeatedly tripping disallow filters, thereby flooding the log, and, assuming the flood is not the result of a false positive, I will issue {{uw-attempt}} warnings on their respective talk pages. Speaking of false positives, that's the other thing I do in addition to reverting vandalism - working WP:EFFP which appears to be extremely "short staffed" if you will. Many of the reports there are frivolous, but I've found a handful that are legitimate FPs (most commonly new users or IPs attempting to add titles of songs or song albums that happen to contain profanity, but it's not exclusively limited to that). However, the vast majority of the reports that get filed involve private filters. Sometimes, when the same edit trips multiple filters, and at least one of them is public, that's enough information for me to handle the report. Reports that involve exclusively private filters, however, especially ones where the filter title is ambiguous and therefore doesn't provide any hints whatsoever as to what it's looking for, I can't handle. Many of these reports simply go unactioned and will be automatically archived by the bot without a response, which isn't a good thing. The same problem exists with filter log flooding - if a particular user is flooding the log, but all of the filters they are tripping are private without an explanatory title, I have no idea whether it's a vandal being successfully stopped, or if it's a good-faith editor being caught in a string of false positives. That's not good either - even though a majority of the time it's the former, it only takes the latter to happen once for a potential new contributor to be driven away. After all, it's a bad first impression to have your edits blocked by some automated process and not get an answer as to why.

In summary, I am requesting Edit Filter Helper permissions for two reasons. One, to be able to assist better and more completely with false positive reports. As it stands now, it seems to only be myself and one other editor who routinely check that noticeboard, which is a problem in and of itself, but would be less of a problem if I could evaluate more of the reports. Secondly, when patrolling the edit filter log for vandalism that slips through the cracks, it would be helpful for me to know when an edit that tripped a private filter should be reverted (or even the user reported, in dealing with long-term abuse cases), or if something is a false positive that can be ignored assuming it wasn't disallowed. This access will greatly improve my ability to keep Wikipedia free of vandalism and other unwanted content, which, after all, is my primary purpose here at the present time. I will answer any questions to the best of my ability - please ping me upon asking a question.

Rundown of requirements for granting as listed at WP:EFH:

Must meet all of the following criteria:

Y Demonstrated need for access (e.g. SPI clerk, involvement with edit filters) – I think that being able to help evaluate false positive reports more completely and being able to evaluate filter log hits more completely both qualify as a "demonstrated need for access", especially considering that I seem to be one of only two active editors at the FP report page

Y No recent blocks or relevant sanctions – clean block log

Y At least basic understanding of account security – can confirm that I have a strong password

Yg At least basic understanding of regular expressions if the intent is to assist with authoring filters –  Not Applicable as I do not plan on assisting with authoring filters at the present time

Y Sufficient ability with the English language to understand notes and explanations for edit filters – native speaker of American English

Must also meet at least one of the following criteria:

Y Currently-active extended confirmed editor on the English Wikipedia (i.e. has made edits or logged actions within the last 12 months)

N Current administrator on another WMF project –  Not Applicable since the first criteria is met and only one is required

N Current edit filter manager on another WMF project –  Not Applicable since the first criteria is met and only one is required

N Current WMF developer or staff member who needs access for WMF-related purposes –  Not Applicable since the first criteria is met and only one is required

Taking Out The Trash (talk) 15:42, 17 September 2021 (UTC)

Discuss (EFH Taking Out The Trash)

• @Taking Out The Trash: you have a relatively new account and small number of contributions - are there any specific admins you have been working closely with if you have been resolving false positives? Having them speak on your behalf here could go a long way. — xaosflux ^Talk 23:28, 17 September 2021 (UTC)

@Xaosflux: My response to this question would essentially be "what ProcrastinatingReader said below". Taking Out The Trash (talk) 13:55, 18 September 2021 (UTC)

• From my experience, Taking Out The Trash has been competent, has a valid need, and would make good use of the permission. The account is newer, but I don't think the editor is a sock, which is the degree to which tenure matters as this is just a viewing permission. So honestly I'd probably lean support on this one. It's kinda hard to be working closely with an admin or EFM on filter-related things, in part because non-EFH editors don't have access to any of the interfaces so it's excessively burdensome to get much done. Generally I think this would only happen in niche cases (eg people from different areas working together, like a SPI regular working with a filter regular). ProcrastinatingReader (talk) 09:24, 18 September 2021 (UTC)
• I oppose granting the permission, at least for now. While I appreciate that you may have more experience because of a prior account, your current one (and the only one whose track record we can assess), was registered only 38 days ago, and only obtained (temporary) rollback rights today. Some of these filters contain fairly sensitive material, and I wouldn't be comfortable granting the right to someone where there is so little track record to be evaluated. --Blablubbs (talk) 16:05, 18 September 2021 (UTC)
• I cannot support at this time, regretfully. Taking Out The Trash seems competent enough, but I just can't support granting EFH - a sensitive perm whose abuse is nigh-impossible to detect - to an account that's barely a month old. GeneralNotability (talk) 16:08, 18 September 2021 (UTC)
• (edit conflict × 2) The point of a clean start is that it's clean. I don't think it's appropriate to rely on your status of "Someone who had another account previously" without disclosing what that account is. Otherwise, you should be held to the same standards as any other month-old account. I myself picked up perms quite quickly as a new user (rollback after two weeks, among other things), but even if EFH had existed back then I would have never dreamed of requesting it. I don't think there's any amount of good work someone could do in a month (or really less than six months) that would convince me they can be trusted with EFH. -- Tamzin^{[cetacean needed]} (she/they) 16:12, 18 September 2021 (UTC)
• Requestor Comment If I may, I honestly find the comments above regarding tenure to be a little insulting, especially when the comments amount to "they know what they're doing but they need to wait longer for some unstated reason". Tenure is not a measure of competence - someone could have years of editing experience and not be competent to work with filters (there are probably existing admins to whom this would apply). Likewise, someone can be competent to work with filters with less total tenure, which is the situation that I'm in. As it stands now, there is no tenure requirement listed at WP:EFH other than being extended confirmed, though it sounds like there might be a desire to change that (?). I would oppose such a change though - saying that someone needs X number of months before even being considered for Y permission regardless of their edits and productivity is simply not fair. We shouldn't be setting arbitrary tenure requirements for permissions - each and every application should be evaluated on its merits and based on whether or not the user in question is believed to have enough experience to use the permission correctly and appropriately. If there is reasonable confidence that a user will not misuse a permission they have requested, that should be adequate to approve the request, regardless of how long they've been around. Taking Out The Trash (talk) 18:01, 18 September 2021 (UTC)

  P.S. As I noted in the section above, this request wouldn't even be neccesary at this time if we didn't have so many private filters (too many IMO), but it seems there's no consensus to change that. Taking Out The Trash (talk) 18:01, 18 September 2021 (UTC)

  Taking Out The Trash, to me EFH is about trust more than anything else. Whether or not you have the competence to have EFH is not in question here. The question is whether or not I am willing to trust you with the details of our private filters. To be blunt: no, I do not currently trust you that much, and that is heavily influenced by account age. Am I being excessively paranoid? Quite possibly. Perhaps you will earn that trust at some point in the future, at which point I will happily support you for EFH. GeneralNotability (talk) 18:08, 18 September 2021 (UTC)

  I still fail to understand what the (supposed?) connection is between account age and the risk of, oh, I don't know, me going and leaking all of the private filters on Wikipediocracy. As far as I can fathom, account age has nothing to do with mitigating that risk. Taking Out The Trash (talk) 18:55, 18 September 2021 (UTC)

  Account age does not per se mitigate the risk. What mitigates (or lessens) the risk is people having earned the community's trust that they won't abuse the perm. It's not that we would automatically grant EFH to anyone who's been around 6 months or a year or whatever; it's that, after that much time, we would (hopefully) have developed senses of whether we can trust them. Not just whether we can trust them to not intentionally abuse the permission, but also whether we can trust them to make good decisions, and, particularly for EFH, to know which things should and shouldn't be said in public. It's entirely possible that you have amazing judgment and are a master of OpSec. But I have no way to know that yet. There's just not enough data. -- Tamzin^{[cetacean needed]} (she/they) 19:22, 18 September 2021 (UTC)

•  Request withdrawn The responses here are, to put it politely, disappointing. Additionally, I'm concerned that some sort of yet-to-be-explicitly-defined tenure requirement is being applied here, but no such requirement is listed at WP:EFH beyond being extended confirmed. I'd suggest a discussion to consider changing that if this is the norm/expectation among most editors. Finally, I'd encourage existing EFH/EFM/admins to please, please, help with the false positives board, specifically the reports where all of the filters that were tripped are private (i.e. there was no public filter tripped simultaneously that allows others to see the blocked edit in question) and/or where private filters with ambiguous titles are involved (i.e. cases where you can't really deduce what the filter is checking for without seeing the filter itself). Taking Out The Trash (talk) 19:24, 18 September 2021 (UTC)

  The Wikipedia:Edit filter helper policy has not lined up with practice at this noticeboard for a long time, possibly since the day the user right was first created. ProcrastinatingReader (talk) 23:59, 18 September 2021 (UTC)

  And that is a serious problem. Either this noticeboard needs to get in line with what the policy says, or the policy needs to be changed to reflect what this noticeboard expects/desires. I'm not sure which one is more prudent in this circumstance, but something needs to be done. Taking Out The Trash (talk) 14:28, 19 September 2021 (UTC)

  I made a slight modification. ProcrastinatingReader (talk) 15:14, 19 September 2021 (UTC)

  I think that's a good way to put it, yeah. I would object to any change to the policy that focuses specifically on account age, because that's just one factor of many, but specifically noting the importance of trust, and of the discretion of individual editors responding here, seems like a good approach. -- Tamzin^{[cetacean needed]} (she/they) 15:29, 19 September 2021 (UTC)

This is an issue that has been increasing over the last couple of years, due to incidents in the news, involving both BLP and historical bios. It involves the words "white racist", "racist" "racist white supremacist" or variations - always in the lead sentence of an article, "(person) is/was a white racist supremacist". That seems to be a going trend to edit Wikipedia to insert racism labels in the lead sentence. Is there a way this can be filtered out, or do we editors just keep on manually doing the reverts? We can't watch list every bio out there. — Maile (talk) 17:37, 30 September 2021 (UTC)

@Maile66: if a set phrase is constantly, and inappropriately, being added - it can likely be handled by a filter. Please gather a few recent diff's, the collection of phrases - and drop a request over at WP:EF/REQ. A filter can first be built in logging mode to validate it, then it can either "tag" or actually block edits if warranted. — xaosflux ^Talk 19:00, 30 September 2021 (UTC)

Thanks. I'm going to copy this thread to my own talk page, and take care of it at the right time. Today's edits were on historical figures. But I'd like to act on this when I see more serious ones, as in the recent months, I've seen these labels added to BLP office holders. Thanks for the advice. — Maile (talk) 19:24, 30 September 2021 (UTC)

AbuseFilter 602 was created in 2014, with Template:Z33 being set as the trigger when Template:Ds/alert was placed on a userpage. Following a recent TFD it was decided that the z-number templates should be deleted as being no longer necessary, mainly because the insource search functionality makes them redundant. Since Z33 triggers an edit filter, I thought I would check here to make sure the filter is properly updated to no longer look for this string before it is removed from the ds/alert and from current use. (please ping on reply) Primefac (talk) 13:19, 24 September 2021 (UTC)

At a glance I'm not sure why that check is required. Why is a check for -- derived from template:ds/alert -- (a variant of the line above the Z33 one) not sufficient? Ping @AGK: who I think wrote that functionality. ProcrastinatingReader (talk) 13:41, 24 September 2021 (UTC)

That change produces zero false negatives in the last 300 hits. Not sure about FPs, but that seems unlikely. Suffusion of Yellow (talk) 21:13, 26 September 2021 (UTC)

So the Z33 check can be removed without issue? Primefac (talk) 21:19, 28 September 2021 (UTC)

@Primefac:  Done. It should be fine to remove the template from ds/alert now. Suffusion of Yellow (talk) 22:02, 2 October 2021 (UTC)

Excellent, thanks. Primefac (talk) 12:34, 3 October 2021 (UTC)

Why is this filter tripping on the action autocreateaccount, which I assume means an already-existing global account being automatically created locally upon the user's first visit to this wiki? This is generating a ton of false positives, way too many to report, of users with preexisting global accounts (in good standing) who are blocked from merging their account locally on enwiki, despite their username not closely resembling any high-profile user here (and I think AntiSpoof would block the creation of a global account that has a username extremely similar to a preexisting account, if I'm not mistaken). Chances are, if someone created their account initially on a different project, they are not attempting to impersonate anyone here, since someone attempting to impersonate someone from enwiki would attempt to create the impersonation account on enwiki. Therefore, should this filter be changed to only trigger on createaccount, meaning manual account creation on this wiki? I'd also wonder why global AntiSpoof isn't sufficient for this purpose, since it would catch most would-be-impersonations before they can even be created elsewhere. Taking Out The Trash (talk) 18:18, 12 October 2021 (UTC)

@Taking Out The Trash: which filter ID# are you referring to? — xaosflux ^Talk 18:24, 12 October 2021 (UTC)

@Xaosflux: I don't know, because it's private. All I see is the filter being tripped in the logs, with tons of false positives where the global account attempting to be merged doesn't impersonate anyone or anything (at least not obviously) and the global account is otherwise in good standing. Taking Out The Trash (talk) 18:25, 12 October 2021 (UTC)

My understanding is that Global Antispoof...isn't great. And regarding if someone created their account initially on a different project, they are not attempting to impersonate anyone here, since someone attempting to impersonate someone from enwiki would attempt to create the impersonation account on enwiki - doubtful, I have absolutely seen harassment accounts created on other wikis to evade local filters. GeneralNotability (talk) 18:27, 12 October 2021 (UTC)

• OK, seems that this is private filter Special:AbuseFilter/874. — xaosflux ^Talk 18:27, 12 October 2021 (UTC)
  • I'm not seeing any overwhelming number of FP's on this. — xaosflux ^Talk 18:29, 12 October 2021 (UTC)

Well, the impetus for me filing this thread was this lovely flooding of the filter log (granted, the first set of attempts were a few days ago).. but I don't see anything particularly wrong with that username, and the global account appears to be in good standing. This also isn't the first time I've noticed these types of situations. Taking Out The Trash (talk) 18:37, 12 October 2021 (UTC)

@Taking Out The Trash: that specific ones seems to be a FP, and you can report it at WP:EF/FP; that being said it seems to be a suspect account based on the contributions at commonswiki so far so I don't think we would attach it locally without a specific request from that account holder (such as via VRT). — xaosflux ^Talk 18:51, 12 October 2021 (UTC)

@Xaosflux: Firstly, what the heck is "VRT"? (and if I have no clue what that is, can we expect some new user caught in an FP to know what it is?) Secondly, I guess I am of the opinion that we shouldn't be disallowing the automatic attachments of global accounts with the exception of usernames that would be immediately blocked at UAA without waiting for edits. Especially because, now that I think about it, chances are they won't even see the disallow message, since auto account creation/merging usually doesn't require a specific action from the user. Their account just wouldn't get created here, and they'd have no reason to know why. Taking Out The Trash (talk) 18:56, 12 October 2021 (UTC)

@Taking Out The Trash: WP:VRT - and again, for this specific case feel free to report at FP. — xaosflux ^Talk 18:59, 12 October 2021 (UTC)

Anti-spoof has limits - it's basically a character substitution test, and not a particularly good one, whereas we can use regex and substitution and some other stuff. I think this filter does tend to have too many false positives, but as for the rest, the filter is mainly for LTAs and not just impersonations. A lot of LTAs create their account elsewhere. For example, we're glad that Special:CentralAuth/V4Nd4L15M_45_4_53rV1c3 couldn't register here. -- zzuuzz ^(talk) 18:35, 12 October 2021 (UTC)

• As mentioned above: there are a fair few LTAs who create global accounts on other wikis and then move to enwiki; I deal with a fair few on a daily base. That is the reason why autoaccountcreate actions also trip the filter. JavaHurricane 06:40, 27 October 2021 (UTC)

• 1169 (hist · log)
• EFR Request
• VPT discussion

The filter log for 1169 shows a reasonable volume in bad telephone links being added, apparently unintentionally and seemingly due to a bug in Minerva (mobile web). Would it be fair to move 1169 to warn? ProcrastinatingReader (talk) 10:29, 10 October 2021 (UTC)

A couple of thoughts: We should probably at least exclude bots. I'm thinking mainly of revert-bots, although reverts (i.e. content restoration) may generally be an issue as long as this text already exists (I expect most humans could probably just deal with it, although maybe not ideal). We'd also need a meaningful error message, since it's usually (but not always) an unintended action, and it's a bit difficult to respond in the affirmative without seeing that. -- zzuuzz ^(talk) 11:08, 10 October 2021 (UTC)

This can definitely be improved, but it's the best I can do right now. Invalid^OS_talk 11:50, 12 October 2021 (UTC)

Well they wouldn't need to revert it, they would abandon it. And couldn't they just review and fix it? — xaosflux ^Talk 13:17, 12 October 2021 (UTC)

I'm not sure if the problem is in the browser or mobile VE. I think it's the latter, in which case they could only fix it by source editing or on a desktop. ProcrastinatingReader (talk) 14:05, 12 October 2021 (UTC)

@ProcrastinatingReader: from my earlier tests, I'm 90% sure this is a client-side browser issue. If it was VE while in minerva it should be trivial to reproduce, and we would want a high priority phab ticket opened on it. — xaosflux ^Talk 15:30, 12 October 2021 (UTC)

@Xaosflux: Here's a revised version of the warning:

Invalid^OS_talk 11:51, 13 October 2021 (UTC)

• I excluded bots. — xaosflux ^Talk 13:15, 12 October 2021 (UTC)

If we can limit this with user_mobile == true, either with an a/b filter setup or by looking through the logs, I think it would be preferable to do that - it would save hassling most of the reverters. -- zzuuzz ^(talk) 16:25, 12 October 2021 (UTC)

On looking further, I see that Special:AbuseLog/31062535 was not on a mobile. -- zzuuzz ^(talk) 16:38, 12 October 2021 (UTC)

I think the combination that causes this is Mobile Safari + VisualEditor. At least, I couldn't reproduce it on Chrome or Firefox on Android. I don't think it matters if they're using the mobile or desktop version of Wikipedia; I see <meta name="format-detection" content="telephone=no"/> on both the desktop and mobile site; it's just Safari being brain-damaged here. Suffusion of Yellow (talk) 22:08, 12 October 2021 (UTC)

@Zzuuzz, Xaosflux, Suffusion of Yellow, and InvalidOS: What do we think about the latest revision of the filter (thanks xaos & SoY) and the warning template designed by InvalidOS above? Does that seem good to go? I would note that an alternate approach might be not to bug editors about this at all (to avoid abandoned edits) and just have a bot go around and remove the tel links after the edit. I think that might be more ideal actually? ProcrastinatingReader (talk) 11:14, 22 October 2021 (UTC)

That might not be ideal if a vandal was spamming tel links, since it could make it harder for people to detect vandalism going on. We could still have the filter set to tag/log-only, though I'm not sure if a bot would actually be more ideal. Invalid^OS_talk 15:07, 22 October 2021 (UTC)

The alternative seems an improvement to me. Based on this diff, it looks like Safari also has a problem with '/'. If a bot is going to get involved, it may be better to run off the filter logs and apply some intelligence. It would be good if they could do it - do we have such a bot? And now another silly question: can Safari + VE editors actually see warnings? -- zzuuzz ^(talk) 16:59, 22 October 2021 (UTC)

Re warnings: I think yes for mobile web (because this will be on articles). Will link here from WP:BOTREQ regarding the bot part. ProcrastinatingReader (talk) 16:15, 27 October 2021 (UTC)

• 1163 (hist · log)

Could this one be suitable to move to disallow? The purpose is just repeated expressions, but with a throttle (without throttle caused too many FPs, see 2 (hist · log)). Probably fine to unprivate it and make the title more descriptive. It was originally made as a general solution to a specific LTA, although its scope is broader, and most its hits are regular & rapid vandalism rather than LTA vandalism. The issue with the non-throttle EF 2 (discussed with Suffusion of Yellow a couple months ago) was primarily FPs when people were editing tables. That's less common in the samples of EF 1163 diffs I've checked. ProcrastinatingReader (talk) 16:13, 27 October 2021 (UTC)

• Don't think it needs to be private, and can have a useful description. — xaosflux ^Talk 01:41, 28 October 2021 (UTC)
• @ProcrastinatingReader: Still unsure about disallowing, but agree that it can be public. Anyone who can figure out that regex will be capable of finding 100 other ways to disrupt. Suffusion of Yellow (talk) 00:16, 30 October 2021 (UTC)

• 1151 (hist · log)

See this lovely flooding of the filter log... I'm pretty sure almost all of those hits are FPs. Taking Out The Trash (talk) 14:59, 31 October 2021 (UTC)

@Taking Out The Trash: Thanks for reminding me about that filter. I've made a simple change, but it still needs a lot of work before setting to warn/disallow. Suffusion of Yellow (talk) 18:19, 31 October 2021 (UTC)

While looking through the Help Desk archives, I found this question that went unanswered and I was wondering what the person could do.— Vchimpanzee • talk • contributions • 17:29, 23 November 2021 (UTC)

@Vchimpanzee: yes, for example public filter Special:AbuseFilter/225 also checks the summary field. — xaosflux ^Talk 22:33, 23 November 2021 (UTC)

There's also 1086 (hist · log) which I never got around to finishing. The main problems is that "good" edits sometimes have "bad" edit summaries. Where I might say "reverted promotional puffery"; someone else might say "removed promotional bullshit", etc. Suffusion of Yellow (talk) 22:34, 23 November 2021 (UTC)

Thanks. I'll let the person know.— Vchimpanzee • talk • contributions • 22:45, 23 November 2021 (UTC)

Moved from WP:EFR

 – Suffusion of Yellow (talk) 20:09, 20 December 2021 (UTC)

I triggered Special:AbuseLog/31536074 when I tried to add this PDF source from EBSCO Information Services:

Hall, James (February 2014). "The Super Six". Outdoor Life. Vol. 221, no. 2. p. 42. Archived from the original on 2021-12-18. Retrieved 2021-12-18 – via EBSCO Information Services. {{cite news}}: |archive-date= / |archive-url= timestamp mismatch; 2021-12-19 suggested (help)

I created the PDF link by visiting EBSCO Information Services through Wikipedia:The Wikipedia Library, conducting a search for sources, and opening the PDF of one the results which I included in the citation template. I archived the PDF through the Wayback Machine. I think links like these should be allowed. Cunard (talk) 10:51, 19 December 2021 (UTC)

@Cunard: The "original" link is already dead for me. Which, if I understand correctly, is the point of the filter: those links are ephemeral. Or are you suggesting that archive.org links containing "ebcsohost.com" should be allowed? Suffusion of Yellow (talk) 04:08, 20 December 2021 (UTC)

@Suffusion of Yellow: I would like for the archive.org links containing "ebscohost.com" to be allowed. I am putting the archive.org link containing "ebscohost.com" in the |archiveurl= parameter of Template:Cite news. When I do this, I also need to supply the "ebscohost.com" link in the |url= parameter. I think this should be allowed since the ephemeral link issue is handled by archiving the links through the Wayback Machine. Cunard (talk) 04:50, 20 December 2021 (UTC)

@Cunard: If I'm understanding correctly, you're using an ephemeral URL supplied through your EBSCO account to cause the Wayback Machine to make something public that was never publicly viewable in the first place. That seems ... questionable ... from a copyright perspective. Pinging @Cyberpower678 and Beetstra: who might know more. Suffusion of Yellow (talk) 20:17, 20 December 2021 (UTC)

Yeah... I mean the actual URL is dead for a reason; those links tend to expire. So using archive.org to cache it is questionable from a copyright perspective IMO. OP could cite the source without a URL to it. ProcrastinatingReader (talk) 20:31, 21 December 2021 (UTC)

@Cunard: the material that you archived is NOT on ebscohost, it is material from outdoorlife.com. The archive link on archive.org is now pointing to a non-existing 'source' of material that is behind a paywall. We allow archive.org links because they point to the original place of the material. That is here obviously not the case. Ebscohost links are dead for everyone else but you (often you yourself can't even re-use links after you do a fresh login, change machine). That link ('the original') is simply worthless and never suitable as a reference link. And if archive.org is not archiving the original because outdoorlife.com does not want them to archive the original then what you now did on archive.org is plain copyvio (and hence, we should never link to the archive.org link).
That ther is not a direct link (to behind the paywall of outdoorlife.com) does not disqualify the reference. 'James Hall (February 2014) "The Super six", Outdoor life, 221 (2). p40-44' works perfectly fine (that is how found it through my ebscohost access). Maybe someone who has direct access to outdoorlife.com will at some point add a working direct link. Dirk Beetstra ^{T C} 06:01, 22 December 2021 (UTC)

Hi, I'm totally new here and am interested in becoming a filter manager. I've familiarized myself with the guidelines of edit filters and taken a few hours to go through some examples. I have experience programming and am proficient in Regexes, and am confident that I can technically manage the edit filters. I understand that I'm totally new and that the community has no reason to trust me, so I'm willing to start by being a helper for a few months. Thank you for considering! Aaronlearns (talk) 04:26, 25 December 2021 (UTC)

@Aaronlearns: thank you for your interest. See Wikipedia:Edit_filter#User_right for more on this topic. To be blunt: there is a 0% chance that a request for EFM access discussion for you would be successful right now (and <1% for Wikipedia:Edit filter helper). However, there are still opportunities to help that do not require advanced permissions:

1. Getting involved with Wikipedia:Recent changes patrol in general is a good idea (as the filters really deal with RC more than anything else)
2. The Wikipedia:Edit filter/False positives board can usually use help
3. You can place requests for new or improved filters at Wikipedia:Edit filter/Requested

Best regards, — xaosflux ^Talk 12:27, 25 December 2021 (UTC)

@Xaosflux: Thank you for this, I'll definitely be looking at and contributing to those. See you around! Aaronlearns (talk) 14:07, 25 December 2021 (UTC)

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

This filter will warn users who try to restore comments to user talk pages that had been removed by the user. I suspect most people are doing this out of simple ignorance, and it will only take one warning to get them to stop.

It will not warn if:

• The edit is modifying or removing any lines.
• The restored content contains a declined unblock, deletion template, or shared IP template. (in theory at least; I might have missed something but that's what WP:EF/FP is for)
• The edit summary doesn't start with "Undid" or "Reverted", or doesn't link to the "victim's" contributions. That is, if you're editing "User talk:Example", you must link to Special:Contributions/Example in order to be warned. So reverting a third-party removal should work fine.
• The edit is made using "real" WP:ROLLBACK. Nothing I can do about that unless phab:T262157 is implemented.

Possible message (mostly copied from Wikipedia:User pages § Removal of comments, notices, and warnings, see that page for attribution):

As usual, feel free to suggest a better message. Suffusion of Yellow (talk) 20:50, 17 November 2021 (UTC)

The purpose seems sound to me, as does the filter design. I haven't checked the log scrupulously, but the few diffs I did check seemed like cases where a warn filter would've been appropriate. ProcrastinatingReader (talk) 13:36, 18 November 2021 (UTC)

Would have preferred more discussion here, but per (almost) WP:SILENCE can someone please answer the request at MediaWiki talk:Abusefilter-warning-notwallofshame and I'll flip the switch. Suffusion of Yellow (talk) 23:32, 31 December 2021 (UTC)

And  Done. Thanks, Xaosflux. For the record, I'm hoping this will reduce drama. People will see the warning, say to themselves "oh, oops", and never try this again. If instead people ignore the warning and get yelled at for "tripping the filter", then it's just increasing drama and we can talk about disabling it. But there's no way to know what will happen without trying. Suffusion of Yellow (talk) 21:09, 1 January 2022 (UTC)

Hi!

You get this message because you are an admin on a Wikimedia wiki.

When someone edits a Wikimedia wiki without being logged in today, we show their IP address. As you may already know, we will not be able to do this in the future. This is a decision by the Wikimedia Foundation Legal department, because norms and regulations for privacy online have changed.

Instead of the IP we will show a masked identity. You as an admin will still be able to access the IP. There will also be a new user right for those who need to see the full IPs of unregistered users to fight vandalism, harassment and spam without being admins. Patrollers will also see part of the IP even without this user right. We are also working on better tools to help.

If you have not seen it before, you can read more on Meta. If you want to make sure you don’t miss technical changes on the Wikimedia wikis, you can subscribe to the weekly technical newsletter.

We have two suggested ways this identity could work. We would appreciate your feedback on which way you think would work best for you and your wiki, now and in the future. You can let us know on the talk page. You can write in your language. The suggestions were posted in October and we will decide after 17 January.

Thank you. /Johan (WMF)

18:14, 4 January 2022 (UTC)

This should be an easy one: there are a lot of IPs making talkpage posts to Talk:Federal Bureau of Investigation [1] [2], Talk:Alphabet Inc. [3] and others with identical mentions of "Nathaniel meskimen". I've placed a /48 block, but they're getting around it. I've left the last IP unrevdel'd, the edits are all identical to this one. Can we make or modify a filter to deny these edits? Acroterion (talk) 15:52, 5 January 2022 (UTC)

@Acroterion: please drop your request over at WP:EF/R. — xaosflux ^Talk 16:12, 5 January 2022 (UTC)

Ah yes, done. Thanks. Acroterion (talk) 16:35, 5 January 2022 (UTC)

Hi everyone. I just noticed that a vandal used the word 'shithole' to describe San Francisco. Strangely, the word 'shithole' is not detected by any of the four edit filters mentioned in the title. The vandal is an IP so they should not be able to vandalise the Wikipedia page with the s-word. Can someone add the word 'shithole' to filters 12, 225, 380 and 384? Thanks. Train of Knowledge (Talk) 22:15, 7 December 2021 (UTC)

@Suffusion of Yellow: I'm looking to join the abuse filter community. I don't have permission to update filters, but I think this is a simpler issue I could start with. Let me know how I should go about getting started if this is the wrong way.

The edits would be to filter 380 in line 3 and to 384 in line 7, both of which contain the regexes for obscenities.

380:

BEFORE:

3 bad_word := "...|\bSHIT\b..."

AFTER:

3 bad_word := "...|\bSHIT(?:HOLE)\b|..."

384:

BEFORE:

7 bad_word := "...?shit(?:s|ti?er|t?y|t?ing)?...";
 

AFTER:

7 bad_word := "...?shit(?:hole|s|ti?er|t?y|t?ing)?...";
 

I inferred you wanted everything in alphabetical order.

Aaronlearns (talk) 03:58, 25 December 2021 (UTC)

@Aaronlearns: Thank you. But actually this isn't this best way to help. Coming up with the right regex is maybe 1% of the job. The rest is testing. Unfortunately as an aspiring EFM, you have a chicken-and-egg problem: the testing tools are only available to EFMs and EFHs! I've enabled 839 (hist · log) ("Bad word test") and we'll see what it catches. If this isn't common there's no point in adding it to any filter. Suffusion of Yellow (talk) 21:19, 1 January 2022 (UTC)

@Train of Knowledge and Aaronlearns: Added to 384. This doesn't really seem all that common, so four filters is overkill IMO. Suffusion of Yellow (talk) 21:39, 15 January 2022 (UTC)

Not my usual area, so my apologies if I'm missing something here, but I've noticed the filter log sometimes shows edits as warnings only, but the edits do not show up in the editor's contributions, which seems to indicate that the edit was instead disallowed. These are not cases where multiple filters have been triggered and one (or more) disallowed the edit while another filter (or more than one) just warned. Here's a recent example:

https://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=91.230.41.203 shows a warning at 13:04 today on filter 636. The edit was a 1135 byte deletion on Ruby. That's the only filter log today for this user.

91.230.41.203 (talk · contribs) shows no such edit. Meters (talk) 05:49, 17 January 2022 (UTC)

Ah, reading the filter description more closely, it looks like this asks the user to use an edit summary and prevents the edit from being saved the first time, but allows the save if tried again. If the user does not save a second time the edit goes away. OK. Sorry for my confusion. Meters (talk) 05:57, 17 January 2022 (UTC)

I have four threads pinned now as potentially requiring filter changes, if anyone can take a look. Thanks. -- Tamzin^{[cetacean needed]} (she/they) 02:36, 29 January 2022 (UTC)

Thanks, @ProcrastinatingReader and Suffusion of Yellow. -- Tamzin^{[cetacean needed]} (she/they) 22:12, 29 January 2022 (UTC)

Usually, i wouldn't bother saying anything about false negatives, but this one seems waaaay to obvious to ignore. I don't know how this one missed the "Your mom" vandalism filter, possibly the pipe messed it up, but I'm going to say something here in case it needs looking into. Mako001 (C)  (T)  14:01, 26 January 2022 (UTC)

@Mako001: yea, Special:AbuseFilter/320 requires a word boundary at the start of the expression, looks like it is considering the pipe part of the word there. — xaosflux ^Talk 14:59, 26 January 2022 (UTC)

It's the ccnorm; turns the pipe into an "I", so the word becomes "IUR MOM" and hence fails to match. I think I suggested it before but a regex str_replace in AbuseFilter would be useful; then we could just get rid of the pipes before passing it into ccnorm. Other approaches probably also possible. ProcrastinatingReader (talk) 23:03, 29 January 2022 (UTC)

• 1048 (hist · log) (private, "Possible spam")

I created this filter, but I'm not really checking the log all that often anymore. About 50% of what it catches is genuine spam, but the rest is basically newbie formatting mistakes. It would be nice if non-admin/EFM/EFH users could review the log, too. Does anyone think it was overly paranoid to make this private? Most spammers aren't all that clever. I can remove the first line of the notes, to make it less obvious what the filter is doing. Suffusion of Yellow (talk) 23:11, 15 January 2022 (UTC)

I'd lean in favour of making it public. -- zzuuzz ^(talk) 23:28, 15 January 2022 (UTC)

Probably more useful if public. ProcrastinatingReader (talk) 23:04, 29 January 2022 (UTC)

 Done. @Sdkb: This isn't exactly what you requested at EFR, but it catches some of that. Suffusion of Yellow (talk) 23:46, 30 January 2022 (UTC)

Can we get some more of the common variants of the N-word added to the relevant filter? See this diff where the vandal knows to put spaces between the letters to get it through. – Muboshgu (talk) 21:07, 7 February 2022 (UTC)

Courtesy note for non-admins, it's been RevDelled (for good reason). 🐶 EpicPupper ^{(he/him | talk)} 00:05, 9 February 2022 (UTC)

It is possible to make a link to imdb look like a wikilink, like Gillian Dobb (from Magnum,_P.I.#Recurring_characters) and Jonas Brothers: Live in London (from Jonas_Brothers#Television). A normal EL would look like Gillian Dobb.

All these uses [4][5] may not be wrong, but I think these 2 examples clearly go against WP:ELPOINTS 2, though in a sneaky way. For an external links section, something like {{imdb name}} or {{imdb title}} should be used instead.

The idea of an editfilter came up at Wikipedia:Help_desk#Links_to_imdb_that_looks_like_wikilinks, but I know nothing about editfilters. Would it be possible/a good idea to make one that warns in this situation, saying something like

"Links like imdbname/imdbtitle" are often inappropriate on WP, since they hide the fact that the link is a WP:EL. They should not be used in article text, and in External links sections {{imdb name}} or {{imdb title}} is a better choice. Gråbergs Gråa Sång (talk) 17:43, 9 February 2022 (UTC)

It's technically possible, but probably not a good option for the edit filter, which (for the most part) shouldn't be used to enforce content or MOS guidelines. ProcrastinatingReader (talk) 18:03, 9 February 2022 (UTC)

Fair enough. Gråbergs Gråa Sång (talk) 18:14, 9 February 2022 (UTC)

• 869 (hist · log), 891 (hist · log), 894 (hist · log), 1034 (hist · log), 1045 (hist · log), 1057 (hist · log) (all public, warn), 892 (hist · log) (public, disallow)

Should the "unreliable source" filters warn people who aren't adding the source in the first place? Currently, we're (mostly) excluding any edit with a summary that matches ^(?:revert|restore|rv|undid)|AFCH|speedy deletion|reFill. Breaking that down, it's:

• ^(?:revert|restore|rv|undid) because page-blanking vandals often incidentally remove such sources.
• AFCH because AFC reviewers sometimes link to such sources when declining drafts
• speedy deletion Because G12 copyvio tags, and log entries, sometimes link to such sources
• reFill Because sometimes the filter can only "see" the source after it's been expanded from the bare URL.

Note that edits excluded from filters these filters aren't "lost in the void". They're logged by 1081 (hist · log) instead.

Now, I said "mostly" above, because a while back Headbomb removed the check from 891. 892 never had the summary check in the first place, and Beetstra recently objecting to my adding it.

My philosophy is that no one is obligated to fix any problem that's already on a page. If you want to spend all day reverting vandalism, it's not up to you to find and fix bad sourcing. But I think we should at least be consistent. Discuss. Suffusion of Yellow (talk) 21:34, 12 February 2022 (UTC)

Being warned is fine. Especially because a lot of the time people go 'Why did you remove this source, I'm restoring it!' and they don't know it's crap. Headbomb {t · c · p · b} 21:38, 12 February 2022 (UTC)

Are you fine with adding back to 891 the AFCH, speedy deletion, and reFill exceptions, at least? Suffusion of Yellow (talk) 21:45, 12 February 2022 (UTC)

AFCH is definitely a place where that warning needs to be front and center. Same for refill, it's great time to catch the nonsense when someone is doing citation work. For speedy deletions, those shouldn't trigger the filter if all you're doing is nomination the thing for deletion. Headbomb {t · c · p · b} 05:37, 13 February 2022 (UTC)

Edit: Though I do see the point for copyvio CSDs. Headbomb {t · c · p · b} 05:40, 13 February 2022 (UTC)

Why should AFCH users be warned? The only time the filter will trip is if they're mentioning the source in the template, e.g. declining with something like "All your citations are to lulu.com; we can't use self-published sources." The filter will be telling them something they already know. If they're just accepting the draft, the filter won't trip in the first place. Suffusion of Yellow (talk) 21:54, 13 February 2022 (UTC)

Also note that actually saving the edit in Twinkle is kind of confusing. There's no button to save the edit. You need to click "back" and then try again, but it's not obvious that that will work. Suffusion of Yellow (talk) 21:49, 12 February 2022 (UTC)

I objected adding it because in the 892 case the proper proxy links are utterly useless - it is the same as being unsourced except that you know that there is apparently a source out there (try figuring out what was meant by https://web.s.ebscohost.com/ehost/pdfviewer/pdfviewer?vid=1&sid=9dc6fcb4-3f95-4718-b411-c8380bfd8fb9%40redis). Having a speedy deletion tag linking to a true proxy as evidence of copyvio does not enable anyone to check, and if it is behind a paywall good luck finding it (would result in a nice conundrum though - Schroedinger’s copyvio). And I don’t even want bots to add them. For something that is just unreliable I think warning users that revert it back in is good, but then maybe not trip bots who repair some crappy edit - and likely depending on the ‘level’ of unreliability. I would be happy if I was warned after reverting a vandal who blanked a whole section which happened to have a proxy link in them, and frankly the editors that Headbomb mentions is a group that should be warned (but they are indistinguishable from true vandalism reverting). Dirk Beetstra ^{T C} 03:51, 13 February 2022 (UTC)

Good point about deletion templates. And there's no need to add the AFCH exception to 892, for the same reason. And I'd hope reFill would never add a proxy link in the first place. I still think that undo/revert should be excluded from 892, but really, it's a philosophical difference about what edit filters are for. I agree the links are useless link and I agree that it's nice when people reverting vandalism take it step beyond, and fix problems that were there before the page was vandalized. But if they don't, the reverting is still a (large) net positive. I guess I'd like a third opinion here. Suffusion of Yellow (talk) 21:54, 13 February 2022 (UTC)

I ran a check for positive summaries through the disallow filter and found edits like where reverting article blanking was disallowed (see Special:AbuseLog/31876334), after half a dozen different editors tried to revert and eventually an admin had to make the revert (diff). Seems to be a rare case but it happens every now and then. Philisophically I don't think reverting one issue should oblige the editor to fix another issue to make the revert, nor are filters generally purposed as being quality control tools, so I'm inclined to support the exclusion of reverts etc. ProcrastinatingReader (talk) 22:20, 13 February 2022 (UTC)

I somewhere else already pinged user:GreenC, we should get rid of unreadable proxy links completely through bot runs (for many you will need to rely on the memory of the original editor to find it back), and convert all other proxy links to the proper source. At that point reverting does not become an issue anymore - there will not be any leftover to revert back in. I’ve had people care so little that I am expecting the revert exclusion on these filters to be gamed. Dirk Beetstra ^{T C} 04:10, 14 February 2022 (UTC)

Probably best to remove the exception for sysop if you go that route, or the links will just creep back in over time. It's real easy, even for an experienced user, to copy-paste what's in the address bar without thinking. Suffusion of Yellow (talk) 21:10, 14 February 2022 (UTC)

Moved from Wikipedia:Edit filter/Requested

Filters which rely on the rmspecials() function removing spaces may need updating. Details: m:Tech/News/2022/07. Certes (talk) 19:32, 14 February 2022 (UTC)

@Certes: I think that was all taken care of. Not seeing anything in this search (link won't work for non-EF*) except for "deleted" filters. Suffusion of Yellow (talk) 21:23, 14 February 2022 (UTC)

Just a note, since this has caused some confusion. If you get a WP:ECHO notification like this, it does not mean the filter is disabled. The system is just warning you that "your" filter is getting a large number of hits. You need to go and check if the filter is misbehaving. If not, just ignore the message. Suffusion of Yellow (talk) 23:26, 18 February 2022 (UTC)

@Suffusion of Yellow: correct me if I'm wrong, but my understanding is that it had so much activity that some edits were not evaluated against it, and this may be a problem in the future. It could be too broad. — xaosflux ^Talk 23:47, 18 February 2022 (UTC)

I think AbuseFilterEmergencyDisable* only applies to AbuseFilterActionRestrictions (block, rangeblock, etc). No idea if runtime is affected or whether limits are hit there, though. ProcrastinatingReader (talk) 23:52, 18 February 2022 (UTC)

You can see how close we're getting to the condition limit here. That's separate from the throttle. If we go over 1000, then some filters (mostly likely the highest-numbered ones, but I'm not sure) will not be active for all edits. Seems we're at about 840 conditions now. Suffusion of Yellow (talk) 00:04, 19 February 2022 (UTC)

(ec) See Daimona Eaytoy's response in phab:T302047:

Ah, no, only "dangerous" consequences are disabled. Here is the relevant code, and here is the list of such dangerous actions. "Disallow" is not included.

So the only action that would actually get throttled on enwiki is blockautopromote. If we enable block that'll be affected too. Suffusion of Yellow (talk) 23:55, 18 February 2022 (UTC)

1184 & 1185 (by Suffusion of Yellow) were set to disallow due to an ongoing botnet attack. Both are no longer disallowing due to WMF mitigations (sec phab). I'm going to bed (its 2:41am), so just thought I should note where things are big props to Suffusion for their quick action -- TNT (talk • she/her) 02:41, 18 February 2022 (UTC)

Thanks for the update, what annoying botnet edits. — xaosflux ^Talk 11:29, 18 February 2022 (UTC)

Appears to be a resurgence. TNT beat me to re-enabling filters. Courtesy ping Suffusion of Yellow in case adjustments are necessary. ProcrastinatingReader (talk) 23:06, 18 February 2022 (UTC)

If these filters are going to be reused again, can we make a custom warning message that explains the reason for the filters? Presumably the bots aren't reading it, and it'd be more useful to FPs vs the current MediaWiki:abusefilter-warning ProcrastinatingReader (talk) 00:25, 19 February 2022 (UTC)

@ProcrastinatingReader: Special:AbuseFilter/history/1184/diff/prev/26361. Suffusion of Yellow (talk) 00:32, 19 February 2022 (UTC)

Hey y'all—don't panic, its nothing formal, just a "testing the waters" post to see how the general feeling is.. what are the cons of enabling edit filter blocking, and could these be mitigated by rigorous testing (i.e. policy of a sort which states that a filter must be disallowing for `x` days and have a false-positive percentage below `y`)? -- TNT (talk • she/her) 15:43, 18 February 2022 (UTC)

For example of blocks, see meta:Special:Log/Abuse_filter. I'd think the biggest 'con' (besides a bad FP filter that goes nuts) is that we need to properly educate our admins about the process. — xaosflux ^Talk 15:49, 18 February 2022 (UTC)

@Xaosflux: I guess we could put something into MediaWiki:Group-abusefilter.js that alerts people when they're editing a blocking filter. Otherwise I suspect many people will click "save" without even realizing what they're doing. Suffusion of Yellow (talk) 18:41, 18 February 2022 (UTC)

@Suffusion of Yellow: no, I mean when the 83% of non-efm admins who will come across users that got blocked by "a bot?", how to investigate that, how to determine who is accountable for the block, etc. — xaosflux ^Talk 19:10, 18 February 2022 (UTC)

We could put something in Mediawiki:abusefilter-blockreason like {{Friendly message to blockee}} <!-- See [[Wikipedia:How to review an edit filter block]]. --> Suffusion of Yellow (talk) 19:16, 18 February 2022 (UTC)

I think it could be made to work. I'd prefer to see some active peer review and a sign-off quorum, along with a relevant amount of testing. I'd like to see a false-positive rate well below what we might normally see for a disallow filter, if not zero itself. And you know that on-the-fly adjustments are likely to happen. This all needs to be made very clear. I think we might also want to consider what will happen when there is an emergency demand for a blocking filter. You just know that a situation will arise one day where there's a demand for one without the usual wait. -- zzuuzz ^(talk) 16:25, 18 February 2022 (UTC)

@Zzuuzz: Do you any filters in mind, which you would upgrade to "block" if you could? Suffusion of Yellow (talk) 18:41, 18 February 2022 (UTC)

I'm sure there's a few existing ones - maybe 996 (hist · log)? Some past versions of 52 (hist · log)? 1022 (hist · log)? I think we'd probably want to mostly take a fresh perspective. -- zzuuzz ^(talk) 18:57, 18 February 2022 (UTC)

A block is two things: (1) A technical measure preventing an IP or account from editing, and (2) A "stain" on one's reputation. How many AN/I threads have you seen where the reporter starts out with "As you can see, they've been blocked four times for..."? Yes, people shouldn't do that, but "people shouldn't" is not an actionable plan.

So what if we agree to revdel the target username from these blocks when unblocking? That is, if User:Edit filter blocks User:Alice, and Alice is unblocked, then revdel User:Alice from the block log. That wouldn't destroy all evidence of the block (it'd be in her Special:AbuseLog, still), but casual users looking at Alice's block log would see nothing. Suffusion of Yellow (talk) 18:41, 18 February 2022 (UTC)

That seems a fairly reasonable framing. Though I would say there's not a great number of existing disallow filters which target established users. There's be even fewer blocking filters. -- zzuuzz ^(talk) 18:57, 18 February 2022 (UTC)

Even new users might get discouraged though, once they realize how people perceive blocks. For IPs, we have a few "long-termers" on stable IPs and they might not want a dirty block log, either. So lets say the follow get revdelled:

• Any block of a registered user, where the reviewing admin is unwilling to assert "I would have blocked this user myself".
• Any block of an unregistered user, where the reviewing admin is unwilling to assert "I would have blocked this user myself" and the user requests this.

And all blocks of registered users (including new users) must be reviewed within X hours, or the user must be unblocked. No letting the block expire on its own; that leaves ambiguity in the block log. Suffusion of Yellow (talk) 19:12, 18 February 2022 (UTC)

It appears that meta:User:Abuse_filter has been blocking people on meta since 2013. There must be thousands of blocks so far. Does anyone have time to do a spot check on meta:Special:Log/Abuse filter so see if any good faith meta users seem to have ever been blocked? Or, if that's too hard to figure out, has anyone returned from such a block and made some normal-looking edits? The average edit filter has lots of false positives, but User:Abuse filter, if it were allowed to block on *enwiki* as well as meta, would have to be well-nigh perfect to be tolerated for very long. I suppose you could restrict it to blocking IPs or new accounts who were not yet autoconfirmed. EdJohnston (talk) 19:16, 18 February 2022 (UTC)

I've been blocked by abusefilters several times on several wikis, usually because I'm globally replacing a moved Commons file. AntiCompositeNumber (talk) 01:05, 20 February 2022 (UTC)

• Just a tech note, abuseblocks can be set to target IPs, users, or both. Different block durations can be set for users and and ips, per rule. They can be short (e.g. on meta we have some that are just 2 hours). — xaosflux ^Talk 19:25, 18 February 2022 (UTC)
• I know you're asking for cons, but I guess personally I'm not sure for which filters this would be desirable. User:DatBot can report to AIV depending on certain trigger criteria, and AIV response times are usually ok. If it's only used on filters with only occassional hits I dunno if it's really worthwhile. ProcrastinatingReader (talk) 19:39, 18 February 2022 (UTC)

  My vote would be on something like Special:AbuseFilter/58 -- TNT (talk • she/her) 19:54, 18 February 2022 (UTC)

  There are indeed some things which reliably merit an instant block. I do think we should tackle a potential elephant in the room, which is the circumstances leading to this discussion (though it also works as a general query). Last night, for various reasons, we could have used an automated means of blocking a very rampant vandalbot. This type of melee, invasion, crapflood, or DDOS attack is where an automated block would excel (assuming the filter was got right). -- zzuuzz ^(talk) 20:31, 18 February 2022 (UTC)

  But only if we're willing to accept a large number of false positive blocks. That wasn't a "set it and forget it" bot; they were actively responding to the filters as we updated them, usually within minutes. I was just clicking "Save filter" and hoping for the best. If we have to test everything for days (or even hours), then they'll be ten steps ahead of us the whole time. Suffusion of Yellow (talk) 20:38, 18 February 2022 (UTC)

  I think in a similar situation the same rule of necessity would apply—we were doing a lot of untested filter changes during that attack, and having the ability for the filter to be set to block (after confirming a few good disallows) during that would have saved going around and mopping up the IPs. Although this certainly prompted my question, its not the real main benefit I see (given how rare those situations are..) -- TNT (talk • she/her) 20:43, 18 February 2022 (UTC)

  There are varying levels of certainty for some things. Back when there was 'anontalk' vandalism I think we had 4 filters running at a time, and 3 concurrent filters has certainly happened more recently. Like if there a vandalbot attack going on, and an IP makes 8 edits in 1 second, it's a vandalbot mkay. We'd just need different filters for different things. -- zzuuzz ^(talk) 20:57, 18 February 2022 (UTC)

If I recall, there is an interface to allow EFMs to revert actions done by filters, which I *think* includes unblocking editors blocked by a filter. If this is the case, we should have some rules about the process for unblocking by a non-admin EFM - should unblock requests be left only to admins? If this is not the case, then there should be a process for a non-admin EFM to say "this wasn't meant to block, please unblock these ips/accounts" and this should be added as a supported exception to the rule that you can't generally request unblocks for others, Wikipedia:Appealing a block#Appeals by third party. DannyS712 (talk) 21:04, 18 February 2022 (UTC)

Hm, in a bid to make things "simples", can't we just say "non-admin EFMs aren't permitted to do anything related to blocks" (enable/unblock, it'd be fine for them to disable the blocking action when urgent)? -- TNT (talk • she/her) 21:07, 18 February 2022 (UTC)

By default, you need the abusefilter-modify-restricted user right to enable, modify, or disable a blocking filter. Currently, non-admin EFMs do not have this right. So would we give non-admin EFMs the right, but apply "social" restrictions on its use? Suffusion of Yellow (talk) 21:12, 18 February 2022 (UTC)

Oh, much more simple then—no 😋 (in an ideal world yes, given how trusted EFMs are, but I can only imagine the community would cry de-bundling or something similar) -- TNT (talk • she/her) 21:15, 18 February 2022 (UTC)

I've made some updates to User:Suffusion of Yellow/effp-helper. Does anyone care to test the changes before they go live? If you already import EFFP-Helper, please add:

window.effpUseDev = true;

to your common.js.

Changes:

• No more surprises! Everything is there on the Special:AbuseLog page before you click "make edit", including:
  • Has the edit been saved?
  • If so, by whom? Is it still the current edit?
  • If not, who else has edited the page?
  • If you try to save the edit, will you get an edit conflict?
• Signature detection. It's disgustingly hacky, but if you try to save a log entry with ~~~~ but missing new_pst, it will substitute their signature, not yours. In theory.
• If you're helping a registered user, they are now pinged from the edit summary. Expect the occasional "thanks".
• The "back" button should work as expected. At least, no differently than any other edit.
• Translatable messages.

Let me know if you have any problems. (And let me know if it works, too!) Suffusion of Yellow (talk) 23:35, 24 February 2022 (UTC)

Some sort of persistent spam campaign going on? [6] appears to be one way in which they are getting past the edit filter. Pahunkat (talk) 11:02, 21 February 2022 (UTC)

@Pahunkat: Take a small look at AIV. We may need some more people for this. – AssumeGoodWraith (talk | contribs) 11:07, 21 February 2022 (UTC)

In fact, we may need a block filter for this. – AssumeGoodWraith (talk | contribs) 11:08, 21 February 2022 (UTC)

For now I think the string linked above should be blocked by the edit filter(s) we have, it's being added by the reverting IPs that I can see. Pahunkat (talk) 11:08, 21 February 2022 (UTC)

Actually, screw that - they'll just move on to something else. Pahunkat (talk) 11:13, 21 February 2022 (UTC)

@Pahunkat: at least it might be a momentary break – AssumeGoodWraith (talk | contribs) 11:19, 21 February 2022 (UTC)

@Pahunkat this looks like My Royal Young - stuff is added to Phillippines - related articles and is reverted. I don't think they will stop on their own. aeschylus (talk) 21:14, 28 February 2022 (UTC)

Hello, I was looking at the performance of enwiki filters on the MediaWiki logs, and there are a few things that should be fixed:

• Filter 1140 is potentially very slow and it often fails to run because the array index is not checked. My suggestion is to check action first, then use length(that_variable) >= 2 before accessing an element;
• Same for Filter 1101;
• Same for Filter 1150, where the condition with the index access should also be the last thing that is checked;
• Just FYI, Filter 345 is often reported as slow, although I can't think of easy ways to optimize it;

Please let me know if you have any questions -- just please make sure to ping me as I don't watch this page. Thank you, --Daimona Eaytoy (Talk) 12:00, 6 March 2022 (UTC)

@Daimona Eaytoy: Fixed 1140, 1102 (1101 is disabled) and 1150. Filter 345, is, I think, the first filter to look at added_lines for extendedconfirmed (I.E. most) editors. So it's getting "blamed" for the diff-generation step. Nothing I can see to do about that; any "fix" would just move the blame to another filter and not really speed things up.

Why is this a syntax error according to Special:AbuseFilter/tools?

x := [1,2];
false & x[3]

That should short-circuit before the out-of-bounds access. Suffusion of Yellow (talk) 20:37, 6 March 2022 (UTC)

@Suffusion of Yellow: Thanks! I think it wasn't filter 1101 but another one then, although I don't remember which one exactly. And yes, for filter 345 that seems a good explanation. As for the syntax error, short-circuiting is disabled when checking the syntax of filters, otherwise we wouldn't be able to catch some kind of syntax error. In general, the AF syntax checker is fairly strict because we lack a good way to report parser errors to the users. Things have improved a lot lately, mainly thanks to T260903, but it's still far from being perfect; T240847, for instance, is a hard blocker. Also, just to be clear, while your example fails the syntax check, it would run without issues when the filter is checked "normally". HTH! --Daimona Eaytoy (Talk) 12:30, 7 March 2022 (UTC)

• 1151 (hist · log) ("Projectspace blanking", private public)
• Original EFR thread: Wikipedia:Edit filter/Requested/Archive 17 § Page blanking trend?, courtesy ping @Aeschylus and Malcolmxl5:

Originally created as an LTA filter. This might be an LTA (or several), but I think it's more likely that it's just kids pushing buttons. Any objections if I set this to disallow, with the generic message? There were some FPs, but none since the February 5 refinements from what I can tell. At least, everything has been reverted. Suffusion of Yellow (talk) 17:45, 28 February 2022 (UTC)

I think that it sounds okay, but I don't have the rights needed to view the edit filter and see exactly what was hit. We'll need Malcolm's input on this to proceed. aeschylus (talk) 21:11, 28 February 2022 (UTC)

If no one else thinks this is an LTA, I'll make the filter public, too. Suffusion of Yellow (talk) 22:59, 28 February 2022 (UTC)

Good morning. Looking good, I don’t see a problem. Agree it’s not an LTA, just vandals some of whom have been rather persistent. This covers Wikipedia space and Help space, I think? --Malcolmxl5 (talk) 10:35, 2 March 2022 (UTC)

Yes. The same thing sometimes happens with templates, too, but there were too many FPs to include that namespace. Suffusion of Yellow (talk) 19:01, 2 March 2022 (UTC)

• I've made it public, disallow decision still pending. — xaosflux ^Talk 15:00, 2 March 2022 (UTC)
• This change looks good; I don't see any false positives. @Xaosflux and @Malcolmxl5, do you guys think it is okay? I think it is, as I am almost certain that an IP repeatedly blanking pages in the Wikipedia or namespace is not up to good. Especially not more than once. aeschylus (talk) 14:56, 5 March 2022 (UTC)

  It looks good to me, Aeschylus. --Malcolmxl5 (talk) 18:50, 6 March 2022 (UTC)

   Done. Suffusion of Yellow (talk) 21:37, 8 March 2022 (UTC)

• 1191 (hist · log) (private)

Obligatory notice, LTA about which the less is said, the better. But zzuuzz knows what this is about. Suffusion of Yellow (talk) 22:50, 14 March 2022 (UTC)

Yes, thanks. Disallow seems good. -- zzuuzz ^(talk) 22:55, 14 March 2022 (UTC)

@Suffusion of Yellow hmmm, it seems like there is already a p-block that should have caught this? Is there a defect somewhere? — xaosflux ^Talk 22:58, 14 March 2022 (UTC)

No, apparently a "user talk" namespace p-block still doesn't prevent editing your own user talk page, unless TPA is disabled. Suffusion of Yellow (talk) 23:03, 14 March 2022 (UTC)

@Suffusion of Yellow lets see if that works first (see note I put on the filter description). — xaosflux ^Talk 23:08, 14 March 2022 (UTC)

Thanks. They were also doing the same thing on article talk pages, too, before I created the filter, so I'm leaving it at disallow unless you object. And as I said in the notes, this will probably just come down to long sitewide block in the end. I just want to say we tried everything before blocking what might be well be millions of people. Suffusion of Yellow (talk) 23:15, 14 March 2022 (UTC)

Just created 1195 on recommendation from TheresNoTime - idea is to catch image vandalism to templates (examples in the filter description). Not set to do anything but log at the moment of course, but could probably be set to disallow once we're sure the code is solid. firefly ( t · c ) 10:58, 25 March 2022 (UTC)

Just noticed that this one is partially redundant to 600, but this one is narrower and therefore could be set to disallow with a much lower FP risk. firefly ( t · c ) 11:13, 25 March 2022 (UTC)

(edit conflict) Awesome, thank you Firefly! 😄 ~TNT (talk • she/her) 11:14, 25 March 2022 (UTC)

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

This came out of this this discussion. The filter will warn whenever anyone tries to add an uncited entry to any of the 366 day-of-the-year pages. The filter log shows nearly 100% of saved edits were reverted anyway; apparently the "no, being sourced on the target page isn't enough" rule is strictly enforced in practice. The last non-reverted edit was Special:AbuseLog/32085556, and I've tweaked the filter to avoid that kind of FP.

Message, feel free to edit:

Pinging Toddst1 and Kiwipete who have been politely nagging me about this. Suffusion of Yellow (talk) 22:24, 11 March 2022 (UTC)

Looks great to me! Toddst1 (talk) 23:22, 11 March 2022 (UTC)

Looks good to me! 🐶 EpicPupper ^{(he/him | talk)} 01:26, 14 March 2022 (UTC)

And  Done. Suffusion of Yellow (talk) 19:30, 25 March 2022 (UTC)

It was downgraded to tag owing to FPs, but these days I can't see that there's been a false positive in months. It's very effective at picking up its intended targets and disallowing might help limit the amount of revdel required. firefly ( t · c ) 16:53, 2 April 2022 (UTC)

+1. If FPs do become an issue, it would be better to split it into a disallow and tag-only, since some of those have a 0% chance of being used in good faith, and the first alternative in particular appears in >80% of ESes at least from the latter of the two LTAs using it. On that note, should the filter be renamed to note that it catches two LTAs now? CUs have said they're not the same person, and that was my takeaway from a long behavioral investigation into the newer one. (If this were to be split into disallow and tag-only, the tag filter could also look for a pattern matching variants of the username they've used on-and-off on a variety of sites for 4-5 years, which often comes up in their edits but would probably be too FP-prone.) -- Tamzin^{[cetacean needed]} (she/they) 18:38, 2 April 2022 (UTC)

@Tamzin filter renamed following the standard scheme firefly ( t · c ) 18:56, 2 April 2022 (UTC)

I would support moving this to disallow, based on the last month of filter hits. ProcrastinatingReader (talk) 13:33, 3 April 2022 (UTC)

 Done - set to disallow with the standard message given the daily shenanigans from its target. If false-positive issues arise I'd second Tamzin's idea of a narrowly-constructed disallow filter and a wider tagging one. firefly ( t · c ) 17:55, 3 April 2022 (UTC)

Hi everyone! I just wanted to leave a quick note that an update was added to edit filter #53 at 01:29, 14 April 2022. This update accidentally introduced an unintentional pipe ("|") OR value in one of the parameters added to the diff and edit summary strings. This resulted in a very large amount of false positive hits being logged. After noticing this huge influx of hits and after looking through some of the logs, I knew there was a problem and temporarily disabled the filter at 01:38, 14 April 2022 until I could identify and resolve the issue. After some debugging, I identified, located, and resolved the issue shortly afterwards, and the filter is back online and working properly.

I'm leaving this notice in the event that any reports are filed regarding a false positive and as a result of the issue. If the edit filter log recorded a trigger by edit filter #53 and between 01:29, 14 April 2022 - 01:38, 14 April 2022 (9 minutes), you can safely attribute it as being a false positive hit due to this issue, and indicate in the report that it's already been resolved. Thanks everyone, and I apologize in advance for any reports that are filed that involve what happened. If anyone has any questions or concerns, please let me know by messaging me on my user talk page. :-) Cheers - ~Oshwah~^{(talk) (contribs)} 01:59, 14 April 2022 (UTC)

22:52, 15 April 2022 (UTC)

Heh. User talk:Edit filter → here. -- Tamzin^{[cetacean needed]} (she/they) 22:58, 15 April 2022 (UTC)

The edit filter system account is flunking both sets of activity requirements (no edits, last logged action 2020) and should be desysopped. (Although this comment was written in a jocular tone, I do genuinely believe that a bureaucrat should remove the account's admin rights) * Pppery * _{it has begun...} 00:07, 16 April 2022 (UTC)

Looks like the account was desysop'd once before, in 2019. Log entry. Old EFN thread. Phab ticket. –Novem Linguae (talk) 00:31, 16 April 2022 (UTC)

Don't think it's possible to desysop(?), since [7] will just resysop it. And the phab ticket, or more specifically the SRP discussions, seem like bikeshedding; it's a piece of code, not a human. ProcrastinatingReader (talk) 01:55, 16 April 2022 (UTC)

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

I was looking through the log here, and frankly, it looks like the majority of hits are false positives. Now it's not possible to be sure; when you stop an account from being created, you don't get to find out what they were going to do. A few examples:

• "Fabonz": I'm guessing this is supposed be an impersonation of Favonian? But I doubt it.
• "Bl223907": is supposed to be Bbb23, maybe?
• "Varajeezuz": zzuuzz, maybe?
• "Enas Ahmed Eisa" Medeis, it would seem.

And so on. Should we:

• Go through this giant ball'o'cruft and carefully fix each of these of FPs?
• Drop to tag-only, and rely on people reviewing Special:Log/newusers?
• Throw some WP:TNT in the whole thing and start over?
• Something else?

I've never understood the value of disallowing LTA usernames. They are going to pick and another name and disrupt anyway. Except, unless you're a checkuser, you don't know the name they picked. If they stay with "[admin] is a wanker", their edits get reverted on sight. If their second attempt is "BoringUser37823" maybe their edits stick. Suffusion of Yellow (talk) 23:20, 22 March 2022 (UTC)

Yes it is a problem, and has been for a long time. Unfortunately false positives are not usually very visible with this filter. I'd be inclined to work back through the false positives, as well as make some other common sense pruning. I do see some value in having a filter which prevents names which are abusive, and helps with denying recognition to some memes. Sometimes the username is a key part of the disruption. -- zzuuzz ^(talk) 00:44, 23 March 2022 (UTC)

Thank goodness for https://regex101.com/debugger... so far I've managed to combine some patterns together, and I think we should probably split the filter out into more specific issues ~TNT (talk • she/her) 12:32, 25 March 2022 (UTC)

Moving a couple of things into Special:AbuseFilter/1196 ~TNT (talk • she/her) 13:21, 25 March 2022 (UTC)

Thank you! I'll keep an eye on both. Suffusion of Yellow (talk) 19:31, 25 March 2022 (UTC)

Honestly I'm not entirely sure what's being attempted here. It looks like we're just forking the problem and I predict the same issues will persist, as seen in the first log entry of the new filter. It really needs a big old prune (along with more than a few more word boundaries). I'll take a scalpel to both filters in the near future. -- zzuuzz ^(talk) 19:45, 25 March 2022 (UTC)

I've yet to find a time slot to dig though this, but I just wanted to add that I think we're also going to have to also talk about 102 (hist · log). -- zzuuzz ^(talk) 04:51, 31 March 2022 (UTC)

• Someone just pointed out Special:AbuseLog/32282853 to me, which, arises from an issue in 874's 79th alternative. To allow discussion without leaking a private filter, I'll anonymize it as having the following format: abc.d?[e3] . Thus the issue arises from the confluence of the wildcard, the question-mark quantifier, and the lack of a boundary assertion at the end.. To me, that's far too much flexibility to be having in a filter that leaves no obvious avenue for appeal. Since we've been talking about this for a bit, I'd like to make a proposal: All patterns in 874, 102, or any other account-creation filter:
  1. Must not, when excluding any characters that are quantified at minimum length 0, consist only of 3 or fewer literal ASCII characters (like the pattern in 102 that could be reduced to ryr)
  2. If they specify only 4 to 5 literal ASCII characters (like the 79th alternative in 874), must not contain any wildcards mid-pattern. At a minimum, they must use \S or \w, but preferably something narrower than those. Depending on what the characters are, this may be advisable even at higher character counts (as in the Medeis example).
  3. Must not contain any mid-pattern quantifiers of wildcards or large character classes with large or infinite maximum lengths (e.g. zz[a-z]*uu[a-z]*zz, unless both ends are very very narrowly tailored (e.g. Suffusion.*Yellow).
  4. If any string they match could plausibly occur in any context other than abuse, must start with a ^ or \b and end with a $ or \b. (So a direct match on a username that isn't a word outside of Wikipedia (e.g. zzuuzz) doesn't need such an assertion, nor does one with some basic substitution or repeating-character quantifiers fit in (e.g. z[sz]+[uv]+z[sz]+), but something that could arise in a normal context (e.g. zuz, although that also breaks rule 1) needs those boundary assertions.)
• Exceptions could be made in emergencies or by concurrence of two EFMs, to be noted in the filter commments, with the understanding that they will monitor for FPs. Thoughts? -- Tamzin^{[cetacean needed]} (she/they) 21:15, 1 April 2022 (UTC)

@Tamzin: Sound like good ideas, but those giant crufty regexes just give me a migraine. So, I boldy switched 874 to /x ("ignore whitespace") mode. We haven't done that with a filter before AFAIK, but maybe we should start. If no one reverts that change I'll start pruning. Suffusion of Yellow (talk) 00:16, 2 April 2022 (UTC)

• @Zzuuzz, TheresNoTime, and Tamzin: Just did a major tidy of 874 and 1196. In the end, I downloaded the entire filter log (about 22000 hits) log so I could grep locally instead of waiting for abusefiltercheckmatch. There were some patterns in there that had caused thousands of false positives. Oh and (?x) works wonders.Suffusion of Yellow (talk) 22:48, 4 April 2022 (UTC)

  Nice bit of tidying, thanks. -- zzuuzz ^(talk) 10:09, 5 April 2022 (UTC)

  And did a similar de-cruft of 102. "Only" looked at the last five years of the log. If I removed someone's "favorite" string, please restore, but consider providing some context in the notes <grumble grumble>... Suffusion of Yellow (talk) 02:00, 8 April 2022 (UTC)

New proposal

There are two problems with the account creation filters (102, 874, 1196): (1) The standard disallow message that we're using doesn't make any sense and is BITEy. (2) No matter what message we use, disallowing automatic account creations is always BITEy. What are they supposed to do, create two accounts? Expose their IP on EF/FP/R? Ping an enwiki admin from meta? So let's:

(1) Set filter 102, 874 and 1196 to match on manual account creation only, and use a message like this:

After all, no one should expect their first (or second or third) choice on any popular website. All the cool names are taken. Just saying "pick something else" isn't a big deal IMO. But talking about "abuse" and "disruption" and "blocking" and such; let's not do that. Note that the I didn't link to WP:EF/FP/R intentionally; if the account doesn't exist yet, they have to expose their IP to make the report.

(2) Create a new filter (we'll call it "Persistent LTA usernames" or something) matching on manual and automatic creation for use only against LTAs who evade the other filters. Everything added to this filter must:

• Include the date that it was added
• Include some context as to why it was added (log id of account creation, SPI page, whatever)

Anything will no true positives in a year, or anything added without a date or explanation will be removed.

I have no idea what kind of message to use for this new filter. Most autocreations are probably from non-native English speakers anyway. But admins should try to monitor the log, and force local creation for anything that looks like a FP. Since it's only a last resort, the log should ideally be pretty sparse. Suffusion of Yellow (talk) 18:38, 8 April 2022 (UTC)

This seems like a reasonable proposal. We seem to have a lot of username filters, many with their own messages. -- zzuuzz ^(talk) 22:32, 14 April 2022 (UTC)

zzuuzz: Heh, already got started per WP:SILENCE. I'll put in an edit request for the message above, and add it to 102, 874, and 1196. I'm still open to suggestion for a message for 1198 (hist · log) (once something is added to it). What, again, is someone supposed to do when an autocreation is disallowed? Not that they'll notice if they don't try to log in at enwiki, but if they do, what then? Should we set up page at meta for FP reports, and remember to watch it? Ugh. Suffusion of Yellow (talk) 22:53, 14 April 2022 (UTC)

I figured you probably would, but it's sometimes nice to get any feedback. IMO, we should simply be creating these accounts (plus fixing the filter). In other words, we already have the list of reports to watch. How to expedite the reports is another matter. Maybe the (non-ideal) solution would be a page with instructions on who to ping from meta. Another option would be ACC (or VRT). -- zzuuzz ^(talk) 23:07, 14 April 2022 (UTC)

And  Done. Updated 102, 874, 1196 with the new message. @Zzuuzz: How "dangerous" is the centralauth-createlocal right, anyway? I'm having trouble thinking of a way to abuse it. Maybe it should be given to more user groups. Suffusion of Yellow (talk) 20:47, 17 April 2022 (UTC)

The biggest issue I can see is not understanding why the account cannot be self-created. This might be due to a username issue (I guess always a filter?), or a local ACB block. If you don't know an IP address, or thus the reason account creation is blocked, then there's a risk in that. Granted it's not always a huge risk. With ACC, overriding an ACB block is often sent to the CU queue. IMO this system slightly leans towards the more paranoid side of things, but it is based on actually knowing the IP. I'm not going to suggest it should be a CU-only right - admins are entrusted to grant IPBE and lift blocks (and indeed create local accounts) based on what users tell them, but it also requires a certain amount of nous. Interested to hear any suggestions... -- zzuuzz ^(talk) 21:34, 17 April 2022 (UTC)

So, I recently reverted the following revision/vandalism: 1085380463
In it, the supposed phrase that should trigger filter 320 appeared three separate times, but the filter didn't trigger at all. Sure other filters triggered, but 320 which is specifically for this, didn't.
Have I just misunderstood what the filter is for, or is this really a false negative?

Also please correct me if this is the wrong place to report possible false negatives. – 2804:F14:C060:8A01:E11F:9193:92A6:441B (talk) 07:34, 30 April 2022 (UTC)

Well this is awkward... I just realized that the filter only detects changes that altered less than 200 characters (if I read the top right)... so this isn't really a false negative, it's just how the filter works.
Well I won't delete this in case someone answers my question of "where to report false negatives", but I wouldn't have reported it if I had understood that part of the code. – 2804:F14:C060:8A01:E11F:9193:92A6:441B (talk) 08:25, 30 April 2022 (UTC)

You can report FN at the FP board, WP:EF/FP. We don't get a lot of FN reports except from admins who are working on fitlers so there isn't a main board for them. In general we are far more accepting of FN's then FP's. — xaosflux ^Talk 10:16, 30 April 2022 (UTC)

Hi there, please revert this change to filter 680 https://en.wikipedia.org/wiki/Special:AbuseFilter/history/680/diff/prev/cur or try changing the "U" to lowercase "u"; it looks like this making many false positives; see WP:EFFP. Notified Oshwah at EFFP but got no immediate response. 🐶 EpicPupper ^{(he/him | talk)} 06:48, 1 May 2022 (UTC)

@EpicPupper fixed. Lowercase 'x' needed in that Unicode code point. Pretty sure uppercase \X matches any Unicode code point 😬 firefly ( t · c ) 07:10, 1 May 2022 (UTC)

It appears that while "[\\x{1F595}]" matches "🖕", "[\\X{1F595}]" matches the characters "X", "{", "1", "F", "5", "9", and "}". EpicPupper Thanks for reporting this! Suffusion of Yellow (talk) 18:39, 1 May 2022 (UTC)

• 172 (hist · log)
• 2a02:c7d:f008:2400:b822:b409:ff9e:85a2 (talk · contribs · deleted contribs · logs · filter log · block user · block log)

2a02:..:85a2 has been lighting 172 up, triggering DatBot AIV reports in the process, by removing lots of sections containing only {{empty section|date=...}}. In general I'm skeptical of the merits of such edits, but they're a content matter, not inherently problematic. Looking at the filter, it matches not just that, but even the removal of an entirely empty section.

Is that desirable behavior? I would say that if a section is just a header, or a header and {{empty section|date=...}}, that's not what 172 is meant to be looking for. -- Tamzin^{[cetacean needed]} (she/they) 17:37, 18 May 2022 (UTC)

Removing empty sections with "date=June 2017" is perfectly fine indeed. ~ ToBeFree (talk) 19:20, 18 May 2022 (UTC)

(2a02:c7d:f008:2400:612e:8bc8:25d0:a144 (talk · contribs · (/64) · deleted contribs · filter log · WHOIS · RBLs · http · block user · block log) was automatically reported at AIV again today.) ~ ToBeFree (talk) 11:48, 21 May 2022 (UTC)

Yeah, I'd agree that removing empty sections shouldn't be flagged. Galobtter (pingó mió) 19:07, 21 May 2022 (UTC)

Special:AbuseFilter/716 (New user tagging or de-tagging article as FA/GA)
Looking at this, most of the edits caught by the filter are unconstructive and many are disallowed by other filters. Looking at the edits that were not disallowed (most are vandalism, same is reversion of vandalism such as this diff), Should we add an action to this filter, such as tag, warn, or maybe disallow? There's also a similar request about FA/GA tags at WP:EFR (see this diff).

Then there's Special:AbuseFilter/1096 (Saqlainify).
This filter (used to handle someone who was block-evading) had its last three hits in November 10, 2021. Two of these were false positives. Maybe we should delete it as stale?

There have been complaints about the username filters here catching non-violations.

And this racial slur, among other common words you can think of should probably be tested in filter 1. 67.21.154.193 (talk) 14:02, 30 May 2022 (UTC)

• Repeating characters filter #135 (hist · log) (initial discussion on mailing list)

I was wondering why #135 wasn't catching vandalisms like "word word word word" and came to realize that while it only takes 8 repetitions of a single character ("wwwwwwww"), the filter will not trigger on less than 8 repetitions of a longer sequences either, which means 32 characters for a 4-letter word ("word word word word word word word word"), and up to 72 characters for a 9-letter "word". That's somewhat inefficient, I'd say, not only computationally (who can test that?) but also when it comes to catching "lazy" c&p vandalisms with fewer than 8 repetitions of the same word(s). So instead of

rmwhitespace(added_lines) rlike "([^_:.,*'|=#}{0 -]{1,9})\1{7}"

it would make more sense to have something along these lines, I think:

patterns := "([^_:.,*'|=#}{0 -]{1})\1{7}" + "|([^_:.,*'|=#}{0 -]{2})\2{3}" + "|([^_:.,*'|=#}{0 -]{3})\3{2}" + "|([^_:.,*'|=#}{0 -]{4,15})\4{2}";

rmwhitespace(added_lines+summary) rlike patterns

(Note: splitting the pattern for readability reasons; exact repetition patterns can be adjusted as needed)

Similarly, the digit repetition test ("[\W\d]\.\d*(\d{1,9})\1{7}") seems to complex for longer sequences, as they're probably very rare IRL.

Additionally, there's no need for the comma in all {N,} — if N repetitions are found, more than N need not be searched for.

I'm testing this on another wiki, thought you might be interested in reviewing your code here as well. Ponor (talk) 22:17, 21 May 2022 (UTC)

Maybe we can look at filter 887 and see if we can make do some similar stuff here? 67.21.154.193 (talk) 15:55, 1 June 2022 (UTC)

Filter #887 is a much simpler one as it operates on short strings (its first two conditions would not be good for long texts, they'd all match: are, this are ubiquitous), but it does follow the logic of "string length" × "number of repetitions" = nearly constant, unlike the current version of #135. The pattern I proposed works well, I haven't encountered any false positives so far, and I did catch some repetitions that would have gone past #135 otherwise: "sus. sus. sus. sus" now gets caught with ([^_:*'|=#}{0 -]{4,15})\4{2}". Note that I also removed . and , from this [^…] list, as a matter of fact I'm keeping them only in the first pattern, ([^…]){1}\1{7}. Ponor (talk) 17:10, 1 June 2022 (UTC)

Is there any reason why Special:AbuseFilter/247 should not be set to disallow? If someone pushes through the edit it requires suppression in most cases, and if it's somewhere like the Help Desk it often affects upwards of 50 edits simply due to the high edit rate compared to how frequently someone is checking it; I only found Special:Diff/1092437906 in the most recent hits that is a false positive but I feel like the regex could be tweaked to exclude it. Note that this filter only affects NS0 and NS4 (Main and WP spaces). (please ping on reply) Primefac (talk) 13:23, 12 June 2022 (UTC)

Filter 31 (ASCII art): The match string with the character ∆ should be a regex that includes the similar symbols Δ and △. It's possible that there are other white triangle-like symbols I missed. –LaundryPizza03 (dc̄)

@LaundryPizza03: Do you have a few example edits that should have been caught? I don't like adding stings after a one-off occurence; if everyone did that, the filters would become bloated and unreadable. Suffusion of Yellow (talk) 20:39, 13 June 2022 (UTC)

Edit attempt that prompted this inquiry has already been done by someone else, however I think this one could benefit from the addition of !(summary irlike "\bcop(y|ied)|und(id|o)|\brv[vt]?\b|revert|vandal|remov|clean|delet|\brmv?\b|\brepea?t") or something along those lines. Since the filter can already be evaded by someone determined to do so I don't see this as likely to be an issue. 74.73.224.126 (talk) 13:14, 8 June 2022 (UTC)

Thanks. I just went with !(summary irlike "^(?:undid|revert|rv)") which seems to cover most of it; surprisingly many blanking vandals do like to say "deleted" or "removed". Remember this filter has a throttle; so the IP user making the occasional odd fix will never trip it. Suffusion of Yellow (talk) 21:22, 13 June 2022 (UTC)

958 (hist · log)

Hello, edit filter helpers/managers!

I was reviewing filter 958, but I noticed that you didn't list all the IPs of the U.S. Congress under WP:SIP. To provide better guidance, I'd like you to add 137.18.0.0/16, 12.185.56.0/29, 12.147.170.144/28, 74.119.128.0/22, 2620:0:E20::/46, 2620:0:8A0::/48, and 2600:803:618::/48, in case any of them edit.

If you cannot add these to the filter, then that is fine. — 3PPYB6 — TALK — CONTRIBS — 17:07, 28 March 2022 (UTC)

@Legoktm—Courtesy ping as you created this filter. — 3PPYB6 — TALK — CONTRIBS — 17:59, 28 March 2022 (UTC)

This filter is run for all anonymous edits, and it checks each edit against each IP range. For the sake of efficiency it makes sense for the filter to only use ranges which are actively used. The above are not. BTW I'm not really sure of this filter's general utility, since you could just check the contribs. Does anyone think it's useful? -- zzuuzz ^(talk) 18:55, 28 March 2022 (UTC)

This is one of those cases where "conditions" are a really poor measure of performance. An IP range check literally requires converting a few numbers from base 10, then checking against a bitmask. Probably takes a few hundred CPU cycles. But, yes, each check burns through one of our precious 1000 conditions, so I'd rather not do this unless either (A) the filter is converted to use regex, or (B), AbuseFilter is patched so that ip_in_range() takes multiple arguments.

And no, I don't see the point of the filter either. Suffusion of Yellow (talk) 20:01, 28 March 2022 (UTC)

@Suffusion of Yellow—In that case, I'll just say this: on second thought, merely checking WP:SIP should be enough for you to tell any congressional staffer's edits. If you feel that the filter is no longer required, feel free to delete it. — 3PPYB6 — TALK — CONTRIBS — 21:36, 28 March 2022 (UTC)

Don't particularly see the point of the filter either. I remember browsing its hits out of general interest before, to see what Congressional IPs are editing, but not sure of the maintenance purpose here (and even if there were one, what makes US Congress edits distinct to various other countries' parliamentary IPs, which aren't filter-logged?) ProcrastinatingReader (talk) 21:43, 3 April 2022 (UTC)

 Done Disabled the filter. Suffusion of Yellow (talk) 02:04, 8 April 2022 (UTC)

@ProcrastinatingReader, @Suffusion of Yellow: the main point of the filter is for tagging functionality, and I hope United States congressional staff edits to Wikipedia and Wikipedia:Congressional staffer edits explain the utility.

If performance is an issue, I guess I could just write a bot to add the tags instead of relying on AbuseFilter? As for why only US Congress...just my US bias as an American, happy to set it up for other countries/governments if we know their IP ranges. Legoktm (talk) 16:34, 13 April 2022 (UTC)

It's not that it has no utility; I just don't see much utility beyond Special:Contribs.

On the subject of performance, every now and then we get hit with the need for an "emergency" filter. That's not the time to fuss over the condition limit. So I like to keep a buffer of a few hundred conditions when things are "slow", and this looks like low-hanging fruit.

That said, I really doubt this filter actually slows anyone down significantly; as I said IP range checks are a trivial calculation. Suffusion of Yellow (talk) 18:09, 13 April 2022 (UTC)

Sorry if I'm a bit late to the party here but I was just looking through the filters and it seems filter 1025 does something similar (just without the tagging), would it also be worth disabling this? FozzieHey (talk) 16:57, 29 April 2022 (UTC)

@FozzieHey: Sorry for the late response. I was waiting for the ip_in_ranges() function to be merged. Now that this sort of check is "cheaper", I'm not going to disable it for now. Suffusion of Yellow (talk) 20:30, 31 May 2022 (UTC)

Restored

Thanks to WhitePhosphorus, we now have an ip_in_ranges() function, so checking for many ranges should only take up one condition. I've restored the filter (@Legoktm:), with the original three ranges. If anyone wants to add 3PPYB6's suggestions, go ahead. In the meantime, can anyone figure out why I can't restore the tag? I get One or more of the tags you specified is not valid. Tags should be short, they must not contain special characters, and they must not be reserved by other software. Try choosing a new tag name.. But I didn't even change the name, and it worked before. Suffusion of Yellow (talk) 20:30, 31 May 2022 (UTC)

What specific tag are you asking about? — xaosflux ^Talk 23:14, 31 May 2022 (UTC)

@Xaosflux: congressedits. There was apparently nothing wrong with it a few months ago, but now I get the above error message when I try to save the filter with that tag enabled. Suffusion of Yellow (talk) 23:28, 31 May 2022 (UTC)

@Suffusion of Yellow try now, I reactivated that tag. — xaosflux ^Talk 23:32, 31 May 2022 (UTC)

Ok, that worked. But why? You activated it for manual use. That's not supposed to have any effect on the filter. And we don't want people tagging their own edits as congressedits. So I guess we can deactivate it again now? I'm lost. Suffusion of Yellow (talk) 23:36, 31 May 2022 (UTC)

It was stuck in "unused" status, that fixed it, I've set it back to tagged by filter only now. — xaosflux ^Talk 23:59, 31 May 2022 (UTC)

Thank you all for getting this filter back up! Legoktm (talk) 16:15, 1 June 2022 (UTC)

On a related note, should Special:AbuseFilter/1025 also have a tag on it? 67.21.154.193 (talk) 13:04, 2 June 2022 (UTC)

@Dreamy Jazz: Your call. Suffusion of Yellow (talk) 20:40, 13 June 2022 (UTC)

Created a new tag for non-specific parliament / house of commons edits, and assigned that filter the newly created tag. Dreamy Jazz ^{talk to me | my contributions} 10:47, 14 June 2022 (UTC)

Taking a quick look at filter 3 it looks like filter 3 would catch a new user blanking a page they are the only significant contributor to in good faith (G7). This could make new users think you aren't allowed to blank a page as a deletion request. Filter 3 should probably detect if the user is blanking their own page and allow it then. interstatefive  21:28, 12 June 2022 (UTC)

@Interstatefive filter 3 only impacts articles, which are not really someone's "own page", and a blank article isn't going to be useful for our readers at all. The filter variables "page_recent_contributors" and/or "page_first_contributor" have performance issues as well. That being said, they don't just get blindly denied, they get this special message: MediaWiki:Abusefilter-disallowed-blanking, is there something in there that you think can be improved? — xaosflux ^Talk 21:53, 12 June 2022 (UTC)

@Xaosflux Per WP:G7, blanking pages can be taken as a deletion request, but filter 3 prevents that. It should check if the blanking user is the only major contributor to the article, or the message should be updated with info about G7. interstatefive  02:47, 13 June 2022 (UTC)

@Interstatefive The filter used to have a "page_recent_contributors" check for this, but I removed it, because the filter only applies to non-autoconfirmed users, who cannot create articles, so this issue is not possible. Galobtter (pingó mió) 05:24, 13 June 2022 (UTC)

@Galobtter True. But non-autoconfirmed users can create drafts, and sometimes they want those deleted. interstatefive  14:10, 13 June 2022 (UTC)

@Interstatefive filter 3 doesn't apply to drafts. Galobtter (pingó mió) 17:40, 13 June 2022 (UTC)

Oh yeah :P interstatefive  18:05, 13 June 2022 (UTC)

We certainly can add to that message, drop an edit request at MediaWiki talk:Abusefilter-disallowed-blanking with any suggestions! — xaosflux ^Talk 09:37, 13 June 2022 (UTC)

I did it. NotReallySoroka (talk) 19:54, 18 June 2022 (UTC)

However, upon closer inspection, I would argue that the message is unnecessary. Filter 3 only activates for non-confirmed users blanking the mainspace. Since non-confirmed users cannot create mainspace pages, they would have no reason to G7 a page: if they have written no pages, they have no pages that would satisfy the G7 requirement of being the author of a target page. Although there is a case of a new author drafting a page, the page got sent to mainspace, then the author asks for deletion, I do not think that this is important enough for everyone who trips filter 3 to see it. NotReallySoroka (talk) 20:02, 18 June 2022 (UTC)

There is now a "user_global_editcount" that can be used instead of "user_editcount" to avoid affecting globally active users (T130439). I've been the victim of exactly this issue on two wikis when removing spam references, being blocked by filters that are meant to prevent reference-removal vandalism. It's not much of an issue for non-disallowing filters, as experienced users can skip warnings themselves. As a first step, can someone create a list of publicly viewable filters that currently use user_editcount and are set to "disallow"? ~ ToBeFree (talk) 20:09, 21 June 2022 (UTC)

@ToBeFree:

(new mw.Api()).get({
	action: 'query',
	list: 'abusefilters',
	abfshow: ['!deleted', '!private', 'enabled'],
	abflimit: 500,
	abfprop: ['id', 'actions', 'pattern'],
	format: 'json',
	formatversion: 2
}).done(function(response) {
	var ret = [];
	for (let i of response.query.abusefilters) {
		if (i.pattern.includes('user_editcount') && i.actions.split(',').includes('disallow')) {
			ret.push(i.id);
		}
	}
	console.log(ret);
});

12, 247, 260 and 320. NguoiDungKhongDinhDanh 21:01, 21 June 2022 (UTC)

Probably find out first how expensive this is. IIRC, user_global_groups can be really slow. If this one is "cheap", then we can say:

user_global_editcount < 20 &
added_lines rlike "badwords" &
...

But if it's expensive we should probably say:

user_editcount < 20 &
added_lines rlike "badwords" &
...
user_global_editcount < 20

Daimona Eaytoy, is there any harm in looking at this variable on every action, like we already do for the some of the other user_ variables? Suffusion of Yellow (talk) 21:19, 21 June 2022 (UTC)

Per the phabricator task, if I understand correctly, this seems to be just as cheap as user_editcount, as it is a simple lookup of a table value without any calculations. ~ ToBeFree (talk) 21:26, 21 June 2022 (UTC)

Thank you very much, NguoiDungKhongDinhDanh! I have used the code to identify all affected active filters and will have a look at each of them as soon as the syntax checker recognizes the variable. It currently doesn't, so I guess the change isn't rolled out yet. ~ ToBeFree (talk) 21:28, 21 June 2022 (UTC)

@Suffusion of Yellow: I didn't follow that task, but IIUC this variable should not be particularly expensive. CentralAuth itself was changed so that it stores the global edit count (actually an estimate) in a dedicated table, and querying that table should be relatively fast. That said, I guess it could be slower than user_editcount if nothing in the same request has caused the global editcount to be already computed (which I think could be fairly uncommon, as opposed to preloading the local editcount). I haven't benchmarked it though, so I also don't want to give suggestions that could be wrong. --Daimona Eaytoy (Talk) 10:12, 22 June 2022 (UTC)

There are a quite a few open requests there that haven't really received a response there by admins/EF mamagers. I suggest someone go over them. Some unanswered ones have already been archived

[11] not archived as of now

[12] archived, no response. 67.21.154.193 (talk) 13:33, 21 June 2022 (UTC)

We need a mechanism for edit requests regarding edit filters.. 0xDeadbeef 07:28, 24 June 2022 (UTC)

Moved to Wikipedia:Edit filter/Requested/Archive 20 § EF 189 and ccnorm/norm

0xDeadbeef 06:23, 7 July 2022 (UTC)

Please consider removing "|db-unpatrolled" - referring to the now-deleted {{db-unpatrolled}} - from the end of line 9 of filter 98. Thanks and please ping on reply. NotReallySoroka (talk) 12:14, 7 July 2022 (UTC)

@NotReallySoroka:  Done in Special:AbuseFilter/history/98/diff/prev/27323 — TNT (talk • she/her) 04:12, 13 July 2022 (UTC)

No screw ups this time, I promise. I implemented ccnorm for analyzing AbuseFilter/260's matches so it should be fine:

Case { src: "AUSFAILIA", count: 0 }
Case { src: "YAMAL AO2", count: 0 }
Case { src: "NJOTRANS", count: 0 }
Case { src: "GENERISK", count: 0 }
Case { src: "ION (?:DETOXIFY|CLEANSE)", count: 0 }
Case { src: "DETOX FOOT SPA", count: 0 }
Case { src: "NATION(?:AL)? DEBT RELIEF", count: 0 }
Case { src: "YOUR ANONYMOUS VPN", count: 0 }
Case { src: "LSGLASSES\\.COM", count: 0 }
Case { src: "MEEBO BAR WAS LAUNCHED", count: 0 }
Case { src: "SHAVED MY BALLS", count: 0 }
Case { src: "CORY JUDE", count: 0 }
Case { src: "CLEM WASHINGTON", count: 0 }
Case { src: "THE BROTHER ZEN", count: 0 }
Case { src: "YOLOSWAG", count: 0 }
Case { src: "CENSORS THE TRUTH", count: 0 }
Case { src: "9GSOO7EGS8", count: 0 }
Case { src: "I[- ]?8(OO[- ]?(?:98G[- ]?AS2O|87O[- ]?7AI2)|77[- ]?929[- ]?EE7E)", count: 0 }
Case { src: "DIFF=82(?:SI88EG8|GII9SGO)\\b", count: 0 }
Case { src: "OLDID=82(?:SSE78OE|GII9A82)\\b", count: 0 }
Case { src: "USER:BONADEA_AND_USER:FAVONIAN_ARE_SOCKS", count: 0 }
Case { src: "RICHARD MADENFORT", count: 0 }
Case { src: "REGGIE BRADLEY", count: 0 }
Case { src: "78ESOAIEOI", count: 0 }
Case { src: "DREU[FV]", count: 0 }
Case { src: "DISUSEKID}", count: 0 }
Case { src: "HPHELPNUMBER", count: 0 }
Case { src: "CRUI[SZ]IR", count: 0 }
Case { src: "\\bMY SEMEN", count: 1 }
Case { src: "\\bROYER\\d", count: 1 }
Case { src: "▄▄█▀▀", count: 2 }
Case { src: "BUTTPEE", count: 2 }
Case { src: "OH ?SHI-", count: 3 }
Case { src: "\\bPE[MN]JS", count: 3 }
Case { src: "CAT EYES 2OO7", count: 5 }
Case { src: "HUEHUEHUE", count: 6 }
Case { src: "RICK MARTY", count: 6 }
Case { src: "CRUI?Z[IE]?[DR]+\\b", count: 6 }
Case { src: "TASLIMSON", count: 6 }
Case { src: "HUE HUE HUE", count: 8 }
Case { src: "U MAD BRO", count: 10 }
Case { src: "[FV]UERD", count: 14 }
Case { src: "EA8O7778EAG", count: 16 }
Case { src: "NIGGAH", count: 17 }
Case { src: "\\bASS+[ \\-]HAT\\b", count: 18 }
Case { src: "GNAA\\b", count: 18 }
Case { src: "(?:DICK|COCK) IN (?:THE)? (?:ASS+|BU[TM]+|MOUTH)", count: 19 }
Case { src: "SHREK IS LOVE", count: 45 }
Case { src: "FUCKING KILL", count: 71 }
Case { src: "STUPID BITCH", count: 98 }
Case { src: "WIKIPEDIA (?:BLOW|SUCK)", count: 132 }
Case { src: "I LIKE (?:PIE|CHEESE)", count: 156 }
Case { src: "CLETUS ?BARTHOLOMEW", count: 195 }
Case { src: "\\b(?:ASS+|BU(?:TT+|M+))[- ]?(?:R(?:APE|AEP)|(?:PH|F)UCK)", count: 259 }
Case { src: "\\bLIGMA\\b", count: 1052 }
Case { src: "PORN[- ]?STAR", count: 1744 }
Case { src: "HAHAHAHA", count: 2496 }
Case { src: "\\b(?:MAS+IVE|ENORMO?US|HUMO+NGO?US|HUGE|TINY|SUCK(?:ED|ING|S)?|MY|MAH|HIS) (?:(?:KAW|[CK]O)[CK]+|DICK?|PRICK|BALL*S|A[SZ]{2,})\\b", count: 6510 }
Case { src: "NIGG(?:A(H\\W)?|ER)", count: 8377 }

This counts the matches for the last 52 weeks. 0xDeadbeef 14:03, 16 July 2022 (UTC)

@0xDeadbeef: Thanks! I removed everything with 0 hits, and also the redundant "NIGGAH". Doesn't seem to cause any false negatives in the last 2000 hits (about two months). Suffusion of Yellow (talk) 17:58, 18 July 2022 (UTC)

614 (hist · log)

Hello, I have written some Rust code to identify individual matches on 614, as a way to find unused cases and also get some interesting data.

Here's a list of individual cases in that regex and how many times it was hit for the past 52 weeks:

Case { src: "fetus\\s*deletus", count: 1 }
Case { src: "you'?ve\\s*been\\s*gnomed", count: 1 }
Case { src: "e+s+k+e+t+i+t", count: 2 }
Case { src: "gucci\\s*gang[\\s,]*gucci\\s*gang", count: 3 }
Case { src: "hard\\s+(?:pp|peepee)", count: 3 }
Case { src: "hit\\s*or\\s*miss[\\s,]*I\\s*guess", count: 3 }
Case { src: "#sw[4ae]g", count: 4 }
Case { src: "(?:f[u\\*][c\\*]k(?:ing?|ed|s)|sex\\s*with?)\\s*chickens?", count: 4 }
Case { src: "#redirect\\s*\\[\\[donald[\\s_]trump\\]\\]", count: 5 }
Case { src: "#yolo", count: 6 }
Case { src: "ugandan\\s*knuckles", count: 7 }
Case { src: "420\\s*b+l+a+z+e+\\s*i+t+", count: 8 }
Case { src: "tran?s?.?manian?\\b", count: 10 }
Case { src: "y\\s*o\\s*[lo\\s]+s\\s*w\\s*[4ae]+\\s*g+", count: 11 }
Case { src: "\\by+o+l+o[lo]+", count: 11 }
Case { src: "s+w+[4ae]+gg[g]+", count: 11 }
Case { src: "(?:pp|peepee)\\s+hard", count: 12 }
Case { src: "chicken\\s*f[u\\*]?[c\\*]k(?:er|s|ing)?", count: 16 }
Case { src: "bush\\s*did\\s*9.?11", count: 16 }
Case { src: "hitler\\s*did\\s*nothing?\\s*wrong", count: 20 }
Case { src: "\\bdat\\s* boi", count: 24 }
Case { src: "epst(?:ei|ie)n\\W+did\\s*n.?t\\s+kill", count: 30 }
Case { src: "rawr\\s*xd", count: 31 }
Case { src: "dank\\s*meme", count: 36 }
Case { src: "ok(?:ay)?,? boomer", count: 40 }
Case { src: "drumpf", count: 41 }
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: 43 }
Case { src: "(?:them'?s?|dems?|those\\s+are)'?\\s+(?:th[ea]|da)\\s+fa(?:cts|x)!?", count: 48 }
Case { src: "\\booo+f+\\b", count: 52 }
Case { src: "sw[4ae]g\\s*(?:yolo|daddy|money|lord|master)", count: 57 }
Case { src: "\\bt+r+o+l(?:o+l|ll)", count: 60 }
Case { src: "absolute\\s*unit", count: 75 }
Case { src: "\\bayyy", count: 89 }
Case { src: "\\bnibb+a+\\b", count: 98 }
Case { src: "\\bbruv+\\b", count: 103 }
Case { src: "sub(?:scrib(?:e|es|ed|ing))?\\s*(?:to|2)\\s*(?:p(ew|ud|ue|uw|oo)|te*.?series)", count: 115 }
Case { src: "\\b(?:ranboo|tubbo)", count: 153 }
Case { src: "\\beats?\\s*ass\\b", count: 155 }
Case { src: "b+o+iii", count: 234 }
Case { src: "\\br+eeeeee", count: 279 }
Case { src: "\\bg+a+yy(?:y|\\b)", count: 415 }
Case { src: "quandale\\s*dingle", count: 445 }
Case { src: "\\bt+\\s*h+\\s*i+\\s*c\\s*c", count: 456 }
Case { src: "aviation\\s*,[\\s\\S]*?there\\s*is\\s*no[\\s\\S]*?bee[\\s\\S]*?be\\s*able\\s*to\\s*fly", count: 478 }
Case { src: "chung[uea]s\\b", count: 564 }
Case { src: "lolo(?:lo)+", count: 807 }
Case { src: "\\by+ee+t+(?:e+(?:r+|d+))?\\b", count: 858 }
Case { src: "h+iiiii", count: 1014 }
Case { src: "dQw4w9WgXcQ", count: 1033 }
Case { src: "\\bh+iii+\\b", count: 1035 }
Case { src: "hehehe", count: 1414 }
Case { src: "\\bbruh+\\b", count: 1819 }
Case { src: "\\bl+m+a+o", count: 1868 }
Case { src: "\\buwu\\b", count: 1885 }
Case { src: "joe m[oa]m+a", count: 1966 }
Case { src: "(?:69\\D*420|420\\D*69|(?:69\\D{0,50}){3,})", count: 3164 }
Case { src: "(?:d[3e](?:[3e]+[sz]+|[sz][sz]*)e*|th[3e][zs$][3e])\\s*n+u+t+[zs$]", count: 5537 }

I removed negative lookarounds in some regexes because those are not needed for correctness but more so that the library I am using does not support them.
should this be called yolo swag anymore..?
inspect the sources if you would like at GitHub. 0xDeadbeef 16:51, 15 July 2022 (UTC)

Filter 614 is called "Yolo swag and other vandalism trends" since 2014 - are you seeing it just say the former somewhere? — xaosflux ^Talk 12:01, 16 July 2022 (UTC)

Xaosflux, I was proposing that the yolo swag part is removed so it could just be "vandalism trends" or "vandalism trends and memes". 0xDeadbeef 13:33, 16 July 2022 (UTC)

Okay, there might have been a screw up. I didn't make it case insensitive. I will look into this again and post a more correct data dump. 0xDeadbeef 13:41, 16 July 2022 (UTC)

Updated. Looks like they all hit some stuff. It would be nice, though it would be nicer if I added a date for the latest hit. 0xDeadbeef 14:56, 16 July 2022 (UTC)

Thanks again! I renamed it to "Memes and other vandalism trends". I might remove some of those low-hit patterns too. Suffusion of Yellow (talk) 18:57, 18 July 2022 (UTC)

My thought is a tag that would be useful in detecting Wikipedia:Lead dos and don'ts violations. The difficult part is where the cut off should be so adding hatnotes or minor grammatical changes are not tagged. So basically just new prose. Richard-of-Earth (talk) 17:04, 2 August 2022 (UTC)

Which aspects specifically would you like to look into detecting? Length? Parenthetical phrase count? Bolding? I don't know if this stuff is a good fit for an edit filter, but hammering out the details is the next step to discussing this, I think. –Novem Linguae (talk) 19:09, 2 August 2022 (UTC)

Well my first thought was people who add new information to an article in the lead, but not in the body. So I guess we would look at the size of the addition. This is likely to include a lot of false positives, but might still be useful. Maybe a separate tag for bolding in the lead. Such tags might encourage editors to patrol the leads. This is very much a half-baked idea. Richard-of-Earth (talk) 21:49, 2 August 2022 (UTC)

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

Theoretically this should work:

!("confirmed" in user_groups) &
page_age == 0 & 
contains_any(page_namespace, 10, 14, 4) &
!(page_prefixedtitle in "^Wikipedia:(Articles for deletion\/.+|Categories for discussion\/Log\/\d{4} \w{3,9} \d{1,2}|Files for discussion\/\d{4} \w{3,9} \d{1,2}|Miscellany for deletion\/.+|Redirects for discussion\/Log\/\d{4} \w{3,9} \d{1,2}|Templates for discussion\/Log\/\d{4} \w{3,9} \d{1,2})$")

I don't have access to EFH, so I can't test it, but if an EFM could create a test filter for this, it would be much appreciated. 🐶 EpicPupper ^{(he/him | talk)} 03:29, 4 August 2022 (UTC)

Here's a regex101 test: [13] 🐶 EpicPupper ^{(he/him | talk)} 03:36, 4 August 2022 (UTC)

The middle 2 lines should be:

page_age == 0 & 
contains_any(page_namespace, 10, 14, 4) &

I'm not sure if there's a better way to do the title check. It can be done using substr but that won't be better than regex for accuracy and might not make a significantly beneficial performance difference, if any at all. PhantomTech[talk] 04:36, 4 August 2022 (UTC)

I forgot to add SPI. It's in there now. 🐶 EpicPupper ^{(he/him | talk)} 04:40, 4 August 2022 (UTC)

And thanks! 🐶 EpicPupper ^{(he/him | talk)} 04:40, 4 August 2022 (UTC)

Err, on second thought, SPI probably shouldn't be included; I'm thinking this should be a create-type filter rather than edit. There would be too many good-faith pages where IPs/non-AC'ed users could edit (the Teahouse comes to mind, but excluding that I think there would be much more still). 🐶 EpicPupper ^{(he/him | talk)} 05:40, 4 August 2022 (UTC)

Summarizing!

!("confirmed" in user_groups) &
page_age == 0 & 
contains_any(page_namespace, 4, 10, 12, 14, 710, 828) &
!(page_prefixedtitle in "^Wikipedia:(Articles for deletion\/.+|Categories for discussion\/Log\/\d{4} \w{3,9} \d{1,2}|Files for discussion\/\d{4} \w{3,9} \d{1,2}|Miscellany for deletion\/.+|Redirects for discussion\/Log\/\d{4} \w{3,9} \d{1,2}|Templates for discussion\/Log\/\d{4} \w{3,9} \d{1,2})|Template:Did you know nominations\/.+$")

The above code checks if non-autoconfirmed users create a new page in the Wikipedia, Template, Help, Category, TimedText or Module namespaces. It excludes XfD and DYK. This filter should likely be a tag filter. TheresNoTime, can I ask you for a favor? 🐶 EpicPupper ^{(he/him | talk)} 22:25, 4 August 2022 (UTC)

Testing at Special:AbuseFilter/1 (previous test promoted to filter) — TheresNoTime (talk • she/her) 22:31, 4 August 2022 (UTC)

A few comments:

• contains_any(page_namespace, 10) is not the proper way to check for namespaces; for example, it tests true for namespaces 100 and 101. Use equals_to_any(page_namespace, 10)
• if you're checking for "Wikipedia:Articles for deletion/" PLUS "whatever", you might as well check for "Wikipedia:Articles for deletion/" alone; saves some processing time. Same for other strings, in most cases there's no need to be that specific unless you're gonna use the rest of the string for something.
• "in" is not a regex operator, use rlike. When using ^ and $, what's in between needs to go inside a noncapturing group, "^(?: )$"

Documentation is here.

Ponor (talk) 00:29, 5 August 2022 (UTC)

This is right, here's the modified filter

!("confirmed" in user_groups) &
page_age == 0 & 
equals_to_any(page_namespace, 4, 10, 12, 14, 710, 828) &
!(page_prefixedtitle rlike "^(?:Wikipedia:(?:Articles for deletion\/|Categories for discussion\/Log\/\d{4} \w{3,9} \d{1,2}$|Files for discussion\/\d{4} \w{3,9} \d{1,2}$|Miscellany for deletion\/|Redirects for discussion\/Log\/\d{4} \w{3,9} \d{1,2}$|Templates for discussion\/Log\/\d{4} \w{3,9} \d{1,2}$)|Template:Did you know nominations\/)")

PhantomTech[talk] 04:33, 5 August 2022 (UTC)

Thanks for being speedy, a step ahead of me. @TheresNoTime could you tweak the filter? Sorry, this was my suggestion. 🐶 EpicPupper ^{(he/him | talk)} 04:38, 5 August 2022 (UTC)

Changes made (more fool me for only clicking "check syntax" and not properly reading it, given it was log-only.. will be a bit more careful next time) — the debugging tools in AbuseFilter is really useful for testing out things like this — TheresNoTime (talk • she/her) 10:23, 5 August 2022 (UTC)

To further simplify: while it doesn't hurt, forward slashes do not need to be escaped (\/). Use "rescape" function in debug console to see that. Ponor (talk) 08:57, 5 August 2022 (UTC)

While it isn't a special character in regex and doesn't need to be escaped for the filters here, it is the default delimiter at regex101 for PCRE so I think that's why it is escaped. PhantomTech[talk] 09:22, 5 August 2022 (UTC)

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

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

Hmmm, so these are usernames, that if they were to edit - we would be blocking for username violations? — xaosflux ^Talk 18:54, 24 August 2022 (UTC)

Probably some, but not all. And almost never hardblocking. I can't see blocking "Malayalam Malayalam Malayalam" at all. But "Matttttttttttttttttttttttttttttttttttttttty" is kind of difficult to ping without cutting-and-pasting, so maybe they'd be at least strongly encouraged to change their username. Even if they were blocked, they'd get a clear talk page message about what to do next, and an opportunity to appeal with "Hey, I've been editing foowiki for years and nobody has objected, would you reconsider?". Since the filter disallows creation, they can't say anything on enwiki at all without exposing their IP or creating another account. Suffusion of Yellow (talk) 19:12, 24 August 2022 (UTC)

@Suffusion of Yellow is the largest problem here that "filters that are triggered by autocreateaccount, do not present the disallow message"? Not sure where it would display though? What happens to these users when they try to click log in? — xaosflux ^Talk 20:06, 24 August 2022 (UTC)

@Xaosflux: I just tried disallowing (1014 (hist · log)) the name "Suffusion of Yellow alt 9" here, then creating that account on testwiki. When I come back to enwiki, I just get the usual logged out view with no message explaining why (but an attempt to create the account is logged). When I try to log in, I do get the filter message, but that's not really helpful, because there's still no convenient way to report a FP on enwiki.

I suppose we could direct them to meta:Special:GlobalRenameRequest, but what if they don't want to change it? How do they say "hey, can I keep this name please?" Suffusion of Yellow (talk) 20:30, 24 August 2022 (UTC)

@Suffusion of Yellow we could send them to WP:UTRS, the same admins that could unblock them could allow the creation. — xaosflux ^Talk 20:43, 24 August 2022 (UTC)

I guess, but that seems like overkill for the problem these filters are trying to solve. What's the backlog at UTRS?

I also forgot, there's another problem with disallowing account creation: If they don't try to log in and just want to read pages, they never know they're being filtered and can end up flooding the log with hundreds of hits. Frankly that's even a bit creepy privacy-wise; the whole world can see when they're online! Suffusion of Yellow (talk) 20:50, 24 August 2022 (UTC)

The current UTRS backlog is: 2 appeals within a few hours. — xaosflux ^Talk 20:53, 24 August 2022 (UTC)

Wow I can't believe that phab:T21161 is 13 years old and still waiting.... — xaosflux ^Talk 20:55, 24 August 2022 (UTC)

According to that task, it was exploited in the wild 13 years ago. Suffusion of Yellow (talk) 21:03, 24 August 2022 (UTC)

I agree that disallowing autocreate should be a last resort. Is/was there a known issue the disallowing aims to solve? firefly ( t · c ) 20:23, 24 August 2022 (UTC)

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

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

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

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

It's not set to disallow so it shouldn't be causing any actual problems. PRAXIDICAE🌈 21:01, 17 August 2022 (UTC)

Ah, this is probably filter 1202 mentioned below? In that case, the filter itself is probably OK at the moment, but there's still a backlog at WP:EFFP of edits that got caught in it while it was broken and set to disallow. --ais523 21:03, 17 August 2022 (UTC)

I've gone and completely refactored and improved the conditions for filter 1202. I've temporarily disabled the disallow action so that we can watch for any unexpected fallout or false positive hits as a result of the changes I made. Any EFM is free to re-enable the disallow action if they feel that the changes I made did not result in any negative effects as a result. ~Oshwah~^{(talk) (contribs)} 06:15, 8 September 2022 (UTC)

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

@Ohnoitsjamie: FYI — TheresNoTime (talk • she/her) 15:37, 16 August 2022 (UTC)

Oops, thanks for shutting that off! I was trying to fix some false positives, I think I got some nesting wrong. OhNoitsJamie ^Talk 15:43, 16 August 2022 (UTC)

Re-enabled (log-only), with a consistent indentation style, because I couldn't follow the logic either. @Ohnoitsjamie:, unless it's an emergency, whenever I make a non-trivial change to a disallowing filter, I either do a quick spot-check at Special:AbuseFilter/test, or, for complex changes, set the filter to log-only for about ten minutes or so. I realize that it can be it bit tedious to do this every time, but that was over 1500 false positives. Suffusion of Yellow (talk) 21:02, 16 August 2022 (UTC)

Thanks for cleaning that up, I realize it was a bit incomprehensible; it covers a small handful of LTAs. OhNoitsJamie ^Talk 21:08, 16 August 2022 (UTC)

@Ohnoitsjamie: NP. Let me use this opportunity to shamelessly plug some of my own tools:

• User:Suffusion of Yellow/filterDiff: A "show changes" button.
• User:Suffusion of Yellow/batchtest-plus: Test against past hits. Mostly usefull for checking for false negatives, but you can check for FPs by testing against 1201 (hist · log) ("Random sample of non-autoconfirmed edits").
• User:Suffusion of Yellow/effp-helper: For cleaning up the mess afterwards. Suffusion of Yellow (talk) 21:20, 16 August 2022 (UTC)

Suffusion of Yellow - DAMN! Thanks for sharing these! I'm going to import them and check them out! Awesome! :-D ~Oshwah~^{(talk) (contribs)} 06:22, 8 September 2022 (UTC)

I've gone ahead and completely refactored and improved all of the conditions for filter 1202. I've temporarily disabled the disallow action so that we can watch for any unexpected fallout or false positive hits as a result of the changes I made. Any EFM is free to re-enable the disallow action if they feel that the changes I made did not result in any negative effects. If I did make any mistakes or cause issues, please let me know and I'll be happy to take a look. :-) Cheers - ~Oshwah~^{(talk) (contribs)} 06:15, 8 September 2022 (UTC)