Wikipedia:Edit filter noticeboard/Archive 13

Archive 10

Archive 11

Archive 12

Archive 13

Error

Elmira High School, Elmira, OR. Notable Alumni: Paddi Moyer, artisan, has several websites. She is legitimate. There’s no possible way to add her name and it is impossible to contact any of you. 50.45.245.19 (talk) 09:45, 8 March 2024 (UTC)

In order for her to be accepted as notable for the Notable alumni section, she needs to have a Wikipedia article. Nobody (talk) 09:49, 8 March 2024 (UTC)

No mention of the new guitar player Caleb Tucker 2600:1700:A170:3AF0:B0AE:7D02:4851:7C87 (talk) 23:38, 9 March 2024 (UTC)

Please read WP:BIO and WP:MUSIC notability guidelines. Having "several websites" does not address notability criteria. OhNoitsJamie ^Talk 23:51, 9 March 2024 (UTC)

/Requests' archive

As can be seen from the last 400 edits at Wikipedia:Edit filter/Requested, the bot has, since 9 September 2023‎, been archiving everything into Wikipedia:Edit filter/Requested/Archive 4 - this appears to be because of <this change> by @EEng.
Should something be done about that? There are 21 archives.
Note that I'm posting this here because the talk page for /Requests redirects here. – 2804:F14:809E:DF01:1968:B0BD:7883:4C14 (talk) 22:41, 18 March 2024 (UTC)

All I did was increase the max size of the archive pages. Why that caused it to jump to Archive 4 is beyond me. EEng 04:34, 19 March 2024 (UTC)

Cluebot has its |numberstart= set to 4 (it doesn't use a counter system like {{User:MiszaBot/config}}, rather I think it figures out where it should archive every time), and since the archive size was increased enough to allow it to archive to the 4th archive, it did. Probably worth moving everything that ended up in 4 to 21 or 22 and upping numberstart. Aidan9382 _(talk) 06:53, 19 March 2024 (UTC)

 Done EggRoll97 ^(talk) 04:35, 20 March 2024 (UTC)

Over the condition limit

Unless I'm missing something, it seems we're currently over the 1k condition limit (graph)? Though it doesn't seem any edits have been tagged as breaching the limot here ProcrastinatingReader (talk) 10:12, 2 April 2024 (UTC)

Ah, indeed I am missing something (phab) -- the limit is now 2k :) ProcrastinatingReader (talk) 10:17, 2 April 2024 (UTC)

Yep, "data expands to fill available space". No harm in doing a bit of pruning if you see anything stale. Suffusion of Yellow (talk) 23:20, 2 April 2024 (UTC)

Edit filter helper nomination for 1AmNobody24

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.

---

1AmNobody24 (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · fm · mms · npr · pm · pcr · rb · te)}

The earliest closure has started. (refresh)

For those of you that do not know him, 1AmNobody24 has been quite an active patroller of EFFPR spanning a little more than 700 edits in the past few months, and he would be a great asset to the edit filter team in order to review false positives that involve private filters, and to assist with improving and creating private filters. Some of his suggestions include Wikipedia:Edit filter noticeboard/Archive 12#Filter 1112, and Special:Permalink/1211462999#Improving Filter 1045.

Outside of edit filters, he does a great job of reverting obvious vandalism and spam, has decent UAA, AFC, CSD and SPI logs, fixes references (including but not limited to bare URLs, CS1 errors), adds wikilinks, and has signed the confidentiality agreement for nonpublic information per this diff on Meta.

Thank you for your consideration in whether or not you want to support him. Codename Noreste 🤔 talk 17:00, 25 March 2024 (UTC)

Candidate, please indicate acceptance of this nomination here: I accept this nomination. Nobody (talk) 17:16, 25 March 2024 (UTC)

---

• Support as the nominator. Codename Noreste 🤔 talk 17:00, 25 March 2024 (UTC)
• Support: Trusted user who has a clear need. – PharyngealImplosive7 (talk) 18:05, 25 March 2024 (UTC)
• Oppose Weak support: I'm slightly concerned by this, as non-EFH/EFM/sysop should not generally be actioning reports involving private filters, regardless of how obvious the result may be. The key problem is that the person responding doesn't have access to all relevant logs, nor access to the necessary filters to check the report in full. A similar idea applies to this one. While I think they could be responsible with EFH, I'm not a fan of granting it to someone who recently (within 2 months and even 1 month) has shown to be actioning reports as described. EggRoll97 ^(talk) 21:50, 25 March 2024 (UTC)

  @EggRoll97 I agree that most private filter hits should not be actioned by non-EFH/EFM, but those two reports I can easily explain why I responded. The first one one triggered the Rapid disruption private filter and filters 61 and 636 in the same attempt. When looking at the public filters hits, one can see the obvious reason why that attempt is disruptive. The second report is also for an attempt thar hit both a private and a public filter. By looking at the public hit, one can easily see what part got hit for looking like a email. These were both obvious cases of disruptive attempts and even if I don't see the private filters it's obvious that the hits weren't false positives. Nobody (talk) 05:27, 26 March 2024 (UTC)

  I don't necessarily agree with that line of thought, but I find myself leaning neutrally. EggRoll97 ^(talk) 20:44, 26 March 2024 (UTC)

