Wikipedia talk:Edit filter

Where was the community vote on creating an additional privilege above "admin"?

I don't recall anything like that ever showing up in a watchlist notice. And I don't see the RfAFE's for these people either. --Random832 (contribs) 12:54, 23 March 2009 (UTC)

Did you not get the memo?? Happy‑melon 12:58, 23 March 2009 (UTC)

New software features come about all the time. The developers don't sit around seeking consensus for new features. We develop policy as it is needed. Chillum 13:00, 23 March 2009 (UTC)

A feature is one thing, the implementation of this as a separate user group vs including within sysop is something that the devs tend to follow individual project consensus on - so where was the consensus for this? And how did these people in particular get this flag? If there is no process, then there will be no objection to me going down this list and giving it to everyone on it, right? --Random832 (contribs) 13:05, 23 March 2009 (UTC)

Sysops can grant themselves the AFE right if they want to muck around with the AF. There's no additional red tape. AFE is not "above sysop", it's just granted to (or taken by) those who need it to edit or view private filters. Giving it out to every sysop would be pointy imo, and a waste of time. There is discussion above somewhere about rolling the right into the sysop package and another one about whether it is a good idea to consider granting it to non-sysops. –xeno (talk) 13:09, 23 March 2009 (UTC)

How would it be pointy? Given that every current AFE is also an admin; and that there seems to be no objection to admins granting themselves this flag without any discussion, it seems that the reality is that abusefilter-modify is an admin permission. If any admin is entitled to have the ability to modify filters, then there is no advantage whatsoever for the permissions not to be included in 'sysop'. It's not like an admin can 'accidentally' modify a filter if they don't intend to work in that area. Happy‑melon 14:05, 23 March 2009 (UTC)

Spamming the userrights log to make a point? (When I said "giving it out to every sysop", I was referring to Random's suggestion that he might go down the list of sysops and grant every one of them AFE) –xeno (talk) 14:08, 23 March 2009 (UTC)

Oh, sorry, I misread you. Yes, manually granting the 'abusefilter' flag to every current admin would be pointy. I thought you were talking about bundling the same rights into 'sysop'. Do you have an opinion on that? Happy‑melon 14:11, 23 March 2009 (UTC)

Yea, I don't really see why not, other than it would make it harder to get a list of "sysops-who-muck-about-with-the-AF". –xeno (talk) 14:13, 23 March 2009 (UTC)

Modifications to filters are supposed to be logged in Special:Log; that code is disabled for the time being because one of MediaWiki's standard database tables needs to be changed slightly (a column expanded to allow it to take longer entries) to accomodate the data. Then we'll be able to search all filter changes in the normal way. Happy‑melon 14:37, 23 March 2009 (UTC)

I still see some value in having an actual list, rather than forcing someone to trawl through a log to find an AFE-active admin. –xeno (talk) 14:39, 23 March 2009 (UTC)

The list might be current now, but there's no reason why it should remain so; people are just as likely to add that bit, do a bit of work, then drift off, as they are in any other job. If you want to know who currently does renames, do you look at Special:ListUsers/bureaucrat?? People shouldn't have to look at logs or lists to find AFE-competent people; they ask in the appropriate forum and interested admins watch it. Happy‑melon 16:25, 23 March 2009 (UTC)

It is not about sysop vs not-sysop! Good lord no! It is about having the technical knowledge and sense to use such a powerful tool. We don't give it to every admin because many admins would not have a clue how to use it. If we do grant it to non-admins it should be on the basis of technical skill and trust. It is not above or below admin. This is not a 1 dimensional concept and it cannot be reduced to that. Chillum 14:26, 23 March 2009 (UTC)

A similar amount of technical knowledge is required to edit the Spam blacklist, complicated templates, to perform rangeblocks or to modify the site JavaScript. All of these facilities are available to all administrators by default. Yet the site has not collapsed under the weight of admins who "do not have a clue how to use [them]" randomly playing around with features they do not understand, because we have selected the admin community to be, in general, comprised of users who do not do such things. It is not possible to 'accidentally' modify these things, so if you make the good-faith assumption that admins will not mess with things they do not understand until they have gained that necessary understanding, there is no reason why the ability to modify filters should be three clicks away instead of two. Any admin can grant themselves the AFE flag and go fiddling, if they are comfortable that they know what they are doing. Any admin can go edit the spam blacklist, if they are comfortable that they know what they are doing. Where is the additional 'safety' in the former situation? Happy‑melon 14:43, 23 March 2009 (UTC)

I am not opposed to admins granting the right to themselves. I think that they can decide if they are capable of using a tricky tool. The primary advantage of having it as a separate user group is that we can grant it to capable and trusted users who are not admins. Chillum 15:20, 23 March 2009 (UTC)

Indeed, and that is a separate issue. What's being suggested is that the same permissions that are given by the AFE flag are also included in the 'admin' bundle; in exactly the same fashion as rollback or IPBE. We can discuss the issue of whether or not to give AFE out to non-admins separately, but at the moment every one of the AFE flags are held by users who are also admins; there's complete duplication. Admins are indeed capable of deciding if they are capable of using this tool; they don't need to be put through a nuclear warhead-style interlock if they decide they are comfortable using it. Happy‑melon 16:30, 23 March 2009 (UTC)

I think an admin can decide if they are capable of using it before assigning to themselves. I would hardly call it a "nuclear warhead-style interlock", it is the same procedure used to add or remove any user right. Automatically granting it as part of the admin package seems out of place. It should not be granted to all admins because a) not all admins should be using it b) it would give the appearance to others that simply being an admin qualifies you. Think of it as a little plastic lid covering a dangerous button that can be flipped up if it is really needed. Chillum 17:55, 23 March 2009 (UTC)

The "little plastic lid" idea is the analogy I was really going for, except that that implies that there is nothing else to stop admins destroying the wiki. To screw up a filter from an empty browser, the admin needs to log in, type "Special:AbuseFilter" into the search bar, then scroll down, find a likely filter, click on it, change some settings, then click the "save" button. As opposed to logging in, typing "Special:UserRights/Jimbo", checking the AFE box, clicking save, then continuing the process? Do you really think that there is a danger of admins completing the first chain whilst sleepwalking, while the second will defeat them? Indeed admins can decide if they are capable of using it. Having decided, they don't need to go through extra sanity checks, that's the nuclear missile analogy. If an admin thinks they are capable of editing the filters, they will edit the filters. What's the benefit of the extra paper trail?

Your arguments against are, IMO, based on the continued misassumption that no one who has the technical permission is capable of resisting the temptation to use it. "simply being an admin qualifies you"... to do what? Being an admin qualifies you to have the technical ability to edit the filters; that's as true now as it would be if the permissions were bundled. Being qualified to actually implement and maintain filters is a status restricted neither to admins nor to AFE holders; but that's inevitable. Happy‑melon 19:10, 23 March 2009 (UTC)

We seem to be going round and round on something that in my personal opinion doesn't matter. The difference between having a right by default and having the right to add the right is very small. Could someone organize a vote or something so we can try to get some closure on this? Dragons flight (talk) 19:00, 23 March 2009 (UTC)

I agree that it's small; I wouldn't say it's irrelevant. I also agree that further cyclic discussion is unlikely to be constructive. I'll get a little staw poll going. Happy‑melon 19:11, 23 March 2009 (UTC)

Straw poll

“ Should the abusefilter-modify permission be included in the 'sysop' user right? ”

This will have the effect of giving all administrators the access to the Abuse Filter settings that is currently restricted to the 'abusefilter' group. This issue is separate from the question of whether the 'abusefilter' group should continue to exist and to whom it should be granted, which should be discussed separately. Please indicate support or opposition below. Happy‑melon

