Page MenuHomePhabricator

Audit and set smarter defaults for wgAbuseFilterRestrictions
Open, MediumPublic5 Estimated Story Points

Description

I believe (and please update this ticket if I'm incorrect!) that wgAbuseFilterRestrictions is the list of actions that are disabled if a filter hits too frequently.

  • Audit wgAbuseFilterRestrictions to see what is common across all wikis
  • Set new defaults, likely including blocking, preventing, and warning.

Event Timeline

Why would you want to modify this setting that nearly noone can use this feature in a useful way anymore? If no sysop can edit a filter to prevent and warn at editing, they become quite useless.

@MGChecker I think you read the task description backwards. I think the intention is to do the opposite of what you're saying.

Currently, AbuseFilterRestrictions contains array( 'block' => true, 'degroup' => true, 'blockautopromote' => true, 'rangeblock' => true ). (These actions aren't used at enwiki at all.) However, you talk about "blocking, preventing, and warning" in the task restriction.

Now I have to ask: What else could you possibly change except the thing I guessed? Probably there is some kind of misunderstanding here.

Currently, AbuseFilterRestrictions contains array( 'block' => true, 'degroup' => true, 'blockautopromote' => true, 'rangeblock' => true ). (These actions aren't used at enwiki at all.) However, you talk about "blocking, preventing, and warning" in the task restriction.

Now I have to ask: What else could you possibly change except the thing I guessed? Probably there is some kind of misunderstanding here.

wmf-config/abusefilter.php
// Disable some potentially dangerous actions
$wgAbuseFilterActions = [
	'block' => false,
	'rangeblock' => false,
	'degroup' => false,
];

By default on Wikimedia wikis the actions I listed above are disabled. My reading of this task is to change those defaults.

I believe (and please update this ticket if I'm incorrect!) that wgAbuseFilterRestrictions is the list of actions that are disabled if a filter hits too frequently.

@Legoktm: Well, I wasn't aware of this.

I believe (and please update this ticket if I'm incorrect!) that wgAbuseFilterRestrictions is the list of actions that are disabled if a filter hits too frequently.

Well, it's quite strange (considering it's about abusefilter not surprising), because AbuseFilter handles two things by this array. In my critic, I was focussed on the first, you on the latter:

  1. abusefilter-modify isn't enough to edit filters with actions in $wgAbuseFilterRestrictions. You need abusefilter-modify-restricted for that. This permission isn't set for sysops on most projects
  2. Only actions that are listed in $wgAbuseFilterRestrictions are turned off if the filter reaches certain threshold.

To be honest, I think this setting architecture isn't quite thought through and those settings should be splitted into two. The use cases when you want one or both of this don't really align at all.

@Legoktm: Well, I wasn't aware of this.

Well, it's quite strange (considering it's about abusefilter not surprising), because AbuseFilter handles two things by this array. In my critic, I was focussed on the first, you on the latter:

  1. abusefilter-modify isn't enough to edit filters with actions in $wgAbuseFilterRestrictions. You need abusefilter-modify-restricted for that. This permission isn't set for sysops on most projects
  2. Only actions that are listed in $wgAbuseFilterRestrictions are turned off if the filter reaches certain threshold.

To be honest, I think this setting architecture isn't quite thought through and those settings should be splitted into two. The use cases when you want one or both of this don't really align at all.

If I'm reading the code correctly, there are 2 more instances where $wgAbuseFilterRestrictions is used

  1. To remove actions from global filters here
  2. To remove disallow if there are more actions and quote from comments in the code, to prevent double warnings here

I agree with @Legoktm that these settings should be split. Maybe we should work on creating more descriptive globals and using them where it applies before working on this.

@dmaza — Can you please create that ticket?

dmaza removed dmaza as the assignee of this task.Nov 22 2017, 3:46 PM
dmaza added a subscriber: dmaza.
Daimona lowered the priority of this task from High to Medium.Apr 7 2018, 1:35 PM