Jump to content

Wikipedia:Edit filter noticeboard/Archive 2

Add links
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5

Captcha + Edit Filters

Tracked in Phabricator
Task T151116

I thought this problem got fixed a while ago, but we currently have a serious issue of users who should only be warned being indefinitely bounced between an edit filter warning and the captcha. I don't have time to look into this in detail now (I just saw it happen, in person, to another user) so any help testing this would be helpful. We should probably remove the warning function of any active edit filters; they may currently be disallowing a large number of edits. Sam Walton (talk) 16:12, 19 November 2016 (UTC)

Ok it's not as bad as it seems (no need to disable any filters). Expected behaviour is that the user only needs to enter the captcha once and acknowledge the warning once. What actually happens is the user is asked to enter a captcha, enters it correctly and clicks save, gets the warning with no captcha present, then is asked to enter a 2nd captcha, and then clicking save will save the edit. Sam Walton (talk) 17:24, 19 November 2016 (UTC)

Special:AbuseFilter/808

New disallowing filter - requested at WP:EF/R -- samtar talk or stalk 18:20, 19 November 2016 (UTC)

Warnings for Possible BLP issue or vandalism

MediaWiki:Tag-possible libel or vandalism-description shows three filters, from which only 39 gives a warning from what I understand by this. Why don't the other two give a notification to the said editor triggering it? It should also be a specific notification on BLP rather than just the generic one. Ugog Nizdast (talk) 08:03, 21 November 2016 (UTC)

Community wishlist needs your votes!

The 2016 Community Wishlist voting is currently underway, and there's an AbuseFilter wish. Specifically, one to return the per-filter resource tracking that we lost some time ago. Please vote if you think this is important (which as an edit filter manager you really should!) Sam Walton (talk) 09:30, 28 November 2016 (UTC)

lowercase sigmabot III not archiving Talk:Economy of Brazil

I was looking over the edit filter log and saw that lowercase sigmabot III keeps tripping Special:AbuseFilter/702 when trying to archive Talk:Economy of Brazil. I've set up ClueBot III to archive the page. —MRD2014 (talk • contribs) 00:42, 29 November 2016 (UTC)

Replied at Wikipedia:Village pump (technical)#lowercase sigmabot III not archiving Talk:Economy of Brazil. PrimeHunter (talk) 00:51, 29 November 2016 (UTC)

Special:AbuseFilter/803

Now set to disallow with MediaWiki:abusefilter-warning-userpage set as the warning, per consensus at Wikipedia:Requests for comment/Protect user pages by default (and the talk page) — MusikAnimal talk 23:36, 30 November 2016 (UTC)

Possible issue with if statements

Please see this thread at WP:VPT relating to if statements in edit filters -- samtar talk or stalk 09:46, 3 December 2016 (UTC)

Importing private filters into another Wiki

Hello, I'm an administrator of the Romanian Wikipedia and also an abuse filter editor there, as it can be seen here. Are there any ways to import private filters into another Wiki? If not, is there any way that I can see some of them in order to adapt them to my local Wiki? Thanks in advance.Ionutzmovie (talk) 05:05, 16 November 2016 (UTC)

@Xaosflux: (et al.) Given the above and the clear understanding of filter syntax (example 1 (rowp), example 2 (rowp)) - would it be worth assigning the EFM bit (temporarily?) to allow exporting? -- samtar talk or stalk 11:23, 16 November 2016 (UTC)
It should be OK. But you could also privately email them the filters they want. Graeme Bartlett (talk) 11:53, 16 November 2016 (UTC)
Filters can be exported and imported using the filter tools, it does not matter if they are private or not. enwiki has >50 private filters and there is no local group to give "read" access to these. We certainly can email you some exports, is there a specific type of filter you are interested in? — xaosflux Talk 12:48, 16 November 2016 (UTC)
@Xaosflux:, @Graeme Bartlett:, I can't see the filters and I don't see any option locally or on en:wiki to import them. Can anybody e-mail me the filters I listed here. It would be very helpful, since we are a small comunity and many malicious edits are discovered even after years.Ionutzmovie (talk) 21:06, 23 November 2016 (UTC)
Thank you very much. I will not make any changes to en:wp filters. At ro wiki I see the same problems every day, this filters will help us a lot. I will also hide them at my local Wiki.Ionutzmovie (talk) 21:23, 23 November 2016 (UTC)
 Done removed. — xaosflux Talk 22:02, 3 December 2016 (UTC)

Special:AbuseFilter/812

Setting Special:AbuseFilter/812 to disallow edits, following some recent user talk page vandalism. Sam Walton (talk) 23:52, 3 December 2016 (UTC)

Filters 58 and 726

See Paul Eastmaner and Paul t. thomas east for adaptations around those filters. Thanks! CrowCaw 21:45, 7 December 2016 (UTC)

Adding edit notice to WP:EF/R

Hi all, could we add a mention of this template to an edit notice at Wikipedia:Edit filter/Requested? -- samtar talk or stalk 13:08, 8 December 2016 (UTC)

 Done Check it out, does that work for you? — xaosflux Talk 14:01, 8 December 2016 (UTC)
Well would you look at that... Great thank you :) -- samtar talk or stalk 21:39, 8 December 2016 (UTC)

Deferred changes testing

It is now possible to test Wikipedia:Deferred changes at http://deferred-changes.wmflabs.org. This isn't connected to SUL so you need to create an account, if you are an admin here and want admin rights to edit abuse filters there, confirm your account here. Cenarium (talk) 22:24, 8 December 2016 (UTC)

@Cenarium: I'd like to be able to test this out, could you +admin me? I'm User:NotSamtar -- samtar talk or stalk 09:48, 9 December 2016 (UTC)
@Samtar: Sure, done. Cenarium (talk) 12:31, 9 December 2016 (UTC)

Special:AbuseFilter/813

New disallowing filter -- samtar talk or stalk 20:14, 10 December 2016 (UTC)

Formatting Proposal

How about splitting the archives of EF/R to a system similar to Wikipedia:Requests for permissions/Archive? We can move the current archives to a more specific date, and I am also working on a bot to automatically archive/maintain it. Dat GuyTalkContribs 11:50, 11 December 2016 (UTC)

This seems fine. We could do basic archiving with Lowercase sigmabot III or ClueBot III, but I don't think either will allow us to separate completed/denied requests — MusikAnimal talk 19:14, 11 December 2016 (UTC)

Special:AbuseFilter/812 in disallow

We talked about this one in the mailing list. Very straightforward – blocks new users from adding over a 1 MB of content in a single edit. Edits this large are most certainly malicious, and can even crash your browser if you try to view them. Even so we may wish to create a custom notice shown instead of the normal MediaWiki:abusefilter-warning — MusikAnimal talk 22:13, 12 December 2016 (UTC)

Special:AbuseFilter/684

Temporary vandalism filter enabled and disallowing -- samtar talk or stalk 17:16, 18 December 2016 (UTC)

Special:AbuseFilter/817

In disallow — MusikAnimal talk 23:33, 20 December 2016 (UTC)

Special:AbuseFilter/820

Special:AbuseFilter/820 has been temporarily set to disallow. Sam Walton (talk) 19:48, 1 January 2017 (UTC)

Special:AbuseFilter/824

New disallowing filter, information in `Notes`, please email for information as always -- Samtar talk · contribs 20:41, 11 January 2017 (UTC)

Special:AbuseFilter/821

Disallowing — MusikAnimal talk 23:24, 12 January 2017 (UTC)

Special:AbuseFilter/739

Set to disallow. Sam Walton (talk) 10:56, 18 January 2017 (UTC)

Special:AbuseFilter/828

Not yet disallowing and public (given I don't think it's overly evadable) - thought I should get a couple more EFM's opinion on preventing IPs from redirecting talk pages. I can't think of a legitimate reason an IP would need to do this -- Samtar talk · contribs 10:49, 19 January 2017 (UTC)

I think I'd like to see what gets logged first, but I agree I can't think of a reason this should happen. Per Wikipedia:Edit filter#Recommended uses this might fall under the category of good faith edits where consensus is required, so we should wait to see if the edits are primarily vandalism or mistakes. Sam Walton (talk) 11:29, 19 January 2017 (UTC)
I'd like to have a large sample of such edits before setting it to disallow. Jo-Jo Eumerus (talk, contributions) 11:33, 19 January 2017 (UTC)
Good ideas. I have no intention of setting it to disallow before we get a good sample of edits - it was initially created to help combat these sorts of edits. If it's found that a lot of the sample are good faith mistakes (which could be rather likely!) we could always make it private and only check certain page IDs -- Samtar talk · contribs 11:44, 19 January 2017 (UTC)

Special:AbuseFilter/826

In disallow via throttling — MusikAnimal talk 13:04, 20 January 2017 (UTC)

Special:AbuseFilter/832

Set to disallow. Sam Walton (talk) 15:30, 4 February 2017 (UTC)

Special:AbuseFilter/835

Disallowing in response to hopefully shortlived vandalism -- Samtar talk · contribs 21:32, 3 February 2017 (UTC)

Disabled -- Samtar talk · contribs 10:55, 5 February 2017 (UTC)

Special:AbuseFilter/788

Older filter never set to disallow. Disallowing -- Samtar talk · contribs 10:55, 5 February 2017 (UTC)

Special:AbuseFilter/809

Disallowing — MusikAnimal talk 02:31, 13 February 2017 (UTC)

The "flag the edit in the abuse log" checkbox has been removed

Tracked in Phabricator
Task T154091

FYI per T154091, the "flag the edit in the abuse log" checkbox has been removed -- Samtar talk · contribs 11:49, 16 February 2017 (UTC)

Special:AbuseFilter/842

Disallowing. Should be temporary — MusikAnimal talk 23:01, 22 February 2017 (UTC)

Special:AbuseFilter/247 - Setting `Adding emails in articles` to disallow

Hi all, can you think of any legitimate reasons why an email address would be added to mainspace articles? Filter 247 has been successfully logging and warning editors not to do this, but I think we could safely disallow these edits. Given certain criteria in the filter if an email did have to be added to an article for some reason, a more experienced editor could do so -- Samtar talk · contribs 20:48, 21 February 2017 (UTC)

Recent changes log. — xaosflux Talk 00:28, 22 February 2017 (UTC)
Thanks for this Xaos, and having had a look through the last couple of days there isn't much that would be disallowed which shouldn't be. Although we don't want to scare off people making edits such as this, a nicely worded system message could prompt the editor to go back and remove the email address whilst adding the rest of the reference. Then of course there is rubbish like this (1, 2, 3, 4, 5) when needs to be reverted and sometimes revision deleted and/or oversighted -- Samtar talk · contribs 08:30, 23 February 2017 (UTC)

Archiving at WP:EF/R

ClueBot III is working fine, but it'd be nicer if we could use the notation templates and have a bot archive N hours after it was added, and archive to separate pages based on what notation template was used. This is similar to the way it is done at WP:PERM. So I'm proposing a new archiving bot that will offer this functionality, and can be used at any venue or talk page. Please feel free to chime in at Help talk:Archiving a talk page#A new archiving bot — MusikAnimal talk 00:48, 26 February 2017 (UTC)

Special:AbuseFilter/836

Just set this up after prolific ANI spammer / sockpuppeteer. Review appreciated. Georgewilliamherbert (talk) 06:20, 4 February 2017 (UTC)

Zero hits as of now, 11 days later. עוד מישהו Od Mishehu 04:39, 15 February 2017 (UTC)
@Georgewilliamherbert: No hits 17 days later, could we disable this? -- Samtar talk · contribs 20:50, 21 February 2017 (UTC)
Disabled. Glad that the abuser stopped on their own. Georgewilliamherbert (talk) 01:31, 2 March 2017 (UTC)

