Wikipedia:Edit filter noticeboard

Welcome to the edit filter noticeboard

WATCH Recent filter changes (): Filter 380 — Pattern modified Last changed at 03:50, 15 May 2024 (UTC) Filter 1305 — Actions: disallow,throttle Last changed at 17:51, 13 May 2024 (UTC) Filter 1285 — Pattern modified Last changed at 21:34, 12 May 2024 (UTC) Filter 1014 — Flags: enabled; Pattern modified Last changed at 19:20, 12 May 2024 (UTC) This is the edit filter noticeboard, for coordination and discussion of edit filter use and management. If you wish to request an edit filter, please post at Wikipedia:Edit filter/Requested. If you would like to report a false positive, please post at Wikipedia:Edit filter/False positives. Private filters should not be discussed in detail here; please email an edit filter manager if you have specific concerns or questions about the content of hidden filters. There are currently 322 enabled filters and 47 stale filters with no hits in the past 30 days. Filter condition use is ~1004, out of a maximum of 2000. (). See also the profiling data and edit filter graphs. Click here to start a new discussion thread

Tagging and anti-spam filters

• 499 (hist · log) "Possible spambot or promotional username"
• 752 (hist · log) "Possible spamming of references"
• 935 (hist · log) ""ntsamr"-pattern spambot filter"
• 974 (hist · log) "Link-Spam catch"
• 1048 (hist · log) "Possible spam"

Right now there's no way for non-EFH/EFM/admin users to patrol the logs of any of these filters. I don't think the conditions can be refined to the point where warning or disallowing is possible. Should some, or all, of these filters start tagging? Of course there's a slight BEANS risk; spammers will be able to bring up a list of matches and try to work out what the conditions are, but does anyone think that's an acceptable risk? There's no point in logging an action if no one checks the log. Another possibility would be to combine all the private anti-spam filters under one tag; that would make it harder to figure out which edit tripped which filter. Suffusion of Yellow (talk) 19:43, 5 May 2020 (UTC)

@Suffusion of Yellow: just commenting generally, when I patrol edit filter logs here and on other wikis, I find it annoying to click on the diff links, only to find that the edits have already been reverted. What about (just an initial idea), a bot:

• Edit that is saved successfully trips one of the filters
• Bot periodically looks at edits that have tripped the filters, checks if they are the current revision, and if so, posts them to a list
• non-EFH/EFM/admin users can watch that list and revert the edits
• next time the bot runs the edit is no longer the current revision and is removed from the list

This would make it harder for comparing a list of matches, since it wouldn't say what filter it was, and would only list edits that weren't already reverted. If an admin wanted to delete the page each day to block access to the history, that would make it even harder to extract the conditions. Thoughts? DannyS712 (talk) 20:27, 5 May 2020 (UTC)

@DannyS712: Still thinking about the bot, but I created User:Suffusion of Yellow/mark-reverted.js in part to deal with that annoyance. Suffusion of Yellow (talk) 00:30, 6 May 2020 (UTC)

@DannyS712: What if instead the bot lists pages where any of the added_links are currently live on the page? That would be more useful, particularly on active pages where another editor changes the content without removing the link. It could even catch cases where the spammer's edit is disallowed, then they modify something and the edit saves without tripping any filters. Suffusion of Yellow (talk) 20:18, 12 May 2020 (UTC)

@Suffusion of Yellow: not sure that would be practical - it would require either storing the attempted links in a database or manually querying them each time DannyS712 (talk) 20:29, 12 May 2020 (UTC)

Another possibility, which could work in tandem with DannyS712's original idea. Beetstra, would it be possible for COIBot to generate reports for all the added_links in certain filter hits? In the past day, the filters mentioned above got 86, 67, 22, 2, and 56 hits respectively. Throw in a few public filters (e.g. 80 (hist · log) and 149 (hist · log)), and you might be looking at about 300 extra reports a day. Would this overload the bot? Suffusion of Yellow (talk) 21:12, 12 May 2020 (UTC)

Suffusion of Yellow, it would be possible, but I would have to write that functionality into the bot. I have been thinking about something along that lines once, maybe I should think about doing that somewhere in the near future. I'll put it on my todo list. Dirk Beetstra ^{T C} 08:18, 13 May 2020 (UTC)

@Beetstra: Thanks! No hurry of course; COIBot is already immensely useful as it is. Suffusion of Yellow (talk) 17:32, 13 May 2020 (UTC)

Circling back - any support for such a bot report? DannyS712 (talk) 07:37, 22 May 2020 (UTC)

EFH for QueerEcofeminist

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

---

• • QueerEcofeminist (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)}
• I have been cleaning vandalism, copyvios, webhost vios, link spamming for a while here, my csd log might help you to look into that. Having access to privet filters would help me more to find LTA's, identify sock-puppets more efficiently. Additionally I am temporary sysop on mrwikisource too. There we hardly have made use of edit filters, I would like to set up few to identify vandalisms. But before that I would like to learn from enwiki and work on things like LTA's, vandalisms, copyvios, socks. Having access to privet logs will help me a lot. thanks QueerEcofeminist ^{"cite! even if you fight"!!!} [they/them/their] 02:36, 15 May 2020 (UTC)

• How will private filter access help on mrwikisource? Do the same LTAs here vandalize there the same way? Crow^Caw 15:10, 15 May 2020 (UTC)
• If they hardly use filters in mrwikisource, then they don’t have too many LTA. If you guys have LTA wouldn’t there been more filters to stop them? Signed,The4lines |||| ^{(You Asked?) (What I have Done.)} 15:15, 15 May 2020 (UTC)