Pointless poll. Admins can already assign the right to anybody, including themselves, and the right is basically a technical right, people without the technical knowledge have no use for it, and those with it can get it easily and without problems. This right seems to be 100% noncontroversial, and we shouldn't run around demanding exhaustive community polls every time a new feature is enacted. The abusefilter feature has already been approved by the community, so this side trip down Pointless Poll Lane serves little purpose except to derail the implementation of an otherwise useful feature. Lets just let this be and move on. If an admin needs it, let them take it. If a non-admin needs it, let them get it from an admin. The number of people who are needed to maintain the abuse filter is diminishingly small, so there does not seem to be the need to enact this automatically for 1700 people, nor does there seem to be any need to demand a convoluted "approval" process to get this bit. This is a solution in search of a problem, and the entire thing is pointless. --Jayron32.talk.contribs 22:11, 23 March 2009 (UTC)

I'm not sure I understand much of what you're saying here. How on earth do you think that this poll is somehow intended to "derail" the AbuseFilter? If a non-admin needs it, let them indeed get it from an admin; although I suggested that we consider this issue separately, I'm generally in favour of retaining the separate AFE right to give to non-admins if desirable. But if an admin needs it, why the pointless paperwork of granting themselves an extra bell and whistle before getting to work? The situation is analogous to admins still being able to grant and revoke rollback, but needing to grant it to themselves before being able to use it. Happy‑melon 22:31, 23 March 2009 (UTC)

The status quo seems perfectly fine to me. Admins can give themselves the flag if they want to, and having this as a separate flag opens the possibility to give it to non-admins as well, should there be a consensus to do so in the future. --Conti|✉ 22:14, 23 March 2009 (UTC)

I agree, pointless poll. The setup seems to be working just fine at present. We can revisit this question of there are any serious problems, but for now let's just see how it goes. Tim Vickers (talk) 22:15, 23 March 2009 (UTC)

Well we both know there aren't going to be any problems that would be somehow magically 'fixed' by this change. Not all changes have to fix problems. Just because it's not broken doesn't mean it can't be improved. Happy‑melon 22:34, 23 March 2009 (UTC)

• I support its being included in the sysop package, as Administrators are already trusted with tasks of equivalent sensitivity (e.g. Spam blacklists) and hence should be trusted with this. The inclusion of this right would just save Admins a little bit of hassle, in my opinion; its presence does not oblige Sysops to make use of that right every day. To give a similar example, despite technically being able to edit others' .CSS and .JS pages (editusercssjs), upload a file from a URL address (upload_by_url) and mark rolled-back edits as bot edits (markbotedits), I have yet to actually use any of those aforementioned rights. This does not mean, however, that they should be removed from me, as they might come in useful one day. The fact of the matter is, Sysops are trusted not to use their rights with malicious intent, and, as such, the situation whereby they can make use of these technical features should remain. It Is Me Here ^{t / c} 22:18, 23 March 2009 (UTC)

• It's completely pointless. Admins can give themselves the ability or get it from a friendly fellow-admin. There's no need to give someone a right they're unlikely to need. This is totally different from ipexempt and rollback which many admins use frequently in day to day editing; the latter more than the first. This is an ability you only need when you plan on editing this. Keeping it separate allows us to give the right to non-admins (similar to the botflag) without giving them full admin rights they likely won't need. - Mgm|^(talk) 22:43, 23 March 2009 (UTC)

  Certainly we should keep the separate AFE flag in the same fashion as IPBE or accountcreator. But how is this permission different to those? How is it different to something like the spam blacklist? If the coin had come down the other way and the devs had added the permission to the sysop bundle to start with, would we be having this discussion in the other direction? I agree it's a minor issue, but I wouldn't say it's pointless. Happy‑melon 22:52, 23 March 2009 (UTC)

We probably might have. IPexempt, rollback and accountcreate don't require particular know-how to use. That's why I don't think this can properly be compared to those permissions. - Mgm|^(talk) 00:17, 24 March 2009 (UTC)

• Oppose It should be a separate flag. Flagging every admin is like saying every admin is able to understand how the filter works. I trust admins to decide if they are capable of using it safely then giving themselves the right. This extra step is not hard. Chillum 23:20, 23 March 2009 (UTC)

• Meh. Who cares? --Carnildo (talk) 00:46, 24 March 2009 (UTC)
• Oppose, with a dash of meh If someone want to edit the filter, they can op themselves. I would actually prefer that mediawiki and template namespace editing by disallowed in the same fashion for admins, but that's another issue. This is a simple way to keep track of who can edit the filter and a potential speed bump before editors who attempt to edit the filter but really shouldn't be (like me). Protonk (talk) 03:06, 24 March 2009 (UTC)
• Support. I see no reason not to bundle it into the sysop package. Ruslik (talk) 04:38, 24 March 2009 (UTC)
• Support Requiring admins add themselves to a group is a complete waste of time. BJ^Talk 10:37, 24 March 2009 (UTC)
• "Why bother" - As I stated above, I still see value in having the list of AFE flagged people easily accessible. –xeno (talk) 12:55, 24 March 2009 (UTC)

  If it were certain to be an accurate list, I would agree with you. Unfortunately experience with other user groups shows that it will not remain so. Happy‑melon 13:34, 24 March 2009 (UTC)

• Whats the point? Any admin does have it, they just need to click an extra switch. rootology (C)(T) 13:10, 24 March 2009 (UTC)

  Equally, why bother having to add an extra bell? What's the "point" in making them jump through an extra hoop? Happy‑melon 13:34, 24 March 2009 (UTC)

  Exactly. It simply doesn't matter, so why bother even making a fuss over it, and the specific way it was implemented? It's like complaining over a handful more onions than garlic in your meal, or a handful more garlic than onions. A week later, it won't matter since it has zero impact on anything of importance. rootology (C)(T) 13:52, 24 March 2009 (UTC)

  Yes, but in the honeymoon phase of AFE I think it'll be helpful. No need to rush into rolling it up. Jmho. –xeno (talk) 13:58, 24 March 2009 (UTC)

  Well said. We should at the very least wait until the use of the tool stabilizes before giving it out to people who have not even expressed a desire for it. Chillum 14:00, 24 March 2009 (UTC)

• "Pointless question" - Admins who need it can get it, just an extra couple of clicks. If they don't need it, or don't want to use it, then why bother giving it out. Are you also going to hand out AccountCreator, Huggle, VP and popups with the admin bit? Why even make a point about it. --Dirk Beetstra ^{T C} 13:56, 24 March 2009 (UTC)

  Exactly. Everyone knows I'm a Process Fan, since Good Process That Is Enforced Can Give Sunlight To Shenanigans, but this is like raising a fuss over garbagemen smoking a cigarette while they collect garbage instead of during "scheduled smoke breaks" for level of crisis. rootology (C)(T) 14:05, 24 March 2009 (UTC)

  Account creator and Huggle (through rollback) have already been given to all admins. Popups is not an admin tool. Ruslik (talk) 14:53, 24 March 2009 (UTC)

  Similarly for AWB, IPBE, and others. Happy‑melon 15:08, 24 March 2009 (UTC)

  Funny, last time I checked, I was not an Account creator, however, I can turn it on. And rollback != Huggle. You're right with popups, that is a free choice to use it, similar to AWB, IPBE, others .. and now (for admins), AbuseFilter. --Dirk Beetstra ^{T C} 19:14, 24 March 2009 (UTC)

• It may be of interest that there are already 105 people with the AFE right; all of them are administrators (this is 6% of all administrators, a higher percentage of all active ones); but only 45 have ever modified a filter. Interpret as you will. Happy‑melon 14:14, 24 March 2009 (UTC)

• Many are probably like me, that wanted to start out just reviewing filters. I'll probably do more later sometime, as I'm fairly familiar with regex (I should be, after years of use!). rootology (C)(T) 14:18, 24 March 2009 (UTC)

• I have the flag because I intend to use it and have confidence in my ability to do so. I intend to start slow after I have had time to read the instructions, so I have not yet used it. Chillum 14:27, 24 March 2009 (UTC)

