Create separate user group for editing sitewide CSS/JavaScript that does not include administrators by default
Open, Needs TriagePublic

Tokens
"Like" token, awarded by matej_suchanek."Like" token, awarded by ToBeFree."Like" token, awarded by TerraCodes."Like" token, awarded by Liuxinyu970226."Like" token, awarded by chasemp."Love" token, awarded by MichaelSchoenitzer."Like" token, awarded by Harej."Like" token, awarded by Smalyshev."Evil Spooky Haunted Tree" token, awarded by Krenair."Like" token, awarded by Pcoombe."Love" token, awarded by Jdlrobson."Love" token, awarded by Bawolff."Barnstar" token, awarded by Amire80."Yellow Medal" token, awarded by matmarex."Yellow Medal" token, awarded by daniel."Like" token, awarded by MusikAnimal.
Assigned To
None
Authored By
Tgr, Mar 19 2018

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.


Patches:

(Draft) community consultation page: User:Tgr/Create separate user group for editing sitewide CSS/JS
(Draft) user group info page: User:Tgr/Technical_administrator

Affected Wikimedia user groups:

  • sysop
  • user (donatewiki, foundationwiki)
  • securepoll (officewiki)
  • electcomm/staffsupport/electionadmin (votewiki)
  • centralnoticeadmin (metawiki, testwiki)
  • botadmin (frwiktionary, mlwiki, mlwikisource, mlwiktionary)
  • engineer (ruwiki)
  • interface-editor (azbwiki, ckbwiki, elwiktionary, hewiki, huwiki, jawiki, pswiki, ptwiki, trwiki, urwiki)
  • templateeditor (fawiki, rowiki)
  • translator (incubatorwiki)
  • wikidata-staff (wikidata)

Sitewide CSS/JS editing not covered by the patch:

Related issues:

There are a very large number of changes, so older changes are hidden. Show Older Changes

The developers are a continuing massive security risk, and one that is only being kept in check by these "vulnerabilities" that this plans to "fix". We've had confrontations in the past that only failed to be catastrophic because the WMF doesn't actually have the technical ability to stop people from editing JS. Control over the site can't be easily decoupled from powers necessary for basic maintenance, so the WMF and the developers can't seize power without causing everything to fall apart.

Any work towards "fixing" control over JS erodes the balance of power.

Admins are trusted with the site. So much of the software is built upon that assumption. The movement is built upon that assumption being right.

Tgr added a comment.Jun 12 2018, 10:45 AM

Looking at how much JS editing happens in smaller wikis:

0: jdbc:hive2://analytics1003.eqiad.wmnet:100> select count edits, count(*) cnt from (select wiki_db wiki, count(*) count from wmf.mediawiki_history where snapshot='2018-05' and event_entity = 'revision' and event_type = 'create' and event_timestamp > '2017-06-01 00:00:00' and page_namespace = 8 and page_title like '%.js' and wiki_db in (<small.dblist>) group by wiki_db order by count desc limit 1000) x group by count order by count asc limit 100;
1       33
2       23
3       10
4       6
5       3
6       1
7       3
8       1
9       3
10      1
11      2
12      1
13      1
15      2
20      1
22      1
24      1
33      2
53      1

So from the 508 small wikis, 412 had no Javascript namespace edits in the last 12 months, 75 had five or less, 21 had more.

TTO added a comment.Jun 12 2018, 11:00 AM

How many of those were from local privileged users vs global privileged users (e.g. global interface editors, global sysops, stewards)?

stjn added a comment.Jun 12 2018, 1:04 PM

The developers are a continuing massive security risk, and one that is only being kept in check by these "vulnerabilities" that this plans to "fix". We've had confrontations in the past that only failed to be catastrophic because the WMF doesn't actually have the technical ability to stop people from editing JS. Control over the site can't be easily decoupled from powers necessary for basic maintenance, so the WMF and the developers can't seize power without causing everything to fall apart.

Any work towards "fixing" control over JS erodes the balance of power.

Admins are trusted with the site. So much of the software is built upon that assumption. The movement is built upon that assumption being right.

That might be true in smaller projects, but in any big project admins are not being elected with the assumption that everyone has the proficiency in JS/CSS. I mean, English Wikipedia has more than a thousand administrators; how many of them were elected with their technical proficiency in mind?

This, in my opinion, has nothing to do with WMF’s lust for power over editors, because having all local developers demoted because of some dispute would be quite as atrocious as demoting all local admins is right now. So if they are going to go for this option in any sort of dispute, they would have to put up with enormous consequences of such decision, because any sensible developer, in my opinion, would back community’s point of view over WMF’s.