• I am not planning to make any changes to the filter right away to mrwikisource, but I will gather information from here and obviously I have use of this right here first and mrwikisource would be an additional benefit. Yes to answer User:The4lines, We don't have LTA's like enwiki for sure, but as we go ahead we need to have some basic protection/mechanism to deal basic vandalism. and it's a really new project which is coming alive recently.
• So yes, I my intention to ask for this right is to view and help here and learn from it, so that by the time mrwikisource reaches to really active mode, I can use my learnings from here in addition to vandal fighting I would be able to do here. QueerEcofeminist ^{"cite! even if you fight"!!!} [they/them/their] 17:36, 15 May 2020 (UTC)

• If you only have to stop basic vandals, the public filters would work just fine. Signed,The4lines |||| ^{(You Asked?) (What I have Done.)} 17:40, 15 May 2020 (UTC)

pinging @QueerEcofeminist: Signed,The4lines |||| ^{(You Asked?) (What I have Done.)} 17:41, 15 May 2020 (UTC)

• There's really nothing you can learn from private filters that you can't learn from the public ones. Crow^Caw 19:13, 15 May 2020 (UTC)

  Crow, right but as I said even before, that use of learnings here would be byproduct of work I will do here on enwiki. I did made it clear that I want to use the right to work here itself. Thanks QueerEcofeminist ^{"cite! even if you fight"!!!} [they/them/their] 20:01, 15 May 2020 (UTC)

  Interestingly what should be public and what shouldn't is something one needs to learn. QueerEcofeminist ^{"cite! even if you fight"!!!} [they/them/their] 20:03, 15 May 2020 (UTC)

• If you want to learn, then the public filters are more than adequate. There's nothing the private filters will give you that the public ones won't. There's no compelling need for the abilities EFH gives, so I must oppose at this time. Crow^Caw 15:28, 16 May 2020 (UTC)

  Crow, I am not getting, why you guys are ignoring my first part of every argument that, I want this right to see and work here first? is that part invisible? or I am not making it enough clear? QueerEcofeminist ^{"cite! even if you fight"!!!} [they/them/their] 16:01, 16 May 2020 (UTC)

• I've not been ignoring it, but you've done zero work with filters here. EFH is not something you just get without having a demonstrated need, and I personally don't see such a need. Crow^Caw 17:58, 16 May 2020 (UTC)

  Crow, I have been using filters to find problematic edits and tagged edits while patrolling, and that's what I am asking for, permission to view, obviously you will have your own opinion on this also. Thanks for your comments QueerEcofeminist ^{"cite! even if you fight"!!!} [they/them/their] 01:25, 17 May 2020 (UTC)

• Oppose per Crow and me. Signed,The4lines |||| ^{(You Asked?) (What I have Done.)} 17:48, 16 May 2020 (UTC)
• Oppose per Crow. This is putting the cart before the horse. I recommend helping out with false positives and learning through that. Nihlus 15:19, 18 May 2020 (UTC)

  Nihlus, thanks, that is helpful comment. QueerEcofeminist ^{"cite! even if you fight"!!!} [they/them/their] 02:21, 19 May 2020 (UTC)

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

EFM for creffett - courtesy notification

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

---

Hi folks, since I've now got the admin bit, I'm planning to add +EFM to myself as well so I can do some actual work with the filters. Posting this as a courtesy notification in case anyone wants to object (I know that admins may self-grant at their discretion, but I feel more comfortable checking for objections first). I'll wait a couple of days before assigning the bit. Also, to those who remember my request for EFH six months ago - as you can see, I decided to take the easier approach of getting +sysop instead of going through the stress of requesting EFH again :) creffett (talk) 14:37, 18 May 2020 (UTC)

• I wasn't that hard on you, was I? sad crow No objections here. Crow^Caw 14:44, 18 May 2020 (UTC)

Creffett, Make it so. Guy (help!) 14:45, 18 May 2020 (UTC)

I second that. Signed,The4lines |||| ^{(You Asked?) (What I have Done.)} 15:02, 18 May 2020 (UTC)

Best of luck, feel free to ask questions here. — xaosflux ^Talk 13:12, 27 May 2020 (UTC)

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

New or unregistered user blanking someone else's user or user talk page Edit filter

Is there a reason why New or unregistered user blanking someone else's user or user talk page is private when what it does is mentioned in the description visible to everyone see https://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=JoshGaming2003 🌸 1.Ayana 🌸 (talk) 17:18, 19 May 2020 (UTC)

• Probably because there are exceptions that could be exploited by a malicious user. Crow^Caw 17:40, 19 May 2020 (UTC)

• The definition of 'blanking' in 34 has shifted over the years since 2009. From the changes I looked at, it appears to have been adjusted to handle different kinds of vandalism while still attempting to allow legitimate changes. Since it is a heavily-used filter and gets many hits, it would not be wise to share the contents widely. EdJohnston (talk) 18:11, 19 May 2020 (UTC)

• You Might want to change the description visibility to everyone to something different as I do not think it’s a good description for a private filter as it reveals too much informatio🌸 1.Ayana 🌸 (talk) 11:46, 20 May 2020 (UTC)

I disagree; the current name helps regular editors know what is going on while not giving out the exact definition of blanking (that might allow vandals to circumvent it). EdJohnston (talk) 13:56, 20 May 2020 (UTC)

Set filter 1061 to disallow