• Support: They have demonstrated the need, and I trust them with EFH.– DreamRimmer (talk) 13:06, 28 March 2024 (UTC)
• Support has continuous involvement with filters with technical contributions. 0xDeadbeef→∞ (talk to me) 13:55, 28 March 2024 (UTC)
• The earliest closure has started. Would someone mind granting the perm as it seems that consensus agrees to grant? – PharyngealImplosive7 (talk) 17:39, 28 March 2024 (UTC)
•  Comment: WP:EFH only talks about requesting the right for yourself, nothing about nominating others. This feels like it misses the candidate's own statement on why they want the right (even if it's obvious). That said, this reads like it was made using a template, so is this just undocumented? (Also the confidentiality agreement diff link is broken, as I've mentioned, please fix that) – 2804:F1...01:18F4 (talk) 21:02, 28 March 2024 (UTC)

There is a tradition of nominating others, even if it isn't written down on the guidelines. About the statement on why they want the right, I don't really know if it is needed in this case but it could be. – PharyngealImplosive7 (talk) 21:26, 28 March 2024 (UTC)

I'll also concur that it doesn't matter too much if they nominate themselves, so long as they're available to answer questions from others. Ultimately the test that is applied is whether the candidate can be trusted, and while self-nominations are fully acceptable, some also like the reassurance that comes from a nominator. Also, confidentiality noticeboard diff updated. (I hope you don't mind my fixing that diff, @Codename Noreste:.) EggRoll97 ^(talk) 22:34, 28 March 2024 (UTC)

About fixing that diff, I've did that so marked as  Done; we're still awaiting an uninvolved admin to grant the role to the nominee. Codename Noreste 🤔 talk 23:27, 28 March 2024 (UTC)

In addition to that, I have some of my own comments to say of what I've learned despite my two failed nominations:

• Regardless if they're obvious or not, I also agree that reports that only involve private filters should be left to the ones that can view such log entries. I believe I have learned that the hard way.
• Despite so many responses, account age probably matters (almost two years or more is recommended).
• I'm not going to use scare quotes anymore as somebody mentioned, including if it's in the edit or summary.

Codename Noreste 🤔 talk 23:42, 28 March 2024 (UTC)

Just a tip. the {{tq}} template is usually used which is usually considered more friendly than quotes (Example vs "Example") 0xDeadbeef→∞ (talk to me) 02:08, 29 March 2024 (UTC)

Understood, and I will give myself a year at most to address these issues. In addition, I have written and proposed a filter by emailing its conditions to an EFM (1292 to be exact). Codename Noreste 🤔 talk 02:25, 29 March 2024 (UTC)

---

•  Done per consensus above. — xaosflux ^Talk 15:00, 29 March 2024 (UTC)

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.

Edit to filter 54

Their are a few promotional accounts whose names have 'corporations' in them instead of simply 'corporation' which is currently filtered out. I suggest that we should change the syntax to also log these accounts. We could change the related part of the regex to CORP(?:S?.?$|ORATE|ORATIONS?\b). – PharyngealImplosive7 (talk) 00:29, 31 March 2024 (UTC)

Courtesy ping to Oshwah as the last editor to modify filter 54. Codename Noreste 🤔 talk 00:40, 31 March 2024 (UTC)

Hi PharyngealImplosive7! I'll implement your suggestion. Stand by... ~Oshwah~^{(talk) (contribs)} 02:52, 2 April 2024 (UTC)

PharyngealImplosive7 -  Done. ~Oshwah~^{(talk) (contribs)} 02:57, 2 April 2024 (UTC)

Thanks! – PharyngealImplosive7 (talk) 03:07, 2 April 2024 (UTC)

Filter 1162

I came across filter 1162, and I am wondering why there are no actions taken when the filter is triggered. Seems like this should be tagged at the very least. GrayStorm^{(Talk|Contributions)} 22:54, 3 April 2024 (UTC)

For now, I don't think that tagging non-admins placing block templates are necessary. Logging only works fine. Codename Noreste 🤔 talk 03:14, 4 April 2024 (UTC)

Ok GrayStorm^{(Talk|Contributions)} 20:00, 4 April 2024 (UTC)

Searching within filter code

Has anyone else had any problems with searching in filter code (as in, ctrl + f and no search box appearing)? I've tried clicking inside the code then pressing Ctrl+F, tried looking at different filters, tried restarting my computer, nothing. I don't think it's a script issue either, since I tried enabling safemode as well, and that didn't fix it, nor did trying to open the filter in an incognito window. Anyone know if maybe a recent update removed the ability or broke it? EggRoll97 ^(talk) 05:04, 4 April 2024 (UTC)

Generally speaking, ctrl+f is usually controlled by the browser, unless specifically overridden by the web page, for example in the case of visual editor. Are you just viewing a filter or trying to edit it? Can you link to a page giving you the problem? What skin and browser are you using? –Novem Linguae (talk) 05:23, 4 April 2024 (UTC)

Just viewing, haven't had the EFM bit toggled on (yet, still about 19 hours left on that one). I've tried Special:AbuseFilter/3, Special:AbuseFilter/12, and Special:AbuseFilter/11, among others, though it seems to affect every filter. I haven't had any problems previously with Ctrl+F searching in the filter while viewing before, and my normal Ctrl+F works fine (but it doesn't search the filter code, only the filter notes and anything else on the page). I'm on Chrome 123.0.6312.106, and it says it's the newest version. Skin is Vector legacy (not 2022). EggRoll97 ^(talk) 05:47, 4 April 2024 (UTC) Ignore my rampant stupidity, it appears the normal Ctrl+F actually now searches the filter code too (it didn't used to, as far as I could tell). EggRoll97 ^(talk) 05:52, 4 April 2024 (UTC)

The Ace editor does intercept CTRL-F, so long as you've focused on it first. At least, it's supposed to. Instead I get: The resource from “https://en.wikipedia.org/w/extensions/CodeEditor/modules/ace/ext-searchbox.js” was blocked due to MIME type (“text/plain”) mismatch (X-Content-Type-Options: nosniff). But oddly it does work on JavaScript pages. Suffusion of Yellow (talk) 19:25, 4 April 2024 (UTC)

Interesting. I did a search among pages in the WP/Module/Template/MediaWiki namespaces, and nothing exact came up for "ext-searchbox.js" other than this page. Searching Phabricator brings up T251545, not necessarily for the AbuseFilter, but looks like that was a problem a while ago as well, but it was closed as invalid. EggRoll97 ^(talk) 21:18, 4 April 2024 (UTC)

Edit filter manager for EggRoll97

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.

---

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

Hello all. I am presenting myself here to the community today to request that I be granted edit filter manager rights as a non-administrator. I've thought about this for a bit, and it's 0xDeadbeef's response to my request for a bit of advice and his encouragement of boldness here that has pushed me to bite the metaphorical "bullet", so to speak, and write this up. (As a side note, I've hovered over the publish changes button now for about an hour, uncertain if everything is perfect yet.)