Request for permissions: User:Vito Genovese

 Done — MusikAnimal talk 20:09, 9 March 2017 (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.

Vito Genovese (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)

As per my original request, I'd like to be reinstated as an EFM. My access was revoked due to inactivity with no prejudice to readding. I am now active, and we are in need of your experience at trwiki.

My fellow sysops and I have been trying to deter a user-turned-vandal for some time now to no avail (please see this from today as an example). Since this person, who remains unidentified, has some experience, he easily eludes our current filters by trying different things all the time. We have been range blocking open proxies, but one can always find others. The abuse has been going on for months and needs to stop. Therefore I need to access, study, and learn from the private filters.

Please note that my original pledge not to edit any enwiki filters remains, and I will also ensure that the private filters that I happen to import to trwiki and any derivatives thereof will remain private as well.

Vito Genovese 21:49, 27 February 2017 (UTC)

information Administrator note I revoked this, purely for inactivity in 2014. — xaosflux Talk 01:08, 28 February 2017 (UTC)
Vito Genovese non-admin additions to this group on enwiki are routinely open for a week to allow for discussion. — xaosflux Talk 01:12, 28 February 2017 (UTC)

Discussion

  • Support per prior access, continued advanced permissions at trwiki demonstrating need, and per requester's commitment to this being for read-only use. — xaosflux Talk 01:12, 28 February 2017 (UTC)
  • Support clearly trusted with previous access and continued sysop at trwiki -- Samtar talk · contribs 15:13, 2 March 2017 (UTC)
  • Comment I don't have any problem with this, but given your cross-wiki experience I suspect it would not be difficult to get the read-only global abuse filter helper flag on Meta. I'd also like to offer my expertise to you if you need help authoring filters, and I'm sure others here are willing to help as well. I say this as filters targeted towards specific vandals may not share similarity with other vandal-specific filters, so a filter that works for us may not work for you. Your wiki (with all due respect) is also significantly smaller, so you may be able to get away with some edit filter functionality that we avoid here — MusikAnimal talk 18:17, 2 March 2017 (UTC)
    Thank you MusikAnimal (and of course others who are willing to help) for the generous offer, we'd certainly love to have your support (ported your MoreMenu recently, MusikAnimal, excellent work!). Since both projects are Wikipedias, I believe your filters would lead to better results in terms of diagnosing various editing patterns that are specific to encyclopedias. A certain filter may help with profanities, while another may do wonders against sneaky vandalism. I'll certainly consider applying for the meta flag, but I believe our big sister will prove to be our guiding light, as always.--Vito Genovese 18:32, 2 March 2017 (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.

Special:AbuseFilter/702

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.

Should bots be exempt from this filter? I've noticed that lowercase sigmabot III sometimes triggers this filter when it's trying to archive pages (see filter log). —MRD2014 📞 contribs 12:04, 31 March 2017 (UTC)

Perhaps I'm being naive, but I fail to see why a flagged bot should be subject to any of the edit filters. – Train2104 (t • c) 23:12, 1 April 2017 (UTC)
 Done I exempted bots. — xaosflux Talk 23:27, 1 April 2017 (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 847

I've set filter 847 to disallow. It's designed to prevent (persistent, long term, never-ending, obsessive) disruption from the sandbox troll. -- zzuuzz (talk) 09:23, 10 April 2017 (UTC)

Template:Unlocked userpage & filter 803

Pinging @Xaosflux and MusikAnimal:. While making a pass through fully protected templates to see which ones are still needed and which ones merit template protection, I came across Template:Unlocked userpage. Ostensibly it's supposed to allow users to exempt their userpages from the edit filter, but according to Special:AbuseFilter/803 it has not been implemented yet. Is it worth doing so? Jo-Jo Eumerus (talk, contributions) 16:39, 25 March 2017 (UTC)

I think its a good idea - better than filter exceptions for user space. — xaosflux Talk 17:55, 25 March 2017 (UTC)
@Jo-Jo Eumerus and Xaosflux: Here is what I believe to be a working implementation, which I tested back in December: Special:AbuseFilter/history/637/item/16313. So to spell out the checks it makes:
  • First make sure the user is editing someone else's userpage
  • Disallow if they are unconfirmed and {{unlocked userpage}} is not on the page
  • Otherwise, if they are not an admin, disallow if they are trying to add or remove the template
If that sounds right to you I will update the live filter. Feel free to turn on Special:AbuseFilter/637 if you want to test it yourself. Best — MusikAnimal talk 16:47, 27 March 2017 (UTC)
I have now implemented this change. Everything you need to know can be found at Template:Unlocked userpage and meta:Userpage AbuseFilter. I've added {{unlocked userpage}} to Jimbo's userpage and User:Sandbox. For the latter, there may be issues with the sandbox cleaning bot. I'll talk to the operator about it, and if all else fails we'll just manually exclude it in the filter — MusikAnimal talk 00:08, 18 April 2017 (UTC)
User:Sandbox has been manually excluded in the filter. Newbies will likely blank the page from time to time with innocent test edits, and we shouldn't prevent that — MusikAnimal talk 00:59, 18 April 2017 (UTC)
Looking good, not seeing any false positives hitting. — xaosflux Talk 02:17, 18 April 2017 (UTC)

contains_any and similar functions

Note to all, and pinging Zzuuzz and Coffee in particular since I know you've used some of these functions: Turns out contains_any, contains and in all cast some of the parameters or operands into strings. I feel kind of stupid having only now figured this out, but anyway this means you can't do things like contains_any(article_namespace, 0, 1) because namespace 10 will match the 0 and 1, 14 will match the 1, etc. Same for article_articleid in [12345, 67890] or any other integer comparison. Surprisingly, I guess the fastest way to do it, and use the fewest conditions, is via regular expressions. So article_namespace rlike "^(0|1)$" or article_articleid rlike "^(12345|67890)$". Does anyone know of another way? In general I avoid the regex engine but variables like article_articleid and article_namespace are obviously very small and cheap to work with.

I'll also note the anti-harassment team has plans to revamp the AbuseFilter, see meta:Community health initiative/AbuseFilter. With this we might look at having contains_any and others intelligently treat integers as integers, or introduce new functions for this. We also want to look into a better way of gauging performance than simple condition counting. For instance 1 == 0 and old_wikitext irlike "huge regex string" should not be counted as using the same amount of resources. Someone please correct me if I'm wrong about any of the above — MusikAnimal talk 17:16, 19 April 2017 (UTC)

Yes, I agree about using regex for these numbers. It's the approach I took way back in filter 271, and in fact I've always ignored contains_any until very recently as it appears to do the same thing as regex. I seem to recall one or more filters has a huge list of article ids. I can't remember if it's disabled, but perhaps it's worth checking what the other filters use. -- zzuuzz (talk) 17:28, 19 April 2017 (UTC)
@Zzuuzz: Sorry, just double-checking that you know that it does not do the same thing as regex :) E.g. 15 rlike "^(1|5)$" evaluates to false, but contains_any(15, 1, 5) evalutes to true, so if 15 were article_namespace, you'd end up also checking Template, Category, Draft, etc., when you meant to only check Talk and Wikipedia talk. You can try this out in the debugging tools — MusikAnimal talk 19:32, 19 April 2017 (UTC)
But contains_any(15, 1, 5) is the same as 15 rlike "1|5", no? That's the way I think of it. -- zzuuzz (talk) 19:43, 19 April 2017 (UTC)
Yes, in that sense :) If you were to incorporate any other regex functionality other than | it of course would not work. So in general I would not use regex unless you need to, if not just for programmer-friendliness. contains_any is easier on the eyes, and less fragile. In terms of performance your simple regex OR statements are probably marginally more expensive than contains_any — MusikAnimal talk 20:00, 19 April 2017 (UTC)

Word "bi*ch" not allowed in references?

An automated filter (likely designed in the 1950s) prevented me from adding this good reference (with "bitch" in the URL) to an article. Pity. http://www.smh.com.au/entertainment/art-and-design/visual-art-paradie-bi*ch-best-yet-at-white-rabbit-gallery-20151020-gkdi6m.html You will have to put the "t" into the word "bi*ch" to follow the URL.96.127.244.11 (talk) 20:59, 20 April 2017 (UTC)

As explained at Wikipedia:Village pump (technical)#Word "bi*ch" not allowed in references?, the reason for the filter is not references saying bitch but vandals adding the word (and others) to articles for no reason. Autoconfirmed users are allowed to add it. An automated filter cannot tell whether there is a valid reason to say a word. Click the "details" links at [1] to get an idea which edits the filter normally stops. Do you think those edits should be allowed? PrimeHunter (talk) 21:46, 20 April 2017 (UTC)
The folks at Village Pump told me to come here to report this. I think that if the word appears in the reference title or url tag, it should clearly be allowed. Can you give me a reason for the edit filter preventing the use of references that have bitch in it? There are lots of articles with it. A few examples:
In summary, it seems like a common word that might appear in a reference, so its use in reference tags should not trigger the filter.96.127.244.11 (talk) 02:29, 21 April 2017 (UTC)
The benefit does not outweigh the damage; almost certainly, the vast majority of attempts to add "bitch" to references by non-autoconfirmed editors are vandalism. Those wishing to add such a word to an article (in a reference or otherwise) can make a request on the respective talk page (perhaps using {{help me}}) or register an account making 10 other edits and waiting four days. — Godsy (TALKCONT) 01:28, 22 April 2017 (UTC)
The bad words filter checks if those words are already being used in the article. In your case, 96, this word appeared nowhere except in your addition. Someguy1221 (talk) 02:27, 22 April 2017 (UTC)
"almost certainly, the vast majority of attempts to add "bitch" to references by non-autoconfirmed editors are vandalism" is almost certainly speculation. Do you have some specific examples of people adding references that are vandalism and contain swear words? There aren't really any good reasons to filter swear words that are added solely in references; the only one I can think of is that people don't like swear words. 96.127.244.11 (talk) 02:39, 22 April 2017 (UTC)
This is going around in circles - 96.127.244.11: this hit was from Special:AbuseFilter/384 - do you have any specific improvements to that filter you would like to recommend and want to mock up code for? — xaosflux Talk 03:08, 22 April 2017 (UTC)
His proposal (translated to something workable) is to exempt text below the references header from filter 384. This could certainly be done, but I wouldn't support the change myself, doubting it would really prevent all that many false positives. Someguy1221 (talk) 09:42, 22 April 2017 (UTC)
The references usually exist in the article body, not below the header. It should still be possible to exclude things within <ref>...</ref> with some lookaheads/lookbehinds, but I don't think this is by any means "cheap" and the filter is already pretty complicated as it is. I also agree this change would likely prevent few false positives, bringing to question if the expense and/or effort is worthwhile. Another idea is to show a custom warning message with a link to make an edit request, but that might backfire and merely redirect the vandalism to the talk page — MusikAnimal talk 02:52, 27 April 2017 (UTC)

WP:EF/R needs more eyes

There is a thread at WP:EF/R that has open open a month without a response, and several others nearly as long. Please could edit filter managers and others with the technical know-how try and give a reply to good faith requests in a few days at most - even if it can't be actioned then, saying so is better than giving the impression the page is being ignored. Thryduulf (talk) 22:24, 26 April 2017 (UTC)

I've replied to a few and will try to tend to the rest. Believe it or not EF/R is much, much better than it used to be :) No doubt we still need more people that work in this area, but the main issue I think is when you create a filter on behalf of someone you then are essentially signing up to monitor it until it is stable and proven effective. This process can be quite lengthy and may serve as a deterrent for the casual but experienced edit filter manager. I currently have 6 filters I'm actively monitoring daily, and another 10-15 or so that I check on occasionally. They're fun to code but one can easily become overwhelmed — MusikAnimal talk 03:56, 27 April 2017 (UTC)
Thanks. I'd help out but I really don't have the technical skills required for the job. Thryduulf (talk) 10:36, 27 April 2017 (UTC)

Granting Edit filter to Chrissymad

 Done For read only use per discussion below. — xaosflux Talk 12:03, 27 April 2017 (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.

Portions of the this thread were split out to the next topic for a longer discussion
Chrissymad (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)

For those of you who don't know, Chrissymad does an arseload of SPI work and regularly asks admins for information regarding filters and which ones are being triggered. I was going to IAR and give it to her myself, but Ks0stm rightly pointed out that the request needs to be made here. She is a valued asset to the SPI community, and while I don't mind accessing hidden filters to let her know why the vandals are constantly tripping them, it would be nice if she could do it herself. Primefac (talk) 20:36, 20 April 2017 (UTC)

I would support this request, as I'd trust Chrissymad more with edit filter manager than myself, even. Since to my knowledge there's no way to give non-admins access to view private filters and their logs without them having edit filter manager, edit filter manager it is. Ks0stm (T•C•G•E) 20:40, 20 April 2017 (UTC)
@Chrissymad: Given that you don't appear to have experience editing edit filters, would you agree to never make changes to filters without speaking to another edit filter manager if given this right? Sam Walton (talk) 20:51, 20 April 2017 (UTC)
Samwalton9 Absolutely. CHRISSYMAD ❯❯❯¯\_(ツ)_/¯ 20:55, 20 April 2017 (UTC)
  • Do you practice good password security (without going into specifics)? As an aside, would it be worth proposing an "edit filter viewer" right? Has there been any kind of use-case for that, in the opinions of those here? Personally I could use the heck out of read-only EF rights to see how my pet socks are adapting, but that may be a rare situation? CrowCaw 21:00, 20 April 2017 (UTC)
Crow I do and I'm totally willing to use 2FA if possible. I use filters for a lot of things with regard to SPI and identifying LTAs - don't want to go into specifics because of obvious reasons and I absolutely think that an EF viewing right would be useful for a select few people aside from myself. CHRISSYMAD ❯❯❯¯\_(ツ)_/¯ 21:23, 20 April 2017 (UTC)
(oathauth-enable) (for 2FA) is included with Edit Filter Manager access, if granted you can enable. — xaosflux Talk 03:49, 21 April 2017 (UTC)
  • EF access may be granted to non-admins by discussion - and this is the venue to discuss it, including any pledges for read-only. These discussions are normally open for a week. This is not a "vote" and is not run like an RfA. — xaosflux Talk 03:46, 21 April 2017 (UTC)
I think Chrissymad would greatly benefit from this user right and is trustworthy to not delete or modify anything. -- Dane talk 04:17, 21 April 2017 (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.

Special:AbuseFilter/249

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.

Why is "undid" not included in the conditions? The default edit summary for an undo is "Undid revision $1 by $2 (talk)", and if someone is using the undo function over and over again, their edits are not tagged because "undo" and "revert" are not included, even though they would be conducting large scale reverts. —MRD2014 📞 contribs 02:32, 2 May 2017 (UTC)

 Done Good catch! I've added it to the filter — MusikAnimal talk 21:37, 6 May 2017 (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.

Orphaned and undocumented edit filter messages

I've been vetting the various MediaWiki messages used by edit filters and it appears like there are a number of them that do not document which EF is using them, or whose edit filter has been disabled or deleted:

Undocumented messages, or not used in the supposed page:

Messages attributed to disabled/deleted filters:

Some of these messages need to be updated to reflect currently active filters that use them. Others might be deleted as G6 when they are unused in active filters. Jo-Jo Eumerus (talk, contributions) 18:42, 14 April 2017 (UTC)

I tried to track down the usage history of the first section, tagging those that are still in use. I think we can safely delete the pages in the bottom section provided they haven't been edited in a year or two. Sam Walton (talk) 20:07, 14 April 2017 (UTC)
Seems like almost all of them were, so I've deleted them. Now the only ones left to do are MediaWiki:Abusefilter-warning-ip-edit-confirmed, MediaWiki:Abusefilter-warning-DS, MediaWiki:Abusefilter-warning-largeaddition-notice, MediaWiki:Abusefilter-warning-priorcase and MediaWiki:Abusefilter-warning-utf. Jo-Jo Eumerus (talk, contributions) 18:39, 19 April 2017 (UTC)
MediaWiki:Abusefilter-warning-blanking appears to be used on filter 3? – Train2104 (t • c) 18:58, 19 April 2017 (UTC)
Whoopla. Restored that. Jo-Jo Eumerus (talk, contributions) 19:04, 19 April 2017 (UTC)
I've sent a few of the unprocessed messages to MFD. That leaves only two:
Jo-Jo Eumerus (talk, contributions) 08:46, 22 April 2017 (UTC)

Copies of private filters

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 run a MediaWiki site that actively uses the AbuseFilter/edit filter, and I think that many of Wikipedia's filters would be beneficial in stopping some of the recent vandalism that has occurred there. However, many of such filters are private. I would like to request a copy of several private filter's conditions be sent to me personally (not posted publicly of course), but I'm unsure of the right way to pursue this request. -- SlitherSnakeSempter, 22:55, 9 May 2017 (UTC)

@SlitherSnakeSempter: most private filters are private for security reasons. If there is a specific filter you are interested in we may be able to redact it and share. Most of the private filters deal with specific English Wikipedia issues that won't be found in other wikis. — xaosflux Talk 02:36, 10 May 2017 (UTC)
Just looking through the private ones now, most are private to keep it hidden the precise phrases and other conditions so that trolls don't work around it. Not knowing these hidden details won't impact your efforts as you are unlikely to have the exact same vandalism as Xaos mentioned, but we can still send you the general outline of the filter. Someguy1221 (talk) 02:39, 10 May 2017 (UTC)
Some specific filters that I would like to reuse elsewhere include filter 12, filter 51 and filter 52 (both disabled), filter 62 and filter 63 (both deleted), filter 68, filter 102 and filter 225. There's probably more, but I think that's enough to make my point. -- SlitherSnakeSempter, 20:35, 10 May 2017 (UTC)

I would suggest caution in giving this person any portion of this information; it could be used to vandalize Wikipedia. They're pretty obviously a brand new returning user, and there are only so many reasons returning users come back, dive immediately into NPP, and ask for contents of filters. --Floquenbeam (talk) 20:39, 10 May 2017 (UTC)

Ahem, read my user page. If you follow the links to any of my external non-WMF accounts (except for ShoutWiki, where I am inactive), you'll see that I am clearly not a vandal and I do not appreciate being referenced as a possible one. Please do not post similar comments about me again. Also, you didn't read my rationale clearly it appears, as I stated bluntly that I am asking for copies for filters to reuse on other wikis that I help staff. I made no mention of Wikipedia anywhere in that reasoning. Please be careful before making accusations. -- SlitherSnakeSempter, 20:43, 10 May 2017 (UTC)
The fact that you claim something to be true is not the same as it being true. --Floquenbeam (talk) 20:44, 10 May 2017 (UTC)
If you ask around at many of the other non-WMF sites listed on my user page (especially Miraheze), I'm sure that they can tell you that I am a good-faith contributor. -- SlitherSnakeSempter, 20:46, 10 May 2017 (UTC)
The content (and some of the structure) of these filters really is quite specific to this wiki, built through years of experience of specific problems with enwiki vandals like you're unlikely to find anywhere else. If you're running an abuse filter you really should know how to write the basics, because copy-pasting code you don't understand is usually a bad idea. The basics are really simple. For example, edit summary vandalism, just write summary rlike "vandal phrases (regex)". I won't be divulging any secrets to also describe Filter 62, action == "delete" & article_text == "Main Page". Filter 102 is just a matter of testing for some abusive account names. It seems to me there is enough experience at miraheze to be able to write most of these filters. If there's some specific aspect you need help with, someone might be willing, and I'd suggest asking for help with aspects of a filter would be more useful than asking for specific filters. -- zzuuzz (talk) 21:15, 10 May 2017 (UTC)
@Zzuuzz: What about the rest of the filters I mentioned? -- SlitherSnakeSempter, 21:19, 10 May 2017 (UTC)
Which aspect of "Vandalism in all caps" are you having issues with? -- zzuuzz (talk) 21:25, 10 May 2017 (UTC)
I don't want to spill the beans, but I had numerous instances on my personal Miraheze wiki of vandalism that was all caps and very large that was not stopped by my "shouting" filter. I don't want to publicly post a link, and even if I did it wouldn't be useful as the revisions have been deleted. However, I will supply any further evidence necessary via a private channel of communication. -- SlitherSnakeSempter, 21:37, 10 May 2017 (UTC)
I'm not convinced that we should be giving copies of our filters out to users from non-Wikimedia wikis, but I don't see any reason that we can't give advice and general help. @SlitherSnakeSempter: If you want to discuss in a non-BEANS area, please email the mailing list, where we can discuss specifics without worrying about that. But keep general discussion here :) Sam Walton (talk) 21:41, 10 May 2017 (UTC)
And that folks, is why we don't trust people who randomly come here and ask for private details of filters. Sam Walton (talk) 09:06, 12 May 2017 (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.

Privacy of general vandalism filters

The above discussion regarding private fitlers brought up 12 and 225 , both of which in my opinion should be public. These are not specific to any socks, instead targeted at your everyday drive-by vandal. Per WP:PRIVATEFILTER, we should only be hiding filters when necessary. The vandalism filters are merely shortcuts to save patroller's time. Any dedicated vandal could guess their way around them without reading the details. Keeping them open also allows patrollers to suggest new additions and tweaks based on recent disruption. E.g. you might compare this to the MediaWiki:Titleblacklist, which is public.

Going through the vandalism filters, I see many (perhaps most) are public such as 11, 39, 46, 189, 320 and 384; while others such as 260, and 279 in addition to 12 and 225 are not.

Thoughts? I think the guideline mostly already implies they should be public, but a little clarification wouldn't hurt — MusikAnimal talk 03:12, 11 May 2017 (UTC)

I can agree with that. If it's just common vandalism, then public or private isn't going to matter (and as you say, public will help with tweaking it). I think the only ones that really need to be private are those relating to LTAs who trawl through the filters trying to bypass them. Primefac (talk) 12:18, 11 May 2017 (UTC)
 Support original proposal. -- SlitherSnakeSempter, 19:11, 11 May 2017 (UTC) WP:SOCKSTRIKE 01:20, 12 May 2017 (UTC)
Note the filter COMMENTS need to be ok for public use if un hiding, e.g. shouldn't be calling out specific users/ip's etc. — xaosflux Talk 20:05, 11 May 2017 (UTC)
I doubt that the comments of filters 12 and 225, which are the two that I mentioned have any private data in them. -- SlitherSnakeSempter, 20:09, 11 May 2017 (UTC) WP:SOCKSTRIKE 01:20, 12 May 2017 (UTC)

I agree with Primefac that "the only ones that really need to be private are those relating to LTAs who trawl through the filters trying to bypass them"; however, we do occasionally have a troll who trawls through the vndalism filters trying to bypass them, and we need to stop them, too. I think all these listed filters shouldbe private. עוד מישהו Od Mishehu 09:58, 13 June 2017 (UTC)

Techno vandal has new tactics

Sam Walton put together Special:AbuseFilter/663 to lessen the disruption from the Wikipedia:Long-term abuse/Techno genre warrior from Greece who was adding "techno" to lots of articles. Recent disruption from this person often includes the word "rave".

But the old style stuff continues:

Is there a way to rework the filter so that this person is disallowed? Binksternet (talk) 15:59, 14 June 2017 (UTC)

false positive

i made this edit. fortunately, i copy and pasted the text and was able to save it. does anyone know why it happened?68.151.25.115 (talk) 07:18, 14 June 2017 (UTC)

It responds to lines which end in exclamation points (!). By removing the content after a few of these, you created lines which end in exclamation points. עוד מישהו Od Mishehu 17:51, 14 June 2017 (UTC)

Special:AbuseFilter/29

Can removing {{db-g13}}/{{db-afc}} be exempt from filter 29? The template says "If you plan to improve this draft, simply edit this page and remove the {{Db-afc}} or {{Db-g13}} code." Template:Db-afc-notice also says that. Because of that, I don't think removing it should trigger the filter and tag the edit. —MRD2014 talk contribs 02:35, 31 May 2017 (UTC)

  • My concern is that it would be used to game the system to keep an unimproved draft languishing indefinitely. Looking at the last 3 hits on the filter for draft space gives 3 articles that were declined in September 2016, and sat untouched until May when they were tagged for speedy. The tag was removed, triggering the EF, and no substantive edits have been made since then. Ref: Draft:Mindmap Communications, Draft:Chakwal Group, and Draft:RBH Sound. So if nothing else, since the filter doesn't disallow, I think it would be helpful to be alerted to these kinds of situations. CrowCaw 21:18, 5 June 2017 (UTC)
Agreed, especially if they aren't using {{AfC postpone G13}} to keep track of it. Primefac (talk) 12:40, 6 June 2017 (UTC)
I think it might be okay to leave the filter as is, although a patroller might see the tag and then they might restore {{db-g13}} although it's okay to remove. —MRD2014 talk contribs 15:59, 6 June 2017 (UTC)
Even if someone restored it, the reviewing admin could decline on the grounds that it had already been removed. As I said above, the filter probably doesn't need changes after reading the other comments in this thread. —MRD2014 talk contribs 16:57, 6 June 2017 (UTC)
@Primefac and MusicAnimal: What do you think of changing Special:AbuseFilter/29 from tagging edits to preventing edits? Alternatively, what if we created a new version of the filter that was limited to only main namespace pages and made that one prevent edits while AbuseFilter/29 continued tagging? The reason I'm asking is because the New Page Patrollers are upset about spammers removing speedy deletion tags from new articles after they have been marked as reviewed. See this discussion. Kaldari (talk) 03:58, 13 June 2017 (UTC)
This issue was discussed at Wikipedia talk:Edit filter/Archive 2#Special:AbuseFilter/29 - prevention of removal of deletion templates. עוד מישהו Od Mishehu 04:49, 13 June 2017 (UTC)
  • One of the comments/issues brought up there was that there was (at the time) no way to prevent only the creator from removing the tag. But would not user_name == article_first_contributor match that? CrowCaw 18:08, 14 June 2017 (UTC)

@Crow: I was just going to comment on this...not sure if that variable existed back in 2009. That's a good idea and should be done. Although, after reading the filter and Special:PrefixIndex/Template:db-, I want to make sure all those notice templates and oddballs like {{db-revise}} don't get caught (or are renamed). – Train2104 (t • c) 18:40, 14 June 2017 (UTC)

  • It would need discussion of course, since the last consensus was not to do this, but yes the tags used would have to be considered carefully. A user tagging one of their userpages for speedy, then changing their mind, should not be disallowed, nor should a user creating an article, tagging it for G7, then changing their mind and removing the tag. CrowCaw 21:12, 14 June 2017 (UTC)
The existing filter already exempts U1 and G7. The question is, if it's set to disallow, should we exempt more. I think that answer is yes. – Train2104 (t • c) 12:40, 15 June 2017 (UTC)
One of the other issues that was brought up in the previous discussion is that sometimes people remove the tags as part of a bigger article clean-up. I think we need a separate disallow filter that is limited to main namespace and only affects edits that add no content. Limiting it to user_name == article_first_contributor would be a bad idea, IMO, as newbies commonly switch between editing logged in and logged out. Also, FWIW, I don't think the existing filter is doing much good as it doesn't seem like anyone is monitoring it. Kaldari (talk) 16:23, 15 June 2017 (UTC)
  • It's been fairly well established that any editor can remove a csd tag in good faith, including an IP that's not blatantly the creator. The filters can't rule on intent or who is behind an IP, so the only disallow options would be to disallow anyone from removing a tag, or erring on a smaller set of filter hits by disallowing just a specific match. The more I think of it, I suspect that most people would quickly figure out that they can remove the tag by logging out, so we'd be down to disallow anyone, or keep it just tagging. As far as who's watching it, it's a fairly simple matter for RCPs to bookmark this: [2]. CrowCaw 17:44, 17 June 2017 (UTC)

Carlos Gardel filter

The filter protecting the Carlos Gardel article may need some tweaking. It looks to me as if this edit should have been stopped by Special:AbuseFilter/851. What can be done to improve the filter? Binksternet (talk) 15:45, 14 June 2017 (UTC)

Aha. Can the filter be activated to disallow "uruguay" in the infobox? Binksternet (talk) 16:51, 15 June 2017 (UTC)
  • It's only been hit one time since activated in April, so the collateral damage would be low, but the benefit seems equally low vs. the cpu time consumed by the filter. Has this vandal done things that the filter hasn't logged? More:Looking deeper, this vandal is fairly sporadic and the only other recent ip editors have been reverted quickly. Perhaps applying PC1 to this page, or even a semi-prot until the vandal sees that he's locked out, would be better than checking every edit to WP against this filter (which is what happens)? CrowCaw 21:06, 17 June 2017 (UTC)
Yes, good point. In the interest of limiting overhead cycles I'll look into getting PC1 set to indefinite. Binksternet (talk) 22:38, 17 June 2017 (UTC)

Edit filters and the Ross fans

Moved from Wikipedia:Administrators' noticeboard

Fans of Ryan Ross are just going bonkers with silly edits to stick his name in articles, even choosing user names related to him. His personal Wikipedia article has been indef semi-protect since 2011 because of vandalism. The edits I've seen/dealt with at AIV and RFPP are connected to dairy protects. Cheez Whiz, for instance, has been page protected because of this, as has Cheddar cheese. Here's one for Kifr, List of dairy products, Cottage cheese, and on and on it goes. I saw one today somewhere that indicated this type of thing with Ryan Ross has been going on since before 2017. Is there any kind of edit filter that can catch these edits? — Maile (talk) 22:41, 17 June 2017 (UTC)

Looks like Oshwah beat me to [860]. — xaosflux Talk 23:37, 17 June 2017 (UTC)
Indeed, but I'm not convinced that it's catching everything. I ran the filter through tests on different articles that got hit today, and I noticed that this edit didn't get flagged in the test - it looks like the brackets ("[[") might be what's throwing it off? I'm trying to figure out why this edit (and possibly others like this) aren't being caught in this filter. Any input would be appreciated ;-) ~Oshwah~(talk) (contribs) 23:41, 17 June 2017 (UTC)
Oh, good, it's being done. I don't know what it is about Ross, but in the era of social media, even a Cat can be an enduring internet phenomenon . — Maile (talk) 00:07, 18 June 2017 (UTC)
@Oshwah: it is hitting OK, it did not match that specific edit because the page had already been vandalized with that phrase, and that specific edit "removed lines" (by way of shifting the text) the prior vandalism when it added more. See that edit's details. — xaosflux Talk 00:34, 18 June 2017 (UTC)
AHA, got'cha ;-)! Thanks for pointing that out. I was sitting there for quite some time trying to figure out what the heck the deal was... haha! ~Oshwah~(talk) (contribs) 01:35, 18 June 2017 (UTC)
@Oshwah: I think we should change this to "warn", since we are apparently blocking people that make these edits anyway - a warning may dissuade them. — xaosflux Talk 01:24, 18 June 2017 (UTC)
Xaosflux - I agree. Are there any objections from anyone with me making this change to the edit filter? ~Oshwah~(talk) (contribs) 01:33, 18 June 2017 (UTC)
I've gone ahead and made the change. If anyone has questions or concerns, please let me know. ~Oshwah~(talk) (contribs) 01:59, 18 June 2017 (UTC)
Looking fine, looks like since warn was enabled about half of the vandals have gave up. — xaosflux Talk 03:28, 18 June 2017 (UTC)
Though there have still been 21 different IPs and accounts vandalising (that the filter has caught) since then ... Black Kite (talk) 11:04, 18 June 2017 (UTC)
@Oshwah: Another six in the last ten minutes. Can we set it back to "Disallow", please? Black Kite (talk) 11:14, 18 June 2017 (UTC)
Please note, it was on log, then warn - it was never on disallow. — xaosflux Talk 14:15, 18 June 2017 (UTC)
Uh, could we do that then, please? It's very boring for administrators to be trolling through the filter log blocking people (just off to do some more now). This is getting far more hits than many filters that are set to disallow. Black Kite (talk) 14:18, 18 June 2017 (UTC)
Sorry for the late response. Looks like the changes have already been made. I've also added "Brendon Urie" as a parameter to the filter, as the "Brendon Urie" vandalism is related to this as well. I'm holding off on adding "Ryden" to the filter until I can verify that doing so won't trigger any false positives. Stay tuned. ~Oshwah~(talk) (contribs) 19:20, 18 June 2017 (UTC)

Filter set to disallow for filter 860

Yes, thank you for making that modification. I was away, else I would have done so ;-) ~Oshwah~(talk) (contribs) 19:23, 18 June 2017 (UTC)
  • I re-enabled "warn" on this - since we are being heavy with the banhammer - if someone stops after the warning blocking isn't really warranted - if this ends up not being short-lived, changing to outright disallow may be OK. In general it is better to dissuade (especially dynamic IP's) then block. — xaosflux Talk 00:48, 19 June 2017 (UTC)
    @Xaosflux: I'm a little confused why re-enabled warn even though it's set to disallow. The purpose of this is to show a custom message, clearly indicating the edit is being disallowed. Here we're using the standard MediaWiki:abusefilter-warning which says "please click 'Save page' again" if it was an error, yet doing so will still disallow the edit. Without a custom warning, this serves no purpose anyway. The warnings get logged just as the disallowed edits. Generally we need multiple edits to deduce an account as being vandalism-only, so following that logic here you could just look for multiple disallowed log entries, and let users with a single hit get a "pass". This is what I would do in any scenario – wait for at least two attempts to vandalize before even considering blocking. At the very least I don't think we should be showing a misleading message.
    Finally, should this filter be private? It seems this is more of a vandalism trend and not specific to a known pool of vandals — MusikAnimal talk 00:55, 19 June 2017 (UTC)
    @Xaosflux: Question, since it might be my heavy finger on th banhammer there. If it's not an IP, but clearly a vandalism only account, does it matter that they stopped at the warning? In the case of this edit filter log, I was actually looking at the totality of what was stopped by the edit filter, rather than the warning. And I didn't give them enough time to try more vandalism. Are you referring to vandalism only accounts? — Maile (talk) 01:07, 19 June 2017 (UTC)
    I agree. If it is clear they are up to no good, in my opinion it does not matter if the edit went through, or how it was prevented from going through (warning or outright disallow). In your example, the edits were a bit on the egregious side, so for me a VoA block would have been warranted on the second attempt if not the first. In the case of this Ryan Ross vandalism (which is not very egregious), if we want to more politely discourage partaking in the trend, I would recommend showing a some customized message — MusikAnimal talk 01:41, 19 June 2017 (UTC)
    A customized message for the Ross fans seems like a good idea to me. The kind of silliness they're engaging in, it seems like young teenage fans (or younger) who just can't resist inserting their favorite star's name into articles. I did notice one where the Ross edits got stopped by the edit filter, and then were reported by the bot at AIV. Maybe if the filter stops those particular edits, and that's all there is, they don't need to be bot reported at AIV. — Maile (talk) 01:49, 19 June 2017 (UTC)
    I don't know if this will be short-lived or not. For IP editors, I really don't want to drive off potential editors - I may be in the minority here - so I think the warning is a good idea. For users where their only edit is this, I'm pretty much fine with VOA-indef. I'd like to see if warning is useful for 24-72 hours, if it is not helping: I support move to disallow only. Primary reason, I don't want to encourage them to find ways around the filter. — xaosflux Talk 02:00, 19 June 2017 (UTC)