• Filter 1061 (hist · log) (private)

I created this filter per MusikAnimal's suggestion on the mailing list. Normally I wouldn't set a filter to disallow so quickly, but I don't think this one will have an overwhelming number of FPs. I'll keep an eye on the log, of course. Suffusion of Yellow (talk) 23:03, 21 May 2020 (UTC)

Looks good to me. Thanks! — MusikAnimal ^talk 23:14, 21 May 2020 (UTC)

Suffusion of Yellow, looks good to me, would it be worthwhile to add an edit count check as well? creffett (talk) 23:39, 21 May 2020 (UTC)

@Creffett: Of course. Thanks for spotting that. Done. Suffusion of Yellow (talk)

• Can you define Line 1's vars in the notes section of the filter, for ease of easiness? Crow^Caw 13:55, 24 May 2020 (UTC)

  @Crow: Not clear what you mean. The whole notes section is a just a script that generates the filter. Suffusion of Yellow (talk) 18:22, 26 May 2020 (UTC)

@MusikAnimal, Creffett, and Crow: Probably should note that the filter is doing something very different now, but is still set to disallow. I've tested it on 1013 (hist · log); there were a few false positives so the filter should probably be set to log-only when the LTA is inactive. Suffusion of Yellow (talk) 01:54, 8 June 2020 (UTC)

Requesting Wikipedia:Edit_filter_helper right (EEng)

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

---

EEng (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)}

Been thinking for some time I might help out with filters, and this will let me get my toe in. Pinging User:David Eppstein, who knows my technical qualifications. EEng 02:32, 24 May 2020 (UTC)

We all know you just want to find the private filter we use to track your image "contributions" Standard question: what private filters are you interested in working with? creffett (talk) 03:28, 24 May 2020 (UTC)

This gentleman gets sufficient bulk in his diet. He has a regular expression.

-EEng

None in particular. But I've been coding regexes since before they were called regexes so I suspect I could help out. I pledge to use this power only for good, never for evil. EEng 03:56, 24 May 2020 (UTC)

EFH doesn't really help if your goal is to edit filters, apart from granting access to Special:AbuseFilter/test. But anyhow, what sort of filters would be interested in creating/editing? Galobtter (pingó mió) 05:36, 24 May 2020 (UTC)

Seconded, if your intent is to work with filters, EFM is the right for you. EFH is only for tracking LTAs or similar. --qedk (t 愛 c) 05:39, 24 May 2020 (UTC)

From a discussion with Suffusion of Yellow it appears there are some performance problems with LTA defenses, and random probes into the filter log shows longstanding notes for desired improvements to filters that haven't been acted upon, so it seems help is needed. To familiarize myself with current goings-on I looked through User:MusikBot/FilterMonitor/Recent_changes but, it turns out, all but one of the filters there is private, so I thought EFH would let me learn more without anyone worrying that I might break some of the crockery, and of course there's Special:AbuseFilter/test. Assuming no one thinks I'm a security risk I thought this would be a straightforward matter. Should I have requested EFM instead? EEng 16:55, 25 May 2020 (UTC)

@Suffusion of Yellow: thoughts? Galobtter (pingó mió) 21:51, 26 May 2020 (UTC)

I support EFM and EFH, whichever EEng wants; I also see no problem with someone requesting EFH as a first step. Trusted, competent. ~ ToBeFree (talk) 08:11, 27 May 2020 (UTC)

Support EFH - long term trusted user with a clear reason and low risk. --DannyS712 (talk) 08:45, 27 May 2020 (UTC)

• Support. But don't think about The Event. Guy (help!) 11:56, 27 May 2020 (UTC)
• Support. Since I was pinged here. I don't see a problem with this. Usually we ask for more experience with filters, but that's mostly to weed out the hat-collectors and socks, and obviously EEng is neither.. Suffusion of Yellow (talk) 17:54, 27 May 2020 (UTC)

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

• Other than wikipedia-en-editfilters is there a good place to chat/ask questions behind the scenes? EEng 00:03, 28 May 2020 (UTC)

  Hitting up anyone who happens to be in IRC. — xaosflux ^Talk 16:13, 28 May 2020 (UTC)

  Sorry to be dense, but which IRC? EEng 21:00, 28 May 2020 (UTC)

  EEng, freenode. People are usually accessible in #wikipedia-en. More info at WP:IRC. Enterprisey (talk!) 23:35, 28 May 2020 (UTC)

  But for edit filter discussions aren't we supposed to use the Cone of Silence? EEng 00:07, 29 May 2020 (UTC)

Questions

If it's OK, I'll start by asking non-sensitive questions here. First: is there an easy way to test new code against more than the 100 recent changes provided for by Special:AbuseFilter/test (other than, I suppose, doing 100 over and over)? EEng 14:29, 29 May 2020 (UTC)

@EEng: Like User:Enterprisey/abusefilter-diff-check? --Mdaniels5757 (talk) 03:00, 31 May 2020 (UTC)

Thanks but though that's useful it's not what I mean. Here's what I mean: suppose one's considering adding or changing a filter. Naturally it would be reassuring to test its behavior on a large number of recent edits. Special:AbuseFilter/test will run a candidate filter against 100 recent changes, but that strikes me as a small number, especially if the filter e.g. applies only to a particular namespace. Is there a way to test against a larger set, maybe offline somewhere? This would let me fool around with filter features in complete safety. EEng 03:06, 31 May 2020 (UTC)

