Jump to content

Wikipedia:Edit filter noticeboard/Archive 11

Add links
From Wikipedia, the free encyclopedia
Archive 5←Archive 9Archive 10Archive 11Archive 12Archive 13Archive 14

Copypaste vandalism

Moved from Wikipedia:Edit filter/False positives/Reports § FalconsFanZ

@Red-tailed hawk: I agree that WP:FORUM comments are not vandalism. However, they are generally removed as not constructive, and having edit filters prevent them from being added in the first place saves editor time. I think that functionality is useful. The wrinkle is that different levels of strictness are appropriate for regular and talk pages. Paragraph-length bodies of text without punctuation are never an improvement to articles. The same on talk pages could be helpful, assuming they are not forum comments, which I found that most were. I'll be honest that I have no formal programming training and your sentence describing how a bot solution might work made no sense to me. (Sorry!) If the goal would be to reduce the overall strictness toward bad punctuation, it might make sense to let this filter continue to run as-is in article (and perhaps other non-talk) spaces and have the bot handle talk pages. But it sounded like you were describing an algorithm to check for repeating characters?

That said, it now occurs to me that the issue with unformatted lists tripping the filter could probably be fixed by changing \s to just the whitespace character, as those ill-formatted forum comments are pretty much always just a single, long line of text. Repeating character vandalism, which this filter also handles, often does contain line breaks, but a separate condition checking for just that could handle that part of it. (Maybe something like (\w{14}[\w\s]){3}, although I just threw that together in two minutes and it could certainly be better. Now that I think about it, didn't we once have a filter that did something like that? Is it still around? If not, whatever became of it?) Of course, this encounters the same issue I described above where loosening this filter's strictness even slightly in article space would not be desirable; perhaps it would be better to have two slightly different filters for article space and talkspace. —Compassionate727 (T·C) 17:55, 25 January 2023 (UTC)

I agree that WP:FORUM talk posts are generally not constructive, yes. I think we're in agreement on that and that it improves Wikipedia to simply not have the statements appear.
The solution for the bot was to check for repeating sets of characters so that copy-paste vandalism could be identified directly. My understanding is that the current filter only checks for 500 word/whitespace characters, so directly targeting repeating sets of characters could catch somebody pasting:

You likely are the sus chungus imposter. You likely are the sus chungus imposter. You likely are the sus chungus imposter. You likely are the sus chungus imposter. You likely are the sus chungus imposter. You likely are the sus chungus imposter.

whereas the current filter would miss it due to the phrase both having punctuation and being well under the character threshold. Something like (\w{14}[\w\s]){3} would catch literally repeating strings, but only when they're directly adjacent to each other and of exactly length 15 (or have a single space between them and are of exactly length 14). Something like (([\w\s]{40}).*){3} would catch the line I've listed above, as well as something slightly more complicated like

a1b2You likely are the sus chungus imposter. abcd Here is a sample legitimate text to try to trick the filter how lucky am I You likely are the sus chungus imposter. qxyk You likely are the sus chungus imposter.jklp

but it's also going to run the risk of disallowing edits that include something like a moderately long phrase of art or the title of a thing (i.e. the phrase at the 2016 Rio de Janiero Summer Olympics might reasonably appear multiple times in an article). We can adjust sensitivity based off of the two numbers, so it leaves room for thought with something of that design. Any filter based on this sort of logic is going to have to check only added lines, and the existence of the .* means that we're going to need to be very careful with how sensitive that we're going to make this, but I do think that we might be able to make this something like this work using abuse filters rather than a bot.
With respect to having different filters for talk pages and for articles, what you're saying makes sense. I think this could be handled through one filter rather than two (have one condition apply to article space and another to talk namespace, throwing a pipe in there to connect them by a boolean or), so that we don't have to have a second filter dedicated to the same task. — Red-tailed hawk (nest) 19:20, 25 January 2023 (UTC)
Also, I'm not sure exactly the procedure for creating test cases, etc. (I'm new around this noticeboard), so if there's a more secluded forum where this sort of development takes place it would probably be better to continue discussion there, lest trolls see an exhaustive list of test cases listed here. — Red-tailed hawk (nest) 19:21, 25 January 2023 (UTC)
I think we're fine discussing this here because the filter is public. One of the bosses might think otherwise, though.
It sounds like the situation is this: filter 1233 is currently designed to catch random character vandalism. It also happens to catch a lot of poorly punctuated comments, which is generally beneficial but does cause a few false positives, especially when inexperienced editors create lists using only line breaks. We would also like this filter to catch repeating string vandalism, which it is not actually geared toward that, although it catches a lot of it anyway via the random character check.
My inexperience with regex is showing here; I suppose I should just explain what my goal was and let someone else write the regex. I was trying to write code that would catch something like this but not this. What I latched onto was word length: very few English words exceed thirteen characters, so we could distinguish random character vandalism from actual words by checking for strings of word characters longer than that. Of course, because some words are longer than thirteen characters, we would want to check if there are multiple instances of this (three was a relatively arbitrary pick). Apparently () captures the input and not the regex; newbie mistake. The offending strings needing to be adjacent is also not ideal.
We probably don't need to catch your second example, most copypaste vandalism AFAIK isn't that advanced.
I'll have more thoughts on this later tonight, but I need to leave for Bible study now or I'll be late. —Compassionate727 (T·C) 22:58, 25 January 2023 (UTC)
For the two specific cases you've got there, the first is all caps, while the second has both capital and lowercase letters. You'd be able to catch the first with something like having a filter of ([A-Z]{50}) and match it with the added lines that get passed through the rmwhitespace function, which would let you check for a string of 50 consecutive capital letters excluding whitespace. It's a bit hard to see a legitimate usecase of having so many uppercase letters in a row. As far as false positives are concerned, the biggest problem I think would occur is that sometimes citations but through the visual editor interface will be auto-generated with a long list of capital letters if the page that's being referenced is in all caps, but this could be remediated by checking something like passing added lines w/whitespace removed through something like the following something like:
capsInARow := "[A-Z]{50}";;
capsInRefTitle := "[Tt]itle\=[A-Z]{50}"; /* (I'm unsure if the backslash is needed before the equals sign; still getting used to MediaWiki's specific abusefilter language even though its regex formatting is PERL-like) */
!("confirmed" in user_groups) &
rmwhitespace(added_lines) rlike capsInARow &
!(rmwhitespace(added_lines) rlike capsInRefTitle) &
!(rmwhitespace(removed_lines) rlike capsInARow) &
!(rmwhitespace(added_links) rlike capsInARow) &
!(rmwhitespace(page_prefixedtitle irlike ("sandbox|^Draft:|^User(?: talk)?:" + rescape(user_name) + "(?:/|$)"))) &
!(added_lines irlike "poem|lyric")
This assumes we want to keep all of the existing checks of the public filter. It's also probably not the most efficient way of solving this (and there might be a syntax error as I don't have a local testing environment set up) but I think this should convey the idea that I'm trying to get across.
— Red-tailed hawk (nest) 23:46, 25 January 2023 (UTC)
Reading through your comment again: if you want to find if the text added contains three words of length 14 or greater, then something like (([\w]{14}.*){3}) would be able to match that. This wouldn't necessarily get you the same word each time, and I'm not sure how to do that with regex without running into computing constraints.[note 1]Does this more directly address your concerns? — Red-tailed hawk (nest) 00:18, 26 January 2023 (UTC) comment struck; I was wrong — Red-tailed hawk (nest) 19:55, 26 January 2023 (UTC)
Yes, it does. I am confused—it is not clear to me why this check would require so many more resources than checking for strings of 500 word or whitespace characters in a row—but I'm guessing that's my fault for not having the faintest clue how computers actually work, and I trust your judgment about what is and is not feasible. It sounds like my conclusion last weekend that this filter is as optimized as it will get is correct. Thanks for humoring me. —Compassionate727 (T·C) 16:26, 26 January 2023 (UTC)
@Compassionate727: Please excuse my answer directly above, looking more closely I was wrong about how PCRE regex formatting. There is a built-in way to do exactly what you want to do (i.e. matching the preceding filter). ([\w\s]{15,})\1{3} would allow us to check for the same instance of the repeating string of size 15 or greater that's directly next to each other 3 times in a row. The \1 in the regex allows us to specify that we want to match the exact thing we found in the first enclosed group (i.e. the first group w/in parens), so SUSCHUNGUSAMONGUS SUSCHUNGUSAMONGUS SUSCHUNGUSAMONGUS SUSCHUNGUSAMONGUS and I love turning red I love turning red I love turning red I love turning red I love turning red would flag, while SUSCHUNGUSAMONGUS IMALITTLETEAPOTSHORTANDSTOUT SUSCHUNGUSAMONGUS SUSCHUNGUSAMONGUS and I love turning red it is a great movie and I think that we would be much better with it being nominated for an Oscar would not.
I sincerely apologize for my confusion; I had forgotten about this feature (and I need to brush up on my CS theory, apparently). — Red-tailed hawk (nest) 19:52, 26 January 2023 (UTC)
Actually, your previous answer was closer to what I wondering about. I don't want to capture a specific string and check for two other exact matches to it; I want any three strings that are too long to reasonably be words to cause a hit. The reason is, I was trying to write a condition that would catch random character vandalism (which the current design does) but not require punctuation to distinguish random or repeating characters from legitimate prose; something like (?:\w{14}.*){3} would do that[note 2] and could be combined with something like [\w ]{500} to continue capturing WP:FORUM comments as well (because unlike the lists that triggered the false positives, poorly punctuated screeds have no line breaks, either). Anyway, if that's not feasible, perhaps it would be possible to just use something like \w{25}. I've done some research and believe we would essentially never have false positives on normal English words with that number, although I am worried about potential hits on scientific names for chemicals and species; I don't know off-hand how frequently IPs and new users add those things. —Compassionate727 (T·C) 16:18, 27 January 2023 (UTC)
Hm. Ok, I think I understand a bit better now, though please correct me if I'm still not understanding you right.
The [\w]{25} would work to catch strings containing 25 consecutive word characters, yes. (?:\w{14}.*){3} also does what you're describing above.
If we want to flag long strings that don't contain neither punctuation nor newlines, some versions of perl support \h as a horizontal whitespace character set (i.e. whitespace but not carriage returns/newlines) that we could use instead of the existing \s, but I'm not sure if that set is supported in MediaWiki. If it's not, we could use something like (?:[\w]|[^\S\r\n]){500}, to match when there are 500 consecutive instance of a match to ((a word character) OR (any whitespace character except a carriage return or a newline)). — Red-tailed hawk (nest) 17:34, 27 January 2023 (UTC)
@Red-tailed hawk and Compassionate727: So, the title of this filter should be "Long string of characters with no punctuation or markup". It's not about catching repeated text or long words; I went with "copypaste vandalism" to avoid being too BEANsy. But apparently I'm just confusing people, so I'll rename it. Some other filters of interest:
  • 231 (hist · log) (disallow, "Long string of characters containing no spaces"): At least 50 letters and numbers with no spaces. Seems to work well, so let's not mess with it.
  • 135 (hist · log) (disallow, "Repeating characters"): Any string at most 9 characters long, repeated at least 7 times (with all sorts of exceptions for tables, lists, etc.). Also works well; don't mess with it. And to clear up any confusion, no, "regexes" with backreferences are technically not "regular expressions" in the CS theory sense.
  • 1163 (hist · log) (log-only, "Repeated text"): Any number of space-separated words, repeated at least three times, with some sort of whitespace between each repetition (...I think...). Apparently too many FPs to disallow, but I haven't looked into improving it in a while.
This leaves 1233 (hist · log). That was originally about an LTA who was dumping a long list of random words from a dictionary, e.g. [1]. The filter was never good at catching that, but I noticed it was catching all sorts of other nonsense, so I moved the conditions into a public filter.
But we still have the problem of 1233 catching poorly formatted lists. I've combined a few of the suggestions here. The original rule now only applies to mainspace. In all other namespaces, the text must also match [\w ]{500}|\w{15}, that is, a single line of word characters and spaces, OR a single word of 15 characters. This still matches about 480 out of the last 500 hits. If there are too many mainspace FPs containing newline-formatted-lists, perhaps that check should be applied to all namespaces, at the cost of more FNs. Suffusion of Yellow (talk) 03:18, 28 January 2023 (UTC)

References

  1. ^ I don't think that it can be done efficiently; regular languages can all be represented by finite-state automata, but those sorts of machines don't allow for storing memory. An extremely inefficient way to do it exists because there's a limited number of possible words of length 14, and a regex that checks for something like (ABCDEFGHIJKLMN.*){3} can theoretically be made, but doing this for every possible string of length 14 this would require 2614 conditions be checked for the filter to be thorough for uppercase-only strings, and 5214 conditions for strings whose character sets are limited to uppercase and lowercase letters.
  2. ^ Maybe? I have never written regex before and have no idea what I am doing. If I have 60 word characters in a row, would this code treat that as three matches, or would it only count as one because * is greedy?

Thoughts on a new edit filter

