Wikipedia:Edit filter noticeboard

Jump to navigation Jump to search
Welcome to the edit filter noticeboard
Filter 995 — Actions: disallow
Last changed at 00:49, 20 November 2019 (UTC)

Filter 891 — Pattern modified

Last changed at 12:53, 18 November 2019 (UTC)

Filter 260 — Pattern modified

Last changed at 20:33, 16 November 2019 (UTC)

Filter 799 — Flags: disabled

Last changed at 15:11, 16 November 2019 (UTC)

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

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

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


Click here to start a new discussion thread


Filter 384 (Addition of bad words or other vandalism) false positives[edit]

We currently have a long standing problem of many false positives coming from filter 384 (Addition of bad words or other vandalism), mostly in song names. To combat this I suggest adding

!(added_lines rlike "\[\[[^\]]{0,10}"+bad_word+"[^\[]{0,10}\]\]")

to check if it's inside a wikilink. If some edit filter manager could add this to the test filter (filter 1) that would be appreciated. I will monitor it to see if it works like I expect it to. --Trialpears (talk) 18:50, 5 October 2019 (UTC)

@Trialpears: That should be !(added_lines irlike ("\[\[[^\]]{0,10}(?:"+bad_word+")[^\[]{0,10}\]\]")) Note extra parentheses :-). Tried it against a dump of the last 1000 hits, and it looks like these 36 hits would have been excluded by the changes. I see a few FPs in there, but it's still mostly vandalism. Suffusion of Yellow (talk) 20:52, 20 October 2019 (UTC)
Suffusion of Yellow, sorry for late reply. I think this may be further improved by only having this exception for pages with {{infobox musical artist}}, {{infobox album}} and {{infobox song}}, which are the most affected by far. --Trialpears (talk) 20:50, 31 October 2019 (UTC)
@Trialpears: Special:Permalink/924107599. Batch one is 5000 hits from back in December. Batch two is the same 1000 hits as above. Batch three is the most recent hits. A few FPs in there, but still not much constructive editing IMO. People have some strong opinions about music, it would seem... Suffusion of Yellow (talk) 21:20, 1 November 2019 (UTC)
Suffusion of Yellow, I would say this was a fine trade off since a false positive is so much more damaging than a true negative, except for those real bad BLP violations. Now I think it may be best just to keep the status quo anyway. Was worth a try at least. Thanks for the help testing it! ‑‑Trialpears (talk) 10:19, 2 November 2019 (UTC)

Unprivate edit filter 31 (ASCII art)[edit]

Should edit filter 31 (ASCII art) be public? I don't see any reason why an ASCII art filter should be private, but could be wrong since I can't actually see the filter and don't know the history behind it. --Trialpears (talk) 09:16, 7 October 2019 (UTC)

The filter does contain some elements of long term abuse, but these are probably not so relevant these days (and could be filtered in other ways). A lot of entries are just memes which have had their day, and people won't be looking to circumvent. I think I'm in favour of making it public, but would want to hear from others. -- zzuuzz (talk) 10:48, 7 October 2019 (UTC)
@Zzuuzz: I think it shouldn't be public, given the exceptions on line 60 --DannyS712 (talk) 17:56, 7 October 2019 (UTC)
OK, noted, so I won't rush into anything before hearing more opinions. But if I understand your objection correctly, you are saying that a determined vandal could fiendishly devise some ASCII art which evades the filter? I refer to my original comments and would probably disagree with your objection. -- zzuuzz (talk) 18:58, 7 October 2019 (UTC)
I think it can be made public. Most ASCII-spamming vandals aren't going to bother trying to evade the edit filter. Reaper Eternal (talk) 19:32, 7 October 2019 (UTC)
I'd also support making it public. There's a mention in the notes about "spambots" circa 2014-2015, and a something about a "serial vandal" from a few years earlier, but skimming the recent hits, it all looks like ordinary childish vandalism. Suffusion of Yellow (talk) 22:23, 24 October 2019 (UTC)
And I realized that NawlinWiki is active again. Welcome back! Your thoughts? Suffusion of Yellow (talk) 22:25, 24 October 2019 (UTC)
I take the silence as tacit assent. Just checking @Suffusion of Yellow:, any further thoughts before the switch is flipped? -- zzuuzz (talk) 00:22, 3 November 2019 (UTC)
@Zzuuzz:. No.  Done. Suffusion of Yellow (talk) 19:35, 4 November 2019 (UTC)

Special:AbuseFilter/891 (ResearchGate)[edit]

Someone added ResearchGate doi's to the edit filter. That's rather overkill to lump those in the 'predatory journal' edit filter, especially without explanation.

