@Crow, JzG, and Jo-Jo Eumerus: Should we be exempting bots from Special:AbuseFilter/894? I see AvicBot is regularly showing up in the logs. — MusikAnimal ^talk 15:36, 7 January 2018 (UTC)

To me that sounds more like a flaw in the filter; I don't think that the edits in question should be caught by the filter at all, seeing as they aren't changes that add a link to a self-published source. Jo-Jo Eumerus (talk, contributions) 15:40, 7 January 2018 (UTC)

What Jo-Jo said. Guy (Help!) 16:38, 7 January 2018 (UTC)

You can use added_links but this is expensive, so first check added_lines to wean out more edits. See Special:AbuseFilter/892 for an example. Leaving it to Crow or other authors to fix, as I'm not sure what the URLs should be. In the meantime I have fixed the double-redirects that AvicBot was trying to make. — MusikAnimal ^talk 16:49, 7 January 2018 (UTC)

Bots generally aren't adding anything that wasn't there before, so excluding them might be worthwhile, though on the flip side it does alert us to such a situation that might not have been seen without that edit. This particular case was just due to a page move, so unless a title-war breaks out, this specific case is unlikely to recur. I suspect that parsing the username for bot$ should catch all bots since we don't let user accounts end in "bot". @MusikAnimal: Is user_name sufficiently cheap as an excluding condition, or does that bring in the SQL engine? Crow^Caw 17:33, 7 January 2018 (UTC)

I'm not certain, but checking user_groups is the more common way to do this and is also cheap. Here we only care about references though, right? In that case I would recommend using added_links (in the same way as 892). Otherwise any mention of these sites will trigger the filter, which I think would constitute a false positive — MusikAnimal ^talk 17:40, 7 January 2018 (UTC)

Bot usergroup excluded. Hoping to avoid using added_links for cost... maybe changing the added_lines to be the entire link with http?:// would accomplish the same thing and avoid firing just on a mention of the company? Crow^Caw 17:59, 7 January 2018 (UTC)

added_links is expensive, but it's the only sure-fire way to avoid the false positives with merely mentioning the source, barring some very complicated regex that is also not-so-cheap. If you're first checking added_lines you're cancelling out the vast majority of edits, and hence the expense part is only happening when necessary, so I think it is acceptable in that case. — MusikAnimal ^talk 18:32, 7 January 2018 (UTC)

• Sounds good! Crow^Caw 19:01, 7 January 2018 (UTC)
• Tried that and when testing against recent non-bot hits, it looks like a lot of these often have the Link be books.google.com, with the SPS listed only as the publisher in the ref tag, so many recent hits would slip through. For now I'm testing expanding the string to include the variable, e.g. "Lulu.com" --> "upblusher=Lulu.com". Might need to Norm these to catch spaces, caps, etc... thoughts? Crow^Caw 19:52, 7 January 2018 (UTC)

See 898 for a discussion with myself. Apart from 139, does anyone happen to know of any filters which need fixing? Κσυπ Cyp   17:36, 13 January 2018 (UTC)