• Support Current implementation makes little sense. — Jake Wartenberg 18:56, 24 March 2009 (UTC)
• Oppose bundling it with the admin right. It makes very little real difference, the only advantage with the current situation being that one can see which admins have given themselves the permission = have a rough idea of who uses it. Not a great advantage, I know, but decent enough, I think. ╟─TreasuryTag►contribs─╢ 19:16, 24 March 2009 (UTC)
• Support Admins can get it anyway, just by clicking a few buttons. The group should be used for users who are not administrators. Techman224^Talk 19:14, 28 March 2009 (UTC)
• Support, userright is cluttered enough as it is. The capability argument is not really relevant, since an incapable admin can give himself that right already. I'd support a separate right if it was given on a case by case basis by bureaucrats. -- lucasbfr ^talk 09:36, 29 March 2009 (UTC)
• Support – makes sense to me; see #Naive question. —Anonymous Dissident^Talk 11:39, 1 April 2009 (UTC)
• Oppose – ... multiple reasons:
  1. Abusefilter can cause temporary chaos (reversible, but the proverbial damage is done) if a filter is improperly crafted. This can range from slowdowns to accidentally preventing legitimate edits from going through to automatically removing autoconfirmed status on innocent users. Maybe it's just me, but I like the idea of encouraging an admin to sorta "figure out" abusefilter before adding himself to the group.
  2. "Be bold" does not, in my opinion, apply to abusefilter in the same way it does to editing. I think extreme caution needs to be taken on every abusefilter edit, and each of those edits should be treated as if you're walking on eggshells. There's something reassuring about asking an admin to add himself to the group as an informal contract to be careful— that is, "this is dangerous stuff. add yourself to the group with caution."
  3. It would possibly be easier to track who leak the contents of private filters to the public if the only admins who could leak those filters have to be in a specific usergroup (smaller pool size). From there it's logical deduction, so if you're not going to be editing abuse filters, an admin can stay out of the group unless otherwise needed.
  4. It also allows us to track bizarre, sudden self-group-adds to the abusefilter group on dormant admin accounts, which would allow us to more closely watch for compromised accounts before they can do any real damage should they then screw with the abusefilters.
     --slakr^\ talk / 01:48, 20 April 2009 (UTC)

Criteria for a Private Filter

Its come to my attention that wether a filter is private or not is largely down to the discression of the administrator who makes it and there are no guidelines as to what should be private and more importantly, what should not. Im of the opinion that all filters should be public unless an elaborate regex rule that could be easily circumvented if the regex was public (IE a meme pattern).

An example of a filter that should not be private is [1] and because it is an "as is" filter that cannot be circumvented. Another questionable regex is [2]   «l| Ψrometheăn ™|l»  (talk) 02:00, 27 March 2009 (UTC)

These filters both contain information that would assist an abusive user in circumventing them. –xeno (talk) 02:06, 27 March 2009 (UTC)

How can you circumvent a move throttle? seriously? and more to the point I bet any user could tell you what that filter contains either in full regex oy laymans terms, including the conditions.   «l| Ψrometheăn ™|l»  (talk) 02:09, 27 March 2009 (UTC)

Erm, it involves some beans? –xeno (talk) 02:11, 27 March 2009 (UTC)

Well because I don't know what the filter contains, one can but wonder how a simple move page vandalism filter need to be private for it to work and back to the inital statement, what constitutes a private filter?   «l| Ψrometheăn ™|l»  (talk) 02:14, 27 March 2009 (UTC)

He can't move pages until he is autoconfirmed by waiting 4 days and making 10 edits, and yet he routinely waits just long enough and makes just enough edits to do that. If he knew the specific requirements of those rules they would be just as beatable. (At least until we changed them anyway, but no one wants an arms war.) Dragons flight (talk) 02:17, 27 March 2009 (UTC)

This entire feature is an arms war, and apparently one fought by people who don't give a damn about civilian casualties (read: those of us who actually want to improve articles) -- 217.42.77.168 (talk) 17:12, 6 April 2009 (UTC)

We've tried public regex-based filters to prevent pagemove vandalism, with little noticeable effect. Mr.Z-man 03:45, 27 March 2009 (UTC)

That filter is quite different to the epic fail blacklist, but an email has provided me with a sufficent explanation to keep that filter private.   «l| Ψrometheăn ™|l»  (talk) 07:04, 27 March 2009 (UTC)

So does the mediawiki source code, last I checked that wasn't private -- 217.42.77.168 (talk) 17:09, 6 April 2009 (UTC)

He who trade freedom for security deserves neither and loses both, or at least that's what Ben Franklin thought. Maybe we should add and asterisk next to all the proclamations of openness and transparency that litter our statement of principle and other such articles. Burzmali (talk) 17:41, 6 April 2009 (UTC)

Filters at high risk for being circumvented are usually marked private to "cut them off at the pass." One of the bigger problems with titleblacklist, as we found out, as that everything was 100% open to the public to view; as a result, it was regularly circumvented— all that had to be done was for the puppeteer to add the page to his watchlist and adjust in one adjustment. Private filters, on the other hand, force the puppeteer to keep guessing, using up their throwaway accounts in the process, while being able to do nothing to disrupt the encyclopedia the whole time. It's basically the difference between using a clear lock on your house (where all of the pins are visible to someone trying to pick it) and using an opaque one. With the clear lock, the burglar can see the pin shears and have the lock open in a fraction of the time it would take him to brute force it. --slakr^\ talk / 01:55, 20 April 2009 (UTC)

It's my understanding that lock picking proceeds one pin at a time, and pins already picked are held in place, so I'm not sure your analogy is apt. How about the Titanic trying to avoid icebergs without sonar, when all that can be seen is the tip? --NE2 02:47, 20 April 2009 (UTC)

Or to continue the lock analogy, an addition to the titleblacklist is like trying to increase security by adding more doors. It adds an extra step, but getting around it is fairly trivial. A private filter is like putting a lock on the door, connected to an alarm that lets you know when someone is trying to break in. Mr.Z-man 02:56, 20 April 2009 (UTC)

Which works fine until you have a bunch of well-intentioned contributors standing around outside the building unable to get in. Gurch (talk) 10:14, 20 April 2009 (UTC)

Keeping the analogy: Gurch, do you realise, that blacklisting, semi-protection, and IP(-range)-blocking leaves us having those same bunch of well-intentioned contributors standing there (and probably even waaayyy more then with a reasonable filter)? But as we have conveniently turned all streetlights off around the building (with the well-intentioned, precise and irreversible use of a shotgun), we will never know! They can knock, scream, build a trebuchet, paint their faces purple, wear a superman outfit, drop their pants, whatever .. we don't know. Filters can put those editors in the spotlight, and when they knock on the door (or drop their pants :-p ) and can't come in, we can have a look, and open our doors in such a way that we keep out only those which we really want to keep out?

Does such a filter hunt away editors, possibly, but has the blacklisting, semi-protection or blocking alternative done the same? I have seen on some of our filters that we now get again those well-intentioned contributors back after they have been standing there in the dark for years. However, others knock, scream, cry ... --Dirk Beetstra ^{T C} 10:49, 20 April 2009 (UTC)

Performance data

Wikipedia:Abuse filter/Performance. This is still subject to experimentation. It's got about 36 hours of data so far, and hence the (7 day) columns aren't very meaningful yet. Also, the 1 hour column can be quite noisy for a variety of reasons. Please don't use this as a reason to start slashing at things, because the general load is okay right now. But if we do ultimately need to have discussions about prioritizing then this can provide a more tangible and long-term basis for judgment. Dragons flight (talk) 05:24, 6 April 2009 (UTC)

You've got two sets of time columns there. What's the difference between them? --Carnildo (talk) 05:51, 6 April 2009 (UTC)

If I understand your question, the first set is hits in the last X time interval, and the second set is average execution time of the rule during that time interval. Dragons flight (talk) 05:55, 6 April 2009 (UTC)

