Welcome to the edit filter noticeboard |
---|
Recent filter changes (
):Filter 1184 (new) — Actions: none; Flags: enabled,private; Pattern modified
Filter 1185 (new) — Actions: throttle; Flags: enabled,private; Pattern modified
Filter 773 — Flags: disabled
Filter 1186 (new) — Actions: none; Flags: enabled,private; Pattern modified
Filter 260 — Pattern modified
Filter 339 — Pattern modified
Filter 384 — Pattern modified
Filter 1074 — Pattern modified
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 |
Index 1, 2, 3, 4, 5, 6, 7, 8, 9 |
Sections older than 10 days may be automatically archived by Lowercase sigmabot III. |
Make filter 1048 public?
- 1048 (hist · log) (private, "Possible spam")
I created this filter, but I'm not really checking the log all that often anymore. About 50% of what it catches is genuine spam, but the rest is basically newbie formatting mistakes. It would be nice if non-admin/EFM/EFH users could review the log, too. Does anyone think it was overly paranoid to make this private? Most spammers aren't all that clever. I can remove the first line of the notes, to make it less obvious what the filter is doing. Suffusion of Yellow (talk) 23:11, 15 January 2022 (UTC)
- I'd lean in favour of making it public. -- zzuuzz (talk) 23:28, 15 January 2022 (UTC)
- Probably more useful if public. ProcrastinatingReader (talk) 23:04, 29 January 2022 (UTC)
Done. @Sdkb: This isn't exactly what you requested at EFR, but it catches some of that. Suffusion of Yellow (talk) 23:46, 30 January 2022 (UTC)
N-word filter refinement
Can we get some more of the common variants of the N-word added to the relevant filter? See this diff where the vandal knows to put spaces between the letters to get it through. – Muboshgu (talk) 21:07, 7 February 2022 (UTC)
- Courtesy note for non-admins, it's been RevDelled (for good reason). 🐶 EpicPupper (he/him | talk) 00:05, 9 February 2022 (UTC)
A sort of imdb edit filter
It is possible to make a link to imdb look like a wikilink, like Gillian Dobb (from Magnum,_P.I.#Recurring_characters) and Jonas Brothers: Live in London (from Jonas_Brothers#Television). A normal EL would look like Gillian Dobb.
All these uses [1][2] may not be wrong, but I think these 2 examples clearly go against WP:ELPOINTS 2, though in a sneaky way. For an external links section, something like {{imdb name}}
or {{imdb title}}
should be used instead.
The idea of an editfilter came up at Wikipedia:Help_desk#Links_to_imdb_that_looks_like_wikilinks, but I know nothing about editfilters. Would it be possible/a good idea to make one that warns in this situation, saying something like
"Links like imdbname/imdbtitle" are often inappropriate on WP, since they hide the fact that the link is a WP:EL. They should not be used in article text, and in External links sections {{imdb name}}
or {{imdb title}}
is a better choice. Gråbergs Gråa Sång (talk) 17:43, 9 February 2022 (UTC)
- It's technically possible, but probably not a good option for the edit filter, which (for the most part) shouldn't be used to enforce content or MOS guidelines. ProcrastinatingReader (talk) 18:03, 9 February 2022 (UTC)
- Fair enough. Gråbergs Gråa Sång (talk) 18:14, 9 February 2022 (UTC)
"Unreliable source" filters
- 869 (hist · log), 891 (hist · log), 894 (hist · log), 1034 (hist · log), 1045 (hist · log), 1057 (hist · log) (all public, warn), 892 (hist · log) (public, disallow)
Should the "unreliable source" filters warn people who aren't adding the source in the first place? Currently, we're (mostly) excluding any edit with a summary that matches ^(?:revert|restore|rv|undid)|AFCH|speedy deletion|reFill
. Breaking that down, it's:
^(?:revert|restore|rv|undid)
because page-blanking vandals often incidentally remove such sources.AFCH
because AFC reviewers sometimes link to such sources when declining draftsspeedy deletion
Because G12 copyvio tags, and log entries, sometimes link to such sourcesreFill
Because sometimes the filter can only "see" the source after it's been expanded from the bare URL.
Note that edits excluded from filters these filters aren't "lost in the void". They're logged by 1081 (hist · log) instead.
Now, I said "mostly" above, because a while back Headbomb removed the check from 891. 892 never had the summary check in the first place, and Beetstra recently objecting to my adding it.
My philosophy is that no one is obligated to fix any problem that's already on a page. If you want to spend all day reverting vandalism, it's not up to you to find and fix bad sourcing. But I think we should at least be consistent. Discuss. Suffusion of Yellow (talk) 21:34, 12 February 2022 (UTC)
- Being warned is fine. Especially because a lot of the time people go 'Why did you remove this source, I'm restoring it!' and they don't know it's crap. Headbomb {t · c · p · b} 21:38, 12 February 2022 (UTC)
- Are you fine with adding back to 891 the AFCH, speedy deletion, and reFill exceptions, at least? Suffusion of Yellow (talk) 21:45, 12 February 2022 (UTC)
- AFCH is definitely a place where that warning needs to be front and center. Same for refill, it's great time to catch the nonsense when someone is doing citation work. For speedy deletions, those shouldn't trigger the filter if all you're doing is nomination the thing for deletion. Headbomb {t · c · p · b} 05:37, 13 February 2022 (UTC)
- Edit: Though I do see the point for copyvio CSDs. Headbomb {t · c · p · b} 05:40, 13 February 2022 (UTC)
- Why should AFCH users be warned? The only time the filter will trip is if they're mentioning the source in the template, e.g. declining with something like "All your citations are to lulu.com; we can't use self-published sources." The filter will be telling them something they already know. If they're just accepting the draft, the filter won't trip in the first place. Suffusion of Yellow (talk) 21:54, 13 February 2022 (UTC)
- Edit: Though I do see the point for copyvio CSDs. Headbomb {t · c · p · b} 05:40, 13 February 2022 (UTC)
- AFCH is definitely a place where that warning needs to be front and center. Same for refill, it's great time to catch the nonsense when someone is doing citation work. For speedy deletions, those shouldn't trigger the filter if all you're doing is nomination the thing for deletion. Headbomb {t · c · p · b} 05:37, 13 February 2022 (UTC)
- Also note that actually saving the edit in Twinkle is kind of confusing. There's no button to save the edit. You need to click "back" and then try again, but it's not obvious that that will work. Suffusion of Yellow (talk) 21:49, 12 February 2022 (UTC)
- Are you fine with adding back to 891 the AFCH, speedy deletion, and reFill exceptions, at least? Suffusion of Yellow (talk) 21:45, 12 February 2022 (UTC)
- Being warned is fine. Especially because a lot of the time people go 'Why did you remove this source, I'm restoring it!' and they don't know it's crap. Headbomb {t · c · p · b} 21:38, 12 February 2022 (UTC)
- I objected adding it because in the 892 case the proper proxy links are utterly useless - it is the same as being unsourced except that you know that there is apparently a source out there (try figuring out what was meant by https://web.s.ebscohost.com/ehost/pdfviewer/pdfviewer?vid=1&sid=9dc6fcb4-3f95-4718-b411-c8380bfd8fb9%40redis). Having a speedy deletion tag linking to a true proxy as evidence of copyvio does not enable anyone to check, and if it is behind a paywall good luck finding it (would result in a nice conundrum though - Schroedinger’s copyvio). And I don’t even want bots to add them. For something that is just unreliable I think warning users that revert it back in is good, but then maybe not trip bots who repair some crappy edit - and likely depending on the ‘level’ of unreliability. I would be happy if I was warned after reverting a vandal who blanked a whole section which happened to have a proxy link in them, and frankly the editors that Headbomb mentions is a group that should be warned (but they are indistinguishable from true vandalism reverting). Dirk Beetstra T C 03:51, 13 February 2022 (UTC)
- Good point about deletion templates. And there's no need to add the AFCH exception to 892, for the same reason. And I'd hope reFill would never add a proxy link in the first place. I still think that undo/revert should be excluded from 892, but really, it's a philosophical difference about what edit filters are for. I agree the links are useless link and I agree that it's nice when people reverting vandalism take it step beyond, and fix problems that were there before the page was vandalized. But if they don't, the reverting is still a (large) net positive. I guess I'd like a third opinion here. Suffusion of Yellow (talk) 21:54, 13 February 2022 (UTC)
- I ran a check for positive summaries through the disallow filter and found edits like where reverting article blanking was disallowed (see Special:AbuseLog/31876334), after half a dozen different editors tried to revert and eventually an admin had to make the revert (diff). Seems to be a rare case but it happens every now and then. Philisophically I don't think reverting one issue should oblige the editor to fix another issue to make the revert, nor are filters generally purposed as being quality control tools, so I'm inclined to support the exclusion of reverts etc. ProcrastinatingReader (talk) 22:20, 13 February 2022 (UTC)
- I somewhere else already pinged user:GreenC, we should get rid of unreadable proxy links completely through bot runs (for many you will need to rely on the memory of the original editor to find it back), and convert all other proxy links to the proper source. At that point reverting does not become an issue anymore - there will not be any leftover to revert back in. I’ve had people care so little that I am expecting the revert exclusion on these filters to be gamed. Dirk Beetstra T C 04:10, 14 February 2022 (UTC)
- Probably best to remove the exception for
sysop
if you go that route, or the links will just creep back in over time. It's real easy, even for an experienced user, to copy-paste what's in the address bar without thinking. Suffusion of Yellow (talk) 21:10, 14 February 2022 (UTC)
- Probably best to remove the exception for
- I somewhere else already pinged user:GreenC, we should get rid of unreadable proxy links completely through bot runs (for many you will need to rely on the memory of the original editor to find it back), and convert all other proxy links to the proper source. At that point reverting does not become an issue anymore - there will not be any leftover to revert back in. I’ve had people care so little that I am expecting the revert exclusion on these filters to be gamed. Dirk Beetstra T C 04:10, 14 February 2022 (UTC)
rmspecials
![](https://web.archive.org/web/20220218231802im_/https://upload.wikimedia.org/wikipedia/commons/thumb/e/ea/Purple_arrow_down.svg/20px-Purple_arrow_down.svg.png)
Filters which rely on the rmspecials() function removing spaces may need updating. Details: m:Tech/News/2022/07. Certes (talk) 19:32, 14 February 2022 (UTC)
- @Certes: I think that was all taken care of. Not seeing anything in this search (link won't work for non-EF*) except for "deleted" filters. Suffusion of Yellow (talk) 21:23, 14 February 2022 (UTC)
1184 / 1185 were emergency disallowed
1184 & 1185 (by Suffusion of Yellow) were set to disallow due to an ongoing botnet attack. Both are no longer disallowing due to WMF mitigations (sec phab). I'm going to bed (its 2:41am), so just thought I should note where things are big props to Suffusion for their quick action -- TNT (talk • she/her) 02:41, 18 February 2022 (UTC)
- Thanks for the update, what annoying botnet edits. — xaosflux Talk 11:29, 18 February 2022 (UTC)
- Appears to be a resurgence. TNT beat me to re-enabling filters. Courtesy ping Suffusion of Yellow in case adjustments are necessary. ProcrastinatingReader (talk) 23:06, 18 February 2022 (UTC)
Edit filter blocking - redux
Hey y'all—don't panic, its nothing formal, just a "testing the waters" post to see how the general feeling is.. what are the cons of enabling edit filter blocking, and could these be mitigated by rigorous testing (i.e. policy of a sort which states that a filter must be disallowing for `x` days and have a false-positive percentage below `y`)? -- TNT (talk • she/her) 15:43, 18 February 2022 (UTC)
- For example of blocks, see meta:Special:Log/Abuse_filter. I'd think the biggest 'con' (besides a bad FP filter that goes nuts) is that we need to properly educate our admins about the process. — xaosflux Talk 15:49, 18 February 2022 (UTC)
- @Xaosflux: I guess we could put something into MediaWiki:Group-abusefilter.js that alerts people when they're editing a blocking filter. Otherwise I suspect many people will click "save" without even realizing what they're doing. Suffusion of Yellow (talk) 18:41, 18 February 2022 (UTC)
- @Suffusion of Yellow: no, I mean when the 86% of non-efm admins who will come across users that got blocked by "a bot?", how to investigate that, how to determine who is accountable for the block, etc. — xaosflux Talk 19:10, 18 February 2022 (UTC)
- We could put something in Mediawiki:abusefilter-blockreason like
{{Friendly message to blockee}} <!-- See [[Wikipedia:How to review an edit filter block]]. -->
Suffusion of Yellow (talk) 19:16, 18 February 2022 (UTC)
- We could put something in Mediawiki:abusefilter-blockreason like
- @Suffusion of Yellow: no, I mean when the 86% of non-efm admins who will come across users that got blocked by "a bot?", how to investigate that, how to determine who is accountable for the block, etc. — xaosflux Talk 19:10, 18 February 2022 (UTC)
- @Xaosflux: I guess we could put something into MediaWiki:Group-abusefilter.js that alerts people when they're editing a blocking filter. Otherwise I suspect many people will click "save" without even realizing what they're doing. Suffusion of Yellow (talk) 18:41, 18 February 2022 (UTC)
- I think it could be made to work. I'd prefer to see some active peer review and a sign-off quorum, along with a relevant amount of testing. I'd like to see a false-positive rate well below what we might normally see for a disallow filter, if not zero itself. And you know that on-the-fly adjustments are likely to happen. This all needs to be made very clear. I think we might also want to consider what will happen when there is an emergency demand for a blocking filter. You just know that a situation will arise one day where there's a demand for one without the usual wait. -- zzuuzz (talk) 16:25, 18 February 2022 (UTC)
- @Zzuuzz: Do you any filters in mind, which you would upgrade to "block" if you could? Suffusion of Yellow (talk) 18:41, 18 February 2022 (UTC)
- A block is two things: (1) A technical measure preventing an IP or account from editing, and (2) A "stain" on one's reputation. How many AN/I threads have you seen where the reporter starts out with "As you can see, they've been blocked four times for..."? Yes, people shouldn't do that, but "people shouldn't" is not an actionable plan. So what if we agree to revdel the target username from these blocks when unblocking? That is, if User:Edit filter blocks User:Alice, and Alice is unblocked, then revdel User:Alice from the block log. That wouldn't destroy all evidence of the block (it'd be in her Special:AbuseLog, still), but casual users looking at Alice's block log would see nothing. Suffusion of Yellow (talk) 18:41, 18 February 2022 (UTC)
- That seems a fairly reasonable framing. Though I would say there's not a great number of existing disallow filters which target established users. There's be even fewer blocking filters. -- zzuuzz (talk) 18:57, 18 February 2022 (UTC)
- Even new users might get discouraged though, once they realize how people perceive blocks. For IPs, we have a few "long-termers" on stable IPs and they might not want a dirty block log, either. So lets say the follow get revdelled:
- Any block of a registered user, where the reviewing admin is unwilling to assert "I would have blocked this user myself".
- Any block of an unregistered user, where the reviewing admin is unwilling to assert "I would have blocked this user myself" and the user requests this.
- And all blocks of registered users (including new users) must be reviewed within X hours, or the user must be unblocked. No letting the block expire on its own; that leaves ambiguity in the block log. Suffusion of Yellow (talk) 19:12, 18 February 2022 (UTC)
- It appears that meta:User:Abuse_filter has been blocking people on meta since 2013. There must be thousands of blocks so far. Does anyone have time to do a spot check on meta:Special:Log/Abuse filter so see if any good faith meta users seem to have ever been blocked? Or, if that's too hard to figure out, has anyone returned from such a block and made some normal-looking edits? The average edit filter has lots of false positives, but User:Abuse filter, if it were allowed to block on *enwiki* as well as meta, would have to be well-nigh perfect to be tolerated for very long. I suppose you could restrict it to blocking IPs or new accounts who were not yet autoconfirmed. EdJohnston (talk) 19:16, 18 February 2022 (UTC)
- Even new users might get discouraged though, once they realize how people perceive blocks. For IPs, we have a few "long-termers" on stable IPs and they might not want a dirty block log, either. So lets say the follow get revdelled:
- That seems a fairly reasonable framing. Though I would say there's not a great number of existing disallow filters which target established users. There's be even fewer blocking filters. -- zzuuzz (talk) 18:57, 18 February 2022 (UTC)
- Just a tech note, abuseblocks can be set to target IPs, users, or both. Different block durations can be set for users and and ips, per rule. They can be short (e.g. on meta we have some that are just 2 hours). — xaosflux Talk 19:25, 18 February 2022 (UTC)
- I know you're asking for cons, but I guess personally I'm not sure for which filters this would be desirable. User:DatBot can report to AIV depending on certain trigger criteria, and AIV response times are usually ok. If it's only used on filters with only occassional hits I dunno if it's really worthwhile. ProcrastinatingReader (talk) 19:39, 18 February 2022 (UTC)
- My vote would be on something like Special:AbuseFilter/58 -- TNT (talk • she/her) 19:54, 18 February 2022 (UTC)
- There are indeed some things which reliably merit an instant block. I do think we should tackle a potential elephant in the room, which is the circumstances leading to this discussion (though it also works as a general query). Last night, for various reasons, we could have used an automated means of blocking a very rampant vandalbot. This type of melee, invasion, crapflood, or DDOS attack is where an automated block would excel (assuming the filter was got right). -- zzuuzz (talk) 20:31, 18 February 2022 (UTC)
- But only if we're willing to accept a large number of false positive blocks. That wasn't a "set it and forget it" bot; they were actively responding to the filters as we updated them, usually within minutes. I was just clicking "Save filter" and hoping for the best. If we have to test everything for days (or even hours), then they'll be ten steps ahead of us the whole time. Suffusion of Yellow (talk) 20:38, 18 February 2022 (UTC)
- I think in a similar situation the same rule of necessity would apply—we were doing a lot of untested filter changes during that attack, and having the ability for the filter to be set to block (after confirming a few good disallows) during that would have saved going around and mopping up the IPs. Although this certainly prompted my question, its not the real main benefit I see (given how rare those situations are..) -- TNT (talk • she/her) 20:43, 18 February 2022 (UTC)
- There are varying levels of certainty for some things. Back when there was 'anontalk' vandalism I think we had 4 filters running at a time, and 3 concurrent filters has certainly happened more recently. Like if there a vandalbot attack going on, and an IP makes 8 edits in 1 second, it's a vandalbot mkay. We'd just need different filters for different things. -- zzuuzz (talk) 20:57, 18 February 2022 (UTC)
- But only if we're willing to accept a large number of false positive blocks. That wasn't a "set it and forget it" bot; they were actively responding to the filters as we updated them, usually within minutes. I was just clicking "Save filter" and hoping for the best. If we have to test everything for days (or even hours), then they'll be ten steps ahead of us the whole time. Suffusion of Yellow (talk) 20:38, 18 February 2022 (UTC)
- There are indeed some things which reliably merit an instant block. I do think we should tackle a potential elephant in the room, which is the circumstances leading to this discussion (though it also works as a general query). Last night, for various reasons, we could have used an automated means of blocking a very rampant vandalbot. This type of melee, invasion, crapflood, or DDOS attack is where an automated block would excel (assuming the filter was got right). -- zzuuzz (talk) 20:31, 18 February 2022 (UTC)
- My vote would be on something like Special:AbuseFilter/58 -- TNT (talk • she/her) 19:54, 18 February 2022 (UTC)
- If I recall, there is an interface to allow EFMs to revert actions done by filters, which I *think* includes unblocking editors blocked by a filter. If this is the case, we should have some rules about the process for unblocking by a non-admin EFM - should unblock requests be left only to admins? If this is not the case, then there should be a process for a non-admin EFM to say "this wasn't meant to block, please unblock these ips/accounts" and this should be added as a supported exception to the rule that you can't generally request unblocks for others, Wikipedia:Appealing a block#Appeals by third party. DannyS712 (talk) 21:04, 18 February 2022 (UTC)
- Hm, in a bid to make things "simples", can't we just say "non-admin EFMs aren't permitted to do anything related to blocks" (enable/unblock, it'd be fine for them to disable the blocking action when urgent)? -- TNT (talk • she/her) 21:07, 18 February 2022 (UTC)
- By default, you need the
abusefilter-modify-restricted
user right to enable, modify, or disable a blocking filter. Currently, non-admin EFMs do not have this right. So would we give non-admin EFMs the right, but apply "social" restrictions on its use? Suffusion of Yellow (talk) 21:12, 18 February 2022 (UTC)
- By default, you need the
- Hm, in a bid to make things "simples", can't we just say "non-admin EFMs aren't permitted to do anything related to blocks" (enable/unblock, it'd be fine for them to disable the blocking action when urgent)? -- TNT (talk • she/her) 21:07, 18 February 2022 (UTC)