Unfortunately, that variable is not really cheap :( I would avoid using it unless you have to, or do like we do in 139 and run another check before using it (see line 7) — MusikAnimal ^talk 17:45, 14 January 2018 (UTC)

I meant that I tried fixing line 7 in 139, and was wondering if there are any other important filters with a corresponding line to fix. Κσυπ Cyp   20:40, 14 January 2018 (UTC)

Ah I see. Sorry, I failed to read all of your self-discussion =p There are no other filters that I can think of off the top of my head that need this fix. Good catch, by the way!

One other picky complaint... I would discourage enabling any actions on test filters, unless you are doing it as part of a test. It's mainly the title that I think others may find misleading (e.g. why did a test filter disallow my edit?). There are some shared multi-purpose filters like 684, but in my opinion the life of a particular filter, much like a wiki page, should broadly be about the same subject/purpose. — MusikAnimal ^talk 02:43, 15 January 2018 (UTC)

Ok, thanks for the reply. It's ok, my self-discussion did get a bit long and rambling.

I've disabled my test filter, it didn't catch anything anyway. Κσυπ Cyp   15:38, 16 January 2018 (UTC)

Edits such as this trip a tag (visualeditor-wikitext reading "2017 source edit" but it's 2018. It's not immediately obvious that this is for the 2017 wikitext editor, so is there a more intelligible way to word this? Maybe just omit "2017"? ―Justin (koavf)❤T☮C☺M☯ 00:01, 16 January 2018 (UTC)

It's called the 2017 wikitext editor. It's also referred to as the "modern wikitext editor" or the "new wikitext editor". I'm not sure changing it is necessary at this time since the year doesn't refer to the time in which the edit is made, but rather the year in which the editor was built. Nihlus 00:10, 16 January 2018 (UTC)

I understand that but it's just not immediately clear. I'm suggesting that changing it to "modern wikitext editor" is a superior choice for this reason. ―Justin (koavf)❤T☮C☺M☯ 23:32, 16 January 2018 (UTC)

But "modern wikitext editor" won't really make sense in the future if they come out with another build. "2017 source edit" is very specific about what it describes. I mean, I guess it could be changed to "2017 wikitext editor", but whatever it is, I feel the year is important. Nihlus 23:40, 16 January 2018 (UTC)

This tag is added by MediaWiki, not an edit filter. From Special:Tags you can edit the appearance and description, but I agree the "2017" is intentional, although a bit misleading. — MusikAnimal ^talk 05:32, 17 January 2018 (UTC)

Lots of good hits recently, low risk of false positives - TNT^❤ 22:57, 20 January 2018 (UTC)

See Special:Permalink/821983789#Krystal Structure, which is another reminder that some of our shared filters have grown out of proportion over the years. I think this one in particular could use a pruning. There only have been a handful of changes to it in the past two years, which makes me think a lot of it probably isn't relevant today. Pinging the primary author NawlinWiki (who seems to be only semi-active). If anyone else sees anything they are familiar with, perhaps you will know whether or not it is still needed, and update the filter accordingly. I almost want to suggest us starting over entirely, or just remove the more generalized regex strings that are more prone to false positives.

We should also give thought to whether we should continue with the practice of massive shared filters. In my opinion sharing is fine, so long as the regex strings are broadly related, or at least authored by the same person. If we all pile our regex into the same filter, it's difficult to monitor and maintain, and can grow into cruft. I don't have numbers but it is my suspicion that multiple efficiently written filters would only be trivially slower than one combined filter. It might even be faster (see the comment on line 5 of filter 58). I can try to run some tests.

Thanks for your help! — MusikAnimal ^talk 19:53, 23 January 2018 (UTC)

Special:AbuseFilter/58. I tend to think this is quite a useful shared filter, but agree with the prune. I figure I can hack out probably half of it, for others to add back anything they disagree with, or anything which returns as a meme. I'll look at doing this over the next few days.. -- zzuuzz ^(talk) 20:20, 24 January 2018 (UTC)

Please see mw:Code stewardship reviews/Feedback solicitation/AbuseFilter for an important discussion regarding the future of the AbuseFilter extension. — xaosflux ^Talk 18:08, 29 January 2018 (UTC)

• This EFH nomination ends has started. (refresh)
• Achim55 (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)^{( · · · · · · · · · )}
• c:User:Achim55 on Commons

Hello, being an admin on Commons I'm heavily involved in fighting spam, I've done more than 2,700 spam-related blocks of users or IPs there. Most cases are clear as we mainly have to deal with spam that is generated by botnet-controlled zombies. But sometimes there are borderline cases of manual edits where it is not easy to recognise whether one can assume bad faith or not, and thus to act in an appropriate manner - revert, cleanup, delete, warn, block or even not? I think then it might be helpful looking up the logs from here to see if they perhaps already have had a try on this wp. I'm not interested in the filters themselves but just in looking up the spam-related filter logs now and then. If this request is declined I'm fine with that, but then I'd like to ask at the least for the bit that grants access to en:wp's SBL log. Regards, --Achim (talk) 14:34, 3 February 2018 (UTC)

@Achim55: only EFH and +sysop have access to SBLlog here. — xaosflux ^Talk 15:17, 3 February 2018 (UTC)

I thought the spamblacklistlog right could be given separately. --Achim (talk) 15:21, 3 February 2018 (UTC)

Not without creating an entire new group. On commons the only way to currently get it is via +sysop as well. — xaosflux ^Talk 16:44, 3 February 2018 (UTC)

 Note: When gerrit:405670 is deployed (probably this week) all logged in users will be able to view the SBL log. — JJMC89 (T·C) 18:51, 3 February 2018 (UTC)

Interesting @JJMC89: since phab:T64781 says that it didn't yet have a consensus. — xaosflux ^Talk 19:06, 3 February 2018 (UTC)

@Xaosflux: It looks like Legoktm changed his mind per phab:T184483#3916209. — JJMC89 (T·C) 19:16, 3 February 2018 (UTC)

@Cyp and Crow: See Special:Diff/825296358, reported by Jayron32 — MusikAnimal ^talk 16:25, 12 February 2018 (UTC)

• Thanks for reporting this here. I'm not sure what the percentage of false positives is; maybe this filter is keeping back tides of shit I don't know about. But in terms of number of false positives, the last 3-4 reports I have dealt with at AIV have been false positives; given that I deal with AIV maybe 15-30 minutes per day, and I've dealt with 3-4 false positives in the past week or so, that extrapolates to a high number of false positives; I'm wondering if this can be tweaked in some way as to be more carefully targetted against the person it is trying to stop. It seems (IIRC from the last time that I dealt with this) that this is targetted to stop a spammer from self-promoting; it seems one of the keywords that flags this filter is itself a common enough personal name that it shows up innocently on many of these items. Just wondering if there was a way to make this more useful. --Jayron32 17:14, 12 February 2018 (UTC)

• I'd guess it isn't a false positive in this case, but I don't know enough about the target to say for sure. Κσυπ Cyp   17:47, 12 February 2018 (UTC)

​​Vivekka is now blocked, and has even confirmed being a sock. Κσυπ Cyp   20:55, 13 February 2018 (UTC)

That's fine, but it only highlights one of the problems with reporting filters like this to AIV. There's hundreds of admins that patrol that page, and like 3 are familiar enough with this one troll to deal with him. There are a lot of highly specific filters that, even if they are positive, it's hard to know what to do with. Is there any way to set filters to report to specific places (like the filter creators talk page) instead of AIV so they can more quickly and effectively dealt with? --Jayron32 02:03, 14 February 2018 (UTC)

• Regarding the filter, I've been tweaking it as the innocent use of a name trips a FP. That shouldn't happen anymore. Yes this latest one is the sock's MO now that he's been stifled through other avenues. All the Feb hits on the filter have been him. I agree that perhaps this one shouldn't report to AIV as it is not obvious vandalism lately but sneaky innocuous-looking edits. Crow^Caw 14:59, 14 February 2018 (UTC)

Back in September, there was a discussion about this filter (the WP:DAILYMAIL filter) still being tested. Now, four months later, I wonder if we could make the filter do more than just log, so it's actually useful. PinkAmpersand proposed a warning template and I propose we use this template whenever someone adds a link to dailymail.co.uk (not the other two since there was no consensus for it) and tag links to all three sites so people can easily see those edits in their watchlist. Opinions? Pinging @Ritchie333, Zzuuzz, and Xaosflux who participated in the last discussion. Regards SoWhy 10:21, 11 January 2018 (UTC)

I'm all for it (see User:Ritchie333/Userbox Daily Mail, writing Enemies of the People, and recent comments at Wikipedia:Articles for deletion/Cassie Sainsbury); however obviously I have very strong views on this, so I don't think my opinion should count for anything towards consensus. Ritchie333 ^{(talk) (cont)} 11:03, 11 January 2018 (UTC)

The consensus for the edit filter already exists in the linked to discussion, including the consensus for a warning when people try to add such sources ("An edit filter should be put in place going forward to warn editors attempting to use the Daily Mail as a reference.") Mine was more of a technical question, do you think the filter is tested enough to go live? Regards SoWhy 11:09, 11 January 2018 (UTC)

I've spot checked about 20 entries in the log, and they are all adding tabloid journalism to BLPs (most have been reverted) so I would say it's working as designed. Ritchie333 ^{(talk) (cont)} 16:44, 11 January 2018 (UTC)

Thanks for the ping, SoWhy. I've moved my proposed template to its own userspace page, User:PinkAmpersand/Daily Mail template, so others can improve upon it. (I've also made some tweaks to the original text, including boldfacing the most important sentence.) And, needless to say, count me as a !vote to set the filter to warn. — PinkAmpers&^{(Je vous invite à me parler)} 15:40, 11 January 2018 (UTC)

@PinkAmpersand: The filter also traps The Sun and the Daily Star. Are there any US papers that should be avoided? Breitbart? The National Enquirer? Ritchie333 ^{(talk) (cont)} 16:46, 11 January 2018 (UTC)

Careful though, there is no consensus to warn against any links that are not Daily Mail, so while it makes sense to tag such edits, a warning should only be displayed for the Daily Mail additions (until there is consensus against the other sources). Regards SoWhy 16:49, 11 January 2018 (UTC)

I don't think that's possible without rewriting the filter - it traps those three and (AFAIK) it's only technically possible to take one action against a match. I would, however, be utterly astonished if anyone who supported warning against the Mail in BLPs opposed it for The Sun and The Star. Indeed, my impression from reading the BLP and RS noticeboards is there is much more of a solid consensus to avoid The Sun like the plague for BLPs. Tom Morris put it better than I ever could here ;-) Ritchie333 ^{(talk) (cont)} 17:04, 11 January 2018 (UTC)

Hmm... As I said, I don't disagree with you but considering the backlash of the DAILYMAIL RFC we should avoid warning people from linking to newspapers without a strong consensus to do so. If it's not possible to differentiate, I suggest we switch the filter to tag for now and you or someone else interested can start a new RFC for other questionable sources. Regards SoWhy 17:34, 11 January 2018 (UTC)

It seems to me the simplest solution is to fork the filter: one filter on tag-only for The Sun and the Star, another on tag-and-warn for the Mail. If consensus emerges to ban the other two, then the filters can be re-merged (or they can become three separate ones to allow for distinct warnings). — PinkAmpers&^{(Je vous invite à me parler)} 18:05, 11 January 2018 (UTC)

Sounds good to me, if someone could do that (I won't touch that stuff with a ten-foot-pole). Objections anyone? Regards SoWhy 07:48, 12 January 2018 (UTC)

Concurring with opinions presented. --QEDK (桜 ❄ 伴) 08:09, 12 January 2018 (UTC)

(←) 869 now only covers Daily Mail, and 899 covers The Sun and Dailystar. We're still working on the warning for 869, I take it? What should the tag be? Maybe "Adding tabloids to BLPs"? It should be brief — MusikAnimal ^talk 17:57, 14 January 2018 (UTC)

@MusikAnimal: I would suggest just Daily Mail link added. And if you have ideas for the warning template, feel free to be bold. QEDK's already made a few improvements. — PinkAmpers&^{(Je vous invite à me parler)} 18:16, 14 January 2018 (UTC)

In anticipation of us doing the same for other tabliods, I think we should use a shared tag. This will make it easier for patrollers, as presumably we don't care which tabloid it is, right? — MusikAnimal ^talk 18:23, 14 January 2018 (UTC)

I think it does matter. There's a consensus that the Daily Mail should (almost) never be linked. There isn't such a consensus for the other two tabloids. A Daily Mail addition is, IMHO, more demanding of immediate review, because that signals someone not just making a dubious claim, but someone who's just been notified of a consensus and has chosen to ignore it (rightly or wrongly). IMHO, that edit is more demanding of immediate review than is an edit linking to either of the other two tabloids. What about making two tags: one that would cover both 869 and 899, and another that would just cover 899? Also, someone should probably post a new RfC to RSN about the Star and Sun, to see if we can switch those over to tag-and-warn as well. — PinkAmpers&^{(Je vous invite à me parler)} 20:29, 14 January 2018 (UTC)

Sure, let's see what others have to say. Just remember tags associated with an edit are permanent, and any changes to the wording require a new tag, so it's important to get it right from the start — MusikAnimal ^talk 02:51, 15 January 2018 (UTC)

Agree with Pink&, one filter is essentially a byproduct of community consensus while the other is a conclusion drawn from the consensus itself. I don't think the warning split is as much of a problem although MA is correct about the tags ofc. --QEDK (桜 ❄ 伴) 18:05, 15 January 2018 (UTC)

• Rescuing this from the archives, so we can make our minds up once and for all on whether to enable this filter. I'm going to cross-post to WP:RSN to see if the folks there have anything to say. — PinkAmpers&^{(Je vous invite à me parler)} 13:59, 10 February 2018 (UTC)

I , and a few others, maintain a dubious view of such a "filter". Collect (talk) 14:45, 10 February 2018 (UTC)

• Unnecessary. These are like vanity templates. They serve no purpose. No filter or book ban is needed. We need to end the mentality of the Great Purge. A big banner with a blinking Wrongthink or Thoughtcrime is a bit juvenile. --DHeyward (talk) 05:47, 13 February 2018 (UTC)

• Support - It's important that we use all available tools to help keep unusable sources out of the encyclopedia. This proposal has no downside that I can see. - MrX 🖋 01:50, 24 February 2018 (UTC)
• Note - See Wikipedia:Reliable_sources/Noticeboard#Edit filter for the Daily Mail indicating consensus (so far) for implementing this template.- MrX 🖋 23:37, 25 February 2018 (UTC)

I don't know how feasible this is or whether it would be a good use of resources but would it be possible to block pages that begin with "Burim Ademi". A sock master (see Wikipedia:Sockpuppet investigations/Burim Ademi Vines) is constantly recreating the same page, getting blocked, getting it deleted, making a new account, and starting over. The page is just a copy paste of Murugarajrevanth so something that looks for the same thing over and over again would probably work just fine. This has been going on since at least January with very little sign of it stopping. If this isn't a good use of resources that's alright. They aren't that hard to spot anyways. Thanks! --Majora (talk) 05:19, 10 March 2018 (UTC)

That would be a candidate for the Mediawiki:titleblacklist. — JJMC89 (T·C) 09:05, 10 March 2018 (UTC)

I was under the impression that since it was never a title the title blacklist would not help in this situation. The junk is never created under any variation of "Burim Ademi" as the page name but always in their user space under the name of their various sock accounts. Would the title blacklist still catch these? --Majora (talk) 17:38, 10 March 2018 (UTC)

@Majora: so they are not actually creating pages that begin with "Burim Ademi" - they are creating pages that "contain" it? — xaosflux ^Talk 17:53, 10 March 2018 (UTC)

can you give a couple actual example pages? — xaosflux ^Talk 17:54, 10 March 2018 (UTC)

(edit conflict) Correct. The first words are "Burim Ademi". They are spam articles that start with Burim Ademi. Sorry for the miscommunication. You can see the, now deleted, user page of the sock I mentioned above for an example. They are all copy/pastes of the same content so I'm guessing they have the wikitext saved on their computer and every new sock just uses the same thing. --Majora (talk) 17:56, 10 March 2018 (UTC)

Hello, I would like to ask for abusefilter conditions. How to make the conditions fit articles which is date-month or year?

Right now I have (in my home wiki, but English equivalent would be like this)

(article_prefixedtext == "([1-9][0-9][0-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9]|[1-9])( BC|)")
(article_prefixedtext == "([1-3][0-9]|[0-9]) (January|February|...)")

, but it still not working properly. Any ideas to correct this? --Horus (talk) 15:07, 11 March 2018 (UTC)

@Horus: Hello which w:th:พิเศษ:ตัวกรองการละเมิด ID are you working on? Do you want to perform a logical OR on those two conditions? — xaosflux ^Talk 15:34, 11 March 2018 (UTC)

#82, actually I intend it to be negative so the filter should skip both date-month and year articles. --Horus (talk) 15:40, 11 March 2018 (UTC)

@Horus: Lots of ways to do that, e.g.:

!(condition1) & ( 
 !(condition2) )

or

!contains_any(article_prefixedtext, "([1-9][0-9][0-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9]|[1-9])( BC|)" , "([1-3][0-9]|[0-9]) (January|February|...)")

Try those out? — xaosflux ^Talk 16:15, 11 March 2018 (UTC)

The NOT (!) operator is probably what you need for most of what you are doing. — xaosflux ^Talk 16:17, 11 March 2018 (UTC)

If I use contains_any it will affect some article rather than date-month and year such as "2018 Elections" or "1 January events". I want it to detect only articles name "2018" or "1 January". --Horus (talk) 16:45, 11 March 2018 (UTC)

@Horus: if you just want to OR those 2 conditions, use the | operator:

(
 (article_prefixedtext == "([1-9][0-9][0-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9]|[1-9])( BC|)") |
 (article_prefixedtext == "([1-3][0-9]|[0-9]) (January|February|...)")
)

— xaosflux ^Talk 17:29, 11 March 2018 (UTC)

• It looke you are mixing up regex and plain text. contains_any and == don't work with regex. Try something like this:
  article_prefixedtext rlike "[0-9] etc" -- zzuuzz ^(talk) 17:32, 11 March 2018 (UTC)
  • Thanks. It works now. --Horus (talk) 17:37, 11 March 2018 (UTC)

A new tag: https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&tagfilter=abusefilter-condition-limit can show edits that overflow our condition limits. — xaosflux ^Talk 19:53, 12 March 2018 (UTC)

Humorously, the notice that contains the announcement of the abusefilter-condition-limit tag is itself triggering the tag. —RP88 ^(talk) 20:16, 12 March 2018 (UTC)

Heh, indeed! This is a nice feature. However if I understand this correctly, it might be a bit misleading. For instance, if you see page move was tagged as having met the condition limit, that doesn't necessarily mean the filters around page moving need to be improved. Instead it might have been one filter that isn't meant to check page moves at all, but is consuming more conditions that it needs to. Does that make sense?

Anyway, we've historically done quite good at staying within the condition limit. At the time of writing, I see that only one action (of the last 4,000+) has reached the limit. It'd be good to get that back down to zero :) Maybe it's time for a spring cleaning? Anything under User:MusikBot/StaleFilters/Report that we don't need anymore? — MusikAnimal ^talk 21:24, 12 March 2018 (UTC)

@MusikAnimal: problem is that those "4000" seem represent a very small amount of continuous time. But yes, review and optimization is always good! — xaosflux ^Talk 23:58, 12 March 2018 (UTC)

I've added a proposal to add a speedy capability for self-requests to Wikipedia talk:Edit filter helper, baring any actual objections the conversation above suggests this is uncontroversial. — xaosflux ^Talk 15:50, 13 March 2018 (UTC)

• @Lourdes: Self-grant EFM? --QEDK (後 🌸 桜) 08:06, 19 March 2018 (UTC)

...and founder status too? :D No :) Amory was referring to my going to BN, getting the admin bit and checking the afm flag. Lourdes 10:51, 19 March 2018 (UTC)

And the viewing of these is already included with +sysop. — xaosflux ^Talk 11:17, 19 March 2018 (UTC)

With phab:T181024 there is talk to make AbuseFilter treat arrays like arrays, and not cast into strings. So for instance, right now 1 in [0, 11, 20] is true, yet 1 is not in the array. Making it act like a true array makes sense, and would allow you to do things like contains_any(article_namespace, 0, 11, 20) instead of the less desirable article_namespace in "^(0|11|20)$". However there are some things like added_lines where true array handling may be adverse (e.g. "foo" in added_lines would be false unless "foo" was on its own line). There are a number ways to address this issue: maybe introduce new variables for this (added_text), or we could just ensure added_lines is always casted to a string when using in, contains, etc. Basically, we need more input :)

If you have the time, please give phab:T181024 a read and share your thoughts. Comment on Phabricator if you can, but here is fine too :) Cheers — MusikAnimal ^talk 15:44, 26 March 2018 (UTC)

