matthew.britton wrote:

If users are edit warring, block them. If they're edit warring with rollback, they've already made it clear they're not going to follow policy, so what makes you think they wouldn't just start edit warring manually if they didn't have rollback?

Regardless of the number of people in it, "editors" is a manually-assigned privileged group. If users are misusing rights granted by a privileged group, remove them from that group. Or block them.

Implementing a rate limit for rollback would achieve little other than making it frustrating to deal with vandalism.

Complexwikipedia wrote:

(In reply to comment #1)

If users are edit warring, block them.

It is not considered helpful to block many editors involved in an edit war on dewiki as conflict resolution is not possible for blocked users and no problem solved. There is no such thing as a 3RR on our project so such would be disputed.

If they're edit warring with rollback,
they've already made it clear they're not going to follow policy, so what makes
you think they wouldn't just start edit warring manually if they didn't have
rollback?

They would not start edit warring because the filter wouldn't let them do that in conflicts that cannot be solved by other means.

Regardless of the number of people in it, "editors" is a manually-assigned
privileged group. If users are misusing rights granted by a privileged group,
remove them from that group. Or block them.

Been there, done that. To restrain people from doing some specific action is considered less harmful than a block or removal of privileges.

Implementing a rate limit for rollback would achieve little other than making
it frustrating to deal with vandalism.

Reverting vandalism is not a problem in these cases. If it would be, some rule like "action == edit | action == rollback" would make it easy to solve that problem locally.

You know you can put a rate limit on rollbacks *without* the abuse filter, right?

Complexwikipedia wrote:

This would not solve the problem since we want to put a rate limit *on specific actions* like adding or removing some very disputed weblink in hundreds of articles.

happy.melon.wiki wrote:

Technology is not a replacement for common sense, nor a guard against human stupidity. The AbuseFilter is not an internal guardian, it is for protecting against *external* vandalism. Giving people extended permissions implies a trust that they will use those permissions appropriately. If they are being used inappropriately, they should be removed. If they are being used inappropriately but local policy doesn't condone removal, you need to review the definition of "inappropriate" on your wiki. You're saying that you don't have a policy which prohibits edit warring, but you want to use technological means to prevent edit warring. That's totally backwards. Rollback is a feature which allows trusted users to rapidly revert vandalism. If your users are using rollback for other purposes, you have a problem with your users, not with the AbuseFilter.

WONTFIX.

Please don't close my bugs as WONTFIX. I'll do it myself, if it's warranted.

Wanting to filter rollback actions is not an illegitimate aim.

matthew.britton wrote:

(In reply to comment #6)

Wanting to filter rollback actions is not an illegitimate aim.

I'm not sure I agree with that. In theory maybe, on wikis with rollback assigned to *, user or autoconfirmed maybe, but on Wikimedia wikis at least, it's as dubious as wanting to filter block, delete or protect actions. They're all actions limited to privileged groups which carry some implicit level of trust, where abuse is better dealt with by removal from said groups than by some sort of automated filtering tool. Especially one where anyone with a sysop bit can wander in and impose their own iffy understanding of regular expressions on everyone else's contributions.

In this instance the stated use case is even worse. de.wikipedia has a policy against edit warring, which for reasons that escape me is enforced by an abuse filter. Contributors presumably trusted enough to be assigned to the privileged group which includes rollback are using that to circumvent the filter and continue edit warring, and (again for reasons that escape me) simply blocking offenders or removing them from their privileged group doesn't seem to happen. Edit warring is a social problem and should be addressed as such, not with technical kludges. My personal recommendation to any de.wikipedia contributors who feel edit warring is too much of a problem would be to propose and work towards something analogous to en.wikipedia's three-revert rule. And tell their administrators to actually enforce their policies rather than labouring under the false assumption that a computer program can do it for you with a zero error rate.

Just as importantly, rollback is needed to deal with broken and/or excessive filters that start enforcing the presence of vandalism. Remember that the abuse filter suffers from the same design flaw as the external link blacklist -- a change to a filter can render previously fine pages uneditable because existing content on the page matches it. With the closed-source filter system, users affected in this way can't see what is causing the problem, and of course the filters always exempt administrators so nobody who can change the filters sees that the problem is there. As a result, it can take days for such broken filters to be dealt with. During that time, all it takes is for a vandal to erase / screw up / type gibberish over the legitimate content the filter was matching, and now you have a page that is stuck in a vandalised state, and cannot be reverted to its previous state (except by an almighty administrator, of course) because the filter will block the edit. Always allowing rollback to succeed guards against this -- not perfectly, because a vandal knowledgeable of the situation can simply make multiple edits with different accounts, but sufficient for most cases.

If you agreed to modify the filter system so that the only user group checks permitted were for "user" and "autoconfirmed", so that administrators had to suffer with the rest of us when they screwed up filters, then maybe we could talk.

I have no opinion on the German Wikipedia's specific uses of the Abuse Filter.

I think that it makes sense to have the capability to filter all types of actions.

matthew.britton wrote:

(In reply to comment #8)

I have no opinion on the German Wikipedia's specific uses of the Abuse Filter.

I appreciate that, and I suspect it's the same for the English Wikipedia too. With all due respect, though, as the author/maintainer of this you have to realise that implementing any request that gets thrown your way can result in dubious features that a few influential people (or even just people who know what bugzilla is) asked for but which are not beneficial as a whole. Indeed I'm inclined to consider the abuse filter itself to be such a feature. The concept was pushed into existence by a handful of people -- all of whom just happened to be people the filters would never affect, of course, and mostly people who falsely believe a computer program can make a perfect distinction between abusive and non-abusive actions.

I think that it makes sense to have the capability to filter all types of

actions.

Again absolutely agree in theory, just as it makes sense to have the *capability* to grant 'block' to anonymous users. However, unlike such features -- that can't be played with by random wiki admins, however powerful they feel -- people *will* (ab)use this if implemented.

But then why is the delete action filtered? Many more people are having rollback than delete right.
On dewiki the editor group contains rollback. So many people are editors because they are able to detect vandalism and mark edits as sighted or revert it. But that doesn't mean that they never do unwanted edits (e.g. removing any edit they dislike which also a kind of vandalism)

On dewiki the editor group is assigned automatically by mediawiki. So no human has ever checked if the user is will use this right as expected. Admins can remove this right, but only if they know about the abuse use.
So it would be very helpful if the abuse filter can detect these edits and admins reading the log can are getting attention of this user.

• This bug has been marked as a duplicate of bug 19835 ***

happy.melon.wiki wrote:

Dupe this the other way as this has more useful content.

happy.melon.wiki wrote:

*** Bug 19835 has been marked as a duplicate of this bug. ***

• Bug 22713 has been marked as a duplicate of this bug. ***

tim.starling wrote:

content hidden as private in Bugzilla

happy.melon.wiki wrote:

(In reply to comment #15)

r54000

Are you sure about that, Tim? :S

happy.melon.wiki wrote:

Ah, troll...

This is INVALID. It is the suggested behaviour of rollback to bypass all checks. rollback bypass also the spam blacklist, which is sometimes needed when reverting vandalism, where the url is removed and you readd it, which the revert.

Pustomytnyk wrote:

Please make rollbacks visible for AbuseFilter. There is no other way to obtain log of rollback edits. Log of roolbacks is needed to improve anti-vandal filters.

Pustomytnyk: Please provide clearer argumentation *why* it is needed; and please do refer to the arguments listed in comment 18. Closing again for the time being; it's possible to comment without changing status. :)

Pustomytnyk wrote:

Andre Klapper: "Log of roolbacks is needed to improve anti-vandal filters" is quite clear argumentation. It means, when someone writes "y u dontsimply enablethis??77" in article and someone rollback that, I want to have list of rollbacks to see potentially vandal edits uncatched by filters. Would be great if the new type of log event could be introduced.