Wikipedia:Edit filter noticeboard/Archive 7

This is an archive of past discussions. 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 talk page.

Archive 1

←

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

I broke this, leading to about a minute's worth of false positives. I fixed it now. Sorry. I did test, I do not know why the error didn't show up. The sneaky vandal is working hard to get round the filter. Guy (help!) 13:43, 18 February 2020 (UTC)

WP:EF/FP, so most went unreported. JzG, you may find User:Suffusion of Yellow/effp-helper.js of use. Suffusion of Yellow (talk) 20:21, 18 February 2020 (UTC)

Thank you, and I will add a link to the message. Guy (help!) 22:15, 18 February 2020 (UTC)

@JzG: Went through the most recent 100. Most that weren't the usual vandalism, spam, and incompetence to be found in any batch of edits had fortunately already been made, but I still needed to make about 17. Want to pick up where I stopped? Suffusion of Yellow (talk) 01:03, 19 February 2020 (UTC)

And took care of the rest. Was a good excuse to rewrite effp-helper anyway... Suffusion of Yellow (talk) 00:29, 25 February 2020 (UTC)

Moved 1008 to 1033

• 1008 (hist · log) (private)
• 1033 (hist · log) (private)

I've moved the conditions from 1008 to 1033 and renamed 1008. I don't like the idea of "US politics BLP issue" in the filter log of those >100 people who were hit by this. If you've been watching the log of 1008, please update. Suffusion of Yellow (talk) 01:30, 19 February 2020 (UTC)

Suffusion of Yellow, that is a good thing you did there. The first few visible log entries relate to the original issue, if they are suppressed as all earlier entries were then I guess we could remove the filter contents, disable it and make it public? Guy (help!) 13:23, 20 February 2020 (UTC)

This will make the historical filter contents public, so no, please don't do that. It is already disabled. -- zzuuzz ^(talk) 14:04, 20 February 2020 (UTC)

IMDB

I am minded to create a filter to trap and warn when editors attempt to add a <ref> containing either imdb.com or {{imdb}}. This is a user-edited site and not a RS, I keep finding articles with references to IMDB as if it were a reliable source. Guy (help!) 06:41, 22 February 2020 (UTC)

talk) 01:21, 23 February 2020 (UTC)

@Guy: I would probably limit such a warning to non-autoconfirmed editors (maybe non-extended confirmed if you really wanted to go hardcore), but I can imagine this could be pretty annoying for editors who follow Wikipedia:Citing IMDb. –MJL ‐Talk‐^☖ 01:31, 23 February 2020 (UTC)

JzG, it is also pretty common for some editors to create stubs on dubiously notable films based solely on IMDb information. Link to IMDb, the article's only source, is then usually placed in "External links" section. So maybe the potential filter should not be restricted only to <ref>s containing IMDb links. Tymon.r Do you have any questions? 01:43, 23 February 2020 (UTC)

Tymon.r, that was what I said, yes. Guy (help!) 10:36, 23 February 2020 (UTC)

JzG, no objections from me either. Seems like a decent idea with User:MJL's caveats. -- Alexf^(talk) 12:06, 27 February 2020 (UTC)

Had a false positive on

Creffett, it has multiple tlds, but .org and .com are the most common I think. Guy (help!) 09:23, 27 February 2020 (UTC)

talk to the boss) 13:04, 27 February 2020 (UTC)

@

talk) 13:59, 27 February 2020 (UTC)

Review of Kudpung's edit filter manager rights

I'm starting to watch

@

_talk 00:56, 2 March 2020 (UTC)

talk) 01:21, 2 March 2020 (UTC)

We obviously can't detect all userboxes but we can catch those which use {{userbox}} as a meta template. No-brainer mostly, forgot to update here but  Done. --qedk (t 桜 c) 11:52, 2 March 2020 (UTC)

• Filter 894 (log)

I would like to split this into two parts: publisher name in the {{

}} tags, and URLs. This is somewhat complicated by the fact that the urls of many of these publishers are now blacklisted, and people are responding (predictably) by removing the protocol string and formatting them as plain text rather than links. Because responding to blacklisting by not adding the link to the vanity press would be outrageous...

• selfpub := "(publisher|work)\s?[=,:]\s?(Author\s?House|Trafford\s?Publishing|iUniverse\s?|Lulu|XLibris|Edwin\s?Mellen\s?Press|Grosvenor\s?House\sd?Publishing)\b"; should trap the publishers
• selfpuburl := "\b(authorhouse|createspace|grosvenorhousepublishing|iuniverse|lulu|mellenpress|trafford|xlibris)\.\w{2,3}\b"; should trap the sites, if I have this right?

But I can't use added_links because the blacklisted ones are not added as links. I guess added_lines irlike (selfpub|selfpuburl) would work? Guy (help!) 09:56, 25 February 2020 (UTC)

@

TLDs for each site could cause FPs on filenames, e.g. these, or unrelated sites, e.g. https://www.trafford.gov.uk. Probably best to test whatever you do in a separate log-only filter for at least a few days. Suffusion of Yellow (talk) 19:47, 25 February 2020 (UTC)

Suffusion of Yellow, fair point. The big issue is that createspace has dozens of tlds. Most of them are .com only. Guy (help!) 18:22, 26 February 2020 (UTC)

@JzG: Ok, changed the others to .com (diff). Did you mean to leave out CreateSpace from the first line? I'm seeing quite a few false negatives with the current filter. Suffusion of Yellow (talk) 20:08, 26 February 2020 (UTC)

Suffusion of Yellow, no I did not. I dropped it copying from my test sandbox Guy (help!) 22:08, 26 February 2020 (UTC)

@JzG: I'm seeing a problem here. User A adds a "plain" reference, but because there's no URL or citation template, the filter doesn't catch it. For example, Special:AbuseLog/26083382 was caught by the old version of the filter, but wouldn't be now. Later, User B formats the reference using a citation template, and gets warned for something that was already on the page. For example, in Special:AbuseLog/26130647 the SPS was already there. Suffusion of Yellow (talk) 20:51, 1 March 2020 (UTC)

Suffusion of Yellow, good spot. What do you suggest? Guy (help!) 22:45, 1 March 2020 (UTC)

@JzG: It may be be best to go back to Special:AbuseFilter/history/894/item/23137 after all, unless that was causing its own problems. Suffusion of Yellow (talk) 00:46, 2 March 2020 (UTC)

cite}} tag, would be questionable. Maybe I can think of something around that. Guy (help!) 10:07, 4 March 2020 (UTC)

Blogs and personal websites

It seems to me that anything in a reference tag or citation template that links to angelfire, geocities, rootsweb, blogspot/blogger, livejournal or wordpress, should probably receive a warning like the self-published source warning in Filter 894 (log). Guy (help!) 10:10, 4 March 2020 (UTC)

• Agree Seems like a good idea to me. -- Alexf^(talk) 11:17, 4 March 2020 (UTC)

Hi folks, this is a notification that

@

Majavah: Thanks for all your work on the bot! I added __NOINDEX__ to Wikipedia:Edit filter/False positives/Rolling archive/Header, in case people use the lack of a permanent archive to as an excuse to not remove the usual "filter wouldn't let me say that John Doe is a _____ but he really is a total _____!!!!" reports. Suffusion of Yellow (talk) 22:04, 8 March 2020 (UTC)

Redirect in filter log

Hello all, I have seen a few edits on redirect pages over at the filter log (for example, Special:AbuseLog/22937940 on JFK). Instead of staying on the redirect page it redirects automatically to the target page. Is it possible to disable redirects on filter logs? -- LuK3 (Talk) 14:12, 13 March 2020 (UTC)

Phabricator task opened. I believe this would require a change to the software in order to accomplish.

_talk 14:37, 13 March 2020 (UTC)

@InvalidOS: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/579584/ should fix this. Simple tweak to specify redirect=no. Hopefully it'll be reviewed soon DannyS712 (talk) 15:27, 13 March 2020 (UTC)

I can't figure out how this was triggered. ~~ CAPTAIN MEDUSA^talk 09:29, 13 March 2020 (UTC)

The filter is entitled "User adds link containing username", and the username is simply "J". Does that help? If they add links again it's going to be quite difficult for this user to avoid the filter, until they reach the minimum edit count of 40. We could probably set a minimum length for the username, but this is probably a rare occurrence. -- zzuuzz ^(talk) 10:00, 13 March 2020 (UTC)

I think a minimum length could be a good idea, say 3-5 characters? I can't see that the filter is likely to be useful below this length anyway. Sam Walton (talk) 11:46, 13 March 2020 (UTC)

Agreed. Setting the minimum length to 3 characters would fix the problem. ~~ CAPTAIN MEDUSA^talk 12:20, 13 March 2020 (UTC)

I couldn't find any other FPs related to this in the last few hundred hits. But, the change seems harmless enough, so  Done. Suffusion of Yellow (talk) 20:40, 14 March 2020 (UTC)

Hi everyone. It appears {{gs/alert}} contains the line <!-- Derived from Template:Ds/alert --> and therefore, when added to a talk page, it is tagged by edit filter 602 (the DS alert one). Is this supposed to happen? --MrClog (talk) 22:57, 17 March 2020 (UTC)

@

WP:AC/DS compulsorily requires an editor to be made aware (see "Awareness" under AC/DS). Logging alerts by noting it on a page is annoying and people might forget it, the edit filter maintains logs for them, and serves as proof that an editor was aware or not aware (no question of "I did not alert the editor three times" or "I was never alerted"). --qedk (t 心 c) 23:38, 17 March 2020 (UTC)

Filter 892

I am very grateful to everyone who has worked on filter #892 (prevents the addition of library proxy links like dx-doi-org.ezproxy.specificlibrary.com/10.1010/12345). I recently ran into a problem with it here: I was removing the proxy part, not adding it. I believe an error was introduced in this edit: Ebscohost is a database provider like ProQuest, Gale, Project MUSE, and JSTOR. Links directly to ebscohost.com shouldn't be blocked: they lead one to a generic paywall/log-in screen, not a library-specific, useless-for-everyone-else proxy one. Cheers, gnu57 01:29, 20 March 2020 (UTC)

talk) 16:20, 20 March 2020 (UTC)

@

Creffett:, the block of search.ebscohost.com was introduced later. The link you intended for me (inside a university!) does not result in any useful data. Dirk Beetstra ^{T C} 18:25, 20 March 2020 (UTC)

Disguising the true purpose of a filter with its description

Filter 1045

I was just warned for adding a link to a blog or self-published source when I attempted to flag for speedy deletion under criterion G12 a page that had copied its text from a Wordpress site. Is there any way to possibly modify this filter to ignore edits that insert speedy deletion templates?

Thank you, Passengerpigeon (talk) 05:51, 28 March 2020 (UTC)

• I added a check for CSD templates. Crow^Caw 16:42, 4 April 2020 (UTC)

@JzG: Could you point me to any consensus suggesting that the terms "pro-life" and "pro-choice" are enjoined across Wikipedia? I see an RM establishing that "anti-abortion movement" and "abortion-rights movement" are preferred in titles, but that doesn't necessarily mean that those terms should replace every instance of "pro-life" and "pro-choice" in article text. One issue is that there is no adjectival antonym of "anti-abortion" with the same connotation; "pro-abortion" is inaccurate, "abortion-rights" cannot be used as a predicate, etc., so there is no way to express the opposite of "this politician is anti-abortion" without resorting to very cumbersome wording. -- King of ♥ ♦ ♣ ♠ 15:00, 15 April 2020 (UTC)

framing language. That's why the articles were moved. People are also now applying the euphemisms on articles on UK topics, in an attempot to frame the debate inthe same way. The UK doesn't use these terms. So, it's a common non-neutral usage and needs to be alerted. People can still go and use iot if they like, but they should at least know it's not neutral. Guy (help!) 16:19, 15 April 2020 (UTC)