@MusikAnimal: I personally quite like the way that [string arrays] are currently handled. I sympathise with the problem surrounding 1 in [0, 11, 20] being true, but I have only ever encountered this in rare cases like namespaces and article_ids, and it's easy to work around. Treating things like added_lines, user_groups, and added_links as newline-delimited strings allows for some extra flexibility and doesn't have the restrictions imposed by exact (array) matching. Being able to write "confirmed" in user_groups is a feature, not a bug, IMO. So for the sake of simplicity I'd prefer to keep the default casting as it is, and (if so inclined) introduce new array-casting functions. Perhaps the list syntax ([]) could be changed for this purpose. -- zzuuzz ^(talk) 10:29, 4 April 2018 (UTC)

Yeah, all things considered changing this behaviour is probably not good. I think we should consider array-casting functions, as you say, like in_array and array_contains, etc. This will also mean we don't cause massive regressions, since the majority of filters do things like !("confirmed" in user_groups). Thanks for the feedback — MusikAnimal ^talk 20:24, 4 April 2018 (UTC)

Is it possible to use revision deletion to hide Special:AbuseLog entries? I have no particular case in mind. I just noticed there doesn't seem to be a way to do this. Sometimes the filter (e.g. filter 686) might tag an egregious BLP violation (or worse, oversightable information) which we may revdel using WP:RD2, but the edit is still publicly visible via the edit filter log, and it doesn't seem we can redact it there. Mz7 (talk) 08:38, 5 April 2018 (UTC)

Oversighters have Hide entries in the abuse log (abusefilter-hide-log). Admins do not. — regards, Revi 08:51, 5 April 2018 (UTC)

Ah gotcha. I wonder if it might be beneficial to grant some of that functionality to administrators in order to bring the feature in sync with regular log deletion elsewhere. Mz7 (talk) 20:59, 5 April 2018 (UTC)

I think it would be, need a feature request though - the EF logs are completely different then the rest of the logs. — xaosflux ^Talk 23:28, 5 April 2018 (UTC)

Why most of the edit filters is private? Not sure why? 2A02:C7F:963F:BA00:D1AA:6B7B:FE31:F56 (talk) 21:09, 9 April 2018 (UTC)

Most of the active filters are public. Private filters are private to reduce the incidence of users circumventing them. -- zzuuzz ^(talk) 21:34, 9 April 2018 (UTC)

who can view private filters? 2A02:C7F:963F:BA00:5D66:A891:94CC:66A4 (talk) 21:26, 12 April 2018 (UTC)

Admins and a small group of others. — xaosflux ^Talk 21:52, 12 April 2018 (UTC)

Hello! I use the filter log for vandalism patrol quite often and I noticed that a large number of recent hits for filter 867 were page creations by the bot User:Qbugbot. While not necessarily a 'problem', it could be considered a false positive and does tend to fill up the log. Per WP:EXTENDEDCONFIRMED, the bot user right includes extended confirmed so I'm not entirely sure why the filter was tripped (does the filter require explicitly mentioned rights?). Jiten ^talk _contribs 10:24, 26 April 2018 (UTC)

@Jiten D: it looks like there is a bug in the abuse filter, since bots do have this right. I've changed the filter to explicitly exempt the bot right for now. — xaosflux ^Talk 11:59, 26 April 2018 (UTC)

@MusikAnimal: would you mind looking this over to see if I'm missing something before going to phab? — xaosflux ^Talk 12:00, 26 April 2018 (UTC)

We're going off of user_rights (and not groups), so I am not able to explain this misbehavior. I think it is indeed a malfunction. Just when I thought things were becoming more stable :( — MusikAnimal ^talk 00:34, 27 April 2018 (UTC)