I'm not aware of an on-wiki way to do that but I haven't been arsed to bother applying for EFH, so I haven't actually been able to visit that page, only read the docs. I'm sure there are plenty of ways to test regex matching offwiki, and you could probably implement most of the conditionals yourself, but it would probably bee more work than it's worth. --Mdaniels5757 (talk) 03:59, 31 May 2020 (UTC)

So let me guess: the way a new or changed filter gets tested, in practice, is to start it off as log only (or whatever) so a few minutes, hours, or days (depending on the urgency of the abuse to be blocked) can go by to see whether it trips when they shouldn't, before promoting it to disallow (or whatever)? EEng 04:12, 31 May 2020 (UTC)

Ding ding ding! (also, I'm surprised I didn't earn an EEngImg from that typo :) --Mdaniels5757 (talk) 04:18, 31 May 2020 (UTC)

Yup, precisely. Honestly being able to test over 100 edits is a pretty good idea. I'll see if there's some way to write a user script to do that. The AbuseFilter API isn't that great, so my hopes aren't high. Enterprisey (talk!) 04:20, 31 May 2020 (UTC)

EEng, see #abusefilter-mass-test. Enterprisey (talk!) 07:28, 31 May 2020 (UTC)

Wow, the service around here is really quick! EEng 15:34, 31 May 2020 (UTC)

Question 2: To get me some practice, does anyone have a filter that needs some adjustment done, maybe one that kind of does the job but could use fewer false positives or negatives? EEng 15:39, 31 May 2020 (UTC)

There is certainly the queue at Wikipedia:Edit filter/False positives. — xaosflux ^Talk 02:41, 1 June 2020 (UTC)

That got me really excited, but so far it seems that there are these eager beavers fixing everything right away, leaving nothing for us newbies to do. Maybe there's some old project that's been hanging around with no one wanting to bother -- maybe something along the lines of Review filters x, y, and z to make sure they incorporate new list of ..." EEng 17:35, 1 June 2020 (UTC)

Revising guidance on what editors EFH is useful for

WP:EFH lists "Those working with edit filters on another WMF wiki who want to learn from the English Wikipedia's experience and approach" as a reason for granting edit filter helper. In practice, this is only granted when the editor on the other wiki specifically needs access to private filters, as learning about edit filters in general can be done from public filters. Is there support for adding something like "and specifically need access to private filters, as most active filters are public"? There are occasional requests from editors on other wikis who may not realize that on enwiki filters are generally public. I also wonder if similar guidance should be added to "Those interested in helping with edit filters but who do not meet the thresholds required to be able to modify them." as in general EFH doesn't help those who want to eventually modify filters apart from granting access to Special:AbuseFilter/test. Galobtter (pingó mió) 06:18, 24 May 2020 (UTC)

• I would agree with this. The private filters are almost exclusively enwiki-specific, so will be of little practical use to anyone not fighting the same vandal. I would also remove some of the other presumptive entitlements (other than enwiki sysop) for various beansy reasons. Crow^Caw 13:51, 24 May 2020 (UTC)

The one thought I have is that (as far as I know, YMMV, void where prohibited) there are a few globally-useful filter concepts which are entirely locked in private filters. I'm thinking in particular of the image vandalism filters - they all have a very thorough check to identify possible image additions, but that check is probably BEANSy and the list of images is even more BEANSy. creffett (talk) 17:55, 25 May 2020 (UTC)

Disable filters 1040/1041?

• Filter 1040 (hist · log) "Coronavirus tracking" (public)
• Filter 1041 (hist · log) "Coronavirus tracking II" (public)

Prahlad balaji suggested at my talk page that these filters are a bit spammy. I'll admit I don't actually check the logs myself, but I had left them on, in case "someone" found them useful. Is anyone actually looking at the logs? Suffusion of Yellow (talk) 18:14, 26 May 2020 (UTC)

• I personally just skip them. It should also be noted that combined, both filters have 67,000+ hits, and most are just triggered by the words "COVID", "Coronavirus", or "COVID-19". --Stay safe, ◊PRAHLAD^balaji (M•T•A•C) This message was left at 20:26, 26 May 2020 (UTC)

  @Prahlad balaji:  Done. Suffusion of Yellow (talk) 01:57, 8 June 2020 (UTC)

​ Thank you! ◊PRAHLAD^balaji (M•T•A•C) This message was left at 14:15, 8 June 2020 (UTC)

1060 to disallow

Special:AbuseFilter/1060 has proven to be useful without false positives; let's set it to "disallow" as originally intended. QEDK, perhaps you could undo your modification, per the trolling concern mentioned at #Prohibit speedy deletion tag removal by page creator, and to make sure that we really have consensus. Disallowing this for experienced editors could be worth a new discussion. ~ ToBeFree (talk) 08:57, 27 May 2020 (UTC)

Additional note: On average, the filter required 0.3 conditions before, now 2. The original check was extremely performant; I guess it happened in a different filter before. ~ ToBeFree (talk) 09:01, 27 May 2020 (UTC)

You probably don't need the check for page_id > 63959834 (that extra check could actually slow the filter) since the next few checks for removal of a CSD tag would limit the number of edits for which page_first_contributor is accessed to quite few. 2 conditions and an average run time of 0.21 ms is definitely nothing to worry about. Galobtter (pingó mió) 09:20, 27 May 2020 (UTC)

Galobtter, I'm worried that the "page_first_contributor" check, as described at mw:Extension:AbuseFilter/Rules_format, may take a long time for some pages, such as (my personal interpretation) old noticeboards. The page_id check is meant to prevent abuse potential by tagging a noticeboard for speedy deletion. ~ ToBeFree (talk) 09:26, 27 May 2020 (UTC)