This change, as proposed, takes no control away from the community. It provides more fine grained control to the community. If people want to keep the "tech admin" privileges coupled with regular sysop privileges, they still can do that. If they want to grant access to those things separately, they now can also do that. That's all.

Control over the site can't be easily decoupled from powers necessary for basic maintenance, so the WMF and the developers can't seize power without causing everything to fall apart.

That's simply not the case. If the WMF wanted to, it would be trivial to simply deactivate all on-wiki JS and CSS. The fact that editing ability for JS is currently coupled with other admin powers dowsn't prevent "developers from seizing power". What prevents "developers from seizing power" is the fact that developers and the WMF understands how the community works and wants to keep that community empowered.

Johan added a subscriber: Johan.Jun 12 2018, 3:11 PM

Admins are trusted with the site. So much of the software is built upon that assumption. The movement is built upon that assumption being right.

At my home wiki, we elect almost only based on being reasonably familiar with the guidelines, ability to follow community consensus, and not being unnecessarily rude. We happily give out access to admin tools to anyone who's been around for a while where there are no big warning signs telling us we shouldn't, because "adminship shouldn't be a big thing". Most admin elections see no opposing votes. I would say it's less of a trust thing and more a lack of distrust.

CSS/JS knowledge or password security simple don't enter the discussion. That's not something taken into consideration, so I'd say it's something of a stretch to say the community has entrusted me with access to edit site-wide JS.

Tgr moved this task from Backlog to Pending on the User-Tgr board.Jun 13 2018, 5:29 PM

Dropping from TechCom radar, seems to be on track.

Guycn2 added a subscriber: Guycn2.Jun 14 2018, 8:40 AM

I understand the importance of limiting editing CSS/JS files; However, I do not think the proposed change should be implemented on all wikis. For instance, I have sysop privileges on some small wikis, where I also help maintaining the user interface every now and then (for example, I remove obsolete unnecessary JS code from common.js, as well as local CSS fixes for bugs that have already been fixed, etc.) There are not many active administrators on these small wikis, and thus the potential risk of unconstructive edits to CSS/JS files is very minor.

Therefore, I suggest implementing the proposed limitation for big wikis, while letting small wikis (where there is no major potential risk) choose whether they want to have it too or not.

Therefore, I suggest implementing the proposed limitation for big wikis, while letting small wikis (where there is no major potential risk) choose whether they want to have it too or not.

This isn’t really the case. What if a steward or a WMF staff goes on the wiki to do something?

They’re possible a target under the same conditions

Splitting rights differently between wikis just adds complexity

That being said, there’s no reason a wiki cannot locally decide to add their sysops to the new group too.

Aklapper added a comment.EditedJun 14 2018, 1:43 PM

@Guycn2: Even if there was "no major potential risk" I don't see a good reason why not to fix also minor potential risks (if you don't define disadvantages of fixing a minor risk). Because they are risks.

there’s no reason a wiki cannot locally decide to add their sysops to the new group too

The problem here is that there are many wikis that do not have any bureaucrats. These projects would effectively lose the ability to edit their own site-wide CSS and JS.

No, they'd just have to have Stewards assign the rights to whoever is selected for the new role. Just as they already have to do when new admins are selected.

Reedy added a comment.Jun 14 2018, 3:23 PM

No, they'd just have to have Stewards assign the rights to whoever is selected for the new role. Just as they already have to do when new admins are selected.

And if they're getting stewards to do the +sysop anyway, it's less than a seconds worth of extra work (clicking another check box) when they do the change. I'm pretty sure the Stewards won't care if they have to check two boxes rather than one

Tgr added a comment.Jun 14 2018, 3:31 PM

Therefore, I suggest implementing the proposed limitation for big wikis, while letting small wikis (where there is no major potential risk) choose whether they want to have it too or not.

That is a misunderstanding of the threat model. Even if you assume that exposing the readers and editors of a small wiki to attacks is not a major risk (which seems irresponsible to me), with single-sign on and cross-wiki requests XSS on a small wiki can trivially be expanded into XSS on all wikis.

Harej awarded a token.Jun 15 2018, 5:19 PM
Tgr updated the task description. (Show Details)Jun 16 2018, 8:45 PM
Tgr added a comment.Jun 16 2018, 10:18 PM

How many of those were from local privileged users vs global privileged users (e.g. global interface editors, global sysops, stewards)?