I don't see "extendedconfirmed" listed as one of the bot's user rights at Special:AbuseLog/21007768, but I do see "extendedconfirmed" as what should be one of the bot's rights at IntialiseSettings.php. So I will again have to blame AbuseFilter — MusikAnimal ^talk 00:45, 27 April 2018 (UTC)

 Done, unanimous vote — Κσυπ Cyp   06:06, 4 May 2018 (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.

---

Enfcer (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)^{( · · · · · · · · · )}

I am an Admin on Simple English Wiki Verify. I recently had asked one of your Edit Interface users for information on one of your Edit filters, as the LTA Vandal that, that filter was designed to slow down / stop, had started on our wiki. I do hold the Rollback & Pending Change Reviewer rights here on En.Wiki. While most of my focus is on Simple, I do still come here and clean up vandalism that may not have been cleaned up here by users that may have vandalized us first then came here or other vandalism that may not have been reverted yet. Granting me this right will help me protect a sister project of this one and benefit all who use the wiki. I believe I meet all the requirements in the top half of EFH Requirements and I am an Admin on another wiki, as the requirement on the second half. -- Enfcer (talk) 02:37, 30 April 2018 (UTC)

Is a crat and admin on simple english wiki (Special:CentralAuth/Enfcer). — xaosflux ^Talk 04:06, 30 April 2018 (UTC)

• Support this. I'm the EFM he mentioned above, as he's fighting a vandal here who's migrated there. Would be quite useful to have EF editors on both wikis, as I've asked at Simple for similar local EF content there. Crow^Caw 20:34, 1 May 2018 (UTC)
• Aye. -- zzuuzz ^(talk) 20:59, 1 May 2018 (UTC)
• Yas - TNT^❤ 21:00, 1 May 2018 (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.

I'm not the user who made the edit, so I can't fill out a false positive report properly, but I saw this edit (and the one before it) from an IP tripped what appears to be a new filter for detecting RJCola socks. See the IP's filter log. I don't think this has anything to do with him, so this seems to be a bug. Home Lander (talk) 19:41, 15 June 2018 (UTC)

@Cyberpower678: may have already taken care of this. I've temporarily disabled while checking. — xaosflux ^Talk 20:03, 15 June 2018 (UTC)

@Xaosflux and Home Lander: I've re-enabled it. It was caused by an edit conflict between me and MusikAnimal. The Abuse Filters do not handle edit conflicts.—CYBERPOWER (Chat) 20:08, 15 June 2018 (UTC)

@Cyberpower678: please review my edit that you clobbered along with a response to my question. — xaosflux ^Talk 20:10, 15 June 2018 (UTC)

@Cyberpower678: / @MusikAnimal: can you point to the required posting here made about this disallowing filter? — xaosflux ^Talk 20:06, 15 June 2018 (UTC)

@Xaosflux: I don't quite understand. The filter was created in response to extreme harassment to DuncanHill. The filter is being constantly monitored by me.—CYBERPOWER (Chat) 20:14, 15 June 2018 (UTC)

@Cyberpower678: following a 2015 RfC as documented at Wikipedia:Edit_filter#Recommended_uses, Except in urgent situations, new edit filters must not be set to disallow without thorough testing and a notice at the noticeboard to give other edit filter managers and the community time to review the filter for technical accuracy and necessity.[3] In urgent situations, the notice may be made after-the-fact.. Given that 919 has had disallow enabled for many days, and assuming your situation was "urgent", I think there has been plenty of time for the notification requirement to have been fulfilled, but don't see it. — xaosflux ^Talk 20:20, 15 June 2018 (UTC)

@Xaosflux: I was not aware of said notification requirements, I considered the issue to be urgent however. I'm still fairly new to filters, so the policies around them are still being absorbed. I've so far followed practices as laid out by my common sense in trying to minimize disruption on Wikipedia. I have been regularly consulting with MusikAnimal regarding the filter, and have been thoroughly monitoring/testing it.—CYBERPOWER (Chat) 20:23, 15 June 2018 (UTC)

The guideline to post here about disallowing filters needs more discussion. That happened reliably for the few months or so after WP:EF became a formal guideline, since then it's seldom. I am as guilty as others. Most times you don't want to discuss the filter publicly, so you just say "Filter 123 is in disallow", which the bot report already tells you here on this page. Anyway, when that IP edit was tripped the filter was in log-only and was named "possible sockpuppetry" [1], as it was still in testing. I was monitoring and immediately told Cyberpower about it, then we found out I inadvertently overwrote his changes, which if kept wouldn't have tripped that edit. Sorry for the confusion — MusikAnimal ^talk 20:31, 15 June 2018 (UTC)

This discussion needed to happen a while ago. See above for a little more info, but basically when the noticeboard and guideline came about, you were meant to post here about any new filters you created that went into disallow. This was a good idea in theory, but a few problems: First, for LTAs and such you often don't want to talk about it, as they may be watching and go by our discussion to evade the filter. Secondly, the guideline does not suggest posting notifications about changes to disallowing filters, which can be just as severe.

For instance have a look at /Archive 1. These were the early days and you see folks would regularly post this filter is in disallow. Without saying too much... and so forth, and nearly every time no one had anything to add. It was cluttering the noticeboard for one, and given it's a single notice that often doesn't even have an explanation, it's a much better suited job for a bot. Hence why User:MusikBot/FilterMonitor/Recent changes was created (translcuded at the top of this page for your convenience), which you can watch so you can monitor filter changes from your watchlist -- and that includes changes to existing filters that are in disallow. I don't know if we need a new RfC just to modify the guideline about the notification requirement, but we should discuss. What do people think? — MusikAnimal ^talk 20:48, 15 June 2018 (UTC)

I certainly agree that details etc for private filters don't belong here - perhaps the bot report could be enough, but (1) it doesn't help with the review before implementation for non-urgent disallows, (2) it doesn't include any ownership info (like MusickAnimal set #123 to disallow) so the community in general would know who to ask first. — xaosflux ^Talk 20:52, 15 June 2018 (UTC)

Filter managers can click the link to see who is authoring it (could be multiple people, as is the case with 919). The bot is actually capable of reporting the last filter author with a simple flip of a switch, but for reasons I can't recall we kept this option turned off. At any rate, only filter managers would be able to review the private filters anyway. For public disallowing filters, I think it's perfectly reasonable to consult here first. There are still scores of existing disallowing filters that are very fragile, and changes are made to them regularly without discussion. It boils down to the faith we have in our filter managers to do it cautiously, which for the most part I think has gone well. — MusikAnimal ^talk 21:01, 15 June 2018 (UTC)

The current verbiage is only for "new" filters, not changes. I'd argue that completely replacing an existing filter's condition with new conditions would be "new" as well, but minor tweaks are not. It may be enough to adjust this to "new non-private" filters - especially ones being proposed etc. The point was to prevent efm's from just slamming breaking changes in to production. — xaosflux ^Talk 21:13, 15 June 2018 (UTC)

I agree. Filters can evolve a lot over time, to the point they effectively become something new. Usually the purpose of the filter remains unchanged, which is a very good practice (e.g. don't repurpose filters for something completely different, create a new one, so that the log contains broadly related hits). The notification guideline is mostly about that I think -- the purpose and general approach (disallow "foo" and "bar" from new users), and less about implementation details which most people won't understand. And again, here we're talking about private filters, so the approach, details, and sometimes even the purpose, are meant to be non-public. I think it is reasonable to reword the guideline to at least exempt this use case. — MusikAnimal ^talk 21:56, 15 June 2018 (UTC)

If we all agree that we don't have problems with EFMs making breaking changes to edit filters, I fail to understand why we require the notice in the first place. It seems to me that either discussing every new filter is useful, and people will continue to do it without being obligated to, or it is not useful, and the requirement just wastes time. —Compassionate727 ^(T·C) 03:36, 16 June 2018 (UTC)

I miss the point of the notice requirement as well. As I interpret it, the edit filter is intended to reduce problematic edits, and in some cases, identify and report problematic editors (at AIV or similar). Those who would constructively review the notices on this page are unlikely to be caught up by the filter, so the only ones who it really matters to are the trolls, who are exactly the ones that shouldn't be made aware. Home Lander (talk) 20:45, 16 June 2018 (UTC)

@Home Lander: I think the point is that a single filter set to warn or disallow has the potential to break editing for everyone. Now, something that breaking would likely be quickly caught and undone - but is entirely preventable. — xaosflux ^Talk 21:34, 16 June 2018 (UTC)

The notices are only useless if edit filter managers are watching the recent filter changes instead. This prevents overly broad or poorly implemented filters being introduced, and is a useful - and frequent - activity. I also recall one or two filters appearing at arbitration before which might have some bearing on this policy. I would like to see a better implementation of not disallowing too early, of testing, monitoring logs and checking for false positives, particularly for users who are not too experienced in writing filters. I'd also like to see more changes reported which have the effect of changing policy, for example some of the username filters often (and currently) border on doing this. So the noticeboard requirement is a bit redundant but only with the bot reporting and the recent filter changes page, which I encourage everyone to keep an eye on and to amend filters accordingly. -- zzuuzz ^(talk) 21:39, 16 June 2018 (UTC)

Filter 887, and its warning message MediaWiki:Abusefilter-disallowed-repetitious-username, has been really quite successful at preventing the creation of accounts with junk names, and has essentially no false positives, and as far as I can tell, has had an entirely beneficial effect, as accounts with random-typing usernames are generally associated with disruption, and the barrier presented to legitimate editors to rethink their username and to come up with a better one is very low. This filter was previously the subject of community discussion, and in its present form seems to have consensus for being useful.

I now propose that Filter 890 (suitably adjusted to catch "createaccount" actions only) also be switched to disable mode, with a suitable warning message, for the same reason. It's been running in no-action mode for quite some time, and I've also not detected any false positives for the filter in its current version. I've created a new warning message MediaWiki:Abusefilter-disallowed-random-typing-username for this purpose. Is everyone OK with this? -- The Anome (talk) 14:03, 26 June 2018 (UTC)

I agree in general, although I propose that someone with better language skills than me expand the proposed warning to explain why random character usernames are not helpful to further collaboration. Regards SoWhy 14:24, 26 June 2018 (UTC)

See User:Compassionate727/sandbox for my version. I don't like the type, search for and remember and hindering and will see if I can't nicely split that into the two sentences. —Compassionate727 ^(T·C) 21:42, 26 June 2018 (UTC)

@Compassionate727:: thank you: I've adopted your suggestion. -- The Anome (talk) 10:05, 28 June 2018 (UTC)

@The Anome: I've actually copyedited it a little more, if it wouldn't be too much trouble to update it again. —Compassionate727 ^(T·C) 18:51, 28 June 2018 (UTC)

I've done so again. -- The Anome (talk) 22:40, 28 June 2018 (UTC)

Seems fine, but I think we should combine 887 and 890 as they serve a similar purpose. — MusikAnimal ^talk 16:50, 26 June 2018 (UTC)

I've now activated Filter 890, but not yet merged the two: if there's any pushback on this, I don't want it to affect filter 887, which has now been working well for some time. Once filter 890 has been working for some time without problems, yes, I think they should be merged. -- The Anome (talk) 10:04, 28 June 2018 (UTC)

 You are invited to join the discussion at Wikipedia:Village_pump_(proposals)#Proposal_to_increase_trigger_of_Special:AbuseFilter/68. Ronhjones  ^(Talk) 19:37, 5 July 2018 (UTC)

See [2]. LucaPuca7 was flagged twice for repeatedly attempting to vandalize England national football team. But when "diff" is selected, both instances show the same edit by 2A02:C7F:722B:B900:B5D7:662B:863F:1408 (talk · contribs · (/64) · deleted contribs · filter log · WHOIS · RBLs · http · block user · block log). Their filter log is empty. Something seems amiss. Home Lander (talk) 18:48, 2 July 2018 (UTC)

• Will check if this is something that is oversight related. — xaosflux ^Talk 19:37, 2 July 2018 (UTC)

  Pending response from OS team. Notable, the edits referenced in the log also do not appear at those timestamps in the article. — xaosflux ^Talk 19:41, 2 July 2018 (UTC)

  Nothing OS'd on the article, nor in LucaPuca7 or 2A02:C7F:722B:B900:B5D7:662B:863F:1408's contributions. This also isn't a bug which has disclosed the user's IP address. Interesting.. - TNT ^💖 20:03, 2 July 2018 (UTC)

• phab:T198651 opened. — xaosflux ^Talk 20:12, 2 July 2018 (UTC)
  • Xaosflux and others: I'm not registered on Phabricator, but I'm trying to follow along. In reading the post from Daimona, I'm gathering that he/she thinks that if one attempts to edit a page but leaves the content alone several times in a row, this filter will trip and display a result like above. I'm assuming a non-autoconfirmed account is necessary to test this. Home Lander (talk) 19:53, 3 July 2018 (UTC)
    • Evidently not. After making a null-edit with one non-autoconfirmed account, I used another to repeatedly save the same content. No filters tripped on either of the two. Home Lander (talk) 20:21, 3 July 2018 (UTC)

    Should be able to test with any account. In this case Daimona was interested only if the account and IP in question had made the same exact edit, at the same time, such that it wouldn't cause an edit conflict and wouldn't save (yet still be registered in AbuseFilter). This actually makes sense... the "repeated vandalism" filter works by checking how many times an edit to the same page is attempted but didn't save. Usually, when an edit doesn't save, it's because it was blocked by some other filter, which is the assumption being made by Special:AbuseFilter/279 — MusikAnimal ^talk 20:22, 3 July 2018 (UTC)

    @MusikAnimal: OK, interesting... so if two users try to make the exact same edit at the exact same instance, this may set this off. How many times does an edit have to fail before filter 279 activates? Home Lander (talk) 20:39, 3 July 2018 (UTC)

    Three times in 5 minutes (see "Actions to take" at the bottom of Special:AbuseFilter/279), not quite the exact same time. By nature the filter is prone to false positives, since there are non-vandal things you can do where your edit doesn't get saved. Regardless, AbuseFilter shouldn't in this case try to associate it with an edit that was saved. — MusikAnimal ^talk 20:47, 3 July 2018 (UTC)

    @MusikAnimal: Well, can't see that (yet anyway), because it's private. Home Lander (talk) 20:50, 3 July 2018 (UTC)

    Ah, well, there's no reason for that. I've made it public — MusikAnimal ^talk 21:11, 3 July 2018 (UTC)

    There I can see it. So the idea is that both the user and the IP both attempted the same edit at the same time multiple times? Just trying to wrap my head around this! Home Lander (talk) 23:00, 3 July 2018 (UTC)

    It's absolutely possible, but highly improbable. I think, unless the two users are one and the same, you'd have better odds winning the lottery.—CYBERPOWER (Around) 02:01, 4 July 2018 (UTC)

    @Cyberpower678: That was exactly my thought, and I didn't. Home Lander (talk) 17:35, 4 July 2018 (UTC)

    According to the ph:T198651, the edits wouldn't have to be at the exact same time; rather, an edit conflict while attempting to make the same edit would also cause this, as the condition is simply that the content be the same. This doesn't make it remarkably probable, but it significantly improves the odds. They could have both been reverting vandalism, or fixing a typo, or something else super obvious. —Compassionate727 ^(T·C) 04:41, 6 July 2018 (UTC)

    Not that this explains how 279 specifically was tripped, because we need to have three edits mininimum for that to happen. —Compassionate727 ^(T·C) 04:52, 6 July 2018 (UTC)

Cyberpower678, MusikAnimal, Xaosflux, and others: I think I found another instance. See [3] and [4]; again, the wrong user is shown compared to the diff. There was heavy traffic to that article at the time, and the filter was tripping repeatedly. See [5]; there might be others. Home Lander (talk) 18:40, 5 July 2018 (UTC)

• My memory might be flaky, but I'm pretty sure this exact same bug/issue/feature has been reported before ... Black Kite (talk) 23:07, 5 July 2018 (UTC)

• Ah, found it (or at least found what I was thinking of). Is [6] related? It certainly looks similar. Black Kite (talk) 23:09, 5 July 2018 (UTC)

• @Black Kite: It appears so, it was tagged in the current Phabricator case as being possibly connected. See also Wikipedia:Edit_filter_noticeboard/Archive_2#Can_someone_more_competent_than_me_take_a_look. Maybe just me, but that instance seems weirder, with it tripping so many times on the same action. Home Lander (talk) 00:30, 6 July 2018 (UTC)

 Done — MusikAnimal ^talk 02:01, 11 July 2018 (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.

---

Earliest closure has started. (refresh)

Compassionate727 (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)^{( · · · · · · · · · )}

Okay, I don't really see any reason to wait to request this. Someone trout me if I'm far premature and I'll happily withdraw. But I've been recently (the past month, maybe?) spending time handling the false positive reports, as they don't usually seem to be responded to quickly (if ever), with the hopes that by filtering out the blatant junk and making edits for constructive contributors where the filters shouldn't be modified, I can direct the attention of actual edit filter managers to things that would actually benefit from their attention. Lord knows if it's actually helping anything, as I'm not sure I'm seeing it. But regardless, I'm often hindered in my efforts to figure out what needs expert attention by the fact that I can't see the edits in question. This would especially help when screening false positives for the Fuerdai filter, which has produced a whole rash of false positives lately, and a couple of sockpuppetry filters, which have also been causing issues. Obviously, I'm aware that the filters in question are hidden from public view for good reason and would never disclose the details of what exactly tripped a filter to a good-faith contributor. — Preceding unsigned comment added by Compassionate727 (talk • contribs) 2018-07-05T22:58:52 (UTC)

Support - don't see any reason not to. Home Lander (talk) 00:25, 6 July 2018 (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.

How expensive is it to filter on any use of a single word? Is there a single filter that keeps a list of words? As an example, every so often we get sockpuppet edits like this[7] on random pages. How expensive would it be to filter on the word "Kumioko"?

Related:

• Wikipedia:Administrators' noticeboard/Reguyla-Kumioko community ban
• Category:Wikipedia sockpuppets of Kumioko
• Category:Suspected Wikipedia sockpuppets of Kumioko
• Wikipedia:Sockpuppet investigations/Kumioko/Archive
• Wikipedia:Sockpuppet investigations/Reguyla

--Guy Macon (talk)

Not expensive. This could fit with the LTA filter, 58, just need to test it somewhere else to see how common it is, false positives, etc. Someguy1221 (talk) 22:52, 11 July 2018 (UTC)

Wikipedia:Edit filter/Requested/Archive_12#LTA filter 58?

Is there any point in requesting "Reguyla" or should I wait until I see some abuse using that username? --Guy Macon (talk) 22:13, 13 July 2018 (UTC)

I just got a response saying that filter 58 wouldn't work for this.[8] --Guy Macon (talk) 04:40, 15 July 2018 (UTC)

@Crow: 918 was getting quite a few false positives (and causing reports to go to AIV), but it looks like you've attempted to make some changes to rectify this? - TNT ^💖 20:42, 13 July 2018 (UTC)

I've disabled 918 due to the latest bout of FPs - TNT ^💖 23:34, 13 July 2018 (UTC)

@There'sNoTime: Yes, I've been trying to fine tune the FPs but given the pattern in question this is clearly proving difficult. I will likely re-enable it with no action until I can tune it better, if you have no objection. Crow^Caw 18:00, 14 July 2018 (UTC)

@Crow: No objection if you remove 918 from DatBot's reporting list to stop it filling up AIV - TNT ^💖 18:03, 14 July 2018 (UTC)

• That too! Crow^Caw 18:15, 14 July 2018 (UTC)
• @There'sNoTime: Pretty sure it's the second variable's case, when comparing against the hits in the last 24h. Crow^Caw 18:28, 14 July 2018 (UTC)

How many legitimate hits is that filter (or at least that specific part) getting? —Compassionate727 ^(T·C) 00:33, 18 July 2018 (UTC)

I, and several other editors, have been on the recieving end of what can only be described as "thanks spamming": abuse of the thank mechanism to saturate a user's message feed. See here for a log showing this. Is this something which could be throttled using the edit filter? If not, could the edit filter mechanism be adapted to make this possible? -- The Anome (talk) 09:19, 20 July 2018 (UTC)

@The Anome: I think there is a better way to do this (admin only link for more information). — xaosflux ^Talk 13:19, 20 July 2018 (UTC)

@Xaosflux: Can you email me that? Thanks, Kevin (aka L235 · t · c) 21:39, 20 July 2018 (UTC)

Hi. I use this feature over on Wiktionary moderately often. The summary table of filters shows the date when a filter was last modified. Have you thought about also showing the date when the last "hit" occurred? This would be useful to see at a glance whether a filter is still useful/relevant. Equinox ◑ 21:27, 24 July 2018 (UTC)

@Equinox: can you specify which table you are referring to? FWIW we do have a bot request of the active filters that have been unhit the longest here: User:MusikBot/StaleFilters/Report. — xaosflux ^Talk 01:46, 25 July 2018 (UTC)

This was created following a request, in response to a major PR incident where some nazi-related vandalism went unreverted for some time. The filter has been running for a while with great success. I quick glance through the logs shows the hits are almost always vandalism, BLP violations or otherwise very questionable edits. Much of it is very subtle. Every time I go through I find edits that haven't been reverted. Indeed political articles and human subjects are a primary target.

I think this filter at least should be throwing a warning. Do you think disallow would be acceptable? The standard warn/disallow messages seem satisfactory to me. — MusikAnimal ^talk 21:47, 25 July 2018 (UTC)

@MusikAnimal: I'm not really a fan of special filter for one word at all - can this be combined with another warning filter? Special:AbuseLog/21589919 looks like a FP as well. — xaosflux ^Talk 22:44, 25 July 2018 (UTC)

For sure, if we put in warn/disallow it makes sense to merge it elsewhere. This filter does things a little differently than most word-prevention filters, though: it checks old_wikitext to make sure there was no prior mention of "nazi(sm)" in the whole article, something you usually avoid for performance reasons. Here it was used to further prevent false positives. We're also checking against the edit_delta. I'll have to reevaluate the false positive rate if we change these things. And yes, there are definitely false positives as it is now, but seemingly rare. Overall my belief here is that this form of vandalism is more severe than "poop" or the like, as it often goes unnoticed. — MusikAnimal ^talk 22:59, 25 July 2018 (UTC)

Warn/Tag should fix the "unnoticed" problem though as the tags can be patrolled - perhaps some more "and didn't contain" words that could cut down FP's would be useful as well. — xaosflux ^Talk 00:16, 26 July 2018 (UTC)

Hey all, not to be a pest, but can anyone spare a few minutes to look at Wikipedia:Edit_filter/Requested#Komail_Shayan? I opened a request about a month ago. If this is the typical wait time, then I apologize--I know that all you technical types are always very busy. This guy keeps vandalizing[13][14][15] and it seems like it would be fairly easy to dissuade him. Thanks! Cyphoidbomb (talk) 15:35, 24 July 2018 (UTC)

•  Done Crow^Caw 20:41, 24 July 2018 (UTC)

Thanks Crow! Cyphoidbomb (talk) 15:31, 26 July 2018 (UTC)

Can someone take a look at this? Seems the IP twice triggered 279 and nothing else. Pinging MusikAnimal who was last to edit filter. Home Lander (talk) 02:28, 27 July 2018 (UTC)

Probably a bug server side. Dat Guy^Talk_Contribs 09:15, 27 July 2018 (UTC)

I've a similar theory to as before -- the editor was repeatedly attempting to save their edit, but it wasn't another filter that stopped it. Could be any number of things, who knows... It wasn't "vandalism". That filter name is misleading, better would be something like "repeated attempts to save edit". I chalk it up as a glitch or limitation in AbuseFilter. Honestly, I'm not sure how valuable this filter is to begin with. Is anyone monitoring that log? It tags as "possible vandalism", which if other filters were tripped, it might already be tagged. To me, "Repeated attempts to vandalize" in many cases is redundant, because I can already see the other filters repeatedly disallowed their edit. — MusikAnimal ^talk 15:52, 27 July 2018 (UTC)

@MusikAnimal: I regularly monitor the log, that was actually how I spotted this instance. I suppose you could say I use it as an alternate to "recent changes". I've noticed that most times when 279 properly flags an edit, other filters are doing so also. At minimum perhaps the name should be changed, but in my opinion it could probably be disabled as redundant. Home Lander (talk) 18:37, 27 July 2018 (UTC)

Sometime recently, we were discussing further restricting the page-move throttle. Can't remember exactly where. Check out this account. Think whichever filter controls the page-move throttle is going to have to be modified. Home Lander (talk) 02:35, 28 July 2018 (UTC)

@Home Lander: I think you are referring to Special:AbuseFilter/68. See the private conditions. — xaosflux ^Talk 03:06, 28 July 2018 (UTC)

Thanks Xaosflux. Did the above account have any deleted contribs? Home Lander (talk) 03:12, 28 July 2018 (UTC)

@Home Lander: That was a recent neglected and failed proposal at the Village pump. See Wikipedia:Village pump (proposals)/Archive 151#Rate limits for autoconfirmed users. Ultimately it didn't really make a whole lot of sense, at least not as presented. I'm open to suggestions that would result in less colateral damage. —Compassionate727 ^(T·C) 02:16, 31 July 2018 (UTC)

There seems to be a problem with the tag name since it doesn't only tag edits in userspace. Filter#354 says it only checks namespaces 2 and 3 (user and usertalk) but it seems to also be tagging edits in Draftspace (example [16]). Checking draftspace is probably intended behaviour, but then the tag label itself needs to be updated to reflect that to remove inaccuracies. :) Ben · Salvidrim! ✉ 21:48, 11 August 2018 (UTC)

@Salvidrim: the edit you referred to hit filter 627 (see log) not 354. I'm not seeing any Draft space hits in 354's log. Can you elaborate? — xaosflux ^Talk 23:27, 11 August 2018 (UTC)

I'm just going off of Special:Tags which says this tag is applied by 354. If 627 applies it to Draftspace it should use a different tag for draftspace or the tag whould be updated to reflect both filters which use it. ..... right :/ Ben · Salvidrim! ✉ 23:29, 11 August 2018 (UTC)

@Salvidrim: OK, I see 627 was using the same TAG as 354. I've updated the tag on 627. Hope that helps! — xaosflux ^Talk 23:31, 11 August 2018 (UTC)

Sure thing. I just saw a patently inaccurate tag and thought I'd point it out. :) Ben · Salvidrim! ✉ 01:51, 12 August 2018 (UTC)

@Kuru: It looks like Special:AbuseFilter/927 could be merged into Special:AbuseFilter/793. I would do this for you but I had a question: I thought after phab:T29987 we didn't have to use the spoofed variant in our regex (O instead of 0), yet I see we are in filter 793. @Zzuuzz: maybe you know? — MusikAnimal ^talk 21:40, 20 August 2018 (UTC)

I have some concerns about the maintainability of filter 793, because it's going to just keep growing with no real sense to be made of any additions, but if you want to merge go ahead because it will make little difference. I've been basing recent additions on the debugging tools and the equivset (here I think). It seems to work. As I understand it, while you should no longer use 0 instead of O, you should use O instead of 0. The numbers which need converting are 0=>O, 1=>I, 3=>E, 4=>A, 5=>S, 6=>G. But I'm sure MusikAnimal knows more about this than me. -- zzuuzz ^(talk) 22:19, 20 August 2018 (UTC)

Well that's why I'm confused. The point of phab:T29987 was to make it so that you don't have to use O instead of 0, etc., since that's so unintuitive. I'll have to do some testing to make sure. You're right 793 is becoming bloated, but the same is true with the many other shared filters. They all could use a pruning — MusikAnimal ^talk 22:52, 20 August 2018 (UTC)

My understanding is that, to quote someone on the phab ticket, "The assumption (which is usually correct) is that numbers are used to spoof letters rather than vice versa". -- zzuuzz ^(talk) 04:16, 21 August 2018 (UTC)

@MusikAnimal: Dammit. I even scanned the entire list for something similar; just missed that one somehow. Will merge when I get a sec. Kuru (talk) 22:22, 20 August 2018 (UTC)

@Kuru: No problem. Do make note of the above -- on 793 we're currently using the spoofed variant of some characters in the regex, so you should probably do the same (though again I thought we didn't have to do it that way!) — MusikAnimal ^talk 22:54, 20 August 2018 (UTC)

Converted and done; deactivated 927. Kuru (talk) 11:54, 21 August 2018 (UTC)

For the last month, there has been a persistent IP-hopping vandal that has a bone to pick with Amber Green Martin, a public figure holding office in Pennsylvania. The vandal is adding a block of text (see diffs) accusing Martin of theft to otherwise unrelated articles that contain "Amber", "Green" and/or "Martin" in their titles. This is a clear BLP violation meant to slander the subject. There is too much collateral damage to do a /16 rangeblock, and the randomness of the article selection makes blocks problematic.

• The Green Slime diff 1 diff 2
• Amber Tamblyn diff 1 diff 2
• Robson Green diff 1 diff 2
• Sonequa Martin-Green diff 1 diff 2
• Martin Green (professor) diff 1 diff 2
• Martin Grene diff 1
• Martin Green (author) diff 1

I'm sure there are more. I think a text filter may be the best way to deal with this vandal.

Thanks, caknuck _° needs to be running more often 22:06, 23 August 2018 (UTC)

This is the Cutler vandal in his latest rants after the last edit filter tweak from here. While he certainly keeps Prolog and I entertained, his BLP violations are pretty specific and severe on this round. I should have done this several days ago. Ravensfire (talk) 22:32, 23 August 2018 (UTC)

Got it. I placed semi-protection on all of the above listed articles for 1 month. caknuck _° needs to be running more often 23:32, 23 August 2018 (UTC)

Hi all, please see Special:AbuseFilter/928 which will use MediaWiki:Abusefilter-warning-transcludinguser as an edit warning. It is currently in log only to weed out any FP's. requested by @Home Lander: who noticed this was a recurring issue. Will change from log to warn in a day or two if no issues or concerns. Best regards, — xaosflux ^Talk 03:29, 21 August 2018 (UTC)

@Xaosflux: Thought of something. Considering that this filter will likely mostly flag edits on pages with quite long titles, it might cut down on the log to trim the filter description to something like "Transclusion of userpage to Wikipedia namespace". Some page titles are probably long enough that it would run onto three lines as it is. Home Lander (talk) 03:36, 21 August 2018 (UTC)

I shortened it to "Transclusion of userpage to WP namespace". — xaosflux ^Talk 03:39, 21 August 2018 (UTC)

Lookin' good! I think this is filter is a great idea. I've changed it to target namespaces 1, 3, 4 and 5, where most pings happen. Once we've got enough data we can decide which namespaces we should target before putting it into warn — MusikAnimal ^talk 04:33, 21 August 2018 (UTC)

@MusikAnimal: Probably should exclude user subpages (User:xxxx/...) as they are unlikely accidents but likely user space templates - feel free to add it in an optimized fashion, I'll be away from working on this for ~12 hours probably today. — xaosflux ^Talk 11:28, 21 August 2018 (UTC)

Done! — MusikAnimal ^talk 17:55, 21 August 2018 (UTC)

MusikAnimal, appears to have worked; [17] and [18] were logged by the filter but [19] was not. Home Lander (talk) 18:42, 21 August 2018 (UTC)

 Done activated in warn only mode, let me know if you see any troubles. — xaosflux ^Talk 17:37, 22 August 2018 (UTC)

Xaosflux, tested it in the sandbox again, looking good. Home Lander (talk) 19:13, 22 August 2018 (UTC)

@Xaosflux: Could we get an exception for the string "archive={{User" on user talk pages; it will stop FPs like this. Home Lander (talk) 23:22, 27 August 2018 (UTC)

@Home Lander: though it looks to be a FP for this specific case, from the subsequent edit on that page it looks like it was still malformated and this filter may have helped get it fixed. — xaosflux ^Talk 23:42, 27 August 2018 (UTC)

Oh - good as it is then. Home Lander (talk) 23:51, 27 August 2018 (UTC)

I was thinking that since we don't want users to index user pages because of promotion (hence this filter), should this filter only apply to non-confirmed users, but be set to disallow? ^Semi_Hypercube ✎ 12:49, 4 September 2018 (UTC)

@SemiHypercube: right now this is a tracking filter, and applies to all editors. Users are allowed to request indexing for legitimate purposes. I think we would still want to track these, so if you wanted a disallow for anonymous/newbie accounts it would need to be a separate filter (and then those groups could be excluded from this one). You can request a new filter at Wikipedia:Edit filter/Requested. — xaosflux ^Talk 13:18, 4 September 2018 (UTC)

After this change, filter 384 seems to have almost stopped working, and is only catching edit summaries, not article content. See [20] [21] [22] [23], etc.

Based on my reading of the manual, I think the problem is with the order of evaluation of irlike vs +, and this will fix it:

 
@@ -6,7 +6,7 @@
 
         added_lines irlike bad_word &
         !(added_lines rlike "\bDick('s\s[A-Za-z][a-z]|\s[A-Z][a-z.])|\b([A-Z]([a-z]+|\.)?|[DM]r\.)\sDick\b|\b(first|last)\s*=\s*Dick\b|{{\s*[Ss]ortname\s*\|\s*Dick\s*\|") &
-        !(removed_lines irlike bad_word + "|\w\*{1,4}\w") &
+        !(removed_lines irlike (bad_word + "|\w\*{1,4}\w")) &
         !(
             page_title rlike bad_word &
             old_wikitext irlike "\{\{disamb"

If not, I have no idea. Maybe just revert the change for now? MusikAnimal, Someguy1221, your thoughts? Suffusion of Yellow (talk) 01:35, 12 September 2018 (UTC)

That's it! Careless mistake on my end. Thank you Suffusion of Yellow. For the record, I tried to examine previous hits to check for regressions, but was unable to due a bug in AbuseFilter where added_lines wasn't save in the log. Anyways, I've tested the revised filter on the edits you linked to, and it catches them. Cheers — MusikAnimal ^talk 01:50, 12 September 2018 (UTC)

I've set filter 895 to warn in response to a suspected spambot, as mentioned at the Administrators' noticeboard. This filter is quite extreme. It should definitely be disabled in the near future. -- zzuuzz ^(talk) 08:21, 16 September 2018 (UTC)

@Zzuuzz: what do you expect this to do? (It looks like you disabled the warning already) - the accounts will still get created and I'm pretty sure the createaccount interface won't display this warning - it could still be useful for a log/investigate though. — xaosflux ^Talk 15:24, 16 September 2018 (UTC)

Yes, I've eased it back already, but may throttle it up again depending on activity. The warning does appear to have an effect, as you'll see from (most of) the log entries. It can also be dismissed, as you can see from the account created at 10:24 today. I haven't tested to see what it looks like. -- zzuuzz ^(talk) 16:16, 16 September 2018 (UTC)

The other piece of information you might need for this to make sense, is that in my experience bots can't deal with warnings. -- zzuuzz ^(talk) 17:58, 16 September 2018 (UTC)

Based on recent BLP vandalism at Martin Green (musician) and Willie Green, could someone with the bit see about refining this filter? Ivanvector (^Talk/_Edits) 15:27, 19 September 2018 (UTC)

• Tweaked. Crow^Caw 15:35, 19 September 2018 (UTC)

Thank ya both kindly! Ravensfire (talk) 15:50, 19 September 2018 (UTC)

Edit filter 164 is fairly outdated, and could use some improvements. I am not the most familiar with maintenance templates and their syntax, and would like someone familiar with AfC templates etc. to make suggestions. I have an idea myself: the filter should check for escaped wikilinks to categories (which are common at drafts). I also have a question – since there are many undetected candidates for history merging, is checking all articles that currently exist necessary? wumbolo ^^^ 12:13, 11 October 2018 (UTC)

I've re-used Special:AbuseFilter/684 ("temporary vandalism") and set it to disallow - very narrow, tested at 773, and I'm watching the logs - TNT ^💖 09:24, 23 September 2018 (UTC)

Disabled - TNT ^💖 08:34, 16 October 2018 (UTC)

Please review 937. This is a very simple filter intended to patrol for WP:CHUTIYA long term abuse. Guy (Help!) 06:42, 12 October 2018 (UTC)

As a logging filter it seems fine, not sure how popular of a term Chutia is, if there are many legit uses adding conditions about the editor may help. — xaosflux ^Talk 11:44, 12 October 2018 (UTC)

Very few, as far as I can tell. Guy (Help!) 23:54, 12 October 2018 (UTC)

@JzG: Should we be tagging edits with "possible long term abuse"? I feel like this is a WP:DENY-type situation. Also it gives it away to them that they're being tracked, and they can easily see what isn't triggering the fitler. Is the abuse log (which is now private) insufficient? — MusikAnimal ^talk 04:57, 16 October 2018 (UTC)

I have no problem with using different text. The filter has already flushed out several IP edits by Qwertywander, and some sophomoric abuse (chutiya is also a term of abuse, apparently). Guy (Help!) 09:21, 16 October 2018 (UTC)

@JzG: What I'm trying to ask is how the tag is at all advantageous over the log. Patrollers will have to be familiar with the case, and do some digging before they can deduce if it's really the LTA. Those who are in the know can simply refer to the abuse log. Overall to me it doesn't seem like tagging is appropriate here, but if it is really desired, would "possible vandalism" suffice? — MusikAnimal ^talk 15:13, 17 October 2018 (UTC)

Happy to go with your judgment here. The tag was intended for generic LTA, not this specific case, there are several LTA cases we could tie to filters. Guy (Help!) 15:57, 17 October 2018 (UTC)

Cool, well if you're okay with it I'll go ahead and remove it. Thank you :) When it comes to filters, LTA-related things are usually hush-hush. The idea being that if they catch wind that they're being tracked, they might change their M.O. and then we don't have a means to identify them anymore. I did assume the tag was created to be multi-purpose, but the same things apply: (a) Patrollers don't know what to look for (as opposed to "possible vandalism" where you could usually tell immediately), especially if it is a shared tag for multiple LTAs, (b) the LTAs themselves can clearly see they're being tracked (and there may be WP:DENY concerns), and (c) the log provides us (those who do know what to look for) the same information whilst being completely hidden from the vandal. I'm not saying the LTA tag is a terrible idea, but it may warrant broader discussion. I also worry its existence will promote further use that in turn may work against us. — MusikAnimal ^talk 19:40, 17 October 2018 (UTC)

Recently, Crow made filter 930 (prevents new users from indexing pages in userspace), which I requested. Crow said that a custom message should be created for the filter, as they could not make it since they are not an admin, so they cannot make pages in the MediaWiki namespace. It has been a few days since the filter was created, but there is still no custom warning for the filter, so I am requesting an admin make a custom warning. ^Semi_Hypercube ✎ 12:47, 13 September 2018 (UTC)

@SemiHypercube: what would you like it to say?

Here is a template: (see parameters at Template:Edit filter warning)

Warning: An automated filter has identified this edit as potentially unconstructive. Please be aware that vandalism may result in revocation of your editing privileges. If this edit is constructive, please click 'Publish changes' again, and report this error.

— xaosflux ^Talk 13:06, 13 September 2018 (UTC)

@Xaosflux: Probably something along the lines of "since it is often used to get high search rankings for promotional pages, which is against policy, page indexing is disallowed for new users" or something similar. ^Semi_Hypercube ✎ 15:51, 13 September 2018 (UTC)

@MusikAnimal: thanks for disabling blocking on this. @Crow: please follow up here. This is another example of why the EF guidelines include Except in urgent situations, new edit filters must not be set to disallow without thorough testing and a notice at the noticeboard to give other edit filter managers and the community time to review the filter for technical accuracy and necessity. — xaosflux ^Talk 18:00, 13 September 2018 (UTC)

Sure thing. I do think disallowing for newbies is appropriate (based on what we've seen so far), but we shouldn't do it without an informative message. I'm not convinced everyone means harm, for instance Special:AbuseLog/22002948 where they tried to add the INDEX magic word, but also added {{advertisement}} to the top. I don't know why... maybe they're just trying to be transparent, but anyway it doesn't seem that malicious.

In my opinion, all draft articles in the userspace should be prohibited from being indexed. That's definitely for a much broader discussion, though. — MusikAnimal ^talk 19:04, 13 September 2018 (UTC)

I expect that sometimes it's just cargo cult editing — they saw the magic word on another page and assumed it must have some purpose. At least, that's the only I reason I can think of why they sometimes add __NEWSECTIONLINK__ and other magic words along with it. The warning message should probably tell them what exactly to remove in case they have no idea they are indexing the page in the first place.

And yeah, I agree that this should be disallowed (silently by the software, like we already do for draftspace) for all users. Search my recent deleted userspace contribs for "G10" and look at how long some of those pages lasted. I don't think any were indexed, but they could have been and probably no one would have noticed. Suffusion of Yellow (talk) 19:44, 13 September 2018 (UTC)

• MusikAnimal pointed me here after an unrelated discussion in the admins IRC channel. I'd support disallowing indexing of userpages by users with less than 100 edits. Would also be fine making it extended confirmed. Don't have a strong preference here, just commenting that I think there is general support for. TonyBallioni (talk) 20:31, 14 September 2018 (UTC)

  @TonyBallioni: something like that should be proposed at VP; and while it is easy to filter on "_INDEX_" if they use a template, etc - it won't be perfect but should catch the egregious uses (can easily catch {{index}} as well). — xaosflux ^Talk 15:03, 15 September 2018 (UTC)

• Hello sorry for my absence, some local issues have kept me tied up in RL. @Xaosflux: point taken on the premature disallow, that was indeed unnecessary as being non-urgent. Perhaps I need to step back a bit and not look at such situations so microscopically. In any case you are completely correct. Regarding the custom warning, I think this thread has it under control so I will withdraw. Crow^Caw 16:45, 15 September 2018 (UTC)

It's been a while, could anyone make a custom warning and set this back to disallow? ^Semi_Hypercube ✎ 21:33, 23 September 2018 (UTC)

@SemiHypercube: this would be in effect a form of semi-protection across an entire namesapce - was there a discussion that this restricted is supported by the community in general you can point to? — xaosflux ^Talk 23:59, 23 September 2018 (UTC)

@Xaosflux: Suggestions for forcing noindexing in the user namespace came up in the discussion of this (failed) proposal. Also, this isn't really a form of semi-protection across an entire namespace. That's a different filter. ^Semi_Hypercube ✎ 12:23, 24 September 2018 (UTC)

@SemiHypercube: I think this may be a good idea, however you will need to gather more support than just at this page to move this to disallow. I suggest WP:VPPR. — xaosflux ^Talk 12:57, 24 September 2018 (UTC)

So, @Xaosflux:, I took your suggestion and, lo and behold, there is clear consensus that allowing search engine indexing of userpages should be restricted to extended confirmed users, not even just confirmed users. ^Semi_Hypercube ✎ 16:23, 7 October 2018 (UTC)

@SemiHypercube: thanks for the note, will make some tweaks to this to get it going, do you have some good verbiage to put in the denial banner? — xaosflux ^Talk 16:42, 7 October 2018 (UTC)

@Xaosflux: The wording could probably be something along the lines of "This edit has been prevented because you have tried to allow a user page to be indexed by search engines. Since this is often used to get high search rankings for promotional pages, which is against policy, page indexing is disallowed for users whose accounts are less than 30 days old or have less than 500 edits." Again, you can probably change the wording, it was hard for me to put the idea into words. ^Semi_Hypercube ✎ 16:51, 7 October 2018 (UTC)

I've updated the documentation at Wikipedia:Controlling_search_engine_indexing#INDEX_magic_word to reflect the new restriction. — xaosflux ^Talk 16:58, 7 October 2018 (UTC)

Special:AbuseFilter/930 has been updated for the new parameters, at least 1 day hold (and needing a custom deny message) before moving to disallow to look for FP's. Pings to prior filter editors: @Crow:, @MusikAnimal:. — xaosflux ^Talk 16:52, 7 October 2018 (UTC)

Regarding custom message, something like:

would seem good. Galobtter (pingó mió) 16:57, 7 October 2018 (UTC)

I've started MediaWiki:Abusefilter-warning-noindexuser, but I don't love it. — xaosflux ^Talk 17:06, 7 October 2018 (UTC)

I was looking through the filter hits, and a large portion, as you'd expect, is spammers trying to spam with G11 stuff; I'm thinking that another sentence with strong message against promotion, perhaps explaining that spam is likely to simply be deleted, may be warranted. Galobtter (pingó mió) 17:18, 7 October 2018 (UTC)

Note that using Wikipedia for advertising may result in deletion of the pages and revocation of your editing privileges? Galobtter (pingó mió) 17:23, 7 October 2018 (UTC)

Here is current:

I'm pretty open to it having more in it. — xaosflux ^Talk 17:22, 7 October 2018 (UTC)

• Warning from MediaWiki:Abusefilter-warning-noindexuser has been added, will move to deny tomorrow if no issues. — xaosflux ^Talk 22:55, 7 October 2018 (UTC)

Disallow has been enabled, revert and let me know if any issues. @SemiHypercube::  Done. — xaosflux ^Talk 20:55, 8 October 2018 (UTC)

Removed index checking from Special:Abusefilter/354 as it collides. — xaosflux ^Talk 21:20, 8 October 2018 (UTC)

Also disabled colliding filter Special:AbuseFilter/840. — xaosflux ^Talk 21:21, 8 October 2018 (UTC)

@Xaosflux: Um...isn't 840 supposed to be a tracking filter? If it was just set so that it only considered x-con users and other users exempt from 930, that would be better. (the whole "filter 840 is for tracking was why I proposed this whole filter in the first place) ^Semi_Hypercube ✎ 21:25, 8 October 2018 (UTC)

@SemiHypercube: OK I re-enabled 840, setting it to track for EC use. We don't really need to track sysop/bot use. — xaosflux ^Talk 21:33, 8 October 2018 (UTC)

@Xaosflux: Thanks. Turns out you were the user who told me that filter 840 was for tracking. ^Semi_Hypercube ✎ 21:35, 8 October 2018 (UTC)

@Xaosflux: (ec) Looks good. But, anticipating future sneakiness, perhaps the filter(s) should look for \{\{\s*index\s*[|}], instead of just {{index}}? Suffusion of Yellow (talk) 21:51, 8 October 2018 (UTC)

@Suffusion of Yellow: can you show me an example of an edit where this occurred? — xaosflux ^Talk 22:36, 8 October 2018 (UTC)

@Xaosflux: Well, all I can find is the not-at-all spammy user pages of Phil Boswell and Problemsmith, which use {{INDEX|visible=yes}}, and the WTF of a page that is User talk:hopiakuta/Archive 7, which uses used {{ index }}. So I guess it's not a huge problem after all, but I figure spammers will eventually try to find a way around this. Suffusion of Yellow (talk) 22:58, 8 October 2018 (UTC)

@Suffusion of Yellow: I changed it to just {{index we don't need to care what (if any) parameter is used I guess. — xaosflux ^Talk 00:00, 9 October 2018 (UTC)

And I dont expect any of these on userspace anyway. — xaosflux ^Talk 00:01, 9 October 2018 (UTC)

@Xaosflux: Thanks. I'll let you know if I notice anyone getting around this. And if too many good-faith cargo-cultists show up at WP:EF/FP/R I'll see if I can improve the warning. I still can't figure why so many hits also include __NEWSECTIONLINK__ or __FORCETOC__. Suffusion of Yellow (talk) 04:17, 9 October 2018 (UTC)

@Xaosflux: Apparently, VisualEditor has been providing a "Let this page be indexed by search engines" option under "Advanced settings" on all pages this whole time. Is there some way to disable this locally on enwiki? If not, perhaps we should have a line like: If you are using VisualEditor, go to "Advanced settings", and under "Let this page be indexed by search engines", choose "Default". for people who just like to stab at buttons and don't understand why they are getting the warning. Suffusion of Yellow (talk) 22:45, 17 October 2018 (UTC)

@Suffusion of Yellow: looks like this has been a complaint for 3 years, see phab:T110329. — xaosflux ^Talk 22:58, 17 October 2018 (UTC)

We could tweak the prompts in there with these messages. — xaosflux ^Talk 23:01, 17 October 2018 (UTC)

Ugh. Hmm, maybe You can click this button if you like, but then we won't let you save the page. So don't click it, mmmkay? And don't ask why we put it here in the first place, if we're not going to let you use it. It's, uh complicated. No, maybe not. Better ideas, anyone? Suffusion of Yellow (talk) 23:52, 17 October 2018 (UTC)

• MAYBE we could hide ooui-27 which appears to be the 'advanced' settings section button. Would need to go try this out on testwiki first. — xaosflux ^Talk 00:43, 18 October 2018 (UTC)

  Yea, no that would be a bad hack at best - and those numbers are not consistent. Would be best to get this fixed from the VE side. — xaosflux ^Talk 00:51, 18 October 2018 (UTC)

• @Suffusion of Yellow: I added some verbiage to those prompts that may help here, should at least explain that the edit may be blocked. — xaosflux ^Talk 01:03, 18 October 2018 (UTC)

  @Xaosflux: It's better than what I could come up with, at least. I tried to answer Deskana (WMF)'s request for data over at phab:T110329, and the problem is even worse than I thought. Of the first 20 hits that still had working (diff) links for me, every single one was made with VisualEditor. I'd be curious to know if the same is true for deleted edits. Suffusion of Yellow (talk) 21:52, 18 October 2018 (UTC)

  @Suffusion of Yellow: 10 out of 10 of the older deleted paged that I checked got their INDEX directive from visual editor. — xaosflux ^Talk 23:27, 18 October 2018 (UTC)

Disallowing - TNT ^💖 08:35, 16 October 2018 (UTC)

938 and 939 probably need updating. There's fresh attacks since they were instituted. I'll leave it to the EF admins to comb through the revdeleted edits at Wikipedia:Help desk and Wikipedia:Teahouse to find good data for helping set this up. It should be noted that the attacker has moved on from the Ref Desks to other help forums, and is still attacking User talk pages, so the scope of the EF should include those as well. --Jayron32 15:54, 22 October 2018 (UTC)

Also, WP:AN has been hit. --Jayron32 18:01, 22 October 2018 (UTC)

Made some updates, thank you - TNT ^💖 18:06, 22 October 2018 (UTC)

Thanks a bunch. This DDOS has really put a hurt on most of the places IPs go for help, which is a shame. Hopefully, the edit filter can be of some help in shutting him down. --Jayron32 12:38, 23 October 2018 (UTC)

See Wikipedia:Edit filter/Requested/Archive_12#Kumioko. --Guy Macon (talk) 00:29, 23 October 2018 (UTC)

I've replied there. Sorry for the wait! — MusikAnimal ^talk 00:07, 25 October 2018 (UTC)

Please add "1-855-479-2999" to this filter if it's technically possible. See contributions of User:Sabnampayal. Seems like this area of articles has some increased spam activity recently. PS: I figured simply naming these numbers here without technical details would be OK, but if you like I can also mail future numbers instead (?). Please feel free to delete this message, if it's not OK on this forum. GermanJoe (talk) 14:45, 26 October 2018 (UTC)

@GermanJoe: please post at WP:EFR. — xaosflux ^Talk 21:02, 31 October 2018 (UTC)

Thanks for the tip, @Xaosflux:. I wasn't entirely sure, if EFR was only for entirely new edit filters or also for edit filter changes. Will post there now. GermanJoe (talk) 21:31, 31 October 2018 (UTC)

Please check this EF log where a new users tried to leave me a normal message but was blocked from doing so by filter 478 multiple times. It seems the filter is too strict and/or does not adequatly explain to new users why it's blocking edits. Regards SoWhy 20:41, 31 October 2018 (UTC)

This is hitting on the phrase (REDACTED admin only link) — xaosflux ^Talk 20:56, 31 October 2018 (UTC)

@SoWhy: and looks like it has been in there for years, added by @NawlinWiki: in 2015. — xaosflux ^Talk 21:00, 31 October 2018 (UTC)

Thanks for pointing that out. That makes sense then. Regards SoWhy 21:15, 31 October 2018 (UTC)

• I really don't think that particular phrase should result in the edit not being allowed. --Floquenbeam (talk) 18:54, 1 November 2018 (UTC)

  @NawlinWiki: any reason this should be kept? — xaosflux ^Talk 18:57, 1 November 2018 (UTC)

  Nawlin's not too active these days. I'll have a trim of the filter over the near future, including this thing. -- zzuuzz ^(talk) 19:01, 1 November 2018 (UTC)

@The Anome: I'm trying to understand the purpose of these changes to filter 890. These new patterns seem to account for a large fraction of the recent hits. Yes, there are many obnoxious names in the log, but I don't see what's disruptive about Daffyduck123456, Hs01234567, Qwertysallybruns, Chris12345632, or Davidsqwerty. There also seem to be a few established users with names like these. These names certainly don't contain a "long sequence of apparently random or otherwise meaningless characters" nor are they particularly "difficult to type, search for, and remember". Or am I missing something? Suffusion of Yellow (talk) 19:43, 2 November 2018 (UTC)

Thanks for the feedback. I think you're right: while this was catching patterns of the "qwertyuiopsdfghjklzxcvbnm" variety (which is what I was aiming for), it was also catching too many false positives. I've backed the changes off. -- The Anome (talk) 14:54, 3 November 2018 (UTC)

I seem to recall a filter that would prevent edits containing unicode (?) letters that were similar, but not identical to actual letters. The closest I can find is 680, which prevents emojis. Any chance we could have one prevent upside-down characters, like in this thread? Sites like [24] make it easy to do. Home Lander (talk) 01:10, 8 November 2018 (UTC)

See [25]. Some troll has too much time on their hands and uses countless open proxies to spam the Teahouse with random generated nonsense featuring usernames. Any ideas on how to create a filter to prevent such edits? Regards SoWhy 13:12, 7 November 2018 (UTC)

@SoWhy: Hard to say without knowing what the content of the edits is (they appear to have been oversighted). More details about the content or edit summary would be useful. If that can't be posted here you can email the edit filter mailing list. Sam Walton (talk) 14:54, 7 November 2018 (UTC)

They've also spammed multiple user talk pages with the same deleted edits. See the list of pages here (permalink). theinstantmatrix (talk) 15:02, 7 November 2018 (UTC)

The edits basically consisted of creating a new section called "[some random text] username [more random, negative text]" filled with symbols using an open proxy in rapid succession. Regards SoWhy 15:23, 7 November 2018 (UTC)

It looks like Zzuuzz has something related at Special:AbuseFilter/940 (won't got into details here). Could the above information be incorporated to this filter? Sam Walton (talk) 10:21, 8 November 2018 (UTC)

I'll drop Sam an email in a bit. We have a throttle at filter 796 (the vandal knows this) which has been working fairly well for some time. A slight change in MO meant it missed some edits for a time yesterday, but that's been fixed. -- zzuuzz ^(talk) 10:29, 8 November 2018 (UTC)

Things are getting out of hand; the user that 938 (and several other filters) was created to address has spread his actions out across all of Wikipedia now. He's basically attacking random pages at will, making it hard to track and stop. See [26] for one example, there's been dozens of these types of attacks just today. --Jayron32 15:58, 9 November 2018 (UTC)

I'm not very confident about edit filters but I've been testing around in my testing filter (886) and it seems potentially effective without false positives (ignore before 2:50, 10 Nov UTC, I changed the filter). Would it be reasonable to move it into a disallow or throttle filter? (This is my first time doing this .) Best, Kevin (aka L235 · t · c) 09:12, 10 November 2018 (UTC)

@L235: one of your conditions is about 'moves' do you have a sample hit on that in your testing log? — xaosflux ^Talk 16:59, 10 November 2018 (UTC)

@Xaosflux: I've removed that condition – there was a lot of that kind of abuse before, but it seems to have largely subsided now. It still seems to be catching quite some disruption. Best, Kevin (aka L235 · t · c) 23:27, 10 November 2018 (UTC)

Moves are restricted to certain users. Anyway, see also 809 where this could be merged if necessary. BTW if someone can help resolve that filter (see recent changes) it would be appreciated. -- zzuuzz ^(talk) 04:33, 11 November 2018 (UTC)

I've now merged most of filter 886,[27] and hopefully nearly resolved the other issue with 809 in a less-than-ideal way. I'll leave it to you whether to fully merge the two filters and/or disable 886. I personally don't think a full merger would be trouble-free. -- zzuuzz ^(talk) 12:06, 11 November 2018 (UTC)

Great work at the Reference desk. You're up all hours and it's much appreciated. One small point - I've checked the edit filter noticeboard as far back as December last year and there's no mention of either filter 796 or filter 941. Is this an oversight? When was filter 796 set to disallow? 109.180.7.39 (talk) 14:54, 11 November 2018 (UTC)

Oh, and could you unprotect the reference desk talk page, which is indefinitely protected at the moment? 109.180.7.39 (talk) 14:56, 11 November 2018 (UTC)

It seems that 886 still catches edits that 809 doesn't and hasn't had false positives yet, and I agree that a full merge would cause problems, so I'm enabling it for now (set to throttle). Please feel free to revert if you disagree or if this is the incorrect process. Best, Kevin (aka L235 · t · c) 23:32, 11 November 2018 (UTC)

1. Task: Prevent addition of "Taslimson" into articles
2. Reason: Someone with multiple IPs have added a non-notable name to articles (usually Indonesian Americans [28] [29] [30] [31] [32] but also other articles e.g. here and here. The edits are straight-up spamming an unimportant name and a non-existent "foundation" all over the place, and is quite an annoyance at this point. At this point, there are absolutely no use (or media coverage outside blogs, see here) of the name in other contexts within Wikipedia beyond complaints about this vandal. Note that this filter has been requested six months ago, and at least four ANI notices [33] [34] [35] [36]. Juxlos (talk) 15:42, 15 November 2018 (UTC)

   Juxlos, weird as to the lack of replies in the earlier thread but this ought be very easily process-able, even as a de-novo filter.

   But am pretty certain that filters of this sort already exist and this can be punched. ∯WBG^converse 15:58, 15 November 2018 (UTC)

@Winged Blades of Godric: Yeah, just that this seems to take a while in the response time department and would rather get it done before the mext set of vandalism. Juxlos (talk) 18:44, 15 November 2018 (UTC)

@Juxlos: please see WP:EFR to request or (re-request) new filters . — xaosflux ^Talk 15:53, 15 November 2018 (UTC)

@Xaosflux: Oops, my bad Juxlos (talk) 15:55, 15 November 2018 (UTC)

My mistake actually, I'm the one who pointed Juxlos to EFN. Oops! :) Ben · Salvidrim! ✉ 18:19, 15 November 2018 (UTC)

I'm dealing with a fascinating FP right now. It seems the user attempted one edit to the page, and it was logged as "Repeated attempts to vandalize". And, the (diff) link in the log points to different user. That part is probably explained by phab:T198651 (see also this thread), but I'm wondering if the throttle setting should be changed from "user,page" to "user,ip,page". Otherwise, if I'm understanding throttling correctly, we are lumping all logged-out users together as one user, so this filter will be triggered if e.g. four distinct IPs make unrelated changes to the page within five minutes, or one IP make repeated vandalism attempts, and another comes along (again within five mintes) and makes a good-faith edit. Or is this the way the filter is intended to work, i.e. tag raids and IP-hoppers? Suffusion of Yellow (talk) 00:28, 21 November 2018 (UTC)

 Done Access granted per support below. — xaosflux ^Talk 00:49, 21 November 2018 (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.

---

Earliest closure has started. (refresh)

• Suffusion of Yellow (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)^{( · · · · · · · · · )}

Well, I've been helping out at WP:EF/FP/R for the past few months, making edits for users who tripped filters, and pestering admins with suggested fixes. Some reports relating to private filters have been going unanswered, leading me to ping-spam every filter editor I can find in Special:log/abusefilter. If given this right, I'd be able to help these users myself, and only bother other people when the filter looks fixable. I'd also like to start helping out at WP:EF/R a bit, but without access to Special:AbuseFilter/test, it's difficult to come up with a good filter, except in trivial cases, where EFMs don't really need help. Of course, I understand the importance of account security (and security in general), and of not discussing the details of private filters in public. Suffusion of Yellow (talk) 23:31, 17 November 2018 (UTC)

Yes, please. Suffusion of Yellow has been an enormous help. I believe I even suggested they seek management rights, but "helper" is certainly a good start. — MusikAnimal ^talk 05:24, 19 November 2018 (UTC)

• Support this due to the level of help at EFFP. Crow^Caw 17:28, 19 November 2018 (UTC)
• Support, clearly. I'm not quite clear on whether EFH requests are granted by solely consensus among users, or if the three day waiting period is to see if anyone objects and if not, then as long as the promoting admin agrees, give the user EFH, so if someone could enlighten me regarding this that would be greatly appreciated, as I can't seem to find the answer anywhere. Anyways, I've seen Suffusion of Yellow a lot at EF/FP/R, and from what I've observed they're (he or she?) very knowledgeable with abuse filters, an excellent vandalism fighter, always kind and helpful to new users, obviously trustworthy, and has demonstrated a clear need for the tools, so imo, granting them edit filter helper would clearly be a net benefit to the project.--SkyGazer 512 ^{Oh no, what did I do this time?} 03:08, 20 November 2018 (UTC)

  @SkyGazer 512: Wikipedia:Edit filter helper has most of this - in general if you check all the boxes and there are no serious concerns an admin can grant this, in general consensus is the overriding factor and the RfC that created this was by consensus. In practice, a few supports with no objections are normally sufficient. — xaosflux ^Talk 03:34, 20 November 2018 (UTC)

Thanks for the explanation; based on what I had seen from previous discussions, I had thought this or something similar might be the case, but I really wasn't sure. The page you linked doesn't really explain this clearly, it just says that the right will be granted if the request was successful.--SkyGazer 512 ^{Oh no, what did I do this time?} 16:08, 20 November 2018 (UTC)

• Support. -- zzuuzz ^(talk) 17:12, 20 November 2018 (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.

I'm particularly thinking of my request at Wikipedia:Edit filter/Requested/Archive 12#Switching text from Israel to Palestine or Indian to Pakistan. There are others of course. Thanks. Doug Weller talk 15:02, 23 November 2018 (UTC)

@Doug Weller: I don't know the answer to your general question, but I've un-archived your post, at least. Perhaps the archive time should be tweaked. Suffusion of Yellow (talk) 23:04, 23 November 2018 (UTC)

I've changed the delay to two weeks. Maybe it should be even higher. Suffusion of Yellow (talk) 23:09, 23 November 2018 (UTC)

@Suffusion of Yellow: thanks. I'm not at all sure that's long enough. I'm surprised it was shorter. Doug Weller talk 18:41, 24 November 2018 (UTC)

Hi all, want to discuss strategy for enforcing: Special:PermaLink/870355366#RfC:_should_we_automatically_pending-changes_protect_Today's_Featured_Articles?. The RfC closed with consensus to disallow non-autoconfirmed users from adding images on TFAs, as a default measure. This appears to require an edit filter, but we will also need something to match on. The pages are already being updated by @Legoktm: 's TFA Protector Bot - so perhaps that could be worked in to the process (e.g. adding and removing a comment code to say "this is currently the TFA"). Any ideas before people start building this? Some pings to some people from the RfC: @MusikAnimal: , @L293D:. — xaosflux ^Talk 15:28, 24 November 2018 (UTC)

@Xaosflux: I asked Legoktm if they were interested in implementing the bot task, and got no reply. I'm happy to take it on. This will be quite easy to implement, and I'm eager to get it done as soon as possible. Shall I file a BRFA? — MusikAnimal ^talk 17:04, 24 November 2018 (UTC)

Related, I've created Special:AbuseFilter/943. I know that's a quite unwanted solution, but think of it as a temporary, emergency safeguard. If you disagree with it, feel free to disable. — MusikAnimal ^talk 17:24, 24 November 2018 (UTC)

@MusikAnimal: 943 seems OK, I'd hope it never actually hits now. — xaosflux ^Talk 18:03, 24 November 2018 (UTC)

@MusikAnimal: the full 'extra protection' seem fine for now. — xaosflux ^Talk 21:51, 24 November 2018 (UTC)

Right now, 17 filters are set to "warn, disallow". This is kind of pointless; if the edit is never going to save, we should just be disallowing it up front. Of course, in most cases this was just because the software didn't have an option for custom "disallow" messages, so if we wanted to show the user a custom message, it had to be a warning. But thanks to a recent software update, it looks like it is now possible to have custom disallow messages. I'd suggest the following changes:

• 46, 320, and 365: Generic vandalism filters. Use plain old MediaWiki:abusefilter-warning. Not sure why these have warnings at all. Probably should just use the standard disallow message, with no warning. No need to encourage the user to "click 'Publish changes' again" when it's not going to work.
• 554 "top100 blog charts": Current warning, MediaWiki:abusefilter-top100 should probably just be the disallow message. No need to bring in the WP:BITEy "Disruptive editing may result in a block from editing." from MediaWiki:abusefilter-disallowed for people just citing unreliable sources.
• 642 "OTRS template added by non-OTRS member (global)": Current warning, MediaWiki:abusefilter-warning-otrs, looks good as a disallow message, but should include a link to WP:EF/FP.
• 680 "Adding emoji unicode characters": Current warning, Mediawiki:abusefilter-warning-emoji looks fine as a disallow message.
• 694 "Moves to or from the Module namespace": Current warning, MediaWiki:abusefilter-warning-scribunto-contentmodel should have a link to WP:EF/FP, but is otherwise fine.
• 782 "Content Translation Edits": Current warning, MediaWiki:abusefilter-warning-cx looks fine but needs a WP:EF/FP link.
• 803 "Prevent new users from editing other's user pages": Current warning, Mediawiki:abusefilter-warning-userpage is good as a disallow message, but needs a WP:EF/FP link.
• 887 "Excessive repetition in usernames" and 890 "Random typing in username": Not sure what to do here. If we encourage the user to report the false positive, we are encouraging them to make their IP address public, since if they were hit by these filters, they don't have an account yet. Maybe just the make the warnings the disallow messages, and let the user figure it out? Or send them to WP:RAC? In any case, generic disallow is too WP:BITEy here.
• 892 "RS linked through proxy". Generic disallow definitely way too BITEy. Current warning MediaWiki:abusefilter-warning-proxy-link should have a WP:EF/FP link but is otherwise good.
• 930 "Prevent indexing userspaces by newer users" Current warning, MediaWiki:abusefilter-warning-noindexuser looks good as-is.

Also see the private filters 68, 139, 648, and 651. They might need some changes, but I don't want to try to figure out which filter uses which warning. Suffusion of Yellow (talk) 21:27, 22 October 2018 (UTC)

@Suffusion of Yellow: Thank you for creating this list! I have removed the warnings and adjusted the disallow messages for all the said filters. I did not modify any of the messages, though. MediaWiki:abusefilter-top100 in particular I think is fine... it may be a little bite-y, but it's not as bad it used to be!

Under principle I agree all disallow/warn messages should link to WP:EF/FP, but at least for a few of the filters there's a slim to no chance of false positives, such as 694. Anyway, I'll try to update them all soon, but anyone else should feel free to do it and not wait on me. Thanks again! — MusikAnimal ^talk 22:48, 23 October 2018 (UTC)

Can someone provide some insight as to what is happening here? To me it looks like someone is trying to create an account but is getting blocked by an “abusive account names” filter, even though the username does not appear abusive, and they are repeatedly resubmitting the account creation and therefore creating quite a flood. I’m also concerned that the filter in question appears to be private (hence I don’t even know the ID number) as monitoring for abusive account creations is something that anyone can do and should not require advanced permissions. — Matthew Wong (at PMA), 15:32, 28 November 2018 (UTC)

This is a filter which, among other things, prevents user names containing three consecutive hyphens (don't blame me). For the sake of this one user who already has a global account, I've extended it to four. -- zzuuzz ^(talk) 15:39, 28 November 2018 (UTC)

Thanks, but why is that filter private anyway? There are many filters that are blocking far worse things than 3 consecutive hyphens that are publicly visible. — Matthew Wong (at PMA), 15:44, 28 November 2018 (UTC)

I did say among other things. Among other things it blocks some bad LTA stuff. According to my interpretation of the addition (admin only), this pattern actually formed part of some LTA abuse. -- zzuuzz ^(talk) 15:46, 28 November 2018 (UTC)