Would it be possible to do something like getting information on processing time for different input sets? E.g. for an 'A & B & C' filter it would be nice to see the processing time for 'A = false', 'A = true and B = false' and 'A = true and B = true and C = false' .. Rules which hit only one page or a small group of editors are generally very fast (1-2 msec), but they might give problems when hitting really on a really big page. Or getting information on 'fastest and slowest processing time measured', or percentages of time that the filter runs <1 msec, 1-2 msec, 2-3 msec, 3-5 msec, 5-10 msec, 10-20 msec, and 20+ msec (rules should preferably have a very low count in the latter 2-3 of these categories) might already help. IMHO, the averages don't mean too much. --Dirk Beetstra ^{T C} 12:33, 6 April 2009 (UTC)

What unit of time is on the right?   Will Beback  talk  01:51, 7 April 2009 (UTC)

The first table seems to show that all filters have taken up a total of 321.9 milliseconds in one hour, and 347.72 ms in one day. Is that correct?   Will Beback  talk  01:54, 7 April 2009 (UTC)

That is the mean execution time per edit during the last hour/day/etc. So a number of 333 ms means that the average edit took 1/3 of a second longer to save because of filtering. Dragons flight (talk) 01:58, 7 April 2009 (UTC)

Can you add the number of users who were warned and did not proceed to save their edits, and the number of users who were warned and hit the report FP link. Dy yol (talk) 17:53, 11 April 2009 (UTC)

Current Trends

Based on the data as of 4/8/09

Category	Private	Public
Total Filters	41%	59%
Total Hits	2.5%	97.5%
% of Filters that disallow	83%	17%
% of Category that disallow	80%	12%
% of Total Disallows	28%	72%
% of Hits against category resulting in Disallows	88%	6%

Not very interesting numbers, but it does show that private filters are being used to disallow edits with very specific editing patterns as opposed to public disallow filters which have much wider scope, since despite making up only 17% of disallow filters, public filters result in 72% of disallow actions. Burzmali (talk) 14:42, 8 April 2009 (UTC)

That is interesting data, thank you! :) — Werdna • talk 02:05, 16 April 2009 (UTC)

AbuseLog appearance

I found the entries in Special:AbuseLog overly descriptive, so on another wiki I changed MediaWiki:Abusefilter-log-detailedentry into something like

$1: $4: [[Special:AbuseFilter/$3|$3: $7]], $2 on $5, action: $6 ($8) ($9)

so the log entries look like

• 14:03, 9 April 2009: edit: 25: Filter name, Example (talk | contribs) on Foo, action: Disallow (details) (examine)

Just a thought... —AlexSm 15:59, 10 April 2009 (UTC)

Interesting; I agree that there's scope for improvement. I turned your example into regular text with live links, so we can see better what it would look like. I think this might be a little too compact. How about:

$1: $2 on $5 ($4), [[Special:AbuseFilter/$3|$7]]. Action taken: $6 ($8 | $9)

• 14:03, 9 April 2009: Example (talk | contribs) on Foo (edit), Filter name. Action taken: Disallow (details | examine)

Thoughts? Happy‑melon 20:41, 10 April 2009 (UTC)

That's going to stop working soon, because of some changes I've made to global filters $3 will be replaced by a link to the filter, rather than the actual filter. The link text will be in a separate message. I suppose I could pass the filter name to that message, though. — Werdna • talk 02:04, 16 April 2009 (UTC)

I see, so if it hits local filter #3 it would link to Special:AbuseFilter/3, whereas if it hit global filter #3 it would have to link to, eg, meta:Special:AbuseFilter/3. Why does the link text need to be in a separate message? Happy‑melon 13:36, 19 April 2009 (UTC)

Stop creating filters to catch one specific instance of vandalism

Things like this. Unless you want to make 1000000 filters most of which will have 0 hits and slow editing to a crawl. kthx 86.164.203.7 (talk) 20:51, 11 April 2009 (UTC)

Well, Prodego, an administrator here, says that it's recurring vandalism. In general, our admin community has a lot of technical expertise; the filter is run by Werdna, who is payed full-time to work on the system. I'm sure that they know what they're doing. ╟─TreasuryTag►contribs─╢ 20:53, 11 April 2009 (UTC)

And that's a strange example since it's not even enabled. —Wknight94 (talk) 21:33, 11 April 2009 (UTC)

Actually, your admin community is picked for their article writing experience, and frequently screw up regexes and do things like block article creation, block new user creation and deautoconfirm several hundred people (not mentioning any names) -- 86.164.203.7 (talk) 21:39, 11 April 2009 (UTC)

No, they're not. WP:RFA, WP:ADMIN etc... ╟─TreasuryTag►contribs─╢ 21:46, 11 April 2009 (UTC)

As was already said, the filter in question is not enabled and hasn't been for a week. In any case, the first check it does is for an exact match on the page title, on any article other than Warren G. Harding the time it adds to the edit would likely be <5 ms. Mr.Z-man 21:44, 11 April 2009 (UTC)

That would be one of the "Colbert Report" filters. It would have been nice to have had in place when the Warren G. Harding siege was going on. I don't know why an IP address would have a problem with such a filter - unless it would thwart his own attempts to vandalize the article. Baseball Bugs ^{What's up, Doc?} carrots 02:55, 12 April 2009 (UTC)

I said what? Don't confuse my comment with that of User:Will Beback ([3]) who enabled the filter. I in fact am the one who disabled that filter. In general I agree that filters should be targeted so to prevent the maximal amount of vandalism for the minimum amount of resources. In some cases this is a very wide filter, in some cases it is a very narrow one. Prodego ^talk 05:29, 13 April 2009 (UTC)

I agree that every extra filter imposes some cost in time and resources, and that we should seek to gain the greatest benefit. We have the recurring situation of certain specific phrases being inserted into single articles, like San Diego, Elephant, or Warren G. Harding. The "Colbert" vandalism seems to drop off because there are few re-runs, while other shows or media may have a more lasting effect. Perhaps using a mix of filters (to cover the peak periods) followed by bots (once the frequency drops off) would address the problem best? Also, if there are ways of optimizing filters for specific articles then that might reduce the problem too.Are there opther ways of handling this kind of vandalism that are better than filters?   Will Beback  talk  06:13, 13 April 2009 (UTC)

According to "Wikipedia:Don't worry about performance", we should let others concern themselves with system performance. Baseball Bugs ^{What's up, Doc?} carrots 08:45, 13 April 2009 (UTC)

That essay was written before administrators were given the ability to potentially add several seconds of processing time to every edit. Gurch (talk) 19:17, 18 April 2009 (UTC)

We are the others Baseball Bugs. The filters are a substantial load, we do have to worry about performance. @Will, generally rotating in more specific ones works for things like Colbert vandalism (which is periodic). Prodego ^talk 04:18, 14 April 2009 (UTC)

On one hand, the nature of this feature means it's always easy to use it to drag the system down, so we do need to worry about performance. On the other hand, it we really needed a lot of single article (or group of page) filters, it should be possible to make them work efficiently, if the right functionality were implemented. But a single fast filter that's changed with the flavor of the week shouldn't create a performance worry. -Steve Sanbeg (talk) 19:58, 15 April 2009 (UTC)

False positives page

Can I get some reassurance that things listed on the false positives page will be read and acted upon? Even sampling random log entries while trying to test code for interacting with the logs, I keep finding stuff that shouldn't be there; I'm sure if I actually looked deeper, I'd find a lot more wrong. The paranoid desire to unnecessarily keep most of the details of these filters hidden from me is not exactly helping, either, it's like trying to debug software by examining its output when you don't have the source code. Are posts there likely to be read, or am I better off sending everything to the administrators' noticeboard? Gurch (talk) 17:47, 18 April 2009 (UTC)

Both cases you reported are for log-only filters, there have been no actions performed on the editor, the edit has been performed without the user noticing. I would think that sending these to the administrators' noticeboard would be unnecessery. I hope this explains. --Dirk Beetstra ^{T C} 18:15, 18 April 2009 (UTC)

Being log-only doesn't mean a filter should be catching things that don't match its description, especially when it's a private one and the description is all we have to go on. In fact, such a filter is worse than no filter at all -- you get the performance cost of having the filter without the benefit of actually having the abuse log, well, logging abuse. Gurch (talk) 19:15, 18 April 2009 (UTC)

No, of course, filters should be as good as possible, with an as small as possible number of false positives as possible (preferably: zero). But for some of them, having a filter which catches everything what you want to catch, plus a handful of false positives can also be better than not having a filter at all, as otherwise you will have to devise other ways of finding all occurances (see filter 129).

Although I agree that we need to keep an eye on performance, and that the overal performance of the 'pedia does not suffer under the filters, on the other hand, there should also be a drive to improve the system behind the filters to make them as fast as possible. --Dirk Beetstra ^{T C} 19:24, 18 April 2009 (UTC)

where should I go?

Hi folks - and no need to point me in the obvious humor direction for my thread title ;). I got a spam filter notice for ezine.com when I tried to use it as a reference. I looked first to the MediaWiki talk:Spam-blacklist/log page, but I can't seem to find the right area to ask. Is ezine.com considered to be an unreliable site for reference? Thanks. — Ched :  ?  19:48, 18 April 2009 (UTC)

