Wikipedia:Edit filter noticeboard

"WP:EFN" redirects here. For information on the {{efn}} template, see WP:EXPLNOTE.

Welcome to the edit filter noticeboard

WATCH Recent filter changes (): Filter 614 — Pattern modified Last changed at 20:01, 20 May 2024 (UTC) Filter 1306 (new) — Actions: none; Flags: enabled,private; Pattern modified Last changed at 21:47, 19 May 2024 (UTC) Filter 260 — Pattern modified Last changed at 01:25, 17 May 2024 (UTC) This is the edit filter noticeboard, for coordination and discussion of edit filter use and management. If you wish to request an edit filter, please post at Wikipedia:Edit filter/Requested. If you would like to report a false positive, please post at Wikipedia:Edit filter/False positives. Private filters should not be discussed in detail here; please email an edit filter manager if you have specific concerns or questions about the content of hidden filters. There are currently 323 enabled filters and 47 stale filters with no hits in the past 30 days. Filter condition use is ~1001, out of a maximum of 2000. (). See also the profiling data and edit filter graphs. Click here to start a new discussion thread

AIV disruption

The filter that detects new users removing entries from AIV (I don't know the specific number) can be subverted by commenting out entries instead of completely removing them (example). Perhaps the filter could be modified to account for this? Partofthemachine (talk) 01:32, 6 July 2023 (UTC)

This is filter 768. — Mdaniels5757 (talk • contribs) 02:43, 6 July 2023 (UTC)

Since it's a private filter, I don't know how it operates or what change should be made to fix this issue. Partofthemachine (talk) 18:34, 9 July 2023 (UTC)

As far as I can tell, the filter has still not been fixed. Partofthemachine (talk) 23:16, 13 July 2023 (UTC)

If it's a one-off issue, then we don't require a change urgently. If one notices multiple occurrences, then we can make a case on this. Thanks, Lourdes 09:58, 16 July 2023 (UTC)

This is a pretty regular pattern for a specific LTA (Wikipedia:Long-term abuse/AudiGuy-1204), here is another example of this user doing that. Partofthemachine (talk) 23:57, 25 July 2023 (UTC)

Special:CreateAccount and WP:EFFP

I'm seeing a good number of users in recent days who are being directed to WP:EFFP after being denied a username or something like that (see two, recent examples). It doesn't appear that this is part of the abuse filter, but is there some page that's pointing people experiencing errors with account registration to WP:EFFP? — Red-tailed hawk _(nest) 03:13, 11 July 2023 (UTC)

(note: the two links appear to point to the same place)

Abuse filters do deal with account creation. The documentation page lists autocreateaccount and createaccount as possible values of the action variable.

See also this abuse log. 0xDeadbeef→∞ (talk to me) 06:10, 11 July 2023 (UTC)

That's coming from this edit to {{Edit filter warning}}. All "disallow" filters now show an inviting blue button leading to a pre-filled WP:EFFP report. It seems {{FULLPAGENAME}} is Special:CreateAccount, but the hits are actually logged under Special:UserLogin Possible fixes:

• Replace {{FULLPAGENAME}} with {{#ifeq:{{FULLPAGENAME}}|Special:CreateAccount|Special:UserLogin|{{FULLPAGENAME}}}}, so at least the report makes sense.
• Just hide the inviting blue button, when {{FULLPAGENAME}} is Special:UserLogin, unless the message has "opted in" with fplink=yes.

The question is, do we want FP reports from username filters? Ideally, yes, but they haven't created an account yet, so they have to expose their IP just to make the report. Yes, this fact is disclosed, just as with any other edit, but still, I'm leaning towards hiding the button. Suffusion of Yellow (talk) 19:51, 11 July 2023 (UTC)

Is there a way to allow new editors to report a problem with the edit filter without making them disclose their IP? Potentially we could redirect them to WP:VRT instead. Partofthemachine (talk) 03:00, 12 July 2023 (UTC)

What if we redirected them to WP:ACC? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 14:01, 13 July 2023 (UTC)

I think take them to ACC as VRT can't actually create accounts to override the title blacklist/edit filters without the needed permissions. Zippybonzo | Talk (he|him) 14:49, 13 July 2023 (UTC)

Yes, if you ask the VRT to create you an account, you will likely be directed to ACC anyway, so this is the logical next step. I’ll ping @Red-tailed hawk for possible comment, as they are the creator of this thread. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 15:27, 13 July 2023 (UTC)

I've created a request to implement the change proposed by Suffusion of Yellow above. I think it's strictly an improvement over the current state. I don't know the answer as it pertains to whether EFFP is the most competent venue to handle these, but so long as we don't have consensus to point the reporting flow elsewhere, I think that we should improve within our current structure. — Red-tailed hawk _(nest) 02:27, 19 July 2023 (UTC)

Disagree. The only thing stopping them from starting up right now right now is the name. Why make them wait for a response from ACC? Instead they should create an account (under maybe a less-preferred name) and request rename afterwards, if they really feel so inclined. Suffusion of Yellow (talk) 18:32, 13 July 2023 (UTC)

I don’t think it takes long for ACC to create an account. Arguably, it will take longer to request a rename then to get your preferred name from the outset. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 18:35, 13 July 2023 (UTC)

Well, it used to be backlogged by months. I haven't paid attention recently. But the point is, even if the rename takes a while, they can start editing under the current name right away. The ACC route makes them wait to edit, unless they want to expose their IP. Suffusion of Yellow (talk) 18:37, 13 July 2023 (UTC)

This is true. Maybe we give them a choice, they can begin editing now and request a rename, or use ACC. Is that okay with you? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 18:45, 13 July 2023 (UTC)

Really, I don't see why. The 47,434,980 "best" names are already taken. When Bob tries to register an account, he's going to be to Please choose a different name for "Bob", "Bob1", "Bob123", "Bob42", "Robert", and so on. If 887 (hist · log) also won't let him have "Bobobobobobobobobob", he should, again, pick another name. There's no need to interact with a human. I am, of course, talking about creataccount actions. FPs on autocreataccount are a much bigger problem, but we try to avoid disallowing autocreateaccount at all costs.

That said, now that I look them, Mediawiki:Abusefilter-disallowed-repetitious-username and Mediawiki:abusefilter-disallowed-random-typing-username could be a bit less BITEy. There's no need to mention words like "unconstructive" at all. Suffusion of Yellow (talk) 20:59, 13 July 2023 (UTC)

Perhaps something along the lines of: The username you selected is unavailable because [reason] please choose a different username. Your username is not permanent and can always be changed later by requesting a rename.

Which should encourage people to try again without human intervention, while also mitigating any concerns they have about needing to get their username perfect ab initio. 74.73.224.126 (talk) 01:19, 14 July 2023 (UTC)

I think this approach would work best. A kind message explaining that excessive repetition in usernames is going to be better than directing them to EFFP, which frankly can't actually help them create an account. — Red-tailed hawk _(nest) 02:25, 14 July 2023 (UTC)

Agreed. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:37, 14 July 2023 (UTC)

There’s been another new report relevant here. I think we should direct them to WP:ACC or just tell them to create an account at another name. Either way a change needs to be made immediately before we receive more reports, and users are forced to leak their IPs. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 01:51, 19 July 2023 (UTC)

Re ACC backlogs: if there are no blocks on the IP, it's about 12 hours maximum wait. If there are blocks, and the guide requires a checkuser investigate, the wait could be more like 2 months. — Mdaniels5757 (talk • contribs) 02:37, 19 July 2023 (UTC)

Okay, thanks for the insight. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:38, 19 July 2023 (UTC)

https://accounts.wmflabs.org/internal.php/statistics/monthlyStats is one of the few statistics pages that's actually public-access, although it's use of statistics like standard deviation means it still takes a bit of interpretation. The main backlog indeed hasn't been at the level of months for several years now. stwalkerster (sock | talk) 08:37, 26 July 2023 (UTC)

Filter No. 1062

• 1062 (hist · log) ("Rickroll vandalism prevention", private)

Might we want to create a narrow exemption to the general regex to allow legitimate reporting on AIV/UAA? I'm looking at this report, and it seems to be a legitimate false positive case. It's a private filter, so I'm limited in what I can say publicly, but I don't think we want this sort of thing to block new users/IPs from reporting potential rickroll vandalism to the relevant page. — Red-tailed hawk _(nest) 02:37, 14 July 2023 (UTC)

On a related note, is there a mailing list for EFH/EFMs to discuss private filters? If so, how can I get added? — Red-tailed hawk _(nest) 02:37, 14 July 2023 (UTC)

https://lists.wikimedia.org/postorius/lists/wikipedia-en-editfilters.lists.wikimedia.org is the mailing list. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 13:31, 14 July 2023 (UTC)

Can't we just exempt it when it's at UAA and other admin noticeboards? Zippybonzo | Talk (he|him) 04:46, 14 July 2023 (UTC)

Seems fine to me. I trust your judgement. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 18:39, 14 July 2023 (UTC)

13 July from 16:39 UTC to 16:41 UTC RickRollLandFan (who has no live or deleted contributions) unsuccessfully tries to add RickRoll edits and is stopped by a filter. The IP you refer takes just 3 more minutes to find out this user's id, and to understand that RickRollLandFan has tripped edit filters which have disallowed edits, and then within these 3-5 minutes reports (or tries to) report the vandal to AIV and UAA altogether... Then, reports the false positive. And these all are this IP's first edits here. I'm all for helping IPs file legitimate reports, but would suggest taking a second look. Thanks, Lourdes 11:30, 16 July 2023 (UTC)

If we're talking about 2601:1C0:4401:F60:0:0:0:0/64, I see hundreds of edits going back about month or so. To me, they look like an experienced vandalism patroller whose IP changes occasionally. Suffusion of Yellow (talk) 19:36, 16 July 2023 (UTC)

Aside from the range analysis that Suffision of Yellow aptly notes, the bigger concern I had was that these sorts of antivandalism folks would be prohibited from actually making reports for these sorts of usernames, which is a false positive for a filter whose goal is to try to prevent rickroll disruption. I had a slightly narrower fix in mind for AIV-only, but I think we can wait and see if the larger change is meaningfully increasing rickroll vandalism on-wiki before we try that. — Red-tailed hawk _(nest) 04:29, 17 July 2023 (UTC)

@Red-tailed hawk: Made a larger change. I will resort disallow in a little while, but if I forget, go ahead. Personally, I wonder if that filter even needs to be private. Suffusion of Yellow (talk) 21:08, 16 July 2023 (UTC)

Suffusion of Yellow hi. Rth linked 2601:1C0:4401:F60:88A8:5D40:287C:C78D as the filer and my assessment above was for that. Lourdes 03:56, 17 July 2023 (UTC)r

In general, the IPv6 ranges on Comcast tend assign a /64 to each router, and the range assigned to each router tends to be fairly static, but individuals tend to hop around quite a bit within that range as their device disconnect from/reconnects to the router; this sort of jumping is not unusual for someone with a device that regularly powers down and powers back up. — Red-tailed hawk _(nest) 04:26, 17 July 2023 (UTC)

Because of the way exemption currently works, I think it's best to be kept private. — Red-tailed hawk _(nest) 04:31, 17 July 2023 (UTC)

Ok. My point was that the IP that reported the false positive was the very apparent duck that tried to Rick-vandalise us. Why help the vandal and invest our time here, was what I was pointing to. Lourdes 04:35, 17 July 2023 (UTC)

Are you... sure? I'm not seeing anything from the range history that would indicate a history of vandalism, and they reported multiple accounts to AIV the day before they tried to make the report that started this.

If you're confident that the IP is being used with accounts for good-hand-bad-hand socking, you could shoot an email to the checkuser team to ask them to investigate (they can't publicly link IP addresses and accounts, so an SPI filing probably would not get one far). But I do have to admit that I'm a bit skeptical that this is a case of GHBH based on the broader activity of the /64—is there something I'm missing from their contribs/filter log that indicates that the account is related to the IP, besides the attempt by the IP to report the account to AIV and the related EFFP filing? — Red-tailed hawk _(nest) 04:44, 17 July 2023 (UTC)

My friend, see the filter hits of RickRollLandFan (the account the IP tried to report), check when the account unsuccessfully tried to create a draft article. And then see the filter hit timing of the IP when they tried to unsuccessfully file at UAA/AIV. It is a long shot that an IP got to know of an abusive account that had no contributions, was created just an hour earlier, and tried to add a draft just 3-4 minutes before the IP tried to file the report at UAA. I am ambivalent to what is finally done here, as this is too much of an effort from me to explain. Sorry Red. Go ahead and do what you think prudent. Thanks, Lourdes 04:54, 17 July 2023 (UTC)

Filter 1124

On the note of AbuseFilter/1124, pretty much anyone would agree on the fact that Among Us has barely any popularity now. Sure, there might still be those few vandals clinging on to a dead meme, but that could probably be rolled into an existing filter. GrishForce (talk) 21:02, 18 July 2023 (UTC)

Maybe, but looking at the filter hits, it looks like there are still multiple per day, so I see no reason to change. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:36, 18 July 2023 (UTC)

It's a bit easier to debug when kept separate, and it's still getting daily hits. If it ain't broke... — Red-tailed hawk _(nest) 03:02, 26 July 2023 (UTC)

Filter 247

In response to concerns raised in an EFFP report, it might be worth discussing in the abstract how to address links to mastodon accounts. We currently have a filter that disallows the adding of emails, and it does that quite well, but Mastodon handles have the same format as emails (i.e. username@website.tld) and can thereby cause false positives. From my understanding, part of the rationale for disallowing these things is that (aside from spam prevention) we generally want to keep new users from posting their personal contact information on Wikipedia. This rationale was the thrust of discussion in April, when the filter was expanded to block the addition of emails by new users in all namespaces. (Some related discussion was also on the Oversight policy talk page.)

The filter's currently private, but I do think that it's worth having some abstract discussion on this. Do we want to exempt new users posting Mastodon handles from this filter, or do we want the filter to disallow this sort of posting as a way to prevent new users from posting their off-wiki contact information on Wikipedia?

— Red-tailed hawk _(nest) 04:17, 19 July 2023 (UTC)

CC: Zippybonzo and ILM126, who discussed this on WP:EFFP. — Red-tailed hawk _(nest) 04:17, 19 July 2023 (UTC)

Can we not check for keywords like mastodon, or the @username@mastodon.network, and have a hardcoded list of mastodon networks to allow? Zippybonzo | Talk (he|him) 04:24, 19 July 2023 (UTC)

We could very easily have a hardcoded list of mastodon networks to allow (from a technical perspective). The question I'm posing is whether or not we would want to create that exemption or if we want to prevent the addition of Mastodon links just as much as we do emails. — Red-tailed hawk _(nest) 17:09, 19 July 2023 (UTC)

I don't think we'd want to prevent people from adding Mastodon links. I might be wrong, but I think twitter links are currently allowed and not being prevented by a filter. 0xDeadbeef→∞ (talk to me) 17:53, 19 July 2023 (UTC)

That makes sense. In that case, I have no problem creating a whitelist. Is there any good public comprehensive list of mastodon instances? Best I can find is this, but it's in a format that will require a good bit of manual work to get each of the urls. — Red-tailed hawk _(nest) 18:06, 19 July 2023 (UTC)

Considering anyone can host a Mastodon node on their domain, I wouldn't say this is a good idea. DatGuy^Talk_Contribs 18:32, 19 July 2023 (UTC)

As @DatGuy mentioned, unless there is a way to ping the website to *check* if it is a Mastodon instance. I don't really see a way to reliably keep a hardcoded list due to its decentralised nature. The closest thing that might be a temporary (or permanent) solution is to have a standardised way of typing a Mastodon name/link, that's how I got around the email warning.

@name/@domain instead of @name@domain, with a note within the email warning saying if users are typing in a Mastodon link, they should format is as the first method.

And @0xDeadbeef, Twitter links do work! I've got both on my page. ILM126 (talk) 01:14, 20 July 2023 (UTC)

Regarding unless there is a way to ping the website to *check* if it is a Mastodon instance, no, there aren't any ways to do this using the abusefilter extension. — Red-tailed hawk _(nest) 04:12, 20 July 2023 (UTC)

An alternative solution: {{mastodon user|mdaniels5757@mas.to|mdaniels5757|noon=true}} returns mdaniels5757, so perhaps whitelist {{mastodon user}} (or some better suited template}} and tell users to use that? — Mdaniels5757 (talk • contribs) 19:34, 22 July 2023 (UTC)

That seems reasonable to me, and I think it avoids the problem of anyone can host a Mastodon node on their domain noted by DatGuy above. — Red-tailed hawk _(nest) 03:48, 24 July 2023 (UTC)

Filter 172

There were some false positives from Special:AbuseFilter/172 from removing unreferenced blank sections (report, permalink).

Should we add & !((summary irlike "unsourced") & !(removed_lines irlike "<ref")) (reformatting, of course) or similar to the end of the filter to fix this? — Mdaniels5757 (talk • contribs) 23:56, 21 July 2023 (UTC)

this would be rather niche, considering that the filter only tags edits. I'd say we should keep the status quo, since new users/IPs removing unreferenced sections with many edits would still need to be reviewed 0xDeadbeef→∞ (talk to me) 18:30, 23 July 2023 (UTC)

Fair enough. FWIW DatBot automatically reports users with more than 5 hits of a list of filters including this one in 5 minutes to AIV/TB2 per Template:DatBot filters, so too many FPs would be a problem. — Mdaniels5757 (talk • contribs) 18:37, 23 July 2023 (UTC)

Then DatBot should be reconfigured with this in mind. 0xDeadbeef→∞ (talk to me) 03:52, 25 July 2023 (UTC)

Filter 1245

Most of our false positive reports recently have been from this filter and none of them have actually been false positives. Because it’s effectively wasting volunteers time to review false positives from a filter that has practically none (that I can find), I propose removing the button to report false positives from the disallow message. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:30, 24 July 2023 (UTC)

Agreed. We should keep the link but not have that clickable button. 0xDeadbeef→∞ (talk to me) 06:07, 24 July 2023 (UTC)

I also agree as well with respect to Filter 1245. Any implementation that's broader needs broader discussion, but if we can implement a quick check in the template for this filter alone, I would be supportive. — Red-tailed hawk _(nest) 03:17, 25 July 2023 (UTC)

Yeah for this filter in particular we should encourage people to expand their post rather than futilely reporting a false positive. Galobtter (talk) 03:24, 25 July 2023 (UTC)

Yes, agree. I've updated the documentation for {{edit filter warning}}; just add |fplink=no to MediaWiki:abusefilter-disallowed-new-talk-page-section and the button should be hidden. Suffusion of Yellow (talk) 18:37, 25 July 2023 (UTC)

 Done — Ingenuity (talk • contribs) 18:44, 25 July 2023 (UTC)

Thanks everyone! - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 21:19, 25 July 2023 (UTC)