Jump to content

Wikipedia:Edit filter noticeboard/Archive 7

Add links
From Wikipedia, the free encyclopedia
Archive 1←Archive 5Archive 6Archive 7Archive 8Archive 9Archive 10

1008

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)

Mediawiki:Abusefilter-disallowed-BLP doesn't have a link to 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

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)

Edit Filter Helper request (User:Tymon.r)

There does not exist a consensus to grant Tymon.r the edit filter helper right at this time. The candidate is encouraged to participate more in edit filter areas before re-requesting the right. Best, qedk (t 桜 c) 07:03, 25 February 2020 (UTC)

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

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

Hello, I am an active anti-vandal with some programming experience (and knowledge of regex). I believe I could help with handling false-positives reports, when private filters are concerned, and suggesting improvements to edit filter managers. Therefore, I am requesting to become an WP:EFH. In regard to the trust, I am an WP:XCON and I am identified to WMF. Thanks for consideration. Tymon.r Do you have any questions? 14:27, 20 February 2020 (UTC)

Tymon.r, since EFH's main purpose is granting access to private filters, which private filters are you primarily interested in working with? creffpublic a creffett franchise (talk to the boss) 14:35, 20 February 2020 (UTC)
Creffpublic, Primarily with these I could possibly properly examine while reviewing false-positive reports, thanks to my anti-vandal experience. It's hard to be specific as they're all (by definition) not public and the hit count for them is not disclosed too. As for now, I'd say: 52, 294, 820. Best, Tymon.r Do you have any questions? 15:04, 20 February 2020 (UTC)
Tymon.r, you have made an average of just over one edit per day since registering. That seems on the low side for this request. Guy (help!) 06:51, 22 February 2020 (UTC)
JzG, agreed. I cannot hide I used to be more and less active on Wikipedia and other projects. I have always dealt with vandalism, though. And for clarification, I have made an average of 5.6 edits per day since registering, having 10k+ edits overall – if edit count matters that much. Best, Tymon.r Do you have any questions? 01:34, 23 February 2020 (UTC)
Hi Tymon.r. I have seen almost no activity from you on WP:EFFPR, how are you planning to use these rights? Majavah (t/c) 23:15, 22 February 2020 (UTC)
Hi Majavah, and thanks for your question. Edit filters are great and effective tools, which are very often the Wikipedia's first line of defense against vandals and other WP:NOTHERE editors. They save the time of recent changes patrollers and make the project cleaner. As I've stated above, as a programmer and a person familiar with (advanced) regex I'd use them to suggest changes to be implemented in private filters, additionally using my anti-vandal knowledge of disruptive editing patters.
As long as my previous activity on WP:EFFP is concerned – I've recently started to review some reports, at least these related to possibly malfunctioning public filters. Before I started, I had been reviewing EFFPR archives to get a better understanding of how the cases were handled in the past. Obviously, having EFH rights would enable me to review reports regarding private filters too. Hope you find this answer satisfactory. Best, Tymon.r Do you have any questions? 01:34, 23 February 2020 (UTC)
Can you show us anything where you have helped with non-private filters? -- Amanda (aka DQ) 02:05, 23 February 2020 (UTC)
@Tymon.r: Thanks for answering. I'd like to see more involvement with edit filters before obtaining the EFH bit. Most of the reports on EFFPR are non-private and users without EFH certainly can help there. Majavah (t/c) 14:42, 23 February 2020 (UTC)
Not sure if I get a !vote here as a non-EFH/EFM, but I'm going to go with not yet. I appreciate the enthusiasm to jump right in and help, but I'd like to see more participation on the EF noticeboards/EFFPR (as Majavah suggested above) - there's plenty you can do with just the public filters. There just isn't enough participation in the relevant areas for me to evaluate whether you're sufficiently knowledgeable and trustworthy. creffett (talk) 15:12, 23 February 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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)

JzG, no objections from me. If you add it to a test filter I'd be happy to help review the results. creffett (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)

Tweak to WikiLeaks filter

Had a false positive on 1034 here. Looks like it tripped on "WikiLeaks.", that is, the word followed by a sentence-ending period. Can we narrow it to wikileaks.com, or does it exist under multiple TLDs? Ping JzG, looks like your filter. creffett (talk) 03:31, 27 February 2020 (UTC)

