Talk:Creation of separate user group for editing sitewide CSS/JS

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
This page is for discussions related to the Creation of separate user group for editing sitewide CSS/JS page.

  Please remember to:

Wikimedia Community Logo.svg
Filing cabinet icon.svg
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 7 days and sections whose most recent comment is older than 30 days. For the archive overview, see Archive.

Will this change be implemented on all wikis?[edit]

If you please, I'm copying here what I've written in the related Phabricator ticket:

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. Guycn2 · 10:59, 14 June 2018 (UTC)

@Guycn2: As the text says, The damage is not limited to a single wiki: due to Wikimedia wikis all using a single global login system, an exploit on one wiki can be used to take over admin accounts on any other wiki and extend the attack further. So if anything small-wiki accounts are higher-risk because they are less watched.
In any case, there is no reason you couldn't get technical admin privileges on the wikis where you have admin privileges - they can be given by the same people. --Tgr (talk) 20:04, 14 June 2018 (UTC)
@Tgr: What you are saying is obviously true, but since small wikis can decide about their own wiki there is no reduction of risk by letting them ask a steward to assign an additional flag at all. I don't believe that the right-assigning steward will go into a very deep evaluation on whether the admin in question is a JS/CSS expert or not. Hence, while I understand what this measure is trying to solve on big wikis with thousands of (inactive) admins like enwiki, enabling this group split on small wikis with 0, 1 or 2 admins would seem highly bureaucratic and annoying to the community in question to me, without solving any problem. I would kindly ask you to reconsider implementing this change on small wikis. --Vogone (talk) 19:09, 27 July 2018 (UTC)
@Vogone: the main risk is account theft, not real admins plotting evil (that can happen but is super rare), and an attacker stealing an account and asking bureaucrats/stewards out of the blue for techadmin/interface-admin rights is very likely to raise some red flags for the local community (who can then warn the steward). --Tgr (talk) 17:28, 29 July 2018 (UTC)

Well, I am here for the same reason, we have just 5 admins at or.wikipedia and fewer at sister sites, so i don't think this is really required at sites! If this has to happen, then I hope we are all aware of the changes that are going to happen and how to implement and deal with the changes first. I would suggest to give enough time to the communities and first finalise the names, rights, procedures, etc. before notifying. And make a brief and precise summary. Not everyone can go through these discussisons to know what is going on! -- ɑηsuмaη «Talk» 06:39, 10 July 2018 (UTC)

@Ansumang: small wikis are much more at risk than large ones; often they have a few admins but no one able to vet JS edits, and in any case time until such an edit gets reviewed is much larger. And they can be used as stepping stones for attacking large wikis.
There will be a shorter announcement when the changes actually go into effect, sure. --Tgr (talk) 09:49, 10 July 2018 (UTC)

editcontentmodel right[edit]

Thank you very much for this proposal! I have not carefully checked but the editcontentmodel right should maybe be restricted to this new group instead of sysops because if not it may possible to someone with the editinterface and editcontentmodel rights to just change the content model of Mediawiki:common.js to wikitext, do some edits and move it back to javascript. Tpt (talk) 12:23, 9 July 2018 (UTC)

If I remember correctly, if a person can’t edit the pages with a content model, they can’t do any actions to it. stjn[ru] 12:47, 9 July 2018 (UTC)
You do remember correctly. Also, just to be on the safe side, editsitejs is required for MediaWiki: pages with a JS content model regardless of extension, and MediaWiki: pages with a .js extension regardless of content model. --Tgr (talk) 21:07, 9 July 2018 (UTC)

Didn't want to create a new section for one question, so I'm asking here. Pardon if it's obvious to you, but will techadmins be able to delete pages in MediaWiki namespace? They won't have the delete right, right? tufor (talk) 15:59, 9 July 2018 (UTC)

No (at least not in the current configuration), they have to be normal sysops as well to do that. —Tacsipacsi (talk) 16:20, 9 July 2018 (UTC)
Yeah, the assumption is that most techadmins are normal admins as well, and when they are not, not having any other admin powers like deletion is a good thing. --Tgr (talk) 21:07, 9 July 2018 (UTC)
[edit conflct] Well, shouldn't they be allowed? I mean, deleting a page from MediaWiki namespace doesn't happen that often, but I think techadmins should be able to do that, since from then on, it will be only them who can edit these pages so why not delete them as well? Also, after the changes, if an admin account gets compromised, it can still make a huge mess by deleting a js script in MediaWiki namespace (will the same admin be able to restore it later?). I know it causes even more technical problems, because then techadmins should also have a right to restore them, so also browse deleted history in MediaWiki namespace, etc. but as we think of improving overall security and lowering any risks, then, in my humble opinion, it's one of the details that should be at least analysed. And yes, I know, most techadmins will also have admin rights, but just some food for thought. And one more question, to make sure: current administrators will retain the (new, curbed) editinterface right, right? Meaning they won't be able to edit .css nor .js scripts but will be able to edit pages like MediaWiki:Sidebar? tufor (talk) 21:13, 9 July 2018 (UTC)
@Tufor: Deleting some JS file is a very small mess compared to the things we are talking about here. In any case, the software does not let you delete things you can't edit. Same is true for move and almost every other action. So you'd have to be both admin and techadmin to delete/restore JS pages.
The advantage is that it makes it easier to grant techadmin without admin (maybe some wiki does not want all of its JS editors to see all deleted content). That said, if some community wants to grant delete rights to techadmins locally, there is no reason they shouldn't. If it turns out that most communities want that, we can make that the default.
editinterface won't be removed from any group that currently has it; it just won't allow editing CSS/JS pages anymore. --Tgr (talk) 08:17, 10 July 2018 (UTC)
Assume case: a small wiki decided than no current admin has techadmin skills, and decided to grant techadmin right to some noadmin users. What then? Who should move / delete .js pages if necessary? Ankry (talk) 17:38, 23 July 2018 (UTC)
The local sysops, just like any other time when a non-admin needs to have a page deleted. Or stewards/global sysops if there are no local admins. – Ajraddatz (talk) 19:18, 23 July 2018 (UTC)
@Ajraddatz: perhaps I'm missing something here, but that doesn't stand in line with what Tgr said: In any case, the software does not let you delete things you can't edit. If admins can't edit a .js page in MediaWiki namespace, then they cannot delete it, so it's not "just like any other time when a non-admin needs to have a page deleted". tufor (talk) 19:30, 23 July 2018 (UTC)
I didn't realize that, thanks for pointing it out. In that case my answer is the same: we use the existing processes for people who are able to delete the page. Local admins with the interface admin rights, or stewards if not. – Ajraddatz (talk) 19:33, 23 July 2018 (UTC)

Is this going to cause havoc during renames if the renamer is not a local interface editor, as the user css/js subpages will get left behind? — xaosflux Talk 19:47, 5 August 2018 (UTC)

Now THAT is a question! I believe it's answered at #Page_moves as "yes." ~ Amory (utc) 19:50, 5 August 2018 (UTC)

Separate secure account as an alternative[edit]

As an alternative, I think we can discuss moving sensitive rights to separate secure accounts. If getting sensitive rights like JS/CSS editing will go with additional constraints like 2FA, is it possible to generalise an option to have these rights only on a separate account? This can also go with other sensitive rights like CU and OS.

The issue is: the more constraints we have, the less people be willing to accept them. For example, I might want to connect to Wikimedia sites while using my tablet on holiday and block a vandal if I spot one. However, with 2FA I might not be able to do this if I don't have my authentification device with me. However, I would hardly ever edit a CSS or a JS like that, and I might wait till I come back to my device to connect into my secure account and make that CSS or JS edit.

I recall we had a CU who opted for such setup and had some issues with their accounts. If more users will be subject to additional requirements perhaps we can generalise such practice? — NickK (talk) 12:50, 9 July 2018 (UTC)

It can be an option but I can't support that as a default. MediaWiki's log out and log in seriously s**ks (log out automatically triggers logout on all device) and having to log in on 5 devices (I have two smartphones, one tablet, two laptops) every time is a PITA. — regards, Revi 13:07, 9 July 2018 (UTC)
Stock MediaWiki actually doesn't behave that way, it only logs you out of the current browser/device while leaving others intact. CentralAuth is what gives that behavior, since it has no way to clear the necessary cookies on every site. There are ways around that (discussed in task T51890), but they'd need development work.

You can work around it by using a different browser for the second account (e.g. Firefox for normal editing and Chrome for the advanced account), or you could log in to the second account in a private browsing session where its cookies won't interfere with your main account cookies. It might even work to just visit Special:UserLogin to switch accounts without ever using Special:UserLogout (I haven't tried that one). Anomie (talk) 14:06, 9 July 2018 (UTC)

