Jump to content

Wikipedia talk:Edit filter: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
SwirlBoy39 (talk | contribs)
SwirlBoy39 (talk | contribs)
m →‎Messages: reword
Line 305: Line 305:
These use more friendly wording and have better explanations of what is going on. [[User:ViperSnake151|ViperSnake151]] 21:04, 18 March 2009 (UTC)
These use more friendly wording and have better explanations of what is going on. [[User:ViperSnake151|ViperSnake151]] 21:04, 18 March 2009 (UTC)


:In response to block notices {{tl|MediaWiki:Abusefilter-blocked}}, how is the blocked user supposed to edit to report a false positive? [[User:SwirlBoy39|<span style="font-family:Lucida Handwriting Italic;color:#36454F;">'''ѕ'''wirl'''в'''oy</span>]]&nbsp;[[User talk:SwirlBoy39|<span style="font-family:Lucida Handwriting Italic;color:#616D75;font-size:120%;">₪</span>]] 22:54, 18 March 2009 (UTC)
:In response to block notices from the filter, how is the blocked user supposed to edit to report a false positive? [[User:SwirlBoy39|<span style="font-family:Lucida Handwriting Italic;color:#36454F;">'''ѕ'''wirl'''в'''oy</span>]]&nbsp;[[User talk:SwirlBoy39|<span style="font-family:Lucida Handwriting Italic;color:#616D75;font-size:120%;">₪</span>]] 22:54, 18 March 2009 (UTC)


== Impact on new users ==
== Impact on new users ==

Revision as of 22:55, 18 March 2009

Toward a decision

Werdna has asked me to look this page over with an eye to deciding whether we have a consensus. Judging only by the "Vote" section, I'd say no, but of the fourteen people opposing in that section, ten cite only their discomfort with blocking-by-bot, and one more opposer cites two qualms of which one is blocking. This means that if the filter does not automatically block anyone, there is quite a strong consensus in its favor. The next section, "Discussion: blocking or de-autoconfirming?", points me toward the same conclusion. It's my opinion that the filter has gained consensus, with the condition that it de-autoconfirm users rather than block them.

I think Werdna asked me to interpret this discussion because I'm a bureaucrat. I should mention that bureaucrats do not at the moment have any sort of official status outside of the RFA/B process, so I present my considered opinion as an uninvolved user, rather than as a bureaucrat. I hope it's good for something anyway. — Dan | talk 06:40, 21 September 2008 (UTC)[reply]

Thanks, Dan :-)Werdna • talk 09:11, 21 September 2008 (UTC)[reply]
I see Dan has already got to it. I agree with the assessment too. =Nichalp «Talk»= 14:02, 21 September 2008 (UTC)[reply]
Yes. De-autoconfirming seems to be the right level of control for the time being, until there's more confidence in the system. -- The Anome (talk) 22:40, 21 September 2008 (UTC)[reply]

Thanks to Nicholas and Dan for helping out here. I've filed bugzilla:15684, and everybody is encouraged to vote for that bug (but don't comment just to say "me, too"). I consider the discussion closed at this point. — Werdna • talk 07:50, 22 September 2008 (UTC)[reply]

Deferred revisions

I've started Wikipedia:Deferred revisions, a system to use the abuse filter to defer suspect edits to reviewers for review, to be used against vandalism, spam, ... But there are technical difficulties, for example to correctly handle multiple edits, the abuse filter would have to analyze the diff between the latest version and the stable version, instead of just checking the edit. Cenarium (Talk) 01:41, 31 January 2009 (UTC)[reply]

It would perhaps have been prudent to ask for information about implementation details before making a proposal. At first blush, it seems that this system would be best used in conjunction with Flagged Revisions, not as an alternative to it. The reason is that most of the requisite functionality already exists in Flagged Revisions – some integration might be possible, but it's not necessarily going to be prioritised. — Werdna • talk 05:44, 31 January 2009 (UTC)[reply]

Yes, it would be used in conjunction with Flaggedrevs, but on all articles and possibly other non-talk pages, while flagged revisions would be used for certain pages only. It should be possible it Flaggedrevs can handle a negative flag. On the other hand, the abuse filter would need to analyze the diff to the latest stable version. And the system would be even more efficient if the defer flag were rollback-like and the abuse filter could analyze the diff to the revision before the user edited, but to work properly, they need each other. Cenarium (Talk) 16:14, 1 February 2009 (UTC)[reply]

Uses of the AbuseFilter