Creffett, it has multiple tlds, but .org and .com are the most common I think. Guy (help!) 09:23, 27 February 2020 (UTC)
JzG, all right, then how about changing the ending to something like \.\w{2,3} like you suggested for 894 above? creffpublic a creffett franchise (talk to the boss) 13:04, 27 February 2020 (UTC)
@Creffpublic: Removed what appeared to be a duplicate signature. InvalidOS (talk) 13:59, 27 February 2020 (UTC)

Review of Kudpung's edit filter manager rights

Editor says they no longer need this (and it has been removed). — xaosflux Talk 01:13, 1 March 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.

Per the final decision of the Arbitration Committee at Wikipedia:Arbitration/Requests/Case/Kudpung, Kudpung's administrator rights were removed. Since he self-granted edit filter manager rights, I am posting here per the clerk procedures to request a review of whether he should keep these rights. For the Arbitration Committee, Dreamy Jazz 🎷 talk to me | my contributions 23:11, 29 February 2020 (UTC)

  • I removed EFM from Kudpung's account. To quote WP:EFM: "The assignment of the edit filter manager user right to non-admins is highly restricted. It should only be requested by and given to highly trusted users, when there is a clear and demonstrated need for it." I'm not questioning trust, but as Kudpung has never used the right the clear and demonstrated need isn't met. Prodego talk 00:59, 1 March 2020 (UTC)

(edit conflict) The edit filter right was used at the time to examine certain filters to see how they work in relation to the developments that were taking place with all things concerned with NPP, AfC, and ORES. It is not needed needed now and no conjecture should be raised as to why I accorded my account that right. Kudpung กุดผึ้ง (talk) 01:11, 1 March 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.

Exclude userboxes in 994

I'm starting to watch 994 , it's a useful filter but I see a good number of false positives for custom userboxes with images. Could we add an exclusion to it? Maybe something like !added_lines irlike "{{\s*userbox" (or something like that). Ping MusikAnimal since you created the filter originally. creffett (talk) 03:38, 27 February 2020 (UTC)

@Creffett: I'd say checking that and then checking if it is in userspace? It seems near impossible to detect if a template is a userbox. InvalidOStalk 00:56, 2 March 2020 (UTC)
InvalidOS, pretty sure it's only catching templates in Template: space. creffett (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

I would like to split this into two parts: publisher name in the {{cite}} 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)

@JzG: Using \.\w{2,3} instead of explicitly listing the 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)
Suffusion of Yellow, that was kind of ugly and had its own issues of false positives - but maybe we can be simpler here: anything in External Links, References or Further Reading, and anything in a ref or {{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 894 (log). Guy (help!) 10:10, 4 March 2020 (UTC)

New bot at EFFPR

Hi folks, this is a notification that my bot that was discussed in Wikipedia:Edit_filter_noticeboard/Archive_6#Bot_idea_for_EFFP has recently been approved and implemented. This will cause EFFPR to be significantly shorter as handled reports will be archived more recently. --Majavah (t/c) 19:04, 6 March 2020 (UTC)

@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

Tracked in Phabricator
Task T247615

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. InvalidOStalk 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)

Special:AbuseLog/26225194

I can't figure out how this was triggered. ~~ CAPTAIN MEDUSAtalk 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 MEDUSAtalk 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)

GS alerts tagged by edit filter 602

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)

@MrClog: It is intended, GS is a community-authorized DS regime, which following from 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)

Genericusername57, agreed, ebscohost itself shouldn't be blocked, just the proxies to it. Beetstra, this was your edit, thoughts? creffett (talk) 16:20, 20 March 2020 (UTC)
@Genericusername57 and 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

WP:FOOLS. — xaosflux Talk 13:08, 2 April 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.

I'm sorry, but since when did it become proper to disguise the true purpose of an edit filter by using a misleading description? This is not remotely acceptable, and whoever is responsible needs their filter rights revoked immediately; I don't have time to look through the history. See Special:AbuseFilter/46. It is absolutely egregious that this filter has been described as "Poop" vandalism instead of 💩 vandalism. Outrageous. Home Lander (talk) 01:59, 1 April 2020 (UTC)

@Home Lander: That was the original name in 2009 - see Special:AbuseFilter/history/46/item/231 DannyS712 (talk) 02:28, 1 April 2020 (UTC)
Then maybe we should go back to the old version. Spectrum {{UV}} 2604:2000:8FC0:4:68BA:3B32:8613:8B6D (talk) 04:01, 1 April 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Filter 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)