And likewise it can be argued that the terms you wish to use are euphemisms for "pro-life" and "pro-choice" in order to appear NPOV (Wikipedia's version of political correctness), especially on the biographies of American politicians who describe themselves that way. My point is, it's a grey area and an edit filter warning falsely implies that it is official Wikipedia policy to avoid use of those terms. You need to get consensus before encoding your interpretation of policy in an official-looking message. -- King of ♥ ♦ ♣ ♠ 16:56, 15 April 2020 (UTC)

• Filter 1026 (hist · log) (private)
• Wikipedia:Administrators' noticeboard/IncidentArchive1029#Persistent addition of promotional content - Globe Elections UN
• Wikipedia:Edit filter/Requested/Archive 15#Globe Elections UN
• And now today: Wikipedia:Help desk#Ongoing vandalism by multiple IP addresses

Any objections? It's been log-only for almost two months, with only one FP, caused by a too-aggressive user_groups check, which I've now fixed. Suffusion of Yellow (talk) 22:40, 3 April 2020 (UTC)

• Yes I would agree. This will only get worse as political silly season ramps up. Crow^Caw 16:38, 4 April 2020 (UTC)

   Done. Suffusion of Yellow (talk) 22:08, 24 April 2020 (UTC)

Filter 964 (hist · log): AFC unsourced submissions

I believe that a tag will make life for AFC reviewers much easier to track unsourced AFC submissions which can be declined first. Thanks, and stay safe!

@Eumat114:  Done. See MediaWiki talk:tag-unsourced AFC submission and MediaWiki talk:tag-unsourced AFC submission-description and let me know if you don't like the appearance or description of the tag. Suffusion of Yellow (talk) 00:41, 25 April 2020 (UTC)

I've been testing an improvement to edit filter 1050 in edit filter 2. Over the last few hours, there haven't been any false positives, and filter 2 caught an edit that 1050 did not. Since I've not modified edit filters before, I would appreciate if regulars could review it before it's implemented to make sure I didn't screw anything up. I notified ST47, the original author, on their talk page as well. — Wug·a·po·des​ 03:48, 28 April 2020 (UTC)

• I suggested an edit, and a conceptual approach, in the comments. Crow^Caw 16:45, 28 April 2020 (UTC)

Hi all! Just wrote

@Enterprisey: Sounds like a good idea, but didn't work for me: Special:AbuseLog/25429102 -> Special:Diff/927708461, but it says no filters were hit DannyS712 (talk) 02:45, 3 May 2020 (UTC)

@Enterprisey: Looks like the abuselog entry has timestamp 2019-11-24T07:42:30Z, but the revision has timestamp 2019-11-24T07:42:29Z. In my experience, the timestamps might differ by several seconds, in either direction. Very frustrating. You can try to use the revid parameter from the abuselog, but beware of phab:T217970. Suffusion of Yellow (talk) 03:13, 3 May 2020 (UTC)

Thanks for letting me know! I used 10 seconds for the allowed delay. Enterprisey (talk!) 03:32, 3 May 2020 (UTC)

The script was renamed to User:Enterprisey/abusefilter-diff-check and now also lets you load the AbuseFilter test page, preloaded with the diff you were on. Enterprisey (talk!) 04:45, 4 May 2020 (UTC)

Running OK for a few days and most accounts on this seem to be blocked, should we set to warn? --qedk (t 愛 c) 15:41, 5 May 2020 (UTC)

@QEDK: I would object, for a few reasons:

• It trips whenever the user undoes several edits in a row, even with no intervening edits from other users. This is likely behavior from an unregistered user; they don't have access to Twinkle or rollback, so when they see several consecutive bad edits, and they don't know how to edit old revisions, they'll try to undo each of the vandal's edits, one at a time. This can be fixed by adding length(page_recent_contributors) > 0 & user_name != page_recent_contributors[0].
• It's only based on the edit summary. charmanderblue may be indef blocked, but they tripped the filter for editing a talk page section titled Unclear block and reverts to draft articles. I suppose this problem can be reduced by checking that the match isn't inside the "/**/", or restricting to article space.
• Vandal fighters will trip this filter whenever they get into an "edit war" with a vandal while waiting for a response at AIV. This is basically a
  WP:CONTEXTBOT
  problem and I don't see a solution. Yes a few false positives are inevitable for all filters, but this will give certain users an endless string of warnings to click past.

My worry is that both edit warriors and good-faith vandal-fighters will start using misleading edit summaries as a way to avoid the filter warning. This will make histories harder to read.

That said, with the first two problems fixed, it might be worth seeing how common the third problem really is. Suffusion of Yellow (talk) 18:25, 5 May 2020 (UTC)

I wasn't involved in the original discussion of the filter, so apologies if I'm suggesting anything that's already been discussed:

• Can we filter on tags for an edit? If so, I would add the "Undo" tag as an OR condition with the "summary irlike" line. We could theoretically also filter on the rollback tag, but I doubt anyone <1 month old is going to have rollback.
• Why 1 month? I generally would prefer these things be tied to account status (so perhaps extended-confirmed here) rather than an arbitrary time.
• Support Suffusion of Yellow's suggestion in their first bullet.

talk) 18:31, 5 May 2020 (UTC)

@

Creffett: That's not currently possible, is infeasible according to phab:T206490. Maybe just an is_undo variable would be simpler to implement. True rollbacks aren't even tested against any filter. Suffusion of Yellow (talk) 18:49, 5 May 2020 (UTC)

I share some of the concerns mentioned above, particularly if we're thinking about warning. Additionally, we are currently labelling something as a definitive 3RR violation when it might fall under the exceptions. I know a few IP helpful users who might trip this undoing vandalism. A more substantial concern is that this is discriminatory against IPs and new users. The filter should be evaluated as if all users were equal. Taking the example of Special:Contributions/84.10.242.48, we are labelling them as a 3RR violator, while the registered user they were having a content dispute with completely gets away with it. I think a looser 'edit-warring' filter would less bad. -- zzuuzz ^(talk) 19:06, 5 May 2020 (UTC)

• I actually intended for this to be filter to warn new editors about the existing
  WP:3RR
  policy, adding a deterrent to rapid edit warring is helpful imo, from my experience, a lot of people will stop when they are informed in a certain way that their actions are against policy. To address concerns in their order:
  • @Suffusion of Yellow: There is unfortunately no way to not base it on the summary, we cannot check tags, so yes, this is the best we have got. I guess someone will have to file a patch and work on it for several weeks to make an effective "catch-all" filter, but again, that was not my intent for the filter. Just adding, that you should add that bit if you think it will be more effective, I'm open to all improvements and suggestions.
  • New vandal fighters are especially prone to getting blocked under 3RR/edit-warring, assuming vandalism when not (as someone who faced this when I joined Wikipedia first).
  • @
    Creffett
    : I intended this to be more catch-all than just autoconfirmed, as that is a very low bar and extendedconfirmed which is a somewhat higher bar, so I took the tenure for an extended-confirmed editor with some leeway on the edits.
  • @Zzuuzz: I thought of "possible 3RR violation" but removed it for conciseness, I'll add "possible" for accuracy.
• Let me know what you all think. :) --qedk (t 愛 c) 20:08, 5 May 2020 (UTC)

  I think this definitely needs more discussion before any sort of warning or even tagging. Personally I'm not sure what's supposed to be wrong with the current standard of manually warning users/newbies when they edit war, which allows a human to evaluate edits for whether they really edit warring. (After all the standard is no blocks unless they revert even after being warned.) The current practice of manually warning new vandal fighters about AGFing on edits rather than assuming vandalism I think works fine. Galobtter (pingó mió) 22:26, 5 May 2020 (UTC)

  Agreed, logging is the best approach for now, it'll let us catch edit warring in progress and not rely on it being reported by a user who may often have an agenda. -- King of ♥ ♦ ♣ ♠ 01:43, 6 May 2020 (UTC)

• I think the majority viewpoint is that the filter is not helpful so I have deleted it (marked for "deletion" to be accurate). It can be repurposed into something more useful if anyone wants to. --qedk (t 愛 c) 09:12, 6 May 2020 (UTC)

29 (hist · log) "Removal of speedy deletion templates"

I believe that G13 should be exempted from this as well as G7. The {{db-g13}} notice stated that one can remove the tag if one wants to improve the page. Hence this should also be exempt. Eumat114 formerly TLOM (Message) 01:45, 7 May 2020 (UTC)

Sounds reasonable enough to me. Adding afc|draft|g13 to the list of exceptions in line 4 should be sufficient.

talk) 01:53, 7 May 2020 (UTC)

APK edit filter

Hello all. ferret requested an edit filter that would flag edits that add a link containing "apk" to an article. I figured I'd draft a set of conditions for the edit filter, which I did at User:MrClog/APKfilter.js. Could someone review them for any potential problems and if there are none or they are fixed, would it be a good idea to turn it into an edit filter? The way I wrote it now, it should:

• Check whether the user is autoconfirmed (if they are, the filter won't block their edit)
• Check whether the edit is made in the main namespace (other namespaces won't be filtered)
• Check whether the edit adds "https://" or "http://", and "apk"
• Check whether the edit adds a speedy deletion tag, removes an apk link and/or has WP:TW in the edit summary (which wouldn't point towards it being a rollback from page blanking or the like). If any of these conditions are met, the edit wouldn't be filtered.

(By the way, the "nowiki" begin and end line are just there to prevent the page from being listed in

; edited 13:58, 28 April 2020 (UTC)

• The regex as given is not going to do that... Plus, syntax aside, those matches as written will cause many false positives. I'm actually testing a pattern more specific to the vandal's typical pattern. @Ferret: has the vandal been active in the last week or so? Crow^Caw 14:25, 28 April 2020 (UTC)

• Apologies, Crow, I know I suggested I find these all the time but it's been a little while. A search for "mod apk" shows there's quite a bit of cleanup needed but that's another venue. (For example just found this very old one from Oct 2019 -- ferret (talk) 16:19, 28 April 2020 (UTC)

• @Crow and Ferret: I changed the regex, it should work now and produce less false positives. "apklink" is now defined as "https?://[\S]*apk[\S]*", meaning it only flags edits that contain both "http(s)://" and "apk" in the same sequence (without spaces in between). --MrClog (talk) 18:00, 28 April 2020 (UTC)

• @MrClog: Why is \S in a range? And the slashes need to be escaped. https?:\/\/.*apk will do just fine. There is ofc no guarantee that the links will contain http(s), you can build a link with //, www, a lot really. --qedk (t 愛 c) 20:54, 28 April 2020 (UTC)

• @QEDK: Thanks for the comment, I updated the regex. I think apklink := "(https?:\/\/|www\.|ww\d\.).*apk"; may fix the issue of some links not including "http(s)://". --MrClog (talk) 21:10, 28 April 2020 (UTC)

• Try apklink := "(https?:\/\/|www?\d?\.)\S*apk". Replace the \S with . if you want to test just presence of link and "apk" and not necessarily an APK link. I recommend using https://regexr.com to test and learn regex (the best way to learn is by using, and they have a very helpful cheatsheet). --qedk (t 愛 c) 21:25, 28 April 2020 (UTC)

• @QEDK: What about apklink := "(https?:\/\/|www?\d?\.)\S*\Wapk"? That way, it catches an edit if it adds a link with "apk" preceded by any non-word character (such as "/" or "-"), like this edit, but not an URL that would e.g. have "apk" in it as part of a word (like napkin). --MrClog (talk) 21:49, 28 April 2020 (UTC)
• @QEDK: I decided to change the filter a bit. It now filters any link with "apk" in it. To prevent the issue above of some words having including "apk", I have added a line that filters the only words with "apk" in it I could find online. --MrClog (talk) 11:47, 29 April 2020 (UTC)

• @MrClog: Most of the conditions are extraneous, for e.g. why are you ensuring that removed_lines do not contain it, we are only checking if the link was added, similarly checking for Twinkle and deletion templates is also superfluous, since we just want to track when links are added, the words exception consideration might be useful if there's lots of FPs. I'm testing the base regex in filter 1027 for now. --qedk (t 愛 c) 14:08, 29 April 2020 (UTC)

• @QEDK: The speedy deletion exception is done to make sure that is does not tag edits that would like to the url as part of a csd template (e.g. G12). The Twinkle exception is in case someone is reverting vandalism and by doing so brings back the same link it had before, though that exception may not be necessary. Does filter 1027 have to be private? I'd be nice if I could see the results too. --MrClog (talk) 14:50, 29 April 2020 (UTC)

• The deletion one does make sense, yep. I made the filter public for now. --qedk (t 愛 c) 14:58, 29 April 2020 (UTC)

• (edit conflict) The likelihood of unconfirmed user doing a twinkle revert is probably small so would have been discounted by a prior condition. Same for CSD tagging though that's less unlikely. Also many of the splats are greedy, which can make the variable evaluation expensive. Lazying them up would help, if such additions are expected and common, though from ferret's comment this is not a common vandalism; depending on the hitcount of the test filter adding the regex to the blacklist may be a better approach. And lastly, simply looking for apk will probably result in false positives, and the vandal has a more specific pattern to flag on. BEANS though (which is why some filters are set private). Crow^Caw 15:05, 29 April 2020 (UTC)

@Crow, MrClog, and QEDK: Latest example from this morning, Apkhackers. This one is a slightly different flavor as it's less of a throw away account and represents a site directly. This one used a citation, but as you can see the text added is a ruse, as a source about a "monster hunter mod apk" has nothing to do with the statement. -- ferret (talk) 12:18, 7 May 2020 (UTC)

@Crow and Ferret: Your ping did not go through for some reason, after the latest change (adding the word boundary), Special:AbuseLog/26641596 seems to be the only FP (do check, I did a quick skim), let me know if you're all ok with setting it to disallow. --qedk (t 愛 c) 13:54, 7 May 2020 (UTC)

I looked through some of the hits now. A lot of false positives seem to be coming from India related topics. Everything that wasn't seems to have been a valid hit. It may be worth while to look for the word "mod" as well rather than just "apk". -- ferret (talk) 15:57, 7 May 2020 (UTC)

• Suggestion in filter. Crow^Caw 16:49, 7 May 2020 (UTC)

I seem to have unintentionally made a filter that's excellent at catching

@Enterprisey: I created a second, public filter, 1057 (hist · log) that's more focused on this. I suspect some of those were added by VisualEditor users. Open a page in VE, click on "Cite", then paste in a Wikipedia URL, and it'll fill in the oldid for you. Filter 1057 can probably be set to warn, or at least tag, after a while. Suffusion of Yellow (talk) 20:31, 8 May 2020 (UTC)

User:Enterprisey/abusefilter-hide-search makes the Special:AbuseLog search panel collapsible. Enterprisey (talk!) 19:21, 12 May 2020 (UTC)

@Enterprisey: see also; phab:T252584. — xaosflux ^Talk 19:34, 12 May 2020 (UTC)

(off-topic) Sad part is, their implementation at Special:Contributions is noticeably more laggy on my computer than the one this userscript uses (jquery toggle), so even if it does get done in PHP there may still be a use for this script. Enterprisey (talk!) 19:56, 12 May 2020 (UTC)

For some context (I don't know if it was already reported, but I know this person has been added to filters), the last 6 months somebody vandalized

@

WP:OVERSIGHT can hide individual log entries. I'd suggest emailing them a list. Suffusion of Yellow (talk) 00:48, 13 May 2020 (UTC)

See also

WP:AN#TFA vandal. Enterprisey (talk!) 02:01, 13 May 2020 (UTC)

Prohibit speedy deletion tag removal by page creator

The idea came up at Wikipedia_talk:Edit_warring#Possible_addition_to_3RRNO: Can we set a filter like Special:AbuseFilter/29 to "disallow" with the condition "user_name = page_first_contributor" and a proper explanatory error message? The page_first_contributor variable has poor performance according to the documentation at mw:Extension:AbuseFilter/Rules_format#Built-in_variables, but we could limit the filter to pages with a minimum page_id to prevent disruption on old pages with many revisions (noticeboards etc.). ~ ToBeFree (talk) 17:42, 14 May 2020 (UTC)

ToBeFree, I am not in a position to comment on the technical aspects of this, but if this filter would effectively prevent the author of a page from removing a CSD tag that they are not permitted to remove, then I think that would be a very elegant solution to the problem. Thank you. GirthSummit _(blether) 19:01, 14 May 2020 (UTC)

ToBeFree I agree with Girth Summit that would be a good solution to the problem. Best, Signed,The4lines |||| ^{(You Asked?) (What I have Done.)} 19:06, 14 May 2020 (UTC)

• Let's pretend I'm an established editor with lots of content creation. If some troll (an actual troll, not just someone I disagreed with) came along and put a speedy tag on one or several articles I've created, just to annoy me, I'd like to be able to remove the tag(s). Not wait until I've reported them at AIV or ANI or wherever. You'd be hard-coding in something that would forbid IAR. I have actually seen this happen before, but I don't really know how common it is. If this too edgy an edge case, I don't feel too strongly, but I do think it's worth considering. I know of several heavy content creators that I strongly suspect would raise holy hell if a filter prevents them from removing a troll SD tag. --Floquenbeam (talk) 19:17, 14 May 2020 (UTC)

  Not sure whether it would be better to just adapt 29 (as TBF linked above), but if we are going to make a new one, my thoughts:

  • Log-only at first, of course
  • Only show if user_name = page_first_contributor AND user is not extended-confirmed (probably want to bump that down to autoconfirmed when it switches to actually preventing, but I want to see some stats on whether this is a legitimate problem for AC users)
  • Same set of exceptions built into 29 - U1, G7, G13 if the discussion above about adding G13 to the exemptions goes through.

  talk) 19:34, 14 May 2020 (UTC)

  • @
    Creffett
    : EC sounds right, or maybe user_editcount < 100. Checking autoconfirmed won't help in articlespace, since they never could have created the page in the first place. :-)
  • The performance impact of page_first_contributor can be limited by making it the last check. Slowing down an edit that's going to be disallowed anyway isn't a big deal. The only other users who would be slowed down are non-EC users removing tags from pages they didn't create. That's not a common activity for non-EC users, expect for socks of the page creator of course.

  Suffusion of Yellow (talk) 19:50, 14 May 2020 (UTC)

  talk) 19:56, 14 May 2020 (UTC)

  @

  Creffett: No, I was just saying that only checking non-AC users would be effectively limiting the filter to non-articlespace, which may not be desirable. I assume the 11-edit mainspace spammers sometimes remove tags as well. Suffusion of Yellow (talk) 20:01, 14 May 2020 (UTC)

  talk) 20:04, 14 May 2020 (UTC)

• User:Floquenbeam does make a good point. Signed,The4lines |||| ^{(You Asked?) (What I have Done.)} 19:22, 14 May 2020 (UTC)
• A currently disabled filter with a first draft can be found at
  creffett's proposal from Wikipedia:Edit_filter_noticeboard#Edit_Filter_29_allowing_more in the new filter as well. ~ ToBeFree (talk) 21:02, 14 May 2020 (UTC)

  The filter is now enabled for logging, and we have a first hit at

  games the deletion process, even when done in good faith, as the resulting empty page has revisions that should normally have been deleted. Also, evading scrutiny by removing a template that attracts administrative attention to an actual issue shouldn't be possible. A user can still remove all content except the deletion tag if the filter is set to "disallow". ~ ToBeFree (talk) 22:16, 14 May 2020 (UTC)

  Floquenbeam, you make a good point about the potential for trolling. Speedies like that would naturally be declined, but I can see that it would open up a door for annoying mischief. I'd be comfortable with the filter only applying to non extended confirmed accounts, I'm confident that it would catch the vast majority of cases. The filter log already makes interesting reading. GirthSummit _(blether) 14:31, 15 May 2020 (UTC)

• Girth Summit Right, I doubt any troller wants to wait 30 days and make 500 good edits, just to do that. They might as well do some classic vandalism. And the people who really care about creating good article are EC. (Most at least) Also I have not seen any troller that is EC which makes my first point. Thanks, Signed,The4lines |||| ^{(You Asked?) (What I have Done.)} 14:39, 15 May 2020 (UTC)

  The4lines, it's not so much trolls as spammers and paid editors who do this. They're not here to vandalise anything or cause intentional disruption, they want to publish an advert without anybody noticing, and hope that by removing the tag they can stop it being deleted. I have seen some EC accounts doing this, but they're not too common - as you say, there's a certain amount of effort involved in building up an EC account, throwing that effort away by getting your account blocked is at least something of a deterrent - you mostly see it from throwaway single purpose AC accounts with precisely eleven gnomish contribs and then a shiny bit of promo. GirthSummit _(blether) 14:46, 15 May 2020 (UTC)

  Girth Summit Yeah, as AC accounts aren’t to hard to wait for which makes it the level that spammers and paid editors normally go to, as there is not that much to lose if the account gets blocked. Compared to a EC account as you said, that there is a amount of effort going in to a EC account and just to throw it out the window after it gets block is a big deterrent. Expect for the really hardcore spammers that will do anything to promote their whatever. Signed,The4lines |||| ^{(You Asked?) (What I have Done.)} 15:10, 15 May 2020 (UTC)

This filter is pointless. It only says that an admin is editing a protected page. Not sure what this filter is for, so please delete if it has no real purpose. Otherwise, please tell me what it's supposed to do. --Stay safe, ◊PRAHLAD^balaji (M•T•A•C) This message was left at 01:55, 16 May 2020 (UTC)

@Prahlad balaji: See Wikipedia:Administrators#Restoration_of_adminship. Admins can permanently lose their bit if they go inactive for a year AND haven't made an "administrative action" in five years. Most administrative actions (deleting, blocking, protecting, etc.) can be found at Special:Log. Editing a protected page is also an "administrative action" but isn't logged as such, hence the filter. That said, does anyone know if there's a better way to find this information? The filter seems like a waste of conditions/time if so. Suffusion of Yellow (talk) 02:10, 16 May 2020 (UTC)

As protection can change over time, we need something that detects and logs the edit exactly when it is made. That's what an edit filter does, without imaginable alternative. ~ ToBeFree (talk) 11:14, 16 May 2020 (UTC)

@ToBeFree: Ok, but why do you need to log protected edits? What's the purpose? --Stay safe, ◊PRAHLAD^balaji (M•T•A•C) This message was left at 14:32, 16 May 2020 (UTC)

Prahlad balaji, when an administrator is elected by the community, the administrator gets sysop privileges. Sysop privileges are required to edit protected pages. Administrators are required to use sysop privileges from time to time. If an administrator never uses the sysop privileges, the administrator loses the privileges. The filter shows us if administrators really use their sysop privileges. ~ ToBeFree (talk) 16:20, 16 May 2020 (UTC)

@ToBeFree: Thanks for letting me know. Now I really do know the purpose of this filter. --Stay safe, ◊PRAHLAD^balaji (M•T•A•C) This message was left at 16:32, 16 May 2020 (UTC)

Is there any way to match the end of a line in a regular expression in an edit filter? $ doesn't seem to work. Enterprisey (talk!) 21:01, 18 May 2020 (UTC)

@Enterprisey: Try ($|\n). added_lines is converted to one big string when used with rlike, etc. So if added_lines is really ["foo", "bar"], it will be converted to "foo\nbar" before it's tested. Suffusion of Yellow (talk) 21:08, 18 May 2020 (UTC)

@Enterprisey: Hold on minute, just \n seems to work now. So I guess it's actually becoming "foo\nbar\n". Either something changed, or I was remembering incorrectly. Suffusion of Yellow (talk) 21:11, 18 May 2020 (UTC)

Ah, time to junk my strpos monstrosity. Thanks! Enterprisey (talk!) 21:38, 18 May 2020 (UTC)

Just to add to this, the regex uses single line mode (?s) by default, so $ will match the end of the whole input string, whereas line breaks within the string contain \n. You could also try turning on multi line mode (?m) within the regex, which will make ^ and $ work on each line. I mention that for completeness but I probably wouldn't normally recommend it. -- zzuuzz ^(talk) 21:54, 18 May 2020 (UTC)

(Moved from requested edit filters)

(

• The problem with this is that we'd be effectively banning something that's not banned. While we want to know about these sorts of things (hence the Tag action), COI editing and Autobiographies are both officially "discouraged", not disallowed.
  WP:AUTOBIO even has tips for someone who insists on proceeding with an autobiography despite all the reasons on that page not to. Additionally the way 148 is built, it will catch names like "Bob from XYZ Corp" which is exactly the type of name we suggest to users who wish to edit in their own area of COI (despite all the strong discouragement we list). So no, this would be enforcing a policy that isn't there, as painful as both can be on NPP. Crow^Caw 19:53, 18 May 2020 (UTC)

Disallowing would also just encourage spammers to create a new account, making the spam harder to detect. Suffusion of Yellow (talk) 20:01, 18 May 2020 (UTC)

In addition to the issues pointed out above, an article that matches the creator's username isn't always a COI article or an autobiography. Sometimes users just name themselves after what they want to write about. I've seen it with dead people and with obviously encyclopedic subjects like animal species, for example.

talk) 20:13, 18 May 2020 (UTC)

I've also seen people create, say,

talk) 21:03, 18 May 2020 (UTC)

I'm concerned that this might discourage a good-faith editor who chose a name matching an area of interest. For example, a hypothetical User:Mill wouldn't be able to create many articles about mills. Certes (talk) 21:21, 18 May 2020 (UTC)

Maybe only disallow for new editors/IPs. Signed,The4lines |||| ^{(You Asked?) (What I have Done.)} 22:28, 19 May 2020 (UTC)

Is there a reason why New or unregistered user blanking someone else's user or user talk page is private when what it does is mentioned in the description visible to everyone see https://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=JoshGaming2003 🌸 1.Ayana 🌸 (talk) 17:18, 19 May 2020 (UTC)

• Probably because there are exceptions that could be exploited by a malicious user. Crow^Caw 17:40, 19 May 2020 (UTC)

• The definition of 'blanking' in 34 has shifted over the years since 2009. From the changes I looked at, it appears to have been adjusted to handle different kinds of vandalism while still attempting to allow legitimate changes. Since it is a heavily-used filter and gets many hits, it would not be wise to share the contents widely. EdJohnston (talk) 18:11, 19 May 2020 (UTC)

• You Might want to change the description visibility to everyone to something different as I do not think it’s a good description for a private filter as it reveals too much informatio🌸 1.Ayana 🌸 (talk) 11:46, 20 May 2020 (UTC)

I disagree; the current name helps regular editors know what is going on while not giving out the exact definition of blanking (that might allow vandals to circumvent it). EdJohnston (talk) 13:56, 20 May 2020 (UTC)

• 499 (hist · log) "Possible spambot or promotional username"
• 752 (hist · log) "Possible spamming of references"
• 935 (hist · log) ""ntsamr"-pattern spambot filter"
• 974 (hist · log) "Link-Spam catch"
• 1048 (hist · log) "Possible spam"

Right now there's no way for non-EFH/EFM/admin users to patrol the logs of any of these filters. I don't think the conditions can be refined to the point where warning or disallowing is possible. Should some, or all, of these filters start tagging? Of course there's a slight BEANS risk; spammers will be able to bring up a list of matches and try to work out what the conditions are, but does anyone think that's an acceptable risk? There's no point in logging an action if no one checks the log. Another possibility would be to combine all the private anti-spam filters under one tag; that would make it harder to figure out which edit tripped which filter. Suffusion of Yellow (talk) 19:43, 5 May 2020 (UTC)

@Suffusion of Yellow: just commenting generally, when I patrol edit filter logs here and on other wikis, I find it annoying to click on the diff links, only to find that the edits have already been reverted. What about (just an initial idea), a bot:

• Edit that is saved successfully trips one of the filters
• Bot periodically looks at edits that have tripped the filters, checks if they are the current revision, and if so, posts them to a list
• non-EFH/EFM/admin users can watch that list and revert the edits
• next time the bot runs the edit is no longer the current revision and is removed from the list

This would make it harder for comparing a list of matches, since it wouldn't say what filter it was, and would only list edits that weren't already reverted. If an admin wanted to delete the page each day to block access to the history, that would make it even harder to extract the conditions. Thoughts? DannyS712 (talk) 20:27, 5 May 2020 (UTC)

@DannyS712: Still thinking about the bot, but I created User:Suffusion of Yellow/mark-reverted.js in part to deal with that annoyance. Suffusion of Yellow (talk) 00:30, 6 May 2020 (UTC)

@DannyS712: What if instead the bot lists pages where any of the added_links are currently live on the page? That would be more useful, particularly on active pages where another editor changes the content without removing the link. It could even catch cases where the spammer's edit is disallowed, then they modify something and the edit saves without tripping any filters. Suffusion of Yellow (talk) 20:18, 12 May 2020 (UTC)

@Suffusion of Yellow: not sure that would be practical - it would require either storing the attempted links in a database or manually querying them each time DannyS712 (talk) 20:29, 12 May 2020 (UTC)

Another possibility, which could work in tandem with DannyS712's original idea. Beetstra, would it be possible for COIBot to generate reports for all the added_links in certain filter hits? In the past day, the filters mentioned above got 86, 67, 22, 2, and 56 hits respectively. Throw in a few public filters (e.g. 80 (hist · log) and 149 (hist · log)), and you might be looking at about 300 extra reports a day. Would this overload the bot? Suffusion of Yellow (talk) 21:12, 12 May 2020 (UTC)

Suffusion of Yellow, it would be possible, but I would have to write that functionality into the bot. I have been thinking about something along that lines once, maybe I should think about doing that somewhere in the near future. I'll put it on my todo list. Dirk Beetstra ^{T C} 08:18, 13 May 2020 (UTC)

@Beetstra: Thanks! No hurry of course; COIBot is already immensely useful as it is. Suffusion of Yellow (talk) 17:32, 13 May 2020 (UTC)

Circling back - any support for such a bot report? DannyS712 (talk) 07:37, 22 May 2020 (UTC)

• I would agree with this. The private filters are almost exclusively enwiki-specific, so will be of little practical use to anyone not fighting the same vandal. I would also remove some of the other presumptive entitlements (other than enwiki sysop) for various beansy reasons. Crow^Caw 13:51, 24 May 2020 (UTC)

The one thought I have is that (as far as I know, YMMV, void where prohibited) there are a few globally-useful filter concepts which are entirely locked in private filters. I'm thinking in particular of the image vandalism filters - they all have a very thorough check to identify possible image additions, but that check is probably BEANSy and the list of images is even more BEANSy.

talk) 17:55, 25 May 2020 (UTC)