I'm not going to request this be a new filter quite yet as I"d like the opinion of those who regularly patrol this noticeboard. I was thinking that creating an edit filter to filter out WP:NOTAFORUM posts to talk pages might be helpful. Something along the lines of the only content in the newly added section matching the section header (which is almost always a WP:NOTAFORUM post). I'm not sure if this is feasible to do or if we should make an edit filter for such a thing, which is why I'm asking here first instead of just going straight to requesting a new one be created. ― Blaze WolfTalkBlaze Wolf#6545 20:53, 27 January 2023 (UTC)

@Blaze Wolf can you provide 3 diffs that are still in recent changes demonstrating the edit you would want to catch? — xaosflux Talk 21:50, 27 January 2023 (UTC)
Here's one. I would probably say another criteria would be the edit is under X amount of bytes (probably 500 or maybe less). Something that could also be added but would require it to be tag only would be if the section header matches the article title, although with this i Could see some false positives. I'm currently searching for more. I often encounter them when patrolling via SWViewer but when I'm trying to look for them now I'm having a hard time finding them. ― Blaze WolfTalkBlaze Wolf#6545 22:39, 27 January 2023 (UTC)
@Blaze Wolf I don't the edit you linked there is what you meant to link. — xaosflux Talk 00:27, 28 January 2023 (UTC)
Ah, that's my revert of the edit, sorry. This should be the correct link. ― Blaze WolfTalkBlaze Wolf#6545 00:30, 28 January 2023 (UTC)
Such a filter should be relatively simple to design. Whether it is worthwhile to devote a filter to these types of edits is another question. So far you have only shown one example; I trust you when you say there are more, but you haven't really been able to give us an indication of how common these edits are. I would suggest making a note somewhere whenever you encounter an edit like this and coming back with a list, which should give us a better sense of a filter's potential utility. —Compassionate727 (T·C) 23:24, 28 January 2023 (UTC)
SOunds good. And it may just feel more common than it actually is, but I could be wrong. ― Blaze WolfTalkBlaze Wolf#6545 23:25, 28 January 2023 (UTC)
That's why I asked for 3 recent diffs - if it is a relatively rare thing, we prob won't dedicate a filter for it. — xaosflux Talk 23:38, 28 January 2023 (UTC)
This is actually quite frequent -- I sorted my contribs like this, and there are probably 100+ edits like what @Blaze Wolf is talking about. I just picked a few at random: [2][3][4][5]. I can't really think of a filter that can eliminate all these types of posts without false positives, though. Potentially any non-autoconfirmed user adding a new section to the talk page with a diff less than +200 characters? — Ingenuity (talk • contribs) 01:19, 29 January 2023 (UTC)
What you linked to is different from what BlazeWolf was talking about. It would easy enough to also screen for the ones with section headers and no content, but everything else would a be harder. Not impossible, though. I'd have to think about specifics; my main worry would be the potential for false positives. —Compassionate727 (T·C) 03:21, 29 January 2023 (UTC)
I found this [6] which is ~1.5 months ago 0xDeadbeef→∞ (talk to me) 04:08, 29 January 2023 (UTC)

1221 to disallow?

Can 1221 (hist · log) be set to disallow? Seems to have no FPs. @Firefly and Suffusion of Yellow. ProcrastinatingReader (talk) 15:13, 29 January 2023 (UTC)

No, because the LTA is smart enough to evade filters. Needs to be in log-only mode or they'll just change what they write to avoid scrutiny. —Compassionate727 (T·C) 17:31, 29 January 2023 (UTC)
Replied here, on a thread also about 1221. firefly ( t · c ) 18:14, 29 January 2023 (UTC)
Also replied in that thread. Suffusion of Yellow (talk) 21:35, 29 January 2023 (UTC)

EF 880

There was a false positive report today concerning this filter; it was triggered by an IP using a certain editor's username. I checked the recent hits, and this seems to be a relatively common false positive, as the editor in question interacts with new users regularly. The last true positive involving this editor's name was back in November. I honestly can't tell whether or not that means the LTA is still a concern or if it would be possible to remove the editor's name from this filter. Thoughts? —Compassionate727 (T·C) 17:57, 29 January 2023 (UTC)

@Compassionate727: Thanks, fixed. I think there was an extra ? that wasn't supposed to be there. The LTA has been around since forever, so I don't they've gone away. Suffusion of Yellow (talk) 21:48, 29 January 2023 (UTC)

EFH Request: 0xDeadbeef

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.

0xDeadbeef (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 · ev · fm · mms · npr · pm · pc · rb · te)
Earliest closure has started. (refresh)

Hi all, I have been patrolling and helping with cases at EFFP for some time, and I would like to help process cases that involve private filters. I am requesting EFH permissions for dealing with false positive cases and assisting in debugging/editing/creating edit filters. I am familiar with regex syntax as an AWB/JWB user, and my bot involves a bit of regex as well. 0xDeadbeef→∞ (talk to me) 16:59, 31 January 2023 (UTC)

Support per continued and in-depth involvement with filters and other technical areas. While we're at it, I'd support +EFM also. Suffusion of Yellow (talk) 22:57, 1 February 2023 (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.

Multiple Chris-Chan filters

Can't see Special:AbuseFilter/1217, but Special:AbuseFilter/1159 already exists. Is 1217 narrower in scope or is this an error? InvalidOStalk 20:23, 31 January 2023 (UTC)

The presence of there being two filters was touched on above at Condition limit/1159. Unless there is a substantial difference between the two, or 1217 specifically is getting hits on something that needs to be private, I'm not sure why we'd need both. Sideswipe9th (talk) 03:20, 1 February 2023 (UTC)
The two are not entirely redundant to one another, and I think there are good reasons to keep them as separate filters. I won't say why per WP:BEANS, but any other EFM/EFH should be able to confirm that the two are not identical. I think the current distinction is wise for the time being; if we need to scrape a couple conditions from the condition limit, this might be a topic for future discussion, but right now I think the differences between the two filters are warranted. — Red-tailed hawk (nest) 19:50, 4 February 2023 (UTC)
Ah cool! Thanks, that resolves that question :) Sideswipe9th (talk) 19:52, 4 February 2023 (UTC)

Why is filter 979 getting so many hits?

See this graph. What's going on here? The VisualEditor problem is fixed. When I open a page in VE and type "1" into the citation tool, it switches to the "re-use" panel, as it should. So where are these irrelevant low PMID citations coming from. My first thought was that people were publishing locally saved copies. But it's been two months now. I'd expect the problem to have tapered off, at least. Any other ideas? Suffusion of Yellow (talk) 21:52, 5 February 2023 (UTC)

@Suffusion of Yellow If you look at the actual diffs of the edits being made now they seem to be a mix of adding metadata to citations added some time ago, creations of pages that look to be old or locally-stored copies, and false positives:
  • [7] False positive
  • [8] Was converting an existing reference - it seems like the automatic-switching behaviour may not happen if you try to convert a reference that already exists.
  • [9] Citation bot adding metadata to an old citation
  • Then there are a few edits to a deleted article from a paid editor who presumably had a local (old) copy
  • [10] This seems to be copying an article from a page that already exists
  • [11] Likewise
  • [12] Citation bot again
  • [13] Not sure on this one - long term edit warring or perhaps content from another wiki
  • [14] Not sure here either but @Egeymi: fixed their edit, so perhaps they can clarify how the error occurred.
Does that make sense to you or am I missing something? Sam Walton (talk) 22:19, 5 February 2023 (UTC)
Yeah, thanks, makes sense. I guess I should have looked at more than a few examples. These refs are going to be shuffled around forever unless they're removed. I still can't reproduce the behavior in the second example, though. Suffusion of Yellow (talk) 22:48, 5 February 2023 (UTC)
Looking at the ten most recent log entries for the filter, 9 seem to be false positives where the edit in question is correctly citing a very old paper with a correspondingly low PMID (1, 2, 3, 4, 5, 6, 7, 8, 9), and one is an editor putting a DOI as the PMID (1). Sideswipe9th (talk) 22:20, 5 February 2023 (UTC)
Checked entries 11-20, those are all false positives where an editor is correctly citing an old paper with a correspondingly low PMID. Sideswipe9th (talk) 22:23, 5 February 2023 (UTC)
I wouldn't call most of those FPs. The citations are totally unrelated to the statements they're claiming to support. Suffusion of Yellow (talk) 22:48, 5 February 2023 (UTC)
It's possible I was looking at this from the wrong perspective? I was checking if the PMID addition was to the correct paper, ie does PMID 12 correspond to a paper with the title "The effect of adrenaline and of alpha- and...", and not whether the citation itself was correct in the context of the content it was supposed to be supporting. I don't think we have the technology yet to design an edit filter that could determine if a given citation is correct for the context its supporting.
If all we're wanting to do is to track whenever an editor cites something with PMID 1 to 99, in the main, user, or draft namespaces, the filter will do that. But determining whether that edit was user error, a visual editor bug, or an intentional use of the wrong citation, is something we'd need to start asking about. Sideswipe9th (talk) 23:18, 5 February 2023 (UTC)
A bit more background. The idea was to warn users with something like this. The tiny number of people who actually intended to cite one of those obscure papers could just click past the warning. Except, now that warning message is wrong. VE doesn't do that anymore. If it's just old refs being shuffled around, and bots filling in missing fields, I guess there's nothing to do. But I suspect that at least a few of these are new, and I'd like to know here they're coming from. Suffusion of Yellow (talk) 23:56, 5 February 2023 (UTC)

WP:LTA/BKFIP and "famously" removals

Wikipedia:Long-term abuse/Best known for IP has been using mobile phone IPs to avoid detection and blocks. They are actively removing the word "famously" from Wikipedia. I'm not sure how to track removals of the word, except when they show up in my watchlist. Any suggestions? Examples: Édouard Stern and Deborah Scaling Kiley. -- GreenC 22:15, 3 February 2023 (UTC)

They may be an LTA, but those edits look like improvements to the article. One could create a detective filter that tracks removals of "famously" from lines and has some check to make sure that things weren't just redirected, but I imagine that there will be a good number of false positives. — Red-tailed hawk (nest) 05:49, 4 February 2023 (UTC)
Having a quick look at the LTA page, only two of the known non-IP accounts have ever made it past auto-confirmed, so unless there's a bunch of unknown XC accounts in their sock pile you could use that to filter out at least some of the false positives. You can do a filter to track removals of just the word "famously" and/or the few other variants the LTA likes to remove, but if you make it too specific it becomes too easy to avoid, and if you make it generic enough to prevent that then you'll get a lot of false positives. I dunno. Sideswipe9th (talk) 18:53, 4 February 2023 (UTC)
The LTA page, and SPI archives, are severely underinclusive. BKFIP is quite recognizable once you've dealt with them a few times so accounts are frequently blocked without formal investigation. Further BKFIP usually abandons accounts once they are suspected, so many socks are never blocked at all. Autoconfirmed accounts occur with regularity, and a handful have even reached extended confirmed. Not that this changes any of the analysis below, but that knowledge may prove useful in the future.
Disclosure: In the past I had defended BKFIP, but now regret having done so. 74.73.224.126 (talk) 21:05, 6 February 2023 (UTC)
Okay, unpopular opinion: this is not worth our time. These edits are, by and large, improvements. The whole shtick here is to make small mostly-positive edits, get reverted per banned means banned and then insult those making the reverts. By engaging with them, whether by reverting or spending time creating an edit filter we are giving them what they want.
I have a lot of sympathy with the idea that bans apply to any edits, good, bad, or indifferent. I have G5'd whole swathes of pages at SPI and blocked an awful lot of socks on that basis, however here we have a case where the edits themselves are improvements (honestly, the word "famously" in the contexts here serves no purpose), and reverting will allow the user to have their fun. I recommend we leave these sorts of edits alone and just quietly block the accounts or IPs used when we come across them. firefly ( t · c ) 19:14, 4 February 2023 (UTC)
Mostly agree. Blindly reverting BKFIP's edits will degrade the encyclopedia. That said, the usual pattern is more like (1) BKFIP makes some edit, with a mean-spirited edit summary. (2) User (who has never heard of BKFIP) reverts or warns BKFIP. (3) BKFIP calls user a "troll" and "vandal". (4) User understandably loses their cool, and says something not 100% civil to BKFIP. (5) Matters escalate to ANI. (6) ANI's resident mall cops get in on the action, and join in with BKFIP attacking user. I don't have a solution here. But I think there's value to monitoring BKFIP's edits with a filter. Please, keep an eye on 667 (hist · log). Yes, maybe 90% of that is false positives. But sometimes you'll be able to interrupt a "situation" before it gets out of hand. Personally, sometimes I don't report the sock if they're sticking to mainspace, not edit warring, not hounding anyone, and not being too nasty. I just watchlist their talkpage (I wish we had a "user watch" feature but I know it would be abused...), and report them as soon as they get into a spat with someone. I never click "mass rollback", though I might revert any talk edits without replies. Suffusion of Yellow (talk) 22:39, 4 February 2023 (UTC)

Set filter 1241 to disallow

  • 1241 (hist · log) ("User talk page disruption", private)

Mandatory notification. Please do not discuss publicly. Suffusion of Yellow (talk) 22:16, 7 February 2023 (UTC)

"possible vandalism" tag capitalization

The "repeated attempts to save edit" and "Rapid disruption II" filter currently seems to add the "Possible vandalism" tag (with a capital P), while the other filters (11 (hist · log) for example) add the "possible vandalism" tag (with a lowercase P). This results in two possible vandalism tags. I suggest either this be corrected or changed to something like "possible vandalism- throttled". 137a (talk • edits) 16:05, 15 February 2023 (UTC)