EFH for CAPTAIN MEDUSA (2)

There is no support to grant EFH at this time. — JJMC89 (T·C) 06:58, 14 April 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.

Hello again, I am requesting edit filter helper again. Since the last request, I have been helping out WP:EF/FP/R continuously and implementing edits for the reports. I have requested some filters such as 1043 (hist · log) which prevents self-advertisement. This tool would make it quicker to respond to private filter false positives reports rather than leaving it in the queue for days. I actively monitor Special:AbuseLog as part of my anti-vandalism work, and I frequently come across private filters this would help me report users to WP:AIV quickly.

@Crow: Further more, I want to see private filter to propose updates to them, and I want to access the testing filter so I can see what will happen before requesting updates. ~~ CAPTAIN MEDUSAtalk 11:17, 2 April 2020 (UTC)
  • This still doesn't rise to what I consider "need". I won't outright oppose now, hoping others will opine, but I can't support right now either. To me, "need" implies that you are fairly hamstrung in your efforts by the lack of the permission, and from looking at your (most appreciated) help so far you are certainly not lacking for things to do. I go by the expectations held by the participants in the discussion over the creation of this permission. It was never intended to be like rollback where it would be one more tool to help out, but was supposed to be reserved for very specific situations where the ability to edit filters was not desirable but the helper was still unduly restricted by not having it. I think someone commented that likely only a handful of people would ever get this. Again, just my opinion and I hope others will chime in. CrowCaw 16:36, 4 April 2020 (UTC)
information Administrator note not closing yet, as there has been little participation so far. — xaosflux Talk 11:59, 4 April 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Filter 1044

@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)

King of Hearts, see WP:EUPHEMISM. In most cases people link, and the links are redirects. Neither term is NPOV: the "pro-life" movement are generally silent on the death penalty and maternal deaths due to lack of afordable healthcare (with the honourable exception of consistent life ethic advocates), "pro-choice" is also 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)

Set filter 1026 to disallow?

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)

Add tag for filter 964?

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! TLOM (The Lord of Math) (Message) 04:17, 14 April 2020 (UTC)

@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)

Edit filter 1050

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)

EFH for Samuele2002

 Request withdrawn by requester. — xaosflux Talk 21:50, 1 May 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.

Hi I am admin on it.wikiversity and beta.wikiversity and I request the Edit filter helper flag to be able to improve my knowledge of filters and to take inspiration from the filters here to create them in the wiki where I am an admin to effectively fight vandalism. Thanks --Samuele2002 (talk) 00:05, 1 May 2020 (UTC)

@Samuele2002: Not sure if I get a say but, I’m not seeing much need for this right. You have not participated in any EFN or any related place if I am right. The4lines |||| (You Asked?)(What I have Done.) 01:24, 1 May 2020 (UTC)The4lines
@The4lines: The criteria for access include allowing edit filter managers / admins on other wikis to see how enwiki uses its filters, to help spread technical knowledge here to other wikis DannyS712 (talk) 01:27, 1 May 2020 (UTC)
@DannyS712: Ok, thanks for information. The4lines |||| (You Asked?) (What I have Done.) 01:29, 1 May 2020 (UTC)The4lines
General vandalism filters are public; private filters are generally for specific WP:LTAs so I don't see a reason to see them to be able to learn from enwiki filters. Galobtter (pingó mió) 01:35, 1 May 2020 (UTC)
Disregard what I said above. I now see a reason why to grant the flag per above, so I Support. The4lines |||| (You Asked?) (What I have Done.) 03:07, 1 May 2020 (UTC)The4lines
  • I'm kind of on the fence here - the projects Samuele2002 are admin on barely have any abuse filtering going on, and the requester hasn't made many updates to the filters that exist, with no updates since 2017 on their largest content project. That being said, the bar for this isn't meant to be very high, as the primary risk is that someone will inappropriately disclose things that would help vandals or harassers. Most of the things that can be used to improve knowledge of filters can be done without the private filters though. — xaosflux Talk 13:06, 1 May 2020 (UTC)
  • Question: As Galobtter said, what benefit will accessing the private filters give you? They're no more technical or special than the public filters... they simply have search terms specific to enwiki LTAs, so unless you've got the same vandals on itwikiversity they're not going to do anything for you. CrowCaw 13:40, 1 May 2020 (UTC)
  • Again disregard what I said, I misunderstood it. But after looking closer I finding less and less of a reason to grant. Like what Xaosflux said. They also have not done much stuff with the edit filters, thus not giving much need for the right. Added with that there is not (Most Likely) LTA or Lots of vandals. But I’ll leave to the experts. The4lines |||| (You Asked?) (What I have Done.) 14:28, 1 May 2020 (UTC)The4lines