Special:AbuseFilter/1060 has proven to be useful without false positives; let's set it to "disallow" as originally intended. QEDK, perhaps you could undo your modification, per the trolling concern mentioned at #Prohibit speedy deletion tag removal by page creator, and to make sure that we really have consensus. Disallowing this for experienced editors could be worth a new discussion. ~ ToBeFree (talk) 08:57, 27 May 2020 (UTC)

Additional note: On average, the filter required 0.3 conditions before, now 2. The original check was extremely performant; I guess it happened in a different filter before. ~ ToBeFree (talk) 09:01, 27 May 2020 (UTC)

You probably don't need the check for page_id > 63959834 (that extra check could actually slow the filter) since the next few checks for removal of a CSD tag would limit the number of edits for which page_first_contributor is accessed to quite few. 2 conditions and an average run time of 0.21 ms is definitely nothing to worry about. Galobtter (pingó mió) 09:20, 27 May 2020 (UTC)

Galobtter, I'm worried that the "page_first_contributor" check, as described at mw:Extension:AbuseFilter/Rules_format, may take a long time for some pages, such as (my personal interpretation) old noticeboards. The page_id check is meant to prevent abuse potential by tagging a noticeboard for speedy deletion. ~ ToBeFree (talk) 09:26, 27 May 2020 (UTC)

I don't see the abuse potential. Rollbacks bypass the edit filter anyways, extended confirmed users should definitely be excluded and so they can revert any such edits, and "slow" in the context of the abusefilter would probably mean like 500 ms or a few seconds (loading the oldest edits of ANI - [1] - is pretty fast for me). Galobtter (pingó mió) 09:33, 27 May 2020 (UTC)

(edit conflict) @ToBeFree: It's not an issue because as the last check, the number of edits which will hit it are the ones which are actually (probably) being disallowed, most edits will get filtered before reaching it. As for the sysop/extconfirmed, it's still policy to not remove CSD tags, it's entirely possible for a disagreeing admin/extconfirmed user to remove the tags for articles they create (personally I think tagging or warning for this use-case is better) but feel free to make any changes (and remove my note :) --qedk (t 愛 c) 09:34, 27 May 2020 (UTC)

I think it's a pretty bad idea to not exclude sysops or extended confirmed users because of the vandalism potential (as Floq mentions in the discussion) - not every policy violation has to be enforced with an edit filter and for established editors we can ofc warn etc if they violate policy. Galobtter (pingó mió) 09:37, 27 May 2020 (UTC)

(edit conflict) The vandalism potential exists for everyone right, not just sysops/extconfirmed, maybe a few sysops who have irked off more vandals but that's really about the only "difference". It's an arbitrary measure at best, and I'm not trying to prove you're wrong, but that vandalism is more random than we're making it out to be. :) --qedk (t 愛 c) 09:40, 27 May 2020 (UTC)

Ah, I have over-estimated the amount of time required to fetch the first contributor name on pages with a long revision history. All right; I have removed the page_id check. @

WP:IAR isn't the purpose of the filter, and does not seem to have the required consensus. At the same time, we already have 173 hits that should have resulted in "disallow" action to reduce the amount of maintenance that has been proven to exist. 173 times, someone had to manually restore the tag; it's time to let the tested filter do its job. I don't want to undo your improvement of the regex at the same time, though, and I'm a bit uncomfortable with reverting your administrative modification of my administrative creation. Would you mind restoring the EC/sysop check for now, and giving your okay for "disallow" here? ~ ToBeFree (talk) 11:18, 27 May 2020 (UTC)

@ToBeFree: Seems like you missed the last part of my message - ...but feel free to make any changes (and remove my note :) It's not a strong point of contention for me, was just explaining my viewpoint. --qedk (t 愛 c) 11:46, 27 May 2020 (UTC)

QEDK, I was referring to it, but okay, I have now restored the EC/sysop exemption myself. What do you think about disallowing? If I understand correctly, your "tagging or warning" refers to EC/sysop editors, not those affected by the current filter. ~ ToBeFree (talk) 12:06, 27 May 2020 (UTC)

(edit conflict) I don't have much opinion on this tbh, I'd say go for it - we can always reconsider if things go awry. :) --qedk (t 愛 c) 12:07, 27 May 2020 (UTC)

• On a related note, do we or should we have a filter to warn if there's an attempt to add a CSD tag to a non-userspace page with a large edit history? There's a pretty clear expectation that an article wiht a long history would normally go through XfD. Guy (help!) 11:55, 27 May 2020 (UTC)

  Interesting thought! However, as far as I know, there is no variable that contains the number of revisions a page has. See mw:Extension:AbuseFilter/Rules_format. There is "page_age", but old pages with a small history can indeed qualify for speedy deletion. ~ ToBeFree (talk) 12:04, 27 May 2020 (UTC)

• {{
  db-author}} was missing, checking for the non-existent {{db-auth}}, causing a false positive today. Let's wait a week or two again. ~ ToBeFree (talk) 14:53, 28 May 2020 (UTC)

  Further research shows that "db-auth" existed when Special:AbuseFilter/29 was created. The template was deleted in 2011; the error went unnoticed in filter 29 for over eight years. I have now fixed it there too. ~ ToBeFree (talk) 15:01, 28 May 2020 (UTC)

User:Enterprisey/abusefilter-mass-test lets you test filters with more than 100 edits. It's a little buggy, but works fine in the main use case, which is testing against all recent edits. Enterprisey (talk!) 07:27, 31 May 2020 (UTC)

@Enterprisey: cool. I'll note that, at least when I tried to use it, the logic for showing vs hiding non-matches appears to be flipped. Also, the script has a typeerror in the line elements[0].dataset.mwTs.substring( 0, 8 ); sometimes ("Cannot read property 'dataset' of undefined") - try running the script over the last 1000 edits with the pattern action = 'edit' & page_namespace == 8 and you should be able to reproduce DannyS712 (talk) 10:07, 31 May 2020 (UTC)

I think this is probably a great improvement, since not only can you test against a larger set of changes, but you can test against the same large set repeatedly as the filter is refined, or against a date range which contains a set of problematic changes from the past of a type which you want to defend against in future. (As I recall, under the prior version you just got whatever the latest 100 changes happened to be.)

Not to look a gift horse in the mouth, but a useful additional feature might be to allow testing of a pseudorandom sample within the date range. However, let's enjoy what you've already done. And if you decide to do that please talk to me, because I have some design advice. EEng 16:17, 31 May 2020 (UTC)

DannyS712, thanks for the suggestions - both have been implemented. EEng, that's also a great idea, and I would definitely like to have it. The underlying "API" is only able to do date ranges, however. So specifying a sample would be a bit wasteful, as the tests would be done on every edit anyway. If there's a use case where it would still be useful to have a sample, I'd be perfectly fine with implementing it anyway. Enterprisey (talk!) 19:26, 31 May 2020 (UTC)

@Enterprisey: You can use a query like https://en.wikipedia.org/w/api.php?action=abusefiltercheckmatch&filter=!(%22autoconfirmed%22%20in%20user_groups)&rcid=1267581277 to test a single edit. It will take 100 queries to test 100 arbitrary edits, of course, but that's not as wasteful as using /test. The question is, how many requests to send in parallel? User:Suffusion of Yellow/batchtest-plus.js uses the same module, and tries to keep 10 "in-flight" at a time. Fewer than that, and it gets tiring to wait for; sending all 100 at once seems to cause some to go missing, and is probably kind of rude anyway. Suffusion of Yellow (talk) 21:13, 31 May 2020 (UTC)

The use case -- and I'm not saying it's necessarily a significant one -- is where for some reason you want to test diffs drawn from a relatively wide time range (days? months?) but at the same time it's enough to take a small proportion of all the edits in that time range. But here's the thing: I don't understand enough (yet) about the data flow and relationship of the components to participate intelligently in a discussion of something like this, so let's put this in abeyance for now while I know more. For the record, my concern would be about the details of sampling, including how to seed the randnum generator to keep everything reproducible and yet give the user the ability to conjure up new samples when wanted; it's not hard but things need to be framed the right way. EEng 22:08, 31 May 2020 (UTC)

• Other than wikipedia-en-editfilters is there a good place to chat/ask questions behind the scenes? EEng 00:03, 28 May 2020 (UTC)

  Hitting up anyone who happens to be in IRC. — xaosflux ^Talk 16:13, 28 May 2020 (UTC)

  Sorry to be dense, but which IRC? EEng 21:00, 28 May 2020 (UTC)

  EEng, freenode. People are usually accessible in #wikipedia-en. More info at WP:IRC. Enterprisey (talk!) 23:35, 28 May 2020 (UTC)

  But for edit filter discussions aren't we supposed to use the Cone of Silence? EEng 00:07, 29 May 2020 (UTC)

