Wikipedia:Edit filter noticeboard/Archive 6

This is an archive of past discussions about Wikipedia:Edit filter noticeboard. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current main page.

Archive 1

←

Archive 4

→

RfC on Meta

There is an RfC on meta about creating a global usergroup with the permission to edit editfilters on all wikis. See m:Requests for comment/Creating abusefilter-manager global group. Thryduulf (talk) 23:48, 20 August 2019 (UTC)

AfD filter

Based on the discussion here: WP:AN/I#183.177.231.187 IP editor mass !voting at AFD (almost botlike) (permalink)

I created the following possible edit filter:

user_age == 0 &
page_namespace == 4 &
page_title rlike "Articles for deletion/"

This would theoretically prevent any IP user from editing an AFD discussion. Can I get feedback on it? –MJL ‐Talk‐^☖ 15:36, 7 August 2019 (UTC)

There are a number of private filters already available, some of which may or may not be running, but yes something like that would do what you say should it ever be required. Since you asked for feedback, there is no need to use rlike (regex) which is more expensive than contains (plain text). -- zzuuzz ^(talk) 15:54, 7 August 2019 (UTC)

I regularly close AFDs and I've seen plenty of useful contributions from IP addresses, sometimes comments and sometimes formatting. Is there a specific pattern of IP addresses doing this? Jo-Jo Eumerus (talk, contributions) 16:04, 7 August 2019 (UTC)

Just a quick note that this isn't the place to decide whether IPs should be permitted to contribute to AfD discussions, that would need to be a (fairly substantial) RfC elsewhere. Sam Walton (talk) 16:16, 7 August 2019 (UTC)

I don't think anyone's suggesting that (or at least I hope not), but in some emergency short-term situations (like the one mentioned) it's something that it might be wise to be prepared for. In any case, always poke the other edit filter managers, because we have ways to avoid such severe actions. -- zzuuzz ^(talk) 16:20, 7 August 2019 (UTC)

@Samwalton9 and Jo-Jo Eumerus: zzuuzz has it right. There was recently an incident of an LTA (via IP) spamming keep votes at AFDs. It was thrown out there that maybe an edit filter would help. There wasn't any public ones I was aware of, so I wanted to try my hand at writing one. I'm not asking for it to be implemented or anything.
@zzuuzz: Thank you for that feedback!

–MJL ‐Talk‐^☖ 19:30, 7 August 2019 (UTC)

How about tagging, so that RC patrollers get a heads-up? Guy (Help!) 09:12, 24 August 2019 (UTC)

Filter 869

Filter 869 traps use of the Daily Mail as a source. I have expanded this to allow other deprecated sources in Wikipedia:Reliable sources/Perennial sources, starting with VDARE, which has been used for BLP violations and is also known for publishing antisemitic and white nationalist content. I have also edited the filter warning and changed it to use a parameter for the list of deprecated websites.

This is also relevant to 894 .

Was:

equals_to_any(page_namespace, 0, 118) & (
    contains_any(added_lines,
      "AuthorHouse ",
      "Author House ",
      "Trafford Publishing",
      "iUniverse",
      "ublisher=Lulu.com",
      "ublisher = Lulu.com",
      "Xlibris"
    ) &
    !contains_any(removed_lines,
      "AuthorHouse ",
      "Author House ",
      "Trafford Publishing",
      "iUniverse",
      "ublisher=Lulu.com",
      "ublisher = Lulu.com",
      "Xlibris"
    )
) &

Now:

equals_to_any(page_namespace, 0, 118) & 
(
    selfpub := "author\s?house|trafford\s?publishing|iuniverse|publisher\s?[=,:]\s?lulu\.com|xlibris";
    added_lines irlike selfpub &
    !(removed_lines irlike selfpub)&
    !("bot" in user_groups) &
    !("AFCH" in summary)
)

In theory this should work and match, e.g. AuthorHouse, authorhouse, Author House etc. but \s? is implementation specific in regex - a quick test shows it does appear to work but insight form more experienced filter mavens would be appreciated. Guy (Help!) 10:22, 24 August 2019 (UTC)

Currently, filter 869 has a negligible average run time of 0.15 ms, which only increased by 0.02 ms (from 0.13 ms) when eight domains were added. There is RfC-based consensus to filter nearly all of the sources listed in WP:DEPSOURCES. — Newslinger talk 08:56, 25 August 2019 (UTC)