Nice catch, the tags do seem to be duplicated on Special:Tags. I'm minded to do the fix you propose - changing them to the lowercase - but would appreciate more opinions for a sanity check. ProcrastinatingReader (talk) 12:36, 16 February 2023 (UTC)
@ProcrastinatingReader they should all just be lowercased, if we actually want different tags use a different term for one. — xaosflux Talk 13:40, 16 February 2023 (UTC)
Thanks both. Both filters updated. ProcrastinatingReader (talk) 15:15, 22 February 2023 (UTC)

OpenAI Detection Filter

Yesterday, I asked the teahouse (link) if it was okay to write an essay about a possible method for OpenAI text detection based on a group of nine Reddit posts, all of which share certain characteristics. These common characteristics, when examined closely enough, do not appear to have been written by somebody classified as biological.

After a great deal of thought, I decided that the risk of causing problems off-wiki (and feeding the trolls on-wiki) is too high.

Can I email my thoughts on this to the mailing list, in the hope that maybe an edit filter can be created based off my analysis?

I do not have regex experience, nor do I ever want an edit filter flag. I do have... unique first experience with software automation. Proof of that can be provided if needed. DarklitShadow (talk) 23:32, 9 March 2023 (UTC)

My general idea feels like good faith, but this is the wrong approach. DarklitShadow (talk) 02:39, 11 March 2023 (UTC)

Filter Error Question

Hello everyone

While responding to Wikipedia:Edit_filter/False_positives, I came across Abuse Filter 225 which looked like it missed something. After putting it in Regex it looked like !summary rlike ("/\* .*" + match + ".* \*/") misses something. Would !summary rlike ("\/\* .*" + match + ".* \*\/") fix it? 1AmNobody24 (talk) 10:25, 17 March 2023 (UTC)

Hi. If I understand you correctly, you're possibly thinking we're using /re/ -slash-style delimiters at either end of the pattern. Many regex engines will use this format, but this isn't the case here; we only need to escape the asterisks. The forward slashes are contained within the edit summary when you click on a section link - the summary automatically contains "/* section_title */ ", and that's what the pattern is testing for. It's checking for an edit summary containing an automatic edit summary for a section with a suspicious word already existing in its title, so it can be ignored. Does that make sense and answer the question? -- zzuuzz (talk) 11:36, 17 March 2023 (UTC)
@Zzuuzz Yes that answers it. I wasn't sure if the / was meant as a delimiter or as text to search for, 1AmNobody24 (talk) 11:48, 17 March 2023 (UTC)
Good stuff. I'll just add that it doesn't do any harm to escape them, and you'll see that sometimes - I know I've instinctively written some filters in this format, and it may also help reduce confusion (as seen here!) and increase portability. If you're testing in another environment, you might need to escape the forward slashes. -- zzuuzz (talk) 11:55, 17 March 2023 (UTC)

Backlog of false positives needing review

There is a backlog of pinned requests needing further review at WP:EFFPR, with the oldest one going back nearly a month now. Some additional eyes/investigations are needed. Taking Out The Trash (talk) 15:52, 21 March 2023 (UTC)

Filter about only number changes without summaries

Hello everyone! I'm an admin from SqWiki. For many months now we're disturbed by a vandal which changes dates and other numbers in articles just for malicious purposes. Can someone help us set up a filter that would catch up edits which contain only number changes without providing any summaries? Maybe you already have such a filter I can copy to my community? - Klein Muçi (talk) 13:40, 22 February 2023 (UTC)

@Klein Muçi can you provide a couple of example diffs? — xaosflux Talk 14:21, 22 February 2023 (UTC)
712 (hist · log) is one that jumps to mind. Otherwise this kind of vandalism (WP:SNEAKY) is a tough problem to deal with in the general case, because a lot of number changes are vandalism, but some are corrections to inaccurate data (or effectively reverts of previous vandalism). AFAIK the best defence against this is recent changes patrolling, because it's very difficult for a filter (or even something smarter like an AI vandalism bot) to know if these changes are legitimate or not.
It could also be justifiable for your community to disallow unregistered users from making these kinds of changes, but that's more of a community/policy decision, as it involves a trade-off which would also block many legitimate edits. Only applying to edits without a summary is reasonable, but if you can circumvent it just by adding a summary then I imagine it's unlikely to be of use for long. Perhaps a more targeted filter for your particular vandal is possible. ProcrastinatingReader (talk) 15:25, 22 February 2023 (UTC)
ProcrastinatingReader, @Xaosflux, hello and thank you for your expressed interest! It so happens that we have already discussed this matter together a few months ago: Special:Diff/1091973424#mw-diff-ntitle1
It's the same problem persisting. You say
It could also be justifiable for your community to disallow unregistered users from making these kinds of changes, but that's more of a community/policy decision, as it involves a trade-off which would also block many legitimate edits.
and that is the exact situation in which we are. Being a small wiki, we generally don't allow small number only edits by IPs without summaries even when we don't have a strong reason to suspect they might be vandalisms, the reason for that being that we lack the active volunteers needed to check and approve each of those edits. So that is a trade-off we have already been accepting for more than half a year now. The filter would just make de facto manual work that has been already happening for a long time easier. If you find the courage to travel on the rabbit hole of links I've brought above you'll see a lot of more details for this situation which is a desperate recurring request from me now. You'll also see that some MediaWiki changes we're issued to accommodate such a request but all started discussions were closed without any fruitful results. — Klein Muçi (talk) 17:01, 22 February 2023 (UTC)
@Klein Muçi this ask seems a bit narrower in scope, can you provide a couple of diffs that are still in recent changes that illustrate the current edits? — xaosflux Talk 17:15, 22 February 2023 (UTC)
Xaosflux, I've currently blocked for the millionth time the IP user which usually does these kinds of edits so I'm not sure if there are any on recent changes left (90% of those edits for us come from that one single user) but maybe I can find some old ones or imitate them artificially in my sandbox? Would any of those methods benefit you? — Klein Muçi (talk) 17:22, 22 February 2023 (UTC)
@Klein Muçi In last 90 days should be fine, even if already reverted (so long as not deleted). Reason why is so that the AF Examine tool can be used to get the most details out of the edit. — xaosflux Talk 17:25, 22 February 2023 (UTC)
Xaosflux, yes, I understand. I'm guessing some sandbox artificial edits would also help then, no? That would be easier to achieve than finding past edits. — Klein Muçi (talk) 17:28, 22 February 2023 (UTC)
@Klein Muçi they could, but this was also to attempt to determine if how you describe the situation above is actually what the situation is; rules are programmatic but memories can be fuzzy :D For example is it ONLY strict number changes such as "156156" --> "156256", or is it also things like "100 003,1415" --> "100 003,1115", "3,14" --> "31,4", and "tetëmbëdhjetë" --> "gjashtë". Is it really null edit summaries, or is it also edit summaries that aren't null, etc. — xaosflux Talk 17:49, 22 February 2023 (UTC)
Xaosflux, Edit 1, Edit 2, Edit 3.
These are all artificial edits. The first is full page edit with one single page, the second is full page edit with multiple changes and the third is a section edit (is this really "without summary"?).
I fully agree with your logic. Such variations do indeed exist for us but the idea is to hopefully get the code/regex for the general case and further modify it as needed. If you wish to go the extra mile, you might present me with the "general regex" and a variation where space + commas/periods are introduced. I believe that would be more than enough for me to model on further changes. — Klein Muçi (talk) 18:59, 22 February 2023 (UTC)
OK, that matches: 6358179, 6358180, and 6358181. — xaosflux Talk 19:07, 22 February 2023 (UTC)
@Klein Muçi so for example, notice that third one: it does have an edit summary: /* Filmografia */. — xaosflux Talk 19:08, 22 February 2023 (UTC)
Xaosflux, I see. Any way to include such changes that have no manual inputted summary?
If not, let's stick with whole page edits, only number changes without summaries by IPs (even though the artificial examples I brought were made by registered accounts). — Klein Muçi (talk) 01:10, 23 February 2023 (UTC)
Sorta, the "only number changes" is the hard part of this (and a MVP) - so that's the first hurdle, lets see if anyone comes up with any bright ideas for that first. — xaosflux Talk 01:52, 23 February 2023 (UTC)
I commented on phab:T220764 that having better diff info to AF may solve this. — xaosflux Talk 15:51, 23 February 2023 (UTC)
┌─────────────────────────────────┘
Just letting everyone know that after some experimenting and some help from some users, I've managed to cook up something that works well enough on what I wanted to achieve: w:sq:Speciale:AbuseFilter/20
This is currently being closely monitored to further fine-tune it and lower false positive numbers. — Klein Muçi (talk) 15:29, 25 March 2023 (UTC)

Set 716 to Warn or Disallow?

Filter #716 currently tags edits by new users that tag/detag pages as good articles or featured articles. Lots of the hits are vandalism, so I think this should definitely be set to warn. New users shouldn’t be doing this anyways. It could be set to disallow, but what do you think? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:46, 28 March 2023 (UTC)

It seems a lot of these hits are otherwise disallowed though — e.g. this recent IP. — TheresNoTime (talk • they/them) 00:59, 28 March 2023 (UTC)
Yes, they usually are, but not always. I see no harm in changing this to warn or disallow. Do you @TheresNoTime:? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 01:03, 28 March 2023 (UTC)
I guess not, at least for warn —  Done — TheresNoTime (talk • they/them) 01:08, 28 March 2023 (UTC)

Set 432 to disallow?

I checked ~200 of the edits that were tagged for Special:AbuseFilter/432, and didn't find any false positives. I think it can be set to disallow - thoughts? Galobtter (pingó mió) 06:31, 24 March 2023 (UTC)

I've checked a few past hits and I didn't find any false positives too. +1 on setting this to disallow. 0xDeadbeef→∞ (talk to me) 08:04, 24 March 2023 (UTC)
Seems fine. Out of the last 100 hits with saved changes, only [15] and [16] (plus a few that I reverted myself) weren't reverted. I'm not sure either is bad-faith, but so long as there is a custom message, I think the high volume of edits justifies setting this to disallow. Suffusion of Yellow (talk) 23:37, 24 March 2023 (UTC)
Yeah I'd convert the custom warning to a similarly worded custom disallow. Galobtter (pingó mió) 04:31, 25 March 2023 (UTC)
I agree with @0xDeadbeef and @Suffusion of Yellow. You should really never have to start a line with lowercase letters, so there should be only a VERY small amount, if any, of false positives. I think we definitely set the filter to disallow. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:55, 25 March 2023 (UTC)
This filter probably also only applies to new users, making the risk of false positives even lower. Animal lover |666| 10:57, 26 March 2023 (UTC)
True. Honestly this should have been set as disallow sooner. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:20, 26 March 2023 (UTC)
@Galobtter: As you are an edit filter manager, I think you can go ahead and set it to disallow. There is clear consensus here. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:20, 26 March 2023 (UTC)
 Done — TheresNoTime (talk • they/them) 00:53, 28 March 2023 (UTC)
 Thanks - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:56, 28 March 2023 (UTC)
@TheresNoTime: Did you mean to set that to warn+disallow, instead of just disallow? Currently MediaWiki:Abusefilter-warning-lowercase-letters is telling users to press 'Publish changes' to continue, at which point they'll get the generic disallow message. Suffusion of Yellow (talk) 23:48, 30 March 2023 (UTC)
Nice catch @Suffusion of Yellow! You’re right, that should probably be changed. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:51, 31 March 2023 (UTC)
I fixed the filter to now use MediaWiki:Abusefilter-disallowed-lowercase-letters. Galobtter (pingó mió) 08:32, 31 March 2023 (UTC)

Set 1244 to Warn

I have seen this filter catch a lot of phone numbers with few false positives. I believe that we can start having the filter warn users. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 21:12, 2 April 2023 (UTC)

I think that's way too premature. Only a few hours ago it was realised that a simple timestamp would trigger a false positive. I hate to think how many other potential FPs are just waiting to be found. I suspect there are many. Let's let it run longer. -- zzuuzz (talk) 21:23, 2 April 2023 (UTC)
I was unaware of the timestamp issue. Sorry! - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 21:27, 2 April 2023 (UTC)
As zzuuzz said - I appreciate the enthusiasm, but I'm monitoring the filter and will ask about setting actions when I'm satisfied that there will be a low false positive rate, which might take a few weeks. Galobtter (pingó mió) 21:26, 2 April 2023 (UTC)
Okay. I look forward to hearing from you. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 21:27, 2 April 2023 (UTC)

Setting 1245 to disallow?

I created Special:AbuseFilter/1245 to stop the unending spam of nonsensical new talk page sections created by new users, per Wikipedia:Edit filter/Requested/Archive_21#Talk page junk. I wouldn't normally ask about disallowing a filter less than two days after creating it, but the regex is super strict so there's very little potential for false positives and there's a high volume of junk coming in. Of course the disallow message would be friendly and be customized to explain what talk pages are for. Galobtter (pingó mió) 19:44, 5 April 2023 (UTC)