Well yeah, I can have my third browser (Safari for revi, Chrome for Revi (WMF), and then something new for that advanced separate?) but that's waste of my storage, and that "private session" purges every time I restart. (And I also agree this is bit offtopic) — regards, Revi 14:35, 9 July 2018 (UTC)
Ctrl+Shift+N--Tucvbif (talk) 18:54, 20 July 2018 (UTC)
To me that sounds out of scope for this discussion. Besides the inconveniences -revi mentioned, it should be simple enough from a technical standpoint and come down to whether the community will allow it. What were the issues that CU encountered? Anomie (talk) 14:06, 9 July 2018 (UTC)
I think phab:T153454 would be a better idea here and in many other places as well; same account - but allow for different grants as needed. — xaosflux Talk 15:49, 9 July 2018 (UTC)
All of this sounds like an absolutely miserable experience for the user, at least if it was required. Nor do I see how much of this would make my advanced access any more secure - if I held my steward rights on a separate account (User:Ajr Stew), would an attacker not just try to compromise that account instead? phab:T153454 looks like it would require me to enter my password every time I took an advanced action, which would be horrible from a workflow and time efficiency perspective. – Ajraddatz (talk) 17:23, 9 July 2018 (UTC)
I don't want to suggest anything like that. My idea is that at the moment we force 2FA for a group of users there should be some sort of choice between setting 2FA on the main account or creating a separate "secure" account and moving rights there. Of course this setup would be unrealistic for stewards given the amount and frequency of actions but can be a reasonable alternative for CSS/JS editing (low-volume and not really frequent) — NickK (talk) 23:21, 9 July 2018 (UTC)
Makes sense (thanks for clarifying), but I worry that this will still affect stewards since we'll have these rights in our global group. I'm still not a fan of mandatory 2FA for this group, or for that matter any group. – Ajraddatz (talk) 03:07, 10 July 2018 (UTC)
I am not a fan of mandatory 2FA either but I am afraid it will become mandatory at some point. My problem is that I will probably not take a flag if it makes me use 2FA, but using a separate account with 2FA for it will make it even more secure (it's harder to hack it if I am normally logged into it) — NickK (talk) 11:06, 10 July 2018 (UTC)

An IMO more user-friendly option is login security levels: you can login into "secure mode" (e.g. by entering a second factor) which gives you access to sensitive permissions for a limited time, then your session reverts to normal mode. This is supported somewhat by MediaWiki (you can visit Special:ChangeEmail to see it working), but needs further development work to be useful. --Tgr (talk) 08:57, 12 July 2018 (UTC)

Yes, that would be a good option. I would consider "limited time" as something that can be chosen by the user: it might be a year for a steward on their home computer (as they will use these permissions almost all the time), but just a few hours for a person editing sensitive JS/CSS — NickK (talk) 09:28, 12 July 2018 (UTC)
@NickK: That would largely defeat the point, I think. The goal is to ensure that users are in non-secure mode most of the time, so that an attacker is forced to attack in a specific time window, making their job much harder. There might be other ways to support home computers (e.g. making secure logins last longer but binding them to IP) but that needs more thought and more work. --Tgr (talk) 09:40, 12 July 2018 (UTC)
@Tgr: Please look at Ajraddatz's comment above: as a steward he uses "secure mode" permissions almost each time he logs in to wikis, and having him confirm at each action that he really wants to do this secure action would create an extreme burden. Of course steward accounts are way more vulnerable but I am not sure stewards will like this additional login for each action. It would still be a good idea to make long-lasting secure logins device-specific — NickK (talk) 12:07, 12 July 2018 (UTC)
Oh, and I just realised that granting these rights will be way more sensitive. Attacking a bureaucrat will allow you to grant these rights to yourself — NickK (talk) 14:42, 12 July 2018 (UTC)


Will 2FA be required to be part of this group? Should 2FA be required to be part of this group? I tend to believe so... Strainu (talk) 08:01, 10 July 2018 (UTC)

@Strainu: At some point, it probably will. AIUI there are UX issues to work out first. --Tgr (talk) 08:20, 10 July 2018 (UTC)
@Strainu: As far as I know, it is not possible to make 2FA a requirement for a group yet, this is phab:T150562. —TheDJ (talkcontribs) 08:08, 11 July 2018 (UTC)
Most people can't use 2FA, so I very much hope not. --Yair rand (talk) 03:05, 12 July 2018 (UTC)
Bureaucrats will also need to use 2FA if they have the ability to grant the group membership to users. -- WOSlinker (talk) 19:16, 13 July 2018 (UTC)

Hopefully this would never be a requirement. It is a sure way to guarantee yourself to be locked out of the account at least in some situations (e.g. when you lose a phone). I would rather attempt to remember sha256 private key by heart than use 2FA. --Base (talk) 20:49, 27 July 2018 (UTC)

Bureaucrat revoke techadmin[edit]

It seems that the current patch does not contain revoke techadmin right. In the future, is it allowed for local bureaucrats to revoke techadmin by modifying the site configuration? -- 星耀晨曦 (talk) 23:32, 11 July 2018 (UTC)

full support --Cohaf (talk) 06:47, 12 July 2018 (UTC)

@星耀晨曦: the MediaWiki core patch does not contain that because in default MediaWiki bureaucrats are "superusers" (like stewards in Wikimedia wikis) who can automatically grant or revoke anything. There is a Wikimedia config patch which just copies the situation for admins (that is, allows bureaucrats to revoke techadmin on the same wikis where they can revoke admin). --Tgr (talk) 06:55, 12 July 2018 (UTC)

To be clear, with reference to the patch, is it possible to be as follows for line 11630 if there is a community consensus.
'+zhwiki' => [
'bureaucrat' => [ 'flood', 'techadmin'],
'sysop' => [ 'patroller', 'rollbacker', 'autoreviewer', 'confirmed', 'flood', 'massmessage-sender', 'filemover' ], // T130814 and T195247
--J.Wong 09:39, 12 July 2018 (UTC)

@Wong128hk: sure, details of how to manage the permission are up to the local community. --Tgr (talk) 10:09, 12 July 2018 (UTC)

  • Having Bureaucrats remove techadmin rights is not a good idea! Neither is leaving such to the local community! Security matters are best left to those with much experience with .css or .js. Mistakes happen while learning. A bureaucrat may punish where an expert helps undo and educates. I believe you may need to have a group of experienced techadmins to advise where needed. They may need objective steward intervention rather than dependence on local oversight. --Marshallsumter (talk) 05:26, 17 July 2018 (UTC)
    • What if the community is large enough to have more than few bureacrats. I don't think it would be a problem if there are already ten bureaucrats and an active enough community for check and balance. I don't think stewards can make a better judgement if there is a language barrier. --J.Wong 06:36, 18 July 2018 (UTC)
    • @Marshallsumter: Stewards are not necessarily JS experts any more than bureaucrats are. Presumably they consult the community or the other techadmins before removing the permission. I don't see why that would be worse for security-related permissions than for any other one. --Tgr (talk) 10:42, 18 July 2018 (UTC)
Support: Should be revocable by crats. Lesser workload for stewards and easier-to-read logs. --MBq (talk) 06:50, 31 July 2018 (UTC)
I also support this, especially in the light of the lack of ability (for now, at least) to give temporary membership to the group.
— Luchesar • T/C 07:54, 31 July 2018 (UTC)

Semantics and scope of the problem statement[edit]


1) In my opinion "Most administrators do not actually want or need the ability to edit CSS and JavaScript. In the first place, that requires the knowledge of those languages, which most admins lack." is not really correct. At Russian Wikipedia more than a half of the administrators whom I approached about Lua or CSS or JavaScript were able to competently handle it. Perhaps there is a different situation at another wiki? Perhaps this phrasing needs to be changed, to "At some wikis, most administrators do not actually want or need the ability to edit CSS and JavaScript. In the first place, that requires the knowledge of those languages, which at some wikis most admins lack."?

2) "so that an attacker stealing their account can do no harm" Is this a frequent occurrence?

3) "Also, communities who want to vet JS editors at a higher level or scrutiny than admins (which is generally a wise thing to do) should be supported by the wiki software." agreed, but in the case a community does not want that, what is their option? Can the "editsitecss" and "editsitejs" rights remain assigned to the sysop user group in the cases of wikis which prefer this option? I believe this is equivalent to the current situation, and perhaps the best option in some wikis.

--Gryllida 01:51, 12 July 2018 (UTC)

@Gryllida: looking at the 85 ruwiki admins, 35 have never edited CSS or JS and 25 have edited it less than 10 times throughout their adminship so I doubt giving the right to all admins would be wise. In any case, it will not possible to assign editsitecss/editsitejs to other user groups (for unrelated technical reasons - it makes incident monitoring easier). --Tgr (talk) 07:50, 12 July 2018 (UTC)

