to implement this functionality into Mediawiki

Please add the MediaWiki project tag (and review tags/subscribers) so the task can be found

I'm assuming that this is all meant to be oversight-level suppression, rather than admin-level (unless we want both as options).

Correct!

• Should editors be told that their names will be immediately hidden as editors?

Yes — no issues with informing editors that their names will be suppressed.

• Should enabling/disabling this be in the public protection log (if editors are informed before saving then probably) (only a question if the suppression is oversight-level)

Yes — it's best if there's some public accountability if, say, an oversighter is starts suppressing tons of pages.

• Should each edit be logged individually as a revision deletion/suppression action? If not it might be confusing if the edits are later made visible. If yes, under what name - maintenance script?

Yes (not sure what the proper name should be though).

• Should enabling this retroactively apply to all prior edits, or just new ones?

My feeling is that this should just apply to just new edits! That's a soft preference, though — I'm willing to be convinced otherwise if someone has very strong feelings about it.

I think there should be an option - hide previous versions or not. Currently ruwiki's bot hides all revisions, for example - all revisions of Putin's article since 2003.

In T354577#9451983, @MBH wrote:

I think there should be an option - hide previous versions or not. Currently ruwiki's bot hides all revisions, for example - all revisions of Putin's article since 2003.

Yes, but on the other hand the oversighter can easily go and hide those revisions themselves at the same time that they enable this for future revisions

It's not so easy if an article consists of >10000 revisions. Less actions to achieve the final goal is better.

Hi @DannyS712! Have you made any progress on this?

In T354577#9503830, @Htriedman wrote:

Hi @DannyS712! Have you made any progress on this?

I started a patch but its not a priority for me to be working on this, sorry - if someone else wants to do it I don't mind if you take over my patch. I'm updating the patch when I have time but it'll probably be a few weeks at least

There's no huge rush — we've deployed a short-term fix, but it requires some manual updating from WMF developers on a regular basis. If you can get to this in a few weeks that would be fine.

Will this hide data or suppress it? I think, hiding may be better on many pages, because if we suppress this data, even admins and arbitrators will can't see who did what on protected pages, and this will paralyze administrator actions and even ArbCom decisions. Ruwiki's bot hides this data, not suppresses, but it owner has suppress rights.

thanks for awareness around your capacity, @DannyS712!

@Ottomata flagging you on this, just as an FYI

Maybe I've misunderstood this task, but I can't think of a situation where this would be useful for *all* usernames: English Wikipedia oversighters can suppressdelete pages and that seems sufficient. If protection is needed in tandem with suppression, usually only the last couple of editors need their usernames to be suppressed. If all of the usernames are suppressed on a page, wouldn't that cause issues with attribution?

I highly doubt this would be enabled in enwiki. We are talking about is let's say Russian, Chinese, Arabic, Persian, and some other wikis with very sensitive material. it is already done in several articles in Russian Wikipedia: Here is article of Putin there https://ru.wikipedia.org/w/index.php?title=%D0%9F%D1%83%D1%82%D0%B8%D0%BD,_%D0%92%D0%BB%D0%B0%D0%B4%D0%B8%D0%BC%D0%B8%D1%80_%D0%92%D0%BB%D0%B0%D0%B4%D0%B8%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B8%D1%87&action=history

@Ladsgroup is correct about this — this is already happening on an ad hoc basis in some cases where there may be concerns about editor safety for sensitive material.

(Per the list in Russian Wikipedia, in more than a thousand pages. A code-based solution would be better at protecting privacy at such a number of pages at large, and would make it easier to revert this action when the political situation in Russia/Belarus changes.)

going to investigate the feasibility of this at the WMF Hackathon in a few weeks

I'm about to leave WMF, and I wanted to leave a comment here summarizing the design spec for this desired functionality.

The Problem

There are some communities operating within jurisdictions where editing pages on Wikimedia projects could be legally risky and/or physically dangerous. Some of these communities have taken steps to automatically redact editor information from sensitive pages by creating a bot that monitors for edits from sensitive pages and auto-hides edits to those pages whenever they are made.

This is a mostly effective mitigation, but leaves some vulnerabilities open:

1. Event stream-based architectures (like the Wikimedia event streams and WME) receive events as they happen, and retain a multi-day history of events, meaning an adversary may, for a limited time, be able to see the editor information of events that were suppressed on-wiki.
2. If the bot breaks or otherwise has downtime, edits could be missed and editor information could be present on-wiki.

The Solution(s)

Over the last year, we've temporarily patched vulnerability 1 above (see: T354456 and T356325), but these are imperfect solutions, as they need to be manually updated on a semi-regular basis. There is also no current mitigation for vulnerability 2, though the bot doing auto-hiding on-wiki seems to have pretty good uptime.

To fix this problem long-term (and ensure that it is managed by the community), we want to build a MediaWiki extension, limited to users with certain high-level privileges, that can enable this auto-hiding functionality from within MW.

The Spec

• A MediaWiki extension that does the following:
  • has functionality to search, add, and delete pages to a list of oversightprotected pages
  • has access control limitations so that only users with the role 'oversightprotecter' can edit the page, but all users can see it
• Using that list of pages, we then must do the following:
  • when a page is added to the oversightprotect list, the edit history of that page is automatically hidden
  • when an edit happens on a oversightprotected page:
    • the edit is published with the editor information pre-hidden
    • no actor/editor information is emitted to the eventstream (meaning no manual redaction must be done further on down the line)

Open question: What should happen when a page is removed from the list? Should the entire history, including edits that were never public, be shown? Should only new edits be shown?

Examples of similar functionality

• Functionality to search, add, and delete pages on a list, where viewing is allowed to everyone and editing is only allowed to people with specific permissions: SpecialTags in MW core
• Functionality to automatically edit revisions with certain characteristics: the TorBlock extension, specifically:

	/**
	 * If enabled, tag recent changes made by a Tor exit node.
	 *
	 * @param RecentChange $recentChange The change being saved
	 * @return bool true
	 */
	public function onRecentChange_Save( $recentChange ) {
		global $wgTorTagChanges;

		if ( $wgTorTagChanges && TorExitNodes::isExitNode() ) {
			$recentChange->addTags( 'tor' );
		}
		return true;
	}

Tagging @acooper for visibility.

Tagging Trust and Safety Product Team as something we might want to look at (cc @Niharika @Madalina) at some point. Would also be useful to get Stewards' perspective on this (cc @Urbanecm).