I don't see the abuse potential. Rollbacks bypass the edit filter anyways, extended confirmed users should definitely be excluded and so they can revert any such edits, and "slow" in the context of the abusefilter would probably mean like 500 ms or a few seconds (loading the oldest edits of ANI - [1] - is pretty fast for me). Galobtter (pingó mió) 09:33, 27 May 2020 (UTC)

(edit conflict) @ToBeFree: It's not an issue because as the last check, the number of edits which will hit it are the ones which are actually (probably) being disallowed, most edits will get filtered before reaching it. As for the sysop/extconfirmed, it's still policy to not remove CSD tags, it's entirely possible for a disagreeing admin/extconfirmed user to remove the tags for articles they create (personally I think tagging or warning for this use-case is better) but feel free to make any changes (and remove my note :) --qedk (t 愛 c) 09:34, 27 May 2020 (UTC)

I think it's a pretty bad idea to not exclude sysops or extended confirmed users because of the vandalism potential (as Floq mentions in the discussion) - not every policy violation has to be enforced with an edit filter and for established editors we can ofc warn etc if they violate policy. Galobtter (pingó mió) 09:37, 27 May 2020 (UTC)

(edit conflict) The vandalism potential exists for everyone right, not just sysops/extconfirmed, maybe a few sysops who have irked off more vandals but that's really about the only "difference". It's an arbitrary measure at best, and I'm not trying to prove you're wrong, but that vandalism is more random than we're making it out to be. :) --qedk (t 愛 c) 09:40, 27 May 2020 (UTC)

Ah, I have over-estimated the amount of time required to fetch the first contributor name on pages with a long revision history. All right; I have removed the page_id check. @QEDK: You do have a point, but forcibly preventing experienced users from applying WP:IAR isn't the purpose of the filter, and does not seem to have the required consensus. At the same time, we already have 173 hits that should have resulted in "disallow" action to reduce the amount of maintenance that has been proven to exist. 173 times, someone had to manually restore the tag; it's time to let the tested filter do its job. I don't want to undo your improvement of the regex at the same time, though, and I'm a bit uncomfortable with reverting your administrative modification of my administrative creation. Would you mind restoring the EC/sysop check for now, and giving your okay for "disallow" here? ~ ToBeFree (talk) 11:18, 27 May 2020 (UTC)

@ToBeFree: Seems like you missed the last part of my message - ...but feel free to make any changes (and remove my note :) It's not a strong point of contention for me, was just explaining my viewpoint. --qedk (t 愛 c) 11:46, 27 May 2020 (UTC)

QEDK, I was referring to it, but okay, I have now restored the EC/sysop exemption myself. What do you think about disallowing? If I understand correctly, your "tagging or warning" refers to EC/sysop editors, not those affected by the current filter. ~ ToBeFree (talk) 12:06, 27 May 2020 (UTC)

(edit conflict) I don't have much opinion on this tbh, I'd say go for it - we can always reconsider if things go awry. :) --qedk (t 愛 c) 12:07, 27 May 2020 (UTC)

• On a related note, do we or should we have a filter to warn if there's an attempt to add a CSD tag to a non-userspace page with a large edit history? There's a pretty clear expectation that an article wiht a long history would normally go through XfD. Guy (help!) 11:55, 27 May 2020 (UTC)

  Interesting thought! However, as far as I know, there is no variable that contains the number of revisions a page has. See mw:Extension:AbuseFilter/Rules_format. There is "page_age", but old pages with a small history can indeed qualify for speedy deletion. ~ ToBeFree (talk) 12:04, 27 May 2020 (UTC)

• {{db-author}} was missing, checking for the non-existent {{db-auth}}, causing a false positive today. Let's wait a week or two again. ~ ToBeFree (talk) 14:53, 28 May 2020 (UTC)

  Further research shows that "db-auth" existed when Special:AbuseFilter/29 was created. The template was deleted in 2011; the error went unnoticed in filter 29 for over eight years. I have now fixed it there too. ~ ToBeFree (talk) 15:01, 28 May 2020 (UTC)

abusefilter-mass-test

User:Enterprisey/abusefilter-mass-test lets you test filters with more than 100 edits. It's a little buggy, but works fine in the main use case, which is testing against all recent edits. Enterprisey (talk!) 07:27, 31 May 2020 (UTC)

@Enterprisey: cool. I'll note that, at least when I tried to use it, the logic for showing vs hiding non-matches appears to be flipped. Also, the script has a typeerror in the line elements[0].dataset.mwTs.substring( 0, 8 ); sometimes ("Cannot read property 'dataset' of undefined") - try running the script over the last 1000 edits with the pattern action = 'edit' & page_namespace == 8 and you should be able to reproduce DannyS712 (talk) 10:07, 31 May 2020 (UTC)

I think this is probably a great improvement, since not only can you test against a larger set of changes, but you can test against the same large set repeatedly as the filter is refined, or against a date range which contains a set of problematic changes from the past of a type which you want to defend against in future. (As I recall, under the prior version you just got whatever the latest 100 changes happened to be.)

Not to look a gift horse in the mouth, but a useful additional feature might be to allow testing of a pseudorandom sample within the date range. However, let's enjoy what you've already done. And if you decide to do that please talk to me, because I have some design advice. EEng 16:17, 31 May 2020 (UTC)