@Tgr: Truthfully, your reasoning does not make sense to me. Admins are supposed to be trustworthy persons who would have the good judgement not to tinker injudiciously with something they don't know about. Therefore, the fact that any given admin has not been editing js or css files cannot possibly be in any way evidence that they should not be able to; on the contrary, it is at least as likely to be evidence that they are indeed worthy of trust. --Pi zero (talk) 22:53, 16 July 2018 (UTC)
You seem to be missing the point, Pi zero. It isn't about whether we can trust an admin to know their limits by not editing css/js or whether an admin who doesn't edit css/js has the skills but not the desire to do so. It's about making it so that there are only 25 targets (rather than 85) for an attacker seeking to compromise an admin account as a vehicle to adding malicious sitewide css/js, and to recommend and later perhaps to require that those 25 techadmins take further hardening measures with their accounts without inconveniencing the other 60. Anomie (talk) 13:17, 17 July 2018 (UTC)
@Anomie: I was addressing another point that is also part of this. That said, the point you are making is also part of this, and as Gryllida has mentioned above, your point seems open to doubt. Bottom line, you are saying, in a different way, that you don't trust admins, without providing grounds for that position, That is not altogether separate from the point I was just making, either: the evidence cited by Tgr, above, fails to provide any evidence of the problem you're trying to use to justify your position. The appearance is of trying to justify something that would cause problems by citing a supposed problem that does not, in fact, exist. The supposed problem cannot be weighed against the problems that would be introduced by the proposed change until-and-unless evidence of the problem is presented, by which to guess how much it weighs. Gryllida did ask for evidence. --Pi zero (talk) 14:51, 17 July 2018 (UTC)
If you won't trust Wikimedia developers who deal with security issues to accurately assess when a security issue exists and insist on putting words into people's mouths, it seems likely there's no convincing you. Anomie (talk) 21:39, 17 July 2018 (UTC)
About 2014 or later someone hacked Myspace and apparently made off with perhaps a million password accounts including mine. Last year someone tried twice to hack Wikipedia using my expired password and failed both times. I use strong passwords and am a custodian on Wikiversity and have and would like to continue to have techadmin rights. It's not a matter of trust but reducing hacker access and potential success. --Marshallsumter (talk) 00:30, 18 July 2018 (UTC)
@Marshallsumter: Although it sounds plausible that reducing the attack surface would increase security, an eminently reasonable question raised by Gryllida is how often there have actually been breaches of admin accounts, and one might wisely extend that question to ask what proportion of breaches to admin accounts were accounts that would have had techadmin privs anyway; and of course how all of it correlates with project size. This change would clearly not be without drawbacks, and those drawbacks could change behaviors in ways that would increase security risk. One obvious one that occurs to me: I don't see anything in the proposal that clearly identifies techadmins as a subset of admins. If the techadmin priv gets handed out to users who aren't trusted to be admins, that could create a bigger security risk than allowing all admins to edit js/css.

@Anomie: I was saying that distrust of admins is inherent in your position. If that was unclear, I apologize, and will try to factor the incident into my future articulations. --Pi zero (talk) 15:26, 19 July 2018 (UTC)

Pi zero has raised an interesting concern about previous hacks or attempted hacks. I have and use a Target credit card. Several years ago, Target was hacked and perhaps a million accounts were stolen including then active passwords, once again including mine. Worse, according to press releases apparently three mid-level Target managers at corporate HQ provided the hackers with key information. To my knowledge, it's only happened that once at Target. My password was stolen but was only used with Target and their security and quick response prevented damage. --Marshallsumter (talk) 21:04, 19 July 2018 (UTC)
These stories about huge databases of passwords being stolen are certainly evidence (as any were needed) that security is a concern. However, they appear to offer no evidence in support of the proposal for a separate techadmin group. If a massive collection of passwords were compromised, the separate groups seems at best a feeble mitigation. Reducing the number of accounts with CSS/JS could have greater or lesser effect on risk of compromise due to attacks on individual accounts, and the effect would depend greatly on factors some of which I've mentioned above. Without statistics on compromise of individual accounts, there's still no evidence that the proposal would be meaningfully helpful (and, as noted, statistics in order to be meaningful in this case would need to take various related factors into account). --Pi zero (talk) 00:54, 21 July 2018 (UTC)

