Wikipedia:Edit filter noticeboard
- Last changed at 03:42, 28 December 2024 (UTC)
Filter 614 — Pattern modified
- Last changed at 02:40, 28 December 2024 (UTC)
Filter 1182 — Flags: disabled
- Last changed at 23:53, 26 December 2024 (UTC)
Filter 1334 (new) — Actions: none; Flags: enabled,private; Pattern modified
- Last changed at 22:58, 26 December 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 334 enabled filters and 48 stale filters with no hits in the past 30 days. Filter condition use is ~1069, out of a maximum of 2000. ( ). See also the profiling data and edit filter graphs.
Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14 |
This page has archives. Sections older than 10 days may be automatically archived by Lowercase sigmabot III. |
Preventing unauthorized changes to edit filter configuration
[edit]Inexperienced users should not be making changes to Template:DatBot filters related to filters they may not be able to view, especially new or experimental filters that aren't stable, and there's potential for abuse by disruptive users. This is something I've been concerned about for a while. Generally, we would solve this with template protection or full protection, but that would prevent EFMs and EFHs from modifying the page, so I instead added a filter at 484 (hist · log). While this is a bit of a corner case right now, the runtime cost is very low, and I think there may be some similar use cases in the future. Daniel Quinlan (talk) 22:46, 26 November 2024 (UTC)
- I talked with DatGuy earlier, keeping him in the loop here. Daniel Quinlan (talk) 22:53, 26 November 2024 (UTC)
- I mean, feasibly template protection could work, the only problem that would be run into would be that all the (10?) non-admin EFMs would likely immediately request the template editor permission, which isn't a...bad idea (I've mentally floated proposing
editinterface
to eliminate the need for edit requests for filter messages, but frankly I don't have the confidence to put it up for an RfC given it would likely fail pretty badly, given it includes all the MediaWiki pages, not just the ones adding it would fix). Theoretically the granting guidelines are merely guidelines, and I can't think of a much better substitute for proof of technical experience than a community consensus showing such. EggRoll97 (talk) 23:37, 26 November 2024 (UTC)- Yeah, adding the
templateeditor
right to EFMs is another option. However, it's not worth proposing based on a single example (the proposal would also likely fail), especially when we have a workaround that addresses the immediate need. Daniel Quinlan (talk) 00:01, 27 November 2024 (UTC) - Most people don't edit that page, and the edit request process is always available too. — xaosflux Talk 17:41, 28 November 2024 (UTC)
- Yeah, adding the
- I wondered in the past if it would make sense that: Those who can't see private filters, can't add them to {{DatBot filters}}. I guess Daniel had the same idea. Nobody (talk) 06:23, 27 November 2024 (UTC)
- And FYI, there are no users that disruptively moved that edit filter configuration page, but it's better to be safe than sorry. Codename Noreste 🤔 Talk 21:19, 27 November 2024 (UTC)
- The page has been indefinitely fully move protected for several years. Daniel Quinlan (talk) 21:31, 27 November 2024 (UTC)
- I'll also just note that why we need to enforce pseudo-edit protection that goes beyond EC users (that do not hold edit filter privileges) is because of Special:Diff/1259682905. Codename Noreste 🤔 Talk 16:59, 28 November 2024 (UTC)
- A single unwanted edit? That's what revert is for. — xaosflux Talk 18:20, 28 November 2024 (UTC)
- No. That user added a private filter while they can't see private filters. Codename Noreste 🤔 Talk 19:02, 28 November 2024 (UTC)
- And? This section starts with the exciting title that this is needed to secure the "edit filter configuration" - this is a bot's page, it is not the configuration of the abusefilter. — xaosflux Talk 11:35, 2 December 2024 (UTC)
- No. That user added a private filter while they can't see private filters. Codename Noreste 🤔 Talk 19:02, 28 November 2024 (UTC)
- A single unwanted edit? That's what revert is for. — xaosflux Talk 18:20, 28 November 2024 (UTC)
- I'll also just note that why we need to enforce pseudo-edit protection that goes beyond EC users (that do not hold edit filter privileges) is because of Special:Diff/1259682905. Codename Noreste 🤔 Talk 16:59, 28 November 2024 (UTC)
- The page has been indefinitely fully move protected for several years. Daniel Quinlan (talk) 21:31, 27 November 2024 (UTC)
- And FYI, there are no users that disruptively moved that edit filter configuration page, but it's better to be safe than sorry. Codename Noreste 🤔 Talk 21:19, 27 November 2024 (UTC)
- I don't think we should be using the abusefilter as page protection for a single page. — xaosflux Talk 17:39, 28 November 2024 (UTC)
- Do you mean this as in "We shouldn't use an abusefilter for pseudo page protection" or "We shouldn't have a abusefilter for one specific page"? Nobody (talk) 18:42, 28 November 2024 (UTC)
- Both, but especially the later. Using it for an entire very broad class of pages is sometimes OK (e.g. the one against base userpages). — xaosflux Talk 10:48, 2 December 2024 (UTC)
- I agree with the later. With the former I'm not sure, since there isn't some kind of edit filter protection level. (And I don't think there will be, since a RfC about that would probably end with a bunch of "just become an admin and full protect it.") Nobody (talk) 11:59, 2 December 2024 (UTC)
- Yes, there are some very specific use cases where this could make sense- and that one that applies to 48 million+ pages is an example. — xaosflux Talk 13:38, 2 December 2024 (UTC)
- I agree with the later. With the former I'm not sure, since there isn't some kind of edit filter protection level. (And I don't think there will be, since a RfC about that would probably end with a bunch of "just become an admin and full protect it.") Nobody (talk) 11:59, 2 December 2024 (UTC)
- Both, but especially the later. Using it for an entire very broad class of pages is sometimes OK (e.g. the one against base userpages). — xaosflux Talk 10:48, 2 December 2024 (UTC)
- If we had a way to allow edits by EFMs (see above), I would be inclined to agree. Without this filter in place, the risk is too high. We're dependent on DatBot to report abuse to AIV and there's significant history of disruptive editors modifying configuration (in the last year: User:DatBot/Filter reporter/Run, User:MDanielsBot/AIVStop, User:Lowercase sigmabot III/Shutoff, User:ClueBot NG/AngryOptin, User:GreenC bot/button, and User:Yapperbot/kill/FRS). Some specific LTAs will similarly remove, or attempt to remove, page protection requests. I also don't believe this will limited to a single page in the future. I think we can let it grow organically, though. Daniel Quinlan (talk) 20:27, 28 November 2024 (UTC)
- In fairness, those are quite uncommonly abused. So long as there are editors which notice the bot isn't running (there will usually be, if the bot is doing a useful task) they should reactivate. The shutoff pages should be quite accessible so any editor can turn it off if something goes wrong - autoconfirmed/extendedconfirmed are decent barriers to abuse IME.
- Immediately, like xaosflux, I don't see any issues in the history of Template:DatBot filters to suggest ECP isn't working. (If there were, I would prefer to use templateeditor protection on the page, and give the TE userright to the very few non-admin EFMs that don't already have it.) ProcrastinatingReader (talk) 10:44, 2 December 2024 (UTC)
- This edit was an extended-confirmed user adding a private and experimental filter to the configuration (i.e., they had no idea what the filter did), while the filter was still being changed frequently. And nobody watching the page even blinked. Also, autoconfirmed is definitely not enough based on the history of those filters. For example, GreenC bot has been shut off twice recently by both an autoconfirmed user and an extended-confirmed user. Daniel Quinlan (talk) 17:12, 16 December 2024 (UTC)
- Do you mean this as in "We shouldn't use an abusefilter for pseudo page protection" or "We shouldn't have a abusefilter for one specific page"? Nobody (talk) 18:42, 28 November 2024 (UTC)
Per discussion above, I'd like to suggest disabling the filter and continuing to rely on ECP (or TE, if necessary) protection. Would that be OK with you, Daniel Quinlan? ProcrastinatingReader (talk) 10:19, 16 December 2024 (UTC)
- Maybe with an edit notice that warns users, that only those who can see private filters, should modify private filter listings and misuse can get them page blocked? Nobody (talk) 12:20, 16 December 2024 (UTC)
- Let me spend some time pursuing a user right solution. I've been occupied with some other edit filter priorities the last several weeks. Daniel Quinlan (talk) 16:55, 16 December 2024 (UTC)
- I concur that using an edit filter to enforce a kind of ghost protection for a specific page is a bad idea. * Pppery * it has begun... 21:38, 27 December 2024 (UTC)
- @Daniel Quinlan: I'm not seeing consensus above that this blocking filter is supported - any comments? — xaosflux Talk 23:24, 27 December 2024 (UTC)
- I think there are more pages that could be usefully covered by this filter, but I haven't had time to work on this more. I've disabled it. Daniel Quinlan (talk) 03:44, 28 December 2024 (UTC)
Implement my suggestion to filter 707?
[edit]Courtesy link from October: Wikipedia:Edit filter noticeboard/Archive 14#c-Codename Noreste-20241008081700-Update to filter 707.
See the following log entries for edit filter 707 that are users who tried to withdraw their own reports, but were prevented:
- Special:AbuseLog/39450648
- Special:AbuseLog/39427289
- Special:AbuseLog/39249126
- Special:AbuseLog/39122043
Therefore, I would propose the following update for 707:
New filter code for 707
|
---|
page_id == 26204397 /* [[WP:EFFPR]] */ & !("confirmed" in user_groups) & ( ( /* Prevent the removal or modification of headers */ contains_any( removed_lines, "__NONEWSECTIONLINK__", "__NOINDEX__", "<noinclude>", "{{Wikipedia:Edit filter/False positives/Header}}", "{{shortcut|WP:EF/FP/R|WP:EFFPR}}", "</noinclude>" ) ) | ( /* Page blanking or report meddling from non-confirmed users */ ( new_size < 300 & old_size > 300 | edit_delta < -250 ) & /* Allow users to withdraw their own report */ !( user_name in removed_lines & user_name in page_recent_contributors & edit_delta > -1500 ) ) ) |
Any questions or concerns regarding the new filter code? Thank you. Codename Noreste 🤔 Talk 04:18, 11 December 2024 (UTC)
- Like I said in the initial thread, I don't think users are going to be removing their reports very often. One of those is absolutely not a false positive, the others have abuse logs that show disruption to the encyclopedia, so there's not really a benefit to allowing these vandals to withdraw their report. Frankly, I don't see much of a point here. EggRoll97 (talk) 19:20, 11 December 2024 (UTC)
- And your code also has the ability to let users remove their title and potentially other reports, which is still a form of vandalism. I agree with EggRoll97 here that this change would probably be not needed. – PharyngealImplosive7 (talk) 20:29, 11 December 2024 (UTC)
- I officially withdraw my filter suggestion. Codename Noreste 🤔 Talk 21:31, 11 December 2024 (UTC)
- Anyway, keep in mind that this was my attempt to exclude duplicate EFFPR reports made by legitimate users while disallowing unexplained removals by vandals. However, for now it's not the time to implement this experimental code. Codename Noreste 🤔 Talk 02:09, 12 December 2024 (UTC)
- I officially withdraw my filter suggestion. Codename Noreste 🤔 Talk 21:31, 11 December 2024 (UTC)
- And your code also has the ability to let users remove their title and potentially other reports, which is still a form of vandalism. I agree with EggRoll97 here that this change would probably be not needed. – PharyngealImplosive7 (talk) 20:29, 11 December 2024 (UTC)
LTA check
[edit]Hey, would an EFM familiar with the LTAs being handled by filter 1094 give their input on whether this edit is likely the LTA being addressed with that condition? —Compassionate727 (T·C) 21:16, 13 December 2024 (UTC)
- It's just the addition of a filter-blacklisted source, and no it's not intended for any LTA. Codename Noreste 🤔 Talk 21:52, 13 December 2024 (UTC)
Redundant filter check
[edit]Line 73 of filter 1242 seems to check for the same string twice. Not going to be more specific than that because of the filter being hidden, but I assume this was unintended and can be fixed. —Compassionate727 (T·C) 19:57, 25 December 2024 (UTC)
Filter 602 and {{Welcome-arbpia}}
[edit]I think that it would be natural to log the {{Welcome-arbpia}} under filter No. 602, since it's a sort of a contentious topics notification that makes users aware of the topic area as well as restrictions within it. Currently, someone who checks the filter logs would miss when somebody is assigned the template, which could lead to redundant notifications. If we log this, it would be improved.
(Courtesy ping to ScottishFinnishRadish, who created the template.)
— Red-tailed hawk (nest) 05:06, 27 December 2024 (UTC)
- I think this would have to go through ArbCom because only {{Contentious topics/alert}} and {{Contentious topics/alert/first}} count as the "official" standardized awareness notices (i.e. simply using the welcome template does not make the user formally "aware") IIRC. C F A 05:28, 27 December 2024 (UTC)
- I had thought that they got rid of the super formal requirements for "awareness" when we moved from DS to CTOP. But looking at the language in CTOP, there is still some strictness for the first CTOP alert. Maybe it's worth a WP:ARCA to see if ArbCom is OK with this sort of thing. — Red-tailed hawk (nest) 05:57, 27 December 2024 (UTC)
- Probably not a bad idea. C F A 15:01, 27 December 2024 (UTC)
- That's why I normally drop the alert/first along with it, but that does work against the purpose of not BITING and flooding the talk page with a bunch of legalese. ScottishFinnishRadish (talk) 15:03, 27 December 2024 (UTC)
- In my mind, the obvious obstacle to it being considered sufficient for awareness is that it only mentions one of the three restrictions active in the area. —Compassionate727 (T·C) 20:29, 27 December 2024 (UTC)
- I had thought that they got rid of the super formal requirements for "awareness" when we moved from DS to CTOP. But looking at the language in CTOP, there is still some strictness for the first CTOP alert. Maybe it's worth a WP:ARCA to see if ArbCom is OK with this sort of thing. — Red-tailed hawk (nest) 05:57, 27 December 2024 (UTC)
- I think we should stick with considering that template an informal introduction. Perhaps /alert/first could be transcluded into the Welcome-arbpia template, so it's presented at the same time, which would allow it to be considered a CTOPS formal alert? That would satisfy the requirement that the specific template be used, and still present a summary picture of CT procedures, rather than legalese alone. EggRoll97 (talk) 02:39, 28 December 2024 (UTC)