Tiny wikis, the kind that a global interface editor visits to make mass edits to the interface across many wikis, may not have many or any local folks qualified to review the edits.

Implementation also seems like it could be complicated. Would need a flaggedrevs-ish extension, and flaggedrevs is a headache.

I would guess that implementation of this would be not trivial. There may be low-hanging fruit tagged with 2026-user-javascript-incident that is a higher priority and/or easier to address, but I think this should remain on the radar as something to do.

This turns the concept of "administrator" ad absurdum as this is about having "buddies" instead.

Blindly blocking ‘high-risk’ actions would not work for small wikis and could even complicate fighting vandalism (as in the case of blocking the use of CheckUser). Even for some of the larger wikis, interface administrators might not always know what they are doing (and could be copying over code from other wikis, having been elected because a more qualified person was not available or interested) and there might not be another IA to review their work, or another IA could be just as clueless. You cannot really stop people intentionally adding code they don’t understand with the proposed mechanism. I do realize that this feature request seems to be aimed at stopping the misuse of compromised accounts but I think 2FA should be satisfactory in that regard unless the WMF actually wants to go through all the trouble of configuring auth very differently for all the Wikimedia wikis (which doesn’t seem warranted).

In T422312#11788031, @Aklapper wrote:

This turns the concept of "administrator" ad absurdum as this is about having "buddies" instead.

Haha, yeah, that could limit the effectiveness of the proposed mechanism as well, especially with people unwilling to upset others in different situations for whatever reason.

See T71445: Implement a proper code-review process for MediaWiki JS/CSS pages on Wikimedia sites for a more viable solution for such issue.

In T422312#11788001, @Novem_Linguae wrote:

Tiny wikis

In T422312#11788036, @Redmin wrote:

small wikis

Not a problem. Can just make it configurable, default being off, and turn it on for medium or large wikis. Alternatively, have it on everywhere, but allow any interface admin on the wiki farm to confirm the proposed edit.

In T422312#11788031, @Aklapper wrote:

This turns the concept of "administrator" ad absurdum as this is about having "buddies" instead.

I don't think the proposal is absurd. I think it's adequate security considering what JavaScript can do, and how highly visited some wikis are.

We're focused right now on platform-based protections (namely re-authentication), rather than introducing more social coordination. That's a development focus for us for the next few months.

In T422312#11788031, @Aklapper wrote:

This turns the concept of "administrator" ad absurdum as this is about having "buddies" instead.

Please explain this, @Aklapper. What do you mean?

In T422312#11788310, @EMill-WMF wrote:

We're focused right now on platform-based protections (namely re-authentication), rather than introducing more social coordination. That's a development focus for us for the next few months.

That's fine. Thanks.

In T422312#11788152, @Nirmos wrote:

In T422312#11788001, @Novem_Linguae wrote:

Tiny wikis

In T422312#11788036, @Redmin wrote:

small wikis

Not a problem. Can just make it configurable, default being off, and turn it on for medium or large wikis.

Bigger wikis don't have an issue which this fixes and smaller wikis are the more likely to install something they shouldn't.

Alternatively, have it on everywhere, but allow any interface admin on the wiki farm to confirm the proposed edit.

... big ditto to prior sentence. We do not need arbitrary interface admin from arbitrary small wiki confirming changes on large wikis.

And regarding

using the CheckUser tool.

No.

This already occurs by proposing changes on talk pages in the context of larger wikis for interface administrator && asking for a 2O for the CU tool. I doubt we need extra mediawiki-side barriers for this kind of interaction.

In T422312#11788945, @Izno wrote:

In T422312#11788152, @Nirmos wrote:

In T422312#11788001, @Novem_Linguae wrote:

Tiny wikis

In T422312#11788036, @Redmin wrote:

small wikis

Not a problem. Can just make it configurable, default being off, and turn it on for medium or large wikis.

Bigger wikis don't have an issue which this fixes and smaller wikis are the more likely to install something they shouldn't.

Alternatively, have it on everywhere, but allow any interface admin on the wiki farm to confirm the proposed edit.

... big ditto to prior sentence. We do not need arbitrary interface admin from arbitrary small wiki confirming changes on large wikis.

Hi, please explain "Bigger wikis don't have an issue which this fixes". This is would be a risk mitigation measure. Requiring a code review from a second person for a change to sitewide js, or a similarly very high risk action, seems like a good idea to me. I agree that if this was implemented on wikis where there is a shortage of interface admins that implementing this might require some additional social changes to ensure adequate availability of people with the needed permissions, but that's something that simply can be planned through more before any implementation of this which is likely to be at least months from now. So, how would this proposal, if implemented, not mitigate a risk that big wikis have?