One of the issues that needs consideration is the limits to which this extension should be used. With a program this powerful, there are a lot of possible uses that wouldn't fall under the auspices of vandalism prevention per se, but would be possibly legitimate uses of the tool. For example

  • Setting up filters to catch and warn about test edits (from the toolbar buttons especially like http://example.com)
  • Discouraging people from certain behaviors, like creating cross-namespace redirects or redirecting their User_talk: page to somewhere else
  • As a mechanism to prevent the insertion of spam
  • As a mechanism in content disputes, for example, stopping the re-insertion of a controversial phrases into particular articles
  • As a mechanism to block certain editors from certain articles (e.g., User:AntiJew can't edit Israel)
  • As a mechanism to enforce Arbitration Committee sanctions

These are just some of the examples off the top of my head. There are likely a number of other ways this tool could be (mis)used. Any thoughts on all of this? --MZMcBride (talk) 18:00, 5 February 2009 (UTC)[reply]

The abuse filter in its current state has only two options for edits: warn or disallow (and both). Therefore, it should not be used for anything else than clear-cut cases. But I agree an automated filtering of certain edits may be valuable, this is why I proposed Wikipedia:Deferred revisions. It would add the additional action to defer the edit to a trusted user for review. Cenarium (Talk) 18:26, 5 February 2009 (UTC)[reply]
To elaborate, let's consider test edits. There are cases where the user only adds a "link title", this can be reverted, it can be done by a bot such as SoxBot III. There are also cases where a user adds a "link title", or example image, but also adds other information, for example a sentence. This should not be reverted by a bot or disallowed by the abuse filter. Instead, it should be deferred, so that it comes to the attention of a reviewer who can remove the "link title", and consider whether the sentence should be removed or not (vandalism, pov pushing, whatever) (and "undefer" the edit). I would be opposed to disallow test edits, even adding no content, as users should be encouraged to edit, but of course it needs to be reverted. The same can be done for filtered images (not bad enough to be on the bad image list, but with a use needing review), filtered external links (not blacklisted but again, needing review). I gave some examples of filters here. However I don't believe it should be used to block certain editors from editing certain articles or prevent insertion of controversial material. This is extreme filtering and tends towards a quasi-totalitarian content-control. Cenarium (Talk) 18:52, 5 February 2009 (UTC)[reply]
Per-article blocking is being dealt with by bugzilla:674, and will be applied to enforce ArbCom sanctions and community-based editing restrictions. Tim Vickers (talk) 19:16, 5 February 2009 (UTC)[reply]
I think you're missing the point here. While that bug may be resolved, as far as I'm aware, this tool will be capable of per-user per-article restrictions. So I imagine there are some who will want to use the AbuseFilter for this purpose, especially if it takes a long time for that bug to be resolved (if ever). --MZMcBride (talk) 09:36, 6 February 2009 (UTC)[reply]
Using a list of users disallowed from editing a certain page would simulate per-article blocking, but Werdna says this cannot be used for performance reasons. Cenarium (Talk) 09:42, 6 February 2009 (UTC)[reply]
Yes, selective blocking is an excellent feature for arbitration enforcement. Cenarium (Talk) 09:06, 6 February 2009 (UTC)[reply]
Is it possible to also add basic anti-vandal features, like more than one page blank in 15 seconds for an editor with...100 edits? Or an edit that only adds "penis" to an article? Or is there no consensus for that yet? NuclearWarfare (Talk) 22:43, 5 February 2009 (UTC)[reply]
The AbuseFilter can't do tracking like the former would require, it can only get information about individual edits and about the user who made the edit at the time they made the edit. Mr.Z-man 23:29, 5 February 2009 (UTC)[reply]
You may think that's a clear example, but what if a vandal removes a legitimate use of "penis" from an article? --NE2 08:50, 6 February 2009 (UTC)[reply]
It's the reason edits should generally not be disallowed, but instead deferred - or tagged for review (possibly with a warning before that). Editing should be encouraged, even if it creates problems with tests, etc, we can handle. Only indisputably bad, Grawp-style, vandalism, should be disallowed. Cenarium (Talk) 09:06, 6 February 2009 (UTC)[reply]

Correcting some misconceptions:

  • Edits can also be tagged for review on recent changes.
  • Edits can be tracked (using the 'throttle' feature.
  • The Abuse Filter is not intended for use in enforcing arbcom sanctions, for performance reasons.

And some others. — Werdna • talk 06:43, 6 February 2009 (UTC)[reply]

Reporting pages for review

A system to report pages with edits matching a certain filter to a special page, e.g. Special:ReportedPages, would be quite useful. It could be used for anti-vandalism and anti-spam purposes, but also for maintenance or policy enforcement. For example broken refs, links to userspace, redlink transclusions, non-free images in non-articles, etc. A filter by severity would be needed to distinguish vandalism and other urgent issues from the rest, for example high/moderate/low. I realize this is a shift from the initial purpose of the abuse filter, but this is an opportunity to detect and fix numerous problems. Is something like this doable ? Cenarium (talk) 21:27, 1 March 2009 (UTC)[reply]

There is already the abuse log, which can be filtered by filter. — Werdna • talk 22:45, 6 March 2009 (UTC)[reply]

Being able to filter the abuse log by filter is good... It would be nice to be able to filter by multiple filters, e.g. by placing 14,26,31 in the filter ID imputbox, all actions taken by filters 14, 26 and 31 are shown. Also, a way to know if an edit has been checked/reviewed would be helpful for report-only filters, maybe some kind of button to mark the edit checked/reviewed (only available for users in a given usergroup), and a possibility to filter so that only unchecked edits appear ? Cenarium (talk) 23:21, 6 March 2009 (UTC)[reply]

Possible function

Could a filter be created which would prevent speedy deletion tags being removed by the creator of the article they're in, and by non-autoconfirmed users. That is, it should prevent anyone who isn't autoconfirmed, and anyone who created the article in question, from removing a speedy tag. That would save a lot of trouble for us all, I think. Other helpful things would be preventing large text-dumps in the sandbox, preventing the removal of the sandbox header, etc. - possible? Thanks! ╟─TreasuryTagcontribs─╢ 18:32, 7 March 2009 (UTC)[reply]

All three of those are possible. — Werdna • talk 03:24, 10 March 2009 (UTC)[reply]
And while we're at it, will there be any place where additions like these can be discussed before they are being implemented? Or is a single suggestion that makes sense to the developer enough? (Yep, I do object to the above suggestions, but this is a more general question.) --Conti| 14:14, 12 March 2009 (UTC)[reply]
Since admins will be editing the filters, WP:AN or here would probably make the most sense. Perhaps this page should be split up like the spam blacklist page; 1 section for policy discussion, the other for filter discussion. Mr.Z-man 16:55, 12 March 2009 (UTC)[reply]

And where are we up to with getting this installed on en-wiki? :-) ╟─TreasuryTagcontribs─╢ 18:25, 11 March 2009 (UTC)[reply]

Updated versions pushed to other wikis yesterday. Doing some profiling to make sure everything's in order, hoping for deployment to enwiki within the week if no problems arise. — Werdna • talk 05:11, 12 March 2009 (UTC)[reply]

  • As a non-programmer, and since I don't seem to be able to edit the filters anyway (!) could someone possibly look into these ideas? Thanks! ╟─TreasuryTagcontribs─╢ 08:25, 18 March 2009 (UTC)[reply]
    • I don't think we should prevent anyone from moving speedy tags, even from articles they created (someone may need to IAR for a trigger happy new page patroller) - perhaps a warn. –xeno (talk) 15:53, 18 March 2009 (UTC)[reply]

Non-admin abuse filter rights

Are we going to grant the abusefilter group to non-admins soon? And if that, what are the criteria to getting it. Techman224Talk 02:57, 18 March 2009 (UTC)[reply]

I brought this up over here. Not sure which venue is better. — Jake Wartenberg 03:16, 18 March 2009 (UTC)[reply]
This is absolutely not a "show good faith and understanding of the rules" thing like rollback. Any attempt to create a "request for abuse filter" process is going to be a disaster. There is no reason at all for non-admins to have the right anyways, after the flurry of new filters slows down we will be left with an established set of filters that will only need a few changes a day, at most. Abuse Filter is in no way comparable to rollback, it simply isn't needed for day to day editing. It is an admin task, let's leave it like that. BJTalk 07:03, 18 March 2009 (UTC)[reply]
It really should be accessible only to those with the technical skill, like bots. --NE2 07:58, 18 March 2009 (UTC)[reply]
Admins have shown they are generally smart enough to leave things they don't understand (complex templates, JavaScript, CSS, blacklists) alone. I don't see an y reason to create a new closed group for this. BJTalk 09:48, 18 March 2009 (UTC)[reply]

Now fully active?

Just to clarify... is the filter now fully active, and if so, what are the rights, and which groups hold them? Can a non-admin apply for any further rights similar to rollback? Just for clarity... Thanks! ╟─TreasuryTagcontribs─╢ 08:22, 18 March 2009 (UTC)[reply]

Abuse Filter is fully active, non-admins can not apply for the editor right. BJTalk 09:45, 18 March 2009 (UTC)[reply]
When, or actually will, non admins be able to apply for this right? §hawnhath 16:47, 18 March 2009 (UTC)[reply]

BASEPAGENAME

Is there any way to get the {{BASEPAGENAME}} in the abuse flter? I want this for a log-only (maybe later upgrade to warning) for edits to an other's userspace (one of the exceptions is edits to a user's talk page). עוד מישהו Od Mishehu 05:04, 18 March 2009 (UTC)[reply]

Uh... blocked users can't report a false positive...

I know blocking is not turned on (perhaps those templates should be commented out), but if it were on, the link to "report this error" would not be available. --NE2 05:33, 18 March 2009 (UTC)[reply]

We would presumably have some type of instruction about reporting a false positive through an unblock template if the abuse filter were set to block people. –xeno (talk) 13:54, 18 March 2009 (UTC)[reply]

Possibly urgent false positive

[1] doesn't seem right. --NE2 05:44, 18 March 2009 (UTC)[reply]

Contains: "<ref>Insert footnote text here</ref>", which is the kind of default edit bar text it was designed to exclude. Not exactly sure what to do since there is a lot of legitimate text there. Was this a vandal revert or something? Dragons flight (talk) 06:04, 18 March 2009 (UTC)[reply]
It looks like the IP is doing a lot of additions to that and similar articles (no idea if they're constructive). This wasn't abuse; it was a misclick. Even if it was simple vandalism, the filter falls afoul of the note at the top of this page: "Please keep in mind that this extension's aim is not to catch simple vandalism, as some bots already do. [...] It won't catch childish vandalism or page blanking." --NE2 06:10, 18 March 2009 (UTC)[reply]
Unfortunately, I need to bow out. Hopefully by next morning some else will have things sorted. Dragons flight (talk) 06:16, 18 March 2009 (UTC)[reply]

AF - combine?

In looking the above over, there seem to be several that are rather similar. (With some similar names, as well.)

Would it be possible to combine some of these? (Not going into details, since I'm not sure yet what's seen and unseen, and therefore what should be mentioned...) - jc37 08:18, 18 March 2009 (UTC)[reply]

Action taken?

Sorry to keep plaguing with questions... could I ask what is meant by "Action taken - tag," and "Action taken - warn," ? Thanks! ╟─TreasuryTagcontribs─╢ 11:12, 18 March 2009 (UTC)[reply]

Warn shows you a bar resembling an edit notice before it accepts the edit. Try saving a page with test edit artifacts to see for yourself. Not sure what tag does. –xeno (talk) 14:08, 18 March 2009 (UTC)[reply]
I think tag tags the edit in recent changes, but I'm not sure how it is meant to appear. –xeno (talk) 16:34, 18 March 2009 (UTC)[reply]

Viewing deleted pages

On log entries such as this, one seems to be able to view the contents of a deleted page, which is, of course, a privacy risk... Is it possible for this to be fixed?

Also, more generally, surely the "non-autoconfirmed users deleting {{db}} tags" should disallow, rather than just log, such edits? ╟─TreasuryTagcontribs─╢ 11:21, 18 March 2009 (UTC)[reply]

Are non-autoconfirmed users not allowed to remove speedy-deletion tags? --Conti| 11:37, 18 March 2009 (UTC)[reply]
They should never have any reason to. They are the most likely candidates for removing the tags from articles they create, vandalising etc. An admin or experienced user can always make the final decision on a tag; an anon- or non-autoconfirmed user should never have to. ╟─TreasuryTagcontribs─╢ 11:38, 18 March 2009 (UTC)[reply]
But they are allowed to at present, so you'll have to change the policy first. The only exclusion is that the article creator may not remove the tag Fritzpoll (talk) 12:51, 18 March 2009 (UTC)[reply]
True, so why the filter, then? ╟─TreasuryTagcontribs─╢ 13:52, 18 March 2009 (UTC)[reply]
Beats me. Fritzpoll (talk) 13:59, 18 March 2009 (UTC)[reply]
The filter doesn't block the edit, it doesn't even warn currently. I don't see why the policy would need to be changed for that. Mr.Z-man 15:57, 18 March 2009 (UTC)[reply]
So what's the point of the filter, then? --Conti| 16:05, 18 March 2009 (UTC)[reply]
To provide a list of possible disruptive edits. Personally I'd be in favour of it disallowing or warning, but it's relatively useful as it is now. ╟─TreasuryTagcontribs─╢ 16:08, 18 March 2009 (UTC)[reply]
Hmm, you're right, actually, listing these edits might be useful. I'd be against any automatic action being taken tho, because the filter will probably have too many false positives. --Conti| 16:27, 18 March 2009 (UTC)[reply]

And as for my original point, that deleted pages can be viewed? ╟─TreasuryTagcontribs─╢ 14:28, 18 March 2009 (UTC)[reply]

Well it's about as problematic that new page patrollers see the "soon-to-be-deleted page" as they tag it... but then it gets kept as a permanent record in the log. I'm sure we have some way of supressing offensive or BLP-violating material. –xeno (talk) 14:40, 18 March 2009 (UTC)[reply]
You're not hinting at actually requesting oversight for all of these logged edits (and in some cases, logged attempts at edits) that yesterday would have been simply deleted as attack pages and never seen by the general public again, are you? wodup 15:04, 18 March 2009 (UTC)[reply]
No, not oversight, but perhaps some way for admins to flag parts of the log details as hidden if its required. –xeno (talk) 15:08, 18 March 2009 (UTC)[reply]
Phew! Had me worried. :P What about having the AbuseFilter automatically hide the content if the page that was acted upon to trigger the filter is deleted? wodup 15:17, 18 March 2009 (UTC)[reply]
That would work, if it's even possible. –xeno (talk) 15:38, 18 March 2009 (UTC)[reply]

New user vs. non-autoconfirmed user

I made a change to Special:AbuseFilter/30 changing "new user" to "non-autoconfirmed user" for clarity's sake. But do we want to keep it simple or clear? I see other filters use the description "new user" as well when they actually mean non-autoconfirm user. Now that the filter can revoke autoconfirmed status not all the non-autoconfirmed users will be "new". Also, the filter was disabled per the 5% rule, I may have inadvertantly re-enabled it... –xeno (talk) 14:15, 18 March 2009 (UTC)[reply]

/ in regex

It appears that including "/" in regex expressions can fail without giving a syntax error. The correct way to do this is to escape it as "\/". Dragons flight (talk) 15:24, 18 March 2009 (UTC)[reply]

Idiot's guide for admins?

Would someone with a clue mind writing up a walkthrough guide on how to read/view/change/modify/etc these for people that don't have the time or knowledge of the filter system to get a running start? :) rootology (C)(T) 16:22, 18 March 2009 (UTC)[reply]

  • It wouldn't hurt to have a guide (that's why the navigation template redlink is for), but I don't think it should be aimed at newbies (or "idiots"). I've also added a request page so people without any sort of technical knowledge can ask others for filters to be created. - Mgm|(talk) 19:56, 18 March 2009 (UTC)[reply]

Requesting "abusefilter-private" right

While I'm not a huge fan of Security through obscurity, I can see why the details of filters would be hidden. That said, is there a way for us lowly editors to get this user right? Burzmali (talk) 16:37, 18 March 2009 (UTC)[reply]

It's not "-private" that you want, that's Checkuser IP information. I think you mean "-modify"? ╟─TreasuryTagcontribs─╢ 16:41, 18 March 2009 (UTC)[reply]
See below. — Jake Wartenberg 16:54, 18 March 2009 (UTC)[reply]
I think the -private right is currently rolled into the admin package. There's private filters that probably aren't viewable by non-admins. For example, filter 2 is currently set to private. –xeno (talk) 16:55, 18 March 2009 (UTC)[reply]
The article indicates that "abusefilter-private" is the user right that allows you to view the filters that are marked private. I don't really want to edit the filters at the moment, but I am curious to see how they work. Burzmali (talk) 16:57, 18 March 2009 (UTC)[reply]
According to Special:ListGroupRights, abusefilter-private isn't assigned to any group. I believe TreasuryTag is correct with what its purpose is. Mr.Z-man 17:44, 18 March 2009 (UTC)[reply]
No, I think someone just forgot to add the entry. Try clicking this: Special:AbuseFilter/2 from a non-admin account - You may not view details of this filter, because it is hidden from public view.xeno (talk) 17:57, 18 March 2009 (UTC)[reply]
I can't view that, either. rootology (C)(T) 18:33, 18 March 2009 (UTC)[reply]
Add yourself to abusefilter-editors and you should be able to. –xeno (talk) 18:36, 18 March 2009 (UTC)[reply]
If you read this section, it seems to suggest that the -private permission is for viewing "private information" - and I recall from the pre-installation discussion that that right was given to checkuser. The viewing "secret" filters presumably comes with the admins' -modify right. ╟─TreasuryTagcontribs─╢ 18:06, 18 March 2009 (UTC)[reply]
Whatever it is, it should be clarified. –xeno (talk) 18:13, 18 March 2009 (UTC)[reply]

No, it doesn't do that. It shows the ip who triggers a filter. You have to be identified to the foundation to view it. Techman224Talk 21:11, 18 March 2009 (UTC)[reply]

-modify right (moved from AN)

Hi all,

After about six months' waiting, I've finally activated the AbuseFilter extension on enwiki!

In brief, the Abuse Filter allows automated heuristics to be run against every edit. It's designed as an anti-vandalism tool for very simple and/or pattern based vandalism.

PLEASE do not activate a filter with any action other than flagging without testing it first with just flagging enabled. — Werdna • talk 23:36, 17 March 2009 (UTC)[reply]

It's finally here! :D — neuro(talk)(review) 00:09, 18 March 2009 (UTC)[reply]
Wonderful! One thing we need to do now is hammer out some kind of a guideline as to when admins are allowed to give out the "abusefilter" flag to users. — Jake Wartenberg 00:23, 18 March 2009 (UTC)[reply]
Right. That would be a marvelous idea. Synergy 00:30, 18 March 2009 (UTC)[reply]
Awesome, this is great. Cirt (talk) 00:35, 18 March 2009 (UTC)[reply]
Hooray! shoy (reactions) 01:37, 18 March 2009 (UTC)[reply]
Yay! Lets do this as quickly as possible. I'm waiting for it. Techman224Talk 03:24, 18 March 2009 (UTC)[reply]

Giving non-admins the ability to use this could create a dangerous escalation of privileges. Esp. as this can be used to block editors. Though I'm told there are ways to restrict what certain people can do with AbuseFilter. --MZMcBride (talk) 03:39, 18 March 2009 (UTC)[reply]

Agree with MZMcBride (talk · contribs). Cirt (talk) 03:41, 18 March 2009 (UTC)[reply]
Agree, also it could be used to pseudo-protect pages (by denying any edit to a certain page). MBisanz talk 04:16, 18 March 2009 (UTC)[reply]
As currently implemented, AbuseFilter cannot block users, it can only take away their autoconfirmed status. And using the extension to pseudo-protect a page would be a clear abuse of the tool, and access to it would be revoked immediately. So I see no reason not to grant this permission to trusted members of the community, especially as many of the filters cannot even be viewed without it. Social, as well as technical restrictions need to be considered here. — Jake Wartenberg 04:27, 18 March 2009 (UTC)[reply]
Seems too much of a risk to allow for potential abuse of the AbuseFilter. Cirt (talk) 04:30, 18 March 2009 (UTC)[reply]
To be fair, many admins shouldn't have access to it either, given the possibility of false positives. --NE2 04:38, 18 March 2009 (UTC)[reply]
Maybe we need an AbuseFilterFilter to prevent abuse of the AbuseFilter. Cirt (talk) 04:41, 18 March 2009 (UTC)[reply]
Now thats an idea! :). Oli OR Pyfan! 09:44, 18 March 2009 (UTC)[reply]
but how can we stop people abusing it?--Jac16888Talk 15:29, 18 March 2009 (UTC)[reply]
(edit conflict)x2 It should be pretty easy to tell if a user is going to use this for deliberate disruption. The bar for geting this flag should be rather high, but there are knowledgeable, trusted users that are not sysops that can help out in this area. I think that there is a reason we created yet another flag for this, rather than just bundling it in in with +sysop. The AbuseFilter guideline says "anybody in reasonably good standing may request the appropriate permissions on Wikipedia", though I am not sure what that is intended to mean. — Jake Wartenberg 04:42, 18 March 2009 (UTC)[reply]
  • And non-admins--trusted non-admins, e.g. those who have proven thoughtful use of rollback--get this permission how? It's not at WP:PERM yet. //roux   05:48, 18 March 2009 (UTC)[reply]
    • Err... first you'd have to draw a correlation between rollback and AbuseFilter. Visual aids might help. :-) --MZMcBride (talk) 05:52, 18 March 2009 (UTC)[reply]
      • Way to miss the point. //roux   06:00, 18 March 2009 (UTC)[reply]