If those are warranted in an edit filter, the warning it throws should at least warn that papers with ResearchGate dois are possibly (likely?) not peer-reviewed and might not be suitable as a reference. Headbomb {t · c · p · b} 19:50, 31 August 2019 (UTC)

Or rather, it should be split into a new filter, for "potential unreliable sources" with a priority lowered to "tag", rather than warn. Headbomb {t · c · p · b} 15:24, 1 September 2019 (UTC)
@Crow:, could you remove 10.13140 from this one. It's already in Special:AbuseFilter/1003. Likewise for removing frontiers\.in which pretty much does nothing since there's no such website. Also acacdemicjournals should be academicjournals. Headbomb {t · c · p · b} 21:50, 9 September 2019 (UTC)

De-archived as unresolved. Headbomb {t · c · p · b} 19:03, 7 October 2019 (UTC)

Specifically
  1. Remove 10.13140 since RG isn't predatory, and should be/is handled by Special:AbuseFilter/1003 instead
     Done Guy (help!) 11:43, 16 October 2019 (UTC)
  2. Remove frontiers\.in since that's not a domain in use for anything, and the likely intended target Frontiers Media is way too borderline to be covered by such a filter.
 Done#Fix acacdemicjournals to academicjournals
Headbomb {t · c · p · b} 19:13, 7 October 2019 (UTC)
@Xaosflux: could you take a look at this, since Crow seems to be on a break? Headbomb {t · c · p · b} 04:55, 16 October 2019 (UTC)
  • 3 done. — xaosflux Talk 11:08, 16 October 2019 (UTC)
  • Ping to @JzG: regarding other changes. — xaosflux Talk 11:09, 16 October 2019 (UTC)
Frontiers has been fixed to the correct domain, but that is still an abuse of the edit filter, which should be restricted to clearly predatory publishers, not borderline cases. Headbomb {t · c · p · b} 21:17, 18 October 2019 (UTC)
@JzG: FWIW, frontiers.in is now responsible for 67 of the last 100 hits. I have no opinion about the removal of this from the filter, but it needs to mentioned in Mediawiki:Abusefilter-warning-predatory, along with scirp.org and academicjournals if it's going to stay. Right now only lists biomedres.info, cennser.org, and cpinet.info, which must be confusing to users. Suffusion of Yellow (talk) 19:54, 4 November 2019 (UTC)
@JzG: And now we are both calling it frontiers.in for some reason... See my edit request at Mediawiki talk:Abusefilter-warning-predatory. Suffusion of Yellow (talk) 20:46, 4 November 2019 (UTC)
Suffusion of Yellow, reviewing those edits was... illuminating. Some non-MEDRS, quite a bit of self-promotion Guy (help!) 21:06, 4 November 2019 (UTC)
Headbomb, In your opinion. It was added because of the reputation of Frontiers for substandard material, and because most additions are non-RS additions to medical articles. Guy (help!) 21:07, 4 November 2019 (UTC)
There are many substandard sources used, but the filter for predatory journals should be restricted to predatory sources. Frontiers maybe be crap-ish, and not WP:MEDRS, but medicine does not rule all of Wikipedia. Headbomb {t · c · p · b} 21:35, 4 November 2019 (UTC)

Tags cleanup[edit]

Is there any reason why the removal of COI template, large plot addition, disambiguation template removed, possible birth date change, missing file added, predatory and deprecated source tags are activated for manual addition to edits? Seems they should only be applied by filters. Not a big deal but it does add clutter to API help pages (eg [1]). Any objection if I deactivate these? Suffusion of Yellow (talk) 23:19, 4 November 2019 (UTC)

@Suffusion of Yellow: some of these were recently added, see this log, I'd check with the creators first. — xaosflux Talk 16:17, 5 November 2019 (UTC)
@Galobtter, JzG, Premeditated Chaos, and Zzuuzz: Any reason for these to be manually applied? Special:Tags doesn't make it very clear, but when you save a filter with a non-existent tag, it seems to be created automatically. At least, I never touched anything at Special:Tags and yesterday and yet this works. Suffusion of Yellow (talk) 21:10, 5 November 2019 (UTC)
I can speak for the removal of COI template tag. It was not my intention that it be manually applied. The reason it is so, and remains so, is the lack of documentation. I seem to recall failing to fix it for whatever reason, but have at it. -- zzuuzz (talk) 21:23, 5 November 2019 (UTC)
The deactivate button worked for me. The filter is still applying the tag. So perhaps MediaWiki:Tags-create-explanation should make it clear that the form is only for manually applied tags. Suffusion of Yellow (talk) 21:54, 5 November 2019 (UTC)
Suffusion of Yellow, feel to deactivate any of those tags created by me. I did not know that the tags would be automatically created and created the tags while creating their descriptions etc. Galobtter (pingó mió) 02:51, 6 November 2019 (UTC)
Suffusion of Yellow, I have no idea how I created that tag except that it's probably a screwup related to me trying to figure out the tag on this edit. Feel free to delete it or deactivate it or whatever is done with tags. ♠PMC(talk) 06:57, 6 November 2019 (UTC)