• I also looked at Wikipedia talk:WikiProject Spam and didn't see anything. I should have read the message I guess, instead of assuming it was an "Abuse filter" issue. Instead I just backspaced out of the edit warning window, and used a different reference. Oh well, any info on it would be appreciated. — Ched :  ?  19:57, 18 April 2009 (UTC)
  • You didn't hit any filter, at least. --Conti|✉ 20:12, 18 April 2009 (UTC)

    Yes, there are various different filters and blacklists that an edit has to pass through to be saved; unfortunately, rather a confusing situation for contributors. In this case, my guess is you were blocked by an entry on the spam blacklist added by someone who didn't bother logging it because it was obvious to them why they didn't like the look of the site. Looking at the site myself, I have to agree with them. "Submit Your High Quality Unique Articles To EzineArticles.com In Exchange For Traffic & Exposure Back To Your Website!" doesn't exactly scream "reliable source". Gurch (talk) 20:36, 18 April 2009 (UTC)

Thanks for the input folks ;) — Ched :  ?  04:07, 19 April 2009 (UTC)

My mistake, already fixed

On filter 58, already reverted. Sorry. NawlinWiki (talk) 02:12, 19 April 2009 (UTC)

You mean to say you hadn't made enough mistakes with MediaWiki:Titleblacklist? If you can't test before enabling, don't edit the filter. --NE2 04:43, 19 April 2009 (UTC)

I'm wondering why the abuse-filter code even accepted that change. I wouldn't think '("string1" & "string2")' is even syntactically valid, but since it is, I can see why it matches all edits. --Carnildo (talk) 04:46, 19 April 2009 (UTC)

PHP is weakly typed. MER-C 13:07, 19 April 2009 (UTC)

Looking further into it, the abuse filter appears to be effectively untyped, and the problematic addition didn't match all edits, only those with the character '1' in added_lines. --Carnildo (talk) 01:10, 20 April 2009 (UTC)

Somehow I knew it would be you :/ can't you get someone else to do these things? Gurch (talk) 14:19, 19 April 2009 (UTC)

AfD filter #147

I've created a filter (currently disabled) to check AfD !votes. It should be able to flag bolding problems like '''delete''. I've tested it myself several times, but could someone else make sure it works, since I'm new to the abuse filter and it involves the apostrophe (a tricky character)?

Also, I'd like to extent it to the following perhaps:

• Making sure people don't just cast a vote in an AfD; require them to give a reason.
• Making sure people don't make syntax errors such as failing to close bold/italics/other formatting, in other places like articles.

King of ♥ ♦ ♣ ♠ 00:20, 20 April 2009 (UTC)

I don't think forcing people to give a reason is a particularly good idea. –xeno ^talk 01:12, 20 April 2009 (UTC)

This is the abuse filter, not the "enforce my pet guidelines" filter. Gurch (talk) 10:15, 20 April 2009 (UTC)

I agree with Gurch; the abuse filter is not intended for style enforcement. -- The Anome (talk) 11:04, 20 April 2009 (UTC)

IP-ranges

I'm trying to create a filter on svwp which prohibits a certain ip-range from editing certain articles. But when I try to use the ip_in_range thing it either catches every IP or none at all. Presumably I'm doing it wrong! Can you tell me how to use it to catch a certain range? Would be much appreciated. Njaelkies Lea (talk) 17:15, 21 April 2009 (UTC)

The command is 'ip_in_range(user_name,"1.2.3.4/24")', see it for example at work in Special:AbuseFilter/38. Hope this helps. --Dirk Beetstra ^{T C} 17:58, 21 April 2009 (UTC)

I can't see the private filters on enwp unfortunately as I'm not an admin here, but I got the information I needed. Thank you! Njaelkies Lea (talk) 18:56, 21 April 2009 (UTC)

On Wheels

Can we add "Willy on wheels", "on wheels" and various capitalizations. Spate of vandalism earlier today in this regard and obvious historical reasons.--Fuhghettaboutit (talk) 12:42, 22 April 2009 (UTC)

Oh, and if not already done, "Haggar" "Hagger" etc. with various spellings, capitalizations and diacritic use would be appropriate.--Fuhghettaboutit (talk) 12:46, 22 April 2009 (UTC)

There are legitimate uses, such as Meals on Wheels. --NE2 13:17, 22 April 2009 (UTC)

So we limit it to avoid false positives. If "on wheels" is too general for content filtering for article additions, use only "willy on wheels" and "willy-on-wheels" with various capitalizations. Page moves, however, should be prevented from any existing title to anything "on wheels", as this was a major modus operandi. Limiting this to just moves may prevent much damage and it's very unlikely to result in more than 1 or 2 false positives over many years. In that unlikely event, an admin can be contracted or a requested move request can be made.--Fuhghettaboutit (talk) 17:23, 22 April 2009 (UTC)

I agree it is a reasonable thing to target if it is a current problem, but it's been a very long time since I've noticed "on wheels" vandalism. Can you point to the recent examples? Dragons flight (talk) 19:42, 22 April 2009 (UTC)

Yeah, this got old in 2005, nobody does it any more. Gurch (talk) 20:06, 22 April 2009 (UTC)

See these 14 pages created today. These are not all of the ones created today; just the ones I protected out of a larger group, and that I can therefore easily find. We still get Willy on Wheels vandalism, despite that it's all copycat. Unless the abuse filter has a very finite number of things it can look at, I don't see the point of not doing it. And don't lose the second issue. Haggar is active today.--Fuhghettaboutit (talk) 20:55, 22 April 2009 (UTC)

Are those creations, or moves? If they were moves I would have thought filter 1 would have blocked them, but then I have no way of telling what's in there Gurch (talk) 13:03, 23 April 2009 (UTC)

Creations. Cenarium (talk) 08:59, 24 April 2009 (UTC)

• There's no numerical limit to filters, but some of them simply take too much processing time. Stifle (talk) 15:55, 24 April 2009 (UTC)

So "on wheels" isn't on the title blacklist? Seems odd, given half of Unicode is on there. Gurch (talk) 21:53, 25 April 2009 (UTC)

It is (2nd entry under 'ATTACK TITLES AND/OR PAGE MOVE VANDALISM TARGETS'):