Whats the project page for this for requests for filters/filter reports/discussion of things to do with it? rootology (C)(T) 05:53, 18 March 2009 (UTC)[reply]

Wikipedia:Abuse filter (talk). --MZMcBride (talk) 05:56, 18 March 2009 (UTC)[reply]
Hmm, shouldn't there also be some kind of noticeboard/discussion page where the actual filters can be discussed, new ones proposed, etc.? --Conti| 11:28, 18 March 2009 (UTC)[reply]

We can restrict certain actions to administrators while still allowing non-admins in the abusefilter group to modify filters. None of these actions are available yet. When we have some better performance data on the abuse filter, we'll consider whether we want to activate some of the harsher actions. — Werdna • talk 08:28, 18 March 2009 (UTC)[reply]

Roux, that is exactly the problem—we don't have a policy for giving this to non admins yet. Ideally, I think, this would be a WP:PERM thing, but the criteria for getting the flag will have to be quite a bit higher than rollback or accountcreator, as if deliberately abused it can cause quite a bit of disruption. Perhaps we want there to be a three day waiting period on the requests so that other people can raise objections before it can be granted by a single admin? — Jake Wartenberg 12:55, 18 March 2009 (UTC)[reply]
  • I think at present it should probably be restricted to admins until we have some time on the system and see how it performs in the wild. Kudos to everyone involved in getting this thing up and running. –xeno (talk) 12:57, 18 March 2009 (UTC)[reply]
