Topic on Extension talk:AbuseFilter

Why is $wgAbuseFilterActions's "degroup" = true by default?

4
Joeytje50 (talkcontribs)

The degroup ABF action to me seems like the most nuclear option in the entire extension. Consider a hypothetical where I'd go rogue on a wiki where I'm admin (not bureaucrat, so I shouldn't be able to remove admin rights of fellow admins or from bureaucrats normally), and I create a filter like this:

user_name !== "Joeytje50"

with the actions "Disallow, Block, Degroup". Any action that can trigger an ABF action, will trigger an ABF action, and to my knowledge there's nothing stopping my hypothetical rogue action from blocking out everyone else on the wiki, giving me free reign to ruin the wiki all the way until the sysadmins stop me.

All of this could be justified if the existance of such a tool was just too darn useful. However, on top of its incredible desctructive power, I can literally think of not a single legitimate application for this ABF action. There are two worst-case scenarios (where an AbuseFilter would 'save the day') I'd like to consider here:

Worst-case scenario #1: Rampant vandal with a bot account, vandalising huge amounts of pages (or bot-reverting them to a previous state).

Luckily, you have a magic abusefilter set up to detect exactly this behaviour. The actions taken are: Disallow, Block, Degroup. AbuseFilter saved the day!
However, in the real world, I would not trust any automated system to be flawless. The way safer solution would be to take the actions: Disallow, Block. The block action already prevents the vandal from doing any further harm, and can then decide whether the user should be unblocked. There is no need to hurry with the removal of privileges; if that is at all necessary (i.e. the ABF was not a false positive), a bureaucrat can come in and take away these bot rights.

Worse-case scenario #2: Rogue admin vandalising huge amounts of pages (or mass-deleting pages, or merging every single File: page onto a single page causing a huge mess).

Luckily, you've got a magic abusefilter predicting this exact type of rogue admin! You and your crystal ball can happily sit back and relax, because the actions taken are: Disallow, Block, Degroup. Abusefilter saved the day once again!
However, this admin was clever enough to come up with some devilish plan to mass-delete or mass-merge pages to cause havoc. Do you think this rogue admin would not be able to come up with the more devilish plan to strip all of his fellow admins from all of their rights through an abusefilter?

Admittedly, having a possibility for an automated process to revoke rights might be useful in some specific situations where an administrator has gone rogue, but given the situation of a rogue admin, I think the availability of this nuclear button only makes rogue admins more dangerous, not less.

To me, this action only seems safe if the 'degroup' action would be restricted to users that have the actual right to remove the highest possible removeable group. For example, if 'degroup' is able to remove 'bot' and 'rollback', then restrict editing abusefilters with this action taken only to users with the right to remove 'bot' and 'rollback' (probably Admins and higher). If 'degroup' is able to strip even 'admin' and 'bureaucrat' privileges, then editing any abusefilter with this action enabled on it should be limited to only groups that have the privileges to remove 'bureaucrat' and 'admin' from other users. If this restriction is not present, then my opinion is that this feature only ever offers more destructive than preservative control, for the reasons explained above.

Please make the 'degroup' action a disabled action by default, until degrouping is restricted to something that prevents abuse, e.g. something similar to what I described in my previous paragraph, or perhaps some other system where there would be legitimate applications for this feature.

Daimona Eaytoy (talkcontribs)

I partly agree with your rationale, in that degroup is indeed a nuclear option, and that I can't really think of a use case. However, I should note that it was disabled by default almost two years ago, see gerrit:468696, included in MediaWiki 1.34.

Joeytje50 (talkcontribs)

So then the documentation on the extension page is just wrong right now?

Daimona Eaytoy (talkcontribs)

Yes. I've just updated it.

Reply to "Why is $wgAbuseFilterActions's "degroup" = true by default?"