0: jdbc:hive2://analytics1003.eqiad.wmnet:100> select count edits, count(*) cnt from (select wiki_db wiki, count(*) count from wmf.mediawiki_history where snapshot='2018-05' and event_entity = 'revision' and event_type = 'create' and event_timestamp > '2017-06-01 00:00:00' and page_namespace = 8 and page_title like '%.js' and wiki_db in (<small.dblist>) and event_user_text not in (<`curl -s 'https://meta.wikimedia.org/w/api.php?action=query&format=json&list=globalallusers&agulimit=max&agugroup=steward%7Cglobal-sysop%7Cglobal-interface-editor' | jq '.query.globalallusers[].name' | paste -s -d,`>) group by wiki_db order by count desc limit 1000) x group by count order by count asc limit 100;
edits   cnt
1       8
2       4
3       3
4       2
5       2
7       2
9       1
13      1
20      1
21      1
24      1
33      2
45      1

Not counting those groups, 479 small wikis had zero edits from a local privileged user, 19 had five or less, 10 had more.

Zerabat added a subscriber: Zerabat.Sun, Jul 1, 6:12 PM

I can't find the RfC for this. Could you give me a link to read input from community?

Izno added a comment.Sun, Jul 1, 7:49 PM

I can't find the RfC for this. Could you give me a link to read input from community?

These changes don't strike me as needing community consensus. Why do you think the community needs to provide input on this task?

daniel added a comment.Sun, Jul 1, 8:45 PM

I can't find the RfC for this. Could you give me a link to read input from community?

This was brought to the attention of TechCom, but we found no need for an RFC. This change is not strategic, not cross-cutting, nor hard to undo (just assign the new permission the sysop group per default).

Don't get me wrong: Changing the default behavior for wmf wikis / requiring users to be added to a new group in order to be able to edit site wide JS and CSS files warrants community feedback. This happened, the discussion for that consultation can be found at https://meta.wikimedia.org/wiki/Talk:Creation_of_separate_user_group_for_editing_sitewide_CSS/JS.

Note however that this change was driven by incidents that threatened the integrity of the WMF run sites and the privacy of our users. While community input for such changes is important, preventing security breaches is the WMF's prerogative. Allowing users to edit JS code executed in other user's browsers with no checks from staff is a huge risk. So I think it's acceptable to require local communities to explicitly specify who they trust to do such things.

chasemp added a subscriber: chasemp.

Realistically speaking,
as a bug reporter and sometimes a person who pushes community consensus to phabricator, I don't see the reason for not giving current users having the interface editor permission or single permission equivalent to obtain the right automatically - that say that interface editor should automatically transit to techadmin, where administrators shouldn't do so.

Anomie added a comment.Thu, Jul 5, 1:12 PM

There are, broadly speaking, two reasons for someone to have an "interface editor" permission:

  • The person is editing JS or CSS.
  • The person is only editing translations or other things that are not JS/CSS.

We should avoid giving the new group to people in the second bullet, as that would be counter to the goals behind this change.

daniel added a comment.Thu, Jul 5, 1:17 PM

@1233thehongkonger to me, that seems counter-intuitive. Allowing people to edit interface messages generally requires a lower level of trust than allowing them to block people and delete pages. On the other hand, allowing people to edit JS that is run in the browser of every visitor should require a higher level of trust than regular adminship, since it effectively allows them to hijack every account on the wiki.

@1233thehongkonger to me, that seems counter-intuitive. Allowing people to edit interface messages generally requires a lower level of trust than allowing them to block people and delete pages. On the other hand, allowing people to edit JS that is run in the browser of every visitor should require a higher level of trust than regular adminship, since it effectively allows them to hijack every account on the wiki.

If this is the case, then there wouldn't be interface editors at some wikis.

I really would hope that the new group would be granted globally rather than locally though.

Nirmos added a comment.Fri, Jul 6, 2:48 PM

If this is the case, then there wouldn't be interface editors at some wikis.

The idea of an interface editor or engineer group that is meant to be more accessible than sysop is indeed backwards with regard to security.

I really would hope that the new group would be granted globally rather than locally though.

There is already global-interface-editor, but understandably, that right is very hard to get because of the potential damage someone could cause. With that said, though, I don't fully understand what you're trying to say. This task is about removing the right from people who don't use it anyway. If the individual communities remove it from people who don't use it, and let people who use it retain the rights, no one should notice any difference, while the security situation is much better. What you're saying seems to be that every new techadmin should instead be a global interface editor, but that would make the situation much worse with regard to security. It also would simply not work policy-wise. Only a small percentage of all techadmins across all WMF wikis would ever be trusted with global-interface-editor. You can view the complete list of members to get an idea of how restricted that is.

