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.
Latest comment: 3 months ago4 comments3 people in discussion
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.
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
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
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
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.
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
Nice find, looks like that just got added several days ago. I'm going to need to reread all of that. There are about a dozen enabled filters using ip_in_range and ip_in_ranges, including some LTA filters, so hopefully T357772 ends up in a good place. Daniel Quinlan (talk) 06:01, 16 April 2024 (UTC)Reply
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
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):
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.
Special:AbuseLog/37514053 - was draftified by a checkuser due to being a commissioned article, & therefore needing to go through AFC
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
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-robinor{{db-move}} situation; but at the same time, it doesn't seem like what this filter was designed to catch
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.)
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
So then what variable would work better? I can't seem to find any suitable alternatives, but again you raise a point about the existence of the draft article preventing someone from moving back the page unless they are an admin or page mover (which isn't the majority of editors). So that wouldn't work because the move would be impossible. – PharyngealImplosive7(talk)02:36, 23 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
If they don't have pagemover rights, then they've left a redirect behind in mainspace. I don't know what fraction of admins at least do a spot check on R2 deletions, but if anyone frequently gets up to shenanigans like this, they'll be caught eventually. Filters (especially public filters) are never meant to stop every clever person from finding a workaround. With all that said, I still wouldn't object to a second, log-only, no-exceptions filter. The condition limit was doubled last year, and "move" filters are cheap. Suffusion of Yellow (talk) 23:50, 22 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.
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
To be fair, the round-robin moves I found in this filter's logs all appear to have been done manually (rather than using a script) - there appears to already be an exception in 1076 for moving to subpages of Draft:Move, which - as far as I'm aware - is what the scripts do. Personally speaking, I'd like to see if the false positive rate can be reduced before considering implementing a warning. All the best, —a smart kitten[meow]13:11, 24 April 2024 (UTC)Reply
Is this worth changing the 'Numeric change without summary' filter?
Latest comment: 2 months ago2 comments2 people in discussion