I am not sure anyone should have it until they demonstrate a technical understanding of the features. I for one will not touch it till I have time to thoroughly read the manual. Chillum 15:15, 18 March 2009 (UTC)[reply]
I thoroughly agree. — Jake Wartenberg 15:32, 18 March 2009 (UTC)[reply]

A parallel discussion seems to be happening over here. It would be nice to keep this in one place. — Jake Wartenberg 15:48, 18 March 2009 (UTC)[reply]

The discussion should be held there, so as to not be lost in the annals of AN archives. –xeno (talk) 15:54, 18 March 2009 (UTC)[reply]
As you can see, the thread has been moved. I hope this is OK. — Jake Wartenberg 16:53, 18 March 2009 (UTC)[reply]
Considering the disruption that a poorly-written filter could cause, I don't think this should be an easy flag to get. I'm not a fan of people wanting to poke things around simply out of curiosity. Tim Vickers (talk) 18:35, 18 March 2009 (UTC)[reply]

I'd be very much in favour of trusted users (like myself... :p ) - perhaps the rollbacker group, perhaps a little stricter than that - being given the right. We're no more foolhardy than admins, would realise that if we cause chaos then we'll be in trouble (!) and on my own count, I'd like to be able to see all filters, all settings, test etc. I do have a limited amount of programming experience, sufficient to confirm that I won't muck anything up, anyway. ╟─TreasuryTagcontribs─╢ 18:38, 18 March 2009 (UTC)[reply]