Edit filter managers need demonstrated competency with the edit filter to be considered, as well as being trusted by the community to safely utilize the edit filter. As for trust, it's largely a factor that differs by person, though I of course will present that I have been an edit filter helper handling private filters for just over four months now without spilling the beans, and have signed the confidentiality agreement for non-public information (see m:Special:Diff/20180422). For technical competency, I have attached a few links below for both public and private filter changes I have requested. I've attempted to summarize the private filter changes as best I can without compromising private filter integrity.

Public filter changes:

Direct proposal for edits to a filter, implemented with modifications

Not a direct proposal for editing, but discussion about what could be done to reduce the false positive probability

Private filter changes:

A filter concern about problems with excessive matching

Some suggested improvements to an existing filter of simple changes

General changes to a filter to avoid false positives from it on innocent edits

Further, I have also passed by more than a few false positives reports that had small changes proposed to the filters that just needed an EFM to make them. This is something I would plan to work on a lot if granted the userright. The EFM right would also allow me to use filters filter 1 (public testing) and filter 2 (private testing) which can be more efficient than Special:AbuseFilter/test as it only tests the last 100 edits (though User:Suffusion of Yellow/FilterDebugger works wonders). I plan to extensively test any edit filter changes I implement, and with new edit filters as applicable, enable on log-only until fine-tuning has kept the false positive count to a low and reasonable degree. I am aware of the confidentiality expectations applicable to the private filters, and am aware of the extensive damage that edit filters can cause if recklessly implemented. I thank you for your consideration, and am fully open to and will respond to any questions and queries as applicable. EggRoll97 ^(talk) 00:11, 29 March 2024 (UTC)

---

• Question: what type of public and/or private filters do you intend to create using your knowledge of regular expressions and edit filter syntax other than filters 1 and 2? Codename Noreste 🤔 talk 00:27, 29 March 2024 (UTC)

@Codename Noreste: I'd likely take inspiration from the requests at Wikipedia:Edit_filter/Requested, though I believe the bulk of my contribution would come through fine-tuning existing filters based on false positives and filter history. We do, after all, already have a massive number of filters, so I'd be more likely to test changes to an existing filter and merge them in when properly vetted, then to create a new filter, if possible. For reference, at the time of writing, we have over 300 enabled filters. (314, to be exact.) To answer your question directly though, I'd probably start by enabling Wikipedia:Edit_filter/Requested#No_rcats? in log-only and monitoring. EggRoll97 ^(talk) 00:35, 29 March 2024 (UTC)

EggRoll97, I can also email you a new proposed (and private) filter early if there might be consensus to promote you to EFM. Codename Noreste 🤔 talk 00:38, 29 March 2024 (UTC)

@Codename Noreste: Since it's a private filter request, if you send it to the mailing list, I can take a look at it alongside the other EFHs and EFMs. EggRoll97 ^(talk) 00:40, 29 March 2024 (UTC)

… and emailed! I'm waiting for my request to pass moderator approval. Codename Noreste 🤔 talk 00:50, 29 March 2024 (UTC)

May sound somewhat off-topic, but it would be useful if you are a moderator of that edit filter mailing list who can accept or deny (and respond to) requests. Codename Noreste 🤔 talk 00:52, 29 March 2024 (UTC)

• Support. Good technical ability and experience. Will be a positive addition to the EFM team. 0xDeadbeef→∞ (talk to me) 02:09, 29 March 2024 (UTC)
• Support per 0xDeadbeef. I’ve seen them edit and test filters on a test wiki, and I am confident that they will not cause intense disruption to thousands of editors. Codename Noreste 🤔 talk 02:31, 29 March 2024 (UTC)
• Support. Seems capable and trustworthy. – PharyngealImplosive7 (talk) 17:09, 29 March 2024 (UTC)
• Support There are no red flags. They have a good track record and technical ability. – DreamRimmer (talk) 18:02, 2 April 2024 (UTC)
• OK, no objections here (I rarely enthusiastically support anything so consider that a positive). -- zzuuzz ^(talk) 18:39, 2 April 2024 (UTC)
• Support looks good to me --DannyS712 (talk) 00:56, 3 April 2024 (UTC)

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.

Mark filter 1157 as public?

Per Wikipedia:Edit filter noticeboard/Archive 10#1157, I agree that I'm not sure if we have to keep 1157 (hist · log) private, since the filter only logs non-admins/clerks/CheckUsers tagging sockpuppets. Any objections if this filter was to be marked as public to maintain consistency with 1170 (hist · log)? Thanks. Codename Noreste 🤔 talk 23:38, 1 April 2024 (UTC)

Courtesy pings: @TheresNoTime and Blablubbs: -- zzuuzz ^(talk) 08:43, 2 April 2024 (UTC)

Sounds reasonable to me, but I'll defer to Blablubbs — TheresNoTime (talk • they/them) 08:57, 2 April 2024 (UTC)

Thanks for the ping; I don't see any reason to keep it private. --Blablubbs (talk) 09:23, 2 April 2024 (UTC)

Me neither. Plus the history doesn't seem to contain anything private. [Insert delay for any further comments]. -- zzuuzz ^(talk) 09:52, 2 April 2024 (UTC)

Also support on making it public. EggRoll97 ^(talk) 17:37, 2 April 2024 (UTC)

Okay, if there are no objections before then I'll made the filter public on 5 April 2024 (based on UTC) so in just under 48 hours, giving a further delay in case there are others who haven't seen this thread yet (which I think is what zzuuzz was suggestion) --DannyS712 (talk) 00:53, 3 April 2024 (UTC)