Sorry I will have misunderstood the purpose of EFH, I withdraw the request. --Samuele2002 (talk) 20:54, 1 May 2020 (UTC)
No worries @Samuele2002: - but if you do have questions about filter syntax, please post them here and we'll be happy to help. — xaosflux Talk 21:50, 1 May 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.

show-abusefilter-hits.js

Hi all! Just wrote User:Enterprisey/show-abusefilter-hits (renamed to User:Enterprisey/abusefilter-diff-check). If you go a diff page and click "AbuseFilter?" in the "More" menu, it'll show whether the diff hit any filters. Enterprisey (talk!) 00:47, 3 May 2020 (UTC)

@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)

Filter 1053

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.
creffett (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)

Edit Filter 29 allowing more

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. creffett (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 CAT:CSD.) --MrClog (talk) 11:18, 28 April 2020 (UTC); 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? CrowCaw 14:25, 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)
  • (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). CrowCaw 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)

1056

I seem to have unintentionally made a filter that's excellent at catching citations of Wikipedia articles. Which noticeboards or talk pages should I tell about this? Enterprisey (talk!) 14:33, 7 May 2020 (UTC)

@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)

Connie Glynn

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 Connie Glynn. Since April 20, they have vandalized every TFA, they later move to other main page sections, and later nothing happens until the next day. As far as I know this has been added to filters because everytime they get creative just to avoid those filters. They later started using non-revdeleted edits, Wikidata links and now it's using edit filter links to avoid filters (see edit filter of 2600:1017:B00B:191F:6F97:A0AC:672A:B6B5 (talk · contribs)) and the recent history of Jerry Stiller and These Are the Voyages.... Is it possible to make invisible these filtered edits? © Tbhotch™ (en-3). 00:43, 13 May 2020 (UTC)

@Tbhotch: Only 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#Who is this LTA? and 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.
    creffett (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)
    Suffusion of Yellow, would we be restricting to articlespace? I've had issues with editors removing deletion tags in draft and userspace as well, where AC isn't as relevant. creffett (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)
    Suffusion of Yellow, ah, okay, I get what you're saying now. Agree completely. creffett (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 Special:AbuseFilter/1060 now. I hope the filter addresses both Floquenbeam's concern as well as Suffusion of Yellow's analysis. Feel free to edit and enable for logging, and perhaps merge back to Special:AbuseFilter/29 one day. I have implemented 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 User:Jhossainpinkel55. The user has blanked their userpage when it was tagged with {{db-notwebhost}}. I personally think that such blanking 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)

Filter 942

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, ◊PRAHLADbalaji (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, ◊PRAHLADbalaji (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, ◊PRAHLADbalaji (M•T•A•C) This message was left at 16:32, 16 May 2020 (UTC)

Match end of line

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)

148 To disallow

(Moved from requested edit filters)

(Creffett Black Kite) We should put 148 to disallow as any new editor is just going to disregard the warning. Signed,The4lines |||| (You Asked?) (What I have Done.) 19:33, 18 May 2020 (UTC)

  • 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. CrowCaw 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. SpicyMilkBoy (talk) 20:13, 18 May 2020 (UTC)
I've also seen people create, say, Draft:Creffett because they think that that means "creffett's draft" (instead of "a draft about creffett"). I think completely disallowing would be overkill. I don't expect high quality from most articles that this filter catches, but I think completely disallowing is overkill (and, per Crow, preventing something which isn't explicitly banned). creffett (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)

New or unregistered user blanking someone else's user or user talk page Edit filter

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://wiki.riteme.site/w/index.php?title=Special:AbuseLog&wpSearchUser=JoshGaming2003 🌸 1.Ayana 🌸 (talk) 17:18, 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)

Tagging and anti-spam filters

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)

Revising guidance on what editors EFH is useful for