.*[OÓÒÔÖÕǑŌŎǪŐŒØƏΌΟΩῸὈὉὌὊὍὋОӨӦӪ][N₦ŃÑŅŇṆΝ][ ]?[WŴẀẂẄẆẈ₩][HΉĤĦȞʰʱḢḤḦḨḪНҢӇӉΗἨἩἪἫἬἭἮἯῊᾘЋΗⱧԋњһh][ÉÈËEĘĚĔĖẺẸẾỀỄễỂểȨȩḜḝĒḖḗȄȅȆȇỆệḘḙḚḛ3عڠeēėèéëẽĕęəẻếềẹ][ÉÈËEĘĚĔĖẺẸẾỀỄễỂểȨȩḜḝĒḖḗȄȅȆȇỆệḘḙḚḛ3عڠeēėèéëẽĕęəẻếềẹ]+[L₤ĹĽḶŁĿΛЛЉ][[S$ŚŜŞŠṢΣЅ].* <moveonly> # Disallows moves with "on wheels" with 2 or more Es
.*on wh33ls.*
.*on whiels.*
.*\bwith wh?iels\b.* <moveonly>
.*on rails.* <moveonly>
.*on treads.* <moveonly>

As you can see its had the Unicode treatment --Chris 00:04, 26 April 2009 (UTC)

But set to "moveonly"? Someone should take that out of there, I guess, then it will block page creations too. Better to do that than add another abuse filter, as the title blacklist is more efficient. Gurch (talk) 10:36, 26 April 2009 (UTC)

Filter 98

Can this filter excluse autoconfirmed users (and not just sysops). Its quite clear by looking throught the logs that people tripping it are non-autoconfirmed and that the people who are autoconfirmed are doing so for a reason (IE making a good solid stub compared to incoherible jibberish). I can see no reason why sysops should be excluded from this filter if autoconfirmed users arn't Prom3th3an (talk) 02:28, 23 April 2009 (UTC)

Some examples would be useful. I looked through the past couple hundred hits and didn't find anything. The ones that weren't deleted or tagged for deletion were either redirected, expanded in later edits (often by other people than the creator), or have cleanup tags on them Mr.Z-man 04:38, 23 April 2009 (UTC)

Filter 131

Resolved

For starters, i dont think removing an image (no matter how often it happens) is abuse and therefore within the morals of the abuse filter. Secondly. If i was a vandal I would spam those images (and / or upload images with simiar names and spam those to) on those pages because I know no one but a sysop could remove them which would take some time longer than a user. I think that filter as it stands (as proven above) is flawed and needs to be refined a bit. Prom3th3an (talk) 02:43, 23 April 2009 (UTC)

I've removed your advice to vandals. Seriously, what were you thinking?

As to the rest: Of course the repeated deletion of the Muhammad images is vandalism and abuse, I really don't see how you could describe it otherwise. If there were some discussion of the issue and a new consensus then they could be removed, but there is a long history of ideologically motivated edit warring that nothing to do with consensus editing. If you have a constructive suggestions then please offer them, but the images are already accompanied by comments warning against removal, so further warnings are likely to be pointless. Dragons flight (talk) 02:57, 23 April 2009 (UTC)

Also I wish to note another flaw in your actions, whilst you may have made the filter private the request (of which consensus was somewhat unclear at best to disallow) is still easily viewed and contains the pages and images concerned. Are you going to censor that too or fix or disable your filter? —Preceding unsigned comment added by Prom3th3an (talk • contribs) 03:46, 23 April 2009 (UTC)

Filter 118

Is a joke and outside of the abuse scope by far. Noting that every rule slows the servers down I must wonder why Raul needs his own rule that does absolutly nothing and has no clear purpose. I would stongly encourage its deletion as Prodego already tried. Again, this is an abuse filter not some office clerk. The abuse filter was made to stop serious issues, it however was not made to stop things that we personally find annoying. Prom3th3an (talk) 02:53, 23 April 2009 (UTC)

Wow... yeah. Why does that exist? --NE2 03:09, 23 April 2009 (UTC)

Occasionally, people have tried to self-publish things in the TFA queue. Whether simply by mistake or actively out of a desire to self-promote, I don't know. Having only one real hit, it is probably not an active enough problem to need a rule though. Dragons flight (talk) 03:14, 23 April 2009 (UTC)

Don't those pages get protected? --NE2 03:18, 23 April 2009 (UTC)

I agree its rather pointless. Are we worried Raul and anyone else (the one real hit was reverted by an anon) is just going to not notice and put some spam on the main page? Mr.Z-man 03:19, 23 April 2009 (UTC)

Filter already disabled once?

Prodego disabled this filter on the 5th of april providing "Too specific, disabling, performance -Prodego" as a reason as well as a detailed explanation on flight's talkpage of why. Within hours [4] of Prodego doing so Dragons flight re-enabled the filter without any additional comment [5] (talkpage or on-filter).

This raises serious questions about why Dragons flight reverted another admin when sufficent reason was provided. I also note he is yet to disable it despite increasing calls to do so. Prom3th3an (talk) 04:20, 23 April 2009 (UTC)

I don't see why this needs its own subsection, but its been less than 2 hours since the "increasing calls" started. I don't see what the purpose of rushing this is and making vague, ominous statements like "serious questions about why Dragons flight reverted another admin". Have you tried asking him? Mr.Z-man 04:34, 23 April 2009 (UTC)

As was discussed at length on this page, Prodego disabled 19 filters out of a mistaken concern about performance. I re-enabled about half (slightly less I think, but I'm not sure) that had made real hits in the preceding week (or in two cases had no hits but were less than a day old). Since Prodego's concern about performance was mistaken, there was no need to disable potentially useful filters. Since the filter had only been around for a few days and had seen a real hit, it wasn't clear how often the issue would actually arise. Now it is of course more clear. Dragons flight (talk) 04:59, 23 April 2009 (UTC)

I've turned it off. As you should be aware I was a little busy patching the 0day exploit you yourself publicized. Dragons flight (talk) 05:03, 23 April 2009 (UTC)

Ghost edits in the filter logs

Occasionally, I find edits that didn't really seem to exist in the filter logs. For example in the log of filter 81, I find

• 21:54, 22 April 2009: Until It Sleeps (talk | contribs) triggered filter 81, performing the action "edit" on Louis Armstrong. Actions taken: none; Filter description: Badcharts (details) (examine)

This edit seems to be a complete phantom: it isn't in the history of the article, and it isn't in the editors coontribution history. I'm sure there's a simple explanation, but I don't know what it is, and I'm curious.—Kww(talk) 03:27, 23 April 2009 (UTC)

The only thing I can guess is that the user was using some out of date data when vandal patrolling, as the phantom rollback was supposedly made 8 minutes after the edits he was trying to rollback were rolled back by someone else, but the abuse filter triggered before MediaWiki checked whether the rollback was valid. Other times things like this can happen if a user trips multiple filters, where one only logs but the other warns or disallows, if one only sees the log-only hit, it'll look like a phantom edit, but it was actually stopped by another filter. Mr.Z-man 03:35, 23 April 2009 (UTC)

...Yeah, I believe during that time, Huggle had glitched, and was not showing any new changes... Until It Sleeps 03:37, 23 April 2009 (UTC)

It would be incredibly useful if we could see in the log whether a flagged edit was actually made or not. --Conti|✉ 10:11, 23 April 2009 (UTC)

It would be more useful to fix this, as it's really a bug in MediaWiki -- at the very least, it should check whether the rollback can actually succeed or not before going to the abuse filter, and to be honest, I see no reason why the abuse filter should be checking rollbacks at all. Gurch (talk) 12:55, 23 April 2009 (UTC)

Rollbacks should absolutely be checked. If I clean vandalism out of an article and someone attempts to roll the vandalism back in, that's still vandalism.—Kww(talk) 11:31, 24 April 2009 (UTC)

I don't consider this a bug, although it may be useful to, as suggested, record which edits succeed. — Werdna • talk 04:24, 24 April 2009 (UTC)

How about killing two birds with one stone: if the edit succeeded, give us a direct link to the diff. 99% of the hits I monitor need to be reverted, and it's irritating to have to use a three-step process to get to the edit in question.—Kww(talk) 04:27, 24 April 2009 (UTC)

Yes, that would be awesome. Can this be done, pretty please? :) --Conti|✉ 09:28, 24 April 2009 (UTC)

This was the first obvious omission I noticed when I first looked at the abuse filter log. I filed it as bug 18374; apparently there are technical difficulties involved in doing so. My attempts to work around this in external software work for the most part but are also stumped by things like the above (actions that appear from the abuse log to have succeeded but actually didn't). Gurch (talk) 11:13, 24 April 2009 (UTC)

Werdna, whereabouts in the edit saving process does the abuse filter actually kick in? Can edits trip a filter but then fail anyway due to, say, edit conflicts or the spam blacklist, in addition to rollback failing? Personally I think the filter should be the very last step, partly for better performance and partly so things don't get logged that wouldn't have happened anyway. Gurch (talk) 11:16, 24 April 2009 (UTC)

Psudo-block using abuse filter

I have seen 2 types of situations where, in my opinion, a psudo-block using the abuse filter could be better:

1. A sockpuppeteer with lots of sleeping socks - we could, in stead of hardblocking the IP address, combine a softblock together with an abuse filter which disallows edits which fit the following qualifications:
   1. The account doesn't have the "admin" of "IPBE" flags. (similar to true blocks. Using the IPBE allows for admins to allow specific false-positive accounts to edit.)
   2. The edit isn't to the user's own talk page.
   3. The IP address is the one which the sockpuppeteer has been using.
   4. Identifying information about the sockpuppets - this can include names, account age, low number of edits, etc. This is the reason to use a psudo-block in stead of an actual block.
2. Users who were blocked, but there is a very good reason to allow them to edit a small number of pages, such as an open ArbCom case - set a filter to disallow all edits by the user except to the user's own talk page and the pages in question.

Both of these should give a disallow message which resembles MediaWiki:Blockedtext. עוד מישהו Od Mishehu 09:06, 23 April 2009 (UTC)

Abuse filter rights and administrators

A long time ago in a galaxy far, far away Jimbo said adminship is no big deal. But, we now have abuse filter rights built into it. Now it's a much bigger deal. One well intentioned administrator can cause serious damage to the project. We've seen editing shut down for a while due to one admin screwing up applying a new filter.

It's already becoming insanely impossible to become an administrator, and the rate of new administrators is way down. Adding abuse filter into the rights mix just makes all the more reason why people would want to limit who becomes an administrator.

I don't think we need abuse filter editors so badly (hell, we already have over a hundred of them) that we have to permit all administrators the notional ability to do it.

I hate, despise, scream in agony at the thought of creating a new bureaucracy, but something has to be done to separate the rights to abuse filter editing away from administrators. --Hammersoft (talk) 15:33, 23 April 2009 (UTC)

What exactly do you propose? Even without the Abuse filter, administrators already have the ability to cause absolutely unbelievable damage through their access to the MediaWiki namespace, far far more than you could possibly cause with the Abuse filter. Even so, they have been, and continue to be trusted with this access. I have seen no evidence that access to the abuse filter makes it more difficult to pass an RfA. In fact, in the last few weeks (although it has slowed recently), I have noticed a marked increase in the number of successful RfAs. J.delanoy^gabs_adds 15:41, 23 April 2009 (UTC)

It will happen. Count on it. --Hammersoft (talk) 15:44, 23 April 2009 (UTC)

What sort of an argument is that? I'd rather not "count on it", if you don't mind, I'd much rather hear some convincing argument why it is certain or even likely to be the case. :P Happy‑melon 15:46, 23 April 2009 (UTC)

Let's play liar's dice, shall we? I bet I can name ten different ways that an administrator can prevent all edits to a wiki until reverted, without using the abuse filter. I won't, of course, on-wiki, but I'll e-mail anyone who's interested. Unless, of course, someone thinks they can think of eleven... :D

The point is, being able to crash the site is nothing new. Being able to crash the site in new and exciting ways is not new. Being able to crash the site in new and interesting ways that weren't available when the admin passed RfA is not new. What, exactly, is new? Happy‑melon 15:51, 23 April 2009 (UTC)

Part of the issue is that the ability to view private filters is tied to the ability to edit them. We may have 140 abuse filter editors, but only about 60 have ever actually edited a filter. Mr.Z-man 16:05, 23 April 2009 (UTC)

Also, +AFE is not presently bundled with +sysop. yes, we can grant it to ourselves, but there is a distinction to be made. Also, as Z-man says, most of us are simply viewing filters (I made one or two very minor changes, but it's far too complicated for me to be doing major work on it). –xeno ^talk 16:06, 23 April 2009 (UTC)

This is one of those cases where the only way to know for sure is to wait for the future to come. My prediction is a year from now there will be a vetting process for abuse filters editing ability. Those of you who think I am wrong are of course welcome to your opinions. But please remember your opinion and my opinion have the same value. --Hammersoft (talk) 16:13, 23 April 2009 (UTC)

So are you proposing we actually begin to create such a system (as your first, "something has to be done" comment suggested) or just stating your opinion? Mr.Z-man 16:21, 23 April 2009 (UTC)

I'd like to see a system where for 24 hours after each filter is changed it applies to administrators and no-one else. That might help. Gurch (talk) 17:10, 23 April 2009 (UTC)

Yeah thats works fine except nearly every filter have sysops exempted in some way, which is questionable to say the least.   «l| Ψrometheăn ™|l»  (talk) 08:24, 24 April 2009 (UTC)

Actually, most of them only apply to non-autoconfirmed users. Trouble is, of course, that that group is the least likely to know how to report a problem, and the most likely to be deterred from contributing by broken filters and/or annoying abuse filter messages. I just figured that if all admins had to go through a 24 hour period when they were warned for doing stuff, rather than just throwing the filter out there and then ignoring it because they couldn't see its effects, errors would be corrected far more quickly, and in particular screwups that prevented all editing would only prevent all admins editing rather than everyone, which is a much less disruptive situation. Gurch (talk) 09:19, 24 April 2009 (UTC)

Yes, that sounds fine, but then the same should be true for page-protections, rangeblocks and blacklist rules that admins apply. The system should there just randomly apply random blacklist rules, page-protections and edit-blocks to the applying admin as well, just to let them see the annoying effects it can have on innocent editors who are however affected by such measures.</sarcasm>

Gurch, please, properly applied rules have WAY less collateral damage than some range blocks and semi-protections have had here. There are some rules in place, which now very specifically target problems, giving the wikipedia back to the editors (I see IP editors improving articles which have been semi-protected for 2 out of the last 3 years!). You are right, there are some dark the dark sides to this tool, but we admins have worked with semi protection, range-blocking and external link blacklisting, tools which can have WAY worse effects than this (some time ago 't' was blacklisted on meta, so no external link with a 't' could be added anywhere!). So unless you can come up with the following two statistics:

1. The number of editors who have been hit by a abuse filter warning and who a) did not save their edit, and b) did not edit afterwards anymore
2. The number of editors who have been trying to edit a page, but were deterred by a range-block, a semi-protection or a spam-blacklist block, and who a) (where possible) did not adapt their edit and saved it, and b) did not edit afterwards anymore.