Questions and comments from Incubator[edit]

  • Question Questions:
  1. I just want to make sure I understand something here. Is the following correct? All files named MediaWiki:xxx.js or MediaWiki:xxx.css, as well as all files named User:xxx.js and User:xxx.css are included in this change. The same is true of all pages in those two namespaces that have content models of JS or CSS, regardless of name. The only exception is that people can edit their own .js and .css pages.
  2. Are there other pages that are included?
  • Comment Comments:
  1. I personally don't think that repurposing the interface editor group (or eliminating it) is appropriate. There are still edits within the MediaWiki namespace that may need to be made other than .js and .css changes.
  2. I think 2FA must be required for this group.
  3. The question about whether (in general) 'crats ought to be able to grant this right is a good one. I'm pretty agnostic about that, except that I think at minimum 'crats ought to be able to grant this right (and remove it) on their own accounts, and maybe on the accounts of sysops. The reason I say this is that some changes to such files are actually pretty trivial—removal of old code, spelling, what have you. In communities that are big enough (or old enough) to have 'crats, but small enough that there may be few if any tech-admins available, it would be better if people didn't have to run to stewards for such changes all the time.
    • Personally, I'd probably want to briefly and temporarily give myself this flag if I needed to use it, but not have it on my account all the time.
  4. Incubator has some unique features that are going to require some additional thought and discussion among ourselves. Effectively, Incubator is a cluster of (usually) very small communities, with the 'crats (and to some extent sysops) effectively acting in the role of steward within the cluster.
    • We frequently have people who copy in .js and .css pages from other projects expressly for the purpose of allowing them to run only within a single test (by using prefixes). That's how our tests can quickly build up their infrastructure. My experience is that only people who know what they're doing actually undertake this. And this is complicated by the fact that some of these files are annotated in (human) languages that 'crats and sysops on Incubator don't speak. Have we ever had any trouble coming out of Incubator on this? It's difficult enough on test communities not to have access to Wikidata on Incubator; I don't want to make life that much harder. To that end ...
    • Is there a way, perhaps within Extension:Incubator, to exempt prefixed MediaWiki pages from being included?
  5. There are two groups that need to have this privilege set automatically on a global basis: (1) "Pathoschild's global group" (so that he can run Synchbot on such pages) and (2) "New wikis importer" (MF-Warburg and SPQRobin) (so that they can import such pages into new wikis).
  6. People should think about how to handle any future situations where major revisions in the infrastructure will result in wholesale changes to gadgets and other .js and .css files. (I'm thinking about the somewhat recent migration to ResourceLoader as an example.) In such situations, if the number of tech-admins is quite limited, we may run into problems in executing changes.
  7. I like the name "technical administrator" (or tech-admin or techadmin), myself.

StevenJ81 (talk) 15:29, 12 July 2018 (UTC)

@StevenJ81: Thanks for the insightful comments!

  • Your understanding is correct; no other pages are involved. In the future, it's possible other pages that are related to CSS/JS will be covered; for example, it would be logical to extend the protection to MediaWiki:Gadgets-definition which is also a way to deploy CSS/JS sitewide. --Tgr (talk) 11:19, 14 July 2018 (UTC)
  • Bureaucrats can grant sysop rights, so only allowing the new rights to be granted to sysops is not a meaningful limitation (plus MediaWiki does not currently support restrictions like that). Making rights changes slow (e.g. only take effect after a day) and advertising them somehow would be one possible way to limit abuse; it would be non-trivial to implement, though. Support for temporarily enabling the right (as opposed to temporarily granting it) is probably less confusing and easier to implement - see the discussion towards the end of #Separate secure account as an alternative.
  • Exempting pages based on prefix is technically possible. Wouldn't those pages end up being served to users as CSS/JS, though? In that case it would defeat the purpose.

--Tgr (talk) 11:19, 14 July 2018 (UTC)

@Tgr: Thank you for your response!
  • I'm inclined to think that making these rights available only temporarily (to anyone except system developers) might make a lot of sense.
  • With respect to prefixed pages: You're right, of course, but there's a tradeoff involved. As I understand it, CSS/JS on prefixed MediaWiki pages are only served when pages in that test are served. The vast majority of people in Incubator, working on other tests, would never be affected at all.
Understand that at Incubator, we're in the business of developing new projects from scratch, and one of the things that has to happen is for the proper infrastructure to be put in place. The current approach is generally that someone copies in a .JS/.CSS page from another project, places it in mainspace, and then asks me (as someone with (editinterface)) to move it into MediaWiki space. I usually ask them to run it for a few days from their own personal .js/.css files to make sure it seems to work, before then moving it. But I have no more expertise than that to really review the code myself.
I think that @MF-Warburg and @SPQRobin must check these files before they import them into a new wiki. If so, that's probably the main time they are checked for problems. If either/both of them are willing to check these files (as "tech-admins") on a prompt basis (even if I have to ping them), I'd be fine with that. If someone around Meta who is an expert on this is willing to be on call for me at Incubator to check such files, I'd also be OK with that. Otherwise, I will tell you that the more tech-savvy people who start new tests on Incubator tend to deploy these things quickly, and will get frustrated if we can't move them along. And I don't want that to happen. StevenJ81 (talk) 13:41, 16 July 2018 (UTC)
  • I still think that if 'crats don't end up with the right to grant this package to other people in general (even sysops), they should still be able to grant and remove this package (or temporarily grant this package) to/from themselves. As I said, many such edits are trivial, and people who have already reached the trust level of a 'crat probably shouldn't have to go bother a steward or global tech-admin every time any little thing needs fixing. But that's just my opinion. StevenJ81 (talk) 13:46, 16 July 2018 (UTC)

@StevenJ81: I'm not familiar with Incubator's setup, but the main concern with small wikis is that the attacker can easily trick a steward / enwiki techadmin / etc into visiting it, and use local Javascript to take over the visiting account and elevate the attack into other wikis. So the fact that few people visit it normally is not much help. --Tgr (talk) 15:07, 16 July 2018 (UTC)

@Tgr: I see your point. Per en:WP:BEANS, I'm going to send you a question by email. StevenJ81 (talk) 15:19, 16 July 2018 (UTC)

Making assigning of techadmin membership central by default?[edit]

Like many other commenters here, I've been on the fence about bureaucrats on small wikis being able to assign techadmin membership. That makes stealing a bureaucrat account just as bad as stealing a techadmin account; and while people can opt out of being a techadmin if they don't plan to do any CSS/JS editing, there is no way to opt out of being a bureaucrat if one does not plan to do any administration of CSS/JS editors. I wonder what people think of the following?

  • bureaucrats get the right to grant techadmin for the migration period, to make the change smoother
  • after that, they won't have that right, but that can be changed on a per-wiki basis in the usual way (by filing a configuration change request on Phabricator)

That way, small wikis where granting techadmin rights happen rarely can rely on stewards, while large wikis (or small ones if they feel strongly about it) who have the resources to set up their own selection process and to monitor rights changes and quickly detect abuse can manage the full process locally. --Tgr (talk) 12:57, 14 July 2018 (UTC)

On Wikiversity we currently have four bureaucrats, two of which only visit during December to February and apparently have no experience adding code to MediaWiki:Common.css. So far only four active custodians (two are bureaucrats) have added or shown interest in MediaWiki:Common.css, but the rest of the community seems apathetic so far although it's early. Consensus may not occur. Having only the four continue with techadmin rights seems likely and would greatly reduce security risks (from 15 to 4). Renewal of techadmin rights or granting of techadmin rights say to interested editors may be better solved by Phabricator request or stewards. What do you think? --Marshallsumter (talk) 16:25, 14 July 2018 (UTC)
@Tgr: This is something that has just been raised on es.wikivoyages. Their own bureaucrats feel that this permission could better be managed centrally here at Meta, for security; without prejudice that bureaucrats on the biggest wikis can get it back if the community supports such a change and there's an active community we can presume will take a look at who gets promoted/demoted and what kind of changes they do. As such I support your idea. —MarcoAurelio (talk) 09:44, 17 July 2018 (UTC)
Considering the number of Wikimedia sites and the natural need to edit the site's JS/CSS, do you imagine the scale of bureaucracy that will arise with the need to control granting/revoking rights at all these wikis? es.wikivoyages is at least Spanish edition, they know how to contact stewards, they probably know English well. Looks like the techadmin initiative has gone far beyond its original purpose. That purpose wasn't to hamper the sites' ability to control their JS/CSS, and that's stated on the project's page ("Wikimedia communities' ability to shape the workings of their sites is extremely valuable and should be preserved"). And by complicating things with granting/revoking rights you are doing exactly this. Maybe big projects can say one time that they want bureaucrats to control this, but that's not about them.
Also, what would happen if on some small project, a techadmin who was considered trusted turns out to be a malicious user? If the bureacrats have the ability to revoke the right, this would end quickly with the removal of the right. If they don't, the site could stay defaced until the incident gets the stewards' attention. So, the original purpose of tech admins gets not just too far, it gets inverted. Tech admin can't be on one step of the hierarchy with the bureaucrats, as 1) usually the sites are glad to have local technicians who edit JS/CSS (those can be invited to do this task pretty carelessly despite the concept of the level of trust that may be "even higher" than the admins'), but rarely their trust gets close to the bureaucrats', 2) there would normally be more tech admins than bureaucrats. The idea not to give the bureaucrats the right by default would create a poorly controlled level of authority which could easily get out of hand. Jack who built the house (talk) 13:35, 22 July 2018 (UTC)
@Jack who built the house: those are good points. I'm putting this aside for now, might think about a different approach (e.g. opt-in instead of opt-out, and only for granting) later. --Tgr (talk) 20:25, 23 July 2018 (UTC)
Ramble-y comment: From a workflow perspective, stewards can handle the assignment and removal of these permissions without issue. I do like the idea of local bureaucrats being able to add and remove the permissions if decided by the community. The level of trust required for this position seems to be best established at slightly higher than admin, but less than CU/OS, since there is no direct access to non-public info. If these permissions are going to be assigned by stewards by default, it might make sense to have a global policy for this group that can then be modified at the local level as with CU/OS. In this case, we could also allow local communities to make the policy more liberal, in contrast with CU/OS where they can only make it more conservative. – Ajraddatz (talk) 16:10, 18 July 2018 (UTC)
@Tgr: sounds messy - and may create a local community "land rush" of people going to the local crats during the early period to request access without having to deal with the centralized system (and people who don't actually need this access going for it "just in case")- also means community policies need to be built out differently. To avoid mess a decision should be made as soon as possible, and I think these should either be handled the same way as +sysop (local crats deal with in the same manner, stewards deal if no 'crats) or as other local permissions handled by stewards such as +importers ; wherein we need a central policy as Ajraddatz said as to what the requirements should be. — xaosflux Talk 14:36, 19 July 2018 (UTC)
@Xaosflux: technical administrators was my attempt at a global guideline; what else would be needed for a policy? I see your point on the land rush; on the whole it still seems preferable to me to making all bureaucrats into targets. --Tgr (talk) 06:34, 20 July 2018 (UTC)
@Tgr: That page is a good start as far as a description, but it doesn't really speak to tings like granting requirements. If this is going to be a steward only function, communities need to know what they will require (just a "consensus discussion" or something more?); if communities can manage the access need to build their own community-specific policies. Are you still open to letting communities opt-in to self govern this? — xaosflux Talk 11:41, 20 July 2018 (UTC)
Let me remind what I've said elsewhere: Even if this is generally done centrally, I'd like default to be that 'crats can assign and remove to themselves. StevenJ81 (talk) 17:25, 20 July 2018 (UTC)
I would argue against this. If a project can’t trust bureaucrats with this, then why should they be trusted with anything else? In the last years bureaucrats already only lost their local rights, so it doesn’t make sense to overcomplicate things more and put more trust in stewards with which, frankly, no one in local projects, especially non-English ones, has any connection with (stewards, don’t hate me for this, you’re probably cool). Checkusers and oversighters, IIRC, sign the papers to acquire rights, so they are in different category since they are bound by WMF. stjn[ru] 17:36, 20 July 2018 (UTC)
I'm sorry? Not granting bureaucrats (top-trusted site users) the right to govern access to the site scripts/styles (which is a pretty basic need) by default? That's weird. Jack who built the house (talk) 12:33, 22 July 2018 (UTC)

Activity requirement[edit]

Should we have an activity requirement of techadmins? Users with zero edits in some time (probably 6 or 12 months) should be deflagged.--GZWDer (talk) 20:26, 14 July 2018 (UTC)

That will be up to local community on each wiki. Because this is not a global group, so no need of hard and fast rule from here Meta. –Ammarpad (talk) 20:56, 14 July 2018 (UTC)
@GZWDer: I would strongly encourage you to have an activity requirement. You could make it easy to re-obtain membership without a new election, the goal is not to punish people for not being active, but leaving around unused old accounts with powerful privileges is dangerous. People usually don't bother to change their passwords on unused accounts when they somehow become compromised (their phone gets stolen, someone breaks into their email account etc) so they tend to be an easier target for hackers than active accounts. --Tgr (talk) 07:33, 15 July 2018 (UTC)
I'd support AAR to include techadmins. (Well, this is probably a matter of interpretion: should "other advanced right holders" include techadmin?) On the other hand, given the sensitivity of the flag, I'd also support stricter rule for techadmin, like 1 year instead of 2. — regards, Revi 08:23, 15 July 2018 (UTC)
I think we can use 6 months by default and 12 months as maximum (community can choose between 6 and 12 months). In addition, this should apply not only to (local and possibly future global) techadmins, but also to any community user rights that can flag techadmins (including bureaucrats and stewards).--GZWDer (talk) 09:48, 15 July 2018 (UTC)
Depends? From the section above: if communities are allowed to manage this access, they should be allowed to specify their requirements. If it will be centrally managed can the standard for sysop just be used? — xaosflux Talk 14:21, 18 July 2018 (UTC)
Wikis with their own inactivity rules are not bound by AAR. — regards, Revi 09:35, 20 July 2018 (UTC)


We have many paid editors (not paid by WMF) among our custodians. Are these a greater risk than volunteer custodians all other parameters being equal regarding techadmin (security) responsibilities? --Marshallsumter (talk) 14:36, 16 July 2018 (UTC)

@Marshallsumter: not that I can see. --Tgr (talk) 15:13, 16 July 2018 (UTC)
When I worked for the USA Navy, contractors (here outside paid editors) were always considered a high security risk. Their loyalties were to their employers not to the Navy nor necessarily the USA. While what's at risk here is much less damaging, do we need that risk? --Marshallsumter (talk) 05:35, 17 July 2018 (UTC)
@Marshallsumter: Admins are not paid by Wikimedia nor go through army-style training so I don't think it can be assumed as a rule that non-paid admins are more loyal than paid ones. In any case loyalty is a secondary concern: an admin intentionally sabotaging the site is possible but far less likely than a hacker stealing their account and doing so; and that risk is the same for paid and non-paid admins. --Tgr (talk) 11:00, 18 July 2018 (UTC)

This group should have by default editcontentmodel and the possibility to enable 2fa[edit]

I think this group would benefit from having editcontentmodel to manage content model of pages (not only CSS and JS but also JSON and maybe others) and should also have oathauth-enable to allow them to enable 2FA if they want. --Zerabat (discusión) 03:11, 17 July 2018 (UTC)

