| sbassett | |
| Jul 17 2025, 9:45 PM |
| F65711132: Screenshot 2025-08-04 at 16.48.26.png | |
| Aug 4 2025, 2:51 PM |
| F65698649: image.png | |
| Jul 31 2025, 9:48 PM |
We should improve MediaWiki's non-public logging of certain content deletion and suppression-related events. For example:
FWIW, For 1., we have page undeletion events in public streams: in the mediawiki.page_change.v1 where page_change_kind == 'undelete', and also in the deprecated mediawiki.page-undelete stream.
For 2., we have 'unhiding' via the mediawiki.revision-visibility-change stream, also public. (Relevant: T351565: Implement a new notification only revision-visibility-change stream). Revision visibility changes (AKA RevDelete) are also captured on the latest page revision in mediawiki.page_change.v1 (but only for username and comment; content cannot be hidden on latest revision).
These events are emitted even when the action is suppressed, but the information about the actor doing the suppressing is redacted (at least since T342487). These events needs to be public so that good actors (Enterprise, Internet Archive, etc.) can do the right thing on their side.
We do not have unsuppression in events, although...what is unsuppression in this case? I guess this would be unsuppressing an entry/log in RecentChanges that was previously 'suppressed' so that it was not visible there to oversight admins?
Isn't the concern here more about people privately viewing deleted/suppressed revisions, than about actual undeletion/unsuppression, both of which are logged on-wiki?
I agree, I think the idea here is to create a Logstash entry when a user views deleted/suppressed content.
Yes, this in the context of when a user/actor takes these actions on the projects. So additional logging (to logstash, not MediaWiki public logs) for those specific cases. If folks have any suggestions on re-titling or re-phrasing this in the task description, please let me know.
Shifting to MWI team radar since the deletion and visibility events are already logged (which is what would be in scope for MWI). Adding Platform and Trust & Safety to review possible changes to permission workflows.
In general, we may want to change the behavior to opt-in for seeing suppressed content. Today, you just see the suppressed content if you are logged in and have the right permissions. Instead of always granting visibility to logged in users who have permissions, we might want to add more of an "opt-in" workflow to change visibility on suppressed revisions. Then we could more reasonably track instances where the information was specifically sought out.
Notes from the API perspective, this change would also allow us to improve cacheing. We are unable to cache page and revision responses because we currently respect the logged in user permissions and return everything, which is also less than ideal. It would be better to control it through a header or some other opt-in.
So, to be clear, is this about logs for viewing deleted/suppressed content, or is it not? The task description doesn't mention anything about viewing content, but everyone is discussing as if it did.
Seeing suppressed content is already opt-in in the interface (but not in the API). If you follow a link from e.g. page history, you will see a warning like this:
Notes from the API perspective, this change would also allow us to improve cacheing. We are unable to cache page and revision responses because we currently respect the logged in user permissions and return everything, which is also less than ideal. It would be better to control it through a header or some other opt-in.
The action API already has several ways to treat the request as logged-out, and allow cacheing, including a 'Treat-as-Untrusted' header: https://gerrit.wikimedia.org/g/mediawiki/core/+/ee1e8978f4c6355ccf3562a3452c58e8504b3c9f/includes/api/ApiMain.php#733
Maybe all that's needed is better documentation, or some small changes to make them more convenient to use.
Yes, I think we need to update the task description. The idea would be to log something in Logstash when someone presses the "view this revision" link -- we currently don't (AFAIK) log this anywhere.
@sbassett can I repurpose this task to be specifically about logging when someone views suppressed content? (AIUI, we already have logging for the two items in the task description.)
Feel free. I was really just trying to capture what was discussed in T399718#11014418. I appreciate any helpful clarifications!
Seeing suppressed content is already opt-in in the interface (but not in the API). If you follow a link from e.g. page history, you will see a warning like this:
IIRc that's only the case for viewing content - but you would automatically see e.g. "oversighted" user names in the revision history, if you have the relevant permission. Is that not correct?
Notes from the API perspective, this change would also allow us to improve cacheing. We are unable to cache page and revision responses because we currently respect the logged in user permissions and return everything, which is also less than ideal. It would be better to control it through a header or some other opt-in.
The action API already has several ways to treat the request as logged-out, and allow cacheing, including a 'Treat-as-Untrusted' header: https://gerrit.wikimedia.org/g/mediawiki/core/+/ee1e8978f4c6355ccf3562a3452c58e8504b3c9f/includes/api/ApiMain.php#733
Maybe all that's needed is better documentation, or some small changes to make them more convenient to use.
Oh nice, I didn't know that.
It seems to me that at least for GET requests in the REST API, unprivileged mode should be the default.
Seeing suppressed content is already opt-in in the interface (but not in the API). If you follow a link from e.g. page history, you will see a warning like this:
IIRc that's only the case for viewing content - but you would automatically see e.g. "oversighted" user names in the revision history, if you have the relevant permission. Is that not correct?
No, they initially appear removed even to stewards or oversighters. You need to click on "change the visibility of selected revision" (if you have the necessary permissions) in order to check the removed user name.
