Jump to content

Wikipedia:Edit filter noticeboard

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Samwalton9 (talk | contribs) at 00:56, 30 November 2019 (→Open mailing list to edit filter helpers?: done). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

    Welcome to the edit filter noticeboard
    Shortcuts
    Filter 484 (restored) — Actions: disallow; Flags: enabled; Pattern modified
    Last changed at 22:12, 26 November 2024 (UTC)

    Filter 1328 (new) — Actions: none; Flags: enabled,private; Pattern modified

    Last changed at 09:02, 25 November 2024 (UTC)

    Filter 1327 (new) — Actions: showcaptcha; Flags: enabled,private; Pattern modified

    Last changed at 01:02, 25 November 2024 (UTC)

    Filter 614 — Pattern modified

    Last changed at 22:49, 24 November 2024 (UTC)

    Filter 1035 — Pattern modified

    Last changed at 06:54, 24 November 2024 (UTC)

    Filter 945 — Actions: throttle; Flags: disabled

    Last changed at 20:37, 23 November 2024 (UTC)

    Filter 1170 — Pattern modified

    Last changed at 01:00, 23 November 2024 (UTC)

    Filter 1326 (new) — Actions: showcaptcha,throttle; Flags: enabled,private; Pattern modified

    Last changed at 19:30, 22 November 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 331 enabled filters and 48 stale filters with no hits in the past 30 days. Filter condition use is ~1041, out of a maximum of 2000. (Purge). See also the profiling data and edit filter graphs.

    Click here to start a new discussion thread


    Tags cleanup

    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)[reply]

    @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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

    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)[reply]

    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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    @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)[reply]
    Thanks, done. Suffusion of Yellow (talk) 03:48, 9 November 2019 (UTC)[reply]

    Bot idea for EFFP

    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)[reply]

    @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)[reply]
    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)[reply]
    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)[reply]
    Pinging @Suffusion of Yellow and Trialpears for opinions for the archival system. --Majavah (t/c) 19:14, 11 November 2019 (UTC)[reply]
    @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)[reply]
      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)[reply]

    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)[reply]

    @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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    @Majavah: So long as you've checked that you aren't breaking any existing uses of the template, I don't see a problem with any additions. It can always be tweaked later. Suffusion of Yellow (talk) 19:17, 21 November 2019 (UTC)[reply]
    I've merged the changes to the mail template, however I haven't edited the documentation yet (only thing added is archive now). I've also filed the BRFA! --Majavah (t/c) 09:15, 23 November 2019 (UTC)[reply]

    A bug in Special:AbuseFilter/627

    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)[reply]

    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)[reply]

    Urgent

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

    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)[reply]

    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)[reply]
    @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)[reply]
    Yup. A wider group. Guy (help!) 21:58, 9 November 2019 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    New permutations to add: [4], [5] (both suppressed) DannyS712 (talk) 03:37, 13 November 2019 (UTC)[reply]

    Filter cleanup

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

    Filters to clean up

    Use deprecated variables, and should be updated:

     Done

    Use a regex where they should use equals_to_any():

    Other miscellaneous issues:

    Discussion

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

    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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    Added 2 more (ping @Cyberpower678 for 915) Thanks, --DannyS712 (talk) 01:38, 13 November 2019 (UTC)[reply]
    DannyS712, The filter looks fine to me. It would help to know what needs cleaning up. —CYBERPOWER (Chat) 14:15, 16 November 2019 (UTC)[reply]
    @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)[reply]
    DannyS712, tesponded —CYBERPOWER (Around) 02:00, 17 November 2019 (UTC)[reply]

    New editor suspicious activity on bot

    Tracked in Phabricator
    Task T238270
    Invalid
    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)[reply]

    @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)[reply]
    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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    Scratch that, reviewing more. — xaosflux Talk 20:14, 13 November 2019 (UTC)[reply]
    "extendedconfirmed" in user_groups &!