I'd support that as well. —MarcoAurelio (talk) 09:40, 17 July 2018 (UTC)
@Zerabat: oathauth-enable is already planned. editcontentmodel is doable but there is no way to limit it to JS/CSS-related content models or to the MediaWiki/User namespaces. --Tgr (talk) 10:55, 18 July 2018 (UTC)
That might be worth a Phab ticket. There's no reason everyone above a baseline trust level shouldn't be able to change content model in userspace, for example. E.g., the only way to speedily delete (under en.WP process) my own testing123.css page is to create a talk page for it and put a speedy deletion tag on the talk page and hope the admin understands that I mean to delete the both the css page and its talk page. Even if you move it to User:Foo/testing123, it retains the CSS content model, so the speedy deletion template won't work inside it.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  22:15, 18 July 2018 (UTC)
Are you sure about this? In deWP, you can add the speedily delete template to a css/js page and it will be found by admins. The template is not substituted at the page itself, but the page will – because of the template – categorized as a page to be speedily deleted. Regards --Schniggendiller (talk) 23:07, 18 July 2018 (UTC)
Pages with a javascript content model (I'd guess css too but haven't checked) are parsed as wikitext; the output of that parse is not displayed but used to update link tables (category membership, what links here, interwikis etc). --Tgr (talk) 10:02, 19 July 2018 (UTC)
I'll consider myself corrected then. It's not at all obvious that templates will work, at least as to categorization code in them, in interface pages.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:11, 19 July 2018 (UTC)
@SMcCandlish: I have no problem with it if that's the setting most communities prefer (otherwise, they can always change it for a single wiki). I'm not really sure how to establish that though. Short of that, I'd default to no extra permission because it's easier to add them for some specific wikis than to remove them. --Tgr (talk) 10:02, 19 July 2018 (UTC)
Sure, I can buy that, especially since my "big idea" for why was incorrect. :-)  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:11, 19 July 2018 (UTC)

Should be separate from but not necessarily higher than admin[edit]

I like the idea of separating these, but there are many CSS experts who don't have any interest in adminship. E.g., one should be able to do this work as a long-term template editor, perhaps, and with a proven track record of good CSS work on the wiki, through an approval process that focuses on that, not on what one's speedy deletion or vandal-fighting track record is. It's just conceptually separate from adminship, a matter of very narrow technical competence.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  10:14, 18 July 2018 (UTC)

@SMcCandlish: it is "higher" in the sense that it requires more trust: a techadmin can cause a lot more damage than an admin can. (OTOH a techadmin can only cause serious damage intentionally, and an admin can cause problems by being rash, easy to anger etc. So it requires a somewhat different type of trust, I suppose.) There is no particular reason for techadmins to be regular admins, it's just important that communities understand the high potential for abuse. --Tgr (talk) 10:53, 18 July 2018 (UTC)
I don't agree it requires more community trust, just a high trust in competence at something specific. The potential for abuse is actually lower than for some of the rest of the admin tools. A change made by a CSS or JS tweak is as easy to revert as some other bad idea, but if a rogue admin, say, [see details in previous revision at 22:07, 18 July 2018 UTC; I've redacted them for BEANS reasons so they don't show up in searches, in case anyone's looking for disruptive things to do]. Admins require way more trust – of a notably different quality – than "is this person competent to be making changes to interface pages that could temporarily affect the display of a large number of pages?". Seriously, both template-editor and page-mover, at en.WP anyway, are probably more dangerous than this tech bit, which might better be called interface-editor.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  22:07, 18 July 2018 (UTC)
I disagree. The main concern causing this consultation, it seems to me, is not competence, as you say, but a) non-maliciousness b) security. You could do a lot of damage very quickly with JS access. To use your example about deletion or blocking sprees, an attacker could, say, insert code into MediaWiki:common.js causing all administrator accounts which load it to go on a rapid-fire automated deletion and blocking spree through the API. So while the code was live, any admin who loads a page on that wiki suddenly finds they've deleted and blocked God-knows-how-many articles and users. BethNaught (talk) 22:36, 18 July 2018 (UTC)
Yes. Without any need to get into actual cases, the js editing part of the sysop group is probably the most dangerous because it gives you indirect access to everything - even up to steward level. There is less potential for community-side issues, like a bad block which has lasting social impacts beyond when it is reverted, but there is significantly more risk of a discrete incident causing damage. – Ajraddatz (talk) 22:48, 18 July 2018 (UTC)
Hmm. A) "The main concern ... is not competence, ... but ... non-maliciousness" is contradictory. Non-malicious screwups = incompetence. Not doing non-malicious screwups = competence. B) Security: okay, I can buy that. The fix is to separate the JS permission from the CSS one. If this can't be done technically at the Mediawiki user groups level because it's all the same "Mediawiki:" namespace, it could be done rules-wise, i.e., you are forbidden to touch MediaWiki/common.js if you are not an admin, and this could be technically enforced anyway at the particular wiki, simply by making the main JS pages admin-level protected (or higher).

In the end, I think my concerns are completely orthogonal to those of several if not most other participants here. I want to see site CSS editable by highly competent UX and accessibility people, with the kind of community trust-level vetting we use for template-editor, or perhaps a bit higher – about like editfilter helper, which doesn't require adminship either but is only open to a few non-admins who prove themselves. There's a lot of very careful CSS work I would do, but I've never had much interest in adminship, much less "super-extra-mega-adminship". I'll propose an idea below.
 — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:30, 19 July 2018 (UTC)

A two-userlevel proposal[edit]

The security stuff and the "let's get the work done" aspects of the "Mediawiki:" namespace are, under the current paradigm, at direct cross-purposes. But this appears to be easily resolvable by having two bits, perhaps interface helper and interface manager. Make the former like edifilter helper, template editor, and page mover – something anyone can apply for, with clear criteria and proof of competence (probably a high level of technical-competence scrutiny, as with editfilter helper). Make the latter like editfilter manager, open only to admins, and considered high-risk. Set CSS and other less "dangerous" stuff editable by the former group, but JS only editable by the latter. Win–win scenario.
 — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:34, 19 July 2018 (UTC)

PS: I don't care what they're called. It could be tech helper and tech admin or whatever.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:40, 19 July 2018 (UTC)

This might be something for enwiki to look into, but for most wikis this would be too much of an infrastructure change I think. Most wikis don't even have abusefilter managers, and only one has helpers. – Ajraddatz (talk) 15:25, 19 July 2018 (UTC)
Then they need not use it. "Most wikis don't even have abusefilter managers" proves they don't have to. We still need airplanes and MRI machines even if most people can't operate them.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  00:46, 20 July 2018 (UTC)
That's not how we structure user groups around here though... we create them in response to need with a demonstrated use case, not create a bunch of them and then if communities want to use them they can. Maintaining a small number of user groups makes access management easier and more understandable from a user perspective. Individual projects can add onto them as they want, as is done with groups like 'eliminator' or 'interface-editor' on specific wikis, but those groups are enabled on a per-wiki basis not globally when someone comes up with the idea. Also, I wasn't clear regarding abusefilter-managers - the group doesn't even exist on most wikis. It's not that it just isn't populated. – Ajraddatz (talk) 01:23, 20 July 2018 (UTC)

@SMcCandlish: this is more or less what's going to happen - interface editors (an existing group on many wikis) will be able to edit MediaWiki: pages that are not CSS/JS, and interface admins will be able to edit CSS/JS. (CSS is not treated as less dangerous, partly because it's not entirely impossible to use it in JS-equivalent ways, and partly because with TemplateStyles soon enabled everywhere, there will be a perfectly safe alternative so people should not need to edit sitewide CSS most of the time.) --Tgr (talk) 22:04, 19 July 2018 (UTC)

Your "more or less what's going to happen" scenario bears no resemblance to anything I've suggested, and would actually preclude it. We still need template editor even though in most cases there's no need to restrict template editing. I'm well aware of TemplateStyles, and it will reduce the need to edit the site-wide style, but not eliminate it. I'm not talking about the "most of the time" there's no need to edit sitewide CSS. The times that there are such needs, this should be done by professionals, and they need not be admins. I fear this has basically wandered off into a fantasy land. The answer I'm getting here is similar to "The most trusted people in our society, really, are our priests. Therefore, the priesthood should run the technical and dangerous stuff such as the military, the medical system, the legal system, etc. [Historically we have lots of data on what happens when a society turns over such stuff to religion, though that's not actually the point of the analogy, which is simply the disconnect between trust versus narrow technical competence.] While some priests can also be technically competent, it's the exception not the rule. The proportion of appropriately technically skilled editors among admins is smaller than the proportion of them among the overall editorial population, because adminship is more attractive to people with a policing and judging that technical focus.
 — SMcCandlish ¢ >ʌⱷ҅ʌ<  00:46, 20 July 2018 (UTC)
The situation you described above is the status quo, not the proposal. We are separating CSS/JS editing from the sysop group. Individual communities can decide how this new group is assigned, but the best practice here would be to assign it based on trust, technical competence and need for the permission - not simply give it to admins that ask (with the possibility of grandfathering, perhaps). – Ajraddatz (talk) 01:27, 20 July 2018 (UTC)
Sounds too much enwiki specific solution forced globally. Abusefilter-managers/helper, mover, template-editor, interface-editor are just granted to sysops on almost all wikis except for big wikis (like enwiki), and simply does not exist (see for v:ko:Special:사용자권한목록 as an example) on elsewhere. — regards, Revi 09:46, 20 July 2018 (UTC)

