From Wikipedia, the free encyclopedia
    Welcome to the edit filter noticeboard
    Filter 1289 — Flags: disabled
    Last changed at 12:27, 22 April 2024 (UTC)

    Filter 1076 — Pattern modified

    Last changed at 04:19, 22 April 2024 (UTC)

    Filter 1248 — Pattern modified

    Last changed at 03:48, 22 April 2024 (UTC)

    Filter 614 — Pattern modified

    Last changed at 01:29, 21 April 2024 (UTC)

    Filter 892 — Pattern modified

    Last changed at 21:06, 20 April 2024 (UTC)

    Filter 1013 — Actions: throttle

    Last changed at 00:42, 20 April 2024 (UTC)

    Filter 1201 — Pattern modified

    Last changed at 18:12, 19 April 2024 (UTC)

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

    Last changed at 01:55, 19 April 2024 (UTC)

    Filter 1297 (new) — Actions: tag,warn; Flags: enabled,public; Pattern modified

    Last changed at 21:25, 18 April 2024 (UTC)

    Filter 1302 (new) — Actions: none; Flags: enabled; Pattern modified

    Last changed at 09:33, 18 April 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.



    Filter 1301

    Filter 1301 ( hist · log) has been recently created by an admin to prevent users from editing other users' committed identity templates on user pages, but I noticed some possible issues:

    1. The !"sysop" in global_user_groups condition should either be changed to !("steward" in global_user_groups) or removed; the former global group doesn't actually exist at all.
    2. The generic disallow message should either be changed or removed, since it can be bitey to newer users and irritating to experienced users.

    Any opinions or suggestions? Thank you. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 02:08, 12 April 2024 (UTC) reply

    cc Daniel QuinlanNovem Linguae ( talk) 02:40, 12 April 2024 (UTC) reply
    Was this in response to some specific incident? I don't see the need for a filter here; the only people verifying committed identities should be WP:T&S, and I'd hope they check the page history to see who added the template. Suffusion of Yellow ( talk) 03:38, 12 April 2024 (UTC) reply
    I added it in response to this page protection request. I also hope T&S runs WikiBlame (or something similar) to find the edit that added an identity when handling requests as well, but "hope" isn't exactly a description of defense in depth. Daniel Quinlan ( talk) 03:53, 12 April 2024 (UTC) reply
    Filters aren't really security measures. A truly determined person could find a way around any of them. (I will email you one trick if you're curious.) Now that would be very difficult, but we're talking someone capable of conducting a social engineering attack against the T&S team of a ton-ten website. We're not talking about a drive-by vandal. What is a security measure is the protection against editing .js and .css pages; if Aditya-an11 doesn't want anyone editing their committed identity or GPG key, they can wrap it in /* ... */ and put it at something like User:Aditya-an11/key.js. There are also several BEANSy ways in which this filter could be exploited by vandals. Again, I'll email you if you're curious. Suffusion of Yellow ( talk) 04:19, 12 April 2024 (UTC) reply
    I don't think they have email enabled, so they'll have to email you instead. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 04:25, 12 April 2024 (UTC) reply
    I already have his email, and just sent one. But I said "One weird trick" in the subject, so it probably got spam-filtered... Suffusion of Yellow ( talk) 04:41, 12 April 2024 (UTC) reply
    @ Suffusion of Yellow, I haven't received your mail. I am quite unsure on how I didn't got the mail - I have enabled email in my preferences. Could it be that I am a new user?
    Anyways, as I have mailed you -- as directed by @ Codename Noreste. Aditya-an11 ( talk) 07:28, 12 April 2024 (UTC) reply
    @ Aditya-an11 pretty sure Suffusion was talking about emailing Daniel Quinlan, not you. – 143.208.238.195 ( talk) 08:20, 12 April 2024 (UTC) reply
    Sorry, my bad. I have crossed it out Aditya-an11 ( talk) 08:58, 12 April 2024 (UTC) reply
    @ Aditya-an11: Responding to your email, there isn't much you can do to protect against someone who has access to your account from modifying the page. Full protection won't really work; if the attacker says "Hey, I need to update my key, can you unprotect the page for bit" it's highly unlikely any admin would argue. You'll just have to trust that whoever is verifying your identity is clueful enough to check timestamps. Suffusion of Yellow ( talk) 18:20, 12 April 2024 (UTC) reply
    And I just realized that if the account is compromised, the attacker "is" the victim as far as MediaWiki knows, and will of course bypass the filter. If you plan on using anything in your userspace to prove your identity after a compromise, you'd better, again, hope, that someone goes looking for the oldest edit. Suffusion of Yellow ( talk) 04:45, 12 April 2024 (UTC) reply
    But the only things I have are that I have my committed identity listed on my local and global user pages (I've recently updated it minutes ago), and my account has a very strong password and has 2FA enabled globally.
    Only my alternate account has a very strong password but can only be used in an emergency or in unsecure areas where I can't access my main. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 04:52, 12 April 2024 (UTC) reply
    The point is that if someone gains your password and 2FA secret, and then they change your committed identity, this will be recorded as an edit coming from you. The only thing that will be sus is the fact that "you" changed "your" identity recently. If T&S has to distinguish between two people both claiming to be you (if only Brian had known about cryptographic hashes...), it's the oldest hash that they'd have to look at. Suffusion of Yellow ( talk) 05:06, 12 April 2024 (UTC) reply
    If the user has additional permissions, Wikipedia is definitely impacted. I'll respond to your email tomorrow or this weekend. Thanks for the additional context. Daniel Quinlan ( talk) 05:38, 12 April 2024 (UTC) reply
    This is a big drawback that I think this filter has. Not to mention that @ Suffusion of Yellow believes that these filters could be exploited by vandals. And this is concerning to me....
    Sure, the filter seems to provide basic protection, but I feel this fails when my account gets breached OR the person who is vandalising have apt technical knowledge to exploit it. Going by the case of Wikipedia:Wikipedia Signpost/2007-05-14/Committed identity, both the situation are probably.
    These security concerns was partly what prompted me to ask for full page protection in the first place. "Full" as in even if a vandal gets access to my account, they can't edit the my committed-identity page. Only the admins can. And that's way more reassuring and secure than the filter. While I do understand this may not be common, I do see people page protecting their committed identity pages (like Gwern to which I cited here). Though, in all fairness, I am a new user and could be wrong. I would be happy if get any guidance on how to maturely approach this issue. Aditya-an11 ( talk) 07:49, 12 April 2024 (UTC) reply
    Thanks, steward is the appropriate group, I'll update the filter. As far as the message goes, this filter should almost never match, but I'm open to suggestions. Also, if the default disallow message is considered bitey for reasons (beyond it being non-specific), we should discuss making it less bitey under a new topic. Daniel Quinlan ( talk) 04:02, 12 April 2024 (UTC) reply
    Correct me if I'm wrong, but the filter also prevents any editing of any user page containing the template, which is likely to create its own problems (maybe SoY has already pointed this out by email). I took a look at the RFPP request and would say that of course protection can be used for 'important' subpages. I've had my own PGP sub-page semi-protected since I became an admin, and I'm sure I've even fully protected others' key pages, if that's what they asked for (semi is usually enough though, IMO). As SoY points out, timestamps are everything when it comes to key verification. -- zzuuzz (talk) 07:39, 12 April 2024 (UTC) reply
    Honestly, I'd recommend making that filter private right now even if it didn't change from what it currently is(or it's ultimately disabled), if there's any worry of people trying to bypass it - isn't that the main reason filters are privated? @ Zzuuzz, it's not every edit, though it is every user page yes. – 143.208.238.195 ( talk) 07:54, 12 April 2024 (UTC) reply
    Yes, you're right. What would be prohibited is something like courtesy blanking, replacing a user page with a sock tag or a banned notice (or reverting such), along with removing bad content placed by the user near the template. I'm still sceptical about the filter, or anyone relying on it, so will let someone else make that judgement about its visibility. -- zzuuzz (talk) 08:23, 12 April 2024 (UTC) reply
    At this point, since you pretty much said it as an example, I might as well say it, the filter, as a side effect, gives all users the capability of fully protecting specific lines of their choice from non-admin users - this is not something which should be given lightly or even automatically unless it's really good automation (not the case with the way the filter currently is) because ill intentioned users exist. – 143.208.238.195 ( talk) 08:43, 12 April 2024 (UTC) reply
    Yeah, that's what I had in mind, e.g. {{ committed identity|Zzuuzz is a total ...}} Yeah, we could tweak the regex so that they can only talk about how much DEADBEEF 15 A B00BFACE FBDB, but is it worth the trouble? I've already though up about four ways to bypass this filter (again, emailed DQ, some of them are sort of relevant to other filters). Suffusion of Yellow ( talk) 18:03, 12 April 2024 (UTC) reply
    Bbb23, who is a much more frequent target for vandals, would not be exempt from that either. 0x Deadbeef→∞ ( talk to me) 15:21, 13 April 2024 (UTC) reply
    I've disabled the filter and set it to private for now. I think it might be better to integrate it into a more generalized (and probably private) filter for user page vandalism and shenanigans, one that flags edits rather than disallowing them. I'd also like to better address some weaknesses in the implementation (that was always the plan).
    One option we might want to consider is designating a specific location (or locations) for committed identity information, PGP keys, etc. and protecting it similarly to .css and .js files. I think the concerns about the filter allowing users to "protect" specific lines are somewhat overblown as this is already possible with personal .css, .js, and .json pages and this hasn't been a major issue. Daniel Quinlan ( talk) 19:43, 12 April 2024 (UTC) reply

    [URGENT] Education Program needs to be exempted from filters

    See this filter log, and this is something that I've seen before. Members or coordinators of the education program getting caught up in filters is probably one of the worst possible false positives and should be addressed immediately. Taking Out The Trash ( talk) 17:38, 13 April 2024 (UTC) reply

    Courtesy ping to Ohnoitsjamie as the last editor of the miscellaneous article/draft/talk LTA filter. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 18:14, 13 April 2024 (UTC) reply
     Fixed by Ohnoitsjamie. Nobody ( talk) 20:06, 13 April 2024 (UTC) reply
    Thanks, Nobody; I fixed it, then was unable to figure out where this ping originally came from. OhNoitsJamie Talk 20:11, 13 April 2024 (UTC) reply

    Set filter 1294 to disallow

    • 1294 ( hist · log) ("Test edits and low effort vandalism", public)

    Standard notification. Split out of 260 ( hist · log), 384 ( hist · log), and 614 ( hist · log), with a handful of additions. No FPs in the few dozen "new" matches. I'm not going to add this to Template:DatBot filters. In fact, that was part of the reason for the split. I doubt that users adding "lol" and "fdshksdjfhskdjdshfflshjfsldkhfdslkhsfd" are really going to put in the effort to work around the filters, so let's have a bit less clutter at WP:AIV/TB2. Suffusion of Yellow ( talk) 00:36, 14 April 2024 (UTC) reply

    Understood. This filter is targeted towards your run-of-the-mill everyday vandal who doesn't use much effort to bypass this filter and/or trigger 1296 and/or 1297 instead.
    Also, this might be different from 664 ( hist · log). Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 00:50, 14 April 2024 (UTC) reply
    664 is warn-only, though I haven't looked through the log to see if it can be set to disallow. 1296/1297 is an experiment that might go nowhere. 1297 is not going to be easy to maintain and IMO a filter that complicated is only justifiable if keeps out a huge amount of vandalism. Suffusion of Yellow ( talk) 00:59, 14 April 2024 (UTC) reply
    No problems here, seems solid from a glance at the filter. EggRoll97 ( talk) 05:02, 14 April 2024 (UTC) reply

    Need a change for #867

    After noticing this, I suggest excluding undos and reverts from being logged onto the edit filter log by #867. Toadette ( Let's talk together!) 14:47, 14 April 2024 (UTC) reply

     Fixed. EggRoll97 ( talk) 17:56, 14 April 2024 (UTC) reply
    Not sure if that's a good idea. After an AFD was closed as "redirect", it's common that someone will come back much later and try to undo the result. I see no harm in logging that. Suffusion of Yellow ( talk) 18:47, 14 April 2024 (UTC) reply
    Self-reverted for now, though anti-vandalism isn't exactly the scope of this filter. For example, Special:Diff/1218898491 isn't a large page creation, it's reverting redirect vandalism. EggRoll97 ( talk) 20:52, 14 April 2024 (UTC) reply
    Sure but there's no harm in a log-only filter catching a few out-of-scope edits. If I understand this change correctly, around next WP:THURSDAY you'll be able to write something like page_last_edit_age >= 86400 to exclude reverts of recent edits. But even that would exclude rapid edit warring to overturn an AFD. Suffusion of Yellow ( talk) 20:59, 14 April 2024 (UTC) reply

    Prepare for Armageddon: temporary accounts

    (Topic name is a reference to one of my favorite error messages.)

    The 15 April The Tech News weekly summary includes this blurb:

    Volunteer developers are kindly asked to update the code of their tools and features to handle temporary accounts. Learn more

    Of course, it's not just code that will need to be updated. A good number of edit filters are going to need to be updated. I don't think we necessarily want or need to update anything before it happens, but I'd suggest enumerating the variables and functions most likely to be affected and start building a list of filters expected to require updates.

    (This may have been discussed before, but I didn't immediately find anything in the archive.) Daniel Quinlan ( talk) 23:57, 15 April 2024 (UTC) reply

    If we don't have anything to feed to ip_in_range(), that will be bad, and some filters will have to just be disabled. But otherwise, so long as temp accounts are never autoconfirmed, and have an edit count and age that stays at zero or null, I don't think a huge number of filters will need updating. If user_age and user_editcount start incrementing, then we might want to check user_type in some filters. I'd prefer to see how temp-account users act first. Will the vandals clear cookies after every edit? Or will most of them be too clueless? No way to know right now. Suffusion of Yellow ( talk) 01:04, 16 April 2024 (UTC) reply
    I'm hoping that the IP variables are unaffected, but I haven't dug into that. I was most concerned about user_age which is definitely used as an IP test. Daniel Quinlan ( talk) 01:47, 16 April 2024 (UTC) reply
    One thing we might have to consider is this: If people start crying "We're being flooded with vandalism! We need to require registration for everyone!" an alternative might be making the filters much harsher for temp users. As in, you add "gay" to a BLP, in any context, and you're told "you have to register an account to do that". You edit more than three pages in ten minutes: "sorry, either wait ten minutes or register an account". And so on. I hope it doesn't come to that, but disabling all logged out editing would be a greater loss, I think. Suffusion of Yellow ( talk) 02:31, 16 April 2024 (UTC) reply
    Yeah I agree with you as we have a lot of productive IP users. I think that once this gets implemented, using !("confirmed" in user_groups) (as long as the temp accounts can't become confirmed or get other user permissions but that should happen anyways) would work quite well to prevent new users and the new temp account issues. – PharyngealImplosive7 (talk) 02:39, 16 April 2024 (UTC) reply
    It looks like the new user_type variable will probably work well for most simple filters.
    We also need to understand how this affects filters that use the IP in throttling actions.
    It might also be a good time to consider whether there are any additional variables or functions that could help alleviate any losses in functionality. There are "hacks" such as trying to detect reverts by looking at the edit summary. That example might not be something that wants to be fixed sooner because of temporary accounts, but are there other hacks that might be more important to replace with a better solution due to temporary accounts? Daniel Quinlan ( talk) 06:29, 16 April 2024 (UTC) reply
    I think, I hope, that IP masking causing that level of disruption would convince the WMF to roll it back at least locally. Snowmanonahoe ( talk · contribs · typos) 12:45, 22 April 2024 (UTC) reply

    Set filter 1076 to warn

    ("Draftified article more than 180 days old")

    Has some inevitable false positives due to AfDs, but people closing those know what they're doing. Otherwise there are a lot of draftifications of old articles by people who either don't realize how old the page is, don't know they're not supposed to do that, or both, and it would be nice if they could be warned as they do it, not later if someone happens to notice. * Pppery * it has begun... 03:43, 20 April 2024 (UTC) reply

    I agree, so I support warning. Changed to neutral because of the amount of FPs. Also note that if this passes, we'll have to make a new and specialized warning template but I'm sure you already know that... PharyngealImplosive7 (talk) 16:36, 20 April 2024 (UTC) reply
    Also support. EggRoll97 ( talk) 17:56, 20 April 2024 (UTC) reply

    Not opposed to this, but both User:Evad37/MoveToDraft.js or User:MPGuy2824/MoveToDraft.js just say something like this when a filter is tripped:

    Could not move page:
    API error: abusefilter-warning
    
    Try again ?
    

    Also MPGuy's version already gives this warning:

    Draftifying isn't appropriate per WP:DRAFTIFY, since this article is more than 90 days old.

    which is kind of hard to miss. Ideally, these script would be updated to show the parsed warning, though I'm not sure how much of an effect it will have. (Courtesy pings Evad37, MPGuy2824.) Suffusion of Yellow ( talk) 19:45, 20 April 2024 (UTC) reply

    There are also, of course, manual draftifications not using the script, which currently get no warning. * Pppery * it has begun... 21:17, 20 April 2024 (UTC) reply
    Yes, it's probably a fair trade-off even the if the scripts don't display the warning properly. Suffusion of Yellow ( talk) 21:39, 20 April 2024 (UTC) reply

    I'm not sure about this. I've manually analyzed the last 50 filter hits; and while 17 of those were true positives, there were 27 false positives (along with 6 cases in which it wasn't as clear to me). As far as I can see, the majority of the FPs came from round-robin page moves, draftification following WP:AFD/ WP:REFUND, and situations in which the page itself had existed for more than 180 days, but had only recently been moved to mainspace (and were therefore within the time limit for draftification):

    a smart kitten's analysis of recent 1076 ( hist · log) filter hits

    True positives

    1. Special:AbuseLog/37520237
    2. Special:AbuseLog/37517861 - the draftification was of a recently-created article on top of a redirect, so would have been within the time limit for draftification had it been a brand new page. however, given that the page was blanked-and-redirected as a result of an AfD, the page should probably have just been blanked-and-redirected again - rather than moving the page to draftspace, and taking the history of the previous article with it.
    3. Special:AbuseLog/37517848 - same as above
    4. Special:AbuseLog/37515983
    5. Special:AbuseLog/37515631
    6. Special:AbuseLog/37507112 - was originally draftified at an AfD, but was then later accepted through AfC. this draftification took place >180 days after the AfC acceptance
    7. Special:AbuseLog/37506617
    8. Special:AbuseLog/37501991
    9. Special:AbuseLog/37501990
    10. Special:AbuseLog/37501989
    11. Special:AbuseLog/37501988
    12. Special:AbuseLog/37474830
    13. Special:AbuseLog/37465973
    14. Special:AbuseLog/37462419
    15. Special:AbuseLog/37460722
    16. Special:AbuseLog/37442207
    17. Special:AbuseLog/37437883

    False positives

    Manual round-robin page moves

    1. Special:AbuseLog/37526456 - see Special:PageHistory/Mister Peabody
    2. Special:AbuseLog/37526444 - see Special:PageHistory/Una storia importante (song)
    3. Special:AbuseLog/37526437 - see Special:PageHistory/Ucisa
    4. Special:AbuseLog/37510585 - see Special:PageHistory/World egg
    5. Special:AbuseLog/37496701 - see Special:PageHistory/Project 8 (soccer league)
    6. Special:AbuseLog/37475553 - see Special:PageHistory/IT law
    7. Special:AbuseLog/37475530 - see Special:PageHistory/Ballyrory (disambiguation)
    8. Special:AbuseLog/37457511 - see Special:PageHistory/Espresso (Sabrina Carpenter song)
    9. Special:AbuseLog/37452252 - see Special:PageHistory/Conference Finals
    10. Special:AbuseLog/37423355 - see Special:PageHistory/Pentavryso, Kozani

    Draftification from WP:REFUND

    1. Special:AbuseLog/37524078
    2. Special:AbuseLog/37494847
    3. Special:AbuseLog/37475645
    4. Special:AbuseLog/37442191
    5. Special:AbuseLog/37423697

    Draftification from WP:AFD (or similar)

    1. Special:AbuseLog/37500939
    2. Special:AbuseLog/37478431 - was deleted at AfD, & draftified post hoc after a request was made to the closing administrator
    3. Special:AbuseLog/37429525
    4. Special:AbuseLog/37429351
    5. Special:AbuseLog/37419717 - was deleted at AfD in 2017, but draftified at a DRV

    The page itself had existed for >180 days, but had only recently been moved to mainspace

    1. Special:AbuseLog/37517510 - see Special:PageHistory/Draft:Naima G. Sharaf
    2. Special:AbuseLog/37512391 - see Special:PageHistory/Draft:Miriam Grossman
    3. Special:AbuseLog/37439308 - see Special:PageHistory/Draft:Battle of Umbarkhind
    4. Special:AbuseLog/37437754 - see Special:PageHistory/Draft:Radha Krishna Public School, Amroha
    5. Special:AbuseLog/37433258 - see Special:PageHistory/Draft:Jimmy Gardner (labourer)
    6. Special:AbuseLog/37433081 - see Special:PageHistory/Draft:UV Creations
    7. Special:AbuseLog/37423896 - see Special:PageHistory/Draft:St. Rochus Clinic Bad Schönborn

    Less clear/Other potential FPs

    1. Special:AbuseLog/37518209 - all of the substantive content was added to the page by the draftifying editor (see Special:PageHistory/Draft:MPL Philippines Season 11). could probably have been a G7
    2. Special:AbuseLog/37514053 - was draftified by a checkuser due to being a commissioned article, & therefore needing to go through AFC
    3. Special:AbuseLog/37511738 - draftified a newly-created article that was started on top of an older redirect. there was no prior page history besides the redirect, though, so the mainspace redirect was just able to be recreated after the new article was draftified
    4. Special:AbuseLog/37490978 - moved a redirect to draftspace to allow for the title to be taken by an article. should probably (imo) have just been a round-robin or {{ db-move}} situation; but at the same time, it doesn't seem like what this filter was designed to catch
    5. Special:AbuseLog/37488312 - draftified a newly-created article that was started on top of an older redirect from a BLAR in 2021 (see Special:PageHistory/Draft:Samdish Bhatia)
    6. Special:AbuseLog/37455711 - was draftified partially due to possible COI concerns, but the article had existed since 2011

    Although I think a warning for true positives would be beneficial (for the same reason as Pppery), I'm wondering if there are any ways that the rate of FPs can be decreased before this filter is set as such. As things currently stand, I'm leaning oppose, due to the large proportion of warnings that would be given to editors encountering false positives. (Also, Courtesy ping: Bradv as the filter's author.)

    All the best. ‍—‍ a smart kitten[ meow 16:39, 21 April 2024 (UTC) reply

    Maybe we could reduce FPs from recently moved pages like this: moved_from_age > 15552000 & moved_to_last_edit > 604800
    Note that I'm just using 1 week as a placeholder for when the article was last moved so it can be changed to whatever value is best. – PharyngealImplosive7 (talk) 17:03, 21 April 2024 (UTC) reply
    moved_to_last_edit_age seems to be null if the target page doesn't exist; see testwiki:Special:AbuseLog/102036. Suffusion of Yellow ( talk) 19:31, 21 April 2024 (UTC) reply
    Maybe then it could be moved_from_age > 15552000 & (moved_to_last_edit > 604800 || moved_to_last_edit == null) but I'm not too sure about this. – PharyngealImplosive7 (talk) 20:12, 21 April 2024 (UTC) reply
    Ugh, brain fart. Now I get it. You're saying that if the move was recent, the leftover redirect is probably still there in draft space, so we can use its age? Yes, that's a great idea! Though now I'm confused as to why there's a moved_to_last_edit_age variable at all. If the redirect-to-be-overwritten has only one revision, that's just the same as moved_to_age. And if it has more than one revision, the move is just impossible. Suffusion of Yellow ( talk) 04:18, 22 April 2024 (UTC) reply
    This is not convincing to me on principle. because the people doing false positives are experienced users that know what they're doing so will just click through the warning. * Pppery * it has begun... 17:39, 21 April 2024 (UTC) reply
    Thanks for all the digging! The first group of FPs all include a summary that contains either "robin", "swap", or "vacate". I don't know if that's a representative sample, but just excluding those summaries would produce few false negatives, unless someone deliberately uses them to avoid being logged by the filter, in which case they should at minimum receive a stern talking-to. The second group seems to come from one script ( User:SD0001/RFUD-helper) which could be excluded. The others can, I suppose, just click past the warning. Compare 602 ( hist · log), which warns every person leaving a CTOPS notice, appropriate or not. Suffusion of Yellow ( talk) 19:28, 21 April 2024 (UTC) reply
    Paranoia would suggest only excluding edits with the first FP summaries if the requester holds page mover rights, and also creating a separate filter to log any exclusions. * Pppery * it has begun... 20:11, 21 April 2024 (UTC) reply
    Fair point regarding the others just being able to click past the warning - I suppose one of the things I'm concerned about is inadvertently building up banner blindness; though maybe the warning could be worded in such a way that it doesn't state that the editor is definitely trying to improperly draftify a page, just that the edit filter has detected that they might be. I'm in agreement with Pppery regarding only excluding the first set of edit summaries if the editor holds pagemover rights (in a similar way, User:SD0001/RFUD-helper could be set to exclude only if the editor is an admin), and I don't have a strong opinion either way regarding creating a separate filter to log exclusions. Annoyingly, I'm not sure if there's a way to filter out 'page is old but was only recently moved to mainspace' hits.
    As a side-note, I'm wondering if it's worth notifying Wikipedia talk:Draft of this proposal - would anyone have any objections if I did? All the best, ‍—‍ a smart kitten[ meow 09:05, 22 April 2024 (UTC) reply
    I'm disinclined to set anything to warn an experienced editor. The only warnings from the edit filter I receive as an experienced editor are "you're about to place a CTOP" warnings, and those are a pain. They are jarring to my workflow, and they break user scripts. Also a 54% false positive rate is very high. – Novem Linguae ( talk) 10:41, 22 April 2024 (UTC) reply

    Is this worth changing the 'Numeric change without summary' filter?

    Until WP:VPT#I don't understand these edit summaries (task: T360164) is fixed, would it be worth it to change the pattern to match these cases too?
    I'm not really sure how to check how often edits like that are happening and not getting logged by the filter, other than manually looking at Special:RecentChanges (I also don't know what other filter this might be affecting), but I figured I'd point it out and ask anyways. – 143.208.239.226 ( talk) 02:32, 22 April 2024 (UTC) reply

    Thanks, tweaked. Found one example out of the last 1000 mobile app edits. Suffusion of Yellow ( talk) 03:56, 22 April 2024 (UTC) reply
    From Wikipedia, the free encyclopedia
      Welcome to the edit filter noticeboard
      Filter 1289 — Flags: disabled
      Last changed at 12:27, 22 April 2024 (UTC)

      Filter 1076 — Pattern modified

      Last changed at 04:19, 22 April 2024 (UTC)

      Filter 1248 — Pattern modified

      Last changed at 03:48, 22 April 2024 (UTC)

      Filter 614 — Pattern modified

      Last changed at 01:29, 21 April 2024 (UTC)

      Filter 892 — Pattern modified

      Last changed at 21:06, 20 April 2024 (UTC)

      Filter 1013 — Actions: throttle

      Last changed at 00:42, 20 April 2024 (UTC)

      Filter 1201 — Pattern modified

      Last changed at 18:12, 19 April 2024 (UTC)

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

      Last changed at 01:55, 19 April 2024 (UTC)

      Filter 1297 (new) — Actions: tag,warn; Flags: enabled,public; Pattern modified

      Last changed at 21:25, 18 April 2024 (UTC)

      Filter 1302 (new) — Actions: none; Flags: enabled; Pattern modified

      Last changed at 09:33, 18 April 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.



      Filter 1301

      Filter 1301 ( hist · log) has been recently created by an admin to prevent users from editing other users' committed identity templates on user pages, but I noticed some possible issues:

      1. The !"sysop" in global_user_groups condition should either be changed to !("steward" in global_user_groups) or removed; the former global group doesn't actually exist at all.
      2. The generic disallow message should either be changed or removed, since it can be bitey to newer users and irritating to experienced users.

      Any opinions or suggestions? Thank you. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 02:08, 12 April 2024 (UTC) reply

      cc Daniel QuinlanNovem Linguae ( talk) 02:40, 12 April 2024 (UTC) reply
      Was this in response to some specific incident? I don't see the need for a filter here; the only people verifying committed identities should be WP:T&S, and I'd hope they check the page history to see who added the template. Suffusion of Yellow ( talk) 03:38, 12 April 2024 (UTC) reply
      I added it in response to this page protection request. I also hope T&S runs WikiBlame (or something similar) to find the edit that added an identity when handling requests as well, but "hope" isn't exactly a description of defense in depth. Daniel Quinlan ( talk) 03:53, 12 April 2024 (UTC) reply
      Filters aren't really security measures. A truly determined person could find a way around any of them. (I will email you one trick if you're curious.) Now that would be very difficult, but we're talking someone capable of conducting a social engineering attack against the T&S team of a ton-ten website. We're not talking about a drive-by vandal. What is a security measure is the protection against editing .js and .css pages; if Aditya-an11 doesn't want anyone editing their committed identity or GPG key, they can wrap it in /* ... */ and put it at something like User:Aditya-an11/key.js. There are also several BEANSy ways in which this filter could be exploited by vandals. Again, I'll email you if you're curious. Suffusion of Yellow ( talk) 04:19, 12 April 2024 (UTC) reply
      I don't think they have email enabled, so they'll have to email you instead. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 04:25, 12 April 2024 (UTC) reply
      I already have his email, and just sent one. But I said "One weird trick" in the subject, so it probably got spam-filtered... Suffusion of Yellow ( talk) 04:41, 12 April 2024 (UTC) reply
      @ Suffusion of Yellow, I haven't received your mail. I am quite unsure on how I didn't got the mail - I have enabled email in my preferences. Could it be that I am a new user?
      Anyways, as I have mailed you -- as directed by @ Codename Noreste. Aditya-an11 ( talk) 07:28, 12 April 2024 (UTC) reply
      @ Aditya-an11 pretty sure Suffusion was talking about emailing Daniel Quinlan, not you. – 143.208.238.195 ( talk) 08:20, 12 April 2024 (UTC) reply
      Sorry, my bad. I have crossed it out Aditya-an11 ( talk) 08:58, 12 April 2024 (UTC) reply
      @ Aditya-an11: Responding to your email, there isn't much you can do to protect against someone who has access to your account from modifying the page. Full protection won't really work; if the attacker says "Hey, I need to update my key, can you unprotect the page for bit" it's highly unlikely any admin would argue. You'll just have to trust that whoever is verifying your identity is clueful enough to check timestamps. Suffusion of Yellow ( talk) 18:20, 12 April 2024 (UTC) reply
      And I just realized that if the account is compromised, the attacker "is" the victim as far as MediaWiki knows, and will of course bypass the filter. If you plan on using anything in your userspace to prove your identity after a compromise, you'd better, again, hope, that someone goes looking for the oldest edit. Suffusion of Yellow ( talk) 04:45, 12 April 2024 (UTC) reply
      But the only things I have are that I have my committed identity listed on my local and global user pages (I've recently updated it minutes ago), and my account has a very strong password and has 2FA enabled globally.
      Only my alternate account has a very strong password but can only be used in an emergency or in unsecure areas where I can't access my main. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 04:52, 12 April 2024 (UTC) reply
      The point is that if someone gains your password and 2FA secret, and then they change your committed identity, this will be recorded as an edit coming from you. The only thing that will be sus is the fact that "you" changed "your" identity recently. If T&S has to distinguish between two people both claiming to be you (if only Brian had known about cryptographic hashes...), it's the oldest hash that they'd have to look at. Suffusion of Yellow ( talk) 05:06, 12 April 2024 (UTC) reply
      If the user has additional permissions, Wikipedia is definitely impacted. I'll respond to your email tomorrow or this weekend. Thanks for the additional context. Daniel Quinlan ( talk) 05:38, 12 April 2024 (UTC) reply
      This is a big drawback that I think this filter has. Not to mention that @ Suffusion of Yellow believes that these filters could be exploited by vandals. And this is concerning to me....
      Sure, the filter seems to provide basic protection, but I feel this fails when my account gets breached OR the person who is vandalising have apt technical knowledge to exploit it. Going by the case of Wikipedia:Wikipedia Signpost/2007-05-14/Committed identity, both the situation are probably.
      These security concerns was partly what prompted me to ask for full page protection in the first place. "Full" as in even if a vandal gets access to my account, they can't edit the my committed-identity page. Only the admins can. And that's way more reassuring and secure than the filter. While I do understand this may not be common, I do see people page protecting their committed identity pages (like Gwern to which I cited here). Though, in all fairness, I am a new user and could be wrong. I would be happy if get any guidance on how to maturely approach this issue. Aditya-an11 ( talk) 07:49, 12 April 2024 (UTC) reply
      Thanks, steward is the appropriate group, I'll update the filter. As far as the message goes, this filter should almost never match, but I'm open to suggestions. Also, if the default disallow message is considered bitey for reasons (beyond it being non-specific), we should discuss making it less bitey under a new topic. Daniel Quinlan ( talk) 04:02, 12 April 2024 (UTC) reply
      Correct me if I'm wrong, but the filter also prevents any editing of any user page containing the template, which is likely to create its own problems (maybe SoY has already pointed this out by email). I took a look at the RFPP request and would say that of course protection can be used for 'important' subpages. I've had my own PGP sub-page semi-protected since I became an admin, and I'm sure I've even fully protected others' key pages, if that's what they asked for (semi is usually enough though, IMO). As SoY points out, timestamps are everything when it comes to key verification. -- zzuuzz (talk) 07:39, 12 April 2024 (UTC) reply
      Honestly, I'd recommend making that filter private right now even if it didn't change from what it currently is(or it's ultimately disabled), if there's any worry of people trying to bypass it - isn't that the main reason filters are privated? @ Zzuuzz, it's not every edit, though it is every user page yes. – 143.208.238.195 ( talk) 07:54, 12 April 2024 (UTC) reply
      Yes, you're right. What would be prohibited is something like courtesy blanking, replacing a user page with a sock tag or a banned notice (or reverting such), along with removing bad content placed by the user near the template. I'm still sceptical about the filter, or anyone relying on it, so will let someone else make that judgement about its visibility. -- zzuuzz (talk) 08:23, 12 April 2024 (UTC) reply
      At this point, since you pretty much said it as an example, I might as well say it, the filter, as a side effect, gives all users the capability of fully protecting specific lines of their choice from non-admin users - this is not something which should be given lightly or even automatically unless it's really good automation (not the case with the way the filter currently is) because ill intentioned users exist. – 143.208.238.195 ( talk) 08:43, 12 April 2024 (UTC) reply
      Yeah, that's what I had in mind, e.g. {{ committed identity|Zzuuzz is a total ...}} Yeah, we could tweak the regex so that they can only talk about how much DEADBEEF 15 A B00BFACE FBDB, but is it worth the trouble? I've already though up about four ways to bypass this filter (again, emailed DQ, some of them are sort of relevant to other filters). Suffusion of Yellow ( talk) 18:03, 12 April 2024 (UTC) reply
      Bbb23, who is a much more frequent target for vandals, would not be exempt from that either. 0x Deadbeef→∞ ( talk to me) 15:21, 13 April 2024 (UTC) reply
      I've disabled the filter and set it to private for now. I think it might be better to integrate it into a more generalized (and probably private) filter for user page vandalism and shenanigans, one that flags edits rather than disallowing them. I'd also like to better address some weaknesses in the implementation (that was always the plan).
      One option we might want to consider is designating a specific location (or locations) for committed identity information, PGP keys, etc. and protecting it similarly to .css and .js files. I think the concerns about the filter allowing users to "protect" specific lines are somewhat overblown as this is already possible with personal .css, .js, and .json pages and this hasn't been a major issue. Daniel Quinlan ( talk) 19:43, 12 April 2024 (UTC) reply

      [URGENT] Education Program needs to be exempted from filters

      See this filter log, and this is something that I've seen before. Members or coordinators of the education program getting caught up in filters is probably one of the worst possible false positives and should be addressed immediately. Taking Out The Trash ( talk) 17:38, 13 April 2024 (UTC) reply

      Courtesy ping to Ohnoitsjamie as the last editor of the miscellaneous article/draft/talk LTA filter. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 18:14, 13 April 2024 (UTC) reply
       Fixed by Ohnoitsjamie. Nobody ( talk) 20:06, 13 April 2024 (UTC) reply
      Thanks, Nobody; I fixed it, then was unable to figure out where this ping originally came from. OhNoitsJamie Talk 20:11, 13 April 2024 (UTC) reply

      Set filter 1294 to disallow

      • 1294 ( hist · log) ("Test edits and low effort vandalism", public)

      Standard notification. Split out of 260 ( hist · log), 384 ( hist · log), and 614 ( hist · log), with a handful of additions. No FPs in the few dozen "new" matches. I'm not going to add this to Template:DatBot filters. In fact, that was part of the reason for the split. I doubt that users adding "lol" and "fdshksdjfhskdjdshfflshjfsldkhfdslkhsfd" are really going to put in the effort to work around the filters, so let's have a bit less clutter at WP:AIV/TB2. Suffusion of Yellow ( talk) 00:36, 14 April 2024 (UTC) reply

      Understood. This filter is targeted towards your run-of-the-mill everyday vandal who doesn't use much effort to bypass this filter and/or trigger 1296 and/or 1297 instead.
      Also, this might be different from 664 ( hist · log). Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 00:50, 14 April 2024 (UTC) reply
      664 is warn-only, though I haven't looked through the log to see if it can be set to disallow. 1296/1297 is an experiment that might go nowhere. 1297 is not going to be easy to maintain and IMO a filter that complicated is only justifiable if keeps out a huge amount of vandalism. Suffusion of Yellow ( talk) 00:59, 14 April 2024 (UTC) reply
      No problems here, seems solid from a glance at the filter. EggRoll97 ( talk) 05:02, 14 April 2024 (UTC) reply

      Need a change for #867

      After noticing this, I suggest excluding undos and reverts from being logged onto the edit filter log by #867. Toadette ( Let's talk together!) 14:47, 14 April 2024 (UTC) reply

       Fixed. EggRoll97 ( talk) 17:56, 14 April 2024 (UTC) reply
      Not sure if that's a good idea. After an AFD was closed as "redirect", it's common that someone will come back much later and try to undo the result. I see no harm in logging that. Suffusion of Yellow ( talk) 18:47, 14 April 2024 (UTC) reply
      Self-reverted for now, though anti-vandalism isn't exactly the scope of this filter. For example, Special:Diff/1218898491 isn't a large page creation, it's reverting redirect vandalism. EggRoll97 ( talk) 20:52, 14 April 2024 (UTC) reply
      Sure but there's no harm in a log-only filter catching a few out-of-scope edits. If I understand this change correctly, around next WP:THURSDAY you'll be able to write something like page_last_edit_age >= 86400 to exclude reverts of recent edits. But even that would exclude rapid edit warring to overturn an AFD. Suffusion of Yellow ( talk) 20:59, 14 April 2024 (UTC) reply

      Prepare for Armageddon: temporary accounts

      (Topic name is a reference to one of my favorite error messages.)

      The 15 April The Tech News weekly summary includes this blurb:

      Volunteer developers are kindly asked to update the code of their tools and features to handle temporary accounts. Learn more

      Of course, it's not just code that will need to be updated. A good number of edit filters are going to need to be updated. I don't think we necessarily want or need to update anything before it happens, but I'd suggest enumerating the variables and functions most likely to be affected and start building a list of filters expected to require updates.

      (This may have been discussed before, but I didn't immediately find anything in the archive.) Daniel Quinlan ( talk) 23:57, 15 April 2024 (UTC) reply

      If we don't have anything to feed to ip_in_range(), that will be bad, and some filters will have to just be disabled. But otherwise, so long as temp accounts are never autoconfirmed, and have an edit count and age that stays at zero or null, I don't think a huge number of filters will need updating. If user_age and user_editcount start incrementing, then we might want to check user_type in some filters. I'd prefer to see how temp-account users act first. Will the vandals clear cookies after every edit? Or will most of them be too clueless? No way to know right now. Suffusion of Yellow ( talk) 01:04, 16 April 2024 (UTC) reply
      I'm hoping that the IP variables are unaffected, but I haven't dug into that. I was most concerned about user_age which is definitely used as an IP test. Daniel Quinlan ( talk) 01:47, 16 April 2024 (UTC) reply
      One thing we might have to consider is this: If people start crying "We're being flooded with vandalism! We need to require registration for everyone!" an alternative might be making the filters much harsher for temp users. As in, you add "gay" to a BLP, in any context, and you're told "you have to register an account to do that". You edit more than three pages in ten minutes: "sorry, either wait ten minutes or register an account". And so on. I hope it doesn't come to that, but disabling all logged out editing would be a greater loss, I think. Suffusion of Yellow ( talk) 02:31, 16 April 2024 (UTC) reply
      Yeah I agree with you as we have a lot of productive IP users. I think that once this gets implemented, using !("confirmed" in user_groups) (as long as the temp accounts can't become confirmed or get other user permissions but that should happen anyways) would work quite well to prevent new users and the new temp account issues. – PharyngealImplosive7 (talk) 02:39, 16 April 2024 (UTC) reply
      It looks like the new user_type variable will probably work well for most simple filters.
      We also need to understand how this affects filters that use the IP in throttling actions.
      It might also be a good time to consider whether there are any additional variables or functions that could help alleviate any losses in functionality. There are "hacks" such as trying to detect reverts by looking at the edit summary. That example might not be something that wants to be fixed sooner because of temporary accounts, but are there other hacks that might be more important to replace with a better solution due to temporary accounts? Daniel Quinlan ( talk) 06:29, 16 April 2024 (UTC) reply
      I think, I hope, that IP masking causing that level of disruption would convince the WMF to roll it back at least locally. Snowmanonahoe ( talk · contribs · typos) 12:45, 22 April 2024 (UTC) reply

      Set filter 1076 to warn

      ("Draftified article more than 180 days old")

      Has some inevitable false positives due to AfDs, but people closing those know what they're doing. Otherwise there are a lot of draftifications of old articles by people who either don't realize how old the page is, don't know they're not supposed to do that, or both, and it would be nice if they could be warned as they do it, not later if someone happens to notice. * Pppery * it has begun... 03:43, 20 April 2024 (UTC) reply

      I agree, so I support warning. Changed to neutral because of the amount of FPs. Also note that if this passes, we'll have to make a new and specialized warning template but I'm sure you already know that... PharyngealImplosive7 (talk) 16:36, 20 April 2024 (UTC) reply
      Also support. EggRoll97 ( talk) 17:56, 20 April 2024 (UTC) reply

      Not opposed to this, but both User:Evad37/MoveToDraft.js or User:MPGuy2824/MoveToDraft.js just say something like this when a filter is tripped:

      Could not move page:
      API error: abusefilter-warning
      
      Try again ?
      

      Also MPGuy's version already gives this warning:

      Draftifying isn't appropriate per WP:DRAFTIFY, since this article is more than 90 days old.

      which is kind of hard to miss. Ideally, these script would be updated to show the parsed warning, though I'm not sure how much of an effect it will have. (Courtesy pings Evad37, MPGuy2824.) Suffusion of Yellow ( talk) 19:45, 20 April 2024 (UTC) reply

      There are also, of course, manual draftifications not using the script, which currently get no warning. * Pppery * it has begun... 21:17, 20 April 2024 (UTC) reply
      Yes, it's probably a fair trade-off even the if the scripts don't display the warning properly. Suffusion of Yellow ( talk) 21:39, 20 April 2024 (UTC) reply

      I'm not sure about this. I've manually analyzed the last 50 filter hits; and while 17 of those were true positives, there were 27 false positives (along with 6 cases in which it wasn't as clear to me). As far as I can see, the majority of the FPs came from round-robin page moves, draftification following WP:AFD/ WP:REFUND, and situations in which the page itself had existed for more than 180 days, but had only recently been moved to mainspace (and were therefore within the time limit for draftification):

      a smart kitten's analysis of recent 1076 ( hist · log) filter hits

      True positives

      1. Special:AbuseLog/37520237
      2. Special:AbuseLog/37517861 - the draftification was of a recently-created article on top of a redirect, so would have been within the time limit for draftification had it been a brand new page. however, given that the page was blanked-and-redirected as a result of an AfD, the page should probably have just been blanked-and-redirected again - rather than moving the page to draftspace, and taking the history of the previous article with it.
      3. Special:AbuseLog/37517848 - same as above
      4. Special:AbuseLog/37515983
      5. Special:AbuseLog/37515631
      6. Special:AbuseLog/37507112 - was originally draftified at an AfD, but was then later accepted through AfC. this draftification took place >180 days after the AfC acceptance
      7. Special:AbuseLog/37506617
      8. Special:AbuseLog/37501991
      9. Special:AbuseLog/37501990
      10. Special:AbuseLog/37501989
      11. Special:AbuseLog/37501988
      12. Special:AbuseLog/37474830
      13. Special:AbuseLog/37465973
      14. Special:AbuseLog/37462419
      15. Special:AbuseLog/37460722
      16. Special:AbuseLog/37442207
      17. Special:AbuseLog/37437883

      False positives

      Manual round-robin page moves

      1. Special:AbuseLog/37526456 - see Special:PageHistory/Mister Peabody
      2. Special:AbuseLog/37526444 - see Special:PageHistory/Una storia importante (song)
      3. Special:AbuseLog/37526437 - see Special:PageHistory/Ucisa
      4. Special:AbuseLog/37510585 - see Special:PageHistory/World egg
      5. Special:AbuseLog/37496701 - see Special:PageHistory/Project 8 (soccer league)
      6. Special:AbuseLog/37475553 - see Special:PageHistory/IT law
      7. Special:AbuseLog/37475530 - see Special:PageHistory/Ballyrory (disambiguation)
      8. Special:AbuseLog/37457511 - see Special:PageHistory/Espresso (Sabrina Carpenter song)
      9. Special:AbuseLog/37452252 - see Special:PageHistory/Conference Finals
      10. Special:AbuseLog/37423355 - see Special:PageHistory/Pentavryso, Kozani

      Draftification from WP:REFUND

      1. Special:AbuseLog/37524078
      2. Special:AbuseLog/37494847
      3. Special:AbuseLog/37475645
      4. Special:AbuseLog/37442191
      5. Special:AbuseLog/37423697

      Draftification from WP:AFD (or similar)

      1. Special:AbuseLog/37500939
      2. Special:AbuseLog/37478431 - was deleted at AfD, & draftified post hoc after a request was made to the closing administrator
      3. Special:AbuseLog/37429525
      4. Special:AbuseLog/37429351
      5. Special:AbuseLog/37419717 - was deleted at AfD in 2017, but draftified at a DRV

      The page itself had existed for >180 days, but had only recently been moved to mainspace

      1. Special:AbuseLog/37517510 - see Special:PageHistory/Draft:Naima G. Sharaf
      2. Special:AbuseLog/37512391 - see Special:PageHistory/Draft:Miriam Grossman
      3. Special:AbuseLog/37439308 - see Special:PageHistory/Draft:Battle of Umbarkhind
      4. Special:AbuseLog/37437754 - see Special:PageHistory/Draft:Radha Krishna Public School, Amroha
      5. Special:AbuseLog/37433258 - see Special:PageHistory/Draft:Jimmy Gardner (labourer)
      6. Special:AbuseLog/37433081 - see Special:PageHistory/Draft:UV Creations
      7. Special:AbuseLog/37423896 - see Special:PageHistory/Draft:St. Rochus Clinic Bad Schönborn

      Less clear/Other potential FPs

      1. Special:AbuseLog/37518209 - all of the substantive content was added to the page by the draftifying editor (see Special:PageHistory/Draft:MPL Philippines Season 11). could probably have been a G7
      2. Special:AbuseLog/37514053 - was draftified by a checkuser due to being a commissioned article, & therefore needing to go through AFC
      3. Special:AbuseLog/37511738 - draftified a newly-created article that was started on top of an older redirect. there was no prior page history besides the redirect, though, so the mainspace redirect was just able to be recreated after the new article was draftified
      4. Special:AbuseLog/37490978 - moved a redirect to draftspace to allow for the title to be taken by an article. should probably (imo) have just been a round-robin or {{ db-move}} situation; but at the same time, it doesn't seem like what this filter was designed to catch
      5. Special:AbuseLog/37488312 - draftified a newly-created article that was started on top of an older redirect from a BLAR in 2021 (see Special:PageHistory/Draft:Samdish Bhatia)
      6. Special:AbuseLog/37455711 - was draftified partially due to possible COI concerns, but the article had existed since 2011

      Although I think a warning for true positives would be beneficial (for the same reason as Pppery), I'm wondering if there are any ways that the rate of FPs can be decreased before this filter is set as such. As things currently stand, I'm leaning oppose, due to the large proportion of warnings that would be given to editors encountering false positives. (Also, Courtesy ping: Bradv as the filter's author.)

      All the best. ‍—‍ a smart kitten[ meow 16:39, 21 April 2024 (UTC) reply

      Maybe we could reduce FPs from recently moved pages like this: moved_from_age > 15552000 & moved_to_last_edit > 604800
      Note that I'm just using 1 week as a placeholder for when the article was last moved so it can be changed to whatever value is best. – PharyngealImplosive7 (talk) 17:03, 21 April 2024 (UTC) reply
      moved_to_last_edit_age seems to be null if the target page doesn't exist; see testwiki:Special:AbuseLog/102036. Suffusion of Yellow ( talk) 19:31, 21 April 2024 (UTC) reply
      Maybe then it could be moved_from_age > 15552000 & (moved_to_last_edit > 604800 || moved_to_last_edit == null) but I'm not too sure about this. – PharyngealImplosive7 (talk) 20:12, 21 April 2024 (UTC) reply
      Ugh, brain fart. Now I get it. You're saying that if the move was recent, the leftover redirect is probably still there in draft space, so we can use its age? Yes, that's a great idea! Though now I'm confused as to why there's a moved_to_last_edit_age variable at all. If the redirect-to-be-overwritten has only one revision, that's just the same as moved_to_age. And if it has more than one revision, the move is just impossible. Suffusion of Yellow ( talk) 04:18, 22 April 2024 (UTC) reply
      This is not convincing to me on principle. because the people doing false positives are experienced users that know what they're doing so will just click through the warning. * Pppery * it has begun... 17:39, 21 April 2024 (UTC) reply
      Thanks for all the digging! The first group of FPs all include a summary that contains either "robin", "swap", or "vacate". I don't know if that's a representative sample, but just excluding those summaries would produce few false negatives, unless someone deliberately uses them to avoid being logged by the filter, in which case they should at minimum receive a stern talking-to. The second group seems to come from one script ( User:SD0001/RFUD-helper) which could be excluded. The others can, I suppose, just click past the warning. Compare 602 ( hist · log), which warns every person leaving a CTOPS notice, appropriate or not. Suffusion of Yellow ( talk) 19:28, 21 April 2024 (UTC) reply
      Paranoia would suggest only excluding edits with the first FP summaries if the requester holds page mover rights, and also creating a separate filter to log any exclusions. * Pppery * it has begun... 20:11, 21 April 2024 (UTC) reply
      Fair point regarding the others just being able to click past the warning - I suppose one of the things I'm concerned about is inadvertently building up banner blindness; though maybe the warning could be worded in such a way that it doesn't state that the editor is definitely trying to improperly draftify a page, just that the edit filter has detected that they might be. I'm in agreement with Pppery regarding only excluding the first set of edit summaries if the editor holds pagemover rights (in a similar way, User:SD0001/RFUD-helper could be set to exclude only if the editor is an admin), and I don't have a strong opinion either way regarding creating a separate filter to log exclusions. Annoyingly, I'm not sure if there's a way to filter out 'page is old but was only recently moved to mainspace' hits.
      As a side-note, I'm wondering if it's worth notifying Wikipedia talk:Draft of this proposal - would anyone have any objections if I did? All the best, ‍—‍ a smart kitten[ meow 09:05, 22 April 2024 (UTC) reply
      I'm disinclined to set anything to warn an experienced editor. The only warnings from the edit filter I receive as an experienced editor are "you're about to place a CTOP" warnings, and those are a pain. They are jarring to my workflow, and they break user scripts. Also a 54% false positive rate is very high. – Novem Linguae ( talk) 10:41, 22 April 2024 (UTC) reply

      Is this worth changing the 'Numeric change without summary' filter?

      Until WP:VPT#I don't understand these edit summaries (task: T360164) is fixed, would it be worth it to change the pattern to match these cases too?
      I'm not really sure how to check how often edits like that are happening and not getting logged by the filter, other than manually looking at Special:RecentChanges (I also don't know what other filter this might be affecting), but I figured I'd point it out and ask anyways. – 143.208.239.226 ( talk) 02:32, 22 April 2024 (UTC) reply

      Thanks, tweaked. Found one example out of the last 1000 mobile app edits. Suffusion of Yellow ( talk) 03:56, 22 April 2024 (UTC) reply

      Videos

      Youtube | Vimeo | Bing

      Websites

      Google | Yahoo | Bing

      Encyclopedia

      Google | Yahoo | Bing

      Facebook