showing that the latter is really lower than the former, I don't see why you are so afraid of the use of the abuse filter. Admins who apply totally wrong filters which have a significant number of wrong hits (especially those who do not adapt/disable their filter quick when they notice because they go to sleep) should indeed be hit (hard!) with a trout, and we should be generally careful, indeed. But I do not believe that this tool is worse than range-blocking, page protection or blacklisting. --Dirk Beetstra ^{T C} 10:20, 24 April 2009 (UTC)

Well, last I checked the spam blacklist does apply to administrators, and that's the way it should be. As for page proteection, that by definition can't be applied to admins too, but you get the same mentality (I've seen many pages protected with summaries like "no non-admin should need to edit this").

Nowhere did I say the abuse filter was more of a deterrant to useful contributions than rangeblocks and semi-protection. I'm opposed to misuse of those things too, especially use of semi-protection for isolated incidents of vandalism, or reasons like "new users shouldn't need to edit the page", and rangeblocks of whole ISPs for the work of one person. Gurch (talk) 11:22, 24 April 2009 (UTC)

I know Gurch, and I hope that we/I do not use all these tools too lightly anywhere. However, in some cases one editor can make life very difficult for some of us. I may misunderstand you, but I get from your remarks the feeling that 'if a filter has any collateral damage it should not be applied at all'. I am afraid, that no collateral damage is hardly possible for anything. On the other hand, a lot of the 'abuse filters' we have here, are NOT against abuse, they are there to, hopefully friendly and encouraging, 'help' editors to make a better wiki. It would be good to know how many of the 'warn' edits ('you forgot to put a dot on the i!') result in editors walking away.

Remark: blacklisted links are generally not used by experienced editors, as they know they do not fit with the policies and guidelines here. However, new good-faith editors who do not know may run into such blacklisting messages, and those messages may hunt them away. The effect is not the same as a semi-protection or a rangeblock, but it will affect new, good-faith editors who are not familiar with policy and guideline more than regulars as well. --Dirk Beetstra ^{T C} 11:46, 24 April 2009 (UTC)

Notification at least?

We can't automatically block as an action... How about having some notification that a filter is being triggered? Persistent vandals are just continually trying their edits tweaking them until they get around filters (see here). Unless you are sitting on the filter refreshing, there is no way to know. Maybe an e-mail? A talk page message? A note on some page that we could watchlist? Wknight94 ^talk 20:28, 26 April 2009 (UTC)

A mechanism to log rapidly repeated triggers of any filter by a single account would be useful. -- The Anome (talk) 20:45, 26 April 2009 (UTC)

For those who use IRC, I have a bot that makes an alert anytime a user trips 5 filters in 5 minutes, a user trips a filter doing a pagemove, or if 10 filters in 5 minutes are tripped on a page. It operates in #wikipedia-en-abuse-log along with a bot that reports most filter hits. Mr.Z-man 20:54, 26 April 2009 (UTC)

A RSS feed could be very helpful, otherwise. I dunno how hard it'd be to have one running (the RSS on the page apparently points to Special:RecentChanges). -- lucasbfr ^talk 22:12, 26 April 2009 (UTC)

Yes, we'd need a way to report users matching certain abuse filters. Maybe a bot could do that, report to WP:AVI any user matching a filter from a certain list. The list of filters could be held in the 'botspace', so that admins can update it as needed. Cenarium (talk) 20:32, 27 April 2009 (UTC)

Made a bot request, see here. Cenarium (talk) 22:25, 27 April 2009 (UTC)

Filter 107

Filter 107 should not be private because its specifications are easily accessbile here.   «l| Ψrometheăn ™|l»  (talk) 11:30, 29 April 2009 (UTC)

It should be, because it also catches some other things. And the privateness of the filter hides the actual implementation, making it more difficult to get around it. --Dirk Beetstra ^{T C} 11:44, 29 April 2009 (UTC)

Disabled Filters, unnecessary?

OverlordQ (talk · contribs) disabled three filters 94, 101, and 156.

The first two are very lightweight, averaging 0.89 and 1.26 ms respectively (performance data). They are both targeted single page vandalism getting 10 and 8 hits respectively since activation (including 5 and 1 hits respectively in the last two weeks). This kind of persistent targeted vandalism is exactly the kind of thing the Abuse Filter was initially designed for and given that these checks are extremely cheap I am inclined to reactivate these filters.

156 on the other hand is somewhat more expensive (though 5.08 ms is by no means bad) and has drawn 0 hits. It is also so specific in what it targets that it is probably easily avoided by the vandal (who is probably a lone individual, unlike the vandalism in 94 and 101 where there is a decent argument multiple people are involved). The mitigating factor if that 156 is only 4 days old. I probably would have waited several more days to see if there would be any hits before disabling (and would re-enable it in the face of ongoing vandalism), but I generally would agree that this filter seems unlikely to be of much long-term use.

In the interest of encouraging more transparency when it comes to filter use, I wanted to start a discussion about these things. In particular, I'd propose reactivating 94 and 101. Dragons flight (talk) 19:35, 29 April 2009 (UTC)

This is similar to an action by Prodego earlier. I disagree with disabling specific filters for specific vandalism which are set to warn or even to disallow, just to gain a bit of performance, especially not without consulting the AFE who has written and designed the filter (and hence probably knows most about the MO of the vandals who are supposed to be blocked by it). Those are the filters this was written for, and they should be enabled if the threat is still active. I know that filters like 29, 39 give way more hits, but they are (probably) never set to warn, they are (I am repeating myself) more logs than abuse filters, which could easily be run by a bot after the edit has been performed who dumps logs on wiki resulting in a huge gain in functionality in stopping abuse, and being able to do a much more rigorous check than reasonably possible with the filter (I am sure some could be improved but that improvement would result in a huge increase in parse-time per action). Please re-enable these filters for which the abuse-filter was written! --Dirk Beetstra ^{T C} 22:05, 29 April 2009 (UTC)

I honestly think that the abuse filter was designed to stop persistent and chronic abuse, It was not written to stop small minor vandalism that reers its head less than 10 times a month. There are enough hugglers around for things like this. The filters mentioned above should remain disabled. 94 is a waste of time, If he can't add vagina to that article he will just go to another and it is low occuring enough for standard rc patrol to deal with, if it stays on that article it can be watchlisted at least. 156 is a VERY SPECIFIC (if the guy changes one letter it wont trigger) case of vandalism that is no more common than most other vandalism making it unworthy of a filter, again RC patrol and watchlisting. 101 in itself is ok, but the low number of hits raises questions about necessity, again may be more suited to watchlisting and rc patrol. We seem to be forgetting that RC patrol didnt stop the day abuse filter came online. Prom3th3an (talk) 01:04, 30 April 2009 (UTC)

There is no reason that RC, watchlisters, or anyone else ought to be asked to revert these things ten times a month if they don't have to. 2 ms is a negligible burden and it frees up people to worry about other things. 94 is a movie inspired meme, and unlikely to be just one person. The log has IPs from 5 US states and Canada. Similarly 101 has 3 US states and 3 other countries. Besides, maybe when blocked those people will attack somewhere else and maybe they won't. We know that most people shown a page blanking warning (for example) don't continue the edit. I suspect that most people tempted to propagate a specific meme are also likely to give up if blocked. The point of the abuse filter was always to reduce the workload on RC and related tasks, and I'm not sure why we'd back away from that now. I believe historically things like 94 and 101 were in fact more what inspired its creation rather than our more heavily hit filters (like page blanking). Dragons flight (talk) 01:57, 30 April 2009 (UTC)

Prom3th3an pretty much sums up my views, so there's no reason to restate them here. Quick somebody added a word to an article! Lets add it to abuse filter! There's vandalism and there's abuse. Ten in a month is vandalism. Ten in a minute is abuse. In my opinion, only the latter should get a filter. (This is of course ignoring egregious cases) Q ^{T C} 01:21, 30 April 2009 (UTC)

If some of you guys are willing to take over watching the articles that get the same recurring vandalism then great. Reverting something ten times in a month, month after month, gets old.   Will Beback  talk  01:27, 30 April 2009 (UTC)

Will Beback, Regarding the San Diego article, A review of the history indicates that semi protection would be good here as most if not all IP contributions are vandalism of some sort. I'm going to assume no clue here and say if you are not aware of how protection works or where to request it please see Protection Policy and Requests for Page Protection as San Diego has never been protected before, so in the words of arbcom (_{play on words of dispute line}), try all other methods of resolving vandalism (revert, watchlist, block, protect) before requesting a filter. The abuse filter should be the last option Prom3th3an (talk) 01:54, 30 April 2009 (UTC)

A simple filter should be preferred over semi-protection, since that would allow more editing not less. It is not at all the last option. (I haven't looked at the history of San Diego, so there may be other reasons to encourage protection beside the problem with the movie meme.) Dragons flight (talk) 02:01, 30 April 2009 (UTC)

Where did ArbCom say that? Mr.Z-man 02:08, 30 April 2009 (UTC)

It's a play on words from thier dispute resolution line, not ment to be taken literally. San Diego has been semi protected to break the vandalism cycle on that artice. So that (94) abuse filter can remain disabled. Prom3th3an (talk) 02:13, 30 April 2009 (UTC)