Make it blue then?xeno (talk) 18:43, 18 March 2009 (UTC)[reply]
Well, not out of the question, but easier said than done!! ╟─TreasuryTagcontribs─╢ 18:44, 18 March 2009 (UTC)[reply]

I don't think the issue here is that people will make mistakes. Admins can make mistakes just as easily as anyone else. The issue is, the Abuse Filter has the ability to affect actions across the entire site. If someone wrote a bad (malicious) filter, it wouldn't take long for people to figure it out, but even if it took only 30 seconds to fix (ludicrously short, IMO), the speed at which Wikipedia runs means that around a hundred people would be affected. Administrators are, through their access to the MediaWiki namespace and by extension the various blacklists, implicitly trusted by the community to make actions that have an effect on the entire site. Non-admins may or may not be trusted, and in any case, the trust is not "formalized", so to speak.
That said, I am not opposed to allowing non-admins to create filters that perform some of the less drastic functions, but the right should not be nearly as easy to get as rollback. Maybe we could make it so that two or three administrators have to agree to give the right out. J.delanoygabsadds 19:02, 18 March 2009 (UTC)[reply]

As an alternative, or at the very least a temporary measure till we work out a better system, we could just allow users to propose/suggest filters somewhere and have admins add them. --Jac16888Talk 19:06, 18 March 2009 (UTC)[reply]
Of course this will always be possible. Probably using {{editprotected}} on this page. — Jake Wartenberg 19:29, 18 March 2009 (UTC)[reply]
See Wikipedia:Abuse filter/Requested. –xeno (talk) 19:32, 18 March 2009 (UTC)[reply]
Thats what I meant, a specific request page, that one isn't wasn't linked to anywhere--Jac16888Talk 19:35, 18 March 2009 (UTC)[reply]
Yea, it's brand new... Linked from {{Filternav}}xeno (talk) 19:39, 18 March 2009 (UTC)[reply]

