Description

Currently, MediaWiki administrators (members of the sysop user group) have the ability to edit Javascript pages: site-wide JS such as MediaWiki:Vector.js, MediaWiki:Gadget-*.js pages (used by the Gadgets extension, can be configured to load by default) and JS subpages of another user (including User:<name>/global.js, used by the GlobalCssJs extension). Thus an attacker who compromises an admin account (on some wikis, even a less privileged account such as templateeditor on hewiki) can deploy malicious Javascript to all visitors.

The ability of wiki communities to shape wikis to their liking by deploying custom Javascript is an important tool for increasing power user productivity and empowering communities to solve their problems; as such, it is desirable even with this risk. The way access to this right is currently given is suboptimal though:

Most administrators have no Javascript editing skills, and as such there is very little benefit in them having that right. (Maybe faster revert time in case of an attack, but even that is highly questionable.)

Administrators who lack computer skills not only don't need Javascript editing abilities but are extra dangerous attack vectors as they often have weaker password and antivirus practices, don't keep their systems up to date etc.

With Javascript editing being just one of the many rights administrators have, most communities do not fully understand its dangers and are not sufficiently careful about assigning it. E.g. relatively low-trust user groups sometimes get (that resulted in T189665 recently), no one is worried about long-inactive admins retaining their privileges, there is very little oversight of small wikis with few active admins etc.

The obvious solution for this is to split Javascript editing into a separate, dedicated user group, take away the right from all other user groups (sysop, interface-editor/engineer/templateeditor on some wikis), clearly document the risks of handing out that user group, and set higher expectations for membership (e.g. use of two-factor authentication). There is some paranoia around this issue (some people an attempt to revive Superprotect behind anything that changes Javascript editing workflows) but it is unlikely that many editors will be concerned as long as it is made clear that the power to assign Javascript editing capabilities is left with the local communities. Local bureaucrats would be able to add and remove users, and current admins (or interface editors where that right exists) could be grandfathered in if they want to.

Gadgets after T31272: Implement Gadgets 2.0 (will move gadgets out of the MediaWiki namespace and use gadgets-edit and maybe gadgets-definition-edit rights instead; we might want to have rights separation between global and personal gadgets).

Event Timeline

The main problem raised is security and risk for compromising an administrators account. Y not make 2FA compulsory for administrators account. You can't restrict from the fact that administrators are trusted users from the community. And community votes for an appointment of an Administrator. Frankly speaking I don't find this as a concrete solution .Is there any indication that these so called 'engineer/etc' are secured from compromising? . Some Administrators help users in installing user scripts as they have limited knowledge, this was like a plus point. Some wikis have an user group like eliminator which can delete pages etc, so after this change it will be like those. No mediawiki namespace edits than it's very hard time for small wikis to progress in technical stuff. Whereas this request is like just addition of new user group in name of security, whereas no actual solutions of security.
Well waiting for some user that can clear my mind that how secure this new user group will be.

The main problem raised is security and risk for compromising an administrators account. Y not make 2FA compulsory for administrators account. You can't restrict from the fact that administrators are trusted users from the community. And community votes for an appointment of an Administrator. Frankly speaking I don't find this as a concrete solution .Is there any indication that these so called 'engineer/etc' are secured from compromising? . Some Administrators help users in installing user scripts as they have limited knowledge, this was like a plus point. Some wikis have an user group like eliminator which can delete pages etc, so after this change it will be like those. No mediawiki namespace edits than it's very hard time for small wikis to progress in technical stuff. Whereas this request is like just addition of new user group in name of security, whereas no actual solutions of security.
Well waiting for some user that can clear my mind that how secure this new user group will be.

Thanking you.

If you read the thread you would see the small wiki thing is a non issue. If they want to grant both groups they can

Making 2FA compulsory is harder. What if people don’t have an appropriate device to be able to use? Not everyone has a smart phone.

Plus the social challenges of when people lose/break devices and then struggle to prove its their account

The point is to reduce the attack surface. Many people have access to tools they don’t need, or don’t know how to use

"interface admmin" is a better name than "technical admin" (props @Ajraddatz) - it still expresses that this is a powerful permission, but is more clear about what it does. I'll probably go with that.

Several people remarked that two weeks is a bit short for local communities to agree on the required process. Also we need an announcement that explains to communities what they need to do without requiring them to read through the rather verbose consultation page (which needs to be translated). So I'm thinking the timeline should be: consultation ends on the 23rd, announcement is sent to translators; announcement is published and first set of patches (creating the new user group and bureaucrat access to it but not touching existing ones) are merged on the 30th; rest of patches (removing access from old groups) are merged on the 27th of August.

@Tgr if communities need to opt-in to enable this of their bureaucrats the project level RfCs may take some time (a month is not unusual for a project like enwiki) - as the final specification for what access is being removed from sysop, and which access is being included by default in local-interfaceadmin ?

If this is just some obvious consequence of changing the permission balance instead of a real, effective security problem, I think restricting the task does more harm than good. It prevents users from giving input how these issues should be handled. Such tasks have to be resolved before this change is deployed either way, so there's not harm in having people be aware of possible problems for now. If such issues aren't fixed before deploying, people will get the idea how to exploit them within weeks either way, since issues of that type are generally quite obvious.

Following up on discussion from enwiki: Will local sysops's still be able to delete css/js pages if they are not also able to edit them? Specifically in relation to user css/user js pages I suspect this is going to increase the number of users seeking access. Would it be difficult to allow admins to continue to be able to delete? I'm guessing same problem will occur for oversighting these pages? That is if an OS is not also an interface admin will they be unable to perform oversight operations on these pages?

Global renaming bypasses any local restrictions that would prevent the action or subsequent actions from being completed (i.e. if a global renamer was locally blocked on the wiki, if the page was fully protected, etc)

@SpeedyGonsalesright-hidden is/was a Commons hack to prevent a gadget from being used by anyone. Apparently whoever ported the gadget didn't bother to port the message as well. IIRC these days ResourceLoader has a hidden option so the hack is not needed anymore.
Anyway, this has nothing to do with editing, permissions shown on Special:Gadgets are for enabling gadgets.

Because no one has this right (because it does not exist), no one can enable the gadget, so it is effectively hidden from everyone. This is used for some libraries used by other gadgets that don't do anything by themself. Normally you'd use e.g. rights=block on a gadget that provides improvements to the block form, so that it would not show up in preferences for people who can't use it.

@matmarex Thanks for the link! That helps. I'm talking about the removal of mw-space editing perms from the sysop right. I assume it'll be the European mid-day SWAT, like the July 30th change? Or will the config be changed at a different time? I mostly am interested in what time on the 27th of August these other changes will happen.

Small question: while separating rights, you have granted sitewide JSON editing to sysops, but not granted it to other groups that had editinterface before (specifically, this situation is concerning RuWP’s engineers). Is this intentional in any way or could this be fixed without additional bureaucracy?

Each user has the authority to retrieve and edit "Wikipedia language projects" and give them in different sections in other projects, and there is a problem where I do not find it good to give this power to users who have this powerful primitive, and modifying the page of this type of pages is dangerous to the user settings and I see that these The power should wait a bit and be pulled from the users who have obtained it until the problems are fixed