Archives

Index 1, 2, 3, 4, 5, 6, 7, 8, 9

Permissions archives

Sections older than 10 days may be automatically archived by Lowercase sigmabot III.

Filter 31[edit]

Filter 31 (ASCII art): The match string with the character ∆ should be a regex that includes the similar symbols Δ and △. It's possible that there are other white triangle-like symbols I missed. –LaundryPizza03 (dc̄)

@LaundryPizza03: Do you have a few example edits that should have been caught? I don't like adding stings after a one-off occurence; if everyone did that, the filters would become bloated and unreadable. Suffusion of Yellow (talk) 20:39, 13 June 2022 (UTC)[reply]

Regarding filter 958…[edit]

958 (hist · log)

Hello, edit filter helpers/managers!

I was reviewing filter 958, but I noticed that you didn't list all the IPs of the U.S. Congress under WP:SIP. To provide better guidance, I'd like you to add 137.18.0.0/16, 12.185.56.0/29, 12.147.170.144/28, 74.119.128.0/22, 2620:0:E20::/46, 2620:0:8A0::/48, and 2600:803:618::/48, in case any of them edit.

If you cannot add these to the filter, then that is fine. — 3PPYB6 — TALK — CONTRIBS — 17:07, 28 March 2022 (UTC)[reply]

@Legoktm—Courtesy ping as you created this filter. — 3PPYB6 — TALK — CONTRIBS — 17:59, 28 March 2022 (UTC)[reply]

This filter is run for all anonymous edits, and it checks each edit against each IP range. For the sake of efficiency it makes sense for the filter to only use ranges which are actively used. The above are not. BTW I'm not really sure of this filter's general utility, since you could just check the contribs. Does anyone think it's useful? -- zzuuzz ^(talk) 18:55, 28 March 2022 (UTC)[reply]

This is one of those cases where "conditions" are a really poor measure of performance. An IP range check literally requires converting a few numbers from base 10, then checking against a bitmask. Probably takes a few hundred CPU cycles. But, yes, each check burns through one of our precious 1000 conditions, so I'd rather not do this unless either (A) the filter is converted to use regex, or (B), AbuseFilter is patched so that ip_in_range() takes multiple arguments.

And no, I don't see the point of the filter either. Suffusion of Yellow (talk) 20:01, 28 March 2022 (UTC)[reply]

@Suffusion of Yellow—In that case, I'll just say this: on second thought, merely checking WP:SIP should be enough for you to tell any congressional staffer's edits. If you feel that the filter is no longer required, feel free to delete it. — 3PPYB6 — TALK — CONTRIBS — 21:36, 28 March 2022 (UTC)[reply]

Don't particularly see the point of the filter either. I remember browsing its hits out of general interest before, to see what Congressional IPs are editing, but not sure of the maintenance purpose here (and even if there were one, what makes US Congress edits distinct to various other countries' parliamentary IPs, which aren't filter-logged?) ProcrastinatingReader (talk) 21:43, 3 April 2022 (UTC)[reply]

 Done Disabled the filter. Suffusion of Yellow (talk) 02:04, 8 April 2022 (UTC)[reply]

@ProcrastinatingReader, @Suffusion of Yellow: the main point of the filter is for tagging functionality, and I hope United States congressional staff edits to Wikipedia and Wikipedia:Congressional staffer edits explain the utility.

If performance is an issue, I guess I could just write a bot to add the tags instead of relying on AbuseFilter? As for why only US Congress...just my US bias as an American, happy to set it up for other countries/governments if we know their IP ranges. Legoktm (talk) 16:34, 13 April 2022 (UTC)[reply]

It's not that it has no utility; I just don't see much utility beyond Special:Contribs.

On the subject of performance, every now and then we get hit with the need for an "emergency" filter. That's not the time to fuss over the condition limit. So I like to keep a buffer of a few hundred conditions when things are "slow", and this looks like low-hanging fruit.

That said, I really doubt this filter actually slows anyone down significantly; as I said IP range checks are a trivial calculation. Suffusion of Yellow (talk) 18:09, 13 April 2022 (UTC)[reply]

Sorry if I'm a bit late to the party here but I was just looking through the filters and it seems filter 1025 does something similar (just without the tagging), would it also be worth disabling this? FozzieHey (talk) 16:57, 29 April 2022 (UTC)[reply]

@FozzieHey: Sorry for the late response. I was waiting for the ip_in_ranges() function to be merged. Now that this sort of check is "cheaper", I'm not going to disable it for now. Suffusion of Yellow (talk) 20:30, 31 May 2022 (UTC)[reply]

Restored[edit]

Thanks to WhitePhosphorus, we now have an ip_in_ranges() function, so checking for many ranges should only take up one condition. I've restored the filter (@Legoktm:), with the original three ranges. If anyone wants to add 3PPYB6's suggestions, go ahead. In the meantime, can anyone figure out why I can't restore the tag? I get One or more of the tags you specified is not valid. Tags should be short, they must not contain special characters, and they must not be reserved by other software. Try choosing a new tag name.. But I didn't even change the name, and it worked before. Suffusion of Yellow (talk) 20:30, 31 May 2022 (UTC)[reply]

What specific tag are you asking about? — xaosflux ^Talk 23:14, 31 May 2022 (UTC)[reply]

