UCoC Violation Report: Coordinated Cross-Wiki Harassment and Admin Tag-Teaming (el.wiki / Commons)

Here is the context: During an active, ongoing community discussion (consensus-building) regarding a structural update on the Greek Wikipedia (el.wiki), Administrator A unilaterally deleted the work without prior consensus. When I formally asked them to provide the specific local policy that justified this deletion, they completely avoided the question and refused basic accountability (WP:ADMINACCT).

While this discussion was still active and I was waiting for a policy-based answer locally, Administrator B (acting in clear concert regarding the same dispute) followed my contribution history to Wikimedia Commons and began initiating retaliatory copyright/deletion claims against my uploaded files.

Because this involves a coordinated, cross-wiki retaliation effort by multiple local admins to intimidate an editor after shutting down a local consensus process, I want to ensure I report this to the correct global authority.Ioannis Kouimoutzoglou (talk) 12:00, 19 March 2026 (UTC)

@Ioannis Kouimoutzoglou UcoC cases may be opened here: Universal Code of Conduct/Coordinating Committee/Cases. — xaosflux ^Talk 12:06, 19 March 2026 (UTC)

Users with extended rights who were automatically demoted

Due to the configuration of group restrictions, the following users have recently automatically lost membership in some of their groups. These are:

• Karsten11@dewiki lost: checkuser
• Bináris@huwiki lost: checkuser
• Ustad abu gosok@idwiki lost: checkuser
• Penn Station@jawiki lost: checkuser, suppress
• Romanm@slwiki lost: checkuser

None of the affected groups has exactly one member: checkuser@dewiki (4 members), checkuser@huwiki (5 members), checkuser@idwiki (3 members), checkuser@jawiki (5 members), suppress@jawiki (3 members), checkuser@slwiki (3 members).

Please act accordingly if these users should lose access to any related services. Regards, MszBot (talk) 12:47, 25 March 2026 (UTC)

Intrusive surveillance script at trwiki

I talked about this in the Wikimedia Community Discord, and I was directed here by a steward (@AntiCompositeNumber:). Apparently 2 years ago the Turkish Wikipedia added a script to its common.js that monitors the browsers of every Wikipedia reader, logged in or otherwise, and publicly reports changes to the HTML using the "inspect element" tool of the browser. Here's the script, and here's the frankly way too short discussion in trwiki about its implementation.

I found out about this after another user tried to talk about this in the Turkish Wikipedia's village pump, but it was reverted as a "troll" just a few hours later. I tried it to see if it was true after reading about its reverted discussion. I was threatened with a block for this experiment, so I did not continue. Thanks for your attention. Betseg (talk) 23:07, 10 April 2026 (UTC)

To add a bit more context here, the script causes the user to make an edit on a report page if the user uses the console to edit their username specifically for the purposes of impersonating an administrator. Apparently there has been a problem with users using the console to change the username and then take screenshots for use off-wiki. Would appreciate someone a bit more technically minded confirming exactly how the script does that and if it is violating user privacy in doing so - at a glance I don't see anything myself. – Ajraddatz (talk) 23:49, 10 April 2026 (UTC)

The primary problem I see is that this script is causing automated revisions to be published under the logged-in user account without an intentional action to publish. As a result, a revision is attributed to that user and licensed under CC BY-SA, undermining the expectation of informed consent. This does not appear to require emergency intervention, as the script does not appear to capture or publish any sensitive information (such as browser or OS data). This seems like an inappropriate use of common.js and is trivial for bad actors to bypass. I suggest this project look into using AbuseFilter or other server-side mechanisms to log suspicious edits instead. — xaosflux ^Talk 00:40, 11 April 2026 (UTC)

I'm not sure that the abusefilter would work here, as there are no edits that could be flagged. I agree generally with the concern around forcing the user to publish an edit. However if WMF legal has already reviewed I'm not sure what else we would be able to do here, other than nudging the community to make changes or re-evaluate the need for the script. – Ajraddatz (talk) 03:21, 11 April 2026 (UTC)

Ah ok, so these are people that aren't even attempting to publish a revision - that are then being tricked in to publishing a revision without being show and agreeing to the TOU and Copyright notice - that seems like an issue itself. Not sure if that specific concern was brought up to legal. — xaosflux ^Talk 13:51, 11 April 2026 (UTC)

This is not a security problem. If interface admins want to do weird stuff they will. If the trwiki community is OK with what that script is doing I don't see a problem. I would personally avoid doing such things, but hey, some LTA are weird and dumb so maybe that works. I mean this should only work once. Nux (talk) 22:18, 12 April 2026 (UTC)

Read WMF Legal's comment here: . Nemoralis (talk) 02:43, 11 April 2026 (UTC)