In T290324#10747052, @ARamadan-WMF wrote:

@kostajh , Hello, has Trust and Safety completed this?

L3SC approval is documented here. I'd like for Trust and Safety Product Team to take a look at this, because we recently reworked a bunch of code to support T354599: [EPIC] WE4.2.14b Provide IP reputation variables in AbuseFilter and we may have some learnings there that apply to this patch. I'm tentatively placing it in our next sprint for our team to provide code review.

@MolecularPilot Thank you for your work on this and sorry about the delay on our end. I've reviewed the task requirements and it looks good to me. My only question is whether this has gone through any community approvals process? Looking at the number of subscribers on this task it seems like this is a popular idea. If there is a community discussion about it that you can link to, that would be helpful.

I tried to pull the patch into a patch demo to review the feature but that failed presumably because the patch needs rebasing. Happy to look that over once the patch is updated.

@kostajh We can proceed with the engineering review.

Hi @Niharika. As a former fr-wp OS, and current AF: I don't think there are public community discussion on fr-wp, but we wanted to get such Oversight-level abuse filters because we have on fr-wp a (private) anti-harassment abuse filter (148) using real names of editors, especially functionnaries. Which is not optimal for privacy.

I can tell you this has gone through the en OS mailing list as a very popular idea. Crucially this also came out of the Wishlist process which, as I understand it, is supposed to be its own form of community discussion.

+User-notice: IMO this feature is worth a Tech/News announcement if/when it's implemented; feel free to remove the tag if you disagree :)

For Tech News (once this is ready to announce): Drafts/suggested wording would be welcome! (I always appreciate help understanding what exactly needs to be communicated).
Any estimates of the timing of the entry are also always welcome (for when I/other editors are skimming the workboard for recently-active tasks, each week). Cheers.

Test wiki created on Patch demo by MolecularPilot using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/c6c26351dc/w/

Change rebased ontop of protected variable changes (latest master) and ready for code review!

All tests are passing and you can see the patch demo of it working through the above link (login info specified on the main page).

For Tech News, I was thinking something like:

• Edit filters can now be suppressed to automatically restrict details and logs to oversighters only.

but the question does arise do we use enwiki/Wikimedia specific terms ("edit filter", "oversighter") or general MediaWiki terms ("abuse filter, "suppressor")?

The global terms should be preferred for i18n purposes. That said, I'd rewrite the note as "Edit filters can now be set to suppress attempted edits and actions [automatically]." which avoids part of the issue. (And I think edit filter is the wider known terminology these days too, but I could be wrong.) Link suppress to the relevant MW wiki documentation page or Wikidata item, and add a separate "see filters documentation about this feature" sentence after, wherever that lives.

How about "Certain edit filters can now be set to suppress their list of attempted edits and actions. The idea is to restrict information in edit filters related to doxing."

I've added four related wishlist links to the task's Description. I believe that, plus @Niharika's comment above, satisfies the Acceptance criteria for "Approval from Trust & Safety Product", but I'll leave checking-that-checkbox to someone else.

Re: terminology: I see the 4 wishlist pages all use "abuse filter". But I'm aware that that name isn't ideal for a few reasons (incl. inaccurate for some filters, and not universally used by editors). In the Tech News entry, I suggest using "edit filters", but I will also add a note in the "translation guidance" (qqq) telling the translators to use either term, as appropriate for their linguistic community.

Re: Acceptance criteria of "Documentation on mediawiki.org updated to reflect new suppression functionality." -- Is this part done, or planned to be done by someone? It would be ideal to have the updated content both ready for translation, and linked-to within the Tech News entry.

Re: draft of an entry: I'd suggest (but further edits/suggestions are very welcome!):

• Edit filters [[LINK TO NEW DOCS| can now be set]] to suppress their list of attempted edits and actions. This will help oversighters if they are using any edit filters to prevent doxxing.

@Jules78120 @Barkeep49 Noted, thank you. In that case this is all good on my end. The other remaining thing is for our team to do a code review. It's in our current sprint and should be looked at by someone hopefully soon.
@Quiddity let's leave the Approval for TSP checkbox open for whoever does the code review. They can sign off on it.

There was a minor merge conflict in the patch caused by a change merged to main in the last few days, I’ve reconciled this, so it’s ready for code review now, but absolutely no rush for that! :)

Removing our sprint tag as we provided code review but are now waiting for the patch to be updated for the new merge conflicts and the comments I left a few weeks ago.

We would want to take another look at this for code review once the patch has been updated.

Hi! Thank you very much for the patch review,. I’ve addressed all concerns, but due to a problem with WiFi (I am writing this on my phone) I’m currently unable to submit the new patch. I should be able to by next weekend when it is repaired. Thanks again! :)

In T290324#11037917, @MolecularPilot wrote:

Hi! Thank you very much for the patch review,. I’ve addressed all concerns, but due to a problem with WiFi (I am writing this on my phone) I’m currently unable to submit the new patch. I should be able to by next weekend when it is repaired. Thanks again! :)

Thanks for the update! Hope you can get the WiFi sorted soon and there are no other unexpected problems. If you could ping me when that's done, I can take another look at the patch.