While I don’t oppose setting this filter to disallow, I think setting it to warn would be sufficient, with a nice message explaining talk pages. The user could then decide if they want to go through with their edit. If others want this to disallow, I can easily be persuaded. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 21:14, 5 April 2023 (UTC)
In general warn filters are somewhat effective, but usually only in stopping ~60% of edits coming through. That'd still leave a lot of edits which in ~100% cases would need to be rollbacked, so I'm not sure what the point would be of letting the edits through. Galobtter (pingó mió) 21:34, 5 April 2023 (UTC)
You’re right, but I think a lot of these edits may be good faith. I support this filter being set to disallow. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:17, 5 April 2023 (UTC)
Support disallowing. Such a narrowly targeted filter might not be enough, but this is enough of a problem to justify multiple filters, if needed. I wasn't around for WP:AFT, but apparently there were over a dozen filters: 458 (hist · log), 460 (hist · log), 461 (hist · log), 463 (hist · log), 472 (hist · log), 473 (hist · log), 474 (hist · log), 475 (hist · log), 487 (hist · log), 494 (hist · log), 495 (hist · log), 496 (hist · log), 497 (hist · log), 520 (hist · log), 521 (hist · log). Might be worth mining those for ideas. Suffusion of Yellow (talk) 23:56, 5 April 2023 (UTC)
I think this stopped about 30% of the short additions by new users that were identified by your test filter, which is a significant chunk. But definitely more filters might be needed. Galobtter (pingó mió) 01:11, 6 April 2023 (UTC)
I created MediaWiki:Abusefilter-disallowed-new-talk-page-section; suggestions are welcome. Galobtter (pingó mió) 01:11, 6 April 2023 (UTC)
I think it looks good. Links to help page and page to report false positives. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 01:19, 6 April 2023 (UTC)
I set the filter to disallow. Galobtter (pingó mió) 04:08, 6 April 2023 (UTC)

Warning of 1057

 You are invited to join the discussion at MediaWiki talk:Abusefilter-warning-citing-wikipedia § Soft wording. Snowmanonahoe (talk) 22:37, 7 April 2023 (UTC)

989 Set actions

I have reviewed the hits for filter 989 and think it can be set to tag, warn, or disallow, depending on what the community thinks is best. There is really no reason you should be editing someone else’s userpage edit notice. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:54, 7 April 2023 (UTC)

Probably better to only exclude non-confirmed users, to match Special:AbuseFilter/803; a lot of the edits made are good faith fixes. Otherwise this would also not allow most users to tag these pages for deletion if needed. Galobtter (pingó mió) 03:39, 7 April 2023 (UTC)
Yeah. I think that sounds good. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:19, 7 April 2023 (UTC)
@Galobtter: Can this be done? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 18:36, 10 April 2023 (UTC)

Global abuse filters applying here

There's an RfC at m:Requests_for_comment/Make_global_abuse_filters_opt-out to make global abuse filters apply to enwiki and other large wikis. I think we should opt-out since we don't have the issues mentioned and shouldn't allow meta admins to bypass our local guidelines. Galobtter (pingó mió) 06:58, 18 March 2023 (UTC)