───────────────────────── Thanks. Deactived Galob's and PMC's tags. Also deactivated deprecated source (@JzG: not a problem, yes?). predatory can probably be deleted also (admin needed) as it's not used by any filter. @MusikAnimal: just noticed one of those is yours. large plot addition is only for use by the filter, correct? Suffusion of Yellow (talk) 02:59, 8 November 2019 (UTC)

I didn't realize I could delete tags, for some reason I figured an interface admin was required. I've deleted my screwup :) ♠PMC(talk) 06:31, 8 November 2019 (UTC)
Suffusion of Yellow, predatory was designed for assignment to 891. It's probably not needed as tag-watchers probably won't understand the issues, so it can go. Deprectaed only needs to be added by filters. Guy (help!) 11:08, 8 November 2019 (UTC)
@JzG: 891 uses Citing predatory open access journal. See [2]. The predatory tag had only ever been applied to one edit, IIRC. Suffusion of Yellow (talk) 03:45, 9 November 2019 (UTC)
Oh, then it's probably left over form me being an idiot. Please feel free to nbuke it! Guy (help!) 10:15, 9 November 2019 (UTC)
@Suffusion of Yellow: I guess I didn't know we had control over whether tags could be manually added or just via a filter! Yes, in this case it should be filter-only. Thanks MusikAnimal talk 17:58, 8 November 2019 (UTC)
Thanks, done. Suffusion of Yellow (talk) 03:48, 9 November 2019 (UTC)

Bot idea for EFFP[edit]

