Page MenuHomePhabricator

Provide a sane way to bypass abuse filters
Closed, ResolvedPublic

Description

Users have wanted a way to let certain users bypass AbuseFilter's restrictions for a long time. Wikia has already written a hack to allow it. It's also recently become a problem for us with global rename. I propose that we create a proper way to do it, with the following characteristics:

  1. The filter checks themselves are not bypassed. Hits will still be logged, tagged, etc. The only effect will be that the action isn't disallowed.
  2. In most cases*, users will be required to explicitly state their intention to bypass abuse filters with each action. This would take the form of a checkbox from the UI (like titleblacklist currently does for account creation) and an additional parameter from the API.
  3. If a filter has Warn as an action, and it's practical to show a warning*, the warning will not be bypassed.

These rules will strongly encourage wikis to still properly set user_groups/user_rights conditions in their filters, while still providing the bypass ability when necessary.

*Global rename is one case where explicitly choosing to bypass wouldn't be required and where showing warnings wouldn't be practical.

Details

Reference
bz67936

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:26 AM
bzimport added a project: AbuseFilter.
bzimport set Reference to bz67936.
bzimport added a subscriber: Unknown Object (MLST).
Restricted Application added subscribers: Luke081515, Aklapper. · View Herald TranscriptJan 22 2016, 5:45 PM

Change 288571 had a related patch set uploaded (by Matěj Suchánek):
Add "abusefilter-exempt" right

https://gerrit.wikimedia.org/r/288571

Have you just added a possibility to bypass disallow and similar possibily destructive filter actions (block, blockautopromote, degroup) or a possibility to bypass tagging and warning too?

matej_suchanek updated the task description. (Show Details)
matej_suchanek removed a subscriber: wikibugs-l-list.
1997kB added a subscriber: 1997kB.Jan 5 2019, 12:41 PM
Tgr added a subscriber: Tgr.Jan 9 2019, 6:25 PM

Probably the least horrible solution here is for AbuseFilter to provide a global skip flag that can be set by callers before they do an action that might trigger filters, which could then be set for system actions like LocalRenameJob, and triggered int the edit/upload special page and API via an extra boolean input field.

Daimona added a subscriber: Daimona.Jan 9 2019, 7:46 PM

That's what I thought, too... Mostly because the front-end way of bypassing a filter shouldn't exist. That is, if you want someone not to hit a filter, you should code the filter to do that, mostly by excluding user groups. And assigning this right to global renamers would make them unaffected (or, respecting the points in the task description, less affected) by other filters for which they don't really need this flag. This is IMHO not ideal. Edge-cases like rename job should instead be handled back-end.

Tgr added a comment.Jan 9 2019, 7:54 PM

Global rename and other "internal" failures are definitely not a reason to add a bypass user right / checkbox. There might be other use cases; within filter logic you can only skip or affect (you can't for example say "prevent if user is not in group X, show a warning otherwise"; compare with titleblacklist etc. where functionaries can force the action but the check won't just get skipped without them being informed about the failure). But that's probably best discussed when someone has concrete use cases for it.

In T69936#4867327, @Tgr wrote:

Global rename and other "internal" failures are definitely not a reason to add a bypass user right / checkbox. There might be other use cases; within filter logic you can only skip or affect (you can't for example say "prevent if user is not in group X, show a warning otherwise"; compare with titleblacklist etc. where functionaries can force the action but the check won't just get skipped without them being informed about the failure). But that's probably best discussed when someone has concrete use cases for it.

Ditto. As for skipping, we already have warnings. In case a filter exists which targets both privileged and non-privileged people, and wants the former not to be affected by a disallowing action, the filter should probably be splitted.

So I filed T229252, which adds a hook to AF to let other extensions decide whether the current action should be filtered. And CentralAuth is doing that via a temporary user right, although that's not the possible way. I'm unsure whether the "proper way" in the task description is still useful to implement, or we can just close this bug as duplicate.

See also T36928: Create a user right that allows ignoring the spam blacklist - there may be objections to allowing people to bypass filters

Daimona closed this task as Resolved.Nov 26 2019, 1:36 PM
Daimona claimed this task.

See also T36928: Create a user right that allows ignoring the spam blacklist - there may be objections to allowing people to bypass filters