Questions

If it's OK, I'll start by asking non-sensitive questions here. First: is there an easy way to test new code against more than the 100 recent changes provided for by Special:AbuseFilter/test (other than, I suppose, doing 100 over and over)? EEng 14:29, 29 May 2020 (UTC)

@EEng: Like User:Enterprisey/abusefilter-diff-check? --Mdaniels5757 (talk) 03:00, 31 May 2020 (UTC)

Thanks but though that's useful it's not what I mean. Here's what I mean: suppose one's considering adding or changing a filter. Naturally it would be reassuring to test its behavior on a large number of recent edits. Special:AbuseFilter/test will run a candidate filter against 100 recent changes, but that strikes me as a small number, especially if the filter e.g. applies only to a particular namespace. Is there a way to test against a larger set, maybe offline somewhere? This would let me fool around with filter features in complete safety. EEng 03:06, 31 May 2020 (UTC)

I'm not aware of an on-wiki way to do that but I haven't been arsed to bother applying for EFH, so I haven't actually been able to visit that page, only read the docs. I'm sure there are plenty of ways to test regex matching offwiki, and you could probably implement most of the conditionals yourself, but it would probably bee more work than it's worth. --Mdaniels5757 (talk) 03:59, 31 May 2020 (UTC)

So let me guess: the way a new or changed filter gets tested, in practice, is to start it off as log only (or whatever) so a few minutes, hours, or days (depending on the urgency of the abuse to be blocked) can go by to see whether it trips when they shouldn't, before promoting it to disallow (or whatever)? EEng 04:12, 31 May 2020 (UTC)

Ding ding ding! (also, I'm surprised I didn't earn an EEngImg from that typo :) --Mdaniels5757 (talk) 04:18, 31 May 2020 (UTC)

Yup, precisely. Honestly being able to test over 100 edits is a pretty good idea. I'll see if there's some way to write a user script to do that. The AbuseFilter API isn't that great, so my hopes aren't high. Enterprisey (talk!) 04:20, 31 May 2020 (UTC)

EEng, see #abusefilter-mass-test. Enterprisey (talk!) 07:28, 31 May 2020 (UTC)

Wow, the service around here is really quick! EEng 15:34, 31 May 2020 (UTC)

Question 2: To get me some practice, does anyone have a filter that needs some adjustment done, maybe one that kind of does the job but could use fewer false positives or negatives? EEng 15:39, 31 May 2020 (UTC)

There is certainly the queue at Wikipedia:Edit filter/False positives. — xaosflux ^Talk 02:41, 1 June 2020 (UTC)

That got me really excited, but so far it seems that there are these eager beavers fixing everything right away, leaving nothing for us newbies to do. Maybe there's some old project that's been hanging around with no one wanting to bother -- maybe something along the lines of Review filters x, y, and z to make sure they incorporate new list of ..." EEng 17:35, 1 June 2020 (UTC)

As some of the above discussions show, Special:AbuseFilter/test is crap. What if instead EFHs could create and modify log-only filters? This, I believe (ping @Daimona Eaytoy: just to be sure), could be accomplished with a only a configuration change:

1. Disable the almost-never-used blockautopromote action.
2. Mark the tag, warn, and disallow actions as "restricted".
3. Give the abusefilter-modify-restricted right to edit filter managers.
4. Give the abusefilter-modify right to edit filter helpers.

With all that done, EFHs could:

1. Create a filter in log-only mode
2. Modify a filter already set log-only

But could not:

1. Create a filter with any actions
2. Modify a filter with any actions
3. Enable or disable any actions

Nothing would change for EFMs. Admins would no longer be able to enable blockautopromote, but we haven't (intentionally) used that in years anyway. Thoughts, people? Suffusion of Yellow (talk) 22:51, 31 May 2020 (UTC)

Speaking as a lowly EFH myself, I think either someone's got the chops for writing filters or not. While clogging up the logs is an order of magnitude less serious than accidentally blocking edits (or accidentally not blocking them, for that matter) it still makes a mess. But... isn't the recent extension of /test a bit step forward? EEng 23:16, 31 May 2020 (UTC)

It doesn't feel good to rely on a (newly created, potentially buggy, unofficial, non-gadget) userscript when making this decision. The script, discussed a few sections above, is a nice idea, but it just proves the need for the proposed server change. ~ ToBeFree (talk) 01:44, 1 June 2020 (UTC)

As someone who has only recently self-assigned EFM, and who has noticed how educational the creation of a logging-only filter can be, this seems to be a reasonable proposal to me. There is no better way to prove one's suitability for EFM. EFH is restricted to users who are trusted to view hidden filters; the trust requirement behind this privilege already seems to be higher than for what is being proposed here. See also: meta:AbuseFilter for technical details. ~ ToBeFree (talk) 01:38, 1 June 2020 (UTC)

• I'm pretty opposed to this in general. EFH is meant to be a very low bar for people to help with certain use cases.
  WP:RFA is around the corner if you want to work on filters. Keep in mind that even log-only filters can have severe performance impacts if improperly created - so it's not really "read only". — xaosflux ^Talk 02:23, 1 June 2020 (UTC)

  That's pretty much what I was trying to say above. If /test isn't completely reliable, encouragement should be given to make it so. Personally I want to test my filter-writing skills in privacy to avoid humiliation. EEng 02:34, 1 June 2020 (UTC)

• @Suffusion of Yellow: What's being proposed here will work as you expect, but with unexpected side effects. The current (bad) design doesn't use $wgAbuseFilterRestrictions only as a list of actions for which you need abusefilter-modify-restricted. Instead, it's also used:
  1. For determining which actions to disable when the filter gets throttled;
  2. As a list of actions to be disabled for global filters matching a local edit, when $wgAbuseFilterDisallowGlobalLocalBlocks is true (although this doesn't affect enwiki);
  3. As a list of actions that cause "disallow" to be disabled automatically (i.e. tag+disallow would result in tag only, and disallow alone wouldn't work)

So you really cannot use this option right now. See also T175221. There's a patch under review for that task, but it should probably be refurbished and re-reviewed. Generally speaking, I suggest you make a list of what's wrong with the test interface and open a phabricator task with that, so I can try and fix the underlying issues. I cannot guarantee that I'll be able to look at it immediately, but having an idea would be great. --Daimona Eaytoy (Talk) 12:54, 1 June 2020 (UTC)

@Daimona Eaytoy: Thanks. Suspected there would be a catch, but it doesn't seem like this is getting much support anyway. I think the biggest problem with /test is basically phab:T102944, but as you say fixing it won't be easy. In fact, I'd say "nearly impossible"; where is new_wikitext supposed to come from when only new_wikitext_pst was saved in the database? Suffusion of Yellow (talk) 18:23, 3 June 2020 (UTC)

@Suffusion of Yellow: Exactly. And even for variables that we could recompute (e.g. user_groups, user_blocked, etc.) there's no easy way to do that. I think there's no real solution here; perhaps a warning box on /test; or maybe, even a complementary feature like T36180. --Daimona Eaytoy (Talk) 10:55, 4 June 2020 (UTC)

• I tend to agree with Xaosflux and EEng. I think the coding time could be better used making the Test tool more useful. As Daimona Eaytoy suggests, let's start a talk page regarding everything wrong with it, or absent features we'd like to see added. Not in favor of the original proposal, personally. Crow^Caw 13:18, 1 June 2020 (UTC)
• +1 to whatever Crow said. --qedk (t 愛 c) 19:06, 3 June 2020 (UTC)

All, per a couple recent discussions I've BOLDly created an IRC channel for private edit filter helper/manager discussions (my thought is that having real-time discussion would be better for some things, like "can I get help nailing down this private regex," than the mailing list). The channel is #wikipedia-en-editfilters, set to invite-only. I'm not advertising it at

Also, if you're on the #-admins access list, you're automatically granted access to the channel.

talk) 16:44, 1 June 2020 (UTC)

Not a dumb idea at all. EEng 20:09, 1 June 2020 (UTC)

Sounds like a good idea to me. I'm not involved enough to consider subscribing to the mailing list, but I'll add the IRC channel to my autojoin list and perhaps use it for filter-related discussion that I'd previously have had in -admins. ~ ToBeFree (talk) 23:53, 4 June 2020 (UTC)

Sorry if this isn't publically revealable, but I've seen the filter that tags edits with "LTA 1011" in the abuse log a few times and was wondering which LTA it was intended to catch. Thank you, Passengerpigeon (talk) 03:43, 5 June 2020 (UTC)

• As you may have guessed, when we name them that way it is precisely because we don't want to ID the specific LTA or LTAs. Crow^Caw 14:03, 5 June 2020 (UTC)

My regex-fu is not quite strong enough to handle this LTA: Wikipedia:Long-term abuse/Joseph kargbo. We're getting requests for page protection, and I think this is a decent case for the filter; the issue is avoiding false positives. Guy (help!) 15:07, 5 June 2020 (UTC)

• See 864, tweaked slightly. Crow^Caw 15:56, 5 June 2020 (UTC)

• Filter 1061 (hist · log) (private)

I created this filter per MusikAnimal's suggestion on the mailing list. Normally I wouldn't set a filter to disallow so quickly, but I don't think this one will have an overwhelming number of FPs. I'll keep an eye on the log, of course. Suffusion of Yellow (talk) 23:03, 21 May 2020 (UTC)

Looks good to me. Thanks! — MusikAnimal ^talk 23:14, 21 May 2020 (UTC)

talk) 23:39, 21 May 2020 (UTC)

@

Creffett: Of course. Thanks for spotting that. Done. Suffusion of Yellow (talk

)

• Can you define Line 1's vars in the notes section of the filter, for ease of easiness? Crow^Caw 13:55, 24 May 2020 (UTC)

  @Crow: Not clear what you mean. The whole notes section is a just a script that generates the filter. Suffusion of Yellow (talk) 18:22, 26 May 2020 (UTC)

@

Creffett, and Crow: Probably should note that the filter is doing something very different now, but is still set to disallow. I've tested it on 1013 (hist · log); there were a few false positives so the filter should probably be set to log-only when the LTA is inactive. Suffusion of Yellow (talk) 01:54, 8 June 2020 (UTC)

Disable filters 1040/1041?

• Filter 1040 (hist · log) "Coronavirus tracking" (public)
• Filter 1041 (hist · log) "Coronavirus tracking II" (public)

Prahlad balaji suggested at my talk page that these filters are a bit spammy. I'll admit I don't actually check the logs myself, but I had left them on, in case "someone" found them useful. Is anyone actually looking at the logs? Suffusion of Yellow (talk) 18:14, 26 May 2020 (UTC)

• I personally just skip them. It should also be noted that combined, both filters have 67,000+ hits, and most are just triggered by the words "COVID", "Coronavirus", or "COVID-19". --Stay safe, ◊PRAHLAD^balaji (M•T•A•C) This message was left at 20:26, 26 May 2020 (UTC)

  @Prahlad balaji:  Done. Suffusion of Yellow (talk) 01:57, 8 June 2020 (UTC)

​ Thank you! ◊PRAHLAD^balaji (M•T•A•C) This message was left at 14:15, 8 June 2020 (UTC)

Hi. I wrote an edit filter that should help with

@

WP:EFMAILING. Since your request above is now, technically speaking, at 100% support, you might be able to subscribe to the list soon, also. :-) Suffusion of Yellow (talk) 02:45, 8 June 2020 (UTC)

@Suffusion of Yellow:  Done. --Mdaniels5757 (talk) 16:40, 8 June 2020 (UTC)

I recently discovered that there was an edit filter for this purpose. Why is it problematic for new users to store climate data in userspace, and has this been done maliciously before? Passengerpigeon (talk) 03:24, 10 June 2020 (UTC)

The summary was "Wikipedia is being used as a webhost by an off-wiki forum for discussing fictional climate data. This should catch any new user adding the {weather box} template in userspace. (Bradv)".

I made the filter publicly viewable and disabled it. Prodego ^talk 03:50, 10 June 2020 (UTC)

Thanks for the info. I assume the abuse has stopped considering you disabled it; I do see people using Wikipedia as a webhost for fantasy worldbuilding projects from time to time, but the edit I saw that tripped the filter was a page of climateboxes from real Indian cities. Passengerpigeon (talk) 03:59, 10 June 2020 (UTC)

I have patrolled the edit filter for two months, and the thing that's annoying me the most is the section blanking filter tags the edit instead of warning. In 90% of cases, the userse is trying to vandalise, and the other 10% the user will know what they're doing and keep going. If the filter warns the user, a portion of users will not go on, and it gives us time to revert the user and issue warnings. CrazyBoy826 16:03, 11 June 2020 (UTC)

