Page MenuHomePhabricator

Emergency disable action count may be too low
Open, LowPublic

Description

The auto-throttling mechanism disabled dangerous action for a given filter if it matches x% of at least the last y edits, if the filter was modified in the last day. The default values (both inside AF's extension.json and wmf-config) are x=5 and y=2. While x is fine, y sounds like a bit too low. My proposal is to increase it to at least 5 actions, both in AF and for WMF production.

Event Timeline

Daimona renamed this task from Emergency diasble action count may be too low to Emergency disable action count may be too low.Nov 24 2018, 4:43 PM

I misunderstood the docs. The actual meaning is "[...] if it matches more than x edits, consituting more than y% of the last edits". This makes sense, and I also updated the docs in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/475336/.

Ciencia_Al_Poder added a subscriber: Ciencia_Al_Poder.

I'm going to be bold and reopen this bug. I've created the section Emergency throttling explaining how it works, and also how can a filter be randomly disabled, just because 2 edits hit the filter close after the number of profiling action reaches $wgAbuseFilterProfileActionsCap.

Raising the value of $wgAbuseFilterEmergencyDisableCount would lower the chances that a filter gets falsely tagged as "dangerous" and then disabled. (I've already set it to a higher value on my wiki after being hit by this problem)

@Ciencia_Al_Poder Thanks. Just to be clear, only dangerous actions are disabled, and I've updated the docs accordingly.

how can a filter be randomly disabled, just because 2 edits hit the filter close after the number of profiling action reaches $wgAbuseFilterProfileActionsCap.

Yes, this is bad design. I had already noticed it, and left a @todo somewhere in the code, probably in a patch which is still under review. I believe the proper solution would be to evict older values when we reach the cap (LRU-style), instead of resetting to 0. This way we'd avoid spikes and unlucky coincidences. Although I'm unsure whether it could have any impact on performance.

As for tweaking the settings, what values would you propose?

I've raised it to 10, but I can't say whether it's a sensible default value... Maybe 5?

What about measuring the shutdown treshold per user, so it would be like "a lot of users are facing difficulties"? That way, we would be more safe with one-man-shutdowns? What do you think?

CDanis added a parent task: Restricted Task.Mar 15 2022, 2:53 PM