Support opt out - Out of lack of need and filters overlapping. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 16:20, 18 March 2023 (UTC)
  • Opt out. The English Wikipedia is more than capable of managing its own day-to-day operations without WMF involvement. Thebiguglyalien (talk) 18:01, 18 March 2023 (UTC)
  • Support opt out. I have been blocked only once on a Wikimedia Wiki—a false positive on a misconfigured global edit filter affecting the English WikiNews occurred when I was reverting vandalism, and the filter was set to block users automatically. Had Operator873 not stepped in to quickly unblock me, this bad global filter would have actively and substantially prevented me from continuing to revert vandalism while the Wiki was actively under attack from an IP-hopping vandalbot. I have low confidence that the global edit filters have the ability to automatically and appropriately block users in a manner that is consistent with the English Wikipedia's blocking policies, and I think that an opt-out is necessary to prevent future disruption to the English Wikipedia associated with the risks of these sorts of misconfigured global filters. — Red-tailed hawk (nest) 18:56, 18 March 2023 (UTC)
    Red-tailed hawk you were blocked by a local filter on that project as a direct result of my action. My first change to the filters were to a local one that had block enabled and that is the action that lead to your block. After I saw that my action on that filter resulted in you being blocked, I reverted the change and created a dedicate filter which I should've done from the very beginning. Your block was a direct result of my mistake on a local filter with block enabled and I wholly own my mistake. This wasn't a global filter issue as global filters do not auto-block. Operator873 connect 20:05, 18 March 2023 (UTC)
    I had assumed that this was a global filter because I thought that Stewards generally couldn't edit local filters. I apologize for my mistake. That being said, I do support an opt-out of the global filters due to redundancy with EnWiki filters as well as the delocalization of the decision on whether to warn or deny users for edits away from our community. — Red-tailed hawk (nest) 21:37, 18 March 2023 (UTC)
    For what it's worth, there are global filters that block users (LTA 306) as well as ones that block autopromotion (fuerdai vandalism, WP0 copyright infringement prevention mechanism). Blocking decisions must remain local to EnWiki. — Red-tailed hawk (nest) 21:42, 18 March 2023 (UTC)
    I mean, en.wp EFMs deployed a filter that prevented anyone from adding the letter j (or some other letter, I might've gotten it wrong) for a few hours. Mistakes happen, it seems a bit extreme to opt-out solely on the basis that people could screw up (they will! but so will local filter editors). Blocking decisions haven't been solely local to en.wp for years now; stewards have mistakenly locked accounts or globally blocked IPs, but no one is calling for en.wp to opt-out of those global mechanisms. Legoktm (talk) 02:25, 20 March 2023 (UTC)
    The edit filter would create local blocks. Would you please tell me what people other than EnWiki admins have the policy-based authority to issue blocks locally on EnWiki? — Red-tailed hawk (nest) 02:49, 20 March 2023 (UTC)
    Is there a meaningful distinction between a "local block" and other measures that have the same effect of preventing someone from editing? Like, hypothetically if global filters set global blocks instead of setting local blocks, would that be fine then?
    I should say, disallowing global filters from setting local blocks seems entirely reasonable to me. I just don't agree with the premise that currently blocking decisions are solely local. Legoktm (talk) 03:09, 20 March 2023 (UTC)
    I think that there is a meaningful distinction inasmuch as personal accountability is concerned. On the English Wikipedia, we have WP:ADMINCOND and WP:ADMINACCT: both of these allow users to hold specific admins to account for making bad blocks and bad admin actions. We also have a body that is accountable to EnWiki that allows for desysopping admins who fail to adhere to these criteria.
    No such accountability is guaranteed to the English Wikipedia community if Meta admins screw up, and those very same Meta admins are not required to have undergone vetting by the English Wikipedia community prior to being given the tools that would allow them to make decisions of blocking on EnWiki. The only policy on Meta allowing desysopping of full Meta-Wiki admins is one that pertains exclusively to inactivity. This setup would create a poor governance structure, where people who are fundamentally unaccountable for their screw-ups would get to make blocking decisions.
    As for why global locks and global blocks are different: neta admins do not have the policy-based authority nor technical ability to issue global blocks nor global locks. That is reserved for the Stewards, who are accountable to the community through elections and re-confirmations.
    Good community governance proceeds from accountability to that community, but failure to establish accountability creates weakness in governance structure. If we are to retain a strong and effective governance structure, and to mitigate risks associated with privileged users, then keeping local blocks local makes sense. — Red-tailed hawk (nest) 07:04, 20 March 2023 (UTC)
  • Support opt-out At the end of the day, the far reaching effects on enwiki of any mistakes, or unintentional implementations can be far and wide, with not many users who are active to fix them. We have far better quantity and quality of EFMs here then we do xwiki. I would like to think enwiki can hold it's own water about this. -- Amanda (she/her) 20:14, 18 March 2023 (UTC)
  • It depends:
    • Support opting-in to logging and tagging, if the condition limit is doubled. If a little bit of clutter in our AbuseLog helps global patrollers track cross-wiki abuse, so what?
    • Weakly support opting-out of warn and disallow actions. I'm not comfortable with this, but that's mostly because I can't see what's really going on with the private filters. Maybe it's not as bad I as imagine? I'd support enabling these actions, but only with a sunset period, of, say, a month or two. If it causes too many problems, then no need for a second RFC.
    • Strongly support opting-out of blocking action. First, blocking filters (even local blocking filters) are not a good fit for enwiki's "clean block log" culture. I've seen long-time users quit after one 24-hour block. Second, this would effectively give meta-wiki admins the ability to block enwiki users. And third, there's a WP:BEANS reason that I'm sure at least TheresNoTime and a few others are aware of. That reason alone is deal breaker.
  • If such fine-grained control is not possible, then I simply support opting out entirely. Suffusion of Yellow (talk) 20:37, 18 March 2023 (UTC)
    Do we know the effect that opting in would have on the condition count? — Red-tailed hawk (nest) 22:01, 18 March 2023 (UTC)
    From phab:T309609 I gather that global filters would count against the limit. But the limit can be raised. Suffusion of Yellow (talk) 22:06, 18 March 2023 (UTC)
  • For reference, this is the list of enabled global filters. I find it interesting that one filter is set to block and a couple others are set to block autopromote when there's the message on the abusefilter edit page for both that says "(do not set on global filters)". I'm not necessarily opposed to allowing logging as SoY mentions but as of yet that debundling is not possible. Galobtter (pingó mió) 21:09, 18 March 2023 (UTC)
    From meta:User:Legoktm/Global_filters_everywhere I gather that it's technically possible, using the $wgAbuseFilterLocallyDisabledGlobalActions. Suffusion of Yellow (talk) 21:15, 18 March 2023 (UTC)
    Struck, that's good that it is. I think opting in only to logging filters is something that we could definitely do if needed. Galobtter (pingó mió) 21:29, 18 March 2023 (UTC)
  • Support opting out of warning, disallowing, and blocking actions. As somebody who watches the edit filters here and cross-wiki, having the global abuse filter log actions here would be helpful. However, we should definitely opt-out of the more direct actions, such as warning, blocking and disallowing, where we have our own filters here.—*Fehufangą (✉ Talk · ✎ Contribs) 22:59, 18 March 2023 (UTC)
  • Support opt out, and FYI for @Suffusion of Yellow, Galobtter, and Red-tailed hawk: I intend to get T332521 (setting wgAbuseFilterLocallyDisabledGlobalActions) resolved in the next few days — TheresNoTime (talk • they/them) 22:52, 19 March 2023 (UTC)
  • There are good reasons to opt-out, but I think focusing on them misses out on the long-term advantages and opportunities that having global filters brings us. en.wp hasn't opted out of other global anti-vandalism/spam tools like the global spam blacklist (technically possible) or global blocks (also technically possible) or the global locking of accounts (not technically possible). Why should filters be treated differently? en.wp has a lot of filter experience, I'd much rather see a good amount of our EFMs start operating on the global level to improve all Wikimedia wikis at once instead of constantly duplicating efforts. Legoktm (talk) 02:20, 20 March 2023 (UTC)
    We do manage local whitelists for GSBL and GBs, there is no whitelist for GAF. — xaosflux Talk 09:42, 20 March 2023 (UTC)
    Give us some mechanism to disable any one filter locally, and I would say we should accept the global filters except for individual ones we choose otherwise. We have this feature with global blocks and global blacklist; We probably rarely use this, but the fact that we can is crucial here. Animal lover |666| 22:14, 20 March 2023 (UTC)
  • Absolutely allow opt-out from each global filter; this probably requires general opt-out from the global filter system. We certainly should have filter managers keeping an eye on global filters and decide on a case-by-case basis what we want. However, our filter managers (except where our community says otherwise) should have the last word for each filter, not some global authority (except for possible disallowing where legal issues make it necessary; should this actually be necessary, the Foundation can handle it here directly). Animal lover |666| 09:10, 20 March 2023 (UTC)
    Just for the record, I would support a bot which copies all new global filters to our local filter system, and copies modifications from all global filters which remain unmodified here. This would certainly meet the "opt out from individual filters" criterion, as we can simply disable a filter as a means of opt-out. Animal lover |666| 11:43, 21 March 2023 (UTC)
  • Support opt-out and I'd expect the consensus here to be pretty close to unanimous. This global abuse filter sounds fantastic for smaller wikis that don't have enough people with the right skillset to manage a robust filter. It isn't a problem we experience here on enwiki. Every indication I've seen shows that we're more than capable of managing our own filters per our local policies. The WordsmithTalk to me 13:42, 20 March 2023 (UTC)
  • Support opt-out Not an improvement for en-wiki and an ivory-tower-created version is likely to be inferior at best. North8000 (talk) 18:40, 20 March 2023 (UTC)
  • Oppose opt-out I'm definitely in the minority here, but my viewpoint lies in supporting global contributions to anti-vandalism; vandalism is vandalism in any project. EpicPupper (talk) 20:03, 20 March 2023 (UTC)
    Antivandalism filters are not perfect, and enwiki's edit rate will produce a huge workload for maintainers of global filters (which I think I can count myself as) both simply because of the significant increase in filter hits and due to the large number of different false positives not yet accounted for, all for little gain given the active local filter assistance. If enwiki would like to mirror a global filter for logging purposes, asking a Meta admin is always an option. 1234qwer1234qwer4 20:03, 3 April 2023 (UTC)
  • Support opt-out, except for tracking (if that's possible) - The underlying global RfC makes perfect sense, btw, I've no issues at that level. But for the reason covered above, we don't need it. If there's a way to keep the tracking bits working, then why not aid the global side to the degree we can? Nosebagbear (talk) 23:43, 20 March 2023 (UTC)
  • Support opt-out. We are plenty capable of managing our own filters here. —Compassionate727 (T·C) 02:35, 21 March 2023 (UTC)
  • Case-by-case. I think there should certainly be an option to pick and choose which abuse filters should not apply to English Wikipedia. However, I also believe that fully opting out can make it harder to catch cross wiki abuse. The global title blacklists and spam blacklists already allow for that. If we can pick and choose which filters should and shouldn't apply to us then it is all good. That will only be possible, though, if abuse filter managers here are given permission to view the contents of private global filters on Meta-Wiki. Aasim - Herrscher of Wikis ❄️ 19:57, 22 March 2023 (UTC)
    To add on to this: the only global filters that should be enabled on the English Wikipedia are those to enforce global policies on vandalism, spam, T&S, etc., not all global filters. Aasim - Herrscher of Wikis ❄️ 20:00, 22 March 2023 (UTC)
  • Opt out per my comment above. More harm than use, both locally and globally. 1234qwer1234qwer4 20:05, 3 April 2023 (UTC)
  • Opt out: No real need to duplicate filters if possible. Based on a hunch, such duplicates could also cause the "rapid disruption" filters to lose much usefulness. Still, having the logs for the benefit of global RC patorllers like Fehufanga would perhaps be nice, but en.wiki doesn't really need more duplicate filters. And we'd all rather not find out what happens when 256 filters trip at one edit (ok,

I'm joking there) Mako001 (C)  (T)  🇺🇦 14:11, 12 April 2023 (UTC)

Set 1243 to disallow?

I created Special:AbuseFilter/1243 as per Wikipedia:Edit filter/Requested/Archive_21#Prevent removal of talk page headers. It seems to be working pretty well - haven't really seen anything constructive there. So I think this should be a disallow. There is some overlap with the talk page blanking filter, but this also catches a lot of edits that it doesn't. Galobtter (talk) 06:20, 10 April 2023 (UTC)

Support disallow: I didn’t find any false positives, and the filter only applies to non-confirmed editors. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:50, 11 April 2023 (UTC)
I've set the filter to disallow with the message MediaWiki:Abusefilter-disallowed-talk-page-header-removal. Galobtter (talk) 05:23, 13 April 2023 (UTC)

Disallowing the mention of me by non-autoconfirmed users

I think some filter already exists that helps prevent mentioning users by vandals, as I have been mentioned in edit summaries by blocked users (example here where my user page is piped by the text "Kojad". Upon my 5.5 years as a registered Wikipedia user, I don't see any legitimate reason for non-confirmed users to mention me in edit summaries without good reason whereas mentions from those who are at least autoconfirmed generally do. (That is the advice given to me by email, not on Wikipedia itself.) Iggy (Swan) (Contribs) 15:22, 13 April 2023 (UTC)

@Iggy the Swan edit filters are "expensive" - how often is this occurring? Your example doesn't appear to be an edit by a "blocked user" either, can you elaborate? — xaosflux Talk 15:30, 13 April 2023 (UTC)
Re how often is this occurring - in March 2023: 4 times plus another 2 here and a further 2 within the space of two active Wednesdays. I have checked this account has been blocked which contains the edit I've linked when opening this section.
I have never realised edit filters are "expensive". Iggy (Swan) (Contribs) 15:44, 13 April 2023 (UTC)
@Iggy the Swan: that account was blocked on 2023-03-29T09:49:33, the edit was made prior to that at 2023-03-29T09:46:19, so at the time it was made the mention was not sent by a blocked user; generally the only way that could happen is if they were abusing their own talk page while not being blocked from it. Am I missing something about you getting mentioned in edit summaries by blocked users? — xaosflux Talk 16:26, 13 April 2023 (UTC)
Ah I see what you mean now about block status between accounts, obviously what you said is indeed very true. Apologies for possible confusion. Iggy (Swan) (Contribs) 18:44, 13 April 2023 (UTC)

Abusefilter improvements

People might want to add thoughts at m:Talk:Wikimedia_Foundation_Annual_Plan/2023-2024/Draft/Product_&_Technology/OKRs#Result_2_Workflow_improvements - the WMFs draft goals for the year include "complete improvements to four workflows that improve the experience of editors with extended rights (admins, patrollers, functionaries, and moderators of all kinds)", so we might be able to get some proper improvements to abusefilters in the coming year. Galobtter (talk) 22:06, 13 April 2023 (UTC)

That’s exciting! I am glad that abuse/edit filters are going to be improved soon. Good suggestions @Galobtter. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 01:47, 15 April 2023 (UTC)

Proxy URL filter question

Regarding the "Proxy URL" filter, does putting the url in <nowiki> tags bypass it? Because if so, can that please be looked into, because it seems like it is a workaround used to dodge the filter, which achieves absolutely nothing helpful. Mako001 (C)  (T)  🇺🇦 12:10, 10 April 2023 (UTC)

@Mako001: Which specific filter are you talking about? If it is private then the discussion should not take place here. 0xDeadbeef→∞ (talk to me) 12:18, 10 April 2023 (UTC)
@0xDeadbeef: Thanks for noticing something was a bit off there, I meant proxy URL, now corrected. Mako001 (C)  (T)  🇺🇦 12:21, 10 April 2023 (UTC)
Can you give some examples? from AbuseFilter/892 I don't see anything regarding nowiki tags. 0xDeadbeef→∞ (talk to me) 12:32, 10 April 2023 (UTC)
Putting the url in nowiki tags would make it not be in added_links. Galobtter (talk) 22:46, 10 April 2023 (UTC)
Are people actually bypassing this filter? This filter is for unintentional additions, so I wouldn't expect people to try to bypass it. Galobtter (talk) 22:45, 10 April 2023 (UTC)
Well, if it is slightly harder than simply modifying the url, then yes, they may try to avoid having to fix it the proper way. This here is me hitting the proxy URL filter whilst cleaning up nowikis from refs. Nowiki-ing these urls is the very worst thing that they can do, as it hides it from many attempts to find and fix these urls, whilst still giving the citation the appearance of verifiability. The same would go for the predatory/open access journal filter too I'd expect. People do it with the spam blacklist too as it turns out. Whilst trying to clean up some other refs, I found myself hitting the blacklist rather frequently. And I was only searching for a fairly narrow range of uses of nowiki tags around urls. If there is a disallow filter/blacklist set to stop people adding certain urls, then they shouldn't be bypassing it this way, at least not in mainspace. Mako001 (C)  (T)  🇺🇦 13:43, 12 April 2023 (UTC)
Maybe there should be a filter to stop nowikis around URLs. For the spam blacklist stuff, the URLs should be removed or whitelisted. I also didn't realize the filter is disallow. It should probably be warn and tag since it's for good faith edits and I feel like it's better to at least have the URL not be nowiki. Galobtter (talk) 22:50, 12 April 2023 (UTC)
Regarding the first part of your comment: A filter to stop nowiki-ing of URLs would need to be limited to when used inside ref tags, as URLs are often legitimately nowiki-ed inside the body of an article (in internet-related articles particularly). I agree that any URL that the addition of is being disallowed shouldn't be bypassed using nowiki tags, as clear consensus exists that such URLs (proxy URLs and blacklisted URLs) shouldn't be in the encyclopaedia without having a case-by-case assessment of use.
Regarding the second: No, not really, per this discussion (and several cases in the archives where the filter's purpose and set-up has been affirmed[1]) the Proxy URL filter should be an exception to the general rule that filters stopping good-faith edits shouldn't be set to disallow. It was also initially tried as warn and tag. Mako001 (C)  (T)  🇺🇦 05:43, 16 April 2023 (UTC)

References

  1. ^ See:

"Among Us" vandalism in usernames

Whichever filter is currently used to disallow "Among Us" related vandalism in articles, should be extended/expanded to cover account creations too. Usernames like this I'm starting to see too frequently. Taking Out The Trash (talk) 20:19, 12 April 2023 (UTC)

I personally don’t see a reason why usernames can’t have the word sus or similar in them. It’s not offensive or promotional: - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:09, 13 April 2023 (UTC)
And it's kinda easier to block a vandal indef immediately if the username is a meme-linked username. If they use a usename like "Amongus69420sus" and start to vandalise, they're bascially doing us all a favour by making it clear that they aren't here in good faith, which results in a faster block and less overall disruption than if they'd made the same edits using something nondescript like "Username147502". Mako001 (C)  (T)  🇺🇦 05:21, 16 April 2023 (UTC)
Just create a duplicate filter that is set to tag as possibly disruptive username, or something like that. Zippybonzo | Talk (he|him) 12:36, 19 April 2023 (UTC)
This is probably a better fit for User:AmandaNP/UAA/Blacklist. Suffusion of Yellow (talk) 20:27, 19 April 2023 (UTC)

Illusion Flame for edit filter helper

 Request withdrawn Thanks everyone for the helpful advice. I will reapply in a few months when I believe I have more community trust. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 08:21, 21 April 2023 (UTC)

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.


Hello Edit Filter community,

I am requesting Edit filter helper rights as I believe they would allow me to better help out around the edit filters. Currently, I spent most of my time commenting on discussions here, reviewing false positive reports, and occasionally commenting on the requested edit filter page. Being able to view private filters would allow me to better respond to false positive requests that involve private filters. I would also be able to coordinate with fellow EFH/EFM about private filter and how to improve them. (Not publicly if it involves private content of course)

For official requirements, here is how I stand:

Demonstrated need for access:

A: I can help around EFFP to review reports with private filters. This would also allow be to better help out on EFN and requested edit filters.

No recent blocks or relevant sanctions:

A: Clean bock log.

At least basic understanding of account security

A: I have a strong password and understand account security.

At least basic understanding of regular expressions if the intent is to assist with authoring filters

A: I have some understanding of REGEX, though I still have some to learn. I don’t intend to do a lot of filter authoring though.

Sufficient ability with the English language to understand notes and explanations for edit filters

A: I am fluent in English and am capable of understanding notes/explanations.

Currently-active extended confirmed editor on the English Wikipedia (i.e. has made edits or logged actions within the last 12 months):

A: I have over 4,000 edits, have been here for about 2 months as of writing and average ~70 edits per day.

As for non-edit filter related editing, I work a lot in anti-vandalism. I tag a lot of pages for speedy deletion and try to help out new users when possible.

I would also like to thank Zippybonzo for encouraging me to go for this role, as I usually lack self-confidence.

Thanks, - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:45, 20 April 2023 (UTC)

Support- Has a clue, active in the edit filter area, not a jerk, it will help them to improve at filter authoring and there is a need as there aren’t many people who help out with Private false positive reports. Zippybonzo | Talk (he|him) 20:47, 20 April 2023 (UTC)
Support. All things considered, I am not very active around edit filters: I only really use the promotional userpage filters. However, I know enough and have dealt with enough vandalism to tell you that Illusion Flame is one of the most committed beginners on Wikipedia in this area. Some people have before questioned their experience, but having only two months of tenure is a red herring to their ability to just get stuck in. I have been watching Illusion Flame's editing for a while now and although there have been some bumps (early CSD tagging) they have proven that they can be trusted. They demonstrate a clear need for these permissions and will likely do an excellent job. Schminnte (talk • contribs) 21:11, 20 April 2023 (UTC)
Oppose EFH is an extremely high-trust role, and two months of tenure is just nowhere near enough to have earned the trust the role requires. GeneralNotability (talk) 23:38, 20 April 2023 (UTC)
Understood @GeneralNotability. I trust your opinion, but I also feel that time since account creation isn’t everything. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 23:44, 20 April 2023 (UTC)
Oppose for the reasons given at Special:Permalink/1150947285#WP:PERM clerking, and per GN above — it takes time and experience to build trust. I applaud your enthusiasm, but you can be plenty helpful without EFN while that experience (and trust) builds — TheresNoTime (talk • they/them) 02:19, 21 April 2023 (UTC)
Oppose need more time as per GeneralNotability. EFH should probably have a "at least 6 months of activity" requirement, as I wouldn't support anyone with less than that account age. Galobtter (talk) 05:45, 21 April 2023 (UTC)
Might this be something to start an RfC on to add this to policy, because that seems to be what these opposes are based on? Schminnte (talk • contribs) 07:01, 21 April 2023 (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.
  • Adding this note post the closing of the section. Illusion is very talented and extremely active. I would support his application once a few more months go ahead with evidence of learning (which they are already displaying). Warmly, Lourdes 18:26, 21 April 2023 (UTC)

Expanding 247 (email additions) to all namespaces?

From the discussion here, it seems like the consensus is that new users who add their own emails should have those edits reverted and suppressed. Special:AbuseFilter/247 currently disallows email additions to article and Wikipedia space, and I tested running the filter on contributions to other namespaces here. Most of the additions there are of personal emails, with those that are not being of the spam variety, so it seems like a very good idea to me to disallow those additions (when disallowing they would receive the friendly message given here). Any thoughts? Galobtter (talk) 07:45, 15 April 2023 (UTC)

I cannot access the page you linked (because I am not an EFH or EFM), but I trust your judgement on what these have shown. I support setting this to more namespaces if other users that can see private filters also agree. It seems like a no-brainer idea to me. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 19:16, 15 April 2023 (UTC)
This should at least apply to the talk namespace; there's basically no reason for anyone to put their email there. But some users like to keep a public email address. If this filter to also apply to userspace, what guidance should we offer to users to come to WP:EFFPR saying "Yes, please, I really want my email on my userpage, can you please add it because the filter won't let me?" In the test filter's log, I found one address belonging to a Ph.D., and another to a 10-year-old (now oversighted). But most cases aren't so obvious, and I don't want to be the one to share a child's personal information. Suffusion of Yellow (talk) 21:31, 15 April 2023 (UTC)
I think they can be told to use {{no spam}} and readd it themselves. The Ph.D person links to his university page where his email is similarily obfuscated to prevent spam, so it seems reasonable to me to tell people to at least make sure they don't get spammed. Galobtter (talk) 21:42, 15 April 2023 (UTC)
I agree. The filter should 100% not allow it on all talk pages. Just a thought, but we could make the filter only apply to non-extended confirmed users to prevent false positives. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:32, 15 April 2023 (UTC)
It only applies to editors with less than a 100 edits. Galobtter (talk) 01:25, 16 April 2023 (UTC)
I was unaware of this, @Galobtter. If the filter only applies to users with under 100 edits, than I support extending the filter to cover all namespaces. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:14, 16 April 2023 (UTC)
 Done, expanded to all namespaces. I'm open to excluding user space if that becomes a problem. Galobtter (talk) 23:17, 21 April 2023 (UTC)

Discussion at WP:Edit filter helper § RfC for Edit Filter Helper change

 You are invited to join the discussion at WP:Edit filter helper § RfC for Edit Filter Helper change. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:28, 23 April 2023 (UTC)

Set filter 631 to warn

  • 631 (hist · log) ("Extraneous toolbar markup", public)

Looking through the recent hits, most of the edits are vandalism or tests. I think there would be some false positives setting to disallow, so I think we set it to warn for now (with a helpful warning message) and re-evaluate in ~1 month about setting to disallow. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:05, 26 April 2023 (UTC)

Ugh, that filter was outdated. I've updated it to match what the toolbar buttons actually do, in 2023. I may have introduced a new source of FPs, so let's wait on any changes. If we're going to set this to warn, we should remove <ref></ref> at least, if they've added a reference at all, that's a win, even if they formatted it as <ref></ref>https://some.reliable/source.html. Suffusion of Yellow (talk) 23:44, 26 April 2023 (UTC)
Thanks for updating it! - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:42, 27 April 2023 (UTC)

39 Disallow

Looking through the recent hits, I can really only see vandalism. I think setting filter 39 to disallow would be helpful in preventing school page vandalism and there would be few false positives. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 21:24, 30 April 2023 (UTC)

Not the first time it's been proposed, and I'm not a fan. I think you need to look beyond the hits (where I've definitely seen false positives) and ask whether any of these situations are possible: the title matches but it is not an educational institution; someone was notably sacked or expelled; the word 'drugs' has any place in a school article, some teacher commits abuse or sex crimes, a porn actor is an alumnus, the list goes on. These edits are indeed worthy of review, but they're not all vandalism. If there's going to be a disallow filter, it should be another one, IMO. -- zzuuzz (talk) 21:48, 30 April 2023 (UTC)
Yeah, this is a case where Wikipedia:Deferred changes would be lovely but a disallow isn't possible (I too have looked at the filter and seen false positives also). Galobtter (talk) 21:54, 30 April 2023 (UTC)
I think that all the scenarios you propose are very rare and are outweighed by the amount of vandalism prevented. I think our FP system is capable of handing the small possible number number of false positives this change will cause. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:12, 30 April 2023 (UTC)
And it only applies to non-confirmed users too. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:14, 30 April 2023 (UTC)
Non-confirmed users are editors too - we still need to make sure there's a low enough false positive rate. Galobtter (talk) 00:19, 1 May 2023 (UTC)
Agree - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:33, 1 May 2023 (UTC)

Filter 1248

1248 (hist · log) ("Numeric change without summary", public); Originally discussed at WP:VPT#Numerical changes without edit summary should be flagged "r" in watchlist

Set filter 1248 to tag after tripping a rate limit.

Skimming at filter 1248 hits, there seem to be no false positives, so could it be set to tag as possible vandalism after 2 trips in 30 seconds and we can see if it's got any false positives in a few weeks. Zippybonzo | Talk (he|him) 11:33, 30 April 2023 (UTC)

@Zippybonzo: It's not possible to a apply a rate limit to an action; the limit applies to the whole filter. There are two problems with applying a rate limit to the filter. First, this is a really common form of one-off drive-by vandalism. Second, every time there's a football match or whatever, some IP goes and updates all of the players' statistics in rapidfire fashion, with no summary. Not ideal, but hey, the sausage gets made. For example, I haven't checked but I doubt 188.164.221.51 is vandalizing.
That said, we're not even up to 24 hours and the filter already has 1200 hits. No one's going to review them all. We need some way to cut it down. I've done a bit of testing, and just adding !(new_wikitext irlike "Category.*(?:sport|ball)") cuts down hits to about a third. That's a somewhat arbitrary exclusion, but hopefully there are enough obsessive fans of each player or team to spot any vandalism. But I'll take any other suggestions. Suffusion of Yellow (talk) 18:46, 30 April 2023 (UTC)
Excluding sportsball pages would make sense to me – not only is there a base of readers knowledgeable enough to catch errors, but the consequences of statistics being wrong on these pages are much lower than in other topic areas. – bradv 01:05, 1 May 2023 (UTC)
I agree with excluding sports pages. Would it also help to exclude matches of filters 391 and 712? Many of the hits for these filters involve numerical changes. Mori Calliope fan talk 01:28, 1 May 2023 (UTC)

Disable 1,248

When patrolling the edit filters for vandalism, I have recently seen the filter log flooded by 1248 (hist · log). I also have found that changing numbers without an edit summary is usually not vandalism. This can be updating scores from an athletic event, updating an athletes record, etc. I think we should disable the filter because of too many hits it is flooding the log and because most of the edits aren’t vandalism. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:54, 1 May 2023 (UTC)

Oppose: The filter works, and it can catch a lot of subtle vandalism, and if they aren’t trying to vandalise, they should just use a summary. Zippybonzo | Talk (he|him) 11:08, 1 May 2023 (UTC)
Hi Zippybonzo! Nice to talk to you again. I have to say that I no Disagree with you here. Some editors may not know what an edit summary is, or what they are for. This doesn’t mean that their edits are vandalism. Looking in the hits, most edits are not vandalism and they are flooding the feed. This is why the filter should be disabled for now. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 11:14, 1 May 2023 (UTC)
@Illusion Flame, I agree, and it’s just a case of finding the way to perfect it. I’m thinking about exclusion of IPs so that it’s not flooding it but there will be some test data coming in to review. Thanks, Zippybonzo | Talk (he|him) 11:23, 1 May 2023 (UTC)
@Illusion Flame: in the thread above there is a suggestion to exclude athletic articles from the filter – would that make a difference? – bradv 15:49, 1 May 2023 (UTC)
I added the sports page exclusion; let's see how that goes. Suffusion of Yellow (talk) 18:56, 1 May 2023 (UTC)
Thanks and good idea. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:05, 1 May 2023 (UTC)

Edit filter manager for User:0xDeadbeef

EFM granted. -- zzuuzz (talk) 20:53, 1 May 2023 (UTC)

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.

0xDeadbeef (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 · ev · fm · mms · npr · pm · pc · rb · te)

Hello everyone, about two months ago I applied for edit filter helper rights and after working with edit filters for some time I think I am ready to help with editing edit filters. Through helping with false positive cases for some time, I have had times where I felt having the right would help process the cases faster. For example here I suggested a valid edit to the edit filter in question that required 18 days to be actually implemented. Another example is at Wikipedia:Edit filter/Requested/Archive_21#Talk page junk where I helped with creating an edit filter that was eventually set to disallow. I'll admit that my version is quite crude compared to the one Galobtter actually created, but I think that the best way for someone to improve their skill in editing filters is for them to start edit filters. (the same goes to just editing in general) I have 2FA enabled on my account and if I become an EFM I will ensure that each change is sound. (for details on my technical experience see my request for EFH)

Thanks for your consideration. 0xDeadbeef→∞ (talk to me) 10:20, 24 April 2023 (UTC)

information Administrator note advertised this at WP:AN. — xaosflux Talk 18:20, 24 April 2023 (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.

Change name of #247

247 ’s name is “adding emails in articles.” It should be changed to “adding emails to pages” because the filter covers more namespaces than just article. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:30, 5 May 2023 (UTC)

Changed to just "Adding emails". 0xDeadbeef→∞ (talk to me) 13:01, 5 May 2023 (UTC)
 Thanks - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 14:42, 5 May 2023 (UTC)

EFM Needed

Could an edit filter manager look at the top request of the false positives page and weigh in their opinion. Thanks! - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 18:38, 6 May 2023 (UTC)

EFM/EFH Need on EFFP

Please see the report on the top of the page. Looks like it could be a false positive. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 21:15, 18 May 2023 (UTC)

Set filter 1253 to disallow

Sorry, but there WILL be FPs. Open proxy attack. Also Ingenuity (talk · contribs) is working on another filter. Suffusion of Yellow (talk) 02:29, 25 May 2023 (UTC)

I can’t see the filter, but I trust your and @Ingenuity’s judgment on this. I am always here to help handle false positives. :) - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:44, 25 May 2023 (UTC)
Can this filter be disabled for now? I am noticing many FPs from this filter, which I think is supposed to only catch repetitive addition of nonsense. Mori Calliope fan talk 19:52, 27 May 2023 (UTC)
Replied by email. Suffusion of Yellow (talk) 20:27, 27 May 2023 (UTC)
Don’t mean to be nosy, but I was wondering what the same thing as @Mori Calliope fan. If you get a chance @Suffusion of Yellow, could you send a copy to me? Thanks! - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:39, 27 May 2023 (UTC)
Done. Suffusion of Yellow (talk) 20:42, 27 May 2023 (UTC)
 Thanks - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:47, 27 May 2023 (UTC)

642 change

642 currently prevents the adding of VRT template by non-VRT members. I was wondering if this could be changed to also prevent the removal of VRT template as there is currently a request on the VRT Noticeboard where a user removed the template and we are waiting for a VRT agent to re-add it. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 11:35, 30 May 2023 (UTC)

Change page on filter 320

Filter 320 ("Your mom" Vandalism) apparently excludes the page Maternal insult, but was moved to "Yo mama" joke, so the page needs to be changed. 2NumForIce (speak|edits) 23:14, 1 June 2023 (UTC)

 Done — Ingenuity (talk • contribs) 23:19, 1 June 2023 (UTC)

Proposed merger of SpamBlacklist and AbuseFilter

Tracked in Phabricator
Task T337431

Please comment at phab:T337431. Suffusion of Yellow (talk) 19:19, 2 June 2023 (UTC)

Easier reporting of false positives

Presently, any time someone is affect by a false positive, they are told (by Mediawiki:Abusefilter-disallowed and related messages) to "report this error". Whereupon they are taken to WP:EF/FP and have to click another link to actually make the report. Why not skip a step?

Old message:


New message:

Note, also, that we can now pre-fill the page name!

Questions:

  • Does this seem like a good idea? Yes, it means more spurious EFFP reports, but also more good ones, too.
  • Should this be the default for all messages? All "disallow" messages but not "warn" messages? Or only a few messages?
  • It's technically possible to automatically include either the filter id or the filter description in the report. I decided to leave that out per BEANS, but should either be included?
  • I wanted to also prefill the username, so we can get rid of that {{subst:currentuser}} crap in Template:False positive/Preload, but couldn't figure out how. It seems {{REVISIONUSER}} doesn't work in edit filter messages. Can anyone figure out a way?

To see this actually in action, go to WP:EF/MT and attempt to make any edit. Suffusion of Yellow (talk) 21:24, 28 May 2023 (UTC)

This is a great idea! I strongly support this change of adding the button. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:51, 28 May 2023 (UTC)
This is a great idea. I'm not sure if the subst:currentuser thing can be removed. {{subst:currentuser}} already substitutes REVISIONUSER anyways. (by the way, is there documentation for how the filter message is rendered? Are there magic words that we can use in those messages to retrieve additional data?) 0xDeadbeef→∞ (talk to me) 00:08, 29 May 2023 (UTC)
I know of no such documentation; it was just trial and error on testwiki. I know that $1 is the filter description and $2 is the filter ID. {{FULLPAGENAME}} works, but {{REVISIONUSER}} doesn't, probably because it's technically an "edit notice" and {{REVISIONUSER}} isn't allowed in editnotices. I was able to get get of currentuser/REVSIONUSER in the preload by moving it "down a level" to {{False positive}}. But it's still in the section title, which looks ugly. Suffusion of Yellow (talk) 21:59, 31 May 2023 (UTC)
Not as much participation here as I had hoped, but I'll interpret it as WP:SILENCE. So unless anyone else objects, I'm going to put in an edit request to make this change to Template:Edit filter warning. Also:
  • For now, I don't want to change the wording of MediaWiki:Abusefilter-disallowed and related messages; the message is rendering funny in the Android app, and I'm not sure if "click the button below" makes sense to screen reader users. Also there are about 35 messages to update! There's no harm in a redundant link.
  • The button will only show in disallow messages, not warning messages. Why? Because unless you open the link in a new tab, you're abandoning your edit. Let's not make the link too inviting.
  • Individual messages can be opted out or in with the fplink parameter.
  • I'm not including the filter description or id, even though that's public information. I doubt many drive-by vandals know how to find their abuse log, so let's not say "this is the exact thing you were doing; stop doing that and your edit will save".
Suffusion of Yellow (talk) 22:12, 2 June 2023 (UTC)
Green tickY Sounds good to me! - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:14, 2 June 2023 (UTC)
Seems like a good idea, thanks for doing. Making it easier to report FPs is definitely a good thing. Galobtter (talk) 18:11, 11 June 2023 (UTC)

Support administrator rights to test filters?

I recently requested administrator rights on Wikipedia’s TestWiki to test possible filter changes, while reviewing false positives reports, to help the wiki. Xaosflux said that some community support for this would help the granting process. How do you feel about this? Simply respond to this post with your support, or lack thereof. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 15:35, 1 June 2023 (UTC)

FYI: testwiki:Wikipedia:Requests/Permissions/Illusion Flame. — xaosflux Talk 15:57, 1 June 2023 (UTC)
@Illusion Flame: I really doubt this will be as useful as you imagine. There's no way easy way to test hits from enwiki on testwiki, unless "someone" writes a script to do so. But if you really want this, I have no objection to a temporary grant. Please be careful. Suffusion of Yellow (talk) 18:41, 2 June 2023 (UTC)
Yeah, I see your point. I would also like access to the testing tools, specifically the ones that let you check for errors in the code. I think it would generally still be helpful, just not as helpful as I anticipated. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 18:55, 2 June 2023 (UTC)
@Illusion Flame, I know that you have already mentioned you would rather use a Wikimedia Foundation wiki, but for fortestwiki.myht.org has AbuseFilter installed, and has a strong privacy policy with minimal logging, and I hold a few rights there and would be able to grant you the administrator rights if you wish. Zippybonzo | Talk (he|him) 19:19, 2 June 2023 (UTC)
I appreciate the suggestion, but I would really like to stay on WikiMedia Foundation wikis only. As a computer geek, I understand IPs and User agents, that the checkuser tools shows. I really don’t trust some random wiki owner with access to my personal IP and user agent. I hope you understand. Do you support me accessing Wikipedia’s own testing wiki? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:12, 2 June 2023 (UTC)
@Illusion Flame Support for temporary grant - I would support for a 3 month grant for the explicit purpose of testing filters, if there is good quality (IMO) filter authoring then I would support a renewal for another 3-6 months. You may however want to consider hosting your own MediaWiki install, but I imagine testing filters is easier on wiki with other users to provide assistance. I do agree with not trusting random people with your IP. Thanks, Zippybonzo | Talk (he|him) 21:30, 2 June 2023 (UTC)

EFM Needed

There are multiple reports on the false positives page that need attention from Edit filter managers. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 11:24, 12 June 2023 (UTC)

@Illusion Flame Go to wikipedia-en-editfilters on IRC and someone can probably help there. Zippybonzo | Talk (he|him) 11:30, 12 June 2023 (UTC)

Set 1252 to disallow

1252 : See Wikipedia:Edit filter/Requested/Archive_21#Filmcompanion and MediaWiki talk:Spam-blacklist/archives/May 2023#Filmcompanion.in. TrangaBellam (talk) 04:49, 1 June 2023 (UTC)

Someone needs to add a disallow message before this can be set to disallow. 0xDeadbeef→∞ (talk to me) 04:52, 1 June 2023 (UTC)
Maybe use something like, "An automated filter has identified this edit as potential spam, so it has been disallowed. If this edit is constructive, please click the button below. Disruptive behavior may result in being blocked from editing."? I borrowed the language from Suffusion's template, two threads above. TrangaBellam (talk) 04:56, 1 June 2023 (UTC)
It's probably better to have something specific to spam blacklists (the same as the spam blacklist message). 0xDeadbeef→∞ (talk to me) 05:11, 1 June 2023 (UTC)
@0xDeadbeef: Suggest something, please? I am not really well versed with these filters etc. TrangaBellam (talk) 05:20, 4 June 2023 (UTC)
Don't have time for it right now, but I think something similar to MediaWiki:Spamprotectiontext could help. The problem is that the user wouldn't know which specific link triggered since edit filters don't support showing which part. 0xDeadbeef→∞ (talk to me) 18:08, 4 June 2023 (UTC)
So, what's the way out? Suffusion of Yellow, I will appreciate some aid. TrangaBellam (talk) 16:59, 18 June 2023 (UTC)
Right now, there's only one (1) domain in filter 1252. So let's just hard-code the link into the filter message. If we want to add a dozen domains or so, then we can just list them in a table, as with MediaWiki:Abusefilter-warning-predatory. If we want to add hundreds of domains, then we'll cross that bridge when we come to it. (And, TrangaBellam, I will get around to this in a day or so if no one else does.) Suffusion of Yellow (talk) 02:37, 20 June 2023 (UTC)
Ok, really simple, but:
@TrangaBellam:, anything you want to add to that? Under what circumstances might such an talk request be approved? Suffusion of Yellow (talk) 00:07, 21 June 2023 (UTC)
This is all fine; I presume that such requests will be (ought be?) approved for all films emanating out of India. But I can ping the FilmProject guys, if you want confirmation. TrangaBellam (talk) 09:15, 21 June 2023 (UTC)

Is there a consensus?

I am unclear my friends. Why is this edit filter required? If we have the website in the blacklist, why should we allow editors to selectively add this? Do please advise. Warmly, Lourdes 05:12, 19 June 2023 (UTC)
Read the linked discussions? The EF is designed so that the link can be whitelisted. We are talking about a highly reliable website which, regrettably, has been spammed into our articles. TrangaBellam (talk) 03:41, 20 June 2023 (UTC)
The website you quote is run by the wife of a film producer and that has a few journalists other than her, and opinion-editorial contributors, it seems. I see significant amount of content that seems paid for. Some movie reviews by her and unnamed persons seem watchable though. Why would you consider this a reliable source? It seems a puff-piece site. I may be horribly wrong here though. Let me know. Lourdes 06:46, 21 June 2023 (UTC)
Also, I don't see any discussion where consensus has been reached for white-listing this site. Can you please give me the exact discussion where consensus is clear on this? Thank you again. Lourdes 06:47, 21 June 2023 (UTC)
Consensus on whitelisting can be located at this thread; see sysop BlackKite's final reply: Yeah, that seems reasonable.
Consensus about the reliability of the site can be found at this thread. You are indeed horribly wrong, as is (regrettably) often the case — 1, 2, etc. TrangaBellam (talk) 08:54, 21 June 2023 (UTC)
Thank you TrangaBellam, I see a discussion on a noticeboard dedicated to local films in your link where there is some discussion on this link. I don't consider this as consensus to whitelist. Others can of course have a differing opinion, but I would not support whitelisting based on this discussion. Warmly, Lourdes 10:18, 21 June 2023 (UTC)
Collapsing discussion that went off the rails. Will seed an RSN discussion soon. Abecedare (talk) 21:08, 21 June 2023 (UTC)
Okay - I could not care less about your support. I count six editors — me, Krimuk2.0, Shshshsh, DaxServer, BlackKite, and Kailash29792 — in support of whitelisting and two editors — you and Ravensfire — in opposition. TrangaBellam (talk) 11:37, 21 June 2023 (UTC)
Hi TrangaBellam. I've never interacted with you or Lourdes before, but I have this page on my watchlist, and I find the first sentence of your last comment, and the last sentence of your second to last comment, to be pretty serious personal attacks / WP:UNCIVIL. You should strike or remove those right away before this escalates. –Novem Linguae (talk) 19:36, 21 June 2023 (UTC)
Like, escalate where, Novem Linguae?
Lourdes has been censured by the Arbcom — a few months ago — and by the community — a week ago — for displaying a Randy-in-the-Boise attitude. Do you dispute these facts? Or, that it is the same behavior that is clearly at display, here, where she did not bother to consult the linked discussions — and/or peruse the fact that all the project regulars who edit articles on Indian films, having tens of thousands of edits and a cumulative count of over a dozen FAs, had argued the site to be among the most reliable sites of film journalism in India — despite being pointed in the direction but had an unusually strong opinion on how the site barely had any watchable content and was saturated with paid-for-coverage? TrangaBellam (talk) 19:54, 21 June 2023 (UTC)
Lourdes has been censured by the Arbcom — a few months ago — and by the community — a week ago — for displaying a Randy-in-the-Boise attitude. Respectfully, what does this have to do with edit filters? Seems to violate the principle Comment on content, not contributors. –Novem Linguae (talk) 20:07, 21 June 2023 (UTC)
Or, that it is the same behavior that is clearly at display, here, where she did not bother to consult the linked discussions [...] - I explained it, anticipating such a query. EF is not content and switching on EFs/blacklisting/whitelisting are affairs that fall under discretionary powers of an individual admin; no normal editor can meddle in these areas. So, conduct of a participating admin is indeed a fit affair for discussion esp. considering the recentness and unanimous nature of the censures. TrangaBellam (talk) 20:11, 21 June 2023 (UTC)

Change request on filter 380

Based on this false positive report, we should add Gay Times to the exclusions on filter 380, in the same manner we already exclude gay marriage, gay rights, and gay pride. Change is on line 3 of the filter and would involve swapping \bGAY(?![- ](MARRIAGE|RIGHTS|PRIDE)) to \bGAY(?![- ](MARRIAGE|RIGHTS|PRIDE|TIMES)). Sideswipe9th (talk) 18:14, 21 June 2023 (UTC)

+1 — Red-tailed hawk (nest) 02:21, 22 June 2023 (UTC)
 Done — Ingenuity (talk • contribs) 13:40, 24 June 2023 (UTC)

Two blanking tags

Filter 30 uses MediaWiki:tag-blanking, while the MW-level blanking detection uses MediaWiki:tag-mw-blank. Is there a reason for these tags to be different, or can the filter safely be switched to the MW one? -- Tamzin[cetacean needed] (she|they|xe) 18:23, 27 June 2023 (UTC)

Support consolidating tags. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:04, 28 June 2023 (UTC)

Template for EFFP

Could someone familiar with templates create another template for {{EFFP}} that says something like: No filter hits found from this username or IP address. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 15:30, 30 June 2023 (UTC)

There was an existing (albeit undocumented) code: {{EFFP|nofilterstriggered}}. I've added {{EFFP|nft}} as a shortcut, and I've modified a template transcluded to the docs page so that it displays in the list. — Red-tailed hawk (nest) 00:05, 1 July 2023 (UTC)

Filter name

I am not sure if this is a case of the filter having an inaccurate name or something else, as it's a private filter.
But I just wanted to point out <this log>, presumably abuselog:35434257, which reads "Promotional text added by user to own user(-talk) page", but which is about an attempt to add said content on the "User:" page of an IP address.

I have chosen to ignore the "Private filters should not be discussed in detail here" part of the template at the top, since this issue is likely with just the description of the filter (or at least an unimportant part of the filter), and because as an IP address I'm pretty sure I can't email people. You are welcome to not discuss it, or remove this post if I really shouldn't have made it.
– 2804:F14:808E:A601:21F6:A6D:DADF:F210 (talk) 21:35, 2 July 2023 (UTC)

"user(-talk)" encompasses both "User:" and "User talk:" pages, and the filter only operates on those pages, so the filter is properly named. — Mdaniels5757 (talk • contribs) 02:05, 3 July 2023 (UTC)
Well sure, but it wasn't their own "User:" page, is what I was pointing out. – 2804:F14:808E:A601:21F6:A6D:DADF:F210 (talk) 02:41, 3 July 2023 (UTC)
Oh, I see.
EFMs: It looks like on line 3 of the filter, it does not do what the title implies. Depending on the desired effect, either the parentheses should be reconfigured, or the title changed. I note that adding text to other people's userpages by new users is already disabled by filter 803 , although that mostly depends on autoconfirmation and filter 354 has a higher requirement than that. — Mdaniels5757 (talk • contribs) 03:03, 3 July 2023 (UTC)
Tweaked the title a bit... Lourdes 05:33, 3 July 2023 (UTC)

Abuse filter bypass that I noted earlier

There were some inflammatory edits by an IP that are now removed, but I noticed that in most of their talk page edits they substituted the letter C with the less-than symbol (<). This allowed them to say some rather unpleasant things to people on their talk pages.

Would it be possible for this bypass to be mitigated in some way? Assuming it isn't impossible due to something that I'm probably not thinking about.

Apologies in advance if this has already been discussed before, I am not familiar with the edit filter side of Wikipedia. Deauthorized. (talk) 00:32, 2 July 2023 (UTC)

Do you recall which IP editor? An admin could take a peek at the edits, which would be helpful for adjusting the edit filters. –Novem Linguae (talk) 01:39, 2 July 2023 (UTC)
@Novem Linguae It was 70.169.71.243. Sam Walton (talk) 09:37, 2 July 2023 (UTC)
Yeah, looks like they replaced "c" with "<" in many different cuss words. Doesn't look particularly readable though. Is this common? May not be common enough to be worth updating the filter. –Novem Linguae (talk) 09:48, 2 July 2023 (UTC)
@Novem Linguae: I've seen it a couple of times. Maybe it isn't enough for a filter update as of right now, but with how seemingly easy it is to do what they did I can't see how someone else wouldn't get the same idea.
Do you think you can keep track of it in the filter as a note? Just as a future reference. Deauthorized. (talk) 23:52, 2 July 2023 (UTC)
I'm not sure this is all that common. Replacing "c" with "(" would actually be a closer-looking substitution. Partofthemachine (talk) 01:12, 6 July 2023 (UTC)

Request for EFH right: CX Zoom

EFH granted. — Ingenuity (talk • contribs) 18:10, 7 July 2023 (UTC)

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.

CX Zoom (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 · ev · fm · mms · npr · pm · pc · rb · te)

Hi, I'm CX Zoom. I have over 15 thousand edits on English Wikipedia, and also am an administrator on pi: Wikipedia. I understand account security practices, regex, have no blocks or sanctions, and able to understand English. Currently, I need access to filters to enhance my knowledge about the workings of edit filters, so that I could replicate some of them at piwiki. In the future, if the need arises, I may also help with edit filters locally on enwiki when I understand it good enough. Thanks! —CX Zoom[he/him] (let's talk • {C•X}) 12:59, 28 June 2023 (UTC)

@CX Zoom Wouldnt WP:Test Wikipedia be the better place for this? Nobody (talk) 13:25, 28 June 2023 (UTC)
I'm not sure about that. I would like to study existing edit filters to understand how they work (regex), how a hit gets logged, etc. —CX Zoom[he/him] (let's talk • {C•X}) 13:39, 28 June 2023 (UTC)
Which private filters do you need to look at? The majority are public, so you shouldn't need EFH to view them.. — TheresNoTime (talk • they/them) 13:56, 28 June 2023 (UTC)
For now, I guess edit filters Special:AbuseFilter/397, Special:AbuseFilter/466, Special:AbuseFilter/739. There is some persistent vandalism by IPs (each one is a global vandal) since April where they create use pages of users with completely English content on various wikis, presumably copied from somewhere else. I wish to block them (using filters) on piwiki. —CX Zoom[he/him] (let's talk • {C•X}) 14:58, 28 June 2023 (UTC)
Sounds reasonable then 😊 support from me — TheresNoTime (talk • they/them) 07:42, 29 June 2023 (UTC)
As an aside, I am happy to send you the contents of those three mentioned filters for use on pi.wiki (providing they're also set to private of course) — TheresNoTime (talk • they/them) 08:40, 1 July 2023 (UTC)
Thanks, its very nice of you. Can you also point me to a filter that captures non-English characters? I'd need that but doing the exact opposite work (capture English characters). —CX Zoom[he/him] (let's talk • {C•X}) 09:16, 1 July 2023 (UTC)
I think that’s a better idea then granting EFH. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:21, 1 July 2023 (UTC)
I'd support EFH here. CX Zoom has a genuine need for the permission, and he can be reasonably trusted with this information. (non-EFH comment) –MJL ‐Talk‐☖ 16:14, 28 June 2023 (UTC)
This is an explicitly listed reason for requesting EFH, and I am not aware of any issues in CX Zoom's edits here that would call his trustworthiness into question, so I support. -- Tamzin[cetacean needed] (she|they|xe) 05:51, 29 June 2023 (UTC)
Support temporary grant until January 1st 2024 as that is how long their sysop rights last. They aren’t actively involved enough edit filter wise to hold the rights after sysop expires. If a temporary grant isn’t possible, I oppose as filters are very sensitive. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 13:34, 29 June 2023 (UTC)
As I understand it you're requesting EFH on the basis that you'd like to learn about them to help on piwiki, however you only have one logged action and one edit there since January. IANAEFH but based on your current piwiki activity level, I'm hesitant about how useful this is likely to be to you -- do you intend to increase your activity there? Thanks, Giraffer (talk·contribs) 17:12, 30 June 2023 (UTC)
That’s a good point. Until this question is answered, I’m opposed. This almost looks like WP:Hat collecting. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 17:24, 30 June 2023 (UTC)
piwiki is a low activity wiki, so I don't spend a lot of time there. When I became an admin about 1.5 years ago, I did some work reorganising things, and deleting obvious vandalism, now there's not much left. I still visit piwiki every 2-3 days to look out for vandals. In most cases, stewards took care of vandalism within an hour or so of vandalism, so I did not need to work. Once, I found a vandalised page that was not deleted, I chose to inform the steward/global admin who left the deleting work mid-way, because I could not delete the vandalised pages on other projects, and chose to not delete it myself because I feared it may interfere with any scripts they might be using for mass cleanup. As for activity level, I do intend to increase it, although that may not translate to admin-work because as I said, not a lot to do there for now. —CX Zoom[he/him] (let's talk • {C•X}) 17:51, 30 June 2023 (UTC)
I appreciate your honesty, but that doesn’t encourage me to support at all. Your very limited activity on the wiki you wish to add filters to, along with the fact that the sysop rights are temporary, makes me have to oppose. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 17:54, 30 June 2023 (UTC)
I'll leave the boldvoting to the EFMs/EFHs, but it seems contradictory to request a very sensitive permission to work on filters at piwiki and then say that piwiki is a low activity wiki, so I don't spend a lot of time there and that there is not a lot [of admin work] to do there for now. Your response doesn't really alleviate my concerns, but I'll defer to others' judgement; if everybody else here is happy then it's fine by me. Giraffer (talk·contribs) 21:43, 30 June 2023 (UTC)
Let me attempt to clarify, piwiki is a low activity wiki, but most of the activity that exists is basically IP vandals. Right now, I have little admin work to do except keeping them away, which is why I'm here. As admin, I already have the ability to set edit filters there, but I need to know better how to use one. —CX Zoom[he/him] (let's talk • {C•X}) 22:22, 30 June 2023 (UTC)
Support Trustworthy user, has a good reason for requesting the permission. Partofthemachine (talk) 22:09, 30 June 2023 (UTC)
Did you read the discussion just above this? If so, could you provide some input further to help us reach consensus? Thanks! - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:11, 30 June 2023 (UTC)
Support trustworthy, and sysop on a production project. Zippybonzo | Talk (he|him) 08:56, 1 July 2023 (UTC)
Neutral. I don't think you are hat collecting, but I do find the level of demonstrated need for EFH to be a bit low. piwiki doesn't have any abuse filters right now, and I would support after you have worked with edit filters (either on enwiki by suggesting fixes to filters for false positives or on piwiki by creation of filters) for some time and gained some experience. That said I am not opposed to requesting contents of filters on a per-filter basis. 0xDeadbeef→∞ (talk to me) 08:20, 7 July 2023 (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 1151: fix for false positive

Hi! In order to fix Wikipedia:Edit filter/False positives/Reports#Jay1661, could an EFM please make the following change to line 12 of filter 1151?

−
!(page_title irlike "sandbox|correct typos in one click|missing encyclopedic articles") &
+
!(page_title irlike "sandbox|correct typos in one click|missing encyclopedic articles|fix common mistakes") &

Best, — Mdaniels5757 (talk • contribs) 14:34, 6 July 2023 (UTC)

This has been  Done by 0xDeadbeef. — Ingenuity (talk • contribs) 18:16, 7 July 2023 (UTC)

Nomination for Red-tailed hawk as EFM

EFM granted. — Ingenuity (talk • contribs) 19:36, 8 July 2023 (UTC)

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.

Red-tailed hawk (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 · ev · fm · mms · npr · pm · pc · rb · te)

Happy Canada Day everyone!

I would like to go ahead and nominate Red-tailed hawk (talk · contribs) for EFM. Over the past while, RTH has been coming to me with EFM change requests. As I've reviewed each proposed change, not only have I seen minimal errors, but the changes also are damage aware - meaning the changes often reflect an awareness of potential false positives they could create whether forward or reverse. Beyond that, their understanding of regex is now going beyond mine, and they have to explain regex to me to be able to put it in. This is the exact reason I went for adminship back in 2011 - heck I'm old. They also frequent EFFP to handle the colleterial that others have caused.

All that to say I think they are ready to take on the role and would handle it with both respect and understanding. -- Amanda (she/her) 18:41, 1 July 2023 (UTC)

Hello all!
I'm Red-tailed Hawk. I joined Wikipedia in 2019 and I've been an edit filter helper since January, during which time I have become experienced with the abusefilter's syntax for regular expressions. Elsewhere, I'm an administrator on Wikimedia Commons and a VRT permissions agent. In my capacity as an EFH, I've mostly performed two tasks: helping EFMs to create and debug regex and responding to requests at WP:EFFP. If granted the Edit Filter Manager right, I would use it to write and implement changes to the abuse filter in response to false positive reports, in addition to performing the tasks that I have performed as an EFH.
I understand the sensitive nature of the edit filters, as well as the potential for bad changes to edit filters to negatively affect the project. With respect to account security, my account has two-factor authentication enabled and I've created a second account (Red-tailed sock) for use on public/shared/less-secure connections.
I would like to thank Amanda for pushing me towards making this request, and I gratefully accept the nomination. — Red-tailed hawk (nest) 19:28, 1 July 2023 (UTC)
Support, no issues. Zippybonzo | Talk (he|him) 19:32, 1 July 2023 (UTC)
It appears there isn’t a support template @Zippybonzo. You may want to fix it. I would for you, but don’t want to WP:CANVASS. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 19:47, 1 July 2023 (UTC)
@Illusion Flame Can you fix it for me, as I'm short of time right now. Thanks, Zippybonzo | Talk (he|him) 20:41, 1 July 2023 (UTC)
 Done. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:55, 1 July 2023 (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.

filmcompanion.in

filmcompanion.in has been removed from the spam blacklist. Thank you all for the discussions, Lourdes 09:29, 9 July 2023 (UTC)

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.

Per the consensus here, I would suggest removal of filmcompanion.in from the spam blacklist, irrespective of whether we currently have an edit filter for that or not. We can continue to monitor the spamming, if at all it is still continuing, and then take a decision to create an edit filter. Requesting views on this. Thank you, Lourdes 03:57, 5 July 2023 (UTC)

  • Unless there are implementation or performance concerns, I think it would be a good idea to have an edit filter set up to log addition of links to filmcompanion.in. That will help detect if spamming has resumed, and if it has, guide us as to whether the filter should be set to block addition of links by non-auto-confirmed editors or by non-extended-confirmed editors too. Abecedare (talk) 05:53, 5 July 2023 (UTC)
We already have link spam catching filters active here. I would suggest we don't have to wait for a specific filter to be created on filmcompanion for us to remove it from the blacklist... Pinging someone who works with the blacklist for their views. Lourdes 09:14, 6 July 2023 (UTC)
I'm not going to remove it from the blacklist, but I won't object if someone else removes it. OhNoitsJamie Talk 02:28, 7 July 2023 (UTC)
Abecedare, TrangaBellam, as mentioned, we have spam filters in place (not listing them here). Do we have a consensus to remove this title from the blacklist now? I am good to go on this. Lourdes 05:37, 8 July 2023 (UTC)
Sounds good to me. Abecedare (talk) 05:46, 8 July 2023 (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 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)

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)

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)

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 48,244,996 "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 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. DatGuyTalkContribs 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)
I've made an exception for the use of that template. — Red-tailed hawk (nest) 14:32, 26 July 2023 (UTC)
Another report for the same issue: Special:AbuseLog/35586518. — Red-tailed hawk (nest) 14:00, 26 July 2023 (UTC)

Filter 869 addition

Project Veritas was deprecated in a recent RfC. Could an admin update edit filter 869 to include the relevant URLs? The URLs are "projectveritas.com" and "okeefemediagroup.com". Isi96 (talk) 23:52, 30 July 2023 (UTC)

Project Veritas has already been deprecated for a while, it was just O'Keefe Media Group that was deprecated recently. Partofthemachine (talk) 00:41, 31 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)
The IP user could have just been patrolling edit filter hits, so I don't think this is a clear case of GHBH 0xDeadbeef→∞ (talk to me) 03:21, 31 July 2023 (UTC)

"Rapid Disruption III"

(Private filter, ID not known). What exactly is going on here? Taking Out The Trash (talk) 23:33, 2 August 2023 (UTC)

I've changed the filter so that WPCleaner edits don't trigger it. — Ingenuity (talk • contribs) 23:45, 2 August 2023 (UTC)
This happens because sockpuppets often try to gain autoconfirmed/extconfirmed permissions by rapidly making edits where they add a single whitespace character. Partofthemachine (talk) 23:51, 2 August 2023 (UTC)

260 and 384 needs update

See: Special:AbuseLog/35642320

I would recommend 260 and 384 to have a lowercase letter l (L) added to the regex for "alternatives" to the letter I for this word. DarmaniLink (talk) 22:28, 4 August 2023 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter_noticeboard/Archive_11&oldid=1170631268"