CC other users who have edited the filter: @L235, @Tamzin, @Oshwah, @Galobtter --DannyS712 (talk) 00:54, 3 April 2024 (UTC)

No objections from me; make it public. :-) ~Oshwah~^{(talk) (contribs)} 01:06, 3 April 2024 (UTC)

No objections. Best, KevinL (aka L235 · t · c) 01:14, 3 April 2024 (UTC)

 Done, now public: Special:AbuseFilter/history/1157/diff/prev/31865 --DannyS712 (talk) 01:34, 5 April 2024 (UTC)

Is there any reason why block-autopromote is unavaliable?

Just a random thought, but I randomly found MediaWiki:Abusefilter-autopromote-blocked, which I believe blocks you and disallows the edit. However, we don't use on this wiki at least because it is "unavailable" for some reason. Any idea why? – PharyngealImplosive7 (talk) 01:15, 30 March 2024 (UTC)

@PharyngealImplosive7: It's not really "unavailable". It's available, and used on a few projects if I remember correctly, but it's considered a restricted action because if someone does something that merits that, they probably should just be blocked by an admin instead. The filters also don't auto-block because the idea in this project is that all blocks should be made by an admin, similarly to how userrights should be managed by admins in the community's view. It was discussed somewhere if I recall correctly. EggRoll97 ^(talk) 01:19, 30 March 2024 (UTC)

I think the message was more about autopromotion being blocked? It would revoke or prevent them to be autoconfirmed 0xDeadbeef→∞ (talk to me) 01:21, 30 March 2024 (UTC)

@0xDeadbeef: @EggRoll97: When you put it that way, it makes more sense and blocking someone from getting the confirmed right does indeed seem kind of extreme. – PharyngealImplosive7 (talk) 01:26, 30 March 2024 (UTC)

Correct. There isn't an automated edit filter action that blocks the user from editing. This template refers to when the "Prevent the user from performing the action in question" and "Revoke the user's autoconfirmed status" actions are used within an edit filter. ~Oshwah~^{(talk) (contribs)} 03:01, 2 April 2024 (UTC)

Just a thought, but this might be useful for something like filter 68 (hist · log), that throttles page moves and might revoke autoconfirmed from page move vandals? This is just an assumption because I can’t see the private filters and it seems that disallow and throttle work just fine because this hasn’t been brought up recently as far as I know. Again, this is just a thought and it’s fine if it doesn’t work for some reason. – PharyngealImplosive7 (talk) 18:27, 5 April 2024 (UTC)

I don't think blocking autoconfirmed promotion for a few days is a good idea; if we do this, we need to warn the user first that attempting the page move again may result in their autoconfirmed status being revoked. Throttling and disallowing page moves seem to work fine. Codename Noreste 🤔 talk 20:11, 5 April 2024 (UTC)

Yeah that’s what I thought. I totally agree with you. – PharyngealImplosive7 (talk) 20:45, 5 April 2024 (UTC)

Page-move vandalism isn't as much of a thing these days, though every now and then someone goes on a spree. Most (but not all) of the filter 68 hits look more like clueless people fumbling around and making a mess. Probably good that we slow them down, but this certainly isn't enough of a problem to justify such drastic measures. Suffusion of Yellow (talk) 00:13, 6 April 2024 (UTC)

FWIW it looks like it's been used a few times in public filers:

Extended content

MariaDB [enwiki_p]> select afh_filter,afh_timestamp from abuse_filter_history where afh_actions like "%blockautopromote%" order by afh_timestamp desc; +------------+----------------+ | afh_filter | afh_timestamp | +------------+----------------+ | 1028 | 20200212151256 | | 201 | 20120810005233 | | 201 | 20120810005150 | | 201 | 20110916071759 | | 201 | 20110827000025 | | 201 | 20110306091844 | | 201 | 20110306091603 | | 1 | 20091203195833 | | 1 | 20091203195531 | | 54 | 20090318191118 | | 54 | 20090318190355 | | 54 | 20090318190101 | | 54 | 20090318185315 | | 54 | 20090318183632 | | 54 | 20090318183119 | | 54 | 20090318175241 | | 1 | 20090318012627 | +------------+----------------+ 17 rows in set (0.044 sec)

The 2020 use was definitely a mis-click. I don't know how to search the private filter history short of sceen-scraping Special:AbuseFilter/history. Suffusion of Yellow (talk) 00:31, 6 April 2024 (UTC)

I believe the most famous use of blockautopromote, and why there might or should be some nervousness about people using it today, indeed it's a lesson for all time, can be found in the earliest logs of filter 58.[1] Public version starts approximately here -- zzuuzz ^(talk) 00:53, 6 April 2024 (UTC)

An example linked from somewhere else^{(from here)}, just for curiosity: 10:51, 31 May 2010 – 2804:F1...17:B3C2 (talk) 01:50, 6 April 2024 (UTC)

Ah nvm, zzuuzz's link had a bunch, just have to remove the &wpSearchFilter=58 part of the link. – 2804:F1...17:B3C2 (talk) 02:01, 6 April 2024 (UTC)

Here is an analysis of public filter uses of the action. As seen here, block-autopromote was used for some sort of LTA again just for curiosity. It was also just used for some tests and to block page move vandals. – PharyngealImplosive7 (talk) 02:49, 6 April 2024 (UTC)

Extending time for EFH discussions

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.

---

Historically, EFH has been considered a relatively high trust role. I appreciate opinions on this can vary, and so the "need" to grant has been decided by precedence at this board, and evaluated on a case-by-case basis. Since we do not evaluate EFH discussions against a set criteria (like we do TE in Special:Permalink/1215492787, for example), participation is quite important.

Since many editors in the edit-filter community aren't around every day, to maximise participation, I'd like to suggest we extend the time for EFH discussions to the standard 7 days. ProcrastinatingReader (talk) 12:18, 30 March 2024 (UTC)