@Xaosflux: congressedits. There was apparently nothing wrong with it a few months ago, but now I get the above error message when I try to save the filter with that tag enabled. Suffusion of Yellow (talk) 23:28, 31 May 2022 (UTC)[reply]

@Suffusion of Yellow try now, I reactivated that tag. — xaosflux ^Talk 23:32, 31 May 2022 (UTC)[reply]

Ok, that worked. But why? You activated it for manual use. That's not supposed to have any effect on the filter. And we don't want people tagging their own edits as congressedits. So I guess we can deactivate it again now? I'm lost. Suffusion of Yellow (talk) 23:36, 31 May 2022 (UTC)[reply]

It was stuck in "unused" status, that fixed it, I've set it back to tagged by filter only now. — xaosflux ^Talk 23:59, 31 May 2022 (UTC)[reply]

Thank you all for getting this filter back up! Legoktm (talk) 16:15, 1 June 2022 (UTC)[reply]

On a related note, should Special:AbuseFilter/1025 also have a tag on it? 67.21.154.193 (talk) 13:04, 2 June 2022 (UTC)[reply]

@Dreamy Jazz: Your call. Suffusion of Yellow (talk) 20:40, 13 June 2022 (UTC)[reply]

Created a new tag for non-specific parliament / house of commons edits, and assigned that filter the newly created tag. Dreamy Jazz ^{talk to me | my contributions} 10:47, 14 June 2022 (UTC)[reply]

Special:AbuseFilter/1151[edit]

Edit attempt that prompted this inquiry has already been done by someone else, however I think this one could benefit from the addition of !(summary irlike "\bcop(y|ied)|und(id|o)|\brv[vt]?\b|revert|vandal|remov|clean|delet|\brmv?\b|\brepea?t") or something along those lines. Since the filter can already be evaded by someone determined to do so I don't see this as likely to be an issue. 74.73.224.126 (talk) 13:14, 8 June 2022 (UTC)[reply]

Thanks. I just went with !(summary irlike "^(?:undid|revert|rv)") which seems to cover most of it; surprisingly many blanking vandals do like to say "deleted" or "removed". Remember this filter has a throttle; so the IP user making the occasional odd fix will never trip it. Suffusion of Yellow (talk) 21:22, 13 June 2022 (UTC)[reply]

EF 247[edit]

Is there any reason why Special:AbuseFilter/247 should not be set to disallow? If someone pushes through the edit it requires suppression in most cases, and if it's somewhere like the Help Desk it often affects upwards of 50 edits simply due to the high edit rate compared to how frequently someone is checking it; I only found Special:Diff/1092437906 in the most recent hits that is a false positive but I feel like the regex could be tweaked to exclude it. Note that this filter only affects NS0 and NS4 (Main and WP spaces). (please ping on reply) Primefac (talk) 13:23, 12 June 2022 (UTC)[reply]

Filter 3 and new users blanking their own pages (G7)[edit]

Taking a quick look at filter 3 it looks like filter 3 would catch a new user blanking a page they are the only significant contributor to in good faith (G7). This could make new users think you aren't allowed to blank a page as a deletion request. Filter 3 should probably detect if the user is blanking their own page and allow it then. interstatefive  21:28, 12 June 2022 (UTC)[reply]

@Interstatefive filter 3 only impacts articles, which are not really someone's "own page", and a blank article isn't going to be useful for our readers at all. The filter variables "page_recent_contributors" and/or "page_first_contributor" have performance issues as well. That being said, they don't just get blindly denied, they get this special message: MediaWiki:Abusefilter-disallowed-blanking, is there something in there that you think can be improved? — xaosflux ^Talk 21:53, 12 June 2022 (UTC)[reply]

@Xaosflux Per WP:G7, blanking pages can be taken as a deletion request, but filter 3 prevents that. It should check if the blanking user is the only major contributor to the article, or the message should be updated with info about G7. interstatefive  02:47, 13 June 2022 (UTC)[reply]

@Interstatefive The filter used to have a "page_recent_contributors" check for this, but I removed it, because the filter only applies to non-autoconfirmed users, who cannot create articles, so this issue is not possible. Galobtter (pingó mió) 05:24, 13 June 2022 (UTC)[reply]

@Galobtter True. But non-autoconfirmed users can create drafts, and sometimes they want those deleted. interstatefive  14:10, 13 June 2022 (UTC)[reply]

@Interstatefive filter 3 doesn't apply to drafts. Galobtter (pingó mió) 17:40, 13 June 2022 (UTC)[reply]

Oh yeah :P interstatefive  18:05, 13 June 2022 (UTC)[reply]

We certainly can add to that message, drop an edit request at MediaWiki talk:Abusefilter-disallowed-blanking with any suggestions! — xaosflux ^Talk 09:37, 13 June 2022 (UTC)[reply]

I did it. NotReallySoroka (talk) 19:54, 18 June 2022 (UTC)[reply]

However, upon closer inspection, I would argue that the message is unnecessary. Filter 3 only activates for non-confirmed users blanking the mainspace. Since non-confirmed users cannot create mainspace pages, they would have no reason to G7 a page: if they have written no pages, they have no pages that would satisfy the G7 requirement of being the author of a target page. Although there is a case of a new author drafting a page, the page got sent to mainspace, then the author asks for deletion, I do not think that this is important enough for everyone who trips filter 3 to see it. NotReallySoroka (talk) 20:02, 18 June 2022 (UTC)[reply]

Request for permission: User:NotReallySoroka[edit]