Wikipedia:Edit filter noticeboard

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
Welcome to the edit filter noticeboard
Filter 260 — Pattern modified
Last changed at 08:03, 28 June 2022 (UTC)

Filter 1204 — Pattern modified

Last changed at 21:18, 26 June 2022 (UTC)

Filter 432 — Pattern modified

Last changed at 18:51, 26 June 2022 (UTC)

Filter 1014 — Flags: enabled; Pattern modified

Last changed at 19:20, 26 June 2022 (UTC)

Filter 1201 — Pattern modified

Last changed at 22:02, 25 June 2022 (UTC)

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

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

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

Click here to start a new discussion thread

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,,,, 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. — 3PPYB6TALKCONTRIBS — 17:07, 28 March 2022 (UTC)[reply]

@Legoktm—Courtesy ping as you created this filter. — 3PPYB6TALKCONTRIBS — 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. — 3PPYB6TALKCONTRIBS — 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]


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? (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]

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]

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.

NotReallySoroka (t · c · del · cross-wiki · SUL · edit counter · pages created (xtools • sigma· non-automated edits · BLP edits · undos · rollbacks · logs (blocks • rights • moves) · rfar · spi) (assign permissions)(acc · ap · fm · mms · npr · pm · pcr · rb · te)

I would like to request the edit filter help right to help with AIV and to be able to take a look should there be questions regarding private filters. I meet the requirements for granting, including being a currently-active extended confirmed editor. Thank you! NotReallySoroka (talk) 19:49, 18 June 2022 (UTC)[reply]

Oppose. Sorry, but EFH is a (very) sensitive permission, and I'm not really seeing either the strong need or the demonstrated experience that I would normally expect to be comfortable with an applicant. I also note that this is your fourth permission request within 30 days ([1][2][3]), and that it came only about 30 minutes after your request for New Page Reviewer, so I worry that you may be moving a little too quickly. --Blablubbs (talk) 13:16, 19 June 2022 (UTC)[reply]
@Blablubbs: Thank you. To be fair, I had asked about the right at the Teahouse before I came here, but I agree with gaining some experience and not "moving a little too quickly". How may I close this request? Thanks! NotReallySoroka (talk) 22:39, 19 June 2022 (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.

EF 189 and ccnorm/norm[edit]

189 (hist · log)

This filter should probably match a libelous edit like this: Special:Diff/1088504111. I saw ccnorm from mw:Extension:AbuseFilter/Rules_format#Functions, and I think it can be used for this? Thanks. (please ping on reply) 0xDeadbeef 10:40, 21 June 2022 (UTC)[reply]

Backlog of requests at WP:EFR[edit]

There are a quite a few open requests there that haven't really received a response there by admins/EF mamagers. I suggest someone go over them. Some unanswered ones have already been archived

[4] not archived as of now

[5] archived, no response. (talk) 13:33, 21 June 2022 (UTC)[reply]

We need a mechanism for edit requests regarding edit filters.. 0xDeadbeef 07:28, 24 June 2022 (UTC)[reply]

Identify "disallow" filters that could benefit from user_global_editcount[edit]

There is now a "user_global_editcount" that can be used instead of "user_editcount" to avoid affecting globally active users (T130439). I've been the victim of exactly this issue on two wikis when removing spam references, being blocked by filters that are meant to prevent reference-removal vandalism. It's not much of an issue for non-disallowing filters, as experienced users can skip warnings themselves. As a first step, can someone create a list of publicly viewable filters that currently use user_editcount and are set to "disallow"? ~ ToBeFree (talk) 20:09, 21 June 2022 (UTC)[reply]


Extended content
(new mw.Api()).get({
	action: 'query',
	list: 'abusefilters',
	abfshow: ['!deleted', '!private', 'enabled'],
	abflimit: 500,
	abfprop: ['id', 'actions', 'pattern'],
	format: 'json',
	formatversion: 2
}).done(function(response) {
	var ret = [];
	for (let i of response.query.abusefilters) {
		if (i.pattern.includes('user_editcount') && i.actions.split(',').includes('disallow')) {

12, 247, 260 and 320. NguoiDungKhongDinhDanh 21:01, 21 June 2022 (UTC)[reply]

Probably find out first how expensive this is. IIRC, user_global_groups can be really slow. If this one is "cheap", then we can say:
user_global_editcount < 20 &
added_lines rlike "badwords" &
But if it's expensive we should probably say:
user_editcount < 20 &
added_lines rlike "badwords" &
user_global_editcount < 20
Daimona Eaytoy, is there any harm in looking at this variable on every action, like we already do for the some of the other user_ variables? Suffusion of Yellow (talk) 21:19, 21 June 2022 (UTC)[reply]
Per the phabricator task, if I understand correctly, this seems to be just as cheap as user_editcount, as it is a simple lookup of a table value without any calculations. ~ ToBeFree (talk) 21:26, 21 June 2022 (UTC)[reply]
Thank you very much, NguoiDungKhongDinhDanh! 🙂 I have used the code to identify all affected active filters and will have a look at each of them as soon as the syntax checker recognizes the variable. It currently doesn't, so I guess the change isn't rolled out yet. ~ ToBeFree (talk) 21:28, 21 June 2022 (UTC)[reply]
@Suffusion of Yellow: I didn't follow that task, but IIUC this variable should not be particularly expensive. CentralAuth itself was changed so that it stores the global edit count (actually an estimate) in a dedicated table, and querying that table should be relatively fast. That said, I guess it could be slower than user_editcount if nothing in the same request has caused the global editcount to be already computed (which I think could be fairly uncommon, as opposed to preloading the local editcount). I haven't benchmarked it though, so I also don't want to give suggestions that could be wrong. --Daimona Eaytoy (Talk) 10:12, 22 June 2022 (UTC)[reply]