WP:EFH lists "Those working with edit filters on another WMF wiki who want to learn from the English Wikipedia's experience and approach" as a reason for granting edit filter helper. In practice, this is only granted when the editor on the other wiki specifically needs access to private filters, as learning about edit filters in general can be done from public filters. Is there support for adding something like "and specifically need access to private filters, as most active filters are public"? There are occasional requests from editors on other wikis who may not realize that on enwiki filters are generally public. I also wonder if similar guidance should be added to "Those interested in helping with edit filters but who do not meet the thresholds required to be able to modify them." as in general EFH doesn't help those who want to eventually modify filters apart from granting access to Special:AbuseFilter/test. Galobtter (pingó mió) 06:18, 24 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. CrowCaw 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. creffett (talk) 17:55, 25 May 2020 (UTC)

EFH for QueerEcofeminist

 Not done this request did not gain a consensus of support. — xaosflux Talk 13:11, 27 May 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.

  • I am not planning to make any changes to the filter right away to mrwikisource, but I will gather information from here and obviously I have use of this right here first and mrwikisource would be an additional benefit. Yes to answer User:The4lines, We don't have LTA's like enwiki for sure, but as we go ahead we need to have some basic protection/mechanism to deal basic vandalism. and it's a really new project which is coming alive recently.
  • So yes, I my intention to ask for this right is to view and help here and learn from it, so that by the time mrwikisource reaches to really active mode, I can use my learnings from here in addition to vandal fighting I would be able to do here. QueerEcofeminist "cite! even if you fight"!!! [they/them/their] 17:36, 15 May 2020 (UTC)
pinging @QueerEcofeminist: Signed,The4lines |||| (You Asked?) (What I have Done.) 17:41, 15 May 2020 (UTC)
  • If you want to learn, then the public filters are more than adequate. There's nothing the private filters will give you that the public ones won't. There's no compelling need for the abilities EFH gives, so I must oppose at this time. CrowCaw 15:28, 16 May 2020 (UTC)
    Crow, I am not getting, why you guys are ignoring my first part of every argument that, I want this right to see and work here first? is that part invisible? or I am not making it enough clear? QueerEcofeminist "cite! even if you fight"!!! [they/them/their] 16:01, 16 May 2020 (UTC)
  • I've not been ignoring it, but you've done zero work with filters here. EFH is not something you just get without having a demonstrated need, and I personally don't see such a need. CrowCaw 17:58, 16 May 2020 (UTC)
    Crow, I have been using filters to find problematic edits and tagged edits while patrolling, and that's what I am asking for, permission to view, obviously you will have your own opinion on this also. Thanks for your comments QueerEcofeminist "cite! even if you fight"!!! [they/them/their] 01:25, 17 May 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.

EFM for creffett - courtesy notification

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.

Hi folks, since I've now got the admin bit, I'm planning to add +EFM to myself as well so I can do some actual work with the filters. Posting this as a courtesy notification in case anyone wants to object (I know that admins may self-grant at their discretion, but I feel more comfortable checking for objections first). I'll wait a couple of days before assigning the bit. Also, to those who remember my request for EFH six months ago - as you can see, I decided to take the easier approach of getting +sysop instead of going through the stress of requesting EFH again :) creffett (talk) 14:37, 18 May 2020 (UTC)

Creffett, Make it so. Guy (help!) 14:45, 18 May 2020 (UTC)
I second that. Signed,The4lines |||| (You Asked?) (What I have Done.) 15:02, 18 May 2020 (UTC)
Best of luck, feel free to ask questions here. — xaosflux Talk 13:12, 27 May 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.

1060 to disallow

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. @QEDK: You do have a point, but forcibly preventing experienced users from applying 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)

abusefilter-mass-test

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://wiki.riteme.site/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)

Requesting Wikipedia:Edit_filter_helper right (EEng)

 Done per the support established here. — xaosflux Talk 17:57, 27 May 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.

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

Been thinking for some time I might help out with filters, and this will let me get my toe in. Pinging User:David Eppstein, who knows my technical qualifications. EEng 02:32, 24 May 2020 (UTC)