Here, it says that "anyone in reasonably good standing can request the appropriate permissions"... are we going to stick to that, or does it need to come out? ╟─TreasuryTagcontribs─╢ 19:49, 18 March 2009 (UTC)[reply]

Removed for now. –xeno (talk) 19:57, 18 March 2009 (UTC)[reply]
There is also the part in Wikipedia:Abuse filter/Requested that says "only trusted editors in good standing will be given the ability to create new filters". Might wanna zap that too, to avoid confusion. — Jake Wartenberg 21:31, 18 March 2009 (UTC)[reply]
Tweaked, thanks. –xeno (talk) 21:55, 18 March 2009 (UTC)[reply]

Be careful about load

This rule was so burdensome against large pages that the server was timing out whenever someone tried to save a page like ANI. Please try to only do as much processing to the edit stream as is necessary. Dragons flight (talk) 18:43, 18 March 2009 (UTC)[reply]

You can monitor the load by looking at [2] and searching for "AbuseFilter::filterAction". The fourth column measures how many milliseconds it is adding to the edit commit time to run things through Abuse Filter. Right now it is adding nearly 2 seconds to every edit, which is very excessive. MBisanz talk 19:35, 18 March 2009 (UTC)[reply]

According to Tim Starling there is no intelligent branching. Every operation of every rule get evaluated even if there are AND clauses and such that are clearly false. Dragons flight (talk) 20:42, 18 March 2009 (UTC)[reply]