Edit Filter Manager?

GRANTED
After the seven day discussion, no issues have been presented -- There'sNoTime (to explain) 14:52, 20 June 2017 (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.

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

Hi all! At MusikAnimal's continued nudging, I'm asking here about obtaining EFM rights. I'm active at SPI, having a list of pet socks that I routinely run searches against (from my own browser - no botting), and have a decent understanding of Regex. I've contributed some of that here, via the EF mailing list, and at MediaWiki talk:Titleblacklist. My primary use of EFM in the near future would be to check stats on hidden filters, subscribe to the mailing list, and suggest updates to some of the EF's that I've contributed to. (And enabling 2FA on my account would be a plus!) For the foreseeable future, I will not edit any active EF, but rather ones like #637, currently disabled, and let others check my work before re-enabling it. At some point, when/if it becomes clear that I won't crash the database with my edits, I'll ask for consensus to assume a read-write role. Thanks for your consideration, CrowCaw 23:02, 12 June 2017 (UTC)

There is a standard 1 week discussion period for this access. — xaosflux Talk 23:08, 12 June 2017 (UTC)
  • Support as stated, I have sort of been pushing for this :) The reason being Crow is familiar with certain SPI cases that may involve regular updates to filters. Until now Crow has been requesting such updates via the mailing list and WP:EF/R, but they seem competent in my opinion to handle these requests on their own. It's of course fine if Crow just wants to review private logs and make suggestions, but I trust them to make modifications when/if they feel comfortable doing so, and this was my intention when I recommended they ask for these privileges. I certainly don't want to push them any further, though! — MusikAnimal talk 23:54, 12 June 2017 (UTC)
  • Well, if the aforementioned consensus/trust should emerge here, then that's fine too. I suppose it would be a bit counter-productive for granting me the bit to result in making more work for everyone else ("try this", "change this", "enable this"...) but at the same time I don't want to exceed folks' comfort levels. Either way, though, I plan to proceed slowly and carefully, with full understanding of any changes I may make. CrowCaw 06:13, 13 June 2017 (UTC)
  • Support case well made by MA, and I see Crow an awful lot on the mailing list and EFR. Not having the right makes more work, which I'm always against shows clue, understanding of regex and has already mentioned a committent to extensive testing -- There'sNoTime (to explain) 13:59, 13 June 2017 (UTC)
  • Support - Helpful contributions on the EFM mailing list, and I'll be honest, MusikAnimal's recommendation is all I need to support. :) ☺ · Salvidrim! · ✉ 15:29, 13 June 2017 (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.

Exploring how the Edit filter can be used to combat harassment

Hello!

I’d like to invite you to participate in a discussion about how the Edit filter can potentially be used to combat harassment. The Anti-Harassment Tools team is looking into improving performance and adding functionality and we need your input to make our work successful.

Join the conversation at Wikipedia talk:Community health initiative on English Wikipedia#Exploring how the Edit filter can be used to combat harassment. I hope to see y’all there!

— TBolliger (WMF) (talk) 23:19, 21 June 2017 (UTC) on behalf of the Anti-Harassment Tools team

Filter 650

What is the point of this filter? I've tripped it several times already, but yet I didn't know it until I checked out what the "filter log" button on my contributions page did. Creation of an article without any categories shouldn't really be anything that needs filtering IMHO. Thoughts and comments welcome. Catalan (talk) 00:28, 23 June 2017 (UTC)

@Nestor Lozano: this filter is primarily for tracking purposes, and for page patrollers to have a feed to go add categories to pages that don't have any. It does not "filter" anything you are doing - its that all of these are called filters, it is a less formal method of "tagging". — xaosflux Talk 00:32, 23 June 2017 (UTC)
Xaosflux Funny in a way ... I just decided to see if I'd tripped any edit filters on anything. I tripped off 650 three times only, by creating articles. Probably because I created them in a sandbox and then copied and pasted them in entirety into the new article name. — Maile (talk) 00:47, 23 June 2017 (UTC)

Sanity check requested

Tracked in Phabricator
Task T168736

I've been working on a filter request and have run into what I believe to be a bug. When I examine the edits that the filter has tripped, I see it matches it, but the variables shown don't match the actual edit.

Consider Special:AbuseLog/18775762, which is for an edit by 86.150.37.35 made to Diarmuid Johnson. The edit_delta (net change) is listed as 1, and indeed, looking at the edit_diff it looks like only whitespace was added. However check the contributions of this IP (or the revision history) and I don't see any that were +1 in size, or ones that match the edit_diff. Is it just me or is this not adding up? I thought maybe there was recently a bad deploy to enwiki, but reviewing other filters things seem to be working as expected — MusikAnimal talk 15:35, 23 June 2017 (UTC)

@MusikAnimal: looks like a bug, note Special:AbuseFilter/examine/955398370 and Special:AbuseLog/18775762 don't match - seems to be regarding new_size variable. — xaosflux Talk 16:33, 23 June 2017 (UTC)
Bug created. I'm hoping it's just some weirdness limited to this filter in particular, but we might want to do more checks of existing filters, especially those that disallow, to ensure they're not malfunctioning — MusikAnimal talk 17:29, 23 June 2017 (UTC)

Help needed for bnwiki

Hi, Someone who understand Edit filter Please take a look here -> Wikipedia:Edit_filter/Requested#Help_needed_for_bnwiki. Thank you --Aftabuzzaman (talk) 12:42, 1 July 2017 (UTC)

Filter 50 and DISPLAYTITLE

While looking through recent changes, I came across edits like this and this, in which an IP added {{DISPLAYTITLE::-(}}, and it triggered the filter, and after the warning, tagged the edit as shouting, even though they were not attempting to shout (DISPLAYTITLE must be written in all caps), and there is a condition in the filter that exempts templates that have titles in all caps. —MRD2014 02:17, 4 July 2017 (UTC)

The exemption regex looks like it didn't work because that "template" format didn't match the normal pattern of all letters. So this is a false positive, but a bit of an edge case, and the tagging didn't hinder the editor. Of course, that edit didn't work anyway and was soon reverted. — xaosflux Talk 03:46, 4 July 2017 (UTC)

The Ryan Ross vandalism

I believe we have to think beyond Filter 860 to take care of the Ryan Ross fans. They're stepping it up now. About 10 of them hit all at once at AIV. I think it's going to eventually overwhelm the admins who take care of AIV. What can we do to stem the tide that shows no sign of ebbng? — Maile (talk) 23:57, 5 July 2017 (UTC)

@Maile66: can you provide some diffs, can see what can be added. — xaosflux Talk 00:48, 6 July 2017 (UTC)
These are being picked up by the current filter, which is how I see them at AIV. Nevertheless, admins still have to deal with these ... here are some I blocked. 1, 2, 3, 4, 5, 6, 7. — Maile (talk) 00:59, 6 July 2017 (UTC)
@Maile66: Oh ok, so the edits are being stopped - so the filter is working correctly. If you want the bot reporting to change by DatBot, @DatGuy: would need to adjust their bot. — xaosflux Talk 01:26, 6 July 2017 (UTC)
@Xaosflux: I guess maybe it's a case of what you intended for the bot. If your purpose was to get the bot to flag and report the vandalism, rather than waiting for individual editors to find the incidents, then the bot is working great. It just seems like the Ryan Ross vandalism is increasing in the number of incidents. But if human intervention (admins) is needed to deal with each case, then I guess everything is working fine. Thinking this over, admins are probably necessary to make sure the bot is not flagging erroneously. — Maile (talk) 11:05, 6 July 2017 (UTC)
@Maile66: while the filters are stopping the edits, protecting the readers, blocking is not performed by filters. Most of these blatant vandals are also getting blocks to prevent them from moving on to additional vandalism or getting more creative in their vandalism - this the attention of admins is needed. — xaosflux Talk 11:26, 6 July 2017 (UTC)
For what it's worth, I was looking at this (as they're beginning to move x-wiki) and decided to add it to the bot's immediate report filters. That should hopefully mean they're blocked quicker -- There'sNoTime (to explain) 11:38, 6 July 2017 (UTC)
Do note that the bot has been regularly reporting, presumably using User:DatBot/filters which is linked from the EFM page, and not User:DatBot/filters.js as previously. Most memes tire eventually. This is likely to be no exception. -- zzuuzz (talk) 11:45, 6 July 2017 (UTC)
On a positive note, I'm sure the ones who are doing this are having a wonderfully giggling time. — Maile (talk) 11:58, 6 July 2017 (UTC)
I don't know the full story of this thing but it might be useful to mention https://twitter.com/hashtag/WikipediaHatesEmos They don't look too happy. -- zzuuzz (talk) 12:04, 6 July 2017 (UTC)
Emus are never happy -- There'sNoTime (to explain) 12:10, 6 July 2017 (UTC)

@There'sNoTime: I dispute that. xD Kudos for all the good work you folks are doing here, it's greatly appreciated. TheDragonFire (talk) 07:58, 7 July 2017 (UTC)

Filters 768 and 809

What exactly is the purpose of Special:AbuseFilter/768 and Special:AbuseFilter/809? What edits exactly are they targeting? I find it hard to believe that we would need a filter to stop disruption at the noticeboards where disruption is frequently stopped. Additionally, why are both of these filters private? Based on the title, they don't appear to be targeting specific users. 73.142.103.7 (talk) 00:30, 29 July 2017 (UTC)

These two filters, along with Special:AbuseFilter/788, help ensure reports at such venues are not meddled with. Such disruption does go unnoticed, particularly at AIV where the edit rate is quite high. Both of the private filters are at least partially targeted at specific users. All are designed to still allow all users to use the noticeboards as they were intended to be used, and going by the logs they appear to be effective — MusikAnimal talk 00:12, 31 July 2017 (UTC)

Filter 856

Perhaps this filter needs to check if a {{copyvio-revdel}} was added as well. This edit of mine shouldn't have tripped it. – Train2104 (t • c) 23:30, 3 August 2017 (UTC)

@Train2104: please see Wikipedia:Edit filter/False positives. — xaosflux Talk 23:41, 3 August 2017 (UTC)

revisiting local edit filter helpers group

Portions of the above thread were split out here for a longer discussion
  • I love the idea of an edit filter viewer user right, and the only reason I haven't proposed one is I felt like doing so would be more hassle than it's worth without knowing what level of support/use it would get. Ks0stm (T•C•G•E) 21:09, 20 April 2017 (UTC)
  • As an aside, I would also support the creation of an edit filter viewer user right. I have come across situations where it would have come in handy (RE: SPI stuff) as well which I had to escalate and if there were a viewer right I could certainly make good use of it. -- Dane talk 04:17, 21 April 2017 (UTC)
    • Seems like the primary opposition then was "go to meta", but someone from meta said "no, do it here", so I suspect it would pass this time around. And Chrissymad is a great example of someone who wouldn't be granted the ability to edit filters, but should be able to view them. Sam Walton (talk) 12:22, 21 April 2017 (UTC)
Ping in some of the opposition that has recently edited from last the 2 year old discussion - to see if any thoughts have changed. I don't want to go through setting up a new RfC that is just going to end up with the same conclusion. @Reaper Eternal and Epicgenius:. — xaosflux Talk 00:46, 22 April 2017 (UTC)
  • Replying to the ping. Now that there is a "global abusefilter helper" right, I support this right. I don't see why a global right for this purpose could be created, but not the corresponding local right. epicgenius (talk) 02:39, 22 April 2017 (UTC)
  • For me, this would've been great while developing DatBot 3. It could still be useful to check which filters to add. Dat GuyTalkContribs 13:13, 23 April 2017 (UTC)
  • I'd support such a right. I can also see it being a useful learning tool for someone who is trustworthy but has not had the ability to demonstrate readiness for write access. Thryduulf (talk) 22:28, 26 April 2017 (UTC)
  • I don't know where I was the last go around or else I would have offered my strong support. The need for a read-only right comes up often enough, and we'll send people here instead of WP:PERM (where we see occasional hat shopping). In addition to Chirssymadm we granted access to Vito Genovese this past March when they only wanted read-only. I think Vito could have gotten the global group, but for others it doesn't make sense as they are only working with filters here on the English Wikipedia — MusikAnimal talk 02:40, 27 April 2017 (UTC)
Keeping this from archiving - Agree, lets keep this specialty out of PERM (just like EFM); we will need an advertised RfC to create this EFH group — xaosflux Talk 15:19, 8 May 2017 (UTC)
Happy to put an RfC together. So this would work like EFM; a post at this noticeboard with the request, open for 7 days? Should we put something in WP:EF regarding the criteria for being granted the user right? If so, what? Sam Walton (talk) 15:23, 8 May 2017 (UTC)
That sounds pretty good - the criteria is less stringent as they would not be able to actively disrupt editing; details on the process may change during an RfC (it is a request for comments after all :D ) but suggest starting with: "request at EFN"; 7 day discussion period; can be closed by any admin; minimum qualifications: maybe extended confirmed + demonstrated activity with edit filter assistance OR active administrator of another WMF site; no recent blocks or sanctions. requirements to maintain: should have decent account security; must not share private filters to unauthorized parties; must be active (removal after 1 year inactivity); -- I'm just throuhing ideas out here - perhaps draft this on a new page for more input. — xaosflux Talk 15:52, 8 May 2017 (UTC)
There needs to be a "need to know" requirement, such as demonstrated assistance at SPI or significant anti-vandal work. Non-admin SPI clerks once past training should automatically get this right. Since you brought up inactivity - does anyone actually remove TE/PM for inactivity? – Train2104 (t • c) 17:13, 8 May 2017 (UTC)
Yes - usually a few times a year batches of inactivities get cleaned up by various admins - generally a "no big deal" if someone comes back to readd. — xaosflux Talk 17:20, 8 May 2017 (UTC)

What's the current state of this - is an RFC being drafted somewhere? Thryduulf (talk) 14:28, 5 June 2017 (UTC)

It's basically stalled, @Thryduulf: if you are in the mood, here is the place to start the new RfC. — xaosflux Talk 23:11, 12 June 2017 (UTC)
I would appreciate having this right. I currently have EFM, but that's only for viewing purposes; if I've ever edited a filter, I don't remember it. Nyttend (talk) 03:37, 13 June 2017 (UTC)
@Nyttend: sysops now have (abusefilter-view-private) included with access, you do not need to hold the edit filter manager group for this purpose. Head over to Special:UserRights/Nyttend and toggle yourself off to see. This would be for adding "view only" access to all the filters to non-administrators (and possibly also viewing of the spam log as was done on meta). — xaosflux Talk 03:50, 13 June 2017 (UTC)

Edit filter helper right - pre-RFC discussion

As a final step before an RfC, I just want to see if there is local consensus for the following suggestions. They are numbered solely for ease of reference in this discussion, bullets (and possibly more expansive language) will likely be used in the final version.

'Process for requesting right

  1. Make a request for right here (WP:EFN)
  2. Discussion will be open at least 7 3 days
  3. If a previous application for edit filter manager or edit filter helper was unsuccessful, the following people should be notified of the new discussion:
    • Participants in the most recent discussion
    • The closing administrator of the most recent discussion
  4. If the edit filter manager or edit filter helper right was previously removed for any reason other than inactivity, the following people should be notified of the new discussion:
    • The administrator who removed the right
    • Participants in any discussion that resulted in the right being removed
    • The Arbitration Committee, if removal was at the committee's direction
  5. Discussion will be closed by an administrator
  6. If successful, an administrator will grant the right

Requirements for granting

  • Must meet all of these criteria:
    1. At least auto-confirmed
    2. Demonstrated need for access (e.g. SPI clerk, involvement with edit filters)
    3. No recent blocks or relevant sanctions
    4. At least basic understanding of account security
    5. At least basic understanding of regex
    6. Sufficient ability with the English language to understand notes and explanations for edit filters
  • Must also meet at least one of these criteria:
    1. Currently-active extended-confirmed editor on en.wp
    2. Current administrator on another WMF project
    3. Current edit filter manager on another WMF project
    4. Current WMF developer or staff member who needs access for WMF-related purposes (I expect this will be practically never needed, but it seems useful to have in case it is)

Requirements for retaining

  1. Currently active on en.wp (defined as making edits or logged actions within the last 12 months)
  2. Currently active with edit filters on en.wp (defined as making edits or logged actions related to edit filters within the last 12 months)
    Most "helpers" won't have logged actions since it is read only, most other advanced rights are just any activity - suggest we go there. — xaosflux Talk 14:59, 25 June 2017 (UTC)
  • Note these are alternates - please note which you prefer.

Reasons for removal (excluding inactivity)

  • Note this is not an exhaustive list - removal of the right will always be considered in these circumstances, but may be considered in other circumstances too.
  1. Sharing details of private filters with unauthorised parties
  2. Poor account security (including compromised and potentially compromised accounts)
  3. Abuse of edit filters
  4. Sanctioned by Arbcom or the community for actions that mean continued suitability is uncertain

Process for removing right

  1. Any user with the right who no longer meets the activity requirement must be notified of this on their talk page. This notification may be given by any user or by a bot.
  2. Any administrator may remove the right from any user who still does not meet the activity requirement 7 days after being notified. WP:EFN should be notified of the removal and reason.
  3. If the situation is urgent, any administrator may remove the right without prior notification. WP:EFN should be notified of the removal, giving reasons unless privacy or similar concerns prevent this.
  4. If the situation is not urgent, any user in good standing may make a request at WP:EFN for the right to be removed, giving reasons unless privacy or similar concerns prevent this (in which case, contact an administrator privately and note in the request you have done this). The user concerned must be notified on their talk page.
  5. Any discussion about the removal of the right will be closed by an administrator. Uncontroversial requests, including self-requests, will be closed when actioned, other requests will remain open until at least 7 days after the user was notified.

Everything above is draft. Requirements can be added, removed or changed. Please comment. Thryduulf (talk) 14:35, 25 June 2017 (UTC)

Struck some of the "notification" requiremetns for inactivity removal, this is not hard to get we don't need all that. The only admin-controled flag we do this on is ip-block exempt, as it may impact article editing. If someone expires out of this they can come ask for it back. — xaosflux Talk 14:57, 25 June 2017 (UTC)
I've tweaked your striking so that removal for inactivity is explicitly allowed. Thryduulf (talk) 16:47, 25 June 2017 (UTC)
  • We should specifically list out the included group names on this. It may be useful to also include viewing the spam blacklist log, it is related in that it is also a "filter" that can disallow edits and is sometimes the actual thing stopping an edit. — xaosflux Talk 14:57, 25 June 2017 (UTC)
    The exact permissions included in the global group should work here. -- Ajraddatz (talk) 19:48, 25 June 2017 (UTC)
    Many are already included in users here, need to add:
    (abusefilter-view-private) <What this is literally about>
    (spamblacklistlog) <related spam blacklist filter>
    (titleblacklistlog) <future titleblacklist filter log> phab:T68450 — xaosflux Talk 20:11, 25 June 2017 (UTC)
    Good point. Titleblacklistlog probably shouldn't be included at this point, given the continuing debate over what it should show, and the lack of technical implementation at the moment. (abusefilter-log-private) could be included as well. -- Ajraddatz (talk) 20:26, 25 June 2017 (UTC)
    Striken, abusefilter-log-private does not appear to exist? — xaosflux Talk 23:00, 25 June 2017 (UTC)
    The right exists, but isn't included in any local group here. It must be included as part of a higher-level right, maybe abusefilter-modify, so it's never needed to be explicitly bundled in to a group. Then again, it might be included in abusefilter-view-private - I'll test and get back to you on that. Edit: Looks like it is included in abusefilter-view-private, so good to go without it. -- Ajraddatz (talk) 02:12, 26 June 2017 (UTC)
  • A 7 day voting period for read-only rights seems a bit excessive. I can't remember what the norm is on Meta these days for the global group, but 24-48 hours or even just admin approval would probably be sufficient here. As for reasons for removal, abuse of edit filters would be difficult give there is no write access given here. Other than that, the proposal looks reasonable. Though it still makes me a little sad to support adding to the endless number of non-sysop groups on enwiki for people that would have just been made admins 10 years ago, but this is perhaps one of the more useful proposals out of the recent ones. -- Ajraddatz (talk) 19:45, 25 June 2017 (UTC)
    I'd be good with reducing to from 7 to 3. — xaosflux Talk 20:11, 25 June 2017 (UTC)
    Yep, made the request period 3 days. I've left the removal discussion unchanged though. While abusing the edit filters themselves with read only access would be almost(?) impossible, it would be possible to edit around private filters or to flood filter logs. It's also useful to have in case someone does find a way to abuse them. Thryduulf (talk) 23:02, 25 June 2017 (UTC)
    3 days is more reasonable. Fair point with working around; hopefully it won't ever be an issue, but there certainly isn't a cost to keeping that condition in there. -- Ajraddatz (talk) 02:12, 26 June 2017 (UTC)
  • I'm going to suggest that anyone who successfully completes the SPI clerk training be automatically granted the right if they are not an administrator, and that administrators be authorized to grant temporary rights to clerk trainees at their discretion, to be removed immediately should the user not complete the training. – Train2104 (t • c) 00:03, 26 June 2017 (UTC)
    @Train2104: what is involved in "completing" that? — xaosflux Talk 00:05, 26 June 2017 (UTC)
    I'm not familiar with the clerk training process, but WP:SPI/C says ...until the Checkusers (at the recommendation of a clerk) feel the trainee's track record demonstrates sufficient judgment and experience to be relied upon without supervision. – Train2104 (t • c) 13:46, 26 June 2017 (UTC)
    I'm fine with "Checkuser discretion" to add this to any editor a checkuser deems necessary. — xaosflux Talk 14:38, 26 June 2017 (UTC)
    I think I'd be OK with a checkuser giving it to anyone actively helping with CUs would would benefit, providing they meet the normal requirements and haven't had the edit filter helper or edit filter manager right removed previously for cause. Anyone who has had it removed for cause previously should come through the normal process. Thryduulf (talk) 20:40, 27 June 2017 (UTC)

Edit filter helper right - refined proposal

Based on the above discussion, I will put the following to an RfC in a few days if there are not further objections. Please particularly check I've got the technical bit at the start correct, if I haven't please just fix it. Also feel free to make any other changes you feel are uncontroversial but comment with more substantial changes. Thryduulf (talk) 10:10, 31 July 2017 (UTC)

Edit filter helper user right

The rights The edit-filter-helper user right includes the following user rights:

  • abusefilter-view-private - allows viewing of private edit filters
  • spamblacklistlog - allows viewing the spam black list log

It does not confer a right to edit filters.

Granting the right

The edit filter helper right may be granted in the following circumstances:

  1. A Checkuser may, at their discretion, grant this right to a Wikipedia:Sockpuppet investigations (WP:SPI) clerk or trainee clerk who:
    • Meets the criteria in the "Requirements for granting" section
    • Has not had an edit filter-related right removed previously for any reason other than inactivity.
  2. By any administrator following a successful request at Wikipedia:Edit filter noticeboard.

Process for requesting

In a new section, make a request at Wikipedia:Edit filter noticeboard (WP:EFN).

  • If a previous application for edit filter manager or edit filter helper was unsuccessful, the following people should be notified of the new discussion:
    • Participants in the most recent discussion
    • The closing administrator of the most recent discussion
  • If the edit filter manager or edit filter helper right was previously removed for any reason other than inactivity, the following people should be notified of the new discussion:
    • The administrator who removed the right
    • Participants in any discussion that resulted in the right being removed
    • The Arbitration Committee, if removal was at the committee's direction
  • The discussion will be open at least 3 days.
  • The discussion will be closed by an administrator, who will grant the right if the request was successful.

Requirements for granting

  • Must meet all of these criteria:
    1. Demonstrated need for access (e.g. SPI clerk, involvement with edit filters)
    2. No recent blocks or relevant sanctions
    3. At least basic understanding of account security
    4. At least basic understanding of regular expressions if the intent is to assist with authoring filters
    5. Sufficient ability with the English language to understand notes and explanations for edit filters
  • Must also meet at least one of these criteria:
    1. Currently-active extended confirmed editor on the English Wikipedia (i.e. the user has made edits or logged actions within the last 12 months)
    2. Current administrator on another WMF project
    3. Current edit filter manager on another WMF project
    4. Current WMF developer or staff member who needs access for WMF-related purposes

Requirements for retaining

  • Currently active on the English Wikipedia (i.e. the user has made edits or logged actions within the last 12 months)

Reasons for removal (excluding inactivity)

Note this is not an exhaustive list - removal of the right will always be considered in these circumstances, but may be considered in other circumstances too.

  • Sharing details of private filters with unauthorised parties
  • Poor account security (including compromised and potentially compromised accounts)
  • Abuse of edit filters
  • Sanctioned by Arbcom or the community for actions that mean continued suitability is in doubt

Process for removing right

For inactivity:

  • Any administrator may remove the right from any user who does not meet the activity requirement.

For other reasons:

  • If the situation is urgent:
    • Any administrator may remove the right without prior notification.
    • WP:EFN should be notified of the removal, giving reasons unless privacy or similar concerns prevent this (in which case, contact an administrator privately and note you have done this).
  • If the situation is not urgent:
    • Any user in good standing may make a request at WP:EFN for the right to be removed, giving reasons unless privacy or similar concerns prevent this (in which case, contact an administrator privately and note in the request you have done this).

In all cases:

  • The user concerned must be notified on their talk page.
  • Any discussion about the removal of the right will be closed by an administrator, who will remove the right if required and there is consensus to do so. Uncontroversial requests, including self-requests, will be closed when actioned, other requests will remain open until at least 7 days after the user was notified.

Pinging those who have commented previously: @Ks0stm, Xaosflux, Dane, Samwalton9, DatGuy, MusikAnimal, Train2104, Nyttend, and Ajraddatz: Thryduulf (talk) 10:13, 31 July 2017 (UTC)

@Thryduulf: Looks pretty good to me. — xaosflux Talk 11:23, 31 July 2017 (UTC)
Yes, looks fine to me. Thryduulf, if you're striking a 7, please strike text next to it too; on first glance, I thought you were proposing a 73-day discussion period and wondered how/why you'd gotten it to display a slash like a handwritten numeral :-) Nyttend (talk) 11:44, 31 July 2017 (UTC)
's a lot of text. Sure that it is strictly necessary? Jo-Jo Eumerus (talk, contributions) 12:08, 31 July 2017 (UTC)
This Salvidrim guy can't read. Salvidumbass! (talk) 18:28, 31 July 2017 (UTC)
  • Any administrator may remove the right from any user who does not meet the activity requirement. - These activity requirements are defined where? Ben – Salvidrim! ✉ 14:27, 31 July 2017 (UTC)
    @Salvidrim: the user has made edits or logged actions within the last 12 months) — xaosflux Talk 14:52, 31 July 2017 (UTC)
    That's one of the four granting criteria for EFH... so if the user has no edits on enwiki but is an frwiki sysop (for example), he could be granted EFH, and then immediately removed for not meeting activity requirements? The granting criteria and removal criteria need to be explicitly defined (and probably separately). Ben – Salvidrim! ✉ 14:57, 31 July 2017 (UTC)
    That is under the "Requirements for retaining" specific section already, and no - the fact that they asked for it would already mean they have an "edit" in the last year. — xaosflux Talk 15:49, 31 July 2017 (UTC)
    @Salvidrim: The granting criteria ("requirements for granting") and removal criteria ("requirements for retaining", "reasons for removal") are explicitly defined separately already. If the headings could be improved to make this more obvious, then please suggest alternatives - what you see is just my best effort, and I'm no particuar expert on these things. The "Requirements for retaining" is intentionally plural and general to fit with the others and to allow it to allow it to remain should the requirements change at any time without breaking any links. Thryduulf (talk) 17:42, 31 July 2017 (UTC)