We all know you just want to find the private filter we use to track your image "contributions" Standard question: what private filters are you interested in working with? creffett (talk) 03:28, 24 May 2020 (UTC)
This gentleman gets sufficient bulk in his diet. He has a regular expression.
None in particular. But I've been coding regexes since before they were called regexes so I suspect I could help out. I pledge to use this power only for good, never for evil. EEng 03:56, 24 May 2020 (UTC)
EFH doesn't really help if your goal is to edit filters, apart from granting access to Special:AbuseFilter/test. But anyhow, what sort of filters would be interested in creating/editing? Galobtter (pingó mió) 05:36, 24 May 2020 (UTC)
Seconded, if your intent is to work with filters, EFM is the right for you. EFH is only for tracking LTAs or similar. --qedk (t 愛 c) 05:39, 24 May 2020 (UTC)
From a discussion with Suffusion of Yellow it appears there are some performance problems with LTA defenses, and random probes into the filter log shows longstanding notes for desired improvements to filters that haven't been acted upon, so it seems help is needed. To familiarize myself with current goings-on I looked through User:MusikBot/FilterMonitor/Recent_changes but, it turns out, all but one of the filters there is private, so I thought EFH would let me learn more without anyone worrying that I might break some of the crockery, and of course there's Special:AbuseFilter/test. Assuming no one thinks I'm a security risk I thought this would be a straightforward matter. Should I have requested EFM instead? EEng 16:55, 25 May 2020 (UTC)
@Suffusion of Yellow: thoughts? Galobtter (pingó mió) 21:51, 26 May 2020 (UTC)
I support EFM and EFH, whichever EEng wants; I also see no problem with someone requesting EFH as a first step. Trusted, competent. ~ ToBeFree (talk) 08:11, 27 May 2020 (UTC)
Support EFH - long term trusted user with a clear reason and low risk. --DannyS712 (talk) 08:45, 27 May 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.

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)

Let edit filter helpers modify log-only filters?

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. CrowCaw 13:18, 1 June 2020 (UTC)
  • +1 to whatever Crow said. --qedk (t 愛 c) 19:06, 3 June 2020 (UTC)

IRC channel for EFH/EFM

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 WP:IRC yet in case the response here is "that's a dumb idea, why would you do that?" so if you want access (and are an EFH, admin, and/or EFM) just ping me on IRC or here. creffett (talk) 15:54, 1 June 2020 (UTC)

Also, if you're on the #-admins access list, you're automatically granted access to the channel. creffett (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)

LTA 1011

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)

LTA

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)

Set filter 1061 to disallow

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)
Suffusion of Yellow, looks good to me, would it be worthwhile to add an edit count check as well? creffett (talk) 23:39, 21 May 2020 (UTC)
@Creffett: Of course. Thanks for spotting that. Done. Suffusion of Yellow (talk)
@MusikAnimal, 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)

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

Date comma additions

Hi. I wrote an edit filter that should help with Wikipedia:Sockpuppet investigations/Bowtiebandit edits like Special:Diff/957361611. Of course, as I'm not an EFH at this time (my request is above and pending), I can't test it or view it if it's set to private (which may be prudent per WP:BEANS). Please let me know if I should post it below on-wiki or how I should send it to an EFM. Best, --Mdaniels5757 (talk) 18:10, 5 June 2020 (UTC)

@Mdaniels5757: You can send something to 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)

New users storing climate data in userspace

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)

Warn for section blanking

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)

EFH request by User:Mdaniels5757

Hi. I've come into a few situations where the ability to view private filters would be helpful, and would like the EFH permission to help at WP:EFFP/R. I'd also like to assist with proposing/authoring filters; although I know EFH does not give the ability to directly edit filters, this would let me test them. Best, --Mdaniels5757 (talk) 15:43, 31 May 2020 (UTC)

  • 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)

ccnorm* and rm*

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)

Gaining EFH

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". CrowCaw 16:12, 13 June 2020 (UTC)

"Hide details of this filter from public view" checked by default

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)

Is there a filter already for common vandal terms?

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)
RandomCanadian, filter 46 is a block, so there's an aversion to causing false positives. Removing the word boundary would cause things like Special:Diff/712389476 and Special:Diff/615223933 to be blocked, not to mention changes to articles like Tales from the Poop Deck, 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)

Deferred Changes

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)

Filter 1067

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? CrowCaw 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 GuyTalkContribs 21:35, 18 June 2020 (UTC)

Unreliable ancestry sites

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)

Unprivate filter 34 (log) (New or unregistered user blanking someone else's user or user talk page)?

Should edit filter 34 (log) 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 to disallow

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)

803

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)

Disallow empty edit requests

Moved from WP:EFR
 – ~ ToBeFree (talk) 04:04, 1 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. CrowCaw 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)
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)

​​​​​​​ 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... trout 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)

Facebook warn edit filter