After checking on the filter throughout the day, the run time ranges from 0.13 ms to 0.18 ms (although JJMC89's optimization in Special:AbuseFilter/history/869/diff/prev/22238 may have improved it). Considering the normal variance, the addition of the eight domains did not affect performance in a measurable way. — Newslinger talk 03:01, 26 August 2019 (UTC)

@JzG: Globalresearch.ca has been added to the spam blacklist, and can probably be removed from this filter. — Newslinger talk 07:13, 28 August 2019 (UTC)

Filter 320

320 (hist · log)

Hi. I noticed that the filter didn't catch [1], because it added `yo mom` instead of `yor mom`. I looked in the batch testing interface, and didn't see any false positives from changing \b(UR|Y(E|A|O|OU)(H|R|\'RE)) to \b(UR|Y(E|A|O|OU)(H|R|\'RE)?) - can I request that someone set up a logging filter for a couple days to confirm that there are no false positives, and if there aren't change the filter accordingly?

To ensure that the testing filter doesn't include the changes that the current filter catches, the following filter conditions can be used:

user_editcount < 22 &
equals_to_any( page_namespace, 0, 3 ) &
edit_delta < 200 & (
    your_mom := "\b(UR|Y(E|A|O|OU)(H|R|\'RE)?) *M((O|U|A)M+(Y|A)?|[UO](V+|TH)(A|ER))S?\b";

    ccnorm(added_lines) rlike your_mom & 
    !ccnorm(removed_lines) rlike your_mom &

    !contains_any(lcase(added_lines), "basement","borden","how i met your mother", "ozzy osbourne", "your mother would be proud", "[[does ", "honor your father", "is your mother", "should know") &
    !("Maternal insult" in page_title) &
    !(rcount("\"", added_lines) > rcount("\"", removed_lines)) &
    !(rcount("''", added_lines) > rcount("''", removed_lines))
) &!
(
    your_mom := "\b(UR|Y(E|A|O|OU)(H|R|\'RE)) *M((O|U|A)M+(Y|A)?|[UO](V+|TH)(A|ER))S?\b";

    ccnorm(added_lines) rlike your_mom & 
    !ccnorm(removed_lines) rlike your_mom &

    !contains_any(lcase(added_lines), "basement","borden","how i met your mother", "ozzy osbourne", "your mother would be proud", "[[does ", "honor your father", "is your mother", "should know") &
    !("Maternal insult" in page_title) &
    !(rcount("\"", added_lines) > rcount("\"", removed_lines)) &
    !(rcount("''", added_lines) > rcount("''", removed_lines))
)

thanks, --DannyS712 (talk) 06:28, 29 August 2019 (UTC)

Filter 971 and fixes to filter times

(see Wikipedia:Edit_filter/Requested/Archive_13#File_name_changes for previous discussion)

~~Unarchiving because~~ phab:T219092 has been fixed (when it is deployed the next WP:THURSDAY), so the slow filter dashboard should report more accurate results. @MusikAnimal: are you still monitoring the slow filter dashboard? I think we can test reenabling the filter with the more accurate timings and see if it is reported as slow. Galobtter (pingó mió) 03:43, 5 August 2019 (UTC)

@Galobtter: I just read through this entire thread wondering why I hadn't seen t, since the dates go back to October - seeing the rational, can I suggest that this be moved to WP:EFN, since it affects more than just this filter? --DannyS712 (talk) 04:20, 5 August 2019 (UTC)

@DannyS712: moved, and I guess unarchiving is not the best way of doing it due to causing confusion, so fixed. Galobtter (pingó mió) 05:08, 5 August 2019 (UTC)

Let me reping MusikAnimal to see if he has anything to say.. Galobtter (pingó mió) 05:08, 20 August 2019 (UTC)

@Galobtter: I have been slacking on checking on the slow filter dashboard but I certainly can help with this. I will be on wikibreak until Tuesday UTC, however. Daimona Eaytoy has access and may be able to help in the meantime. Best, — MusikAnimal ^talk 16:16, 20 August 2019 (UTC)

Yes, I can surely check logstash. You can re-enable the filter and ping me after a couple of days. --Daimona Eaytoy (Talk) 17:51, 20 August 2019 (UTC)

Thanks both of you. I've re-enabled it and will ping in a couple of days. Galobtter (pingó mió) 23:32, 25 August 2019 (UTC)

Filter seems to be doing well - @Daimona Eaytoy and MusikAnimal:, could either of you check the slow filter dashboard to see if there are any issues? Thanks. Galobtter (pingó mió) 20:02, 27 August 2019 (UTC)

@Galobtter: No entries about that filter since you re-enabled it. So that's great! As a side note, the runtime of filters has slightly increased lately due to some changes to the parser. And in the (possibly near) future we're planning to re-enable the alternative parser (T156095), which also caches the AST, and thus the runtime of all filters will be greatly reduced (see a preview). I still don't know how to handle slow filters with that: the average runtime will be way shorter, but it'll remain at the current levels in case of cold cache. I opened T231112 for that. Then, the runtime will be reduced further with T230982, which is also responsible for the current slowdown. And by that point, almost no filter will be reported as slow with the current threshold. --Daimona Eaytoy (Talk) 08:53, 28 August 2019 (UTC)

Daimona Eaytoy, thanks for checking - good to see! Also, I'm aware of the caching parser, and it is great that there's progress on re-enabling it. Galobtter (pingó mió) 17:55, 28 August 2019 (UTC)

Yes, that's pretty great! We're almost done with the backend fixes, all we need now is to fix broken filters across the wikis. I'm sorry that profiling data won't be very useful after enabling it, but slowdowns should also be less likely. --Daimona Eaytoy (Talk) 08:58, 29 August 2019 (UTC)

Special:AbuseFilter/891 support Template:Doi

If you add something like |doi=10.1234/..., you will trip the edit filter. However, if you add {{doi|10.1234/...}}, you won't. The EF should be updated to handle the second case. Headbomb {t · c · p · b} 19:51, 31 August 2019 (UTC)

Tweaked filter to catch that. Thanks! Crow^Caw 20:35, 31 August 2019 (UTC)

@Crow: You might to catch plain text 'doi:10.foobar' or doi:10.foobar as well. Headbomb {t · c · p · b} 20:57, 31 August 2019 (UTC)

Should catch those now as well. Crow^Caw 21:03, 31 August 2019 (UTC)

There's a 'frontiers\.in' check in there as well. Seems a a very weird filter to have, especially since there is no https://www.frontiers.in/. That should be removed. Headbomb {t · c · p · b} 21:11, 31 August 2019 (UTC)

Ping @JzG: who added that and the above section. Crow^Caw 21:13, 31 August 2019 (UTC)

I'll point out here that if the goal is to filter out Frontiers Media journal, that's an abuse of this edit filter. Headbomb {t · c · p · b} 21:19, 31 August 2019 (UTC)

As the regex sits now, it will flag on *frontiers.in* with the decimal delimiter, so should not flag on frontiersin.org. The Article for Frontiers includes a notice at the top that many journals use "frontiers in" so perhaps this was a way to flag the imposters? Crow^Caw 21:28, 31 August 2019 (UTC)

Nah, those aren't imposter journals, rather it's a very common name for book series and other journals. So if you land at Frontiers Media through its various redirects, you might want to make sure that you weren't searching for a non-Frontiers journals. E.g. Frontiers of Physics instead of Frontiers in Physics. Headbomb {t · c · p · b} 21:36, 31 August 2019 (UTC)

@Crow: could you add namespace 10 (templates) while you're at it? Headbomb {t · c · p · b} 15:31, 1 September 2019 (UTC)

Added. Crow^Caw 16:23, 2 September 2019 (UTC)

RfC proposing an edit filter

Watchers may be interested in an ongoing RfC, Wikipedia:Village pump (proposals) § RFC: Block edits that contain a VisualEditor bug DannyS712 (talk) 04:43, 5 September 2019 (UTC)

New edit filter warning for filter 365

Implemented as below. This NB is a fine venue for this type of request (simply changing the message on a multi-purpose filter). EFR would have been fine too. — xaosflux ^Talk 12:51, 18 September 2019 (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.

I think the edit filter warning for filter 365 (hist · log), Unusual changes to featured or good content, should have a custom edit filter warning since it's catching good faith edits. My suggestion is something like User:Trialpears/Abusefilter-disallowed-unusual-changes-to-featured-or-good-content, but would like some input from experienced edit filter users. --Trialpears (talk) 17:12, 7 September 2019 (UTC)

Any thoughts? Is this how you make edit requests to abuse filters? Could someone implement this? --Trialpears (talk) 08:28, 18 September 2019 (UTC)

Here is probably as good as anywhere, even if WP:EFR might be a more traditional place for requests. Edit filter people can sometimes be a bit slow unless poked. As the filter's primary author I don't really see any problem with this custom warning. I suppose the wording could be tweaked a bit about what to do next. I'd be curious about any examples of false positives. The filter usually picks up so much crap it's very difficult to spot them. -- zzuuzz ^(talk) 08:56, 18 September 2019 (UTC)

I've implemented the change, seeing as it was proposed in a reasonable place for 11 days with no opposition. Jo-Jo Eumerus (talk, contributions) 09:05, 18 September 2019 (UTC)

There was a good faith edit reported to WP:EFFP and that's why I wanted this change, and I wouldn't be suprised if a percent or two are good faith, could check if you really want me to. --Trialpears (talk) 12:39, 18 September 2019 (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.

Unseemingly broken filters

Hello all! Due to a recent update in the AbuseFilter parser, you may be able to save a filter even though it has invalid syntax (T234339). In particular, this is affecting enwiki's filter 874; the error is pretty easy to spot, as it was introduced with this change. Could someone please fix it? Thanks, --Daimona Eaytoy (Talk) 17:43, 1 October 2019 (UTC)

@Daimona Eaytoy: for Special:AbuseFilter/874 the pattern in the description for phab:T234339 does not appear to be present. If the change is on a non-private component, would you please specify what you would like changed below? Optionally, you can drop me an email with the requested change here: Special:EmailUser/Xaosflux. — xaosflux ^Talk 17:55, 1 October 2019 (UTC)

@Xaosflux: Yeah, the example on phab is simplified. The filter is private, so I'm not gonna say too much. However, if you look at the edit linked above, you'll see that there's an extra + in the regexp. Hence, the regex is invalid overall. I think that you can simply remove the plus. --Daimona Eaytoy (Talk) 18:01, 1 October 2019 (UTC)

@Daimona Eaytoy: thanks for the note, think I got what you were talking about resolve here: Special:AbuseFilter/history/874/item/22371 - if not please drop me an email. — xaosflux ^Talk 18:09, 1 October 2019 (UTC)

@Xaosflux: Your edit is totally fine, thanks! --Daimona Eaytoy (Talk) 18:23, 1 October 2019 (UTC)

Fake/Deceptive journal journalofm.org

Please someone blacklist/EF this website per [2]. Headbomb {t · c · p · b} 13:02, 27 September 2019 (UTC)

I'm not sure I see any real problem here, but I might be missing something. EggRoll97 ^(talk) 04:51, 28 September 2019 (UTC)

This isn't a journal, it's Wikipedia articles reformatted in a fake journal format, so that students can link to a fake paywall site that looks legit. Read the Forbes story linked above. Headbomb {t · c · p · b} 18:25, 1 October 2019 (UTC)

Added to the Spam blacklist. — JJMC89 (T·C) 01:35, 2 October 2019 (UTC)

RfC proposing a new filter

Would an uninvolved edit filter manager please assess the discussion at Wikipedia:Village pump (proposals)/Archive 161#RFC: Block edits that contain a VisualEditor bug and determine if a new filter should be created to disallow the specified edits? A close was requested at Wikipedia:Administrators' noticeboard/Requests for closure#Wikipedia:Village pump (proposals)/Archive 161#RFC: Block edits that contain a VisualEditor bug but since the result may require editing a filter, it should be closed by someone with the ability to do so, so cross-posting here for more visibility. Thanks, --DannyS712 (talk) 01:34, 15 October 2019 (UTC)

@GreenC: as you opened that. There is general support to prevent these bad edits, though part of the discussion suggests that it was due to a bug that has since been resolved. Is this issue still occurring? Can you provide a recent example of the bad edit? — xaosflux ^Talk 02:46, 15 October 2019 (UTC)

@ESanders (WMF): says the bug is probably fixed. Determining has proven difficult because it requires knowledge of what actions editors took and when I ask them (admittedly I only asked two) they don't respond or don't remember. And it's been difficult to show unambiguously the text was caused by the bug and not old data/sessions that contained copies. If the bug has truly been fixed it doesn't make sense to add the filter. But edits like this by an editor who has only ever made a single edit to Wikipedia are spooky, it suggests the bug still occasionally occurs, in which case the edit filter would make sense. What do you think ESanders? -- GreenC 03:58, 15 October 2019 (UTC)

Suggest that this is a "log and warn" only filter at least for a while, but the warning would need to be useful to the editor. — xaosflux ^Talk 11:48, 15 October 2019 (UTC)

@Xaosflux: Not sure how filters work but can it point to Template:Warning VisualEditor bug? -- GreenC 02:40, 16 October 2019 (UTC)

@GreenC: yes, they can use templates, and they can use custom markup as well; we generally have a few standard layouts - and then any custom verbiage, each filter can have its own message, it should be whatever will be most useful to the person making the edit. An example of one can be seen here: MediaWiki:Abusefilter-warning-ref-group-blanking. — xaosflux ^Talk 02:46, 16 October 2019 (UTC)

Add exception to edit filter 890 for account creators

Frood recently reported the following false positive at WP:EFFP/R and I'm moving it here to attract more attention for edit filter managers. The following is a direct copy of their second report after the first one got archived:

Previous post was archived before anything actually happened with the filter. Attempting to create an account for WP:ACC (request #261368) and filter 890 is preventing me from doing so. I'm in the accountcreator group and have chosen to override both spoofing and title blacklist checks. The username, while seemingly random, does appear to be legitimate based on some researching I've done prior to trying to make the account. The filter looks like it has an exemption for users with override-antispoof, but only for automatically-created accounts (which isn't the case for ACC).

I'm not super familiar with how the EF syntax works, but I think it'd have to turn into something like:

(
   (action == 'createaccount' | action == 'autocreateaccount') &
   !('override-antispoof' in user_rights)
) &
lcase(accountname) rlike "[bcdfghjklmnpqrstvwxz]{9}"

--Trialpears (talk) 15:12, 9 October 2019 (UTC)

Log of denial is here. — xaosflux ^Talk 15:31, 9 October 2019 (UTC)

Ping for @MusikAnimal:.[3] I don't really understand why this change would have been done. -- zzuuzz ^(talk) 15:46, 9 October 2019 (UTC)

@Zzuuzz: phab:T230256. Basically user_rights doesn't exist for the 'createaccount' action anymore. This means that check would fail because the variable is undefined. But I realize now that is only true when creating your own account for the first time, when you do not have any user rights. Using Special:CreateAccount while logged in would mean that user_rights is defined. I suppose we need to somehow check that user_rights is defined before running comparisons on it, regardless of the action? This may be a bug with AbuseFilter. Pinging Daimona Eaytoy for input. — MusikAnimal ^talk 05:15, 10 October 2019 (UTC)

Exactly. There's some rationale on phab about that. Basically, until a few weeks ago, all unset variables were just null. This means that you can create shorter filters, but sometimes they'll be unpredictable (a recycled example: edit_delta < -50000 would match *all* actions !== edit). Hence, I had changed the AF parser to assign unset variables a "special" value; such value consistently makes any expression containing those variables return false, hence some filters stopped working. I then realized that way too many filters were relying on this kind of shorthands; hence, I decided to switch back to the old behaviour (i.e. use NULL). The patch for that is still under review, though. --Daimona Eaytoy (Talk) 12:41, 10 October 2019 (UTC)

This seems to work, and should continue to work once the change is reverted:

action == "createaccount" & /* Or action contains "createaccount" if we really want to stop autocreations... */
(
    user_rights ?
        !('override-antispoof' in user_rights) :
        true
) &
lcase(accountname) rlike "[bcdfghjklmnpqrstvwxz]{9}"

Daimona Eaytoy, is this the "right" way to check if a variable is defined before using it? Seems strange that !foo | ("bar" in foo) doesn't work, but foo ? ("bar" in foo) : true does, when they seem logically equivalent. Even weirder, !foo ? true : ("bar" in foo) doesn't work either. Suffusion of Yellow (talk) 20:12, 14 October 2019 (UTC)

There's no "right" way, but usually it should be enough to check action. However, sometimes (like in this case) it's not enough. That's why I wanted to add an is_set(varname) function, but that's under review as well. The behaviour is weird due to the very special way that unset variables are treated. As an alternative you could use var === var; if the variable is unset, it will return false. --Daimona Eaytoy (Talk) 12:19, 15 October 2019 (UTC)

Ok,

Done, but set the filter to log-only just in case.

@Frood: (or anyone else with override-antispoof rights), can you try to create an account matching this filter, e.g. bcdfghjklmnpqrstvwxz. You won't be stopped in any case, but if all is working well nothing should appear in your filter log.
@MusikAnimal: Your change also ~~blocked~~ tried to block autocreations from people without override-antispoof rights, but before that all autocreations had been allowed. I assumed that was unintentional, so now I'm just blocking manual creations
- Adding: Actually, it appears user_rights is undefined for autocreations, too. See last few hits from Special:AbuseFilter/2. So we haven't matched any autocreations on any filter, since August 6...
@Daimona Eaytoy: Are you sure? At Special:AbuseFilter/examine/log/25084908, both (user_rights === user_rights) and !(user_rights === user_rights) fail to match. Suffusion of Yellow (talk) 23:08, 18 October 2019 (UTC)

Yes, that's intended. As I said, any comparison involving unset variable will return false. --Daimona Eaytoy (Talk) 09:08, 19 October 2019 (UTC)

@Daimona Eaytoy: (Sorry for all the pings, but I'm having trouble getting this...) If (user_rights === user_rights) === false, then !(user_rights === user_rights) should equal !(false), that is, true, which doesn't seem to be the case. Suffusion of Yellow (talk) 22:32, 19 October 2019 (UTC)

@Suffusion of Yellow: No problem, I recognize it's not easy :) So, user_rights (like other unset variables) has a special data type, "undefined" (which is just internally available). user_rights === user_rights is again undefined, and so is !undefined. In this sense, it's a "special" data type, created to ensure that you won't get unintended matches. A way to use it is e.g. ( user_rights === user_rights ) | ( code to execute if user_rights is unset ). --Daimona Eaytoy (Talk) 12:41, 20 October 2019 (UTC)

@Daimona Eaytoy: At that point, Suffusion of Yellow was enlightened. Maybe. Let mu be any unset variable. Then I think I got this right:

Expression	Old way	New way (but soon to be reverted)
mu \| true	true	true
true \| mu	true	true
mu \| false	false	false
false \| mu	false	false
(!mu) \| true	true	true
true \| (!mu)	true	true
(!mu) \| false	true	false
false \| (!mu)	true	false
mu & true	false	mu
true & mu	false	false
mu & false	false	mu
false & mu	false	false
(!mu) & true	true	mu
true & (!mu)	true	false
(!mu) & false	false	mu
false & (!mu)	false	false
(mu === mu)	true	mu
(mu !== mu)	false	mu

Yes, & seems non-commutative now. Someone may want to double check that, though. :-) Suffusion of Yellow (talk) 03:44, 22 October 2019 (UTC)

@Suffusion of Yellow: Thanks for the table :) Yes, it does seem to be correct. & being non-commutative is definitely a bug that I should fix (it should always be mu). The rest reflects the intention behind undefined data. Note, however, that it won't be fully reverted. The part that will be reverted is assigning an undefined value (as opposed to null) to unset builtin variables when checking filters. However, unset variables will still be undefined when checking syntax (although that doesn't really matter), and custom variables will also be undefined. For instance, (false & (foo := 'bar')); something_using_foo: in the something_using_foo part, foo will be undefined. --Daimona Eaytoy (Talk) 08:28, 22 October 2019 (UTC)

Fixed?

I've set the filter back to disallow. Could an admin or accountcreator please try to create the account "jsghgdlzccn"? I see a few other filters that need fixing, but want to be sure that this works first. Suffusion of Yellow (talk) 22:39, 19 October 2019 (UTC)

@Suffusion of Yellow: See [4]. I encountered no errors at all and I don't see anything in my filter log. Feel free to ping me if you need an ACC guinea pig.

‑‑ElHef (Meep?) 13:09, 21 October 2019 (UTC)

@ElHef: Thanks. Fixed (hopefully) some other filters as well. In theory now no filter should prevent any accountcreator (or admin) from creating any account. If you have any trouble, let us know. Suffusion of Yellow (talk) 02:15, 22 October 2019 (UTC)

@Suffusion of Yellow: Thanks for doing that. The account that originally brought this request was created a few days ago. That said, I think it would be better long-term to give accountcreators the ability to override these filters rather than simply skipping them - like antispoof checks, where we get the error and have to check the box to override it. There have been many occasions where I did all my checks, gone to create the account, and had antispoof find something that I had completely missed. It would be nice to have the filters work the same way, especially since I have no idea what all the filters are looking for (and wouldn't even if I could see the private ones, since I'm not fluent in regex). Of course, I'm not techy enough to really know what I'm asking for, and I'm guessing this would be more complicated than just changing the filters. ‑‑ElHef (Meep?) 17:55, 22 October 2019 (UTC)

@ElHef: Good idea, but unfortunately, if a filter set to "disallow", it means to disallow everything that matches the filter. There's currently no way to say "Disallow users in group A, but only warn users in group B", except to create two copies of the filter with different settings, and then remember to modify both copies every time you need to tweak the regex. Suffusion of Yellow (talk) 21:57, 22 October 2019 (UTC)

Other filters fixed

I made (roughly) the same change to 51 (hist · log), 425 (hist · log), 527 (hist · log), 579 (hist · log), 874 (hist · log), 887 (hist · log), and998 (hist · log). Should all be fixed now. I also disabled one check at 102 (hist · log); see the notes for my reasoning. If anyone wants to revert my removal there, no problem, but if you expect that line to do anything, you'll need to use similar logic to the other filters. Suffusion of Yellow (talk) 02:41, 22 October 2019 (UTC)

Filter 380 exception for "Ass'n" as abbreviation of Association

Could there be an exception added to Filter 380 regarding the usage of Ass'n as an abbreviation for Association? (See Wikipedia:Edit_filter/False_positives/Reports#50.53.21.2) EggRoll97 ^(talk) 20:25, 5 October 2019 (UTC)

(Handy link: Wikipedia:Edit_filter/False_positives/Archive 107#50.53.21.2). @EggRoll97: Well, I couldn't find any hits, vandalism or good faith, for "ass'n" in the last 1000 hits (going back to Oct 16) for 380 (hist · log). But, there are 444 uses of "ass'n" in article space. Anyway,

Done, since it doesn't complicate the regex all that much, and we know of at least one FP. Suffusion of Yellow (talk) 22:05, 24 October 2019 (UTC)

Filter 384 (Addition of bad words or other vandalism) false positives

We currently have a long standing problem of many false positives coming from filter 384 (Addition of bad words or other vandalism), mostly in song names. To combat this I suggest adding

!(added_lines rlike "\[\[[^\]]{0,10}"+bad_word+"[^\[]{0,10}\]\]")

to check if it's inside a wikilink. If some edit filter manager could add this to the test filter (filter 1 ) that would be appreciated. I will monitor it to see if it works like I expect it to. --Trialpears (talk) 18:50, 5 October 2019 (UTC)

@Trialpears: That should be !(added_lines irlike ("\[\[[^\]]{0,10}(?:"+bad_word+")[^\[]{0,10}\]\]")) Note extra parentheses :-). Tried it against a dump of the last 1000 hits, and it looks like these 36 hits would have been excluded by the changes. I see a few FPs in there, but it's still mostly vandalism. Suffusion of Yellow (talk) 20:52, 20 October 2019 (UTC)

Suffusion of Yellow, sorry for late reply. I think this may be further improved by only having this exception for pages with {{infobox musical artist}}, {{infobox album}} and {{infobox song}}, which are the most affected by far. --Trialpears (talk) 20:50, 31 October 2019 (UTC)

@Trialpears: Special:Permalink/924107599. Batch one is 5000 hits from back in December. Batch two is the same 1000 hits as above. Batch three is the most recent hits. A few FPs in there, but still not much constructive editing IMO. People have some strong opinions about music, it would seem... Suffusion of Yellow (talk) 21:20, 1 November 2019 (UTC)

Suffusion of Yellow, I would say this was a fine trade off since a false positive is so much more damaging than a true negative, except for those real bad BLP violations. Now I think it may be best just to keep the status quo anyway. Was worth a try at least. Thanks for the help testing it! ‑‑Trialpears (talk) 10:19, 2 November 2019 (UTC)

Unprivate edit filter 31 (ASCII art)

Should edit filter 31 (ASCII art) be public? I don't see any reason why an ASCII art filter should be private, but could be wrong since I can't actually see the filter and don't know the history behind it. --Trialpears (talk) 09:16, 7 October 2019 (UTC)

The filter does contain some elements of long term abuse, but these are probably not so relevant these days (and could be filtered in other ways). A lot of entries are just memes which have had their day, and people won't be looking to circumvent. I think I'm in favour of making it public, but would want to hear from others. -- zzuuzz ^(talk) 10:48, 7 October 2019 (UTC)

@Zzuuzz: I think it shouldn't be public, given the exceptions on line 60 --DannyS712 (talk) 17:56, 7 October 2019 (UTC)

OK, noted, so I won't rush into anything before hearing more opinions. But if I understand your objection correctly, you are saying that a determined vandal could fiendishly devise some ASCII art which evades the filter? I refer to my original comments and would probably disagree with your objection. -- zzuuzz ^(talk) 18:58, 7 October 2019 (UTC)

I think it can be made public. Most ASCII-spamming vandals aren't going to bother trying to evade the edit filter. Reaper Eternal (talk) 19:32, 7 October 2019 (UTC)

I'd also support making it public. There's a mention in the notes about "spambots" circa 2014-2015, and a something about a "serial vandal" from a few years earlier, but skimming the recent hits, it all looks like ordinary childish vandalism. Suffusion of Yellow (talk) 22:23, 24 October 2019 (UTC)

And I realized that NawlinWiki is active again. Welcome back! Your thoughts? Suffusion of Yellow (talk) 22:25, 24 October 2019 (UTC)

I take the silence as tacit assent. Just checking @Suffusion of Yellow:, any further thoughts before the switch is flipped? -- zzuuzz ^(talk) 00:22, 3 November 2019 (UTC)

@Zzuuzz:. No.

Done. Suffusion of Yellow (talk) 19:35, 4 November 2019 (UTC)

Special:AbuseFilter/891 (ResearchGate)

Someone added ResearchGate doi's to the edit filter. That's rather overkill to lump those in the 'predatory journal' edit filter, especially without explanation.

If those are warranted in an edit filter, the warning it throws should at least warn that papers with ResearchGate dois are possibly (likely?) not peer-reviewed and might not be suitable as a reference. Headbomb {t · c · p · b} 19:50, 31 August 2019 (UTC)

Or rather, it should be split into a new filter, for "potential unreliable sources" with a priority lowered to "tag", rather than warn. Headbomb {t · c · p · b} 15:24, 1 September 2019 (UTC)

@Crow:, could you remove 10.13140 from this one. It's already in Special:AbuseFilter/1003. Likewise for removing frontiers\.in which pretty much does nothing since there's no such website. Also acacdemicjournals should be academicjournals. Headbomb {t · c · p · b} 21:50, 9 September 2019 (UTC)

De-archived as unresolved. Headbomb {t · c · p · b} 19:03, 7 October 2019 (UTC)

Specifically

Remove 10.13140 since RG isn't predatory, and should be/is handled by Special:AbuseFilter/1003 instead
Done Guy (help!) 11:43, 16 October 2019 (UTC)
Remove frontiers\.in since that's not a domain in use for anything, and the likely intended target Frontiers Media is way too borderline to be covered by such a filter.

Done#Fix acacdemicjournals to academicjournals

Headbomb {t · c · p · b} 19:13, 7 October 2019 (UTC)

@Xaosflux: could you take a look at this, since Crow seems to be on a break? Headbomb {t · c · p · b} 04:55, 16 October 2019 (UTC)

3 done. — xaosflux ^Talk 11:08, 16 October 2019 (UTC)
Ping to @JzG: regarding other changes. — xaosflux ^Talk 11:09, 16 October 2019 (UTC)

Frontiers has been fixed to the correct domain, but that is still an abuse of the edit filter, which should be restricted to clearly predatory publishers, not borderline cases. Headbomb {t · c · p · b} 21:17, 18 October 2019 (UTC)

@JzG: FWIW, frontiers.in is now responsible for 67 of the last 100 hits. I have no opinion about the removal of this from the filter, but it needs to mentioned in Mediawiki:Abusefilter-warning-predatory, along with scirp.org and academicjournals if it's going to stay. Right now only lists biomedres.info, cennser.org, and cpinet.info, which must be confusing to users. Suffusion of Yellow (talk) 19:54, 4 November 2019 (UTC)

@JzG: And now we are both calling it frontiers.in for some reason... See my edit request at Mediawiki talk:Abusefilter-warning-predatory. Suffusion of Yellow (talk) 20:46, 4 November 2019 (UTC)

Suffusion of Yellow, reviewing those edits was... illuminating. Some non-MEDRS, quite a bit of self-promotion Guy (help!) 21:06, 4 November 2019 (UTC)

Headbomb, In your opinion. It was added because of the reputation of Frontiers for substandard material, and because most additions are non-RS additions to medical articles. Guy (help!) 21:07, 4 November 2019 (UTC)

There are many substandard sources used, but the filter for predatory journals should be restricted to predatory sources. Frontiers maybe be crap-ish, and not WP:MEDRS, but medicine does not rule all of Wikipedia. Headbomb {t · c · p · b} 21:35, 4 November 2019 (UTC)

A bug in Special:AbuseFilter/627

Integer division in the filter language does not truncate any remainder. Therefore, (article_namespace / 2 = 59) will only match when article_namespace is 118 and not 119, which is not what the filter is intended to work (according to the notes of the filter). There are multiple ways to fix this bug. Change it to (page_namespace === 118) | (page_namespace === 119) is one possibility. --Nullzero (talk) 23:58, 6 November 2019 (UTC)

Thanks, Nullzero! Filter fixed. (Courtesy ping MER-C). FYI, there's now an equals_to_any() function, which saves conditions over multiple ===s. Suffusion of Yellow (talk) 02:21, 8 November 2019 (UTC)

Tags cleanup

Is there any reason why the ~~removal of COI template~~, ~~large plot addition~~, ~~disambiguation template removed~~, ~~possible birth date change~~, ~~missing file added~~, ~~predatory~~ and ~~deprecated source~~ tags are activated for manual addition to edits? Seems they should only be applied by filters. Not a big deal but it does add clutter to API help pages (eg [5]). Any objection if I deactivate these? Suffusion of Yellow (talk) 23:19, 4 November 2019 (UTC)

@Suffusion of Yellow: some of these were recently added, see this log, I'd check with the creators first. — xaosflux ^Talk 16:17, 5 November 2019 (UTC)

@Galobtter, JzG, Premeditated Chaos, and Zzuuzz: Any reason for these to be manually applied? Special:Tags doesn't make it very clear, but when you save a filter with a non-existent tag, it seems to be created automatically. At least, I never touched anything at Special:Tags and yesterday and yet this works. Suffusion of Yellow (talk) 21:10, 5 November 2019 (UTC)

I can speak for the removal of COI template tag. It was not my intention that it be manually applied. The reason it is so, and remains so, is the lack of documentation. I seem to recall failing to fix it for whatever reason, but have at it. -- zzuuzz ^(talk) 21:23, 5 November 2019 (UTC)

The deactivate button worked for me. The filter is still applying the tag. So perhaps MediaWiki:Tags-create-explanation should make it clear that the form is only for manually applied tags. Suffusion of Yellow (talk) 21:54, 5 November 2019 (UTC)

Suffusion of Yellow, feel to deactivate any of those tags created by me. I did not know that the tags would be automatically created and created the tags while creating their descriptions etc. Galobtter (pingó mió) 02:51, 6 November 2019 (UTC)

Suffusion of Yellow, I have no idea how I created that tag except that it's probably a screwup related to me trying to figure out the tag on this edit. Feel free to delete it or deactivate it or whatever is done with tags. ♠PMC♠ (talk) 06:57, 6 November 2019 (UTC)

Thanks. Deactived Galob's and PMC's tags. Also deactivated deprecated source (@JzG: not a problem, yes?). predatory can probably be deleted also (admin needed) as it's not used by any filter. @MusikAnimal: just noticed one of those is yours. large plot addition is only for use by the filter, correct? Suffusion of Yellow (talk) 02:59, 8 November 2019 (UTC)

I didn't realize I could delete tags, for some reason I figured an interface admin was required. I've deleted my screwup :) ♠PMC♠ (talk) 06:31, 8 November 2019 (UTC)

Suffusion of Yellow, predatory was designed for assignment to 891. It's probably not needed as tag-watchers probably won't understand the issues, so it can go. Deprectaed only needs to be added by filters. Guy (help!) 11:08, 8 November 2019 (UTC)

@JzG: 891 uses Citing predatory open access journal. See [6]. The predatory tag had only ever been applied to one edit, IIRC. Suffusion of Yellow (talk) 03:45, 9 November 2019 (UTC)

Oh, then it's probably left over form me being an idiot. Please feel free to nbuke it! Guy (help!) 10:15, 9 November 2019 (UTC)

@Suffusion of Yellow: I guess I didn't know we had control over whether tags could be manually added or just via a filter! Yes, in this case it should be filter-only. Thanks — MusikAnimal ^talk 17:58, 8 November 2019 (UTC)

Thanks, done. Suffusion of Yellow (talk) 03:48, 9 November 2019 (UTC)

Urgent

[7] E Eng 19:32, 9 November 2019 (UTC)

Per ANI and recent suppressions, I think Special:AbuseFilter/1008 would be prudent at this point. What do people think? Guy (help!) 19:58, 9 November 2019 (UTC)

I assume the filter is active while you're waiting for comment. Also, a question: does this filter also catch an attempt to create an article whose title is this string (or variations)? E Eng 20:42, 9 November 2019 (UTC)

@JzG: I've changed the name - I hope the reasons are obvious, and feel free to pick something better. I've also enabled the filter, but temporarily lifted the disallow, as a testing phase. I have one main observation: such a filter takes things out of the world of suppression and into the realm of admins, EFMs, and EFHs. -- zzuuzz ^(talk) 21:06, 9 November 2019 (UTC)

Yup. A wider group. Guy (help!) 21:58, 9 November 2019 (UTC)

Perhaps an unorthodox use of that checkbox, but given that it is apparently a privacy/BLP-sensitive thing, would it make sense to hide it from public view so that the filter log does not spill the information we want to keep off the wiki? Jo-Jo Eumerus (talk) 22:03, 9 November 2019 (UTC)

It is hidden, and thus the logs are hidden. I did accidentally make it public for a short time but soon fixed that. There are three separate hits so far, all suppressed, so I think it's probably good to go as an urgent filter. It might actually reduce the size of the group, because now only certain privileged editors will see attempts to add the content. Hope you can monitor it somewhat Guy(s)? -- zzuuzz ^(talk) 22:05, 9 November 2019 (UTC)

I can't see who has been oversighting all the log entries, but now that the filter is disallowing, is that really necessary? The "secret" information is right there in the filter pattern, so nothing new is learned from the hits, except which article I should add to my watchlist, in case people start evading the filter. Yes, if there's something about the username or target page that gives it away, that would be different, but so far from what I've seen that hasn't been the case. Suffusion of Yellow (talk) 20:00, 10 November 2019 (UTC)

@Suffusion of Yellow: the filter log also contain the entire edit that was attempting to be made, so it has more then just the match word. The OS team is aggressively working on this issue across the project. — xaosflux ^Talk 21:45, 10 November 2019 (UTC)

@Xaosflux: Alright I guess. So, Special:AbuseLog/25297666 is not oversightable, then? It only contains the match word. Suffusion of Yellow (talk) 22:02, 10 November 2019 (UTC)

@Xaosflux: Just commenting generally from experience with oversight filters, when the filter maintainers can't see the filter hits and misses, we kind of rely on the OS crew to either take it easy, take responsibility for catching all the filter misses, and/or help to maintain the filter themselves. Unfortunately there doesn't seem to be a great crossover between EFM and OS, so hopefully you can be conscious of this gap and fiddle where necessary. -- zzuuzz ^(talk) 22:40, 10 November 2019 (UTC)

I'll try to watch as well, and I've looked through the old hits. No FP's so far, there have been between 10 to 20 total hits. Some are just the addition of the filter catch, some also included additional content. — xaosflux ^Talk 23:20, 10 November 2019 (UTC)

And just because it hasn't been suppressed as of now, doesn't mean it is appropriate or won't be suppressed still. — xaosflux ^Talk 23:21, 10 November 2019 (UTC)

I assume we'll get to see any false positives, so that's not the issue. The filter misses are the real blind spot; EFMs can normally get this info from the editors or the articles in order to improve the filter, and now it gets completely removed. An example. So thanks to you and ST47 for helping tweak the filter where appropriate. -- zzuuzz ^(talk) 23:34, 10 November 2019 (UTC)

New permutations to add: [8], [9] (both suppressed) DannyS712 (talk) 03:37, 13 November 2019 (UTC)

Edit Filter Helper request (User:Creffett)

Not done Sufficient support for this access has not emerged. Creffett you are welcome to assist in places such as WP:EF/FP relating to public filters, if you become active in that area a future request may have more support. — xaosflux ^Talk 14:18, 30 November 2019 (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.

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

(this request is for adding the permission to User:Creffett, but I'm not on my personal machine right now so it's being posted under the creffpublic sock)

Hi all, I'd like to request the edit filter helper bit. I've helping off-and-on for a while on the false positive and requests boards, so I'm hoping people at least feel like they've heard my name before. The main reason I'm requesting the bit is that a large portion of my work on Wikipedia is catching promotional/COI edits and spam, and the most of the filters in that area are private. I'd like to be able to see and suggest changes to the relevant filters (particularly 354, 499, and 627) in order to improve their catch rate. I'm reasonably handy with regular expressions (as mentioned on my userpage, my day job is software engineering) and I meet all of the other criteria for EFH (extended confirmed, native English speaker, no blocks/sanctions, and solid understanding of security practices). ^creffpublic _{a creffett franchise} (talk to the boss) 19:37, 22 November 2019 (UTC)

My usual concern, to wit: While EFFP participation is always appreciated, I don't see that typically rising to the level of Demonstrated Need that was expected when the EFH role was being vetted, along with the highly-established user expectation; you've not been here 9 months despite your extremely impressive level of editing. This is not opposition per se, just expressing concerns based around what was generally agreed during the RFC for the EFH bit. Crow^Caw 18:05, 25 November 2019 (UTC)
Crow, all reasonable points, and I can't disagree with them. The only thing I will say is that since most of the filters that tip me are private, it's pretty hard to call out false positives (and I suspect that the response to many of them will be "there was a phrase in there that shows up in a lot of spam pages and it's effective enough that it's not worth changing). If I had the bit, that's the main place where I expect to use it (well, that and suggesting additions). If that doesn't meet the "demonstrated need" threshold, then that's that. ^creffpublic _{a creffett franchise} (talk to the boss) 18:48, 25 November 2019 (UTC)
Weak support. On the one hand, there hasn't been a huge level of participation at the relevant EF-related pages. On the other, said participation has been quite clueful, and I don't pick up a hat-collecting vibe. I think Wikipedia will have less spam, if creffett has access to anti-spam filters and /test. My main concern relates to Crow's: Are we setting a precedent that leads to 500 EFHs at some point in the future? Suffusion of Yellow (talk) 17:53, 27 November 2019 (UTC)
Suffusion of Yellow, just out of curiosity what is the underlying concern about having too many EFHs? Is it that some EFH will conspire with sock puppets to bypass filters targeting them or grave incompetence where a private filter is posted publicly? If that's the case I wouldn't have any concern about granting it to many experienced non-admins in good standing even if their need isn't particularly pressing. ‑‑Trialpears (talk) 18:22, 27 November 2019 (UTC)
@Trialpears: No one has perfect account security. There's probably a weak point in any group of 500 users, even responsible users. If you're gong to say "but we already have 1000 admins" I urge you to check out the history of the main page, or my block log. Suffusion of Yellow (talk) 18:28, 27 November 2019 (UTC)
Suffusion of Yellow, yep that's it of course. I'm still wondering if putting a 2FA condition on weaker applicants and a quick removal time for users not actively doing edit filter related activities could make this bit significantly less high risk, but I guess we don't really have a lack of EFHs either so there's no pressing need. ‑‑Trialpears (talk) 18:41, 27 November 2019 (UTC)
For what it's worth, I've requested the 2fa right (the security person in me is very curious why that has to be specifically requested, but that's neither here nor there). One suggestion - if your concern is "bad people" (spammers, LTAs, etc.) getting access, then you might want to talk to the New Page Patrol project - they've had a couple issues lately with deep-cover paid editors/spammers getting the right and abusing it, so there might be some value in a joint discussion about how to protect these abuseable advanced rights. creffett (talk) 22:38, 27 November 2019 (UTC)
The more I think about the issue the higher risk I think this user right is. Only one bad or compromised actor could permanently reveal the contents of all private filters in a minute. Pherhaps some larger discussion would be beneficial but first of all I think the easier options should be implemented, in particular giving edit filter helpers 2FA access and moving the power to grant EFH and EFM to the crats reducing the amount of accounts that could be compromised by a factor of five. Having some more stringent activity requirements similar to how admins can request their bit back without a RfA, could probably reduce it a lot further as well. That being said adding a few more active EFHs in good standing, especially with solid security practices like you, wouldn't do much to increase the risk so I would be all for you being granted at least a trial. ‑‑Trialpears (talk) 23:25, 27 November 2019 (UTC)

@Creffett: 2fa is in a limited trial because there is not a good support system in place for anyone who runs in to problems with it. — xaosflux ^Talk 23:47, 27 November 2019 (UTC)
Xaosflux, good to know, thanks. creffett (talk) 23:57, 27 November 2019 (UTC)

Note on EFM/EFH's - occasionally we need a filter for something that will also end up getting oversighted, in between the filter hit and the log suppression there is a window for disclosure - so EFH's need a level of general community secrecy trust. — xaosflux ^Talk 19:26, 27 November 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Edit Filter Helper request (User:Headbomb)

Closed as

Request withdrawn. — xaosflux ^Talk 00:14, 2 December 2019 (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.

Headbomb (talk · contribs · count · logs · page moves · block log)

Y Demonstrated need for access – Mostly interested in dealing with Special:AbuseFilter/891 I've made several requests in the past few months.
Y No recent blocks or relevant sanctions – Clean block log/restrictions/sanctions in 13+ years / ~300,000 edits
Y At least basic understanding of account security – Secure enough password
Y At least basic understanding of regular expressions if the intent is to assist with authoring filters – Plenty familiar with regex, operator of a couple of regex-based bots, member of WP:BAG.
Y Sufficient ability with the English language to understand notes and explanations for edit filters – I English good!

Must also meet at least one of these criteria:

Y Currently-active extended confirmed editor on the English Wikipedia (i.e. has made edits or logged actions within the last 12 months)
N Current administrator on another WMF project
N Current edit filter manager on another WMF project
N Current WMF developer or staff member who needs access for WMF-related purposes

Headbomb {t · c · p · b} 10:28, 1 December 2019 (UTC)

Support. --Dirk Beetstra ^{T C} 10:47, 1 December 2019 (UTC)
Support. Valid need, lot of experience. – Ammarpad (talk) 16:03, 1 December 2019 (UTC)
Support. Multiple clueful suggestions for filter edits, this will allow Headbomb to improve the project without relying on laggards like me. Guy (help!) 16:13, 1 December 2019 (UTC)
Question: 891 isn't private, and EFH rights only grant the right to view private filters (not edit filters) - why do you believe that these rights would be useful? --DannyS712 (talk) 22:18, 1 December 2019 (UTC)

@DannyS712: I don't know, @JzG: told me it would be useful for me to have them. If it doesn't let me edit filters, then it's pointless. Unless he meant WP:EFM and not WP:EFH, in which case, that's the thing I'd want. Headbomb {t · c · p · b} 23:23, 1 December 2019 (UTC)

Oh, potentially I am an idiot. Bah! Sorry, sir. You're right, I thought they unbundled that. Y U NO ADMIN, anyway? Guy (help!) 23:27, 1 December 2019 (UTC)

Mostly because I get pissed when admins abuse their positions as a way to win arguments. Headbomb {t · c · p · b} 23:33, 1 December 2019 (UTC)

@Headbomb: so do you want to apply for EFM and stop this request? Note, the assignment of the edit filter manager user right to non-admins is highly restricted and is a standard 7-day discussion. — xaosflux ^Talk 23:57, 1 December 2019 (UTC)

@Xaosflux: yup. Do you just update the counter and ping the previous ~voters, or do you want me to make another distinct request? Headbomb {t · c · p · b} 00:04, 2 December 2019 (UTC)

Xaosflux, I sincerely hope we can grant this right. I cannot think of anyone more suited to it. Guy (help!) 00:11, 2 December 2019 (UTC)

@Headbomb: OK lets just close this and you can start a new discussion. Please read through all of WP:EFM first to ensure you have a good understanding of the access you are requesting. There isn't a guidelines "checklist" so much for that one, as it is rare (<10 non-admin EMF's). — xaosflux ^Talk 00:13, 2 December 2019 (UTC)

@JzG: certainly possible - there is some precedent for non-admin EFM's. — xaosflux ^Talk 00:13, 2 December 2019 (UTC)

My error

I apologise to everyone. I wanted to propose Headbomb for EFM, not EFH. As far as I can tell this is unbundled and can be granted, and I think he'd be a stalwart asset to the (way too small) filter posse. Guy (help!) 00:03, 2 December 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Filter cleanup

Can an EFM please take a look at the following enabled filters?

Filters to clean up

Use deprecated variables, and should be updated:

Done

Use a regex where they should use equals_to_any():

Done

Other miscellaneous issues:

Special:AbuseFilter/499 - line 3 (filter is private) Done
Special:AbuseFilter/806 - line 2 (filter is private) Done
Special:AbuseFilter/856 - line 1 should use equals_to_any() Done
Special:AbuseFilter/930 - line 2 should use !("extendedconfirmed" in user_rights) & Done
Special:AbuseFilter/942 - ("sysop" in page_restrictions_edit) is least likely to be true, and so should go first Done
Special:AbuseFilter/1002 - line 1, and line 2 (filter is private) Done
Special:AbuseFilter/867 - line 1 should use !("extendedconfirmed" in user_rights) & Done
Special:AbuseFilter/915 - line 12 & 14

Discussion

Thanks, --DannyS712 (talk) 06:26, 12 November 2019 (UTC)

The latter list has been done, and I'm currently working through the first list. I've always thought deprecated variables are a good sign, and excuse, for the filter to get a proper review, so I'm trying to do that. Speaking of which can I get an opinion on lines 7-8 of filter 117? -- zzuuzz ^(talk) 10:30, 12 November 2019 (UTC)

That's all done except filter 117. It looks to me like there might be too many double negatives on lines 7 and 8, but it's making my head hurt. Thoughts or testing anyone? -- zzuuzz ^(talk) 19:04, 12 November 2019 (UTC)

@Zzuuzz: That is confusing. Let's see, right now it's saying that:

(NOT (added_lines rlike stringy AND NOT (added_lines contains '#redirect')))

which means

((NOT added_lines rlike stringy) OR (added_lines contains '#redirect'))

So was the original intention to flag redirects, or skip redirects? Go ahead. Say "yes". Using <plug type="shameless">User:Suffusion of Yellow/batchtest-plus.js</plug>, I can only find one recent example containing "#redirect", Special:AbuseLog/25145575, and that was a random test edit, so I guess it's not very common for non-confirmed editors to redirect very very short BLPs? Suffusion of Yellow (talk) 20:00, 12 November 2019 (UTC)

Having stared at the filter for a long time, too long really, I've reached the conclusion that at least it's not doing any harm. So I'll leave it there for others to wonder about at a later date. -- zzuuzz ^(talk) 20:08, 13 November 2019 (UTC)

Thanks. I've added a few more things that can be cleaned up - for the private filters, I've just noted the lines that can be improved / cleaned up; hopefully the implied edit is obvious, but to avoid sharing private details I didn't want to post it. Thanks, --DannyS712 (talk) 11:07, 12 November 2019 (UTC)

Regarding filter 942, I'd agree that editing a protected page is less likely than being a sysop and so should go first. But on that topic I'd be interested to hear from Xaosflux: Isn't a check for the sysop user_group redundant to those other checks? -- zzuuzz ^(talk) 12:52, 12 November 2019 (UTC)

@Zzuuzz: It took me a while to track it down, because I couldn't remember where I came across it, but the answer is that the check is still useful: see m:Stewards' noticeboard/Archives/2019-08#Notice of mistaken edit - it shouldn't add much to the checks, given how rarely that condition would be reached, and would help prevent false positives like the one linked above --DannyS712 (talk) 13:40, 12 November 2019 (UTC)

942 so not exactly redundant, this was birthed from the continuing discussions regarding possible admin activity standards changes, and a way to gather the metrics. At once point I though the group check was "cheaper" then the other one as far as the ordering goes - if it is faster in another order that part isn't important to the goal. — xaosflux ^Talk 13:57, 12 November 2019 (UTC)

That's fine, I can see the point of the filter. I was just wondering about testing for being a sysop and editing a protected page, but DannyS712's cleared that up - though in the context of this filter I still think the group check might be redundant, I'm happy to leave it there (but will re-order the conditions). -- zzuuzz ^(talk) 14:19, 12 November 2019 (UTC)

So, is misuse of global rights to edit protected pages not suspicious enough to warrant an edit filter hit? * Pppery * _{it has begun...} 22:37, 13 November 2019 (UTC)

Honestly? I don't think logging such a thing, alongside thousands of sysop edits, would serve any useful purpose. -- zzuuzz ^(talk) 22:46, 13 November 2019 (UTC)

Added 2 more (ping @Cyberpower678 for 915) Thanks, --DannyS712 (talk) 01:38, 13 November 2019 (UTC)

DannyS712, The filter looks fine to me. It would help to know what needs cleaning up. —CYBERPOWER (Chat) 14:15, 16 November 2019 (UTC)

@Cyberpower678: Since the filter is private, I didn't want to give anything away here. I've emailed you. Thanks, --DannyS712 (talk) 01:33, 17 November 2019 (UTC)

DannyS712, tesponded —CYBERPOWER (Around) 02:00, 17 November 2019 (UTC)

Request for edit filter helper (User:InvalidOS)

Not done this request failed to gain support. — xaosflux ^Talk 19:07, 25 November 2019 (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.

The event has started. (refresh)

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

Since I mostly work on reverting vandalism, where edit filters are helpful, I would like to be able to help out with tasks involving edit filters. Invalid^OS (talk) 17:36, 14 November 2019 (UTC)

There is a standard 3 day hold on these requests for commentary. — xaosflux ^Talk 18:10, 14 November 2019 (UTC)

The general requirement documented at WP:EFH is a "demonstrated need for access". I'm not really convinced that reverting vandalism demonstrates such a need. It is quite possible (and welcome) to help with edit filter tasks without needing the ability to view private filters. -- zzuuzz ^(talk) 22:11, 14 November 2019 (UTC)
I'm not willing to support this right now, though I look forward to doing so in the future. I'd like to see more involvement with public filters first. There's nothing wrong with anything you've done so far; I just haven't seen enough of it, yet. Suffusion of Yellow (talk) 22:42, 16 November 2019 (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.

New editor suspicious activity on bot

Tracked in Phabricator
Task T238270
Invalid

Special:AbuseFilter/806

Hello all, I'm seeing that InceptionBot (talk · contribs · tasks · flag log · actions log · block log · other logs · count) has been tripping the "new account suspicious activity" filter for the few hours or so. It does not look this is a new bot as well according to Wikipedia:Bots/Requests for approval/InceptionBot. Would it be possible for an EFM to look into this? Also pinging the bot operator Bamyers99. -- LuK3 (Talk) 19:49, 13 November 2019 (UTC)

@LuK3: Seems like a bug in the AbuseFilter extension. The extendedconfirmed user right (which is held by EC users, bots, and sysops) isn't being exposed to the filter. Fixed 806 (hist · log), but some others will need fixing, too. @Xaosflux: You mentioned something similar in the notes for 867 (hist · log). Know what's going on here? Suffusion of Yellow (talk) 20:09, 13 November 2019 (UTC)

Couldn't this be solved by giving bots the extended confirmed right explicitly along with the bot flag? ‑‑Trialpears (talk) 20:13, 13 November 2019 (UTC)

@Trialpears: No, I just found an example of an actual extendedconfirmed user who does NOT have extendedconfirmed rights, according to the filter log (Special:AbuseFilter/examine/log/25328598, private, but someone may wish to dig up a public example.) Suffusion of Yellow (talk) 20:19, 13 November 2019 (UTC)

@Suffusion of Yellow: If you use the testing interface with contains_any(user_rights, "bot", "extendedconfirmed"), it does indeed detect things.... DannyS712 (talk) 20:14, 13 November 2019 (UTC)

@DannyS712: Are you using Special:AbuseFilter/test, or examining an actual saved log entry? /test sometimes only has a tenuous connection with what the filter actually sees. Suffusion of Yellow (talk) 20:19, 13 November 2019 (UTC)

@DannyS712: looking at this examine result - looks like at least on that hit a LOT of 'user_rights' are not being evaluated. — xaosflux ^Talk 20:21, 13 November 2019 (UTC)

@Suffusion of Yellow: Special:AbuseLog/25329506 accurately detected extended confirmed; Xaosflux - has anyone filed a phab task yet? DannyS712 (talk) 20:23, 13 November 2019 (UTC)

@LuK3 and Suffusion of Yellow: that bot hadn't been flagged when those were tripping, it has now been flagged so should no longer be causing the trouble, please let us know if you see more issues. — xaosflux ^Talk 20:13, 13 November 2019 (UTC)

Scratch that, reviewing more. — xaosflux ^Talk 20:14, 13 November 2019 (UTC)

@Suffusion of Yellow and Zzuuzz: - seems like you have both been updating 806 in the last day - can you look over for any breaking changes on this, and if there is a new bug revert back and see if it resolves the issue? — xaosflux ^Talk 20:20, 13 November 2019 (UTC)
@Xaosflux: My change was just a revert of Zzuuzz's, in response to this thread. Suffusion of Yellow (talk) 20:21, 13 November 2019 (UTC)
@JJMC89: looks like you are in the mix as well. — xaosflux ^Talk 20:23, 13 November 2019 (UTC)
I have a hunch. @Xaosflux:, can you please assign temporary EC rights to User:Suffusion of Yellow alt 5? Suffusion of Yellow (talk) 20:26, 13 November 2019 (UTC)
@Suffusion of Yellow: done. — xaosflux ^Talk 20:27, 13 November 2019 (UTC)

@Suffusion of Yellow: Can someone set filter 1 to be:

"extendedconfirmed" in user_groups &!
"extendedconfirmed" in user_rights

to log these? The test interface doesn't show any hits, but at run time the filter may act different DannyS712 (talk) 20:28, 13 November 2019 (UTC)
- @DannyS712 and Suffusion of Yellow: I don't want to slam a crazy filter on here, I've made you both temporary admins on testwiki if you would like to try there? Please limit your testwiki admining to these tests and clean up after yourselves. — xaosflux ^Talk 20:31, 13 November 2019 (UTC)
  - @Xaosflux: I had already created Danny's requested filter. But, my hunch, that this bug only affected user with manually-assigned rights, was wrong anyway. I've got no more ideas, right now. Suffusion of Yellow (talk) 20:38, 13 November 2019 (UTC)
    - @DannyS712 and Xaosflux: And testwiki won't work after all. There is no extendedconfirmed right or group on testwiki... Suffusion of Yellow (talk) 20:47, 13 November 2019 (UTC)

I've made sure the changes I recently made are undone (documented in the section above). But this isn't the full picture: this search shows the current use of user_rights. I seem to recall this coming up before. -- zzuuzz ^(talk) 20:40, 13 November 2019 (UTC)

Special:AbuseFilter/history/806/diff/prev/22612 is the change that caused this. I think this is working as intended. Edits made where authentication is done with BotPasswords or OAuth limit the set of rights available to the user in that session. — JJMC89 (T·C) 22:21, 13 November 2019 (UTC)

@JJMC89: thank you for the update - so using 'groups' instead of 'rights' should be fine here. — xaosflux ^Talk 22:36, 13 November 2019 (UTC)

@Xaosflux: I don't know if one is "cheaper" to use than the other, but we need to test groups instead of rights here. In in most cases (if API edits will be tested, which most of the time they would) where the right is not in the basic grant, we need to test groups. — JJMC89 (T·C) 22:56, 13 November 2019 (UTC)

Bot idea for EFFP

What do you all think of a bot that would automatically tag private filters and blocked users in EFFP reports? For me this seems like a great ~~excuse~~ reason to create a bot of my own (I've been wanting to do that for a long time). --Majavah ^(t/c) 15:54, 5 November 2019 (UTC)

@Majavah: There's no such thing as a bad excuse to write code. :-) That said, I'm not sure how useful that would be if that's all the bot does. But if you are in a coding mood, I can think of other possibilities, such as:

Fill in the "page you were editing" field if the user left it blank.
List which filters the user tripped recently, and how many times.
Link to past (archived) reports from the same page or user.
An opt-in system, where EFMs are pinged about FP reports regarding selected filters.
...any other ideas, people?

Still, if you want to write a bot that does only what you suggested, I'd have no objection. Suffusion of Yellow (talk) 02:35, 8 November 2019 (UTC)

A better archiving solution would be great. Currently a not insignificant smount of reports get archived prematurely and a bot looking for a done template may help solving this. ‑‑Trialpears (talk) 07:20, 8 November 2019 (UTC)

I've started working on the bot. At it's current state, the bot can add the page name if left blank and add the private notification message if filter is private. About the archiving, should it just move all requests with fixed, done, not done, declined or blocked to an archive, or should it have more complex logic? --Majavah ^(t/c) 15:29, 8 November 2019 (UTC)

Pinging @Suffusion of Yellow and Trialpears for opinions for the archival system. --Majavah ^(t/c) 19:14, 11 November 2019 (UTC)

@Majavah: Sorry for the late response. Just thinking out loud here, not saying this is best:

I'd say {{effp}} first should be expanded with a few more options, if we're going to tag everything for the bot. There will always be some edge cases not covered by the current options. Maybe just a generic "Done" and "Not done" that say nothing else?
Ideally, removal times should be user configurable for each type of response, so we don't have to bug you with endless requests to adjust times. I.E. {{effp|fixed}} responses are moved after $x$ hours, {{effp|question}} after $y$ hours, responses with no templates are moved after $z$ hours, where $x$ , $y$ , and $z$ are settable from some semi-protected page in the bot's userspace.
Should the bot remove reports marked only with {{effp|v}} (and no additional comments), per WP:DENY? IMO, yes. What do you think? Suffusion of Yellow (talk) 19:40, 11 November 2019 (UTC)
Fully agree with the above. I think vandalism should be removed as well, partly due to DENY but also simply because archiving them isn't particularly useful. I also think non tagged things should be archived as well, but after a significant amount of time (5 days maybe). ‑‑Trialpears (talk) 20:11, 11 November 2019 (UTC)

The technical implementation of the features seems to be working (except archival) and now there is a configuration page, however I'd like to get the templates adjusted before filing a BRFA.

About the archival, would a rolling archive like the one at WP:RPP suffice?
About {{effp}}:
- Do we really need separate "not done" and "declined"?
- Should there be a generic starting like "Automated comment" or should the bot use different template messages for each of its responses? Should the bot prefix {{effp|private}} and {{effp|blocked}} with the "automated comment" note?
- We also need a "closed" template.

Once those are decided I believe the bot is at a stage where I can file the BRFA and (hopefully) start the trial. Also pinging @Suffusion of Yellow and Trialpears so they notice this. Majavah ^(t/c) 17:38, 18 November 2019 (UTC)

@Majavah: I'm going to be away for a few days, but I was thinking that {{effp}} would be adjustable without modifying the bot (only the config page); would that be possible? Otherwise we might get locked in to something we don't like. Are you just saying you want something concrete for the BRFA folks? Suffusion of Yellow (talk) 18:37, 18 November 2019 (UTC)

And yes, I think "Automated comment" would be a good idea, so new users know not to respond to the bot or ask it questions. Suffusion of Yellow (talk) 18:38, 18 November 2019 (UTC)

@Suffusion of Yellow: My primary question is that should the messages be stored in the {{effp}} template or on the config page? --Majavah ^(t/c) 18:49, 18 November 2019 (UTC)

Off the top of my head, {{effp}} makes more sense. Something like {{effp|private|bot=1}} or {{effp|privatebot}} would produce the bot's variant of the message. Suffusion of Yellow (talk) 19:01, 18 November 2019 (UTC)

Agree with Yellow here. For the other questions I think separating not done and declined is appropriate since then we can archive declined vandalism faster and without archiving while letting good faith but inappropriate edits be archived normally when using the not done option. I also think generic closed option would be good just to alert the bot that it's archive time. ‑‑Trialpears (talk) 20:41, 18 November 2019 (UTC)

I've went ahead and added a few parameters to the sandbox page. Any objection or should I merge those to the main template? --Majavah ^(t/c) 15:14, 19 November 2019 (UTC)

@Majavah: So long as you've checked that you aren't breaking any existing uses of the template, I don't see a problem with any additions. It can always be tweaked later. Suffusion of Yellow (talk) 19:17, 21 November 2019 (UTC)

I've merged the changes to the mail template, however I haven't edited the documentation yet (only thing added is archive now). I've also filed the BRFA! --Majavah ^(t/c) 09:15, 23 November 2019 (UTC)

Set filter 1011 to disallow?

1011 (hist · log) (private)

@Zzuuzz: User is active right now, as you know. Ideally it should be tested more, but no FPs in almost a day. Suffusion of Yellow (talk) 00:37, 14 November 2019 (UTC)

Good for short-term issues, but maybe a bit too soon for general use? Or a bit strict? I can see this potentially tripping FPs a fair bit. -- zzuuzz ^(talk) 22:14, 14 November 2019 (UTC)

@Zzuuzz: Yes, there was one "false" positive, from a different, but still disruptive (maybe good faith CIR) user, here today. I expect it will have similar problems as disabled filter 931 (hist · log). If I set this to disallow, I will check the log a few times a day for FPs. I will also turn it back to log-only if the targeted user goes away. Maybe best to give it another day or two, though. In the meantime I think I'll add it to DatBot's list. Suffusion of Yellow (talk) 22:51, 14 November 2019 (UTC)

Still no FPs, except the pseudo-FP mentioned above (IP is now globally rangeblocked as an "infected network" FWIW). I've set it to disallow for now, but anyone may feel free return to log-only. I have a few ideas to reduce FPs, and will implement if needed. Suffusion of Yellow (talk) 02:58, 16 November 2019 (UTC)

Note that this was changed to disallow back on November 20 DannyS712 (talk) 04:30, 5 December 2019 (UTC)

Disable filter 527?

527 (hist · log) (private)

I sent something about this to the mailing list, but Galobtter suggested I come here. There's a specific problem (hard to describe without saying too much about a private filter) described here, that makes the log less meaningful than it would seem. In any case, does anyone find it useful? It's had about 1300 hits in last 24 hours! It was also broken for several months until this change, and no one complained. Suffusion of Yellow (talk) 15:59, 17 November 2019 (UTC)

In favor of disabling; that being said, any reason about restricting the mailing list from EFH ? ∯WBG^converse 16:37, 17 November 2019 (UTC)

@Winged Blades of Godric: Not sure, but see Special:AbuseFilter/history/527/diff/prev/22685 for now. Suffusion of Yellow (talk) 18:16, 17 November 2019 (UTC)

@Suffusion of Yellow: Maybe we should have a discussion about allowing EFH DannyS712 (talk) 08:31, 18 November 2019 (UTC)

I'm in favour of disabling. -- zzuuzz ^(talk) 18:07, 17 November 2019 (UTC)

Do I trigger an edit-filter by looking at an edit-filter page as a non EFH? ——SN 54129 18:13, 17 November 2019 (UTC)

@Serial Number 54129: no DannyS712 (talk) 20:18, 17 November 2019 (UTC)

No objections in ten days, so Done for now. Suffusion of Yellow (talk) 20:48, 27 November 2019 (UTC)

Open mailing list to edit filter helpers?

@DannyS712 and Winged Blades of Godric: suggested this above. My thoughts are that yes, it would have made perfect sense had the EFH group existed when the mailing list was created, but now, there might be problems with allowing a new user group access to the archives. Anyone who has already sent a message to the list did so in the expectation that any admin or EFM could read the message, but in theory they didn't consent to EFHs reading their emails. That said, I'm not sure that anyone would really care. We have 1150 admins, (most aren't subscribed, but they could), and only 21 EFHs. Maybe run this by WMF legal, just to be safe? Suffusion of Yellow (talk) 18:56, 18 November 2019 (UTC)

There's no legally private data being shared, just things we as EFMs consider private. I think the mailing itself is the best place to make your proposal, and if after some time there are no objections, we can open it up to EFHs. I don't expect any opposition. — MusikAnimal ^talk 20:52, 21 November 2019 (UTC)

I don't see any issue with anyone who can see private filters being allowed access to the list. Galobtter (pingó mió) 21:16, 21 November 2019 (UTC)

@Galobtter and MusikAnimal: Access to the list also gives you the email address of everyone (including non-subscribers) who has ever sent an email to the list. Suffusion of Yellow (talk) 21:19, 21 November 2019 (UTC)

Took a quick look at this and we similarly don't see anything legally private there. If people are concerned that EFH's might be getting access to something they weren't before, there's no obligation to let them onto list. But if everyone thinks it makes sense for them to be added, there's no legal barrier to it. -Jrogers (WMF) (talk) 21:24, 21 November 2019 (UTC)

Thanks for looking in to it! I sent a short email to the list, with a link back to this thread. Suffusion of Yellow (talk) 21:42, 21 November 2019 (UTC)

Fine by me - the primary security concern was about the contents of private filters, which EFHs have access to. Sam Walton (talk) 09:35, 22 November 2019 (UTC)

If some other legal barrier comes up, a separate mailing list could be created for EFHs. I don't think it's likely that there would be another legal barrier, though. Invalid^OS (talk) 14:52, 22 November 2019 (UTC)

I was actually first added to the list when I was EFH, so it wasn't a problem then. Best, Kevin (aka L235 · t · c) 05:16, 23 November 2019 (UTC)

Since this seems uncontroversial I've gone ahead and added this to the guideline. Sam Walton (talk) 00:56, 30 November 2019 (UTC)

@Samwalton9: ...but have edit filter helpers been added // how do I get added? DannyS712 (talk) 01:13, 30 November 2019 (UTC)

We can't add anyone to the mailing list ourselves as that would require knowing your email address. If you submit a subscription request our current practice is to follow up with an email via Wikipedia to confirm your identity. We should probably note that on the page. Sam Walton (talk) 01:17, 30 November 2019 (UTC)

@Samwalton9: I've sent a request to subscribe - sending an email to you now DannyS712 (talk) 01:21, 30 November 2019 (UTC)

Samwalton9, I have sent a request, as well .... ∯WBG^converse 14:32, 30 November 2019 (UTC)

Googledocs?

Should this be deprecated/blacklisted? This is... very prone to abuse, for copyright reasons, and for malware reasons too. Headbomb {t · c · p · b} 13:46, 30 November 2019 (UTC)

Traps and pitfalls

There are several threads on this page that could have been prevented by better documentation. I've started a list of some common mistakes. It still needs copyediting, but any suggested additions? I'd like to keep it short enough that people will actually read it, but it's not too long right now. Suffusion of Yellow (talk) 22:17, 14 November 2019 (UTC)

@Suffusion of Yellow: any good examples of a filter that end up actually matching everything that should never be used? — xaosflux ^Talk 04:54, 15 November 2019 (UTC)

Here's a few expressions that would match everything (or almost everything), despite possibly not seeming like they would:

".*$" and "^.*"
"[A-Za-z0-9_]*"
"(/* expression */)[/1]|[^/1]"

I don't see why one would ever use these, though. Invalid^OS (talk) 13:27, 15 November 2019 (UTC)

I meant examples of a past filter that actually was created, something along a P OR (NOT P) type scenario, maybe with usergroups (there may be none). — xaosflux ^Talk 14:20, 15 November 2019 (UTC)

Ah, ok. Invalid^OS (talk) 15:01, 15 November 2019 (UTC)

Went through the Village stocks. One example, from 2012, was caused by (new_html rlike "(z-index|height|width)\s*:\s*\d\d"), which matches ~90% of edits. I noticed that /test took a long time checking that; I was worried it would time out. That might explain why something so scary-looking was put in there in the first place without proper testing. I wouldn't call it likely to come up again, though.

Another example, from 2011, was accidentally saving a filter consisting of, roughly, (ip_in_range(user_name, "Pastor of Muppets")). Nowadays that would be a syntax error, plus the real mistake was accidentally saving too early.

I once accidentally saved a filter by hitting "Enter" while in the "Description" field, but luckily I hadn't changed anything anywhere, so it was just a null edit. Anyone else done that? Suffusion of Yellow (talk) 18:21, 15 November 2019 (UTC)

The classic fail is the very very early days of filter 58 (third revision), which was something close to ("foo" | "bar") (the exact version probably wouldn't work today). It de-autoconfirmed 200 users and earned a stern warning from the author of the abusefilter extension. -- zzuuzz ^(talk) 18:47, 15 November 2019 (UTC)

How did it de-autoconfirm 200 users? Invalid^OS (talk) 19:19, 15 November 2019 (UTC)

There's an option to not only disallow an edit but also strip the autoconfirmed rights of anyone tripping it. ‑‑Trialpears (talk) 19:30, 15 November 2019 (UTC)

Note that the page was published at Wikipedia:Edit filter/Traps and pitfalls --DannyS712 public (talk) 17:21, 5 December 2019 (UTC)

"Poop" vandalism

Why isn't this [10] picked up by filter 46. ~~ CAPTAIN MEDUSA^talk 17:28, 26 November 2019 (UTC)

CAPTAIN MEDUSA, "poo" isn't detected. Only "poop". Otherwise, many legitimate words like "shampoo" would trip the filter. Home Lander (talk) 20:45, 1 December 2019 (UTC)

I'll take a look at this later, but shouldn't it also catch "poopy" - [11], [12] --DannyS712 public (talk) 20:57, 4 December 2019 (UTC)

Figured it out - can an edit filter manager please replace

ccnorm(added_lines) rlike "\bP+([\.\,\/\?\>\<\!\@\#\$\%\^\&\*\(\)\_\+\-\=\{\}\|\[\]\\\:\;\']?)O\1?O+\1?P+\1?(E*\1?S+\1?|E+\1?R+\1?S*\1?|E*\1?D+\1?|I\1?N+\1?G+\1?)?\b" &

with

ccnorm(added_lines) rlike "\bP+([\.\,\/\?\>\<\!\@\#\$\%\^\&\*\(\)\_\+\-\=\{\}\|\[\]\\\:\;\']?)O\1?O+\1?P+\1?(E*\1?S+\1?|E+\1?R+\1?S*\1?|E*\1?D+\1?|I\1?N+\1?G+\1?|Y+\1?)?\b" &

(add |Y+\1?). This would have prevented [13], [14], [15], and shouldn't cause any false positives. Thanks, --DannyS712 (talk) 01:19, 5 December 2019 (UTC)

Done. First edit to an edit filter, so if someone wants to check if I did it right that would be appreciated. Enterprisey (talk!) 09:10, 5 December 2019 (UTC)

Thanks - Special:AbuseFilter/history/46/diff/prev/22795 looks good --DannyS712 public (talk) 17:20, 5 December 2019 (UTC)

DannyS712, Here is a another one [16], ~~ CAPTAIN MEDUSA^talk 13:25, 6 December 2019 (UTC)

Edit Filter Manager request (User:Headbomb)

With clear, widespread, support demonstrated below access is granted. — xaosflux ^Talk 15:14, 9 December 2019 (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.

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

Mostly because #Edit Filter Helper request (User:Headbomb) was the wrong thing to ask about since it's about me being able to edit and manage some filters, rather than just view private stuff. Pinging previous participants @Beetstra, Ammarpad, JzG, DannyS712, and Xaosflux:. Headbomb {t · c · p · b} 00:16, 2 December 2019 (UTC)

Support Headbomb isn't an admin. Who knew? Hawkeye7 (discuss) 00:26, 2 December 2019 (UTC)
Support. EFM is a right granted only in exceptional circumstances. I find it hard to conceive of anyone I would support more wholeheartedly. The chances of Headbomb abusing this right are, in my view, vanishingly small. He will probably do a better job than most of us admins, and I think he will also be conservative and diligent. It's a trust thing. I trust Headbomb. Guy (help!) 01:30, 2 December 2019 (UTC)
Support A shame previous RfAs didn't work out, because Headbomb has my full trust and support. Technical competency is clearly exemplified by his many bots and WP:BAG membership. We could use his expertise. — MusikAnimal ^talk 02:51, 2 December 2019 (UTC)
Yes. Home Lander (talk) 02:54, 2 December 2019 (UTC)
support. —Dirk Beetstra ^{T C} 03:21, 2 December 2019 (UTC)
I was about to suggest this in the above EFH request but I just decided to leave it at what he requested. So I am supporting this too with no hesitation. – Ammarpad (talk) 03:35, 2 December 2019 (UTC)
Completely support. Headbomb has a good head on his shoulders! –MJL ‐Talk‐^☖ 05:47, 2 December 2019 (UTC)
Support. No issues here. Britishfinance (talk) 09:52, 2 December 2019 (UTC)
Support Generally clueful, with the right sort of clues. All the best: Rich Farmbrough, 12:42, 2 December 2019 (UTC).
Support Obviously, ∯WBG^converse 12:43, 2 December 2019 (UTC)
Support per MusikAnimal Ritchie333 ^(talk) ^(cont) 12:59, 2 December 2019 (UTC)
Support In addition to the above, it's arguably more transparent to have Headbomb change those filters directly, since I see people constantly bugging him about them. Nemo 13:11, 2 December 2019 (UTC)

It's a fairly recent thing, mostly because the searching power of WP:CITEWATCH and User:JzG/Predatory have been massively increased in the last few weeks. But as far as I'm concerned, anything that ends up on the filters for predatoryness is subject to review at WP:RSN. Headbomb {t · c · p · b} 13:37, 2 December 2019 (UTC)

Support Clearly competent and trustworthy. I just want to encourage you to take another look at account security if you get this right. You probably already have being a template editor and all but it never hurts being a little cautious. ‑‑Trialpears (talk) 19:17, 2 December 2019 (UTC)
Support Sure! --Malcolmxl5 (talk) 14:15, 3 December 2019 (UTC)
Support. Yep, no problem. Boing! said Zebedee (talk) 14:56, 3 December 2019 (UTC)
Support can be trusted, clear use case, though with a suggestion to test things at first (eg using filter 1 or the batch interface) before updating filters. I note that, as a non-efh, you won't have had access to the batch interface until now - its pretty helpful. --DannyS712 (talk) 18:08, 3 December 2019 (UTC)
Support- No concerns from me. Aloha27 talk 18:35, 3 December 2019 (UTC)
Support — No concerns. ~~ CAPTAIN MEDUSA^talk 12:20, 7 December 2019 (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.

Can edit filters be set to allow only certain editors to edit a certain kind of page?

Based on discussion at User talk:Vanamonde93/Main page editor#Feedback.

There is some discussion and possible consensus that a select group of non-admin DYK regulars should be allowed to promote queue for appearance on the main page which is currently restricted to admins to avoid the obvious potential for vandalism. The actual posting to the Main Page works by having an adminbot copy the queue to the main template at a certain time. My question before I propose a change is this: Can an edit filter be set to block all edits from non-admins to Template:Did you know/Queue/1 ... Template:Did you know/Queue/6 except by a few editors that were deemed trustworthy enough to make these changes? Regards So Why 12:08, 11 December 2019 (UTC)

@SoWhy: That example page is protected, and cascade protected - so those would have to go first. It is possible to make a filter to check (not) user_name, though we rarely do something like that for a specific registered user. A bigger problem is that a filter fail or overload can mean it gets skipped so this would fail-dangerous to allowing that page to just be open - also it doesn't scale well to add lots of conditions (if there were 2 usernames it would be one thing - dozens may start getting costly. — xaosflux ^Talk 12:50, 11 December 2019 (UTC)

The cascade protection would be removed under that scenario, it only exists in order to prevent non-admins from filling queues. Are you saying that malicious users could circumvent the filter by making DoS-style edits until one is not caught by the filter? That would of course make the idea unfeasible... Regards So Why 13:06, 11 December 2019 (UTC)

Yes - the filter has a performance cap. As I understand it, for any given edit only so many filter conditions are checked. Once some limit is reached, the rest are skipped and the edit is allowed to progress. This used to be quite a big issue though I believe the technical limitations were relaxed somewhat in recent years. Still, not as secure a system as we'd want for editing the main page. Sam Walton (talk) 13:32, 11 December 2019 (UTC)

Agreed with all of the above, filters just aren't going to be the right solution for access control, since they're not guaranteed to run. I wonder if an adminbot could be set up to do something similar? i.e. a user on a trusted list can tell the bot to queue the page. Not familiar enough with the bot policy to know if crossing a privilege boundary like that (a non-admin directing an adminbot to take an action on an admins-only page) breaks any rules. ^creffpublic _{a creffett franchise} (talk to the boss) 13:37, 11 December 2019 (UTC)

@Creffett: That shouldn't be a problem if there is a consensus to do so and it's my plan B but it requires changing the code of the bot that does the updates to detect who edited the queue which it currently does not. Regards So Why 13:47, 11 December 2019 (UTC)

891 brainstorm?

Things like ssjournals\.com in Special:AbuseFilter/891 will catch things like ucpressjournals.com. What would the way to make sure that it only matches the ssjournal.com domain, and not stuff like foobarpressjournals.com?

Would changing

urls := "academicjournals\.com|academicjournals\.net|...";

to something like

urls := "\.(academicjournals\.com|academicjournals\.net|...)";

work? Or would

urls := "academicjournals\.com|academicjournals\.net|...|\.ssjournals\.com|...";

be necessary (or just better, as a more targeted option)? Headbomb {t · c · p · b} 13:47, 12 December 2019 (UTC)

I went with the targeted option, since it works just fine for now, but the 'general' version might be better in the long run if false positives are common. Headbomb {t · c · p · b} 14:06, 12 December 2019 (UTC)

@Headbomb: The traditional way to do this would be \bssjournals\.com, where \b represents a word boundary, ie it matches any subdomain or none at all (such as //ssjournals.com). I would think that surrounding all URLs with word boundaries (as in option #2: \b(...|...)\b) would be the best way to do this to reduce false positives, but you might want to have a think about it, discuss it, and/or disable actions while testing ;) -- zzuuzz ^(talk) 20:24, 13 December 2019 (UTC)

Reduce risk of private filters being leaked

As I mentioned in Creffet's EFH application, it may be sensible to move the ability to grant EFH and EFM permissions from admins to crats reducing the amount of people having instantaneous access to the private filters. This is to prevent a compromised admin account from leaking the private filters, which would permanently reveal to LTAs how to bypass many private filters. Any admin would still be able to gain EFM rights no questions asked, but would be required to go through WP:BN with a day hold so a compromised account could be detected. I also think a mass message should be sent to current EFMs to ask if they still need access to further reduce the risk. What do you think is this a reasonable precaution or is it overkill? It's a bit hard for me to know since I can't actually see the filters. ‑‑Trialpears (talk) 21:28, 30 November 2019 (UTC)

Trialpears (and other noticeboard-goers), out of curiosity, do we have any known instances of filters getting leaked (or someone targeting the filter)? Generally speaking, I agree with tanking steps to protect the filters, I'm just curious how big a target they are compared to other things someone could do with a compromised admin account and whether they'd be worth the effort for someone to infiltrate. creffett (talk) 21:33, 30 November 2019 (UTC)

Creffett not sure, but I think it should be taken seriously even if it's just hypothetical, since if it ever were to happen they would be out there forever with usually only small changes. If you have a compromised admin account this could also be done first without raising any red flags since no edits would be required. Infiltrating purely to leek these would be unlikely but coupling this with other disruption seems plausible. ‑‑Trialpears (talk) 21:43, 30 November 2019 (UTC)

@Trialpears: Right now, admins can already see private filters. So for this to work, we'd need to take away the abusefilter-view-private right from admins and make them request the EFH bit. BN's going to be quite busy, for a while. Perhaps we could make it easier: Only crats can assign the rights, but a private request (email or talk page) to a crat is fine, also. And no 24 hour hold. Anyone with access to a compromised account would probably be afraid of interacting with humans, at all, before they do whatever they're going to do. Suffusion of Yellow (talk) 22:00, 30 November 2019 (UTC)

Suffusion of Yellow, wasn't aware of that! When checking Special:ListGroupRights I also saw that EFM doesn't actually contain abusefilter-view-private which I previously thought it did. Does this mean that you (Suffusion of Yellow) can't actually view private filters? All changes suggested sound reasonable and I approve of them. ‑‑Trialpears (talk) 22:43, 30 November 2019 (UTC)

@Trialpears: No, abusefilter-modify implies abusefilter-view-private. The check is here. Suffusion of Yellow (talk) 22:46, 30 November 2019 (UTC)

I'm not really supportive of removing (abusefilter-view-private) from admins who could otherwise use it routinely in things like looking at someone's filter log. Think this would result in the old "problem" of lots of admins adding filter management access they otherwise don't need just for that reading purpose. — xaosflux ^Talk 16:23, 1 December 2019 (UTC)

Also, the current tasks and qualifications of bureaucrats do not involve edit filter management in any way, so I would not attach them there. Jo-Jo Eumerus (talk) 16:28, 1 December 2019 (UTC)

@Jo-Jo Eumerus: I wouldn't rule it out for that reason (e.g. 'crats aren't charged with botting or interface admining either, or technically even admining). Updating user rights is within 'crat expectations - however we don't really do discretionary rights changes, so if this is to be a 'crat function we would need a strongly supported set of parameters for when it should or shouldn't be done. — xaosflux ^Talk 20:13, 1 December 2019 (UTC)

@Xaosflux: The idea is that admins who only need to view filters could request EFH rights (no questions asked). There'd be no need for them to have EFM rights anymore. Admins could keep the abusefilter-log-private right, which should be good enough for most of the "see also filter log" AIV reports, etc. I'm still somewhat ambivalent about this; if only 20% of admins end up with EFH or EFM, it may be worth the trouble, but if it's going to be 80%, why bother? Suffusion of Yellow (talk) 16:59, 1 December 2019 (UTC)

I don't think I'm too worried about the main scenario worry here, "rogue admin reads (and possibly discloses) the filter contents". — xaosflux ^Talk 20:16, 1 December 2019 (UTC)

Taking into account feedback above the following right changes seems most appropriate if this were to be implemented:

Administrators: Replace abusefilter-view-private with abusefilter-log-private and remove the ability to add EFM and EFH user groups. This would allow all admins to see private logs but not the actual filters reducing the risk that the filter would be leaked but allowing all admins to handle private logs. Viewing the actual filter should only be required by people working with filter development meaning only a fraction of admins would need the ability.
Bureaucrats: Add groups Edit filter helper and Edit filter manager. This would be done immediately upon request by any admin without any conditions. The purpose is not to limit access by admins but to reduce unneeded risk in case the account gets compromised while adding as little extra bureaucracy as possible.

Do you guys think it would be worth writing a proper RfC and get some wider community input or is it still more hassle then it's worth? I will defer to you who actually know what's in the filters since it's difficult for me to evaluate the risks involved. ‑‑Trialpears (talk) 21:23, 13 December 2019 (UTC)

Trialpears, I think it's a solution to a non-problem, but feel free if you want to. Guy (help!) 23:39, 13 December 2019 (UTC)

I think you underestimate how easy it is for LTAs to bypass private filters - any LTA that understands filter syntax and how they work well enough to make use of a leak of private filters, could also bypass the filter through changing their patterns. The filter for any active LTA generally has to be regularly updated as they find new ways to bypass it, meaning the impact of a private filter leak would not be massive IMO. Galobtter (pingó mió) 23:49, 13 December 2019 (UTC)

Help reproduce a bug

Tracked in Phabricator
Task T240115
Resolved

See T240115 so I don't have to repeat everything here. In short, the filter is testing some null edits (about 20/hour), when it shouldn't. No one else can reproduce the bug, but can someone try steps 2-9 here, and see if you trip testwiki:Special:AbuseFilter/208? Suffusion of Yellow (talk) 00:02, 10 December 2019 (UTC)

Noting that this was fixed by the the always hard-working Daimona Eaytoy. No hits from filter 1 (hist · log) in a day. Suffusion of Yellow (talk) 17:25, 14 December 2019 (UTC)

Removing bad tags?

I had a stay pipe in 891 for about a minute and a handful of edits were tagged with the 'Citing predatory open access journal' tag. I'm trying to edit tags in articles, but I get a warning saying that "Citing predatory open access journal" tag is not allowed to be removed. What gives? Isn't the whole point of being an edit filter manager being able to deal with these things? Headbomb {t · c · p · b} 13:56, 12 December 2019 (UTC)

@Headbomb: I don't think that's possible. Only tags "activated" for manual addition can be removed. I suppose you might be able activate the tag from Special:Tags, but from the look of Special:Log/tag no one's ever removed a filter-applied tag. Suffusion of Yellow (talk) 18:09, 13 December 2019 (UTC)

I'd say that the primary "point" of EFM access is being able to manage the actual filters - not even sysops can remove those tags directly. You could ask the developers to revisit phab:T20670 about removing errant tags though. — xaosflux ^Talk 20:07, 13 December 2019 (UTC)

Welcome to the 'disable actions while changing things' club :) -- zzuuzz ^(talk) 20:27, 13 December 2019 (UTC)

Hmm, I have a local user script that changes the background color of any AbuseFilter page depending on the actions. Impossible to miss. But the script suffered an attack of severe featuritis, and also (poorly) does about a dozen other things, so I've never published it. Perhaps I'll move that part to User:Suffusion of Yellow/filter-highlighter if anyone else thinks they'll used it. Suffusion of Yellow (talk) 20:39, 13 December 2019 (UTC)

Done anyway, because I felt like it. Suffusion of Yellow (talk) 18:34, 14 December 2019 (UTC)

Set filter 135 (Repeating characters) to disallow?

I think filter 135 should be set to disallow after reviewing 200 recent edits tagged by the filter. Of these one was a false positive from a user replacing a numbered list using hard codedvalues with # symbols. This false positive could be fixed by allowing repeated # symbols (done by replacing "([^_:.*'|=}{-]{1,9})\1{6}" with "([^_:.*'|=#}{-]{1,9})\1{6}" at line 10). The change was tested using https://regex101.com/ and worked as expected. I don't know what false positive rate is generally desired before disallowing but I feel like this should be sufficient after my proposed change. --Trialpears (talk) 11:11, 14 September 2019 (UTC)

Any thoughts? --Trialpears (talk) 07:07, 27 September 2019 (UTC)

Jo-Jo Eumerus wanna respond to this request as well? If you don't want me to ask you in the future tell me. --Trialpears (talk) 18:55, 1 October 2019 (UTC)

Sorry, but my familiarity with edit filter syntax is very limited. Changing a message is something I can do, the actual syntax not. Jo-Jo Eumerus (talk, contributions) 20:00, 1 October 2019 (UTC)

Bump. ‑‑Trialpears (talk) 08:48, 15 November 2019 (UTC)

@Trialpears: 200 edits, checked manually? I don't have that level of patience! But, I went through 500 most recent edits that were actually saved, using an automatic reverted edit detector that I'm working on (so it may have bugs). I only found 13 that were not "cleanly" reverted. Checking those manually, I only found Special:Diff/924861448, Special:Diff/926208443, and Special:Diff/926230932. The first is someone creating an empty ordered list, which relates to the issue you mentioned, the second is a copyvio (song lyric containing "La la la la la" ... in Chinese), and the third is a direct quote of someone writing "Yessssssssss!". So only 1-3 FP out of 500 (assuming we trust the vandalism patrollers, that is), which is actually pretty good. I'd be in favor of setting this to disallow. Suffusion of Yellow (talk) 19:42, 15 November 2019 (UTC)

For over two years that I am aware of this filter; it seems to me to be one of the most accurate filters we have. I don't think I am exaggerating if I say 98% of all edits that it catches are bound to be reverted (and rightly so). I believe empirical data of the reversion must be around that percentage. It's quite overdue for this filter to disallow such edits completely. – Ammarpad (talk) 07:07, 16 November 2019 (UTC)

I remember going through many hits of this filter a while back and not seeing many FPs. Definitely a strong candidate for disallowing; if no one gets to it before I do, I'll set it to disallow and fix the repeated # issue when I have a bit more time. Galobtter (pingó mió) 22:29, 21 November 2019 (UTC)

Galobtter, just a gentle reminder. ‑‑Trialpears (talk) 22:26, 7 December 2019 (UTC)

Apologies, the end of the semester is a busy time. Will definitely get to it (have not forgotten) but it may only happen over winter break. Galobtter (pingó mió) 01:38, 8 December 2019 (UTC)

@Trialpears: Ok, I've tweaked filter to exclude repeated # as you suggested. Will set the filter to disallow in a few days unless there's an unexpected issue with the filter. Galobtter (pingó mió) 19:18, 21 December 2019 (UTC)

@Trialpears, Ammarpad, and Suffusion of Yellow:, I've set the filter to disallow. Galobtter (pingó mió) 03:53, 25 December 2019 (UTC)

Set filter 1018 to warn?

Filter 1018 (hist · log) (public)
Wikipedia:Administrators' noticeboard § Donald Trump factoid spam

Any objections? I know it's not perfect, but thanks to garbage like [17] this I don't expect this to stop soon. I'll monitor the log and refine as needed. Suffusion of Yellow (talk) 21:26, 21 December 2019 (UTC)

Suffusion of Yellow, I went through the currently tagged edits, and the two major false positives I saw are Special:Diff/931787122 (which was a very problematic edit, but isn't the impeachment meme) and the more legitimate Special:Diff/931838295. Since the problem with the latter was that the line already contained "house," maybe adding a !removed_lines check might help? Other than that, I say go for it. creffett (talk) 01:45, 22 December 2019 (UTC)

I've revdelled that first edit for severe BLP violations. I would say a removed_lines check seems reasonable. Galobtter (pingó mió) 02:18, 22 December 2019 (UTC)

Thanks. Special:Diff/931838295 only matched an old version of the filter, before the !(old_wikitext + page_title) irlike "impeach" check was added. Checking for "house" in removed_lines makes sense though, but not "trump", because many of the targets already mention Trump. Suffusion of Yellow (talk) 02:44, 22 December 2019 (UTC)

Noting for anyone reviewing the log, that the hits from 2A02:587:3A0F:5F00:2556:BF0B:A575:61E4 contain supposed Rise of Skywalker spoilers. Suffusion of Yellow (talk) 02:58, 22 December 2019 (UTC)

Done with the default MediaWiki:Abusefilter-warning. I don't think the filter needs a custom warning; people doing this are basically NOTHERE, IMO. If anyone is more willing to AGF than me, feel free to suggest a custom warning. Suffusion of Yellow (talk) 18:39, 22 December 2019 (UTC)

Set filter 1018 to disallow?

Amazingly,^[sarcasm] most people are just ignoring the warning. There have been no FPs since setting this to to warn. Perhaps it's time? Suffusion of Yellow (talk) 18:19, 23 December 2019 (UTC)

That, or perhaps blocking (i.e add this filter to User:DatBot/filters)? Jo-Jo Eumerus (talk) 18:38, 23 December 2019 (UTC)

@Jo-Jo Eumerus: Would most admins agree that this is block-on-sight behavior? I'm thinking of it more as run-of-mill meme vandalism, along the lines of "Epstein didn't kill himself" or "OK Boomer". Suffusion of Yellow (talk) 18:42, 23 December 2019 (UTC)

Bot reports to AIV don't seem to be an issue. --qedk (t 桜 c) 16:25, 25 December 2019 (UTC)

Done again with default warning. The problem with DatBot's list that we have two choices: Report after one hit, or only report after five hits in five minutes. The first should really be reserved for LTAs; if we put too much in there admins will start unwatching WP:AIV/TB2. The five-edits line would be fine, expect that most people adding this impeachment crap aren't really trying all that hard; I doubt many would get reported. Suffusion of Yellow (talk) 05:31, 28 December 2019 (UTC)

EFH for User:CAPTAIN MEDUSA

There is no support to grant EFH at this time. — JJMC89 (T·C) 20:50, 30 December 2019 (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.

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

I am continuously viewing the edit filter log and reporting the users at AIV. I keep on running into private filters including: Possible spambot or promotional username, Image changes by new users, Userspace & talk page spamming, etc. This right will be very useful when reporting the user because I can see the reason the filter was triggered rather than guessing it. I have requested several filters at Wikipedia:Edit filter/Requested and been helping out Wikipedia:Edit filter/False positives.

No recent blocks or relevant sanctions. Y
At least basic understanding of account security. Y ~~I will enable 2FA~~ Enabled 2FA.
At least basic understanding of regular expressions if the intent is to assist with authoring filters. Y
Sufficient ability with the English language to understand notes and explanations for edit filters. Y
Must also meet at least one of these criteria:
Currently-active extended confirmed editor on the English Wikipedia (i.e. has made edits or logged actions within the last 12 months). Y

Thanks for your consideration. ~~ CAPTAIN MEDUSA^talk 21:02, 17 December 2019 (UTC)

@CAPTAIN MEDUSA: you are not a current administrator on any WMF project (verify). However you should meet sub-criteria (1). — xaosflux ^Talk 21:44, 17 December 2019 (UTC)

Xaosflux, I am a admin in test wiki. Anyway chnaged it. Thanks. ~~ CAPTAIN MEDUSA^talk 21:52, 17 December 2019 (UTC)

Ah OK "The Test Wiki" isn't WMF like testwiki is. — xaosflux ^Talk 21:54, 17 December 2019 (UTC)

Xaosflux, oh, I see. ~~ CAPTAIN MEDUSA^talk 21:58, 17 December 2019 (UTC)

I'm not willing to support this, yet. You've only been involved with filters for about a month, unless I didn't notice something, and I'd like to see a longer-term commitment. Suffusion of Yellow (talk) 18:15, 20 December 2019 (UTC)
Suffusion of Yellow Wikipedia:Edit filter helper says At least basic understanding of regular expressions if the intent is to assist with authoring filters. ~~ CAPTAIN MEDUSA^talk 12:25, 22 December 2019 (UTC)
(edit conflict) I set the bar for this right at Demonstrated Need, and I'm not seeing the "need" bit here. As always, contributions to EF/FP are always appreciated, but they alone do not rise to that level in my view. Most of the filters you mentioned above are indeed hidden due to "reasons" but for reporting purposes, promo usernames, spambots, what a new user did to an image, page spamming, and so on, will all be quite obvious; the filter isn't hidden to conceal some secret algorithm that isn't already apparent to the average user. Keep doing what you're doing, though, and when the Need appears, it will also be apparent. Crow^Caw 18:22, 20 December 2019 (UTC)
@Crow: It can be a false positive, but I want to be sure when reporting a user. ~~ CAPTAIN MEDUSA^talk 13:42, 21 December 2019 (UTC)
What filters, exactly, would you be interested in dealing with? Headbomb {t · c · p · b} 18:23, 20 December 2019 (UTC)
@Headbomb: I want to see Possible spambot or promotional username, Image changes by new users, Userspace & talk page spamming, "ntsamr"-pattern spambot filter.~~ CAPTAIN MEDUSA^talk 14:07, 21 December 2019 (UTC)
- I additionally want work with Filter (102, 354, 579, 499) as listed on WP:UAA. To catch more of enwiki user names violations i.e. promotional name. ~~ CAPTAIN MEDUSA^talk 19:27, 30 December 2019 (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.

"youngest entrepreneur"

Moved to Wikipedia:Edit filter/Requested/Archive_14#"youngest entrepreneur"

– ~~ CAPTAIN MEDUSA^talk 13:12, 4 January 2020 (UTC)

I see the phrase "youngest entrepreneur" pop up fairly often in (poorly written) self-promotion in user and draftspace. I'm thinking that it might be a candidate for Special:AbuseFilter/627, thoughts? — Preceding unsigned comment added by Creffett (talk • contribs) 18:18, 20 December 2019 (UTC)

@Creffett: can you point to some recent diffs if this is a priority issue? (In general you can request filter updates at WP:EF/R) — xaosflux ^Talk 13:46, 21 December 2019 (UTC)

Xaosflux, not a priority issue. Sorry about that, I thought that since I was suggesting a change to an existing filter it would be better on EF/N than EF/R, will repost there. creffett (talk) 20:57, 21 December 2019 (UTC)

LTA

Hi. I'd like some help crafting a filter to log an LTA please. The signature element is adding {{cite journal|pmid=[digits]}} with no other parameters. That's easy in itself but I want to strip all whitespace - can I use norm? I am inexperienced with that. Guy (help!) 20:13, 5 January 2020 (UTC)

@JzG: Yes, norm should work. For more details, there's a manual at mw:Extension:AbuseFilter/Rules format#Functions. Majavah ^(t/c) 09:05, 6 January 2020 (UTC)

rmwhitespace should also work, if you want to only remove whitespaces. Ahmad^talk 10:10, 7 January 2020 (UTC)

Edit filter 1009

The attempted edit in Special:AbuseLog/25730534 caused DatBot to report 95.54.131.202 (talk · contribs · WHOIS) at WP:AIV, since the edit was blocked by filter 1009 (hist · log).

It's too harsh to tell IP editors who attempt to add an innocuous picture to the sandbox that their edit was "potentially unconstructive", and then block their edit. The sandbox is intended to be a place where editors can learn using wikitext, and this kind of messaging deters editors from contributing to Wikipedia. Automatically reporting these editors to WP:AIV generates a lot of false positives, and is not reasonable to me. — Newslinger talk 00:10, 8 January 2020 (UTC)

@MusikAnimal, Zzuuzz, and Suffusion of Yellow: please review. — xaosflux ^Talk 00:13, 8 January 2020 (UTC)

@Newslinger: replied by email. Suffusion of Yellow (talk) 00:44, 8 January 2020 (UTC)

Thank you. Let's continue the conversation over email. — Newslinger talk 00:51, 8 January 2020 (UTC)

"we" vs "you" in Abusefilter-unexplained-removal

{{edit interface-protected|MediaWiki:Abusefilter-unexplained-removal|answered=yes}}

I feel like the "we" in MediaWiki:Abusefilter-unexplained-removal comes off as a bit like talking down to the editor (reminds me of how people ask children "how are we feeling today") and might be better as "you." I'd recommend changing the first sentence to "When you remove sourced content you should provide an edit summary with a brief explanation on why you think the content should be removed." I'd also be open to wordsmithing the first part since the "you" could come off as accusatory, maybe "When you remove" -> "When removing"? Bringing it here for discussion before requesting an edit in case anyone feels differently. ^creffpublic _{a creffett franchise} (talk to the boss) 18:17, 14 January 2020 (UTC)

Oops, I've been using "we" like this when giving advice to newer editors, but the pronoun is intended to refer to the Wikipedia community as a whole – which includes both me and the editor I'm talking to. Not sure what the best approach is, but "we" implies that the person who wrote the message is also subject to the same expectations. — Newslinger talk 01:02, 15 January 2020 (UTC)

Newslinger, yeah, I get that as the original intent. Looking at it a second time, I think my biggest issue is coming from "we should" - again, I get that that refers to the community, but it's reading to me like a command wrapped up in the talking-down "we." Also, the second sentence then says "you," so we should probably harmonize the two (or maybe make the second sentence impersonal - "don't interpret those removals as vandalism," perhaps). I'll spend some more time staring at it and see if I can come up with something better. creffett (talk) 02:08, 15 January 2020 (UTC)

It's possible to avoid pronouns altogether, e.g. "When removing sourced content, please provide an edit summary that briefly explains why the content should be removed. This helps ensure that other editors don't misinterpret the removals as vandalism." — Newslinger talk 07:30, 15 January 2020 (UTC)

I like that one! Will wait a little longer in case anyone else wants to comment, then will open an edit request. ^creffpublic _{a creffett franchise} (talk to the boss) 14:32, 15 January 2020 (UTC)

WP:BOLDly made this section an interface-level edit request, put this section in <onlyinclude> tags, and transcluded to MediaWiki talk:Abusefilter-unexplained-removal. The edit request template is in includeonly tags, so it won't show up here. Invalid^OS (talk) 15:08, 15 January 2020 (UTC)

I've reverted the transclusion, since it will simply break when this page archives. Reaper Eternal (talk) 15:12, 15 January 2020 (UTC)

Also,

Done. Reaper Eternal (talk) 15:15, 15 January 2020 (UTC)

Filter disallowing usernames that end with a semicolon

Tracked in Phabricator
Task T238285

There is a bug in MediaWiki (or possibly something with WMF infrastructure) that breaks path-style links to pages/users ending a semicolon. For instance, I was not able to block a vandal because all the links to Special:Block/Printf("Herro World");, Special:Contribs/Printf("Herro World");, etc. don't work. Only the query string URLs work, which is not what most links point to. This seems pretty bad... so I was bold and created Special:AbuseFilter/1023 and set it to disallow. It is showing MediaWiki:Abusefilter-disallowed-semicolon. My question is, should we expand this to do the same for page creations? Conceivably there are encyclopedic use-cases for pages ending in a semi-colon, and I don't want to prevent that. I just felt the issue with usernames was more pressing, since it's an easy exploit for vandals. — MusikAnimal ^talk 22:41, 21 January 2020 (UTC)

What if the account was created elsewhere? –xeno^talk 22:53, 21 January 2020 (UTC)

A local edit filter wouldn't stop that making m:Title blacklist the proper place to fix this. ‑‑Trialpears (talk) 23:03, 21 January 2020 (UTC)

We could check for "autocreateaccount" to prevent local accounts that were created on other wikis, but indeed the Meta title blacklist appears to be the best way to fix this. I didn't know the title backlist worked on account creations! I'll coordinate with others to get this added. — MusikAnimal ^talk 23:24, 21 January 2020 (UTC)

FWIW, it appears we can still block these accounts via API calls and their userid - at least according to my response:

    "error": {
        "code": "alreadyblocked",
        "info": "\"Printf(\"Herro World\");\" is already blocked.",

— xaosflux ^Talk 23:55, 21 January 2020 (UTC)

Replied to your email; but to say it publicly, you can still block by typing the username in manually at Special:Block, or by using query parameters instead of path parameters [18] which is what I did. — MusikAnimal ^talk 00:03, 22 January 2020 (UTC)

Filter 828

Sorry, just came across Special:AbuseFilter/828 and it was bugging me a bit. The stringy variable is declared, but then rather than using it, the content (#redirect[[) is used twice. Can an EFM either use the variable or remove it? Thanks, --DannyS712 (talk) 08:29, 23 January 2020 (UTC)

Done — MusikAnimal ^talk 17:02, 23 January 2020 (UTC)

Better message for LTA filters

This came out of an email conversation with Newslinger. Basically, MediaWiki:Abusefilter-disallowed may a good fit for generic vandalism filters, but it's not the right message for LTA filters. The user either (A) knows exactly what they're doing, and expects to be blocked sooner or later, or (B) has no clue why their edit was disallowed. In case (A) the threatening tone of the default message isn't going to make any difference, and in case (B) it could easily drive away a good-faith editor.

So perhaps we should have a "generic LTA" warning that completely assumes good faith? First, the default message, for comparison:

An automated filter has identified this edit as potentially unconstructive, so it has been disallowed. If this edit is constructive, please report this error. Disruptive editing may result in a block from editing.

Report error

And here's a possible "generic LTA" message:

In response to an ongoing pattern of abuse, an automated filter has prevented this edit.

Don't worry, your work has not been lost! The full content of this edit has been saved, but it will not be visible to readers unless you take further action.

Please go the report page and follow the instructions. An experienced editor will review your changes, and make the edit on your behalf.

Report error

I'm not very satisfied with the wording; any suggestions or alternatives are welcome. Suffusion of Yellow (talk) 23:40, 11 January 2020 (UTC)

An LTA filter that is in any way likely to trigger a false positive should never be set to disallow. Reaper Eternal (talk) 05:38, 12 January 2020 (UTC)

@Reaper Eternal: For what value of "likely"? Should a filter that trips on literally one in a million good-faith edits be set to disallow? If yes, that's about one false positive per week, just for that one filter! In practice, most LTA filters produce the occasional FP. And we want as many of those FPs reported, or the filter won't get fixed.

I'm not, to be clear, suggesting that we use a better warning as an excuse to be sloppy. Suffusion of Yellow (talk) 06:10, 12 January 2020 (UTC)

I'm also not a great fan of the wording, but I do know of a couple of LTA filters which have caused false positives (or at least totally confusing positives) and probably will again. But I'm in two minds - doesn't the same principle apply to all filters? Don't we need to forget about LTAs and just genericise or friendly-ify the current disallow message? -- zzuuzz ^(talk) 07:18, 12 January 2020 (UTC)

Thanks for drafting the new message, Suffusion of Yellow. I think your proposed message is a massive improvement over the current message, since it is less aggressive toward productive users who submit edits that are caught as false positives. As you mentioned, the warning message that LTA filters (set to disallow) show to LTA users makes absolutely no difference to Wikipedia, because edit filters are not going to transform an LTA user into a productive user. At best, these filters can mitigate the damage from LTA users, and we should optimize the warning message to minimize collateral damage caused by false positives.

Zzuuzz, the expected outcomes are different for filters that target disruptive edits from non-LTA users. Assuming that non-LTA users who intentionally submit disruptive edits can be coaxed into becoming productive users (or, at the very least, less disruptive users), the current message might be more effective. When we're not exclusively targeting LTA users, I think it would be best if we reserve the current message for filters that only disallow intentional, highly disruptive edits with a very low rate of false positives. However, I don't have any data on how editors are impacted by these messages, and if we had to choose one message across the board, I would prefer the proposed version. — Newslinger talk 10:51, 12 January 2020 (UTC)

I agree with the logic behind this proposal, but my impression has always been that it's not the wording of the warning that matters, rather the visibility. People just don't read these things... so in that sense the MediaWiki:Abusefilter-disallowed might actually be better since the pink background stands out more. For instance the large font of MediaWiki:Abusefilter-unexplained-removal seemed more effective than older compact version, if I remember correctly. I did this by comparing how many times edit summaries were used on the successful save (after they saw the warning). — MusikAnimal ^talk 04:04, 14 January 2020 (UTC)

Here are some mockups that couple the proposed wording with a red background and/or a larger font:

In response to an ongoing pattern of abuse, an automated filter has prevented this edit.

Don't worry, your work has not been lost! The full content of this edit has been saved, but it will not be visible to readers unless you take further action.

Please go the report page and follow the instructions. An experienced editor will review your changes, and make the edit on your behalf.

Report error

Your changes have not been published.

In response to an ongoing pattern of abuse, an automated filter has prevented this edit.

Don't worry, your work has not been lost! The full content of this edit has been saved, but it will not be visible to readers unless you take further action.

Please go the report page and follow the instructions. An experienced editor will review your changes, and make the edit on your behalf.

Report error

Your changes have not been published.

In response to an ongoing pattern of abuse, an automated filter has prevented this edit.

Don't worry, your work has not been lost! The full content of this edit has been saved, but it will not be visible to readers unless you take further action.

Please go the report page and follow the instructions. An experienced editor will review your changes, and make the edit on your behalf.

Report error

How are these? The heading can also be used for the templates with smaller font sizes. — Newslinger talk 14:30, 14 January 2020 (UTC)

I prefer the last one, which aligns with the pink=disallow convention. — MusikAnimal ^talk 17:24, 14 January 2020 (UTC)

Would the last template be acceptable to you, Suffusion of Yellow and Zzuuzz? — Newslinger talk 01:53, 16 January 2020 (UTC)

Newslinger, last one is much better than the other ones. ~~ CAPTAIN MEDUSA^talk 02:21, 16 January 2020 (UTC)

Since I was asked for feedback, I'll supply it. I'm not going to stand in anyone's way here, though I'm probably still not fully on board. Visibly, the last message seems an improvement. I have some concern about saying that someone will make the changes on the user's behalf. This might be true, but it's not guaranteed, and I think a talk page message (or something else) might also be an option. As a use-case, I can't help but think about filter 847, which it's possible to trip as a false positive. The original default message mentions 'constructive', which might be useful, but I guess that goes back to my original comment in this thread. -- zzuuzz ^(talk) 11:18, 16 January 2020 (UTC)

@Zzuuzz: Alright, what about replacing "An experienced editor will review your changes, and make the edit on your behalf." with "An experienced editor will review your changes, and provide assistance."? Suffusion of Yellow (talk) 20:50, 17 January 2020 (UTC)

Much better, thanks. I'll leave my comments there. -- zzuuzz ^(talk) 20:55, 17 January 2020 (UTC)

Bumping thread. I'm away for a bit, but when I get back I have an idea for how to test this. Basically, temporarily split out one of the "busy" filters into two:

(timestamp % 2 == 0) &
( /* Original  conditions here */ )

and

(timestamp % 2 == 1) &
( /* Original conditions here */ )

with the default warning for the first filter, and the new warning on the second. Then we can measure the results, e.g. how many users who trip each filter report to EF/FP? How many stop after the first warning? Suffusion of Yellow (talk) 19:44, 29 January 2020 (UTC)

Maintenance of MediaWiki:Abusefilter messages

Greetings,

while strolling across the MediaWiki namespace I've come across a number of messages that are supposedly used by edit filters, but appear to belong either to inactive filters or have been replaced or lack information about which filter applies them. In detail:

MediaWiki:Abusefilter-youtubefilter-warning: No filter associated with this and I can't find one.
MediaWiki:Abusefilter-warning-userpage-blanking, MediaWiki:Abusefilter-warning-short-new-article, MediaWiki:Abusefilter-warning-repeated-characters, MediaWiki:Abusefilter-warning-repeated, MediaWiki:Abusefilter-warning-nowiki, MediaWiki:Abusefilter-warning-remove-csd, MediaWiki:Abusefilter-warning-nospaces, MediaWiki:Abusefilter-warning-local-link: Apparently not in use (right now) at filter given. Many of these appear to be currently using a default "disallowed" message rather than the more specific ones.
MediaWiki:Abusefilter-warning-spambot-allowed: Filter is marked as deleted.
MediaWiki:Abusefilter-warning-researchgate, MediaWiki:Abusefilter-unexplained-removal, ~~MediaWiki:Abusefilter-top100~~, MediaWiki:Abusefilter-references, MediaWiki:Abusefilter-disallowed-BLP, MediaWiki:Abusefilter-MariaJaydHicky, MediaWiki:Abusefilter-ANIbugnotice: ~~No filter associated with these.~~Found filters associated with these, but most are now inactive.
MediaWiki:Abusefilter-warning-malformed: Filter disabled for over a year.
MediaWiki:Abusefilter-warning-dailymail: Apparently this is superseded by the general "deprecated" message?
MediaWiki:Abusefilter-warning-archiveis, MediaWiki:Abusefilter-warning-AfC-MfD-submissions: Apparently this filter does not send a warning anymore?
MediaWiki:Abusefilter-warning-AFC: Judging by the last comment on the now-disabled filter, this probably isn't needed anymore.
MediaWiki:Abusefilter-vevo, MediaWiki:Abusefilter-malbot, MediaWiki:Abusefilter-chartnews: I've associated filters with these, but it's marked as "deleted".
MediaWiki:Abusefilter-anon-warning: No filter associated with this, but I am not sure if there should be one.

I am thinking that some of these could be deleted as no longer in use, and others might warrant having filters added. Jo-Jo Eumerus (talk) 17:44, 16 January 2020 (UTC)

Well, something's strange here - I just checked, 636 says it uses abusefilter-unexplained-removal. ^creffpublic _{a creffett franchise} (talk to the boss) 17:59, 16 January 2020 (UTC)

In which case it's just a missing parameter. I'll get that updated. -- zzuuzz ^(talk) 18:01, 16 January 2020 (UTC)

And hey, messages should really follow the pattern MediaWiki:Abusefilter-warning- or MediaWiki:Abusefilter-disallowed- because the abuse filter interface messages also begin with MediaWiki:Abusefilter-, plus they won't get listed in the dropdowns if they don't follow this pattern. -- zzuuzz ^(talk) 18:08, 16 January 2020 (UTC)

Ah, okay, didn't realize that it's a manual process to update the "filters using" list. Thanks!

Separately: abusefilter-warning-local-link is indeed supposed to be used by 1016 but doesn't look like the filter was set to warn. Anyone mind adding that? Or is further discussion needed? ^creffpublic _{a creffett franchise} (talk to the boss) 18:25, 16 January 2020 (UTC)

Facepalm . @Creffett: Meant to do that a while ago, but forgot. Thanks for the ping, and

Done. Suffusion of Yellow (talk) 21:03, 17 January 2020 (UTC)

Speaking about ones I know most about, Abusefilter-disallowed-BLP is used by 1008, which I've now marked. I have found several uses for Abusefilter-warning-spambot-allowed over the years. I don't believe it's in use at this moment, but I think it was in the last year. Likewise, Abusefilter-warning-throttled (not listed) is potentially re-usable. I think I've used them both in about 3 or 4 different filters. Abusefilter-warning-malformed is no longer useful. -- zzuuzz ^(talk) 18:01, 16 January 2020 (UTC)

Regarding the filters of the messages that don't meet naming conventions, it seems like each associated filter has been inactive for many years. I think that deletion would be appropriate. In fact, I think most of them should be deleted save for:

MediaWiki:Abusefilter-top100, MediaWiki:Abusefilter-disallowed-BLP and MediaWiki:Abusefilter-unexplained-removal: I found the associated filter and both it and warning are still active.
MediaWiki:Abusefilter-warning-repeated-characters/MediaWiki:Abusefilter-warning-nospaces/MediaWiki:Abusefilter-warning-AfC-MfD-submissions, MediaWiki:Abusefilter-warning-spambot-allowed and MediaWiki:Abusefilter-warning-remove-csd: As it was only recently removed from the filter, by Galobtter and There'sNoTime respectively, but if they aren't needed anymore deletion is OK.
MediaWiki:Abusefilter-warning-local-link: Was created on request by Suffusion of Yellow, I take we might still want it.
MediaWiki:Abusefilter-warning-researchgate: Recently created by JzG, along with never activated filter.
MediaWiki:Abusefilter-warning-spambot-allowed: If it can be used somewhere, it can stay.

Jo-Jo Eumerus (talk) 19:45, 16 January 2020 (UTC)

@Jo-Jo Eumerus: MediaWiki:Abusefilter-warning-local-link is now in use. Suffusion of Yellow (talk) 21:03, 17 January 2020 (UTC)

Anyone disagree with deleting the obsolete ones? Jo-Jo Eumerus (talk) 10:29, 19 January 2020 (UTC)

Nothing immediately jumps out, but I find this format confusing. Would it be an idea to list the messages to be deleted, or strike the messages which aren't going to be deleted? -- zzuuzz ^(talk) 11:39, 19 January 2020 (UTC)

Thanks, I've had a closer look. Again nothing immediately jumps out and I've no personal knowledge of any potential problems. However, I'd be tempted to wait for more opinions, to consider consulting with relevant editors, to double-check by scanning the filter list, and to exercise your own good judgment (and some of those filters might want a review at some point). -- zzuuzz ^(talk) 22:20, 21 January 2020 (UTC)

Probably best to wait, indeed. Most of the messages/filters are years old. Jo-Jo Eumerus (talk) 10:14, 22 January 2020 (UTC)

It's been a week, so I've applied G6 deletion to these listed above. If someone needs any of them back they can ask the usual ways. Jo-Jo Eumerus (talk) 20:39, 29 January 2020 (UTC)

Names filter addition

I'm hoping there's an existing filter that helps block people that like to add their names to articles. I've been dealing with a probably younger editor that likes to add his name to various Pakistani film and TV show articles for over a year now. The name they are adding is "Qayyum Ansari", and the most recent targets are Meray Paas Tum Ho and Ardaas Karaan (film). They're pretty persistent, hop IP across a pretty wide band and while semi-protection is an option, it would end up being fairly long-term protection from their history. I'm using a search that I run periodically for the name [19] and the annoying thing is that Raza Naqvi Wahi comes up with apparently a valid use of the name. If such a filter exists, is this a possible option? Thanks! Ravensfire (talk) 15:14, 4 February 2020 (UTC)

Filter 1008

Special:AbuseFilter/1008 did not trap this: https://en.wikipedia.org/w/index.php?title=User_talk:117.219.220.183&diff=939595091&unhide=1(admin only). Anyone expert in "norm" able to explain this? Is it worth looking at the filter? Guy (help!) 14:38, 7 February 2020 (UTC)

My guess would be ccnorm failing to normalize all of the letters (plausible?) because the regex looks OK to me. --qedk (t 桜 c) 15:15, 7 February 2020 (UTC)

Filter adjusted. If you haven't used Debugging tools before, this is a good use of it. I see there's another request elsewhere to have this filter adjusted further - I'm not really comfortable going to that extent at this time. -- zzuuzz ^(talk) 15:30, 7 February 2020 (UTC)

Zzuuzz, thanks. The more arcane the regex gets, the more I leave it to you :-) Guy (help!) 15:54, 7 February 2020 (UTC)

Change 987 to disallow?

From a discussion with Beeblebrox at Wikipedia_talk:Template_messages/User_talk_namespace#blank_edit_requests: 987 (hist · log) warns on empty edit requests, but looking at the filter's logs, we still have about one case a day where the editor ignores the warning and publishes a blank request anyway. A non-statistically-significant random sample (i.e. me examining a dozen logged actions) didn't show any false positives. Thus, I suggest we up 987 to disallow, since I can't think of any cases where a new user would actually need to post a blank edit request. ^creffpublic _{a creffett franchise} (talk to the boss) 15:22, 23 January 2020 (UTC)

Hrm. If memory serves, there have been philosophical objections towards using disallowing filters for simple errors. If we do this, we obviously cannot use the MediaWiki:Abusefilter-disallowed warning. Jo-Jo Eumerus (talk) 15:29, 23 January 2020 (UTC)

I'm not personally familiar with those objections, but I get the sentiment - but at the same time, if that error doesn't serve a constructive purpose, then why allow it? As for the second concern, the filter has custom text at MediaWiki:abusefilter-warning-empty-edit-request, that could be tweaked slightly for a disallowed version. ^creffpublic _{a creffett franchise} (talk to the boss) 15:43, 23 January 2020 (UTC)

@Creffett: I'm not sure disallowing the good-faith edits is a good idea. What about, if the edit was the last one to the page, removing the edit request automatically by bot? Less BITEy to the user posting it than disallowing. Just an idea DannyS712 (talk) 17:11, 23 January 2020 (UTC)

DannyS712, I like that idea, agreed that it's less bitey. ^creffpublic _{a creffett franchise} (talk to the boss) 17:20, 23 January 2020 (UTC)

Interesting, I had no idea there was filter for this. If I had to guess I would theorize that people doing this have a fundamental misunderstanding of what an edit request is, they think they are asking for permission to edit the page through the protection or something like that. They obviously aren't reading and understanding the protection policy or the procedure for requesting an edit. But they probably are acting in good faith, just uninformed good faith. I like the idea of removing it, in particular if it creates a notification that the user will see telling them why it was removed. Beeblebrox (talk) 19:14, 23 January 2020 (UTC)

@Beeblebrox: To simplify the bot coding, I propose:

Add a tag to edits made
Query pages where the most recent revision has the tag
Grant the bot rollback (don't need to figure out "undo" actions)
Use a custom summary for the rollback (i.e. the notification will link to the edit, which will have an explanation)
Specify a user for the rollback, to avoid potential edit conflicts

Thoughts? DannyS712 (talk) 19:19, 23 January 2020 (UTC)

So how about this for a bot:

every $interval, bot pulls all pages with open edit requests
for each page in pages_with_edit_requests:
- if edit_request is empty and edit_request is most recent edit:
  - delete empty edit request
  - post friendly note to user's talkpage

I can code that up pretty quickly if you all like it and put in a BRFA for a new creffbot task.

Actually, what would be really helpful for that is if we could tag the edit as well as warn, then the bot can just look for new edits with the tag since it last ran. ^creffpublic _{a creffett franchise} (talk to the boss) 19:21, 23 January 2020 (UTC)

Ha, I see DannyS712 had the same idea. If you want to write it, task is all yours. ^creffpublic _{a creffett franchise} (talk to the boss) 19:22, 23 January 2020 (UTC)

@Creffett: Thanks. I'll leave this open a bit longer - are there any objections to doing this? Using rollback with a custom summary to revert addition (when the addition was the most recent edit) of an empty edit request? DannyS712 (talk) 06:25, 8 February 2020 (UTC)

TV vandal

815 (hist · log) (private)

Could someone more familiar with this vandal check if my recent change to filter 815 makes sense, and is the best way to deal with the recent FPs? I was kind of guessing the original purpose, there, and don't really know this user's MO. Pinging MusikAnimal who added the relevant bit in the first place. Suffusion of Yellow (talk) 22:02, 7 February 2020 (UTC)

@Suffusion of Yellow: This filter had multiple purposes over the years, and I apologize I haven't paid much attention to it. Special:AbuseLog/25965743 (see edit summary) is the primary vandal, who I suspect might even be a bot since the M.O. hasn't changed in the slightest after years of unsuccessful editing. The M.O. for another vandal is indeed what you are talking about in the filter notes. So I think your change makes sense and will fix a lot of problems. Thank you :) — MusikAnimal ^talk 18:20, 8 February 2020 (UTC)

Thanks, good to know! Suffusion of Yellow (talk) 19:42, 8 February 2020 (UTC)

Admin help needed at filter 1028

FIXED

Further discussion should not take place here for now. Please use WP:EFMAILING if there is anything else that is needed. --DannyS712 (talk) 01:23, 13 February 2020 (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.

1028 (hist · log)

It looks like JzG accidentally clicked the "Revoke this user's autoconfirmed status" box at 1028 . I tried to uncheck it but apparently non-admins aren't allowed to edit filters with that button checked. I'm not even sure the should be at disallow, either, but can someone at least uncheck the de-autoconfirm box? COIBot has already been hit by this (but I was allowed to restore its status, oddly). JzG doesn't seem active, right now. Suffusion of Yellow (talk) 22:08, 12 February 2020 (UTC)

Unchecked that option—it should literally never be checked. Reaper Eternal (talk) 22:12, 12 February 2020 (UTC)

@Reaper Eternal: Thanks. Perhaps we should ask the developers to disable it on enwiki, then? I think it would only take a one-line change to a config file. Suffusion of Yellow (talk) 22:23, 12 February 2020 (UTC)

It did have some potential use back in the ~2006 to ~2010 era, when page-move vandalbots were a bit of a thing, but nowadays it has pretty much no use, so I wouldn't mind if it got removed. Reaper Eternal (talk) 22:29, 12 February 2020 (UTC)

@Reaper Eternal: phab:T245094 DannyS712 (talk) 01:22, 13 February 2020 (UTC)

I also switched it to log-only (which should be the case for all new filters to check for false positives...like the one that just happened to COIBot) and to run only on non-confirmed accounts. Reaper Eternal (talk) 22:20, 12 February 2020 (UTC)

Bollocks, sorry. I disabled 1028 anyway - it's in 1026. Looks like I fumbled the save. Guy (help!) 22:59, 12 February 2020 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Filter 885

885 (hist · log) (private)

Made a change there that some might object to, on principle. Based on the logs of 884 (hist · log), it shouldn't cause many problems, in practice. I set 885 log-only in case of a typo, but plan to restore disallow status. I'm not attached to that change, so revert or adjust as needed. Suffusion of Yellow (talk) 21:47, 11 February 2020 (UTC)

Restored disallow per lack of objections. Suffusion of Yellow (talk) 21:39, 15 February 2020 (UTC)

Grant request for an AbuseFilter overhaul

Hello! I have submitted a grant proposal on meta for overhauling and modernizing the AbuseFilter extension. The goal of this proposal is to make the extension easier to maintain, with the side effects of simplifying future maintenance and easing feature additions. The grant will also cover a bugfix part and the addition of a community-requested feature (shared variables, ref T120740).

You can find the request at this link.

If you're interested in this proposal, I invite you to endorse it on meta at the page linked above. If you have any questions, you can use the talk page on meta.

Thanks, --Daimona Eaytoy (Talk) 16:13, 18 February 2020 (UTC)

Edit filters and state

General question about the edit filters - is there any way to use them to hold states? There's a recurring behavior among probably-paid editors (which I won't describe here for obvious reasons) which involves a certain pattern of edits. It's too complex to be captured in a single edit, but I'm wondering if there's some way to capture behavior across multiple edits (in general, something like "did action A five times, then action B twice, then action C"). Can describe via email if anyone wants the exact pattern I'm thinking of. Might be complex enough to be a bot task rather than a filter task, but figured I'd ask here first. ^creffpublic _{a creffett franchise} (talk to the boss) 14:54, 20 February 2020 (UTC)

@Creffett: there is a time-limited "throttle" function you can read about here: mw:Extension:AbuseFilter/Actions#Throttling; it won't handle very complicated things, more like "if they do it twice a minute, OK - if more, NOT OK". — xaosflux ^Talk 15:09, 20 February 2020 (UTC)

Xaosflux, thanks, that's what I thought. I'll probably need to go with the script/bot approach after all. creffett (talk) 23:58, 20 February 2020 (UTC)

Tweak to "bruh" in 614

Copying here from EFFPR for a little better visibility. "Bruh" was recently added to 614 . There was a false positive report here the other day where it flagged on "Bruhns" (a name). I'd suggest changing it to \bbruh\b (or maybe \bbruh+\b, I haven't looked at the filter log but I could imagine "bruhhh" being used) Courtesy ping Ohnoitsjamie since I think you added it originally. creffett (talk) 01:17, 23 February 2020 (UTC)

Good suggestion, I changed it to \bbruh+\b. Let me know if you see any more false positives on that.OhNoitsJamie ^Talk 01:52, 23 February 2020 (UTC)

Abuse filter vs edit filter

Since enwiki has decided to use "edit filter" instead of "abuse filter", I have filed some edit requests to make local versions of system messages that match this practice. While I'm sure admins watch the protected edit requests category / bot report, I thought I should crosspost here. Please see these 16 requests. Thanks, --DannyS712 (talk) 01:39, 23 February 2020 (UTC)

Doing that now. Jo-Jo Eumerus (talk) 09:37, 23 February 2020 (UTC)

AllMessages also has a number of messages with "AbuseLog"; is there a plan to update these as well? Jo-Jo Eumerus (talk) 11:18, 23 February 2020 (UTC)

Some of those certainly should be left alone, like the first one, it wouldn't make any sense if it was changed. For the most part, if these aren't regular editor facing, we shouldn't really localize them. — xaosflux ^Talk 15:36, 23 February 2020 (UTC)