Group name and the word "administrator"[edit]

There are several user groups that use the name "administrator", which is a bit unfortunate. For example, there are "translation administrators" and "central notice administrators" who in fact are no more than "managers". A specific right to manage a certain area of expertise, without advanced powers of deleting pages or blocking users, should in my mind be named managers. So there really should be user group names like "translation managers" or "OAuth managers", and the word "manager" should convey the idea that they are, pardon my French, lower functionaries than administrators or sysops. But alas, well-established group names cannot be changed anymore.

The word "administrator" becomes overused in a way when every single expert becomes an administrator of some sort. However, technical administrators will have powers greater than normal sysops in the future, not lower, so the word "administrator" really is not great as it is said in the document itself. Can someone suggest a replacement to the word "administrator", because now we have a situation where every modified use of the word means someone who really is not an administrator? Or should we make a complete overhaul of the naming system, whereby "technical administrator" would convey the right level of trust and others would become experts or managers? (Sorry for this a bit messy message. I did not have the time to write a more coherent piece.) --Pxos (talk) 11:01, 18 July 2018 (UTC)

@Pxos: we could follow the name used in Russian Wikipedia for their existing group: "engineers" (w:ru:Википедия:Инженеры), created some time ago (this group seems to be like a techadmin plus template editor). But if we follow your suggestion to change the name to another that doesn't resemble the "adminship status", then I suggest everybody to take in account that it should be easily translatable to (at least most of) other languages, without excuses. --Zerabat (discusión) 13:19, 18 July 2018 (UTC)
TechAdmin works reasonably well to designate admins with the additional rights, but if a restricted unbundled right is created at any point, calling them techadmins as well is going to get confusing - they will need a separate name. Something engineer based does sound good, I'd have thought that would translate reasonably well Nosebagbear (talk) 21:24, 18 July 2018 (UTC)
I suggested "interface editor", above, to go along with "template editor".  — SMcCandlish ¢ >ʌⱷ҅ʌ<  22:17, 18 July 2018 (UTC)
Interface editor already exists and will probably be needed in the future (for customizing MediaWiki messages). --Tgr (talk) 10:07, 19 July 2018 (UTC)
Ah so! Well, "interface helper" then, to match "editfilter helper" (and distinct, perhaps, from a higher-than-admin "interface manager"; see proposal in sub-thread above).  — SMcCandlish ¢ >ʌⱷ҅ʌ<  14:37, 19 July 2018 (UTC)

@Pxos: that's a reasonable suggestion but I'd rather not take it on as part of the current change, which is already complex enough. As you say yourself, the name "administrator" fits in this case: the permission is extremely powerful (at least when intentionally abused). --Tgr (talk) 22:09, 19 July 2018 (UTC)

MW devs should ask the community what it wants, not tell them what they must accept[edit]

It feels too late already. I'm not being heard here, willfully, about alternative and more flexible approaches. I suspect it's because too much of this [singular, and mega-admin-only] user group idea has already been decided, without community consultation, instead of doing the consultation first.

The proper approach to such matters isn't to say "JS editing is a risk, here is the [i.e., only] solution, and maybe some minor tweaks are okay, but let's rush this to a vote soon." That's pretty much what's happening here.

The useful process is "JS editing is a risk; what are people's thoughts on what to do about it, hopefully without negatively affecting other things." You get better results, in virtually any endeavor, by taking this latter approach.

This will negatively affect other things, because it's too simplistic. I actually had a plan for a competency-based unbundling proposal to create a trusted, adminship-not-required but very selective, css editor user group, after TemplateStyles settles in. I've proposed above how to work that into this proposal, but people are pooh-poohing and straw-manning it. The current "one new super-user level" proposal confuses trust in admins as good people who won't abuse tools to attack other people or tear up the system, with whether they're technically competent at something very narrow and easily broken. The people who have that particular competency are mostly outside the admin corps and many can be trusted with the CSS work and its risks (even if the JS work genuinely does require a higher-than-admin trust level). That is, it's more likely that a CSS expert will be trustable not to do something stupid or malicious with CSS, than it is that an admin trusted to not do something malicious will not do something accidentally stupid, or simply over-controlling, with that code.

We're also in the middle of an adminship crisis and this will make it worse, in two ways, by disincentivizing tech-minded applicants: a) reducing numbers of incoming admins, and b) further concentrating adminship in the hands of authority-and-punishment-minded people rather than get-the-hard-work-done people, who are already badly outnumbered. It'll remove a significant portion of the incentive I and other Web dev pros would ever have for becoming an admin, by not permitting us to do what we're good at, instead reserving access to that code only to someone you want to have vetted at bureaucrat trust level or higher. Various wikis, en.WP included, have already suffered serious problems of near-OWNership of Mediawiki:common.css by single parties or by tagteams. These problems would become an order of magnitude worse under this system, since even other admins would not be able to override them. We do not need "interface emperors".

This rigid and pre-determined tech admin proposal, from a subset of WMF insiders (the MW devs, and even only a small subset of those), as currently formulated, would make a more flexible approach effectively impossible (if not technically, then by poisoning community will to do it). It's another case of the WMF tail wagging the community dog. It's also a very, very "software project management" idea, based on a gate-keeping model rather than a community self-controlling one. There's a confusion happening here, that the only solution to a risk is a root-level firewall. It's ignoring the effectiveness of multiple layers of permissions and behavioral regulations and more localized tech security measures (like higher protection levels for particular pages where the risks are more likely). It's not understanding that an editorial community is willing to accept some (constrained) risks in exchange for the freedom to get the work done without politicized bureaucracy in the way at every step.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  01:33, 20 July 2018 (UTC)

Hey, SMcCandlish, I'm hearing a lot of frustration for you, so I'm going to be blunt. I hope you'll take it as an antidote to the lack of clear communication you're lamenting, rather than any sort of anger at you (I'm not angry at anyone right now :-) ).
On the process:
There is no question of this plan being rushed to a vote soon, because it is not a vote, full stop. The technical implementation of security fixes is never subject to a vote. There might be some ancillary voting – for example, some communities will vote to update their RFA policies or to determine which current admins will get the separate right – but the change to MediaWiki itself is not subject to a vote.
The MediaWiki community (a community in which volunteers significantly outnumber staff, by the way) has been talking about this problem and various potential solutions for ten years. They have been telling devs and other tech-savvy contributors, "JS editing is a risk; what are people's thoughts on what to do about it, hopefully without negatively affecting other things?" for years. I suspect that the existence of this ongoing, multi-year discussion is why this conversation doesn't seem to be a surprise to most of the volunteers who have responded so far. The consultation specifically about this particular implementation has been going on for months through multiple forums, including mailing lists and in-person discussions at hackathons. The fact that editors who don't usually hang out in the technical spaces are only now joining the years-long conversation does not negate the fact that it has been happening all along.
On your css-editor proposal:
Let's take it as read that sysops at enwiki currently have six basic abilities that experienced editors actually care about:
  1. the ability to delete the Main Page
  2. the ability to block the innocent
  3. the ability to protect The Wrong Version
  4. the ability to install malware (edit js)
  5. the ability to make the site unreadable (edit css)
  6. the ability to change all the buttons to sweary words (edit interface)
The proposal here is to separate abilities #4 and #5 into a second group.
Your proposal is to separate ability #5 into a third group (regardless of whether it is in the second group).
From where you sit, the response to your proposal sounds like "pooh-poohing and straw-manning". I can see how you come to this conclusion, because the responses have generally been non-specific but firm disagreement. However, from where I sit, and with the benefit of having read some of those discussions from previous months, the response to your proposal sounds a lot like "Please stop demanding that I post, for the entire world to read, how to use CSS to hack our users. Please, just this once, please just trust me and all of the other devs who are telling you that edit-css is not as harmless as it sounds".
I agree with you that creating a combined js-css editing right might make it difficult to convince editors that an edit-css-only should be created. OTOH, edit-css is not actually a lightweight priv, and the most serious risks are unlikely to be apparent to the mostly non-technical community members who would be voting to hand that ability over to a user, so maybe that's actually a good thing. Indeed, those risks do not seem to be apparent even to some fairly technical people who just don't happen to be experts in MediaWiki as well, nor would those potential harms be limited to just that "editorial community" that you mention in your last sentence.
As for the goal of expanding the number of people who can do this (from among the subset of users that would like to), there's no particular reason to believe that enwiki, which has a long history of electing admins who promise in their RFA votes that they would never engage in ____ process, despite that button being bundled into the sysop right, would be unable to follow the same model for people who request the techadmin right but promise during the "RFJS" process to use it only for CSS pages. If you think you could get edit-css from enwiki, then I think you will be equally likely to get the combined right, with a promise that you won't edit .js files (or at least to not edit them for reasons unrelated to CSS, as changes sometimes have to be coordinated across both).
On trust:
After this (or something like this) is implemented, you will still need to trust your admins not to cause overt problems, which is what most enwiki editors care about at RFA. However, you will also need to trust the JS/CSS editors in many of the same ways. You will need to trust them in the ways previously mentioned (e.g., to use strong passwords), but you will also need to trust them to respect consensus and to not use their tools to 'win' disputes – just like we trust admins to do these things. In short, you will actually need to trust their judgment as well as their technical skills.
I realize that this isn't what you want to hear. However, I hope you will understand that the opposition to your idea is founded on a good-faith effort to reduce some serious risks for everyone. (Ping me if you need anything clarified; I'm not on Meta much.) WhatamIdoing (talk) 18:43, 20 July 2018 (UTC)
The straw man in the situation is that people keep responding with "if you can edit the CSS pages then you can edit the JS pages and PWN everything", and at least twice already I've pointed out that the obvious solution is to protecte the JS pages higher than the CSS pages (higher even than admin – i.e., it's two new user permissions, not just one). The fact that they're in the same namespace does not tie our hands. We have multiple tools at our disposal.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  02:16, 21 July 2018 (UTC)