Moved to WP:EFR
 – ProcrastinatingReader (talk) 21:10, 9 July 2020 (UTC)

Era style changes

In a recent discussion several highly respected editors have mentioned that WP:ERA 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)

Proposing we set 1071 to disallow

1071 (hist · log) Changed link from 1069 to 1071. {{reply to|Can I Log In}}'s talk page! 05:46, 2 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 RBI. Now public or private? It's possible you may have to switch it to private. {{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)

VPN filter

Hi can someone get me a filter that will block users who try to use a vpn on a wiki please? --Kreba4 (talk) 04:02, 3 July 2020 (UTC)

Open proxies and other problematic IPs are already blocked from editing (see also the meta page on it); and there are so far only 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)

Helper right request

GRANTED
[3]. Cabayi (talk) 17:17, 7 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.


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

I hereby request the edit filter helper right. Please refer to 1070 (hist · log) and the edit filter mailing list for the reason, which I'm not at liberty to disclose here given its sensitive nature. Nardog (talk) 21:15, 4 July 2020 (UTC)

Just noting to confirm that there has indeed been an email sent to the mailing list with a reason that can be considered sensitive. --DannyS712 (talk) 02:44, 5 July 2020 (UTC)
It's a reasonable need for the EFH bit. The question, of course, is whether we feel Nardog can be trusted with being able to see all of the filters (now there's an idea...being able to grant someone the ability to see individual private filters). I don't see any obvious red flags, and my gut says yes, but I'll do some due diligence tomorrow before giving a final !vote. GeneralNotability (talk) 03:30, 5 July 2020 (UTC)
  • Seems pretty unprecedented to request rights, much less rights considered as 'valuable' as EFH, without being willing to disclose any information as to why you require the right, making community vetting or scrutiny impossible. It might as well be a right given by an admin per the mailing list in that case, rather than bringing it to the noticeboard. Removal of rights, yes, often include private information and the reasons for this are often private and not disclosed, and the process for removal at WP:EFH mentions private reasons can be made in confidence, but the granting of the rights in the first place? Seems improper to grant like this. ProcrastinatingReader (talk) 06:31, 5 July 2020 (UTC)
    • I agree that this is likely unprecedented. I would suggest evaluating whether the user can be trusted, has the experience, etc. - everything except having a “Demonstrated need for access“ - with that one criterion being affected by the private information. Nardog communicated privately with existing edit filter helpers/managers, and has explained their perceived need. I haven't looked at it enough to support or oppose yet, but everything other than that one criterion can be evaluated using public information, and this one issue can be left to those with access to determine. DannyS712 (talk) 06:44, 5 July 2020 (UTC)
      • That one criteron you're asking us to ignore is the big decision maker, worth more than the rest combined. Plenty of qualified people make their request on this board and get tossed away, or told that RfA is right around the corner. Just looking at the archives for EFH requests, requests have been denied to users who can "show a demonstrated need" because apparently "their need wasn't good enough". Creffett himself could be an example of that, he was denied EFH at this board just months before he was approved overwhelmingly at RfA. Mdaniels above has a stalled request.
      I'm strongly opposed to giving rights to someone who wants them apparently based on one filter, is not an SPI clerk, cannot show technical competence and a reason for the rights. I'm not saying they don't have a reason or the competence, I'm saying the process here is entirely flawed if they cannot justify to the community, in public, why they should have the rights just like everyone else has had to do, including yourself, from EFH/EFM, admin, to CU/OS. No reason for the rights is compelling enough to ignore this transparent process. ProcrastinatingReader (talk) 07:00, 5 July 2020 (UTC)
      ProcrastinatingReader, maybe this will help - we're being secretive here because of what 1070 is doing. Nardog is aware of what it is tracking (a specific LTA) and is doing some work in tracking that LTA. If I understand correctly, Nardog is also the one who suggested that filter. This is absolutely a strange case, but I believe they have a demonstrated need to see this filter. GeneralNotability (talk) 12:53, 5 July 2020 (UTC)
      GeneralNotability, thank you. That's an acceptable explanation. I don't expect (or want) a technical rundown of 1070 in public, but the reason why one wishes to help, and what help they'll do (suggesting changes, helping make new filters, etc), is never 'private'.
      imo being able to see the logs for one filter, even if they want to help with that particular LTA, doesn't warrant the whole kit. I second what Crow said on how they could help: they can communicate with an EFM to help improve the filter, including getting logs from that EFM, and admins can do the tracking as normal afterwards. ProcrastinatingReader (talk) 17:05, 5 July 2020 (UTC)
  • For the moment, I don't think one filter's need warrants the whole kit. There is ample precedent to share single filter details and logs via email with involved users (typically EFMs from other wikis, but still...), and would not be opposed to doing so here. Ideally it should be watched by an EFM/admin who can take immediate action or who can adjust the filter as needed when the LTA strikes. CrowCaw 16:13, 5 July 2020 (UTC)
  • Oppose primarily due to invoking some cloak of secrecy here, Nardog try explaining your request better. — xaosflux Talk 19:36, 5 July 2020 (UTC)
    • @Xaosflux: Fair enough. The reason for the request is to track the activity of an LTA with a history of POV pushing and harassment and suggest adjustments to the filter should the need arise, but their behavior so far indicates they're sophisticated enough that describing them any more specifically could very well jeopardize the purpose. Consult Wugapodes, the creator of the filter, or any of the admins I mentioned in the email if you need corroboration.
      If I need to prove I can be trusted with the whole set, then I can only hope my activity at AIV, UAA, etc. speaks for itself. Nardog (talk) 21:38, 5 July 2020 (UTC)
      • @Nardog: thank you for the update, strike the oppose; somewhat neutral that the need for just you to track one LTA isn't that persuasive - any of the admins should be able to deal with something like that. — xaosflux Talk 21:55, 5 July 2020 (UTC)
  • Obvious support from me as I suggested Nardog request EFH to help me with 1070. Perhaps this is not a typical request, but it is within our existing policy. Drafting 1070 would be much easier if the person who knows the LTA best can see it and its logs. I've only known about this LTA for a few days, and I don't have a great grasp on what is and is not a false positive. Crow is correct that ideally [1070] should be watched by an EFM/admin who can take immediate action or who can adjust the filter as needed, but to my knowledge that confluence of LTA knowledge and user rights doesn't exist. The next best option is granting Nardog EFH. Of course I could email Nardog the regex and log hits periodically, but that seems like far more work for essentially the same outcome as granting EFH. The request is for read access, so the potential harm is him disclosing the contents of a private filter. Given his track record on the project, I don't believe that will happen. Tl;dr: Support because my job would be made easier if Nardog had EFH. — Wug·a·po·des​ 04:06, 6 July 2020 (UTC)
  • The EF Requests page has a long history of non-EFM/EFH posting requests and keeping updated as to hits and misses. The same has been done to the EF Mailing list for things too sensitive to post publicly. In the case we have here, that's all EFH is going to buy anyway as the details will still need to be sent to an EFM to tune the filter. Sending diffs of the LTA to the list along with a summary description will quickly make it clear how he works, as well as making FPs obvious for tuning out of the filter. In addition to seeing logs, one also needs to know the quirks of how the filter engine works; right now 1070 is almost all false positives just based on the search entered not taking into acount what the filter does at the basic level. CrowCaw 14:22, 6 July 2020 (UTC)