If we'd want participation, we need to formulate explicit requirements for how many !votes are needed as minimum participation. A low participation pass for EFH was actually me from a year ago with only 4 support. 0xDeadbeef→∞ (talk to me) 12:23, 30 March 2024 (UTC)

Though if you count EFH/EFM !votes differently, I suppose it would be different.. 0xDeadbeef→∞ (talk to me) 12:29, 30 March 2024 (UTC)

I think that determination may be up to the closer. I personally wouldn't say it's low participation simply because your request had support from SoY, zzuuzz, Compassionate727 and Red-tailed hawk. It was obviously passing even if left open for more comments. That's in part because the number of active EFMs was quite small, and those two have been persistently dedicated to filters. But also in part because SoY and zzuuzz have criteria which I think roughly matches this board's criteria holistically. As a combination of both factors, I personally would tend to trust their judgement on a request, and I imagine others here do too. ProcrastinatingReader (talk) 12:32, 30 March 2024 (UTC)

I don't think low participation is really a thing on this noticeboard. It's a very small community of people that have the desire and technical knowledge to modify the filters. There are millions of accounts on this site. Of those, 864 at the time of writing are administrators. A lot of the edit filter managers are admins, and didn't go through a consensus !vote on EFN, but rather self-granted as admins. Depending on their interests, they may or may not be involved in edit filters to a deep degree, they may have just given themselves the bit for one edit and forgotten to take it off. Out of the 139 EFMs, I counted at one point and a little over 10 aren't admins. Next, there are 23 edit filter helpers. That means overall, there are maybe 30 non-admins plus a few unflagged who are involved in edit filters. Add in the few admins who are also involved here, and we maybe have 40-50 people in the edit filter "community". I'm sure my count is probably a bit off, but those who toil and tinker with the edit filters aren't a large community, so unless there's serious concerns about someone as a candidate, I don't see that much of a problem with low participation. EggRoll97 ^(talk) 15:56, 30 March 2024 (UTC)

I guess on this note, it's worth also considering the topic Barkeep49 brought up on the talk page regarding nominations for EFM rights. ProcrastinatingReader (talk) 12:25, 30 March 2024 (UTC)

It'd be real nice to stop these third party nominations for both EFH and EFM, at least those that are absent the nominee providing a few sentences of why they need the role or what benefit they can bring. The request for 1AmNobody24 passed without any writings from them besides a four word acceptance and a response to a specific point brought up in an oppose !vote. I'm sure some rationale was included in Codename Noreste's nomination after the two of them had a discussion who-knows-where, but we should really be hearing from the nominees themselves in these discussions.

And EFH discussions should indeed be open for at least seven days. Uhai (talk) 13:48, 30 March 2024 (UTC)

Totally agreed. This is a process where it makes sense that self-noms are a norm.

Extending EFH to seven days also makes sense as we have not failed to process the backlog. The need for EFH will be decreased for each additional EFH we take. 0xDeadbeef→∞ (talk to me) 14:07, 30 March 2024 (UTC)

I don't see any objections of extending EFH nominations to a week, but only self-nominations are allowed? Codename Noreste 🤔 talk 14:27, 30 March 2024 (UTC)

well, what is the reason we should allow third-party noms? 0xDeadbeef→∞ (talk to me) 14:29, 30 March 2024 (UTC)

I don't see any reason not to allow third party nominations, is that EFH nomination for 1AmNobody24 the last third party nomination a user may do? Codename Noreste 🤔 talk 14:31, 30 March 2024 (UTC)

If there is consensus to disallow. The reason for not allowing third-party noms has been said above: we should really be hearing from the nominees themselves in these discussions. 0xDeadbeef→∞ (talk to me) 14:55, 30 March 2024 (UTC)

Oh, I see. I also don't see any objection to not allow third party nominations, but we are going to need consensus for that and to extend the EFH nomination for one week, just like running for EFM. Codename Noreste 🤔 talk 15:21, 30 March 2024 (UTC)

I'd also like to introduce another possibility where non self-noms are allowed but the nominee must also add a few extra sentences at least with some sort of rationale so we can hear from them too. – PharyngealImplosive7 (talk) 00:04, 31 March 2024 (UTC)

For example, this might include: it's 0xDeadbeef's response to my request for a bit of advice and his encouragement of boldness here that has pushed me to bite the metaphorical "bullet". Codename Noreste 🤔 talk 00:41, 31 March 2024 (UTC)

• Support amending earliest close time to 1 week for efh. In the future may also want to consider requiring at least one bolded !vote from an efm. No efm participation, or low efm/efh participation in the discussion, suggests to me that the discussion should be open longer so those folks can chime in. –Novem Linguae (talk) 15:41, 30 March 2024 (UTC)

  A self-nom rule also seems fine to me. –Novem Linguae (talk) 16:22, 30 March 2024 (UTC)

• Support on extending to one week, and on requiring self-noms. I don't think third-party nominations are really very helpful here. EggRoll97 ^(talk) 15:56, 30 March 2024 (UTC)
• Per the discussion above the two supporting votes, I support both the one week extension and the self-nomination requirement. Codename Noreste 🤔 talk 16:02, 30 March 2024 (UTC)
• Support both the only self-noms (unless the nominee also gives some sort of rationale) and the extension to 1 week. – PharyngealImplosive7 (talk) 16:08, 30 March 2024 (UTC)
• Support both extending to 1 week and only self-nominations(for EFH and EFM), more opportunity for input from people who aren't here so often can only do good, and self-noms are easier than having to coordinate third-party nominations with the candidate so they can provide rationale. – user in the /32 - currently 2804:F1...54:171E (talk) 22:45, 30 March 2024 (UTC)
• Support one week. I also think we need a statement from any applicant, and I'll just say that I don't like 3rd party nominations for this role. Just ask for a support statement instead. (I can vaguely imagine scenarios where some highly experienced user might want to introduce an application, but it can probably be done with just a supporting statement). I'd also support some type of quorum, though I think admins closing these applications should probably know what they're doing here, and not rush to close something just because it's past the due date. Being a minor venue, I think admins should be using a wide discretion when it comes to process here. In a sense, the closing admin also needs to be a supporter and not just a closing-bot, which should add to the quorum. -- zzuuzz ^(talk) 00:23, 31 March 2024 (UTC)

  If your changes pass, such as adding a quorum, someone should also update the policy on these elections as they will be quite out of date otherwise. – PharyngealImplosive7 (talk) 00:46, 31 March 2024 (UTC)