1233thehongkonger added a comment.EditedFri, Jul 6, 3:13 PM

If this is the case, then there wouldn't be interface editors at some wikis.

The idea of an interface editor or engineer group that is meant to be more accessible than sysop is indeed backwards with regard to security.

I really would hope that the new group would be granted globally rather than locally though.

There is already global-interface-editor, but understandably, that right is very hard to get because of the potential damage someone could cause. With that said, though, I don't fully understand what you're trying to say. This task is about removing the right from people who don't use it anyway. If the individual communities remove it from people who don't use it, and let people who use it retain the rights, no one should notice any difference, while the security situation is much better. What you're saying seems to be that every new techadmin should instead be a global interface editor, but that would make the situation much worse with regard to security. It also would simply not work policy-wise. Only a small percentage of all techadmins across all WMF wikis would ever be trusted with global-interface-editor. You can view the complete list of members to get an idea of how restricted that is.

I completely know some of the reason behind this change is due to the recent Commons restricted incident, but I didn't see the reason for interface-editor who do not run for admin to have this right removed-doesn't make sense at all , at least, for me. Some of them did not want to be admin just purely because they don't want to get that, and I would personally say to send out surveys to those current interface editors at those wikis to ask for their own opinion.

I really suggest to extend both the transition and the consultation period. It is having a backslash at my home (zh) wiki already.

Note for the global-interface-editor, I don't really see the difference if some css change at one wiki would be applied instantly throughout the whole wiki.


The best way to mitigate these security issue related to css and js would actually be adding a deployment (and/or review) period for these two things : Any changes in between two deployment periods (currently used to deploy newer versions of MediaWiki to different WMF-owned wikis) would be marked as a specific issue.

The new way (for which I propose), would be:

Interface code would be accessible to anyone, but no one can edit it. At the same time, the changes to these codes should not be deployed immediately, but, would be reviewed by a team (by WMF or the community or ArbCom or something similar to that) before it gets deployed. This should solve the case about security issues. (or something like the Pending Changes Reviewer used at Sitewise css and js and auto-accept=staff )

Izno added a comment.EditedFri, Jul 6, 3:37 PM

The best way to mitigate these security issue related to css and js would actually be adding a deployment (and/or review) period for these two things : Any changes in between two deployment periods (currently used to deploy newer versions of MediaWiki to different WMF-owned wikis) would be marked as a specific issue.

This is in the description at T71445: Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites.

The best way to mitigate these security issue related to css and js would actually be adding a deployment (and/or review) period for these two things : Any changes in between two deployment periods (currently used to deploy newer versions of MediaWiki to different WMF-owned wikis) would be marked as a specific issue.

This is in the description at T71445: Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites.

Then I don't get it.
Why are they pushing only one option to the greater community?

Anomie added a comment.Fri, Jul 6, 4:20 PM

Both this and T71445 are useful things to do.

T71445 hasn't happened yet because it's much more complex to design and build.

Both this and T71445 are useful things to do.

T71445 hasn't happened yet because it's much more complex to design and build.

Actually it can be something like:

Re-introduce superlock which locks these css and js pages.
Let those pages be edited by the staff usergroup only, or whatever.

Both this and T71445 are useful things to do.

T71445 hasn't happened yet because it's much more complex to design and build.

Actually it can be something like:

Re-introduce superlock which locks these css and js pages.
Let those pages be edited by the staff usergroup only, or whatever.

I'd be careful about bring back superprotect though

I know the problem about Superprotect. What in here superprotect does is the same, but anyone can get your hands to the talk page to suggest changes to that particular file, though I would hope nothing would change, at best.

stjn added a comment.Mon, Jul 9, 12:03 PM

Hey, I don’t have the ability to point this out in patch, but somewhere in the edits for patches you’ve changed rights from +ruwiki to +quwiki, for example, here:
https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/421124/6/wmf-config/InitialiseSettings.php

Please don’t merge it like this :-)

Reedy added a comment.Mon, Jul 9, 12:08 PM

Hey, I don’t have the ability to point this out in patch, but somewhere in the edits for patches you’ve changed rights from +ruwiki to +quwiki, for example, here:
https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/421124/6/wmf-config/InitialiseSettings.php

Please don’t merge it like this :-)

In this patch specifically? What line numbers?

stjn added a comment.Mon, Jul 9, 12:12 PM

I don’t know exactly where that happened (doesn’t seem like it is exactly there, but it is somewhere in those patches), but line 9524/9510 in the link should read as +ruwiki, since mentioned tasks are for engineer group in ruwiki, T144599 / T190619.

