Page MenuHomePhabricator

Deployment of global AbuseFilter rules
Open, MediumPublic

Description

As part of the AdminTools project, it was identified that allowing centralized AbuseFilter rules would significantly reduce the workload for stewards.

Code for this was put into AbuseFilter in Id69a9d603f9679f838e8691c651a3e9d8461b422, and is enabled on an individual wiki with a config option. Only users with the abusefilter-modify-global permission can create filters that will be applied globally.

In order to deploy this we will:

  • Configure a small set of wikis (test, test2, and mediawiki.org) to use rules from meta, to verify that there is no significant performance impact.
  • Give Stewards the abusefilter-modify-global
  • Deploy to further wikis

Version: wmf-deployment
Severity: normal

Details

Reference
bz44975

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:26 AM
bzimport set Reference to bz44975.
csteipp created this task.Feb 13 2013, 9:22 PM

The first step, enabling the configuration on test, test2, and mw.org has been completed: https://gerrit.wikimedia.org/r/#/c/48070/

If no issues are identified, we'll enable to permission in the next few days, and and continue to monitor performance while Stewards write rules for these enabled wikis.

Jasper added a comment.Apr 2 2013, 6:06 AM

Pending the merging of https://gerrit.wikimedia.org/r/#/c/42800/, stewards probably aren't going to do anything with it, except perhaps very limited testing.

hoo added a comment.Jul 26 2013, 2:02 PM

(In reply to comment #2)

Pending the merging of https://gerrit.wikimedia.org/r/#/c/42800/, stewards
probably aren't going to do anything with it, except perhaps very limited
testing.

I came to think that this is the wrong approach and would rather see this fixed within the AbuseFilter extension itself, possibly even allowing local admins to disable global filters.

(In reply to comment #1)

If no issues are identified, we'll enable to permission in the next few days,
and and continue to monitor performance while Stewards write rules for these
enabled wikis.

I'm a bit confused as to the status of this bug.

I think Jasper is saying bug 43761 should be a blocker for this? If that's the intent, please add it as a blocker.

Hoo, let's keep the discussion about local disabling there.

Aklapper lowered the priority of this task from High to Medium.Apr 9 2015, 12:40 PM
Aklapper added a subscriber: Aklapper.

Global AbuseFilter is now active on all small and middle-sized Wikimedia wikis (with some exceptions).

Well...

'default' => false,
'small' => true,
'medium' => true,
'private' => false,
'fishbowl' => false,
'nonglobal' => false,

// Effectively repeat nonglobal entry above because both labswiki and labtestwiki are also medium
'labswiki' => false,
'labtestwiki' => false,

'enwikisource' => true, // T78496
'frwiki' => true, // T120568
'metawiki' => true,
'testwiki' => true,
'test2wiki' => true,
'mediawikiwiki' => true,
'specieswiki' => true,
'incubatorwiki' => true,
'wikidatawiki' => true,
csteipp removed csteipp as the assignee of this task.Mar 14 2016, 3:19 PM

At some point I think we need to figure out if large wikis should be included. So far they havne't, which means some of the promises of global filters can't be realized (e.g., global throttling). If so, we should keep this open and figure out a roadmap. If not, we should probably mark this "declined" instead, with reasoning.

He7d3r reopened this task as Open.Mar 14 2016, 4:13 PM

Ok, undoing for now.

Is the non-deployment to global wikis a community (i.e needs permission) or a tech (e.g large wikis creating performance problems) issue?

Both probably

The tech component (aiui), is that the global filters will count against the AF runtime limits. So the global filters will reduce the number of local-wiki specific rules that can run. We could raise the limits and accept that some edits are going to take longer to save.

I think the community issue is bigger-- are the large-wiki admins comfortable with the global filter editors having that type of control over the wikis. I'm not sure who the stakeholders are on each of the large wikis to make that determination, or what the correct process would be to decide that.

I can initiate a survey at dewiki, if wished, but I can't tell you the process for other wikis.

On eswiki, it could be brought up on https://es.wikipedia.org/wiki/Wikipedia:Filtro_de_ediciones/Portal/Archivo/Implementaci%C3%B3n/Actual or https://es.wikipedia.org/wiki/Wikipedia:Caf%C3%A9/Archivo/T%C3%A9cnica/Actual

But I think the limits should be split first, with global filters counting against its own limits. It's not appropriate that a steward tweaking one global filter inadvertently disables Very Important Filter™ on xywiki (or that a local filter makes the steward filter unable to run).

I agree that there should be separate global and local filter limits. With no impact on local projects, this shouldn't need any sort of community approval, other than customary input (perhaps through an RfC?) that allows people to point out concerns and perhaps develop systems through which other individuals can become involved in the process.

At some point, someone decided that it made sense to centralize some abuse responses, and made things like global locks, global spam blacklists, global title blacklists, etc. Not sure when we decided to move from that to endless bureaucracy and pretending that each project exists separately of all the others.

(...) With no impact on local projects, this shouldn't need any sort of community approval (...)

That's the problem, at the moment it is not possible to deactive a global filter locally, so it will have an impact.