Hi. I've come into a few situations where the ability to view private filters would be helpful, and would like the

• Support Since no one else wants to comment here, apparently. OTRS and account creator permissions shows you are already trusted with private data, and while your "stats" are a bit minimal, I don't get the impression this is a collect-the-hat-and-move-on request. Suffusion of Yellow (talk) 02:05, 8 June 2020 (UTC)

• I still maintain that Helping at EFFP doesn't meet the Need requirement (imho). Not sure if I want to actually oppose due to reasons though. I'd like to see your proposed filter as below. Crow^Caw 13:40, 8 June 2020 (UTC)
  • Figured I should note up here that I did send that proposed filter to the mailing list. --Mdaniels5757 (talk) 02:45, 12 June 2020 (UTC)

Oshwah, perhaps I'm missing something but wouldn't the ccnorm* and rm* functions at mw:Extension:AbuseFilter/Rules_format#Functions be of use in simplifying Filters 51 and 53 (and possibly improve their coverage)? EEng 20:00, 1 June 2020 (UTC)

Hi EEng! Sorry for the delay responding to your question here. I initially used the ccnorm and rm functions in those filters, but I quickly realized that they do not currently map to all of the variations of letters, symbols, and numbers that LTA users have located and used in order to try and get around the filters and either create accounts or make edits without tripping them. Eventually, I was left with no choice but to add each variation manually to each letter in these filters in order for them to flag these attempts and curb the attempts by LTA users to bypass them. I would LOVE IT if I could add these missing variations and letters to those functions so that I could use them again and not have to split this filter into two different ones for them to function. But this takes a lot of time and steps to go through and implement, and its a process of doing so that requires updating that code, filing a pull request, and having others approve and apply it (to put it simply). I've been given instructions and what I need to do by MusikAnimal, and I started going through that process, but - to be honest - I'm wading through unfamiliar territory, and I just haven't gotten around to doing so. Even after I were to do this and get those changes applied, there's still the issue of needing to quickly add missing letters that they find and that I have to add to these filters to update. It's been faster for me to modify these filters and just add the letter to them than it probably would be for me to go and get those functions updated. I just need to get that process done so that I know how to do so, and streamline the process so that any changes I request in the future can get applied quickly. This would be greatly beneficial to everyone, since all filters that use those functions would begin flagging in those cases, and I could greatly reduce the complexity and size of these two filters I created (as you can obviously see, the code to these filters is an absolute wall of text that's difficult to decipher. I'd love if that could change... I just need to take into account the advantage of actually doing so vs keeping the status quo in terms of quickly being able to update it with new variations and letters that I find that these functions don't check for... ~Oshwah~^{(talk) (contribs)} 02:33, 12 June 2020 (UTC)

Continued at mailing list. EEng 03:23, 12 June 2020 (UTC)

Hello,

I am interested in potentially gaining the Edit Filter Helper right, because I would find the private filters useful for uprooting sockpuppets of long-term abusers and identifying automated spam, which I already have some experience with and enjoy doing. I am not making a formal request yet because I doubt I'd succeed; can anybody look through my contributions and tell me what I need to do next if I want to gain this right?

Thank you,

Passengerpigeon (talk) 03:04, 13 June 2020 (UTC)

• There really isn't a list of steps one takes to warrant the permission; the official criteria is Having a Need, which is somewhat (and purposefully?) vague. EFH isn't like Rollback or NPP, where it is given unless there's reason not to, but rather it is not given unless you really need it. The criteria I use is: when NOT having EFH is hindering your (or EFM's) work. Again that's a bit vague and hard to specifically define, but as Justice Stewart said, "I know it when I see it". Crow^Caw 16:12, 13 June 2020 (UTC)

Several people (including myself) on itwiki said that they would prefer the "Hide details of this filter from public view" option checked by default on Special:AbuseFilter/new. That's because it's quite easy to forget hiding a filter, which in turn could be potentially risky. I'd like to make this the default in the AbuseFilter code. However, I first want to hear some additional opinions about this. Would you be OK with this change? Is there a specific reason for keeping the option unchecked by default? Thanks, --Daimona Eaytoy (Talk) 11:55, 16 June 2020 (UTC)

It's a yes from me. -- zzuuzz ^(talk) 12:43, 16 June 2020 (UTC)

@Daimona Eaytoy: on enwiki, I don't think it will be an issue one way or other, however on small projects it might be a bad idea - they may have very little admins that touch EF's, and they may not be very active on the project. This could lead them to making private filters that don't really need to be private and making it harder for the rest of those communities to figure out what it going on in what is effectively a block. — xaosflux ^Talk 13:55, 16 June 2020 (UTC)

There is that. Maybe it could go in a $wgAbuseFilter variable, with the WMF default set to public (except enwiki, itwiki, and whichever others). After all there's nothing to stop them making all filters private anyway. I also suspect some non-WMF wikis might prefer filters to be private. -- zzuuzz ^(talk) 14:02, 16 June 2020 (UTC)

@Xaosflux: Thanks for bringing this up. I'd like to wait for more opinions, but now I see that there might be drawbacks in making the option checked by default. Of note, @Zzuuzz:, I don't really want to add a config variable for that -- it seems a bit of an overkill (although I don't feel strongly about that). The alternative would be to create a JS gadget (hidden+enabled) like this. --Daimona Eaytoy (Talk) 14:36, 16 June 2020 (UTC)

Such as references to human excrements or common insults? I wouldn't want to file a request for such an edit filter if it (surely?) already exists. RandomCanadian (talk / contribs) 19:37, 16 June 2020 (UTC)

Actually we have a dedicated 'poop' filter 46 (hist · log). Filter 39 deals with some common vandalism to university articles. We also have a few for common vandalism (maybe 260 and 384). The thing I would say is that it's not generally possible to predict every typo or variation, nor to do so without false positives, and rare cases are often not worth coding for. -- zzuuzz ^(talk) 03:52, 17 June 2020 (UTC)

@Zzuuzz: The fact is neither of those are typos; the first one has an explicit "poop" (along with vandalism/removal of a few lines from the infobox, which deserves a filter if it doesn't already have one) and the other one has "stupid" too... Maybe presence or absence of whitespace before or after the vandal words should be ignored if it isn't already? RandomCanadian (talk / contribs) 12:44, 17 June 2020 (UTC)

RandomCanadian, there is a poop filter linked above 46. But it didn't catch that edit you linked, because the filter uses a word boundary (the 'poop' in your example wasn't a separate word, but was combined into the existing one - "Bathurpoop"). ProcrastinatingReader (talk) 13:26, 17 June 2020 (UTC)

So then maybe the word boundary should be removed, as I suggested (i.e. 'presence or absence of whitespace...'). RandomCanadian (talk / contribs) 13:30, 17 June 2020 (UTC)

Flush!: The Scoop on Poop Throughout the Ages, Perl Object-Oriented Persistence, Honaunau-Napoopoo, Hawaii (or references to said articles). ProcrastinatingReader (talk) 13:52, 17 June 2020 (UTC)

Wasn't there an exemption that if "poop" is already in the old wikitext it should be allowed/whitelisted (at least that's what I get from reading the comments)? In any case, what I'm pointing at is that if the current filter doesn't deal well with word boundaries, then those should at least be tagged via a filter leaving a description such as the "possible vandalism" or the like (with of course exemptions for autoconfirmed users, which looks like it is already coded in). RandomCanadian (talk / contribs) 19:11, 17 June 2020 (UTC)

To add to what zzuuzz said, there is also 189 which catches a lot to do with BLPs. ProcrastinatingReader (talk) 13:17, 17 June 2020 (UTC)

Is there a specific reason why those filters are limited to only a subset of articles? I understand that you might want to have dedicated filters for BLPs, but adding 'poop' is vandalism in 99% of cases, in any kind of mainspace article. RandomCanadian (talk / contribs) 13:25, 17 June 2020 (UTC)

RandomCanadian, just to clarify, 189 isn't for poop, it's for other vandal terms. The filter that deals with poop is 46, and that one applies to all pages in the article namespace. ProcrastinatingReader (talk) 13:29, 17 June 2020 (UTC)

I've created a section on Wikipedia:Village pump (technical) regarding deferred changes - a method to allow edit filters (and bots and ORES) to put edits into a queue for manual review.

Would appreciate your thoughts: Deferred Changes

Thanks, ProcrastinatingReader (talk) 19:30, 17 June 2020 (UTC)

Hey folks, I've created 1067 (hist · log) (private because LTA filter), designed to catch a particular recurring LTA. It was successful during private filter testing, 0 false positives and caught a number of the LTA's accounts, so I'm wondering what to do next:

• Is it worth setting to disallow? This particular LTA doesn't seem particularly creative, but I know that disallowing usually just causes an LTA to change their pattern.
• If not disallow, should I tag? The edit filter isn't terribly helpful when private unless non-EFHs/EFMs can't see the output.
• Since this LTA is posting what appears to be somebody's personal information, their contributions usually get oversighted. Do we have any procedures for a filter to have its hits cleared out by an oversighter on a recurring basis? (that's also why you can't see any hits in my test filter; they all got the OS treatment)

GeneralNotability (talk) 19:38, 17 June 2020 (UTC)

Probably worth adding to

this list to have DatBot report hits to AIV. If you really don't want the LTA to know about it, you could potentially leave it at that. Hopefully the admin who catches it at AIV would recognise the need to report it to the oversight team. HJ Mitchell | Penny for your thoughts? 19:44, 17 June 2020 (UTC)

Neat, forgot about DatBot. Added to the list. GeneralNotability (talk) 20:08, 17 June 2020 (UTC)

• Perhaps User:DatGuy could add a condition to DatBot for this kind of thing, so the AIV report includes a request to revdel immediately, and notify oversight to suppress it entirely? Crow^Caw 13:19, 18 June 2020 (UTC)

I'll try to overhaul the /filters subpage soon. Any suggestions other than adding notes? Regarding "notify oversight," do you mean through Special:EmailUser/Oversight? Dat Guy^Talk_Contribs 21:35, 18 June 2020 (UTC)

• ancestry.com  
• genealogy.euweb.cz  

These two sites have been agreed to be unreliable for a long time, but are still being added. I propose to build a filter thus:

equals_to_any(page_namespace, 0, 118) &
( 
    deprecated := "\b((freepages|lists|mailinglists|wc)\.rootsweb\.com|ancestry\.com/(family\-tree|boards)|genealogy\.euweb\.cz)";
    added_lines irlike deprecated &
    !("bot" in user_groups) &
    !(removed_lines irlike deprecated) &
    !(summary irlike "^(Revert|rv|Undid)")
)

The eventual intent is to:

1. initially warn and check logs, then
2. enforce blocking of addition to mainspace, but
3. allow addition to other spaces (both sites may themselves cite reliable sources so may be appropriate for discussion)

I would exclude the article on ancestry.com.

Thoughts? Guy (help!) 13:36, 19 June 2020 (UTC)

Ancestry.com hosts numerous vital records and other valuable primary sources which can benefit articles as references or external links in some cases. It's not exactly accurate to say that the "site" is unreliable. I would not want to see a filter that automatically blocks everything on ancestry.com. I would support blocking any user generated content though, which I believe is the intent here? The other sites are less of a concern (to me). - MrX 🖋 18:51, 19 June 2020 (UTC)

Should edit filter 34 be public? I don't see a reason why this filter is meant to be private. I doubt it is specifically for any LTA accounts, and it is not that much different than filters 3, 30 and 33 in terms of blanking pages (all three filters are public). The only real difference is that it deals with user/user talk pages. Train of Knowledge (Talk) 07:06, 21 June 2020 (UTC)

There was a prior discussion about this in May. That filter still has a few details that appear to be targetting past vandalism and I argue that it's worth keeping Filter 34 private. More details in the prior thread. EdJohnston (talk) 13:51, 21 June 2020 (UTC)

1069 (hist · log)

Ongoing BLP concerns. Opting for a filter over semi-protection as we're probably gonna get some other updates to the article soon, in light of ongoing events. I'm not super-attached to that, though, so everyone should feel free to semi if they think it's necessary. (Log-only at the moment, will set it to disallow soon.) Enterprisey (talk!) 07:49, 24 June 2020 (UTC)

@Enterprisey For those unfamiliar with the article, would you be willing to explain the context in the notes? DannyS712 (talk) 07:57, 24 June 2020 (UTC)

Absolutely. Should have done that in the first place, thanks for the reminder. Enterprisey (talk!) 07:59, 24 June 2020 (UTC)

User:Sandbox's page ID has changed. 95.49.85.227 (talk) 21:39, 25 June 2020 (UTC)

Nice catch. Yes, it was deleted by @HickoryOughtShirt?4 and then recreated, resulting in a new page id. Its now <code>63640560</code> - can an EFM please update line 9 of the filter? DannyS712 (talk) 22:42, 25 June 2020 (UTC)