I agree. There are objections in this case as well. Also, as it was mentioned on that task, AFs can be tweaked very precisely (unlike TB/SB which are all or nothing). For T212082, I had implemented a hook, that extensions can use to specify actions that shouldn't be filtered. I consider this a "sane way" for everything happening in the backend.

OTOH, adding an extra user right seems to actually reduce the precision of abuse filters. Sometimes you really want to target *all* users (the first example that comes to mind: detect the addition of deprecated HTML). Assigning an "abusefilter-bypass" right to any group would effectively defeat the purpose of such filters.

To conclude, I believe that we have actually two sane ways to bypass AbuseFilters. The first one is the golden rule: always put a check user_groups. The second one is the aforementioned hook. IMHO, these meet the DoD of this task, which I'm therefore resolving. FWIW, I'm at the same time declining the part about adding an "abusefilter-bypass" right.

In my opinion an abusefilter-bypass is useful though should normally be granted to no one permanently; my rationale is to prevent https://en.wikipedia.org/wiki/Special:AbuseLog?wpSearchUser=WMFOffice&wpSearchPeriodStart=&wpSearchPeriodEnd=&wpSearchTitle=&wpSearchImpact=0&wpSearchAction=any&wpSearchActionTaken=&wpSearchFilter= from being happen.

@Daimona - can you clarify if you would be okay with adding abusefilter-bypass as a right that isn't given to anyone by default?

In my opinion an abusefilter-bypass is useful though should normally be granted to no one permanently; my rationale is to prevent https://en.wikipedia.org/wiki/Special:AbuseLog?wpSearchUser=WMFOffice&wpSearchPeriodStart=&wpSearchPeriodEnd=&wpSearchTitle=&wpSearchImpact=0&wpSearchAction=any&wpSearchActionTaken=&wpSearchFilter= from being happen.

To prevent those we'd have to assign the right permanently to the 'staff' group, wouldn't we? And then, what if a filter is actually meant to target *all* actions, included the ones by members of the "Staff" group? You simply can't. That's what I was saying: AF already has a precise way to exclude certain user groups from being targeted -- if you permanently exclude a user group, then you're effectively making this tool less precise.

@DannyS712 At the moment, I wouldn't (although I can change my mind, of course). This task asked for a "sane way" to bypass filters. Well, in my opinion, an "abusefilter-bypass" is not a sane way. Checking 'user_groups' is a sane way; having a hook for "unusual" backend stuff (e.g. global renames) is sane. For the WMFOffice case, a sane solution is being able to check for the 'staff' global group, which is currently impossible. I think we already have a feature request to include global user groups in the AF variables, but I cannot find it right now.

Tgr added a comment.Nov 27 2019, 7:01 PM

The right way to bypass filters would be that users with the abusefilter-bypass have a checkbox that they can use to suppress abusefilter effects. That's how it works for blacklists etc. Not sure if it's worth the effort and code complexity though, as Daimona says there are already ways to make the filter bypassable.

One thing that might help is to provide pseudo-user groups such as crosswiki autoconfirmed (has more than X total edits, not necessarily the current wiki) or privileged anywhere, to make it easier to avoid gotchas like not adding stewards to the skip list. (cf. T208477: Move "privileged account' concept into MediaWiki core)

In T69936#5698208, @Tgr wrote:

The right way to bypass filters would be that users with the abusefilter-bypass have a checkbox that they can use to suppress abusefilter effects. That's how it works for blacklists etc.

Saner, yes. Whether this is completely sane, I wouldn't be sure. You'd still be offering a way to bypass a tool that's already supposed to check whether you're allowed to bypass it or not.

Not sure if it's worth the effort and code complexity though, as Daimona says there are already ways to make the filter bypassable.

But yes, either way I think it's not worth doing anything further (unless we find a good reason to do so).

One thing that might help is to provide pseudo-user groups such as crosswiki autoconfirmed (has more than X total edits, not necessarily the current wiki) or privileged anywhere, to make it easier to avoid gotchas like not adding stewards to the skip list. (cf. T208477: Move "privileged account' concept into MediaWiki core)

Yes, this would be great. BTW, I was wrong in my previous comment: we already have a variable for global user groups (global_user_groups) - it's just "invisible" because it's only computed if a filter requires it.

hmm we even have a dedicated extension that add a right bypassing all abusefilters: https://www.mediawiki.org/wiki/Extension:AbuseFilterBypass