So it’s July 23[edit]

What now? Should the communities that casted their votes request for the user right at meta, or what?--Épine (talk) 01:27, 23 July 2018 (UTC)

@Épine: see phab:T190015#4433759 for the timeline. --Tgr (talk) 14:49, 23 July 2018 (UTC)

I just want to ask people organizing this change (Tgr and everyone else) to make sure that this time EVERY SINGLE WIKI is notified, because that wasn't the case with the announcement of these consultations. Thanks in advance, tufor (talk) 15:27, 23 July 2018 (UTC)

@Tufor: as far as I know every wiki was notified (apart from private and semi-private wikis). Can you point out the missing ones? --Tgr (talk) 19:03, 23 July 2018 (UTC)
@Tgr: pl.wikinews, pl.wikiquote - projects in my language so I found out this way, but also, for example, tet.wikipedia or sk.wiktionary; probably there are some more. Yeah, I know that these are really small wikis, but still, these changes will affect them as well so they should get the notification. tufor (talk) 19:22, 23 July 2018 (UTC)
@Tufor: it seems message delivery to those wikis failed ([1], [2], [3], [4]). I'll file a bug but since I have no idea what happened I can't guarantee it won't happen again. I don't think there's even a sane way to see those error messages, MassMessage logs are distributed over hundreds of wikis. --Tgr (talk) 19:36, 23 July 2018 (UTC)
@Tgr: I think it's already reported at phab:T139380. Stryn (talk) 19:48, 23 July 2018 (UTC)
Apparently MassMessage failed for 213 wikis :( (The database was readonly for 201, the namespace was invalid for 8, the page was protected for 3, one opted out of MassMessage delivery.) Not much to do about it at this point; at least now I have a script for checking for errors during the next run. --Tgr (talk) 20:23, 29 July 2018 (UTC)

Ugh, 200+ errors again. I'll try to resend. FWIW here are the non-system errors:

  • bad namespace (ie. probably wrong title in Distribution list/Global message delivery
  • bad namespace
  • protected
  • bad namespace
  • bad namespace
  • protected
  • bad namespace
  • bad namespace
  • bad namespace
  • bad namespace
  • bad namespace
  • opted out

--Tgr (talk) 14:47, 30 July 2018 (UTC)

  • protected
  • bad namespace
  • protected
  • protected

--Tgr (talk) 18:27, 30 July 2018 (UTC)

Took three tries, but notified all the wikis (a dozen or so twice, accidentally), except the ones above which intentionally prevented it or are not correctly tracked on the central delivery list. --Tgr (talk) 18:32, 30 July 2018 (UTC)

Next steps[edit]

Thanks all! The consultation has concluded; I have renamed the group to interfaceadmin per the suggestion of Ajraddatz. I think that was the only significant change. The next steps:

  • Send an announcement to all wikis about what's happening on next Monday (so that translators have a weekend to work on it). I won't advertise it to translators before Wednesday, so feedback/fixes on the text is extra welcome until then.
  • At the same time create the new group, and assign granting/revoking permissions to bureaucrats. Communities can start filling up the new group if they have already decided how they do it.
  • Four weeks after that (that is, August 27) send another announcement (to be written) and remove all other user groups' ability to edit CSS/JS. In case someone misses all the announcements, there will be a custom error message when they do try to edit.
  • At some point before that, global-interfaceeditor should be granted the new rights and renamed to global-interfaceadmin (or split, if there is any interest in having non-interfaceadmin interfaceeditors).

--Tgr (talk) 20:39, 23 July 2018 (UTC)

Will bureaucrats keep this permission or will this be temporary? --MGChecker (talk) 20:50, 23 July 2018 (UTC)
@MGChecker: they will keep it. Possibly they'll be invited later to opt out of having it if they want. --Tgr (talk) 21:19, 23 July 2018 (UTC)
I'll start a discussion regarding the global editinterface group. From what I know of the current membership, we should be able to retain the one group, but we can do a more thorough audit of how people are using it beyond my limited memory before making any decisions. – Ajraddatz (talk) 20:57, 23 July 2018 (UTC)
Tgr, I've added the end of that discussion and its conclusion to Tech News' next issue. Trizek (WMF) (talk) 13:34, 26 July 2018 (UTC)
@Tgr: 28th and still no change taken effect. There was no announcements either.--▸ ‎épine talk 08:24, 28 July 2018 (UTC)
{@Épine: Next Monday is the 30th. --Tgr (talk) 09:13, 28 July 2018 (UTC)
@Tgr: when ‘’exactly’’ will the new user group will be ready for use?--▸ ‎épine talk 09:15, 28 July 2018 (UTC)
@Épine: On Monday, between 11:00 and 12:00 UTC (see wikitech:Deployments#deploycal-item-20180730T1100). More exact time will be known only after it has been deployed. —Tacsipacsi (talk) 11:28, 28 July 2018 (UTC)

The first two bullet points are done now. Please ping me if anything is not working as expected. (@Trizek (WMF): thanks for the Tech News mention!) --Tgr (talk) 13:28, 30 July 2018 (UTC)

Distribution will happen soon. Trizek (WMF) (talk) 14:01, 30 July 2018 (UTC)
@Tgr: On Incubator, a couple of things not working as expected:
  • Per our community discussion, our intention was that only the group Interface administrator (and 'crats, if I'm understanding correctly; see below) would have the rights editsitecss, editsitejs, and editsitejson. The group Translator would retain its current single right of editinterface. (I don't recall if they had 2FA before, or if that just got added with these new rights creations. OK either way on that.)
  • In incubator:Special:ListGroupRights, 'crats rights to assign Interface administrator were added. However, if 'crats are also going to have the rights themselves, those rights were not added to the 'crats section. (This second seems to be true elsewhere, too.)
Question Question: Are these rights actually already in force, or has that not happened yet? (On Incubator and ladwiki, as a 'crat I expected to be able to edit "common.js" and "common.css", and I could. On Meta, where I'm a sysop but not a 'crat, I didn't expect to be able, but at least today I still could. StevenJ81 (talk) 15:31, 30 July 2018 (UTC)
StevenJ81, the admin rights to edit JS/CSS won't be removed until August 27, per "Next steps" above. As for the 'crats retaining the right to edit JS/CSS, I'd say I'm opposed to it—and my impression was that they wouldn't retain it—except in specific projects, where the community wishes so. Technically, if someone breaks into a 'crats account, they could of course grant themselves the right immediately, but this could be used to trigger an alarm one step ahead of the actual damage being done.
— Luchesar • T/C 16:03, 30 July 2018 (UTC)
I see. I misunderstood that above. So as a 'crat I guess I can potentially give myself the right (for 30 minutes or whatever) if I need it, but it wouldn't stay active on my account. Got it now. StevenJ81 (talk) 18:54, 30 July 2018 (UTC)
FYIO: phab:T200698. IKhitron (talk) 15:42, 30 July 2018 (UTC)

As concluded above, the b'crat should be allowed to revoke interface administrator. ("assign granting/revoking permissions to bureaucrats") However, b'crat only get the ability to grant interface administrator. Should it be fixed? --J.Wong 07:40, 6 August 2018 (UTC)

@Tgr: Could you somewhere more visibly state the timeline, e.g.: "On August 27, sysops will lose their right to edit site JavaScript and CSS. In order to retain this right, they must become interface administrators." //Shell 16:29, 8 August 2018 (UTC)
@Skalman: added. --Tgr (talk) 11:19, 9 August 2018 (UTC)
@Tgr: Actually seems that interfaceadmin flag can only be removed by steward. It's nonsense. Should it be fixed please? --.avgas 20:18, 13 August 2018 (UTC)
@.avgas: group add/remove is set up to match sysop (if only stewards can remove sysop on that wiki, only stewards can remove if-admin as well). I will probably change that once I get around to it. --Tgr (talk) 19:03, 14 August 2018 (UTC)

Page moves[edit]

What will happen to page moves? If user is renamed by a global renamer, are their css/js pages moved as well? Stryn (talk) 16:18, 30 July 2018 (UTC)

Yes, as is currently done. 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) – Ajraddatz (talk) 16:36, 30 July 2018 (UTC)

Q: 2FA checkable?[edit]

2FA enhances account security and should be mandatory for interface-admins. Is there a way to check whether a user has enabled it? —MBq (talk) 19:08, 30 July 2018 (UTC)

@MBq: no (and unless highly restricted, it would be contraproductive as it would expose which accounts are most vulnerable). It will probably be made mandatory at the software level at some point, but there are usability concerns currently. --Tgr (talk) 20:04, 30 July 2018 (UTC)


  • CSS can be used to steal edit tokens and
  • CSS-based clickjacking can be used to set up phishing attacks.

How exactly the new, separate, user group will prevent these? For the moment, if a user sees a malicious part of code can alert any (ANY) admin which will revert or change the code. With the new policy probably no one will be able to do these reverts, thus leaving readers unprotected for a long time. Is this really a safer approach??? --Xoristzatziki (talk) 19:11, 30 July 2018 (UTC)

@Xoristzatziki: yes, not letting people edit something is safer than making it easy to revert. (In any case, if the attacker is competent it is not easy; by the time you'd see the change the malicious code is already running, and it could hide the change, disable your ability to edit etc.) Still, allowing admins to delete CSS/JS as a heavy-handed way of removing attacks is something I'd like to add if technically feasible. --Tgr (talk) 21:26, 30 July 2018 (UTC)
@Tgr: The first thing that comes in my mind reading your answer is that either you come or you still work with proprietary software. That said I must inform you that in WMf projects (at least this is my idea until now) the volunteers, before being elected, do not give either their passwords or their computers to any other cowikipedian in order to be checked «if they use strong passwords, if they do not install software of questionable origin if they do have the (non-existant) antivirus that can catch any virus» etc. etc. And, please, «Users who can write CSS/JS code, that they typically have better IT skills in general, and thus better password and system security practices»(!!!) has two consecutive assumptions (1. typically have better ..., 2. thus better password...) that can not be part of any serious conversation or inference and are just for «ostentation». Unless you truly believe those last assumptions, in which case continuation of this conversation is worthless. --Xoristzatziki (talk) 23:41, 2 August 2018 (UTC)
Sorry! But I must agree with User:Xoristzatziki. USA Navy and USAF security have nothing to do with "trust". Everyone monitors everyone else and strives for optimum asset protection. This special group must do likewise. I still cannot believe you want to have local bureaucrats deciding admission, long term or short term, to a security group. --Marshallsumter (talk) 05:51, 4 August 2018 (UTC)

Temporary membership[edit]

According to our 'crats on bgwiki, currently they don't have the ability to grant membership to the new group on a temporary basis. Has this been considered previously? Are there any plans—and is it possible from technical standpoint—to implement it? Considering the associated risks with the new group, the ability to also give temporary membership to it (e.g. for making specific changes to the JS/CSS code) seems much more beneficial than for groups like patrollers and autopatrollers.
— Luchesar • T/C 07:52, 31 July 2018 (UTC)

Disregard that. Apparently it is possible—you just have to check the relevant box to have the duration drop-down displayed. Sorry about the confusion.
— Luchesar • T/C 11:23, 31 July 2018 (UTC)

Interface administrators Icon[edit]

Hello, sorry for this "unimportant side question", but is there any icon for this new group (For example Wikipedia Checkuser Icon.. etc here) --Alaa :)..! 12:19, 3 August 2018 (UTC)

  • any suggestions?--Cohaf (talk) 20:38, 7 August 2018 (UTC)
How will high pixeled view of this look? --Tiven2240 (talk) 14:18, 8 August 2018 (UTC)

Editing CSS and JS pages in the MediaWiki namespace vs. general editing in the MediaWiki namespace[edit]

Something that I've noted on enwiki, apparently this new usergroup not only can edit things like MediaWiki:Common.js but also pages like MediaWiki:Spam-blacklist. I think that this is a little off and would like to recommend to make the new permission so that it can only edit the CSS/JS pages but not all the other interface pages as the two rights have different priorities - CSS/JS needs mainly technical prowess and sound account security practices whereas the latter often need community skills to gauge consensus etc. And on enwiki I've seen that these two requirements do not readily go hand in hand. Jo-Jo Eumerus (talk, contributions) 12:23, 3 August 2018 (UTC)

@Jo-Jo Eumerus: editinterface (the permission for editing the MediaWiki namespace) is implemented a bit weird - technically, it is not a permission, it is a kind of page protection applied to the namespace. So it cannot easily be limited to specific subsets. Fixing that is more work than worth it, IMO. Also, it's not obvious which MediaWiki pages are relevant to dealing with CSS/JS (gadgets involve a bunch of extensionless pages, for example). --Tgr (talk) 13:26, 3 August 2018 (UTC)
@Jo-Jo Eumerus and Tgr: That said, we should probably at least discourage people who didn't previously have a mandate for editing such messages from editing them going forward. StevenJ81 (talk) 13:34, 3 August 2018 (UTC)

Offer the new permission to all current sysops by default[edit]

I've only heard about this through yue.wp and Wikitech-ambassadors after the consultation officially ended.

This proposal involves stripping power from admins of Wikimedia projects. So, whatever the implementation, I strongly urge the permission to be offered to all existing admins with an opt-in period that is open for at least one year.

I also echo concerns above about the scope of this new user group's power:

  • Isn't the existing template-editor permission sufficient for this purpose?
  • How about parts of the MediaWiki namespace that aren't CSS / JS?
  • How about Lua Modules?

--Deryck C. 15:05, 3 August 2018 (UTC)

Just a couple of notes:
  • The Lua code is executed server-side in a well sandboxed environment. JS, on the other hand, is executed on the users' computers. This makes JS so much more viable—and very real—attack vector.
  • Nobody actually bans the administrators from regaining the permissions - as long as there are local bureaucrats, it's up to each community to decide on the exact procedure. Indeed, a community might easily decide to give the right to all current administrators. Now, on the small projects without local 'crats, it may be indeed more complicated to get such permissions - obviously, this will be something decided by the stewards.
    — Luchesar • T/C 16:52, 3 August 2018 (UTC)
And stewards will assign interface-admin in the same manner as the sysop permission on small wikis, so no change there. Also, template-editor is not sufficient - it is both less of a big deal than adminship (defeating the purpose of this), and only exists on one or maybe two wikis out of 836. – Ajraddatz (talk) 17:11, 3 August 2018 (UTC)
  • nope, defeats this proposal in its entirety--Cohaf (talk) 20:37, 7 August 2018 (UTC)

Since March[edit]

One: If you knew already in March about the leaks in the system, why you try to close them five months later in a way that makes us doubt if it works sufficiently? Two: If you want to reduce the number of people with so much possibly destructive power why not leave it to bureaucrats or even stewards rather than all admins, because now it mey be possible that those dangerous rights are going to be in the hands of (whether good or bad) people who never received the trust of the community as a whole?
Greetings and worried salutations from Amsterdam,  Klaas `Z4␟` V:  08:42, 10 August 2018 (UTC)

  • If you read properly, this proposal is exactly to reduce the rights holders, it's not every admin. Don't worry.--Cohaf (talk) 18:17, 10 August 2018 (UTC)

Reducing by giving the rights to only bureaucrats or stewards is not an option? Klaas `Z4␟` V:  06:37, 11 August 2018 (UTC)

  • currently local communities can decide who to give the rights to, and what process, if there is any concerns, a local RFC/VillagePump discussion is the way to go.--Cohaf (talk) 10:29, 11 August 2018 (UTC)

Thanks. A poll is organized, but AFAIK a voting is necessary to make such changes if their is no consensus yet.12:50, 12 August 2018 (UTC)

  • well my wiki did not do a formal vote but a general consensus exercise with some votes for part of policies. We held it at village pump policies as a rfc. Local community can differ from their way of doing things but for our community the policy for this flag will be in place within this week.--Cohaf (talk) 20:14, 12 August 2018 (UTC)

There is going to be a formal vote soon; the only way to get things changed out there. Klaas `Z4␟` V:  21:07, 13 August 2018 (UTC)

What if[edit]

Please be more specific about what will be done if in the future we will want to change something in the common js or css? For the moment it seems that no one is interested in your idea about the group in a small wiki I am an admin. And, as you said, this means no one will be able to make changes in those pages in the future. What will be the steps to do small changes in the future? Do we have to call a steward to do these changes? --Xoristzatziki (talk) 15:15, 11 August 2018 (UTC)

  • @Xoristzatziki:I guess start a discussion in the local village pump / related page, let it run for 7 days for interface admin election/application (or whatsoever you call it). If there are no opposes, I guess stewards can grant the flag on a temp basis. Best,--Cohaf (talk) 16:07, 11 August 2018 (UTC)
Thanks for the ideas (really thanks, although guesses). As I now understand in case something is needed in the future we can make a sort discussion on the needs and we will ask for someone (ex our Bureaucrat) to give temporary access to someone for the changes (or apply them by himself). --Xoristzatziki (talk) 16:39, 11 August 2018 (UTC)
    • @Xoristzatziki:for my home wiki, we had around 20 admins (7 are crats also) who edited css/js/mediawiki spaces. We grandfathered the admins and gave crats the ability to add or revoke the flag. This is after around a month long discussion. For crats to have the ability to grant/revoke, phab ticket must be written well. Now at my homewikiuniversity, we are having discussion to grant 6 users the flag also, 7 days discussion. To devs, I am puzzled why are users up to now still clueless about this entire thing? I am sure the communication can be better between developers and end wiki users. Did the message reach your wiki just recently and have just 3 weeks to digest before it kicked off, if so something in the communication process must change for such a rollout. --Cohaf (talk) 18:45, 11 August 2018 (UTC)