DannyS712, thanks for the suggestions - both have been implemented. EEng, that's also a great idea, and I would definitely like to have it. The underlying "API" is only able to do date ranges, however. So specifying a sample would be a bit wasteful, as the tests would be done on every edit anyway. If there's a use case where it would still be useful to have a sample, I'd be perfectly fine with implementing it anyway. Enterprisey (talk!) 19:26, 31 May 2020 (UTC)

@Enterprisey: You can use a query like https://en.wikipedia.org/w/api.php?action=abusefiltercheckmatch&filter=!(%22autoconfirmed%22%20in%20user_groups)&rcid=1267581277 to test a single edit. It will take 100 queries to test 100 arbitrary edits, of course, but that's not as wasteful as using /test. The question is, how many requests to send in parallel? User:Suffusion of Yellow/batchtest-plus.js uses the same module, and tries to keep 10 "in-flight" at a time. Fewer than that, and it gets tiring to wait for; sending all 100 at once seems to cause some to go missing, and is probably kind of rude anyway. Suffusion of Yellow (talk) 21:13, 31 May 2020 (UTC)

The use case -- and I'm not saying it's necessarily a significant one -- is where for some reason you want to test diffs drawn from a relatively wide time range (days? months?) but at the same time it's enough to take a small proportion of all the edits in that time range. But here's the thing: I don't understand enough (yet) about the data flow and relationship of the components to participate intelligently in a discussion of something like this, so let's put this in abeyance for now while I know more. For the record, my concern would be about the details of sampling, including how to seed the randnum generator to keep everything reproducible and yet give the user the ability to conjure up new samples when wanted; it's not hard but things need to be framed the right way. EEng 22:08, 31 May 2020 (UTC)

EFH request by User:Mdaniels5757

Hi. I've come into a few situations where the ability to view private filters would be helpful, and would like the EFH permission to help at WP:EFFP/R. I'd also like to assist with proposing/authoring filters; although I know EFH does not give the ability to directly edit filters, this would let me test them. Best, --Mdaniels5757 (talk) 15:43, 31 May 2020 (UTC)

• Support Since no one else wants to comment here, apparently. OTRS and account creator permissions shows you are already trusted with private data, and while your "stats" are a bit minimal, I don't get the impression this is a collect-the-hat-and-move-on request. Suffusion of Yellow (talk) 02:05, 8 June 2020 (UTC)

• I still maintain that Helping at EFFP doesn't meet the Need requirement (imho). Not sure if I want to actually oppose due to reasons though. I'd like to see your proposed filter as below. Crow^Caw 13:40, 8 June 2020 (UTC)

Let edit filter helpers modify log-only filters?

As some of the above discussions show, Special:AbuseFilter/test is crap. What if instead EFHs could create and modify log-only filters? This, I believe (ping @Daimona Eaytoy: just to be sure), could be accomplished with a only a configuration change:

1. Disable the almost-never-used blockautopromote action.
2. Mark the tag, warn, and disallow actions as "restricted".
3. Give the abusefilter-modify-restricted right to edit filter managers.
4. Give the abusefilter-modify right to edit filter helpers.

With all that done, EFHs could:

1. Create a filter in log-only mode
2. Modify a filter already set log-only

But could not:

1. Create a filter with any actions
2. Modify a filter with any actions
3. Enable or disable any actions

Nothing would change for EFMs. Admins would no longer be able to enable blockautopromote, but we haven't (intentionally) used that in years anyway. Thoughts, people? Suffusion of Yellow (talk) 22:51, 31 May 2020 (UTC)

Speaking as a lowly EFH myself, I think either someone's got the chops for writing filters or not. While clogging up the logs is an order of magnitude less serious than accidentally blocking edits (or accidentally not blocking them, for that matter) it still makes a mess. But... isn't the recent extension of /test a bit step forward? EEng 23:16, 31 May 2020 (UTC)

It doesn't feel good to rely on a (newly created, potentially buggy, unofficial, non-gadget) userscript when making this decision. The script, discussed a few sections above, is a nice idea, but it just proves the need for the proposed server change. ~ ToBeFree (talk) 01:44, 1 June 2020 (UTC)

As someone who has only recently self-assigned EFM, and who has noticed how educational the creation of a logging-only filter can be, this seems to be a reasonable proposal to me. There is no better way to prove one's suitability for EFM. EFH is restricted to users who are trusted to view hidden filters; the trust requirement behind this privilege already seems to be higher than for what is being proposed here. See also: meta:AbuseFilter for technical details. ~ ToBeFree (talk) 01:38, 1 June 2020 (UTC)

• I'm pretty opposed to this in general. EFH is meant to be a very low bar for people to help with certain use cases. WP:RFA is around the corner if you want to work on filters. Keep in mind that even log-only filters can have severe performance impacts if improperly created - so it's not really "read only". — xaosflux ^Talk 02:23, 1 June 2020 (UTC)

  That's pretty much what I was trying to say above. If /test isn't completely reliable, encouragement should be given to make it so. Personally I want to test my filter-writing skills in privacy to avoid humiliation. EEng 02:34, 1 June 2020 (UTC)

