Extension:AbuseFilter/Priorities and Design
From Linux Web Expert
<translate> This page is obsolete. It is being retained for archival purposes.</translate> <translate> It may document extensions or features that are obsolete and/or no longer supported.</translate> <translate> Do not rely on any information on this page.</translate> |
Identified Priority Projects (highest impact with minimal dev cost)
- Global Rules
- Global Throttle / Variables
Other higher priority issues
- Variable / List Maintenance - Bugs 38279, 32928 (maybe), and the general idea to merge SpamBlacklist into AF
- Blocking Options (custom time, custom reason) - Bugs 22523, 29739, 30024
- Global Blocking - Bug 18660
Design Decisions
Global Rules
- https://meta.wikimedia.org/wiki/Talk:Global_AbuseFilter specifies a set of functionality that the community would like to see implemented:
| Requirement | Design |
|---|---|
| Large wikis with active abuse filter managers will not be affected by these filters. These are projects such as enwiki, dewiki, itwiki, ptwiki, eswiki, nlwiki ,etc who have active people maintaining the local abuse filters, and would not really benefit from global filters. | Each wiki can opt in to using the rules by setting the global variables, pointing to the shared global tables. |
| Global sysops would be granted access to the modifying the filters. Since these filters will not affect every Wikimedia wiki, this can be seen within the global sysop scope, as well as the practical application of it in regards to the current role of global sysops in global anti-spam and counter-vandalism. | Rules are modified on meta, so only admins with permissions on meta can edit or view private rules, which are applied globally. |
| The global filters would not include the options to locally block and remove local rights. These options are not practical with local filters, and even less so with global ones which could cause more false positives. | A new global will be used to control this behavior. If the global is set, the Revoke / Block / Remove actions will be disabled for global rules. |
| Emphasis will be placed on removing filters after one day, or short time of no positive actions. This policy will exclude filters which just tag edits. | It's assumed this will be done by policy. We will not automatically disable filters. |
Global Rules
- Most of the development is already done, but untested in production. Some bugs may be opened as issues are identified.
- Rules will be kept on metawiki. Database access to meta is required, multi-site db setup a requirement for use.
- Every action triggering AF processing will need to read the global rules from meta's database
- Log of hits/actions currently live in the central database (i.e., meta), and accessible based on admin permissions in meta
Global Throttle
- Throttling is currently done with memcache keys, stored by each wiki
- Global Throttling must use memcache, probably using a shared memcache key
- Initially, the existing throttle variables should be sufficient if they're globally applied
Open Questions
- Do we need to keep global rules in memcache for local wiki access?
- Andrew recommended yes. To store them with a key tied to the central server, flushed when a global rules is updated.
- Do we need to list global rules locally in rules view?
- Andrew recommended yes
- Do we need to filter log view by originating wiki on meta?
- Andrew recommended yes
- Do we need links to the central log from local instances? Or show global hits in the local log?
- Does Automatic Disabling need to happen when local wikis trigger global rules over the threshold?