My apologies, this slipped my mind once my WiFi was restored. I’ll resolve the merge conflicts and reviewer comments within a few days and submit an updated patch. :)

@Dreamy_Jazz I've addressed the merge conflicts and all of your feedback in the latest patchset - Patchset 12 - and it's ready for your review when ready. Thank you again for your detailed feedback!

Is this ready for Tech News?

It needs to be reviewed and merged first.

@STei-WMF Please look at the "Details" box to see patch statuses, and at the project tags which may include Patch-For-Review.

Test wiki created on Patch demo by MolecularPilot using patch(es) linked to this task:
https://c638625221.catalyst.wmcloud.org/w/

This patch will not be going out until the week of the 5th of January (as there are no trains over the Christmas holiday period), but otherwise should be ready for a tech news entry

Change #1115319 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] AbuseFilter: Add support for suppressing filters

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

Is this entry still accurate for Tech News?:

Edit filters [[LINK TO NEW DOCS| can now be set]] to suppress their list of attempted edits and actions. This will help oversighters if they are using any edit filters to prevent doxxing.

I think that's great, maybe just also add that this hides the filter details (incl. rules as well) and that the log suppression is done automatically, like:

Edit filters [[LINK TO NEW DOCS|can now be set]] to automatically suppress their details such as rules and list of attempted edits and actions. This will help oversighters use edit filters to prevent doxxing or other suppressible material.

Test wiki on Patch demo by MolecularPilot using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org/wikis/c6c26351dc/w/

Test wiki on [[ | Patch demo ]] by MolecularPilot using patch(es) linked to this task was deleted:

https://c638625221.catalyst.wmcloud.org/w/

I've made new docs now at https://www.mediawiki.org/wiki/Extension:AbuseFilter/Access_flags that can be linked in the tech news entry.

In T290324#11475472, @MolecularPilot wrote:

I've made new docs now at https://www.mediawiki.org/wiki/Extension:AbuseFilter/Access_flags that can be linked in the tech news entry.

Edit filters [[mw:Extension:AbuseFilter/Access flags|can now be set]] to automatically suppress their details such as rules and list of attempted edits and actions. This will help oversighters use edit filters to prevent doxxing or other suppressible material.[https://phabricator.wikimedia.org/T290324]

Done!

@STei-WMF, this change will not be deployed until January but it is being included in next week's Tech News from what I can see.

If we are using it in this coming week's Tech News, can we clarify that this will be available in January?

In T290324#11477087, @Dreamy_Jazz wrote:

@STei-WMF, this change will not be deployed until January but it is being included in next week's Tech News from what I can see.

If we are using it in this coming week's Tech News, can we clarify that this will be available in January?

I will add that it will be available in January.

Change #1220039 had a related patch set uploaded (by MolecularPilot; author: MolecularPilot):

[mediawiki/extensions/AbuseFilter@master] AbuseFilterPermissionManager: Check for blocks when assessing suppresion rights

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

Change #1220039 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] AbuseFilterPermissionManager: Make blocks deny suppressor rights

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

Note the Unsuppress will unhide all the logs. Should be warning somewhere or the logs until unflag should stay hidden?

In T290324#11514874, @Wargo wrote:

Note the Unsuppress will unhide all the logs. Should be warning somewhere or the logs until unflag should stay hidden?

That’s already discussed in T414011 along with other issues. Ideally the option to unsuppress filters should be removed, just like it’s not possible to unprotected filters with protected variables.

Who is able to see the information that a certain filter is suppressed? I would suspect abusefilter-view to suffice, but maybe it is regulated differently?

In T290324#11539679, @MGChecker wrote:

Who is able to see the information that a certain filter is suppressed? I would suspect abusefilter-view to suffice, but maybe it is regulated differently?

That's indeed based on abusefilter-view (usually given to all users, even unregistered ones – or restricted to autoconfirmed users in some projects).

Example from https://test.wikipedia.org/wiki/Special:AbuseFilter (I've now unsuppressed filter 300 again):

Clicking on the filter link without the permissions to view suppressed filters shows the abusefilter-edit-denied-suppressed message which is similar to the denied-messages for private and protected filters.

In T290324#11515167, @Johannnes89 wrote:

In T290324#11514874, @Wargo wrote:

Note the Unsuppress will unhide all the logs. Should be warning somewhere or the logs until unflag should stay hidden?

That’s already discussed in T414011 along with other issues. Ideally the option to unsuppress filters should be removed, just like it’s not possible to unprotected filters with protected variables.

@MolecularPilot what do you think about this proposal?

I agree with what Pppery mentioned in T414990, I don't think making a filter completely unable to be unsuppressed is ideal, and feel it's inconsistent with the wiki model. I think a better solution is to set the, already existing, "manually suppressed" (I don't recall the exact column name) bit for any log generated while a filter is suppressed, so unsuppressed the filter doesn't automatically reveal this. I think it's different to protected filter logs, as they inherently contain PII in the variables like IP addresses, but each log hit for a suppressed filter doesn't necessarily contain this. Though, if we do need to go with irreversible suppression for legal/compliance/etc. reasons, a warning before suppressing would definitely be ideal.