Tgr added a comment.Mon, Jul 9, 12:18 PM

No, that's for a different wiki. Lines are not always consecutive for diff view.

stjn added a comment.Mon, Jul 9, 12:20 PM

Ah, don’t even know how I didn’t notice added lines after clicking on ‘show skipped’. Sorry for misunderstanding.

Tgr added a comment.Mon, Jul 9, 12:26 PM

I really suggest to extend both the transition and the consultation period. It is having a backslash at my home (zh) wiki already.

I think two weeks are plenty of time to leave a comment on a wiki page. As for the transition period, please explain (preferably on the wiki page) what tasks will need to be done on your wiki and how much time you expect you'll need for them. It should not be a big deal to make a transition period longer if it's really needed.

@Tgr I'm afraid only zhuyifei can answer why "two weeks are however not plenty of time to leave a comment on zhwiki"

I didn't see the possibility for the interface editors not having the ability to edit userjs.
Though I am skill skeptical of this idea - isn't there other ways to resolve this problem?

Are all the wiki community informed about this proposal in village pumps and mailing lists? This is a serious change and needs more discussion and consensus from communities. The timespan of 2 weeks for consultation is also not much.

@Tgr I'm afraid only zhuyifei can answer why "two weeks are however not plenty of time to leave a comment on zhwiki"

Dunno. Why? I'm not too familiar with zhwiki stuffs.

Though I am skill skeptical of this idea - isn't there other ways to resolve this problem?

@1233thehongkonger: Please read the previous comments in this very ticket?

Are all the wiki community informed about this proposal in village pumps and mailing lists? This is a serious change and needs more discussion and consensus from communities. The timespan of 2 weeks for consultation is also not much.

I just checked this page and noticed many wikis are not at all informed. As I am reading the comments in meta I guess, community members are not consulted properly and this is already pre-decided to implement in a short notice, whether or not small wikis expressed their concerns, which is disturbing.

RP88 added a subscriber: RP88.Tue, Jul 10, 11:26 AM

I don't know why you think this is such a big problem

https://meta.wikimedia.org/wiki/Creation_of_separate_user_group_for_editing_sitewide_CSS/JS#How_you_can_help

Also, please make sure your wiki has some documentation and election process for the new group past the migration period. Again, this could be as simple as asking newly elected administrators whether they also want to be technical administrators and whether they are familiar with Javascript and basic security practices. In any case, it is recommended to make the bar for technical admins at least as high as for admins (in terms of trust and user behavior), and maybe even higher (see the user group page for more advice).

If you deem it necessary, just grant them both groups?

I just checked this page and noticed many wikis are not at all informed.

@Bodhisattwa: Feel free to make that list more complete in order to fix this problem.

Johan added a comment.Tue, Jul 10, 1:55 PM

For what it's worth, it was also included in Tech News (which is how the technical community communicates most technical changes to the wikis), in the issue that went out yesterday.

Teles added a subscriber: Teles.Tue, Jul 10, 6:47 PM

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.

Reedy added a comment.EditedSun, Jul 15, 5:16 PM

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

I just want to ask:

Is this group must be linked with the sysop usergroup or not? (i.e. you must be in the sysop group before you can be the techadmin)

Per this discussion:
https://zh.wikipedia.org/wiki/Wikipedia:%E4%BA%92%E5%8A%A9%E5%AE%A2%E6%A0%88/%E6%96%B9%E9%92%88#%E4%B8%89%E3%80%81%E5%80%99%E9%81%B8%E4%BA%BA/%E7%94%B3%E8%AB%8B%E8%80%85%E8%B3%87%E6%AD%B7%E8%A6%81%E6%B1%82

no, mediawiki doesn't have restrictions like that on groups. you don't need to be a sysop to be a bureaucrat and you won't need to be an sysop to be a techadmin

ToBeFree added a subscriber: ToBeFree.
Tgr added a subscriber: Ajraddatz.Wed, Jul 18, 11:15 AM

Some reflections, a bit over halfway into the consultation:

  • "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.
  • I'm leaning towards not giving bureaucrats the right to create/remove interfaceadmin by default, as smallish wikis with just a few non-tech-savvy bureaucrats might not be able (or willing) to handle it well (the same considerations about being a target of hackers that applies to admins prior to this change applies to bureaucrats as well). Local communities can still decide that they want their bureaucrats to manage interface admins, this would just be the default. Feedback: https://meta.wikimedia.org/wiki/Talk:Creation_of_separate_user_group_for_editing_sitewide_CSS/JS#Making_assigning_of_techadmin_membership_central_by_default?

@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 ?