In T422312#11788994, @Soda wrote:

This already occurs by proposing changes on talk pages in the context of larger wikis for interface administrator && asking for a 2O for the CU tool. I doubt we need extra mediawiki-side barriers for this kind of interaction.

Is there a technical limitation that would prevent someone from using the CU tool if they didn't have approval from a second CU? I believe that there is no such technical limitation, although probably WMF and/or the audit committee actively monitor for anomalous use of the CU tool. If they don't then I could address that in a second, and probably private, security ticket. Given potential sensitivity on how CU usage is monitored, please please don't discuss details of this in this public ticket, but I can follow up in private with WMF if needed.

In T422312#11797423, @Pine wrote:

In T422312#11788994, @Soda wrote:

This already occurs by proposing changes on talk pages in the context of larger wikis for interface administrator && asking for a 2O for the CU tool. I doubt we need extra mediawiki-side barriers for this kind of interaction.

Is there a technical limitation that would prevent someone from using the CU tool if they didn't have approval from a second CU? I believe that there is no such technical limitation, although probably WMF and/or the audit committee actively monitor for anomalous use of the CU tool. If they don't then I could address that in a second, and probably private, security ticket. Given potential sensitivity on how CU usage is monitored, please please don't discuss details of this in this public ticket, but I can follow up in private with WMF if needed.

There is no technical mechanism, but, to my understanding, there is a fairly thorough post-facto review of actions by peers (especially in the context of SPI). Additionally, as a volunteer, you can basically always ask CU folks for a 2O on a fellow CU's actions. If not, Arbcom is your second place of appeal, followed by the Ombuds Commission.

In T422312#11799712, @Soda wrote:

In T422312#11797423, @Pine wrote:

In T422312#11788994, @Soda wrote:

This already occurs by proposing changes on talk pages in the context of larger wikis for interface administrator && asking for a 2O for the CU tool. I doubt we need extra mediawiki-side barriers for this kind of interaction.

Is there a technical limitation that would prevent someone from using the CU tool if they didn't have approval from a second CU? I believe that there is no such technical limitation, although probably WMF and/or the audit committee actively monitor for anomalous use of the CU tool. If they don't then I could address that in a second, and probably private, security ticket. Given potential sensitivity on how CU usage is monitored, please please don't discuss details of this in this public ticket, but I can follow up in private with WMF if needed.

There is no technical mechanism, but, to my understanding, there is a fairly thorough post-facto review of actions by peers (especially in the context of SPI). Additionally, as a volunteer, you can basically always ask CU folks for a 2O on a fellow CU's actions. If not, Arbcom is your second place of appeal, followed by the Ombuds Commission.

Thanks. I created a new security task regarding the CU tool specifically.

I appreciate the broad and creative thinking around this, but I think such a major feature change needs to be validated a bit more. My understanding is that the ticket was created in response to a particular security incident, and I have no reason to believe that the feature would have prevented the accident. A staff member could have easily gotten a colleague to turn the second key.

On the other hand, such a change would make it much harder for volunteer interface admins to do their important work. A basic first step would be to demonstrate consensus on any wiki, that they want such a feature.

Part of why I asked for a proper incident report to be filled out was so that we have more information around the workflow leading up to the accident, which could help us identify exactly which measures could have prevented it.

The one major thing that have led to the accident was that one should NEVER, EVER run random scripts (in batches of hundreds of them in alphabetic order) from an interface-admin account.

In T422312#11807904, @Wellverywell wrote:

The one major thing that have led to the accident was that one should NEVER, EVER run random scripts (in batches of hundreds of them in alphabetic order) from an interface-admin account.

Right! It seems like a "sudo" style of temporarily elevating permissions like the parent task T197160: All security-sensitive MediaWiki functionality should require elevated security (thanks @Pine for linking) would have helped, from the limited information available. Then it might have been fine or at least less destructive to try random scripts.

Hi @awight I would hope that a second person would not be so careless as to turn the key. I would treat this as the equivalent of a second engineer who is supposed to do code review of the first engineer's code of doing a careless job of the code review. If bad code were then to become active in production and cause a catastrophe, I would treat the second engineer as also responsible for the problem given their carelessness in the code review. But I see little support in this thread for implementing this second layer of review, so this is unlikely to proceed for now.