Page MenuHomePhabricator

Create a way to unprotect an abuse filter
Closed, ResolvedPublicFeature

Description

Currently a protected filter can not be unprotected even if it is protected by mistake. Proposed either:

  • Create a new user right such as abusefilter-unprotect and assign it to a higher user group (such as stewards). Stewards should verify there are no sensitive information in old revisions/abuse logs before unprotecting a filter.
  • (not recommended) Create a maintanence script to unprotect a filter (so user need to open a task to let sysadmins to run the script).

Note unprotecting an filter will also make older versions of it visible.

Event Timeline

Aklapper changed the subtype of this task from "Task" to "Feature Request".Oct 30 2024, 12:26 PM

Note unprotecting an filter will also make older versions of it visible.

If I mark a filter as private (not protected) and later decide to make it public, users without the abusefilter-view-private-right still wouldn't be able to access the private versions in the filter's history. Perhaps something similar should be made if we want to consider making unprotecting protected filters possible.

Tchanders subscribed.

I was going to file this, so thank you for getting there first!

(not recommended) Create a maintanence script to unprotect a filter (so user need to open a task to let sysadmins to run the script).

Although marked as not recommended, I think I would recommend this one, in light of T378553: Do not allow protecting abuse filters if PII variables are not used. Filters should only be protected if a protected variable is used, and once a protected variable was used in the filter's history, it should never be unprotected again, to avoid exposing sensitive information via the logs (which could be cross-referenced with the history).

We have an unintended and temporary situation at the moment, in which there are protected filters that exist without containing protected variables. We should write the maintenance script and run it on the affected filters, and also remove the ability to protect a filter without protected variables. After that, there would be no need to have the ability to unprotect a filter.

It might be that in some cases the steward could work out that it was safe to unprotect a filter (e.g. if it was never triggered and the protected variable was removed), but having this workflow available seems to me as though it might add unnecessary burden on the stewards and the code maintainers, compared to doing the above.

Change #1090528 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/extensions/AbuseFilter@master] Add UnprotectFilter maintenance script

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

Change #1090528 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] Add RemoveProtectedFlagFromFilter maintenance script

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

dom_walden subscribed.

I have run this against a few filters. Protected, public filters become public filters. Protected, private filters become private. Unprotected filters are unchanged.

We don't record anything in the history.

Test environment: local docker Abuse Filter – (84e7f3e) 07:22, 18 November 2024.