What do you all think of a bot that would automatically tag private filters and blocked users in EFFP reports? For me this seems like a great excuse reason to create a bot of my own (I've been wanting to do that for a long time). --Majavah (t/c) 15:54, 5 November 2019 (UTC)

@Majavah: There's no such thing as a bad excuse to write code. :-) That said, I'm not sure how useful that would be if that's all the bot does. But if you are in a coding mood, I can think of other possibilities, such as:
  • Fill in the "page you were editing" field if the user left it blank.
  • List which filters the user tripped recently, and how many times.
  • Link to past (archived) reports from the same page or user.
  • An opt-in system, where EFMs are pinged about FP reports regarding selected filters.
  • ...any other ideas, people?
Still, if you want to write a bot that does only what you suggested, I'd have no objection. Suffusion of Yellow (talk) 02:35, 8 November 2019 (UTC)
A better archiving solution would be great. Currently a not insignificant smount of reports get archived prematurely and a bot looking for a done template may help solving this. ‑‑Trialpears (talk) 07:20, 8 November 2019 (UTC)
I've started working on the bot. At it's current state, the bot can add the page name if left blank and add the private notification message if filter is private. About the archiving, should it just move all requests with fixed, done, not done, declined or blocked to an archive, or should it have more complex logic? --Majavah (t/c) 15:29, 8 November 2019 (UTC)
Pinging @Suffusion of Yellow and Trialpears for opinions for the archival system. --Majavah (t/c) 19:14, 11 November 2019 (UTC)
@Majavah: Sorry for the late response. Just thinking out loud here, not saying this is best:
  • I'd say {{effp}} first should be expanded with a few more options, if we're going to tag everything for the bot. There will always be some edge cases not covered by the current options. Maybe just a generic "Done" and "Not done" that say nothing else?
  • Ideally, removal times should be user configurable for each type of response, so we don't have to bug you with endless requests to adjust times. I.E. {{effp|fixed}} responses are moved after x hours, {{effp|question}} after y hours, responses with no templates are moved after z hours, where x, y, and z are settable from some semi-protected page in the bot's userspace.
  • Should the bot remove reports marked only with {{effp|v}} (and no additional comments), per WP:DENY? IMO, yes. What do you think? Suffusion of Yellow (talk) 19:40, 11 November 2019 (UTC)
    Fully agree with the above. I think vandalism should be removed as well, partly due to DENY but also simply because archiving them isn't particularly useful. I also think non tagged things should be archived as well, but after a significant amount of time (5 days maybe). ‑‑Trialpears (talk) 20:11, 11 November 2019 (UTC)

───────────────── The technical implementation of the features seems to be working (except archival) and now there is a configuration page, however I'd like to get the templates adjusted before filing a BRFA.

  • About the archival, would a rolling archive like the one at WP:RPP suffice?
  • About {{effp}}:
    • Do we really need separate "not done" and "declined"?
    • Should there be a generic starting like "Automated comment" or should the bot use different template messages for each of its responses? Should the bot prefix {{effp|private}} and {{effp|blocked}} with the "automated comment" note?
    • We also need a "closed" template.

Once those are decided I believe the bot is at a stage where I can file the BRFA and (hopefully) start the trial. Also pinging @Suffusion of Yellow and Trialpears so they notice this. Majavah (t/c) 17:38, 18 November 2019 (UTC)

@Majavah: I'm going to be away for a few days, but I was thinking that {{effp}} would be adjustable without modifying the bot (only the config page); would that be possible? Otherwise we might get locked in to something we don't like. Are you just saying you want something concrete for the BRFA folks? Suffusion of Yellow (talk) 18:37, 18 November 2019 (UTC)
And yes, I think "Automated comment" would be a good idea, so new users know not to respond to the bot or ask it questions. Suffusion of Yellow (talk) 18:38, 18 November 2019 (UTC)
@Suffusion of Yellow: My primary question is that should the messages be stored in the {{effp}} template or on the config page? --Majavah (t/c) 18:49, 18 November 2019 (UTC)
Off the top of my head, {{effp}} makes more sense. Something like {{effp|private|bot=1}} or {{effp|privatebot}} would produce the bot's variant of the message. Suffusion of Yellow (talk) 19:01, 18 November 2019 (UTC)
Agree with Yellow here. For the other questions I think separating not done and declined is appropriate since then we can archive declined vandalism faster and without archiving while letting good faith but inappropriate edits be archived normally when using the not done option. I also think generic closed option would be good just to alert the bot that it's archive time. ‑‑Trialpears (talk) 20:41, 18 November 2019 (UTC)
I've went ahead and added a few parameters to the sandbox page. Any objection or should I merge those to the main template? --Majavah (t/c) 15:14, 19 November 2019 (UTC)

A bug in Special:AbuseFilter/627[edit]

Integer division in the filter language does not truncate any remainder. Therefore, (article_namespace / 2 = 59) will only match when article_namespace is 118 and not 119, which is not what the filter is intended to work (according to the notes of the filter). There are multiple ways to fix this bug. Change it to (page_namespace === 118) | (page_namespace === 119) is one possibility. --Nullzero (talk) 23:58, 6 November 2019 (UTC)

Thanks, Nullzero! Filter fixed. (Courtesy ping MER-C). FYI, there's now an equals_to_any() function, which saves conditions over multiple ===s. Suffusion of Yellow (talk) 02:21, 8 November 2019 (UTC)

Urgent[edit]

[3] EEng 19:32, 9 November 2019 (UTC)

Per ANI and recent suppressions, I think Special:AbuseFilter/1008 would be prudent at this point. What do people think? Guy (help!) 19:58, 9 November 2019 (UTC)

I assume the filter is active while you're waiting for comment. Also, a question: does this filter also catch an attempt to create an article whose title is this string (or variations)? EEng 20:42, 9 November 2019 (UTC)
@JzG: I've changed the name - I hope the reasons are obvious, and feel free to pick something better. I've also enabled the filter, but temporarily lifted the disallow, as a testing phase. I have one main observation: such a filter takes things out of the world of suppression and into the realm of admins, EFMs, and EFHs. -- zzuuzz (talk) 21:06, 9 November 2019 (UTC)
Yup. A wider group. Guy (help!) 21:58, 9 November 2019 (UTC)
Perhaps an unorthodox use of that checkbox, but given that it is apparently a privacy/BLP-sensitive thing, would it make sense to hide it from public view so that the filter log does not spill the information we want to keep off the wiki? Jo-Jo Eumerus (talk) 22:03, 9 November 2019 (UTC)
It is hidden, and thus the logs are hidden. I did accidentally make it public for a short time but soon fixed that. There are three separate hits so far, all suppressed, so I think it's probably good to go as an urgent filter. It might actually reduce the size of the group, because now only certain privileged editors will see attempts to add the content. Hope you can monitor it somewhat Guy(s)? -- zzuuzz (talk) 22:05, 9 November 2019 (UTC)
I can't see who has been oversighting all the log entries, but now that the filter is disallowing, is that really necessary? The "secret" information is right there in the filter pattern, so nothing new is learned from the hits, except which article I should add to my watchlist, in case people start evading the filter. Yes, if there's something about the username or target page that gives it away, that would be different, but so far from what I've seen that hasn't been the case. Suffusion of Yellow (talk) 20:00, 10 November 2019 (UTC)
@Suffusion of Yellow: the filter log also contain the entire edit that was attempting to be made, so it has more then just the match word. The OS team is aggressively working on this issue across the project. — xaosflux Talk 21:45, 10 November 2019 (UTC)
@Xaosflux: Alright I guess. So, Special:AbuseLog/25297666 is not oversightable, then? It only contains the match word. Suffusion of Yellow (talk) 22:02, 10 November 2019 (UTC)
@Xaosflux: Just commenting generally from experience with oversight filters, when the filter maintainers can't see the filter hits and misses, we kind of rely on the OS crew to either take it easy, take responsibility for catching all the filter misses, and/or help to maintain the filter themselves. Unfortunately there doesn't seem to be a great crossover between EFM and OS, so hopefully you can be conscious of this gap and fiddle where necessary. -- zzuuzz (talk) 22:40, 10 November 2019 (UTC)
I'll try to watch as well, and I've looked through the old hits. No FP's so far, there have been between 10 to 20 total hits. Some are just the addition of the filter catch, some also included additional content. — xaosflux Talk 23:20, 10 November 2019 (UTC)
And just because it hasn't been suppressed as of now, doesn't mean it is appropriate or won't be suppressed still. — xaosflux Talk 23:21, 10 November 2019 (UTC)
I assume we'll get to see any false positives, so that's not the issue. The filter misses are the real blind spot; EFMs can normally get this info from the editors or the articles in order to improve the filter, and now it gets completely removed. An example. So thanks to you and ST47 for helping tweak the filter where appropriate. -- zzuuzz (talk) 23:34, 10 November 2019 (UTC)
New permutations to add: [4], [5] (both suppressed) DannyS712 (talk) 03:37, 13 November 2019 (UTC)

Filter cleanup[edit]

Can an EFM please take a look at the following enabled filters?

Filters to clean up[edit]

Use deprecated variables, and should be updated:

 Done

Use a regex where they should use equals_to_any():

 Done

Other miscellaneous issues:

Discussion[edit]

Thanks, --DannyS712 (talk) 06:26, 12 November 2019 (UTC)

The latter list has been done, and I'm currently working through the first list. I've always thought deprecated variables are a good sign, and excuse, for the filter to get a proper review, so I'm trying to do that. Speaking of which can I get an opinion on lines 7-8 of filter 117? -- zzuuzz (talk) 10:30, 12 November 2019 (UTC)
That's all done except filter 117. It looks to me like there might be too many double negatives on lines 7 and 8, but it's making my head hurt. Thoughts or testing anyone? -- zzuuzz (talk) 19:04, 12 November 2019 (UTC)
@Zzuuzz: That is confusing. Let's see, right now it's saying that:
  • (NOT (added_lines rlike stringy AND NOT (added_lines contains '#redirect')))
which means
  • ((NOT added_lines rlike stringy) OR (added_lines contains '#redirect'))
So was the original intention to flag redirects, or skip redirects? Go ahead. Say "yes". Using <plug type="shameless">User:Suffusion of Yellow/batchtest-plus.js</plug>, I can only find one recent example containing "#redirect", Special:AbuseLog/25145575, and that was a random test edit, so I guess it's not very common for non-confirmed editors to redirect very very short BLPs? Suffusion of Yellow (talk) 20:00, 12 November 2019 (UTC)
Having stared at the filter for a long time, too long really, I've reached the conclusion that at least it's not doing any harm. So I'll leave it there for others to wonder about at a later date. -- zzuuzz (talk) 20:08, 13 November 2019 (UTC)
Thanks. I've added a few more things that can be cleaned up - for the private filters, I've just noted the lines that can be improved / cleaned up; hopefully the implied edit is obvious, but to avoid sharing private details I didn't want to post it. Thanks, --DannyS712 (talk) 11:07, 12 November 2019 (UTC)
Regarding filter 942, I'd agree that editing a protected page is less likely than being a sysop and so should go first. But on that topic I'd be interested to hear from Xaosflux: Isn't a check for the sysop user_group redundant to those other checks? -- zzuuzz (talk) 12:52, 12 November 2019 (UTC)
@Zzuuzz: It took me a while to track it down, because I couldn't remember where I came across it, but the answer is that the check is still useful: see m:Stewards' noticeboard/Archives/2019-08#Notice of mistaken edit - it shouldn't add much to the checks, given how rarely that condition would be reached, and would help prevent false positives like the one linked above --DannyS712 (talk) 13:40, 12 November 2019 (UTC)
942 so not exactly redundant, this was birthed from the continuing discussions regarding possible admin activity standards changes, and a way to gather the metrics. At once point I though the group check was "cheaper" then the other one as far as the ordering goes - if it is faster in another order that part isn't important to the goal. — xaosflux Talk 13:57, 12 November 2019 (UTC)
That's fine, I can see the point of the filter. I was just wondering about testing for being a sysop and editing a protected page, but DannyS712's cleared that up - though in the context of this filter I still think the group check might be redundant, I'm happy to leave it there (but will re-order the conditions). -- zzuuzz (talk) 14:19, 12 November 2019 (UTC)
So, is misuse of global rights to edit protected pages not suspicious enough to warrant an edit filter hit? * Pppery * it has begun... 22:37, 13 November 2019 (UTC)
Honestly? I don't think logging such a thing, alongside thousands of sysop edits, would serve any useful purpose. -- zzuuzz (talk) 22:46, 13 November 2019 (UTC)
Added 2 more (ping @Cyberpower678 for 915) Thanks, --DannyS712 (talk) 01:38, 13 November 2019 (UTC)
DannyS712, The filter looks fine to me. It would help to know what needs cleaning up. —CYBERPOWER (Chat) 14:15, 16 November 2019 (UTC)
@Cyberpower678: Since the filter is private, I didn't want to give anything away here. I've emailed you. Thanks, --DannyS712 (talk) 01:33, 17 November 2019 (UTC)
DannyS712, tesponded —CYBERPOWER (Around) 02:00, 17 November 2019 (UTC)

New editor suspicious activity on bot[edit]

Special:AbuseFilter/806

Hello all, I'm seeing that InceptionBot (talk · contribs · tasks · flag log · actions log · block log · other logs · count) has been tripping the "new account suspicious activity" filter for the few hours or so. It does not look this is a new bot as well according to Wikipedia:Bots/Requests for approval/InceptionBot. Would it be possible for an EFM to look into this? Also pinging the bot operator Bamyers99. -- LuK3 (Talk) 19:49, 13 November 2019 (UTC)

@LuK3: Seems like a bug in the AbuseFilter extension. The extendedconfirmed user right (which is held by EC users, bots, and sysops) isn't being exposed to the filter. Fixed 806 (hist · log), but some others will need fixing, too. @Xaosflux: You mentioned something similar in the notes for 867 (hist · log). Know what's going on here? Suffusion of Yellow (talk) 20:09, 13 November 2019 (UTC)
Couldn't this be solved by giving bots the extended confirmed right explicitly along with the bot flag? ‑‑Trialpears (talk) 20:13, 13 November 2019 (UTC)
@Trialpears: No, I just found an example of an actual extendedconfirmed user who does NOT have extendedconfirmed rights, according to the filter log (Special:AbuseFilter/examine/log/25328598, private, but someone may wish to dig up a public example.) Suffusion of Yellow (talk) 20:19, 13 November 2019 (UTC)
@Suffusion of Yellow: If you use the testing interface with contains_any(user_rights, "bot", "extendedconfirmed"), it does indeed detect things.... DannyS712 (talk) 20:14, 13 November 2019 (UTC)
@DannyS712: Are you using Special:AbuseFilter/test, or examining an actual saved log entry? /test sometimes only has a tenuous connection with what the filter actually sees. Suffusion of Yellow (talk) 20:19, 13 November 2019 (UTC)
@DannyS712: looking at this examine result - looks like at least on that hit a LOT of 'user_rights' are not being evaluated. — xaosflux Talk 20:21, 13 November 2019 (UTC)
@Suffusion of Yellow: Special:AbuseLog/25329506 accurately detected extended confirmed; Xaosflux - has anyone filed a phab task yet? DannyS712 (talk) 20:23, 13 November 2019 (UTC)
@LuK3 and Suffusion of Yellow: that bot hadn't been flagged when those were tripping, it has now been flagged so should no longer be causing the trouble, please let us know if you see more issues. — xaosflux Talk 20:13, 13 November 2019 (UTC)
Scratch that, reviewing more. — xaosflux Talk 20:14, 13 November 2019 (UTC)
"extendedconfirmed" in user_groups &!
"extendedconfirmed" in user_rights
  • to log these? The test interface doesn't show any hits, but at run time the filter may act different DannyS712 (talk) 20:28, 13 November 2019 (UTC)
I've made sure the changes I recently made are undone (documented in the section above). But this isn't the full picture: this search shows the current use of user_rights. I seem to recall this coming up before. -- zzuuzz (talk) 20:40, 13 November 2019 (UTC)
Special:AbuseFilter/history/806/diff/prev/22612 is the change that caused this. I think this is working as intended. Edits made where authentication is done with BotPasswords or OAuth limit the set of rights available to the user in that session. — JJMC89(T·C) 22:21, 13 November 2019 (UTC)
@JJMC89: thank you for the update - so using 'groups' instead of 'rights' should be fine here. — xaosflux Talk 22:36, 13 November 2019 (UTC)
@Xaosflux: I don't know if one is "cheaper" to use than the other, but we need to test groups instead of rights here. In in most cases (if API edits will be tested, which most of the time they would) where the right is not in the basic grant, we need to test groups. — JJMC89(T·C) 22:56, 13 November 2019 (UTC)

Set filter 1011 to disallow?[edit]

@Zzuuzz: User is active right now, as you know. Ideally it should be tested more, but no FPs in almost a day. Suffusion of Yellow (talk) 00:37, 14 November 2019 (UTC)

Good for short-term issues, but maybe a bit too soon for general use? Or a bit strict? I can see this potentially tripping FPs a fair bit. -- zzuuzz (talk) 22:14, 14 November 2019 (UTC)
@Zzuuzz: Yes, there was one "false" positive, from a different, but still disruptive (maybe good faith CIR) user, here today. I expect it will have similar problems as disabled filter 931 (hist · log). If I set this to disallow, I will check the log a few times a day for FPs. I will also turn it back to log-only if the targeted user goes away. Maybe best to give it another day or two, though. In the meantime I think I'll add it to DatBot's list. Suffusion of Yellow (talk) 22:51, 14 November 2019 (UTC)
Still no FPs, except the pseudo-FP mentioned above (IP is now globally rangeblocked as an "infected network" FWIW). I've set it to disallow for now, but anyone may feel free return to log-only. I have a few ideas to reduce FPs, and will implement if needed. Suffusion of Yellow (talk) 02:58, 16 November 2019 (UTC)

Request for edit filter helper[edit]

The event has started. (refresh)
InvalidOS (t · c · del · cross-wiki · SUL · edit counter · pages created (xtools • sigma· non-automated edits · BLP edits · logs (block • rights • moves) · rfar · spi) (assign permissions)(acc · ap · fm · mms · npr · pm · pcr · rb · te)

Since I mostly work on reverting vandalism, where edit filters are helpful, I would like to be able to help out with tasks involving edit filters. InvalidOS (talk) 17:36, 14 November 2019 (UTC)

There is a standard 3 day hold on these requests for commentary. — xaosflux Talk 18:10, 14 November 2019 (UTC)
  • The general requirement documented at WP:EFH is a "demonstrated need for access". I'm not really convinced that reverting vandalism demonstrates such a need. It is quite possible (and welcome) to help with edit filter tasks without needing the ability to view private filters. -- zzuuzz (talk) 22:11, 14 November 2019 (UTC)
  • I'm not willing to support this right now, though I look forward to doing so in the future. I'd like to see more involvement with public filters first. There's nothing wrong with anything you've done so far; I just haven't seen enough of it, yet. Suffusion of Yellow (talk) 22:42, 16 November 2019 (UTC)

Traps and pitfalls[edit]

There are several threads on this page that could have been prevented by better documentation. I've started a list of some common mistakes. It still needs copyediting, but any suggested additions? I'd like to keep it short enough that people will actually read it, but it's not too long right now. Suffusion of Yellow (talk) 22:17, 14 November 2019 (UTC)

@Suffusion of Yellow: any good examples of a filter that end up actually matching everything that should never be used? — xaosflux Talk 04:54, 15 November 2019 (UTC)
Here's a few expressions that would match everything (or almost everything), despite possibly not seeming like they would:
  • ".*$" and "^.*"
  • "[A-Za-z0-9_]*"
  • "(/* expression */)[/1]|[^/1]"
I don't see why one would ever use these, though. InvalidOS (talk) 13:27, 15 November 2019 (UTC)
I meant examples of a past filter that actually was created, something along a P OR (NOT P) type scenario, maybe with usergroups (there may be none). — xaosflux Talk 14:20, 15 November 2019 (UTC)
Ah, ok. InvalidOS (talk) 15:01, 15 November 2019 (UTC)
Went through the Village stocks. One example, from 2012, was caused by (new_html rlike "(z-index|height|width)\s*:\s*\d\d"), which matches ~90% of edits. I noticed that /test took a long time checking that; I was worried it would time out. That might explain why something so scary-looking was put in there in the first place without proper testing. I wouldn't call it likely to come up again, though.
Another example, from 2011, was accidentally saving a filter consisting of, roughly, (ip_in_range(user_name, "Pastor of Muppets")). Nowadays that would be a syntax error, plus the real mistake was accidentally saving too early.
I once accidentally saved a filter by hitting "Enter" while in the "Description" field, but luckily I hadn't changed anything anywhere, so it was just a null edit. Anyone else done that? Suffusion of Yellow (talk) 18:21, 15 November 2019 (UTC)
The classic fail is the very very early days of filter 58 (third revision), which was something close to ("foo" | "bar") (the exact version probably wouldn't work today). It de-autoconfirmed 200 users and earned a stern warning from the author of the abusefilter extension. -- zzuuzz (talk) 18:47, 15 November 2019 (UTC)
How did it de-autoconfirm 200 users? InvalidOS (talk) 19:19, 15 November 2019 (UTC)
There's an option to not only disallow an edit but also strip the autoconfirmed rights of anyone tripping it. ‑‑Trialpears (talk) 19:30, 15 November 2019 (UTC)

Set filter 135 (Repeating characters) to disallow?[edit]

I think filter 135 should be set to disallow after reviewing 200 recent edits tagged by the filter. Of these one was a false positive from a user replacing a numbered list using hard codedvalues with # symbols. This false positive could be fixed by allowing repeated # symbols (done by replacing "([^_:.*'|=}{-]{1,9})\1{6}" with "([^_:.*'|=#}{-]{1,9})\1{6}" at line 10). The change was tested using http://regex101.com/ and worked as expected. I don't know what false positive rate is generally desired before disallowing but I feel like this should be sufficient after my proposed change. --Trialpears (talk) 11:11, 14 September 2019 (UTC)

Any thoughts? --Trialpears (talk) 07:07, 27 September 2019 (UTC)
Jo-Jo Eumerus wanna respond to this request as well? If you don't want me to ask you in the future tell me. --Trialpears (talk) 18:55, 1 October 2019 (UTC)
Sorry, but my familiarity with edit filter syntax is very limited. Changing a message is something I can do, the actual syntax not. Jo-Jo Eumerus (talk, contributions) 20:00, 1 October 2019 (UTC)
Bump. ‑‑Trialpears (talk) 08:48, 15 November 2019 (UTC)
@Trialpears: 200 edits, checked manually? I don't have that level of patience! But, I went through 500 most recent edits that were actually saved, using an automatic reverted edit detector that I'm working on (so it may have bugs). I only found 13 that were not "cleanly" reverted. Checking those manually, I only found Special:Diff/924861448, Special:Diff/926208443, and Special:Diff/926230932. The first is someone creating an empty ordered list, which relates to the issue you mentioned, the second is a copyvio (song lyric containing "La la la la la" ... in Chinese), and the third is a direct quote of someone writing "Yessssssssss!". So only 1-3 FP out of 500 (assuming we trust the vandalism patrollers, that is), which is actually pretty good. I'd be in favor of setting this to disallow. Suffusion of Yellow (talk) 19:42, 15 November 2019 (UTC)
For over two years that I am aware of this filter; it seems to me to be one of the most accurate filters we have. I don't think I am exaggerating if I say 98% of all edits that it catches are bound to be reverted (and rightly so). I believe empirical data of the reversion must be around that percentage. It's quite overdue for this filter to disallow such edits completely. – Ammarpad (talk) 07:07, 16 November 2019 (UTC)

Disable filter 527?[edit]

I sent something about this to the mailing list, but Galobtter suggested I come here. There's a specific problem (hard to describe without saying too much about a private filter) described here, that makes the log less meaningful than it would seem. In any case, does anyone find it useful? It's had about 1300 hits in last 24 hours! It was also broken for several months until this change, and no one complained. Suffusion of Yellow (talk) 15:59, 17 November 2019 (UTC)

In favor of disabling; that being said, any reason about restricting the mailing list from EFH ? WBGconverse 16:37, 17 November 2019 (UTC)
@Winged Blades of Godric: Not sure, but see Special:AbuseFilter/history/527/diff/prev/22685 for now. Suffusion of Yellow (talk) 18:16, 17 November 2019 (UTC)
@Suffusion of Yellow: Maybe we should have a discussion about allowing EFH DannyS712 (talk) 08:31, 18 November 2019 (UTC)
I'm in favour of disabling. -- zzuuzz (talk) 18:07, 17 November 2019 (UTC)
Do I trigger an edit-filter by looking at an edit-filter page as a non EFH? ——SN54129 18:13, 17 November 2019 (UTC)
@Serial Number 54129: no DannyS712 (talk) 20:18, 17 November 2019 (UTC)

Open mailing list to edit filter helpers?[edit]

@DannyS712 and Winged Blades of Godric: suggested this above. My thoughts are that yes, it would have made perfect sense had the EFH group existed when the mailing list was created, but now, there might be problems with allowing a new user group access to the archives. Anyone who has already sent a message to the list did so in the expectation that any admin or EFM could read the message, but in theory they didn't consent to EFHs reading their emails. That said, I'm not sure that anyone would really care. We have 1150 admins, (most aren't subscribed, but they could), and only 21 EFHs. Maybe run this by WMF legal, just to be safe? Suffusion of Yellow (talk) 18:56, 18 November 2019 (UTC)