Sorry, what did I do? HickoryOughtShirt?4 (talk) 22:47, 25 June 2020 (UTC)

@HickoryOughtShirt?4 you deleted User:Sandbox - see Special:Redirect/logid/107226677 DannyS712 (talk) 22:59, 25 June 2020 (UTC)

Done. GeneralNotability (talk) 23:10, 25 June 2020 (UTC)

• Task: Warn or disallow unregistered and new users from dropping an empty edit request on a talk page.
• Reason: From a repeated
  WP:RFPP request to semiprotect Talk:TikTok where a pattern of various IPs with no pattern have been leaving multiple edit requests, leading to the talk page having been protected several times for up to a month, however I've observed similar behaviour on many pages over time. A user saving an edit with the content of Template:Submit an edit request/preload unmodified should trigger the filter, if it's possible to code a filter to do that. Preventing this specific edit would be more useful than whack-a-mole protections. Ivanvector (^Talk/_Edits) 17:09, 31 May 2020 (UTC)

• It should be able to do that. We'd probably want a custom message displayed rather than the generic "your edit was unconstructive" for good faith edits of that sort. Crow^Caw 18:23, 31 May 2020 (UTC)

This is a recurrent time-wasting problem at many other pages too. To avoid people just typing a random letter to circumvent this, maybe there should also be a minimal number of characters in the edit request – I don't know the exact number, a minimal valid request would be something like "Fix the typo in [word]" (16 + [word]); maybe like 20 or if we want to be even more lenient 10. Cheers. RandomCanadian (talk / contribs) 18:38, 31 May 2020 (UTC)

I don't think this activity is malicious, I think it's just not following instructions, possibly by non-English editors. I'd like to see how much of it goes away if just saving the default unmodified template is flagged or disallowed, before we talk about expanding the criteria. Ivanvector (^Talk/_Edits) 18:47, 31 May 2020 (UTC)

It's definitely not malicious. It's just like we regularly get non-native speakers posting their CVs at (ironically, but not accidentally)

WP:AUTOBIO -- there's something about the instructions that people misunderstand. EEng 06:19, 1 June 2020 (UTC)

• They're already being warned. 987 (hist · log), MediaWiki:abusefilter-warning-empty-edit-request. ping@Suffusion of Yellow: Someone will have to analyse the logs to see if there's any false positives before flipping the checkbox to disallow. -- zzuuzz ^(talk) 19:07, 31 May 2020 (UTC)

  @Ivanvector: Past discussion was at Wikipedia:Edit filter noticeboard/Archive_6#Change 987 to disallow?. There was some talk of a bot removing these requests, but it never went anywhere. Personally I'd no longer object to setting this to disallow; earlier I was worried about FPs, but I've been unable to find any. Suffusion of Yellow (talk) 03:41, 1 June 2020 (UTC)

  @Suffusion of Yellow: Sorry for not following up on the bot idea. If there are no false positives, I think the bot idea is better than disallow, because it would be less bitey and the bot would post a note on the user's talk pages. Do others support the bot idea? DannyS712 (talk) 05:57, 1 June 2020 (UTC)

• Perhaps the problem lies in {{Protected page text}} which is presented if someone clicks "View source" on a page protected beyond their pay grade. It offers a nice big blue inviting {{Submit an edit request}} button, but no way back. Once they've clicked on that, their options are another nice big blue inviting button "Publish changes" or a non-button red-text "Cancel" which runs counter to everything the wiki usually means by a redlink.

Altering {{Protected page text}} to offer a nice big green inviting button to take the user back to the parent page might reduce the occurrence of this error.

Altering "Cancel" across the wiki so it's a white-on-red button of equal prominence to "Publish changes" rather than a redlink may also help, not only for this problem, but in maintaining the consistent meaning of redlinks.

If this is the route by which editors are hitting this problem then, I'd say editors clicking on View source to take a look under the bonnet are at the more technically curious end of the spectrum and would be better served by an edit-filter rejection rather than a talk page message memorialising their mistake. Just my 2¢, Cabayi (talk) 07:54, 1 June 2020 (UTC)

@Cabayi: I'd be in favour of the change to {{Protected page text}}, and also in favour of disallowing empty edit requests through the edit filter. It's silly to make actual users review them, and just a waste of time overall - but of course, many people will, as you rightly point out, not be making them deliberately. This seems like a good approach to tackle the issue. Naypta ☺ | ✉ talk page | 14:30, 8 June 2020 (UTC)

• Just a quick note that because this filter would be disallowing good faith edits in other areas of the encyclopedia, it would require community consensus before implementation per
  WP:EF. Sam Walton (talk) 10:31, 1 June 2020 (UTC)
• Looks like we may need to disallow empty edit filter requests while we're at it [2]. EEng 19:02, 2 June 2020 (UTC)

​​​​​​​ This still happens. The IP here seems to have added a bunch of whitespace to evade the edit filter, while still typing a perfectly empty edit request... RandomCanadian (talk / contribs) 03:43, 8 June 2020 (UTC) Missed a few ​​​. RandomCanadian (talk / contribs) 03:45, 8 June 2020 (UTC)

@RandomCanadian: Nope - Special:AbuseLog/26948207 shows that the edit filter was tripped. Filing the BRFA now DannyS712 (talk) 03:46, 8 June 2020 (UTC)

@DannyS712:: oh, my bad, I thought it had already been enabled...  Self-trout RandomCanadian (talk / contribs) 03:47, 8 June 2020 (UTC)

BRFA filed

Please see Wikipedia:Bots/Requests for approval/DannyS712 bot 71, where I request approval to revert the empty edit requests with an informative summary --DannyS712 (talk) 03:53, 8 June 2020 (UTC)

I'm putting the above on hold until the original discussion decides what to do - if the consensus is to just not allow blank edit requests in the first place, this bot is rather pointless. Primefac (talk) 14:09, 8 June 2020 (UTC)

Could we have the filter changed to disallow, as promised? This, or any of the other recent hits, doesn't look like a false positive to me... RandomCanadian (talk / contribs) 12:40, 17 June 2020 (UTC)

Disallow would be better than revert, also remember the disallow message can be changed to something custom. One of the reasons for these empty requests may be that people think "edit request" means requesting the ability to edit the page, so it can be clarified to "request someone else make the edit you want". Naleksuh (talk) 16:55, 23 June 2020 (UTC)

Aagh... If I could edit the filter I'd go ahead and

WP:FIXIT but can't do that so commenting again so this doesn't get archived... RandomCanadian (talk / contribs) 21:39, 2 July 2020 (UTC)

EFH/EFM audit?

Hey folks, I've been thinking about this for a while, but the Nardog discussion reminded me: how do people feel about auditing the current (non-admin) EFH and EFM groups? My rationale is principle of least privilege/reduction of attack surface - by removing the perm from someone who doesn't need it, if their account is compromised it's less of a threat. I've exclude admins because a) they already have EFH powers by virtue of the admin bit, b) they can self-grant EFM at will, and c) if an admin account is compromised we have much bigger concerns. I'm open to auditing admins anyway if people want, but it just doesn't seem as useful. Outline of how I'd want to go about this:

• Mass-message EFH/EFMs saying "do you still need this permission"
  • Low bar to keeping - just "yes, I still want it" is enough
• If anyone asks for the perm to be removied or doesn't respond within, say, a month, remove the perm
• Anyone who has the perm removed through this process may get it back upon request without the full EFH/EFM vetting discussion (I hope this part will make people more willing to agree to remove the perm if they don't need it)

For reference: list of EFHs (including two admins who don't need it), list of EFMs (by my count, 11 non-admins). GeneralNotability (talk) 16:56, 6 July 2020 (UTC)

I removed the 2 redundant EFH's; we do periodic checks for 1-year inactivity on the non-admins already. I'm not too worried about requiring a continual opt-in for active users on these. — xaosflux ^Talk 18:17, 6 July 2020 (UTC)

Xaosflux, okay, that works, I wasn't aware of the existing periodic checks. GeneralNotability (talk) 18:24, 6 July 2020 (UTC)

We don't really formally document it like we do for admins and crats. — xaosflux ^Talk 18:24, 6 July 2020 (UTC)

Era style changes

In a recent discussion several highly respected editors have mentioned that

violations remain an ongoing headache. I wonder if it wouldn't make sense to filter for IPs changing established era format in a given article. For example, this might be the logic for checking for changing BCE to BC:

• (1) edit by an IP, in article space
• (2) added lines contains "BC" or "B C" or "B.C" or "B. C" [quick check that allows immediate exit in most cases]
• (3) added lines like "(\d[ ]*B[. ]*C[. ]*[^E])|(B[. ]*C[. ]*\d)" [BC or B.C. (but not BCE or B.C.E), followed or preceded by at least one digit, is being inserted]
• (4) existing article text not like (4) [article doesn't already have BC/B.C. with digits]
• (5) existing article text like "(\d[ ]*B[. ]*C[. ]*E)|(B[. ]*C[. ]*E[. ]*\d)" [article already has BCE/B.C.E. with digits]

Of course, the above would be extended to also check for BC -> BCE, AD -> CE, CE -> AD. Wouldn't be 100% effective, but should really cut down the burden. The quick check at (2) should make it cheap (though the "quick check" for the AD/CE case won't be as cheap).

Having said all the above, to avoid false positives it probably needs to ignore anything inside quote marks or templates (thus exempting quoted material and citations); do we have an established formula for that? Thoughts? EEng 20:38, 5 July 2020 (UTC)

<sound of crickets chirping> EEng 04:53, 11 July 2020 (UTC)

Not seeing any false positives lately, and the edits just keep coming... Pinging Zzuuzz, who made it. Enterprisey (talk!) 22:37, 1 July 2020 (UTC)

Did you mean 1071? :) I agree there's no real false positives. However, the vast majority of this vandalism is not and cannot be detected by this filter, so disallowing will have a negligible effect. It is more of a canary in a coal mine. In some senses, as long as this vandalism is in 'raid mode', it is best to let a page get plastered with vandalism so it can be sooner semi-protected. IMO. However the pace of vandalism is changing, and I'm on a wikibreak, so I'll leave the decision to disallow to others. -- zzuuzz ^(talk) 22:48, 1 July 2020 (UTC)

• ZERO false positives! It's very infrequent so I wouldn't imagine a swarm of false positive reports if it's set to disallow; since it's trolling vandalism, not every vandal fighter is going to
  reply to|Can I Log In}}'s talk page! 05:46, 2 July 2020 (UTC)

  It's not a particularly complex filter and there's not much more you can check for, so disallowing it now is a bit pointless. It's also not very high load, so it's not an undue burden, and a lot of the edits flagged by it were reverted by ClueBot anyway. I don't think keeping it in log is particularly problematic, it highlights IPs which may need to get blocked and pages which may need to be protected. ProcrastinatingReader (talk) 02:09, 4 July 2020 (UTC)

• The edits keep coming, so agree that it should be set to disallow --DannyS712 (talk) 13:37, 18 July 2020 (UTC)
•  Done set to diallow mode. — xaosflux ^Talk 16:34, 18 July 2020 (UTC)

Hi can someone get me a filter that will block users who try to use a vpn on a wiki please? --

very few exceptions to this. RandomCanadian (talk / contribs) 01:55, 4 July 2020 (UTC) struck comments from banned sock. PKIhistory (talk) 18:04, 23 July 2020 (UTC)

That's probably an overstatement. @Kreba4: There is no filter capable of doing this. If you could get a list of VPN addresses to put in a filter, you're better off directly blocking them instead of putting them in a filter. However, you will never get a full list of VPN addresses. -- zzuuzz ^(talk) 19:47, 5 July 2020 (UTC)

On

This is not a private filter. Apparently it was tripping because 'Fortnite' was in text that the IP added. User:Reaper Eternal has removed Fortnite from the filter per my request on User talk:Reaper Eternal/Archive 34#Filter 11 Oopsie, due to getting too many Fortnite-related false positives. EdJohnston (talk) 18:58, 14 August 2020 (UTC)

I have come here at the suggestion of

I have noticed an increasing number of links to draft articles being added in mainspace, especially after a draft has been refused, rather than trying to improve the draft. Some of the draft articles linked to are just poor attempts, but others are deliberately misleading and/or propaganda. There is, of course, no difference in colour between a link to a real article, or a draft, so the reader clicks the blue link and may well not notice the word Draft at the top of the linked page.

Izno resolved my syntax problem and produced this search which, at the time, showed 428 articles in mainspace with links to draft articles.
Could a filter be created to stop draft articles being linked-to in mainspace in the future? - Arjayay (talk) 15:03, 29 July 2020 (UTC)