Disabled

Abuse Filter is disabled per Brion with the note

"disabling AbuseFilter on en.wikipedia.org; performance problems on save. Needs proper per-filter profiling for further investigation."

So that means we need to go back to our AV-Bot system for the time being. MBisanz talk 19:43, 18 March 2009 (UTC)[reply]

Ok, Tim found a work-around, being selectively re-enabled. MBisanz talk 19:48, 18 March 2009 (UTC)[reply]
Meaning? :-) ╟─TreasuryTagcontribs─╢ 19:49, 18 March 2009 (UTC)[reply]
Meaning some filters in place had to be turned off since they were killing the servers and others are fine to leave running. MBisanz talk 19:58, 18 March 2009 (UTC)[reply]
It would be nice to have an easy way of telling the difference between high load and low load on a per filter basis. Obviously one can make some intelligent guesses, but real stats would be handy. Dragons flight (talk) 20:02, 18 March 2009 (UTC)[reply]
I think that is going to be the next thing Werdna works on. MBisanz talk 20:04, 18 March 2009 (UTC)[reply]

Because of load issues, is it really smart to run filters that are basically duplicates of toolserver anti-vandalism bots that are running 24/7? = Mgm|(talk) 20:38, 18 March 2009 (UTC)[reply]

In the long-term, yes. There is a transactional cost of adding junk edits to the database having those pulled to the toolserver, having a bot decide to revert, and sending another edit to the database. In the long run, clamping down on that is in our best interest (roughly 20% of all edits are either junk or reverts of junk). In the short run it might make sense to disable those functions depending where we stand on load. For the moment we seem to be okay, though provided we don't push things further. Dragons flight (talk) 20:57, 18 March 2009 (UTC)[reply]