Looks fine to me, if a bit lengthy. Usually we don't include "X must be notified" in user rights granting procedures, though. Also, should we include the ability to set up 2FA as one of the flags? – Train2104 (t • c) 15:43, 31 July 2017 (UTC)
I added the (oathauth-enable) to the list above. — xaosflux Talk 15:51, 31 July 2017 (UTC)
@Train2104: the lengthiness is because this is the combined information, requirements and procedures page about the right - it doesn't exist yet so all three need to be created and I don't see that there is any benefit to having that spread over three pages. As noted by Xaosflux it will go on Wikipedia:Edit filter helper (WP:EFH is conveniently available too) and the RfC here will be about approving (or not) the right and the processes defined there (and any consequential changes to the information pages about edit filters and usergroups, but they'll be uncontroversial simple factual updates that can be added and tweaked by the people who maintain those pages, so do not need to be explicitly defined). Thryduulf (talk) 17:42, 31 July 2017 (UTC)
  • One complaint: At least basic understanding of regular expressions – I don't think that should apply here. Many of the SPI clerks and interested parties merely need to view the private logs. They of course are welcome to suggest changes to filters, but that's not what the edit filter helper right is for. If I trust a user with the private logs, and they're competent at regex, I'd probably be OK with giving them write access.
    Secondly, just a general comment: While I think including 2FA is fine (hopefully all users will have this ability at some point!), here I don't think it is pertinent. You can do zero damage by viewing filter and spam blacklist logs alone. The likelihood of one of the socks breaking into your account to figure out how to get around a filter seems very low. Instead of trial and erroring with your password, they'd have an easier time trial and erroring to get around the filter. Just my two cents... but like I said I don't think adding 2FA is a bad idea, I just wanted to point out the need for additional account security isn't really there with a view-only right (at least one that doesn't reveal super sensitive data such as checkuser logs) — MusikAnimal talk 16:41, 31 July 2017 (UTC)
    • @MusikAnimal: My thought process for including it was so that people could at least get the gist of what the edit filter was doing, but then I wasn't really thinking about SPI helper uses when drafting it. I'm not greatly attached to it, but what do others think? I'd say that 2FA isn't required for edit filter helpers, but if I've understood the right correctly then all it does is allow (not require) people to enable it. I don't see how that would be harmful? Thryduulf (talk) 17:42, 31 July 2017 (UTC)
      • Nope, definitely not harmful. As I said, it's fine to include 2FA. I was just pointing out that this new right does not privilege a user with anything that could cause damage. The clause about having to have familiarity with regex however is something I would remove — MusikAnimal talk 17:54, 31 July 2017 (UTC)
        • Yea, it's a GOOD to have and belongs on WP:EFH, but don't think it needs to be a "requirement" - along with the requirement for "basic understanding of account security": how are we going to "measure" this? (make them take a test?, "Enter your password in to this autofill form to continue!"). — xaosflux Talk 17:57, 31 July 2017 (UTC)
          • I was going to say the same. Basic account security is generally common knowledge, and we have no way to verify if they're actually following it, and again this right isn't that sensitive. Removing this would also take out some of the wordiness with the proposal. My 2 cents! :) — MusikAnimal talk 18:04, 31 July 2017 (UTC)
          • (edit conflict) @Xaosflux: I'm unclear what you are saying is a good thing to have - 2FA or basic knowledge of regex? Where would you put "good to haves"? I don't think we need to define how a basic understanding of account security will be verified in this page (particularly as what constitutes reasonable basic security may change over time with changes in technology, etc), but I imagine it being an implied self declaration thing by those requesting the right (i.e. by requesting the right you implicitly declare you meet the requirements) - good faith would be assumed unless there was a reason not to. Thryduulf (talk) 18:14, 31 July 2017 (UTC)
            • I took back out 2fa, it's really not needed here. For any "requirements" (like regex experience) - how do you intend to actually measure this? — xaosflux Talk 11:36, 1 August 2017 (UTC)
              • As I noted above, I wasn't intending it to be measured. It's a question of asking the candidate "do you have this knowledge?" if they say "yes" then AGF that they do unless there is some reason not to. It's as much a guide to what is useful for the job and a way to dissuade hat collectors than a strict "requirement" as such. If you can think of a better way to achieve this then suggest it but the ask and AGF the answer seems likely to be sufficient for what is not a very powerful right. If you don't think it's necessary to have at all then say so. If you'd prefer it as a "good to have" rather than a requirement, suggest how to indicate that. Thryduulf (talk) 14:58, 1 August 2017 (UTC)

OK, think its good enough to go forward. @MusikAnimal: you may be interested in meta:Requests for comment/Expand two-factor verification as an option for all users on all wikis . — xaosflux Talk 02:10, 3 August 2017 (UTC)

  • I've just had a thought about the requirements for account security and regex knowledge and so propose to link them to a footnote about it. My first draft of that footnote is: "There is no formal definition of what constitutes a "basic understanding", but by requesting this right you are asserting that you meet these criteria. Those commenting on the request should assume good faith regarding this assertion unless they have a reason to do otherwise.". I think that wording could be improved though - suggestions welcome. Thryduulf (talk) 11:05, 3 August 2017 (UTC)
    • I still think we should remove the bit about "basic understanding of regex", even with the footnote. I understand we want to discourage hat collectors, but you might also discourage SPI clerks and those tracking LTAs who just need to see the logs. Why are they expected to have any understanding of regex? Or, how about rewording to "Basic understanding of regex, if the intent is to help with the filters". That makes it requirement for the relevant use-case — MusikAnimal talk 15:14, 3 August 2017 (UTC)
  • Given that it's been a few days since the last comments, unless there are objections in the mean tiem I'll start an RfC on this tomorrow (UK time) using the version as it exists above including MusikAnimal's amendments. Thryduulf (talk) 08:53, 13 August 2017 (UTC)
  • RfC now live in the #RFC - creation of the edit filter helper user right section below. Thryduulf (talk) 14:30, 14 August 2017 (UTC)

Filter 642

Can someone please modify 642 to allow admins? Because it only allows OTRS users, it prevents cleanup of things like [3] where someone subst'd the tag. --B (talk) 22:23, 14 August 2017 (UTC)

Why is this filter set to disallow anyway? The end goal is essentially that of of Special:AbuseFilter/856, which doesn't even warn, let alone disallow. – Train2104 (t • c) 22:44, 14 August 2017 (UTC)
It looks like DeltaQuad was the one who set it to disallow in January this year. Thryduulf (talk) 23:31, 14 August 2017 (UTC)
We had a problem that was identified in January where non-OTRS agents were adding OTRS templates. This resulted in files being marked as verified to a specific ticket when nothing of the sort had happened, essentially tricking editors who couldn't view OTRS (and readers!) into thinking the content was free. That's rather serious, which is why the filter was set to disallow. Keep in mind that we have an OTRS noticeboard that anyone can use to request OTRS assistance from those who can edit through the filter. The sysop exception is fine. ~ Rob13Talk 09:54, 20 August 2017 (UTC)

Can someone more competent than me take a look

Tracked in Phabricator
Task T173977

I know essentially nothing about how the edit filters work. I just removed a false positive from WP:AIV/TB2. SorinaPopescu was reported for triggering filter 279. But when I click on the "diff" link in the EF log, it's showing edits by Dilloncoulter. Why are Dilloncoulter's edits showing up in the edit filter logs of SorinaPopescu? See [4]. Both editors seem to be good faith editors, so also not sure why either one is triggering a vandalism filter. --Floquenbeam (talk) 16:07, 23 August 2017 (UTC)

Related question: where is the best place to report a filter's false positive? Here? --Floquenbeam (talk) 16:08, 23 August 2017 (UTC)
  • The log, examine, and details panes seem to show Sorina's edits, but the Diff link in the EF log shows Dillon's... odd... And Sorina hasn't edited since since Aug 10. CrowCaw 18:18, 23 August 2017 (UTC)
  • First, "repeated attempts to vandalize" is a misnomer, since all that filter does is look for repeated edits that failed to save. Here however they did save, yet somehow the filter was triggered numerous times for a single action, and the edit wasn't tagged which that filter is supposed to do. Baffling! I'm going to create a bug in Phabricator — MusikAnimal talk 18:58, 23 August 2017 (UTC)
    Tracked at phab:T173977. If I'm wrong about anything I said, please comment there or ping me here. Best — MusikAnimal talk 19:53, 23 August 2017 (UTC)

Filter 351 doesn't work properly

This filter does not work as well as it used to. Before it was modified in 2013 (history), the filter would catch edits that added content after categories (example), but now it does not ([5] [6]) (the filter applies to the Category namespace in addition to the mainspace). This is the change that messed up the filter. I was thinking that it should be fixed to the pre-2013 version and look something like this (most of it copied from the pre-2013 version): 

! 'confirmed' in user_groups &
old_size > 0 &
(article_namespace == 0 | article_namespace == 14) &
removed_lines rlike '^\[\[([a-z]{2,3}|Category):.*\]\] *$' &
strpos(added_lines, removed_lines) == 0 &
 (
  add := substr(added_lines, length(removed_lines));
  substr(new_wikitext, length(new_wikitext)+1-length(add)) + '\n' == add
  &! contains_any(add,'{{','[[')
 )
& !(rcount("(^|\n)\s*\S",added_lines) = rcount("(^|\n)\[\[",added_lines)
)

...which is similar to what the filter used to look like. Fixing it would then catch edits that actually added text after categories again. —MRD2014 Talk • Edits • Help! 19:26, 17 August 2017 (UTC)

Ping to @Materialscientist: who made the change you referenced. — xaosflux Talk 12:01, 18 August 2017 (UTC)
In 2013 the filter stopped working. Completely. My change was a quick hack (copy/paste from pt.wiki), I didn't expect it would work well here. Revert me at will, I haven't designed this filter, and can't make time to investigate the problem these days. Materialscientist (talk) 23:30, 18 August 2017 (UTC)
It would appear that the purpose of the edit in question is to prevent the exception of interwikis - which belonged after the categories before 2013, but now belong on WikiData. עוד מישהו Od Mishehu 09:05, 20 August 2017 (UTC)
Re-titled section to give a better idea of what's going on with the filter. —MRD2014 Talk • Edits • Help! 01:43, 25 August 2017 (UTC)

Special:AbuseFilter/684 disallowing

Recent uptick in some vandalism from proxies - no false positives yet but likely to have some. I'm monitoring the log, and will keep it disallowed for the shortest period possible. Any eyes on the log would be appreciated -- There'sNoTime (to explain) 12:58, 30 August 2017 (UTC)

There have been some (4) false positives, but the abuse is still ongoing - keeping the filter disallowing -- There'sNoTime (to explain) 13:09, 30 August 2017 (UTC)

Filter 869

Unless I'm misreading the filter log, filter 869 (the WP:DAILYMAIL filter) does not seem to actually be warning anyone, which is its entire purpose. And unless I'm misreading the filter, that's because the warning function was never enabled. Assuming I'm right about that, could someone please enable it?

An additional concern, though, is that AFAICT there has never been a proper consensus to treat The Daily Star and The Sun the same way that The Daily Mail is treated. The Mail RfC was seen as meriting a five-editor closing panel, while, unless I'm missing something, the only consensus regarding the Star and Sun was a six-comment exchange among four users at AN. On a personal level, I would tend to agree that the Star and Sun should be banned, but on an administrative level I seriously question whether it is appropriate for an edit filter to do so with so little consensus.

If someone is willing to enable the warning function, I would propose the following text for MediaWiki:Abusefilter-tabloid-warning:

If consensus is that we should retain the Star and Sun filtering as well, I'm happy to redraft. But the lack of a significant consensus to cite makes that challenging, which is why I propose removing them from the filter (for now). — PinkAmpers&(Je vous invite à me parler) 00:23, 27 August 2017 (UTC)

This filter is new this month, expect it is still being tuned. It is currently in "log only" mode. — xaosflux Talk 00:56, 27 August 2017 (UTC)
In case anyone's looked at the filter's history and is looking to me for a comment, this is my current take on it. I would say a trawl through the hits to date would be in order to resolve, in particular, the 'sports issue'. It seems other aspects discussed above also need some consideration. So I'll ping @Ritchie333: -- zzuuzz (talk) 16:12, 4 September 2017 (UTC)
For now, I think keeping an eye on this link and checking the total (now 1,775) gradually reduces. I think that's more important than the filter. Ritchie333 (talk) (cont) 16:18, 4 September 2017 (UTC)

Filter 877

I plan on setting filter 877 to disallow shortly. I'll keep as much of an eye on the false positives as I can, but feel free to disable it in favour of other remedies if there's any problems. It is no more restrictive than other solutions, and will probably be in place for at least a few weeks. And if anyone has any other ideas... -- zzuuzz (talk) 16:18, 4 September 2017 (UTC)

Need someone smarter than me to figure out this left bracket thing.

I apologize in advance - this side of Wikipedia is emphatically NOT my area. I only know about commas. Please treat me like I'm five.

I'm not sure if an edit filter is even the best way to handle a problem I've been running across, but it might be. I would love to hand this over to someone else.

For a couple of days I've been running across a lot of recent edits which change < into the unicode characters for that symbol (& l t ;). No other text is added or removed. Occasionally & and > are changed as well. Sometimes just a few characters are changed, but sometimes the damage is massive and breaks the page. You can see an example at today's edits on United States federal executive departments, where over sixty characters were changed, which ruined a table.

In the vast majority of these edits, it's the sole edit made by an IP. I haven't seen this done multiple times to the same article. So contacting/banning the user or protecting the article probably won't help.

I'll be glad to provide any additional info (relevant info may also be gleaned from my recent edits - about half of them have been about this, which should be clear from the summaries). Frankly, I'd love to turn this over to someone who will take the next step(s) in figuring this out, rather than telling me what the next step is... as I said, it's not my area, though I'm happy to keep fixing the errors as I find them. Thank you! Jessicapierce (talk) 16:45, 8 September 2017 (UTC)

Hi @Jessicapierce:, to start with please provide a few different specific diffs. The edit filter can basically: LOG, TAG, WARN, or PREVENT an edit. Assuming these can all be detected - it needs to be determined what the best action to take would be as well (we always would start with LOG to look for false positives as well). — xaosflux Talk 16:58, 8 September 2017 (UTC)
Sure thing, and thanks for your reply! And I forgot I did a bunch of standard copy editing last night, so this phenomenon is more frequent a bit farther back in my edit history. See Sidama Zone (edit), DNS Certification Authority Authorization (edit), T.Love (edit), Kansanshi mine (edit), Eclipsed (album) (edit). Jessicapierce (talk) 17:13, 8 September 2017 (UTC)
If you're interested, the cause is probably a broken content filter/proxy at the ISP's end. It seems there's a pattern related either to mobile editing, or to particular networks, examples: 197.156.102.35, 197.156.102.36, 197.156.115.177, 197.156.122.171, 119.30.35.96, 105.166.145.92, 105.166.144.43, 105.166.222.194. And like any broken proxy it also affects logged in users. We could probably adapt or model something on the 'broken proxy' filter (464). -- zzuuzz (talk) 17:28, 8 September 2017 (UTC)
This would probably be better listed at WP:EFR. I'll drop a request there. -- zzuuzz (talk) 18:06, 8 September 2017 (UTC)
Thanks very much! Jessicapierce (talk) 20:25, 8 September 2017 (UTC)

Should the logs of private filters be completely hidden?

Tracked in Phabricator
Task T174862

Non-admin/EFMs cannot view the logs of a private filter when attempting to view them directly (example) -- yet the hits still show up at Special:AbuseLog, meaning you could piece together the log manually. I feel like if we are hiding the logs in one place, we should hide them everywhere. This includes specifying a user (example), or a page. There are some cases I've ran into where the fact that these log entries are public was problematic. For instance, there could be a log-only filter that is used only for observation, and the LTA can see that they are tripping it in their own logs, and will adjust their M.O. accordingly. Also, it'd be nice to make the names of our private filters more descriptive. Currently we have to be intentionally vague as we know they are public. So I created phab:T174862 to change this behaviour and hide the logs entirely.

However I wanted to get input here first, because this would mean that non-admins/EFMs will have no way of knowing a user tripped a private filter at all, much less which one. This may be problematic for users who have encountered a false positive, for example. They'd have to consult an EFM/admin to verify a filter was even hit. Secondly, it could be argued that seeing what private filters a user tripped would be helpful to recent changes patrollers. Normally we only report to WP:AIV if they've been warned sufficiently, but if they have a page full of filter hits maybe that's a sign admin attention is needed.

My thoughts are that private filters should be private, period. The false positive issue might happen every once in awhile, but anyone working at WP:EF/FP who can't see the filter can just defer to someone who can. As for the patrollers, they probably shouldn't take into account any private filters since they can't see what they are for, or know if it was a false positive. Again, some private filters are log-only, used only for observation, and may regularly encounter false positives (which I think is OK).

What do you all think? Is it a good idea to hide the logs of private filters across the board? Would this be controversial enough to warrant an RfC? If we do move forward with this, I think we should be more careful about which filters we do make private. — MusikAnimal talk 23:07, 8 September 2017 (UTC)

  • I agree that private should be private in all circumstances. If the edit filter helper RFC passes then any non-admin, non-EFM regularly helping deal with the false positives reported would be able to request that right so they could see the relevant logs. At the phab ticket there is discussion about whether the filter number should be visible (e.g. abuse log would show only "Private filter #123" to those without view access to private logs). I haven't thought very long about that, but my initial thoughts are that it would be unlikely to cause problems in all but extreme edge cases when we'd probably want to take stronger measures against the abuser anyway. Thryduulf (talk) 23:26, 8 September 2017 (UTC)
  • Agree too. In the past, despite not having access to viewing private filters, I've been able to access the logs and have wondered about that. With respect to recent change patrollers, the main UAA/BLP vandalism/promotional name/autobiography/link-spam/etc filters (and logs) are public and that's absolutely more than enough (in my opinion). Anyone with an issue with private filter logs can easily refer to an admin active here. No need for an Rfc here and invite public attention to an area that specifically needs to avoid such attention. Lourdes 07:32, 9 September 2017 (UTC)
  • As best I can piece this together, you want to make all logs private for the sake of them being named private filters. Is there any indication that the logs are being abused? Will this move prevent abuse? Will there be any benefits here, or perhaps just make it more difficult for non-admins to respond to vandalism? The point of a private filter is - or should be - to hide the code of the filter so that committed vandals need to take an extra 10 seconds to guess their way around the regex. I'm not sure that there would be added benefit here. -- Ajraddatz (talk) 08:32, 9 September 2017 (UTC)
    • @Ajraddatz: My theoretical example in the first paragraph is exactly what happened recently. I don't want to go into too many specifics, but it was the log-only private filter that was discovered and this caused problems. Either way, surely you find it odd that I can see the logs at Special:AbuseLog, but not when I try to view the logs of the filter directly? I'd like to at least address that — MusikAnimal talk 17:47, 9 September 2017 (UTC)
      • It is odd, but not necessarily bad. I'm concerned with putting more and more technical abilities behind a user group barrier, when there isn't much indication that they've been widely abused. -- Ajraddatz (talk) 18:06, 9 September 2017 (UTC)
        • It's not that they've been abused as much as it is that they can announce the filter's existence to the very people we were hiding it from by making it private. There's no real way to quantify how often a savvy vandal has figured out from his filter log that he's hitting a regex. Hiding that log may still not fix every case, but the potential benefit would seem to out-weigh any downsides (see my "concern" section a few paragraphs down). CrowCaw 20:14, 9 September 2017 (UTC)
  • I'm finding it hard to think of any benefit in hiding a hit to the filter when the filter is set to disallow or warn. The user will always know it has happened. Currently the filter log will display an entry such as "triggered an edit filter, performing the action "edit" on <page name>. Actions taken: Disallow; Filter description: <filter name>" If anything we could just remove the filter name or replace it with the filter number in these cases. This would help, to some extent, with the false positive issue mentioned above. Alongside this there is also the question of whether to show the filter name alongside the number in the list of filters - this is one place where vagueness is useful to hide a filter's purpose. Perhaps the filter's name should also be hidden there, as the number of hits already is. I don't think hiding the logs will be magic pixie dust to solve the problem (or always helpful) where warn/disallow is involved, but I can see some benefit to not showing any hits to private log-only filters. -- zzuuzz (talk) 09:14, 9 September 2017 (UTC)
    • Yes, the filter log for non efm's will only say it tripped a log on an edit. If the edit was disallowed, there will be no diff or examine link, so the log isn't saying anything that the blockee doesn't already know (except for possibly why their edit failed). CrowCaw 16:22, 9 September 2017 (UTC)
      • Yeah, per above, what prompted this proposal was an incident where the existence of a log-only private filter was discovered at Special:AbuseLog, and the LTA responded accordingly, while other users were overly inquisitive of what the filter was for. You probably know what I'm talking about. We could have been more vague with the filter names, but it sucks that we have to do that. We see "LTA #123" and have to view it to find out what it's about. Either way, I find it odd that while logged out, I can't see the logs of a filter directly, but I can see them at Special:AbuseLog. An inconsistency, to say the least — MusikAnimal talk 17:47, 9 September 2017 (UTC)
  • I'm generally in favor, but I have a couple of concerns: First, people caught up in false positives will have no idea why or where to report them. Second, admins patrolling the DatBot listings at AIV may not be able to assess the report properly, which may lead to Thirdly, this may lower the bar of "demonstrated need" for the EFHelper permission, which may not be desirable. CrowCaw 19:01, 9 September 2017 (UTC)
    All messages that are shown with a disallowing filter should include a link to WP:EF/FP. Most FPs happen to new users because most filters target new users, especially those that disallow, so they won't be any more confused than they are now. It'd be the experienced users who might get confused, but again all they need to do is report it and EFMs will have a look. DatBot would have to be granted EFM or edit filter helper (if that happens). All admins can see private filter details and logs, so no worries there — MusikAnimal talk 19:25, 9 September 2017 (UTC)
  • Got it, thanks! So this would only prevent private log-only filters from leaking their existence to those being tracked, since disallows would still let the editor know via the FP link, and tag-only filters announce themselves via the tag? This then seems like a fairly harmless addition to me... since you need to be an EFM/admin to see private filters, it seems logical that the logs should also be hidden, especially if no innocent users will be more harmed/restricted/confused by this. CrowCaw 20:10, 9 September 2017 (UTC)

Upper limit to filter numbers?

More out of curiosity than anything else, does the AbuseFilter extension have an upper limit in terms of filter numbers, or would we hit a performance "limit" before we got to any sort of cap? -- There'sNoTime (to explain) 07:21, 11 September 2017 (UTC)

There is no upper limit on filter numbers that I am aware of or have seen in the code. But any limits to the number of filters would be caused by their run time - the time they add to the process of saving edits. If there were a million filters but they did not impact run time, then there would be no problem. If there was one massive filter that added five seconds to the run time, it wouldn't be good. I can't remember if there is a strict performance limit, but I think there is... someone else will probably know that :-) -- Ajraddatz (talk) 07:27, 11 September 2017 (UTC)
There's effectively a limit on the number of filters, but not directly. As far as I understand it when an edit gets made it gets checked against every filter, going through each filter's conditions until it his a dead end. If an edit reaches 1000 conditions, the rest are skipped. As such we need to keep the number of filter conditions in check, but not necessarily the number of filters. Sam Walton (talk) 10:56, 11 September 2017 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Edit_filter_noticeboard/Archive_2&oldid=1136459752"