• @Suffusion of Yellow: What's being proposed here will work as you expect, but with unexpected side effects. The current (bad) design doesn't use $wgAbuseFilterRestrictions only as a list of actions for which you need abusefilter-modify-restricted. Instead, it's also used:
  1. For determining which actions to disable when the filter gets throttled;
  2. As a list of actions to be disabled for global filters matching a local edit, when $wgAbuseFilterDisallowGlobalLocalBlocks is true (although this doesn't affect enwiki);
  3. As a list of actions that cause "disallow" to be disabled automatically (i.e. tag+disallow would result in tag only, and disallow alone wouldn't work)

So you really cannot use this option right now. See also T175221. There's a patch under review for that task, but it should probably be refurbished and re-reviewed. Generally speaking, I suggest you make a list of what's wrong with the test interface and open a phabricator task with that, so I can try and fix the underlying issues. I cannot guarantee that I'll be able to look at it immediately, but having an idea would be great. --Daimona Eaytoy (Talk) 12:54, 1 June 2020 (UTC)

@Daimona Eaytoy: Thanks. Suspected there would be a catch, but it doesn't seem like this is getting much support anyway. I think the biggest problem with /test is basically phab:T102944, but as you say fixing it won't be easy. In fact, I'd say "nearly impossible"; where is new_wikitext supposed to come from when only new_wikitext_pst was saved in the database? Suffusion of Yellow (talk) 18:23, 3 June 2020 (UTC)

@Suffusion of Yellow: Exactly. And even for variables that we could recompute (e.g. user_groups, user_blocked, etc.) there's no easy way to do that. I think there's no real solution here; perhaps a warning box on /test; or maybe, even a complementary feature like T36180. --Daimona Eaytoy (Talk) 10:55, 4 June 2020 (UTC)

• I tend to agree with Xaosflux and EEng. I think the coding time could be better used making the Test tool more useful. As Daimona Eaytoy suggests, let's start a talk page regarding everything wrong with it, or absent features we'd like to see added. Not in favor of the original proposal, personally. Crow^Caw 13:18, 1 June 2020 (UTC)
• +1 to whatever Crow said. --qedk (t 愛 c) 19:06, 3 June 2020 (UTC)

Disallow empty edit requests

Moved from WP:EFR

 – ~ ToBeFree (talk) 04:04, 1 June 2020 (UTC)

• Task: Warn or disallow unregistered and new users from dropping an empty edit request on a talk page.
• Reason: From a repeated WP:RFPP request to semiprotect Talk:TikTok where a pattern of various IPs with no pattern have been leaving multiple edit requests, leading to the talk page having been protected several times for up to a month, however I've observed similar behaviour on many pages over time. A user saving an edit with the content of Template:Submit an edit request/preload unmodified should trigger the filter, if it's possible to code a filter to do that. Preventing this specific edit would be more useful than whack-a-mole protections. Ivanvector (^Talk/_Edits) 17:09, 31 May 2020 (UTC)

• It should be able to do that. We'd probably want a custom message displayed rather than the generic "your edit was unconstructive" for good faith edits of that sort. Crow^Caw 18:23, 31 May 2020 (UTC)

This is a recurrent time-wasting problem at many other pages too. To avoid people just typing a random letter to circumvent this, maybe there should also be a minimal number of characters in the edit request – I don't know the exact number, a minimal valid request would be something like "Fix the typo in [word]" (16 + [word]); maybe like 20 or if we want to be even more lenient 10. Cheers. RandomCanadian (talk / contribs) 18:38, 31 May 2020 (UTC)

I don't think this activity is malicious, I think it's just not following instructions, possibly by non-English editors. I'd like to see how much of it goes away if just saving the default unmodified template is flagged or disallowed, before we talk about expanding the criteria. Ivanvector (^Talk/_Edits) 18:47, 31 May 2020 (UTC)

It's definitely not malicious. It's just like we regularly get non-native speakers posting their CVs at (ironically, but not accidentally) WP:AUTOBIO -- there's something about the instructions that people misunderstand. EEng 06:19, 1 June 2020 (UTC)

• They're already being warned. 987 (hist · log), MediaWiki:abusefilter-warning-empty-edit-request. ping@Suffusion of Yellow: Someone will have to analyse the logs to see if there's any false positives before flipping the checkbox to disallow. -- zzuuzz ^(talk) 19:07, 31 May 2020 (UTC)

  @Ivanvector: Past discussion was at Wikipedia:Edit filter noticeboard/Archive_6#Change 987 to disallow?. There was some talk of a bot removing these requests, but it never went anywhere. Personally I'd no longer object to setting this to disallow; earlier I was worried about FPs, but I've been unable to find any. Suffusion of Yellow (talk) 03:41, 1 June 2020 (UTC)

  @Suffusion of Yellow: Sorry for not following up on the bot idea. If there are no false positives, I think the bot idea is better than disallow, because it would be less bitey and the bot would post a note on the user's talk pages. Do others support the bot idea? DannyS712 (talk) 05:57, 1 June 2020 (UTC)

• Perhaps the problem lies in {{Protected page text}} which is presented if someone clicks "View source" on a page protected beyond their pay grade. It offers a nice big blue inviting {{Submit an edit request}} button, but no way back. Once they've clicked on that, their options are another nice big blue inviting button "Publish changes" or a non-button red-text "Cancel" which runs counter to everything the wiki usually means by a redlink.

Altering {{Protected page text}} to offer a nice big green inviting button to take the user back to the parent page might reduce the occurrence of this error.

Altering "Cancel" across the wiki so it's a white-on-red button of equal prominence to "Publish changes" rather than a redlink may also help, not only for this problem, but in maintaining the consistent meaning of redlinks.

If this is the route by which editors are hitting this problem then, I'd say editors clicking on View source to take a look under the bonnet are at the more technically curious end of the spectrum and would be better served by an edit-filter rejection rather than a talk page message memorialising their mistake. Just my 2¢, Cabayi (talk) 07:54, 1 June 2020 (UTC)

@Cabayi: I'd be in favour of the change to {{Protected page text}}, and also in favour of disallowing empty edit requests through the edit filter. It's silly to make actual users review them, and just a waste of time overall - but of course, many people will, as you rightly point out, not be making them deliberately. This seems like a good approach to tackle the issue. Naypta ☺ | ✉ talk page | 14:30, 8 June 2020 (UTC)

• Just a quick note that because this filter would be disallowing good faith edits in other areas of the encyclopedia, it would require community consensus before implementation per WP:EF. Sam Walton (talk) 10:31, 1 June 2020 (UTC)
• Looks like we may need to disallow empty edit filter requests while we're at it [2]. EEng 19:02, 2 June 2020 (UTC)

​​​​​​​ This still happens. The IP here seems to have added a bunch of whitespace to evade the edit filter, while still typing a perfectly empty edit request... RandomCanadian (talk / contribs) 03:43, 8 June 2020 (UTC) Missed a few ​​​. RandomCanadian (talk / contribs) 03:45, 8 June 2020 (UTC)

@RandomCanadian: Nope - Special:AbuseLog/26948207 shows that the edit filter was tripped. Filing the BRFA now DannyS712 (talk) 03:46, 8 June 2020 (UTC)

@DannyS712:: oh, my bad, I thought it had already been enabled...  Self-trout RandomCanadian (talk / contribs) 03:47, 8 June 2020 (UTC)

BRFA filed

Please see Wikipedia:Bots/Requests for approval/DannyS712 bot 71, where I request approval to revert the empty edit requests with an informative summary --DannyS712 (talk) 03:53, 8 June 2020 (UTC)

I'm putting the above on hold until the original discussion decides what to do - if the consensus is to just not allow blank edit requests in the first place, this bot is rather pointless. Primefac (talk) 14:09, 8 June 2020 (UTC)

IRC channel for EFH/EFM

All, per a couple recent discussions I've BOLDly created an IRC channel for private edit filter helper/manager discussions (my thought is that having real-time discussion would be better for some things, like "can I get help nailing down this private regex," than the mailing list). The channel is #wikipedia-en-editfilters, set to invite-only. I'm not advertising it at WP:IRC yet in case the response here is "that's a dumb idea, why would you do that?" so if you want access (and are an EFH, admin, and/or EFM) just ping me on IRC or here. creffett (talk) 15:54, 1 June 2020 (UTC)

Also, if you're on the #-admins access list, you're automatically granted access to the channel. creffett (talk) 16:44, 1 June 2020 (UTC)

Not a dumb idea at all. EEng 20:09, 1 June 2020 (UTC)

Sounds like a good idea to me. I'm not involved enough to consider subscribing to the mailing list, but I'll add the IRC channel to my autojoin list and perhaps use it for filter-related discussion that I'd previously have had in -admins. ~ ToBeFree (talk) 23:53, 4 June 2020 (UTC)

ccnorm* and rm*

Oshwah, perhaps I'm missing something but wouldn't the ccnorm* and rm* functions at mw:Extension:AbuseFilter/Rules_format#Functions be of use in simplifying Filters 51 and 53 (and possibly improve their coverage)? EEng 20:00, 1 June 2020 (UTC)

LTA 1011

Sorry if this isn't publically revealable, but I've seen the filter that tags edits with "LTA 1011" in the abuse log a few times and was wondering which LTA it was intended to catch. Thank you, Passengerpigeon (talk) 03:43, 5 June 2020 (UTC)

• As you may have guessed, when we name them that way it is precisely because we don't want to ID the specific LTA or LTAs. Crow^Caw 14:03, 5 June 2020 (UTC)

LTA

My regex-fu is not quite strong enough to handle this LTA: Wikipedia:Long-term abuse/Joseph kargbo. We're getting requests for page protection, and I think this is a decent case for the filter; the issue is avoiding false positives. Guy (help!) 15:07, 5 June 2020 (UTC)

• See 864, tweaked slightly. Crow^Caw 15:56, 5 June 2020 (UTC)

Date comma additions

Hi. I wrote an edit filter that should help with Wikipedia:Sockpuppet investigations/Bowtiebandit edits like Special:Diff/957361611. Of course, as I'm not an EFH at this time (my request is above and pending), I can't test it or view it if it's set to private (which may be prudent per WP:BEANS). Please let me know if I should post it below on-wiki or how I should send it to an EFM. Best, --Mdaniels5757 (talk) 18:10, 5 June 2020 (UTC)

@Mdaniels5757: You can send something to WP:EFMAILING. Since your request above is now, technically speaking, at 100% support, you might be able to subscribe to the list soon, also. :-) Suffusion of Yellow (talk) 02:45, 8 June 2020 (UTC)

@Suffusion of Yellow:  Done. --Mdaniels5757 (talk) 16:40, 8 June 2020 (UTC)

New users storing climate data in userspace

I recently discovered that there was an edit filter for this purpose. Why is it problematic for new users to store climate data in userspace, and has this been done maliciously before? Passengerpigeon (talk) 03:24, 10 June 2020 (UTC)

The summary was "Wikipedia is being used as a webhost by an off-wiki forum for discussing fictional climate data. This should catch any new user adding the {weather box} template in userspace. (Bradv)".

I made the filter publicly viewable and disabled it. Prodego ^talk 03:50, 10 June 2020 (UTC)