• Support one week earliest closure --DannyS712 (talk) 06:19, 31 March 2024 (UTC)

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.

Filter 1291

Would it be possible to add a check for {{pagelinks|Example Article Name}} to 1291 (hist · log)? This would allow it to catch edits like Special:Diff/1217679181 (where one instance of Example Article Name still needs replacing), in addition to edits like Special:AbuseLog/37383189. Pinging DannyS712 as the filter’s creator.

All the best. ‍—‍a smart kitten_[meow] 18:01, 7 April 2024 (UTC)

@A smart kitten  Done Special:AbuseFilter/history/1291/diff/prev/31935 --DannyS712 (talk) 18:12, 7 April 2024 (UTC)

New report to check before going to EFR

Please check out User:Suffusion of Yellow/Commonly reverted words and phrases. Still working out the details, but likely any drive-by vandalism "worth" filtering will be there. Let me know what needs explaining. Suffusion of Yellow (talk) 23:19, 2 April 2024 (UTC)

That's great! Will be useful when some of these inevitably come up at WP:EFR. Philipnelson99 (talk) 20:41, 8 April 2024 (UTC)

Filter 1301

Filter 1301 (hist · log) has been recently created by an admin to prevent users from editing other users' committed identity templates on user pages, but I noticed some possible issues:

1. The !"sysop" in global_user_groups condition should either be changed to !("steward" in global_user_groups) or removed; the former global group doesn't actually exist at all.
2. The generic disallow message should either be changed or removed, since it can be bitey to newer users and irritating to experienced users.

Any opinions or suggestions? Thank you. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 02:08, 12 April 2024 (UTC)

cc Daniel Quinlan –Novem Linguae (talk) 02:40, 12 April 2024 (UTC)

Was this in response to some specific incident? I don't see the need for a filter here; the only people verifying committed identities should be WP:T&S, and I'd hope they check the page history to see who added the template. Suffusion of Yellow (talk) 03:38, 12 April 2024 (UTC)

I added it in response to this page protection request. I also hope T&S runs WikiBlame (or something similar) to find the edit that added an identity when handling requests as well, but "hope" isn't exactly a description of defense in depth. Daniel Quinlan (talk) 03:53, 12 April 2024 (UTC)

Filters aren't really security measures. A truly determined person could find a way around any of them. (I will email you one trick if you're curious.) Now that would be very difficult, but we're talking someone capable of conducting a social engineering attack against the T&S team of a ton-ten website. We're not talking about a drive-by vandal. What is a security measure is the protection against editing .js and .css pages; if Aditya-an11 doesn't want anyone editing their committed identity or GPG key, they can wrap it in /* ... */ and put it at something like User:Aditya-an11/key.js. There are also several BEANSy ways in which this filter could be exploited by vandals. Again, I'll email you if you're curious. Suffusion of Yellow (talk) 04:19, 12 April 2024 (UTC)

I don't think they have email enabled, so they'll have to email you instead. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 04:25, 12 April 2024 (UTC)

I already have his email, and just sent one. But I said "One weird trick" in the subject, so it probably got spam-filtered... Suffusion of Yellow (talk) 04:41, 12 April 2024 (UTC)

@Suffusion of Yellow, I haven't received your mail. I am quite unsure on how I didn't got the mail - I have enabled email in my preferences. Could it be that I am a new user?

Anyways, as I have mailed you -- as directed by @Codename Noreste. Aditya-an11 (talk) 07:28, 12 April 2024 (UTC)

@Aditya-an11 pretty sure Suffusion was talking about emailing Daniel Quinlan, not you. – 143.208.238.195 (talk) 08:20, 12 April 2024 (UTC)

Sorry, my bad. I have crossed it out Aditya-an11 (talk) 08:58, 12 April 2024 (UTC)

@Aditya-an11: Responding to your email, there isn't much you can do to protect against someone who has access to your account from modifying the page. Full protection won't really work; if the attacker says "Hey, I need to update my key, can you unprotect the page for bit" it's highly unlikely any admin would argue. You'll just have to trust that whoever is verifying your identity is clueful enough to check timestamps. Suffusion of Yellow (talk) 18:20, 12 April 2024 (UTC)

And I just realized that if the account is compromised, the attacker "is" the victim as far as MediaWiki knows, and will of course bypass the filter. If you plan on using anything in your userspace to prove your identity after a compromise, you'd better, again, hope, that someone goes looking for the oldest edit. Suffusion of Yellow (talk) 04:45, 12 April 2024 (UTC)