Can someone review this filter? Somehow it is getting triggered, despite the fact that the people triggering the filter aren't removing any text. What could be causing these false positives and how do we solve them? - Mgm|(talk) 20:55, 18 March 2009 (UTC)[reply]

If a line is modified, its old version is included in removed_lines and its new version is included in added_lines. If you really want to know that something was removed you need to find it in removed_lines and not be able to find it in added_lines. Dragons flight (talk) 21:03, 18 March 2009 (UTC)[reply]
Or have length(added_lines) = 0, etc. Dragons flight (talk) 21:07, 18 March 2009 (UTC)[reply]
  • It's obviously going to show up in the added_lines if the filter considers moved material as removed and added. Any ideas? - Mgm|(talk) 22:05, 18 March 2009 (UTC)[reply]

Messages

How we've done the messages could be improved a bit, maybe something like this:


These use more friendly wording and have better explanations of what is going on. ViperSnake151 21:04, 18 March 2009 (UTC)[reply]

In response to block notices from the filter, how is the blocked user supposed to edit to report a false positive? ѕwirlвoy  22:54, 18 March 2009 (UTC)[reply]

Impact on new users

This is a very powerful tool, and especially with very common problem actions, I'm optimistic that it will help to prevent a lot of damage and allow us to focus more attention on editing that's currently spent on routine maintenance.

That said, I'm concerned about the impact all these filters will have on a new user's experience. It's very easy to make up new filters, and there are already dozens of them. Some filters seem to be created without a measured, known need. What's our process for assessing whether the benefit for a new filter (potentially recognizing a harmful edit) is greater than the harm (potentially confusing a new user)? Here are some thoughts:

  • Should there be a "Filters for deletion page" or something similar to nominate unnecessary filters for removal?
  • Should there be a Wikipedia:WikiProject BITE or something similar focused on recognizing and eliminating filters (and other practices) that distract or irritate people acting in good faith?
  • Should there be a policy/guideline page on what makes a good filter? (For example: Avoid overcommunicating to the user, stick to the basics and most common misuses and get those right with well-designed filters)?

Given that we're also now using this for recommendations rather than actions known to be abusive, I also think we may want to change the language "abuse filter": Imagine that you're a new user doing something completely innocuous and being directed to a page that shows that you're triggering an "abuse filter". Would it be hard to generalize this to be called an "edit filter"?

But in general, I hope that we can have a discussion about how to make sure that this tool doesn't conflict with our ideals of being welcoming, accessible, and friendly to newcomers. --Eloquence* 21:17, 18 March 2009 (UTC)[reply]

Actually, none of the messages mention an "abuse filter". I deliberately triggered one of the most frequently triggered filters from a school computer, and the message seems fine to me. J.delanoygabsadds 22:08, 18 March 2009 (UTC)[reply]

Personal Logs

Every editor including every IP now has an Abuse Filter log linked from their Contributions page. Right now, that log apparently shows changes that person made to the filters. Would it not be more helpful to log every time that editor tripped a filter? EnviroboyTalkCs 21:36, 18 March 2009 (UTC)[reply]

Actually that log does absolutely nothing at the moment. Dragons flight (talk) 21:52, 18 March 2009 (UTC)[reply]

Messages spelling mistake

On most (if not all) the templates, the messages refer to a non-existent "Submit" button (should be "Save page"). Could someone fix them? x42bn6 Talk Mess 22:10, 18 March 2009 (UTC)[reply]