Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Page MenuHomePhabricator

Do not allow protecting abuse filters if PII variables are not used
Closed, ResolvedPublicFeature

Description

Feature summary:
T363906 introduced a new checkbox to abuse filters, to protect PII-sensitive variables. The checkbox is labeled "I understand that details of this filter will be hidden from users who cannot see protected variables. This action is permanent and cannot be undone."

T364485 introduced a warning when trying to save an unprotected filter with PPI-sensitive variables.
I think a similar warning might be useful when changing an existing filter from its current status to protected: Even though the checkbox already says, this action cannot be undone, one might not fully realise what they are doing and accidentally (e.g. while trying to test the new checkbox) change an existing filter which doesn't need to be protected.

I suggests adding a warning asking to confirm the change when clicking "save" and changing an existing filter to protected โ€“ at least while the feature is still new, the warning might be useless once everyone has learned about protected filters.

Use cases / benefits:
Prevent admins from accidentally changing existing filters to protected in case the current checkbox helper text isn't taken seriously and the filter doesn't need to be protected.


Approach, following discussion on this task:

  • Remove the "protect" checkbox from the form. (This means a filter can't be protected without protected variables.)
  • After clicking save, show a warning with a "protect" checkbox if the filter contains protected variables
  • Without checking this box, it is impossible to save the filter

Event Timeline

Restricted Application added a subscriber: Aklapper. ยท View Herald TranscriptOct 21 2024, 5:22 PM

I would go further still, and use only the warning and not the checkbox. Since the checkbox seems to show up on every abuse filter edit even ones that have nothing to do with protected variables having it on every save is scary.

An alternative solution is do not allow protecting abuse filters unless sensitive variables are used.

@STran fyi, the scenario described above has now happened on a major content wiki: https://en.wikipedia.org/wiki/Wikipedia:Edit_filter_noticeboard#c-Ohnoitsjamie-20241109182800-Codename_Noreste-20241108230800 โ€“ there should clearly be a solution to warn/prevent admins from accidentally protecting filters which don't need protection.

I would go further still, and use only the warning and not the checkbox. Since the checkbox seems to show up on every abuse filter edit even ones that have nothing to do with protected variables having it on every save is scary.

This ^^. There is no reason to protect a filter that is not using a protected variable. Let's make it a two step process rather than allowing filters to be protected preemptively.

In the meantime, I filled T379503: Disable AbuseFilter protected variables features on wikis where Temporary accounts are not about to be released to disable that subfeature on projects where it is needed. That should prevent accidents from happening.

I would go further still, and use only the warning and not the checkbox. Since the checkbox seems to show up on every abuse filter edit even ones that have nothing to do with protected variables having it on every save is scary.

This ^^. There is no reason to protect a filter that is not using a protected variable. Let's make it a two step process rather than allowing filters to be protected preemptively.

Meantime, would it be possible for a sysadmin to reverse the protection of 1165 on enwiki? @suffusion_of_yellow has a good suggestion of giving stewards the right to undo it if accidental protection continues to be possible, but I agree with Pppery and Urbanecm that it should just not be possible.

Meantime, would it be possible for a sysadmin to reverse the protection of 1165 on enwiki?

Good question, we'll discuss that and get back to you. In the meantime: I see the filter is now deleted and hidden, and presumably copied to a different filter. Would you mind clarifying why it would be helpful to unprotect 1165?

@suffusion_of_yellow has a good suggestion of giving stewards the right to undo it if accidental protection continues to be possible, but I agree with Pppery and Urbanecm that it should just not be possible.

Thanks for the suggestion. I'm not sure that would be possible, as protection enables collection of certain otherwise-private data. Unprotecting the filter would need those data to be deleted (meaning there still would be a great deal of irreversibility, just a different kind). But, this would definitely be considered while deciding on a decision. Personally, I think it would be much easier to ensure it is not possible to protect filters that do not need the protection.

Meantime, would it be possible for a sysadmin to reverse the protection of 1165 on enwiki? @suffusion_of_yellow has a good suggestion of giving stewards the right to undo it if accidental protection continues to be possible, but I agree with Pppery and Urbanecm that it should just not be possible.

Thanks for the suggestion. I'm not sure that would be possible, as protection enables collection of certain otherwise-private data. Unprotecting the filter would need those data to be deleted (meaning there still would be a great deal of irreversibility, just a different kind). But, this would definitely be considered while deciding on a decision.

Further discussion should be at T378551: Create a way to unprotect an abuse filter

Unprotecting the filter would need those data to be deleted

If they are just unnamed user IPs, hidden them should be enough and they will be removed after 90 days.

I would go further still, and use only the warning and not the checkbox. Since the checkbox seems to show up on every abuse filter edit even ones that have nothing to do with protected variables having it on every save is scary.

An alternative solution is do not allow protecting abuse filters unless sensitive variables are used.

It sounds like we're converging on doing both of these:

  • Remove the "protect" checkbox from the form
  • After clicking save, show a warning with a "confirm" checkbox if the filter contains protected variables
  • Without confirming, it is impossible to save the filter

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

[mediawiki/extensions/AbuseFilter@master] Improve workflow for protecting filters with protected variables

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

Tchanders renamed this task from Add a warning before changing an abuse filter to PII protected to Do not allow protecting abuse filters if PII variables are not used.Wed, Nov 13, 12:22 PM
Tchanders updated the task description. (Show Details)
Tchanders added subscribers: Tchanders, Novem_Linguae.

I've updated the task description and title to reflect that we'll disallow protecting filters that don't have protected variables.

Change #1090837 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] Improve workflow for protecting filters with protected variables

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

dom_walden subscribed.
  • Remove the "protect" checkbox from the form. (This means a filter can't be protected without protected variables.)
  • After clicking save, show a warning with a "protect" checkbox if the filter contains protected variables
  • Without checking this box, it is impossible to save the filter

I can confirm.

After submitting a filter with the user_unnamed_ip variable I see the below message and checkbox.

protected_message.png (104ร—1 px, 16 KB)

protected_checkbox.png (80ร—715 px, 12 KB)

Test environment: https://de.wikipedia.beta.wmflabs.org Abuse Filter โ€“ (6bc32ac) 08:17, 19 November 2024.

Meantime, would it be possible for a sysadmin to reverse the protection of 1165 on enwiki?

We'll do this in T380290: Remove protected flag from accidentally protected filters, once the maintenance script is available to enwiki, which should be later this week.

Meantime, would it be possible for a sysadmin to reverse the protection of 1165 on enwiki?

We'll do this in T380290: Remove protected flag from accidentally protected filters, once the maintenance script is available to enwiki, which should be later this week.

Do we actually need to do this still? It looks like the filter is abandoned since it was accidentally protected: T380290#10352299

Meantime, would it be possible for a sysadmin to reverse the protection of 1165 on enwiki?

We'll do this in T380290: Remove protected flag from accidentally protected filters, once the maintenance script is available to enwiki, which should be later this week.

Do we actually need to do this still? It looks like the filter is abandoned since it was accidentally protected: T380290#10352299

It was pointed out to me that we should still remove the "protected" flag from the filter, because of access to the logs. It's been done now: T380290#10352472

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

[mediawiki/extensions/AbuseFilter@master] maintenance/SearchFilters: Allow searching by privacy level

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

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

[mediawiki/extensions/AbuseFilter@master] maintenance/SearchFilters: Allow searching by privacy level

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

Wrong task