But the only things I have are that I have my committed identity listed on my local and global user pages (I've recently updated it minutes ago), and my account has a very strong password and has 2FA enabled globally.

Only my alternate account has a very strong password but can only be used in an emergency or in unsecure areas where I can't access my main. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 04:52, 12 April 2024 (UTC)

The point is that if someone gains your password and 2FA secret, and then they change your committed identity, this will be recorded as an edit coming from you. The only thing that will be sus is the fact that "you" changed "your" identity recently. If T&S has to distinguish between two people both claiming to be you (if only Brian had known about cryptographic hashes...), it's the oldest hash that they'd have to look at. Suffusion of Yellow (talk) 05:06, 12 April 2024 (UTC)

If the user has additional permissions, Wikipedia is definitely impacted. I'll respond to your email tomorrow or this weekend. Thanks for the additional context. Daniel Quinlan (talk) 05:38, 12 April 2024 (UTC)

This is a big drawback that I think this filter has. Not to mention that @Suffusion of Yellow believes that these filters could be exploited by vandals. And this is concerning to me....

Sure, the filter seems to provide basic protection, but I feel this fails when my account gets breached OR the person who is vandalising have apt technical knowledge to exploit it. Going by the case of Wikipedia:Wikipedia Signpost/2007-05-14/Committed identity, both the situation are probably.

These security concerns was partly what prompted me to ask for full page protection in the first place. "Full" as in even if a vandal gets access to my account, they can't edit the my committed-identity page. Only the admins can. And that's way more reassuring and secure than the filter. While I do understand this may not be common, I do see people page protecting their committed identity pages (like Gwern to which I cited here). Though, in all fairness, I am a new user and could be wrong. I would be happy if get any guidance on how to maturely approach this issue. Aditya-an11 (talk) 07:49, 12 April 2024 (UTC)

Thanks, steward is the appropriate group, I'll update the filter. As far as the message goes, this filter should almost never match, but I'm open to suggestions. Also, if the default disallow message is considered bitey for reasons (beyond it being non-specific), we should discuss making it less bitey under a new topic. Daniel Quinlan (talk) 04:02, 12 April 2024 (UTC)

Correct me if I'm wrong, but the filter also prevents any editing of any user page containing the template, which is likely to create its own problems (maybe SoY has already pointed this out by email). I took a look at the RFPP request and would say that of course protection can be used for 'important' subpages. I've had my own PGP sub-page semi-protected since I became an admin, and I'm sure I've even fully protected others' key pages, if that's what they asked for (semi is usually enough though, IMO). As SoY points out, timestamps are everything when it comes to key verification. -- zzuuzz ^(talk) 07:39, 12 April 2024 (UTC)

Honestly, I'd recommend making that filter private right now even if it didn't change from what it currently is(or it's ultimately disabled), if there's any worry of people trying to bypass it - isn't that the main reason filters are privated? @Zzuuzz, it's not every edit, though it is every user page yes. – 143.208.238.195 (talk) 07:54, 12 April 2024 (UTC)

Yes, you're right. What would be prohibited is something like courtesy blanking, replacing a user page with a sock tag or a banned notice (or reverting such), along with removing bad content placed by the user near the template. I'm still sceptical about the filter, or anyone relying on it, so will let someone else make that judgement about its visibility. -- zzuuzz ^(talk) 08:23, 12 April 2024 (UTC)

At this point, since you pretty much said it as an example, I might as well say it, the filter, as a side effect, gives all users the capability of fully protecting specific lines of their choice from non-admin users - this is not something which should be given lightly or even automatically unless it's really good automation (not the case with the way the filter currently is) because ill intentioned users exist. – 143.208.238.195 (talk) 08:43, 12 April 2024 (UTC)

Yeah, that's what I had in mind, e.g. {{committed identity|Zzuuzz is a total ...}} Yeah, we could tweak the regex so that they can only talk about how much DEADBEEF 15 A B00BFACE, but is it worth the trouble? I've already though up about four ways to bypass this filter (again, emailed DQ, some of them are sort of relevant to other filters). Suffusion of Yellow (talk) 18:03, 12 April 2024 (UTC)

Bbb23, who is a much more frequent target for vandals, would not be exempt from that either. 0xDeadbeef→∞ (talk to me) 15:21, 13 April 2024 (UTC)

I've disabled the filter and set it to private for now. I think it might be better to integrate it into a more generalized (and probably private) filter for user page vandalism and shenanigans, one that flags edits rather than disallowing them. I'd also like to better address some weaknesses in the implementation (that was always the plan).

One option we might want to consider is designating a specific location (or locations) for committed identity information, PGP keys, etc. and protecting it similarly to .css and .js files. I think the concerns about the filter allowing users to "protect" specific lines are somewhat overblown as this is already possible with personal .css, .js, and .json pages and this hasn't been a major issue. Daniel Quinlan (talk) 19:43, 12 April 2024 (UTC)

[URGENT] Education Program needs to be exempted from filters

See this filter log, and this is something that I've seen before. Members or coordinators of the education program getting caught up in filters is probably one of the worst possible false positives and should be addressed immediately. Taking Out The Trash (talk) 17:38, 13 April 2024 (UTC)

Courtesy ping to Ohnoitsjamie as the last editor of the miscellaneous article/draft/talk LTA filter. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 18:14, 13 April 2024 (UTC)

 Fixed by Ohnoitsjamie. Nobody (talk) 20:06, 13 April 2024 (UTC)

Thanks, Nobody; I fixed it, then was unable to figure out where this ping originally came from. OhNoitsJamie ^Talk 20:11, 13 April 2024 (UTC)

Set filter 1294 to disallow

• 1294 (hist · log) ("Test edits and low effort vandalism", public)

Standard notification. Split out of 260 (hist · log), 384 (hist · log), and 614 (hist · log), with a handful of additions. No FPs in the few dozen "new" matches. I'm not going to add this to Template:DatBot filters. In fact, that was part of the reason for the split. I doubt that users adding "lol" and "fdshksdjfhskdjdshfflshjfsldkhfdslkhsfd" are really going to put in the effort to work around the filters, so let's have a bit less clutter at WP:AIV/TB2. Suffusion of Yellow (talk) 00:36, 14 April 2024 (UTC)

Understood. This filter is targeted towards your run-of-the-mill everyday vandal who doesn't use much effort to bypass this filter and/or trigger 1296 and/or 1297 instead.

Also, this might be different from 664 (hist · log). Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 00:50, 14 April 2024 (UTC)

664 is warn-only, though I haven't looked through the log to see if it can be set to disallow. 1296/1297 is an experiment that might go nowhere. 1297 is not going to be easy to maintain and IMO a filter that complicated is only justifiable if keeps out a huge amount of vandalism. Suffusion of Yellow (talk) 00:59, 14 April 2024 (UTC)

No problems here, seems solid from a glance at the filter. EggRoll97 ^(talk) 05:02, 14 April 2024 (UTC)

Need a change for #867

After noticing this, I suggest excluding undos and reverts from being logged onto the edit filter log by #867. Toadette ^{(Let's talk together!)} 14:47, 14 April 2024 (UTC)

 Fixed. EggRoll97 ^(talk) 17:56, 14 April 2024 (UTC)

Not sure if that's a good idea. After an AFD was closed as "redirect", it's common that someone will come back much later and try to undo the result. I see no harm in logging that. Suffusion of Yellow (talk) 18:47, 14 April 2024 (UTC)

Self-reverted for now, though anti-vandalism isn't exactly the scope of this filter. For example, Special:Diff/1218898491 isn't a large page creation, it's reverting redirect vandalism. EggRoll97 ^(talk) 20:52, 14 April 2024 (UTC)

Sure but there's no harm in a log-only filter catching a few out-of-scope edits. If I understand this change correctly, around next WP:THURSDAY you'll be able to write something like page_last_edit_age >= 86400 to exclude reverts of recent edits. But even that would exclude rapid edit warring to overturn an AFD. Suffusion of Yellow (talk) 20:59, 14 April 2024 (UTC)

Is this worth changing the 'Numeric change without summary' filter?

• 1248 (hist · log)

Until WP:VPT#I don't understand these edit summaries (task: T360164) is fixed, would it be worth it to change the pattern to match these cases too?
I'm not really sure how to check how often edits like that are happening and not getting logged by the filter, other than manually looking at Special:RecentChanges (I also don't know what other filter this might be affecting), but I figured I'd point it out and ask anyways. – 143.208.239.226 (talk) 02:32, 22 April 2024 (UTC)

Thanks, tweaked. Found one example out of the last 1000 mobile app edits. Suffusion of Yellow (talk) 03:56, 22 April 2024 (UTC)

Prepare for Armageddon: temporary accounts

(Topic name is a reference to one of my favorite error messages.)

The 15 April The Tech News weekly summary includes this blurb:

Volunteer developers are kindly asked to update the code of their tools and features to handle temporary accounts. Learn more

Of course, it's not just code that will need to be updated. A good number of edit filters are going to need to be updated. I don't think we necessarily want or need to update anything before it happens, but I'd suggest enumerating the variables and functions most likely to be affected and start building a list of filters expected to require updates.

(This may have been discussed before, but I didn't immediately find anything in the archive.) Daniel Quinlan (talk) 23:57, 15 April 2024 (UTC)

If we don't have anything to feed to ip_in_range(), that will be bad, and some filters will have to just be disabled. But otherwise, so long as temp accounts are never autoconfirmed, and have an edit count and age that stays at zero or null, I don't think a huge number of filters will need updating. If user_age and user_editcount start incrementing, then we might want to check user_type in some filters. I'd prefer to see how temp-account users act first. Will the vandals clear cookies after every edit? Or will most of them be too clueless? No way to know right now. Suffusion of Yellow (talk) 01:04, 16 April 2024 (UTC)

I'm hoping that the IP variables are unaffected, but I haven't dug into that. I was most concerned about user_age which is definitely used as an IP test. Daniel Quinlan (talk) 01:47, 16 April 2024 (UTC)

One thing we might have to consider is this: If people start crying "We're being flooded with vandalism! We need to require registration for everyone!" an alternative might be making the filters much harsher for temp users. As in, you add "gay" to a BLP, in any context, and you're told "you have to register an account to do that". You edit more than three pages in ten minutes: "sorry, either wait ten minutes or register an account". And so on. I hope it doesn't come to that, but disabling all logged out editing would be a greater loss, I think. Suffusion of Yellow (talk) 02:31, 16 April 2024 (UTC)

Yeah I agree with you as we have a lot of productive IP users. I think that once this gets implemented, using !("confirmed" in user_groups) (as long as the temp accounts can't become confirmed or get other user permissions but that should happen anyways) would work quite well to prevent new users and the new temp account issues. – PharyngealImplosive7 (talk) 02:39, 16 April 2024 (UTC)

It looks like the new user_type variable will probably work well for most simple filters.

We also need to understand how this affects filters that use the IP in throttling actions.

It might also be a good time to consider whether there are any additional variables or functions that could help alleviate any losses in functionality. There are "hacks" such as trying to detect reverts by looking at the edit summary. That example might not be something that wants to be fixed sooner because of temporary accounts, but are there other hacks that might be more important to replace with a better solution due to temporary accounts? Daniel Quinlan (talk) 06:29, 16 April 2024 (UTC)

I think, I hope, that IP masking causing that level of disruption would convince the WMF to roll it back at least locally. Snowmanonahoe (talk · contribs · typos) 12:45, 22 April 2024 (UTC)

The WMF legal department is requiring IP masking. I do not anticipate a rollback. –Novem Linguae (talk) 00:12, 23 April 2024 (UTC)

Damn, you're right... Snowmanonahoe (talk · contribs · typos) 03:49, 23 April 2024 (UTC)

• Relevant to the questions above by Daniel and Suffusion: For developers#Updating AbuseFilter filters – 143.208.236.191 (talk) 05:34, 16 April 2024 (UTC)

  Nice find, looks like that just got added several days ago. I'm going to need to reread all of that. There are about a dozen enabled filters using ip_in_range and ip_in_ranges, including some LTA filters, so hopefully T357772 ends up in a good place. Daniel Quinlan (talk) 06:01, 16 April 2024 (UTC)

• I'll just raise Special:AbuseFilter/1283. It seems to be the only active filter of its type (we've previously used this technique in several now-inactive filters). -- zzuuzz ^(talk) 06:05, 16 April 2024 (UTC)