"extendedconfirmed" in user_rights
    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)[reply]
    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)[reply]
    @JJMC89: thank you for the update - so using 'groups' instead of 'rights' should be fine here. — xaosflux Talk 22:36, 13 November 2019 (UTC)[reply]
    @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)[reply]

    Set filter 1011 to disallow?

    @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)[reply]

    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)[reply]
    @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)[reply]
    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)[reply]

    Request for edit filter helper (User:InvalidOS)

     Not done this request failed to gain support. — xaosflux Talk 19:07, 25 November 2019 (UTC)[reply]

    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.

    The event has started. (refresh)
    InvalidOS (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)

    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)[reply]

    There is a standard 3 day hold on these requests for commentary. — xaosflux Talk 18:10, 14 November 2019 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]
    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.

    Traps and pitfalls

    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)[reply]

    @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)[reply]
    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)[reply]
    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)[reply]
    Ah, ok. InvalidOS (talk) 15:01, 15 November 2019 (UTC)[reply]
    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)[reply]
    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)[reply]
    How did it de-autoconfirm 200 users? InvalidOS (talk) 19:19, 15 November 2019 (UTC)[reply]
    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)[reply]

    Set filter 135 (Repeating characters) to disallow?

    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 https://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)[reply]

    Any thoughts? --Trialpears (talk) 07:07, 27 September 2019 (UTC)[reply]
    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)[reply]
    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)[reply]
    Bump. ‑‑Trialpears (talk) 08:48, 15 November 2019 (UTC)[reply]
    @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)[reply]
    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)[reply]
    I remember going through many hits of this filter a while back and not seeing many FPs. Definitely a strong candidate for disallowing; if no one gets to it before I do, I'll set it to disallow and fix the repeated # issue when I have a bit more time. Galobtter (pingó mió) 22:29, 21 November 2019 (UTC)[reply]

    Disable filter 527?

    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)[reply]

    In favor of disabling; that being said, any reason about restricting the mailing list from EFH ? ∯WBGconverse 16:37, 17 November 2019 (UTC)[reply]
    @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)[reply]
    @Suffusion of Yellow: Maybe we should have a discussion about allowing EFH DannyS712 (talk) 08:31, 18 November 2019 (UTC)[reply]
    I'm in favour of disabling. -- zzuuzz (talk) 18:07, 17 November 2019 (UTC)[reply]
    Do I trigger an edit-filter by looking at an edit-filter page as a non EFH? ——SN54129 18:13, 17 November 2019 (UTC)[reply]
    @Serial Number 54129: no DannyS712 (talk) 20:18, 17 November 2019 (UTC)[reply]

    Open mailing list to edit filter helpers?

    @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)[reply]

    There's no legally private data being shared, just things we as EFMs consider private. I think the mailing itself is the best place to make your proposal, and if after some time there are no objections, we can open it up to EFHs. I don't expect any opposition. — MusikAnimal talk 20:52, 21 November 2019 (UTC)[reply]
    I don't see any issue with anyone who can see private filters being allowed access to the list. Galobtter (pingó mió) 21:16, 21 November 2019 (UTC)[reply]
    @Galobtter and MusikAnimal: Access to the list also gives you the email address of everyone (including non-subscribers) who has ever sent an email to the list. Suffusion of Yellow (talk) 21:19, 21 November 2019 (UTC)[reply]
    Took a quick look at this and we similarly don't see anything legally private there. If people are concerned that EFH's might be getting access to something they weren't before, there's no obligation to let them onto list. But if everyone thinks it makes sense for them to be added, there's no legal barrier to it. -Jrogers (WMF) (talk) 21:24, 21 November 2019 (UTC)[reply]
    Thanks for looking in to it! I sent a short email to the list, with a link back to this thread. Suffusion of Yellow (talk) 21:42, 21 November 2019 (UTC)[reply]
    Fine by me - the primary security concern was about the contents of private filters, which EFHs have access to. Sam Walton (talk) 09:35, 22 November 2019 (UTC)[reply]
    If some other legal barrier comes up, a separate mailing list could be created for EFHs. I don't think it's likely that there would be another legal barrier, though. InvalidOS (talk) 14:52, 22 November 2019 (UTC)[reply]
    I was actually first added to the list when I was EFH, so it wasn't a problem then. Best, Kevin (aka L235 · t · c) 05:16, 23 November 2019 (UTC)[reply]
    Since this seems uncontroversial I've gone ahead and added this to the guideline. Sam Walton (talk) 00:56, 30 November 2019 (UTC)[reply]

    Edit Filter Helper request (User:Creffett)

    Earliest closure has started. (refresh)
    Creffett (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)

    (this request is for adding the permission to User:Creffett, but I'm not on my personal machine right now so it's being posted under the creffpublic sock)

    Hi all, I'd like to request the edit filter helper bit. I've helping off-and-on for a while on the false positive and requests boards, so I'm hoping people at least feel like they've heard my name before. The main reason I'm requesting the bit is that a large portion of my work on Wikipedia is catching promotional/COI edits and spam, and the most of the filters in that area are private. I'd like to be able to see and suggest changes to the relevant filters (particularly 354, 499, and 627) in order to improve their catch rate. I'm reasonably handy with regular expressions (as mentioned on my userpage, my day job is software engineering) and I meet all of the other criteria for EFH (extended confirmed, native English speaker, no blocks/sanctions, and solid understanding of security practices). creffpublic a creffett franchise (talk to the boss) 19:37, 22 November 2019 (UTC)[reply]

    • My usual concern, to wit: While EFFP participation is always appreciated, I don't see that typically rising to the level of Demonstrated Need that was expected when the EFH role was being vetted, along with the highly-established user expectation; you've not been here 9 months despite your extremely impressive level of editing. This is not opposition per se, just expressing concerns based around what was generally agreed during the RFC for the EFH bit. CrowCaw 18:05, 25 November 2019 (UTC)[reply]
      Crow, all reasonable points, and I can't disagree with them. The only thing I will say is that since most of the filters that tip me are private, it's pretty hard to call out false positives (and I suspect that the response to many of them will be "there was a phrase in there that shows up in a lot of spam pages and it's effective enough that it's not worth changing). If I had the bit, that's the main place where I expect to use it (well, that and suggesting additions). If that doesn't meet the "demonstrated need" threshold, then that's that. creffpublic a creffett franchise (talk to the boss) 18:48, 25 November 2019 (UTC)[reply]
    • Weak support. On the one hand, there hasn't been a huge level of participation at the relevant EF-related pages. On the other, said participation has been quite clueful, and I don't pick up a hat-collecting vibe. I think Wikipedia will have less spam, if creffett has access to anti-spam filters and /test. My main concern relates to Crow's: Are we setting a precedent that leads to 500 EFHs at some point in the future? Suffusion of Yellow (talk) 17:53, 27 November 2019 (UTC)[reply]
      Suffusion of Yellow, just out of curiosity what is the underlying concern about having too many EFHs? Is it that some EFH will conspire with sock puppets to bypass filters targeting them or grave incompetence where a private filter is posted publicly? If that's the case I wouldn't have any concern about granting it to many experienced non-admins in good standing even if their need isn't particularly pressing. ‑‑Trialpears (talk) 18:22, 27 November 2019 (UTC)[reply]
      @Trialpears: No one has perfect account security. There's probably a weak point in any group of 500 users, even responsible users. If you're gong to say "but we already have 1000 admins" I urge you to check out the history of the main page, or my block log. Suffusion of Yellow (talk) 18:28, 27 November 2019 (UTC)[reply]
      Suffusion of Yellow, yep that's it of course. I'm still wondering if putting a 2FA condition on weaker applicants and a quick removal time for users not actively doing edit filter related activities could make this bit significantly less high risk, but I guess we don't really have a lack of EFHs either so there's no pressing need. ‑‑Trialpears (talk) 18:41, 27 November 2019 (UTC)[reply]
      For what it's worth, I've requested the 2fa right (the security person in me is very curious why that has to be specifically requested, but that's neither here nor there). One suggestion - if your concern is "bad people" (spammers, LTAs, etc.) getting access, then you might want to talk to the New Page Patrol project - they've had a couple issues lately with deep-cover paid editors/spammers getting the right and abusing it, so there might be some value in a joint discussion about how to protect these abuseable advanced rights. creffett (talk) 22:38, 27 November 2019 (UTC)[reply]
      The more I think about the issue the higher risk I think this user right is. Only one bad or compromised actor could permanently reveal the contents of all private filters in a minute. Pherhaps some larger discussion would be beneficial but first of all I think the easier options should be implemented, in particular giving edit filter helpers 2FA access and moving the power to grant EFH and EFM to the crats reducing the amount of accounts that could be compromised by a factor of five. Having some more stringent activity requirements similar to how admins can request their bit back without a RfA, could probably reduce it a lot further as well. That being said adding a few more active EFHs in good standing, especially with solid security practices like you, wouldn't do much to increase the risk so I would be all for you being granted at least a trial. ‑‑Trialpears (talk) 23:25, 27 November 2019 (UTC)[reply]
      @Creffett: 2fa is in a limited trial because there is not a good support system in place for anyone who runs in to problems with it. — xaosflux Talk 23:47, 27 November 2019 (UTC)[reply]
      Xaosflux, good to know, thanks. creffett (talk) 23:57, 27 November 2019 (UTC)[reply]
    Note on EFM/EFH's - occasionally we need a filter for something that will also end up getting oversighted, in between the filter hit and the log suppression there is a window for disclosure - so EFH's need a level of general community secrecy trust. — xaosflux Talk 19:26, 27 November 2019 (UTC)[reply]

    "Poop" vandalism

    Why isn't this [6] picked up by filter 46. ~~ CAPTAIN MEDUSAtalk 17:28, 26 November 2019 (UTC)[reply]

    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter_noticeboard&oldid=928548878"