@Arjayay and Izno: Any edit filter would need to be written so it did not stop moves from mainspace to draft, which create a redirect to the draft by default. These are normal, and should be promptly marked for speedy deletion. Otherwise only an admin or page mover could do draftification. I have little experience with edit filters, and i am not sure how this could be done. DES ^(talk)_{DESiegel Contribs} 15:15, 29 July 2020 (UTC)

Well, of course we don't want to stop draftification. Adding a check for "the added draft link doesn't match Draft:CurrentPageName" would suffice. GeneralNotability (talk) 16:50, 29 July 2020 (UTC)

@Arjayay: what is the sequence of events that is leading to this, for example can it be summed up as prevent edits to existing articles that contain text like "[[Draft:...]]" ? — xaosflux ^Talk 17:10, 29 July 2020 (UTC)

Xaosflux - I'm not sure what you mean by "sequence of events that is leading to this" - as clearly explained above the sequence of events was "I have noticed an increasing number of links to draft articles being added in mainspace, especially after a draft has been refused" - that led me to try and find a way of detecting such links, which led to Izno's suggestion of coming here.
You can call the filter what you like, and we can manually/AWB deal with the existing articles - indeed DES is doing that at the moment - The suggestion is to prevent such future additions, to avoid repeatedly having to carry out repeated searches and repeatedly having to deal with the results of such trawls - Arjayay (talk) 17:24, 29 July 2020 (UTC)

I can't think of other, similar formats, so I'm not sure what "contain text like "[[Draft:...]]"}}" (my bold) would include - what could usefully be included that is "like" that? My specific request is just for "include "[[Draft:...]]"}}" - Arjayay (talk) 17:31, 29 July 2020 (UTC)

To make it clear, such a filter seems reasonable in principle to me, assuming there are no technical hurdles. The AWB run is to deal with existing pages, which a filter would not catch. It would be better not to have to repeat such a run on a regular basis. It is already policy not to have such links in articles. DES ^(talk)_{DESiegel Contribs} 17:37, 29 July 2020 (UTC)

@

WP:EF/R. — xaosflux ^Talk 19:00, 29 July 2020 (UTC)

Xaosflux - You had better ask DES where the majority of these links were - he has already cleaned up most of the backlog, although he may well not have looked at the history to identify when the links were added.
Those that I have come across were generally added to existing articles - mostly NN people, bands, schools and villages being added to articles about places, cast-lists of films, music genres etc.
However, as they should not be added anywhere in main-space, except automatically when moving an immature article into draft-space, surely a "catch-all" is easier than trying to define inclusion/exclusion parameters? - Arjayay (talk) 08:52, 30 July 2020 (UTC)

In general, edit filters should be as narrow as possible so they can be fast and avoid false positives - its better that a filter is very fast and misses a few things than be slow. Some examples of the diffs that introduced the links would be great. — xaosflux ^Talk 10:56, 30 July 2020 (UTC)

I'd also be curious to know how old the oldest hit in the above search was. As in, how often does this happen and does it warrant checking every edit to the encyclopedia to stop it? If an AWB job can be run periodically to fix it, that nay be better than using a filter. Crow^Caw 13:30, 30 July 2020 (UTC)

I don't know how frequently draft links are added to articles, but it is a regularly accurring problem. I used to run a script semiregularly to remove links to drafts in articles (or transcluded templates) per

MOS:DRAFTNOLINK. I hadn't run it since December until yesterday, after seeing this thread. I removed about 90 links and noticed that DES had gotten to many of the pages before me (replag). The database replicas indicated that there were 1,764 articles with links to drafts. — JJMC89 (T·C) 00:45, 31 July 2020 (UTC)

(

i9n places where a ;link would be appropriate if this were an article rather than a dsraft. This could be simply a lack of understanding that drafts should not be linked to from articles, or it might be promotion. But since the actor seems to be retired, (last appearance in 2004, most before 2000) it does not look like ordinary promotion to me. Moreover, I suspect that this actor is in fact notable, albeit marginally. Perrydigm is not quite an SPA, but has been concentrating on this one actor in all recent edits.

a few Diffs:

• here
• here
• here
• here
• here

But these are all from one editor, and may not be typical of what other editors do. DES ^(talk)_{DESiegel Contribs} 13:54, 30 July 2020 (UTC)

@DESiegel: so from a non-technical point of view, is this really that bad? If it was a red link then readers following it would land on a page that would tell them there is a draft, requiring them to click again to read the draft. As a blue link it goes to a draft page - from a reader perspective that could be better than nothing, especially if we can better identify that drafts are early works in progress - perhaps requiring a draft banner as a namesapce notice as proposed in phab:T6469? — xaosflux ^Talk 14:12, 30 July 2020 (UTC)

Xaosflux Drafts do not, almost by definition, meet the standards for articles. Many of them are unsourced or undersourced. Many of them are promotional or biased. A majority of them are never approved. A fair number are out and out spam. We relax our standards with them in significant degree because no one but active editors ever sees them, usually only editors working on a draft and reviewers and patrollers. They are automatically NOINDEXed, so Google and other search engines do not link to them. Ordinary readers may well not understand the difference, no matter what banner is on a draft. That could become a means of SEO, if links to unapproved promotional drafts became at all common, and would require much stricter policing of drafts, reducing the change that an initially promotional draft can be converted into a valid article and reducing the value of the draft namespace overall. I do not think such links should eb allowed to stand. Whether it is better to use an edit filter, or regular AWB runs, or a bot, or perhaps some other method to remove such links, I am not sure. But I think some method of removing them should be made. DES ^(talk)_{DESiegel Contribs} 14:23, 30 July 2020 (UTC)

Agree with DES that something needs to be done, hence my original request. I know some editors create fake, or deliberately inaccurate, draft articles and then link to them in main-space. Please see this list of some of the draft articles created by just one sock-master, who then links them in mainspace as seen here and here
I don't understand the ins and outs of the different filters, if using the edit filter is seen as too "resource-heavy" could it be done via Cluebot? or would that use the same resources, under a different name? Arjayay (talk) 14:52, 30 July 2020 (UTC)

@Arjayay: yes, it is all about resource checking. Yes, this could possibly be added to something that is already checking "full text" of edits like a recent changes bot. The problem with edit filters on a project as busy as enwiki is that it is very expensive to check broad things, such as "every edit, on every article, for certain free text". Why it matters, is that when the filters get too slow - everything gets through (it overflows by not checking). This is because the filter is 'real time' and has to run inbetween someone clicking publish and before the revision is saved (something that happens a lot and needs to be fast). Recent changes bots look at edits that were already made, so they can afford to be behind and catch up - so if this is a rarer occurrence that happens in a wide area (like all article edits) that may be a better approach. It is a careful balancing act about how bad an edit is, and how often it is happening. — xaosflux ^Talk 15:29, 30 July 2020 (UTC)

(edit conflict)A filter must run on every edit, Arjayay. Therefore if it is too complex, it will slow every edit that anyone makes. A bot can run on a schedule, and uses no resources when it is not running, but must check some list of articles, rather than being triggered on each change as a filter is. Always there are tradeoffs. DES ^(talk)_{DESiegel Contribs} 15:33, 30 July 2020 (UTC)

I have now filed a formal request for this at

WP:EF/R. DES ^(talk)_{DESiegel Contribs} 21:07, 19 August 2020 (UTC)

Diffs

• Željko Burić; June 2020
• Laura_Bach; July 2020
• Russian Civil War; June 2020
• Russian_Revolution; 29 June 2020
• List of business schools in Switzerland - 30 July 2020
• List of Hindu temples in Sri Lanka - 30 July 2020
• Trondheim; 16 July 2020
• Track gauge; 12 July 2020
• Tamil Nadu Dr. M.G.R. Medical University; 30 April 2020
• The Voice (American season 18); 18 July 2020
• Saguenay–Lac-Saint-Jean; 1 June 2020
• Affective computing; 10 July 2020
• List of biographical films; 11 July 2020
• Eurovision Song Contest 1966; 15 July 2020
• The Voice (American season 18) 1 august 2020
• [https://en.wikipedia.org/w/index.php?title=Todd_Tilghman&diff=prev&oldid=970682757

• Yuli Edelstein; 21 July 2020

@Xaosflux and Crow: The above list now contains 15 difs, taken from the 230 I have already fixed (in addition to the 6 all by the same editor in the previous section). Because finding the edit that inserted the draft link requires a separate use of WikiBlame for each article, I don't see a convenient method to find all the diffs, or the date of the oldest one. I am not sure what order AWB puts its list in when not explicitly commanded to sort, so I'm not sure just how representative this selection is, but it is not all from the start of the list. I note that the oldest I have found is April 2020. I suppose that such edits are noticed and corrected when the artiles are edited for other reasons, so most would be fairly recent. But that is just speculation, I've made no attempt to find articles that used to have such links but no longer do. Is this list enough for any analysis you want to do? DES ^(talk)_{DESiegel Contribs} 20:24, 30 July 2020 (UTC)

I misunderstood DES's intent with his list - I added two links created yesterday to that list (Nos 5 + 6), and the links so-far today include:-

• Russian Civil War; 31 July 2020
• G Files awards; 31 July 2020
• 2018 South Dakota gubernatorial election, 31 July 2020
• List of criminal enterprises, gangs, and syndicates, 31 July 2020
• List of criminal enterprises, gangs, and syndicates, 31 July 2020 - same article but different editor

• List_of_criminal_enterprises,_gangs,_and_syndicates 31 July 2020
• List of political parties in the United Kingdom 31 July 2020
• 2018 United States gubernatorial elections 31 July 2020
• 2018 South Dakota gubernatorial election 31 July 2020
• Todd Tilghman 1 August 2020
• The_Voice_(American_season_18) 1 August 2020
• Jake Hoot 1 August 2020
• TaherSaifuddin, 2 August 2020
• List of programming languages 2 August 2020
• Panpsychism 2 August 2020
• Derek Slap, 2 August 2020
• Frank and Fearless (2018 film), 2 August 2020

In a couple of days we should get a very rough indication of the additions/day - Arjayay (talk) 20:04, 31 July 2020 (UTC)

@Xaosflux and Crow: I have added another 10 diffs to the list provided by Arjayay, in addition to the 15 at thye top of this sub-section. These seem to show something like 2-3 instances per day across en.Wikipedia, plus any that are reverted by other editors before I run a check. Are these diffs sufficient to decide whether, and if so how, to create an edit filter here? Is it helpful for me to continue to add to the above list. DES ^(talk)_{DESiegel Contribs} 23:13, 2 August 2020 (UTC)

Added 2 more from 2 August after the "last post" - 17 in 3 days - seems nearer 6 than 2-3 / day - Arjayay (talk) 10:32, 3 August 2020 (UTC)

@

WP:EF/R, referencing this for next steps. — xaosflux ^Talk 23:19, 2 August 2020 (UTC)

Edit Filter Helper for EggRoll97

 Request withdrawn I withdraw my request due to a general lack of responses in support or at all. — EggRoll97 ^(talk) 04:46, 24 August 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.

---

• EggRoll97 (t · th · c · del · 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)}

Prior requests:

July 2018 - Declined

February 2019 - Declined

Here I am again. I don't particularly have any kind of big statement to convince anyone, but I'm looking to be granted the edit filter helper right to be able to view private filters while helping at

the false positives page

.

The first requirement to be granted the right is a demonstrated need for access. As mentioned above, I would like to be able to handle reports involving private filters, and I've been helping at the false positives page for a while now. The second requirement is that the requester have no recent blocks or relevant sanctions. Excellent, never had a block or a sanction against me. The third is that the requester has at least a basic understanding of account security. I have already enabled 2FA through the global tester group, and have a strong password on my account. The fourth is that the requester have a basic understanding of regular expressions if the intent is to assist with authoring filters. While I do not have the intent to specifically be assisting with authoring filters, I do have a basic understanding. The fifth is sufficient understanding of the English language, which I am fluent in and is my native language. The final is to meet one of four criteria, and I meet the criteria of being a currently active extended confirmed editor.

Following the policy on requesting the userright, here's the notifications for those involved in the previous discussion: @Nihlus: @Crow: @Xaosflux:

As always, thank you to everyone who even takes the time to reply to this request. EggRoll97 ^(talk) 16:04, 14 August 2020 (UTC)

• Oppose - My statement in the last request still stands: Knowing what is in the filters is half the battle, and I am not sure you have the experience needed to handle the rest. You've made only a couple hundred edits in the last 18 months, which is not enough to demonstrate that you are experienced. Also, requesting this multiple times without substantively addressing the concerns brought up in prior requests does you no favors. Nihlus 20:24, 14 August 2020 (UTC)

The amount of edits I make should not be indicative of overall experience. EggRoll97 ^(talk) 21:14, 14 August 2020 (UTC)

•  Request withdrawn Given a general lack of support, I withdraw this. EggRoll97 ^(talk) 04:46, 24 August 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.