Page MenuHomePhabricator

Add a warning before changing an abuse filter to PII protected
Open, Needs TriagePublicFeature

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.

Event Timeline

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