Would an uninvovled admin close this please? — xaosflux Talk 18:54, 23 July 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Filter 11 made a oopsie

On Apple Inc. litigation, a IP made a legitimate addition to the article complete with a reliable source, but it was tagged with "possible vandalism" by filter 11 according to the IP's filter log. I think it has something to do with Fortnite being included in the filter. Can an edit filter manager investigate for me? Thank you. SuperGoose007 (Honk!) 00:58, 14 August 2020 (UTC)

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 Izno at WP:VPT
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)
@Arjayay: so are the "bad edits" we want to stop mostly editors adding these links to existing articles, is it something that is only happening during certain moves, is it only happening during new page creation, etc? Once it is quite clear when the filter would apply, and what the condition(s) are that it would need to apply to - it can be requested at 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. CrowCaw 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)

(edit conflict) @Arjayay and Xaosflux: I did not look at the history as I was doing clean up, but the ones I fixed are all in my contributions. I noticed a few that occurred multiple times, most particularly links to Draft:Jose Perez (actor). These now link to the non-existent Jose Perez (actor), and"what links here" shows some 10 articles linking to that page. These seem to be largely introduced by Perrydigm 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:
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

@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:-
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)
@DESiegel: I think you have enough examples, go ahead an list at 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.

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)
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.
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Edit_filter_noticeboard/Archive_7&oldid=1236358947"