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

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Warning! Please do not post any new comments on this page. This is a discussion archive first created on 01 January 2018, although the comments contained were likely posted before and after this date. See current discussion or the archives index.

Other rigths for the new group[edit]

Tgr: Thank you for pushing this important rearrangement in rights/groups for sensitive access to js. In hewiki (possibly other wikis too) there is already somewhat similar user group called "interface-editor" (not a a right, but rather a user group)[1][2]. The user group have also the following rights:

  • import - useful for importing user scripts/gadgets from other wikis and properly preserve credits. (unfortunately there aren't yet "global gadgets")
  • abusefilter-* - abusefilter related rights, as abusefilters requires technical skills and similar to JS can be abused or accidentally harmful (but differently - mainly on site wide without targeting specific user as it is executed on the server side)

I would like to know what you and other people think about having those rights as part of "technical administrators". eranroz (talk) 03:51, 14 May 2018 (UTC)

@ערן: abusefilter is not dangerous (not on the same scale, anyway). Worst case, it can be used to break editing of the site, and then someone else can unbreak it. There is no revert button for harming readers or editors.

Import does not care about user permission at all AFAIK, and whether that could/should be changed is a too complex issue for this discussion. It's not too much of a problem though as usually those permissions only cover other Wikimedia wikis so there only should be non-malicious scripts to import (and if they aren't, those can be exploited without import permissions). There are some corner cases like T112937 but those can be fixed separately, so I don't think import needs to be taken away from other groups.

That said, if scripts/gadgets are the only reason for having the import permission, it makes sense to only give it to techadmins since they will be the ones maintaining scripts/gadgets. --Tgr (talk) 07:04, 14 May 2018 (UTC)

I don't think we need to complicate this proposal by adding more permissions at the outset. Nothing stops us from revisiting that later once the groups(s) exist. 😂 (talk) 03:47, 18 May 2018 (UTC)

Usercss/userjs parenthetical[edit]

A comment on usercss/userjs permissions: There is also discussion on getting rid of these permissions completely, but that's unrelated to the introduction of technical admins. This parenthetical should either link to that discussion, or if truly unrelated, simply be removed. I tend toward the latter. --Izno (talk) 21:40, 11 June 2018 (UTC)

@Izno: removed. There is no good place to link, it was discussed in passing in various places. I opened a dedicated task: T197087 --Tgr (talk) 10:24, 13 June 2018 (UTC)

JSON[edit]

Hi. I really think that json should be in the same box with jss and cs. You say the programmer must write js so it will be impossible? I can give you a 128KB example that they just can't, because even if you could add 512KB more js to sanitize json files, you can't avoid from somebody to remove entirely some entry from json. IKhitron (talk) 11:51, 12 June 2018 (UTC)

I think you'll need to be more clear about what your complaint here. The reason JSON isn't included in this proposal is because JSON is data, not code executed in the user's browser. Anomie (talk) 13:20, 12 June 2018 (UTC)
Neither css. IKhitron (talk) 13:21, 12 June 2018 (UTC)
The FAQ deals with the reasons for including CSS. JSON is not dangerous as long as the script using it is written sanely. If many people want JSON editing to be similarly restricted, or a local community wants it, we can do that, but IMO there is no reason for it. --Tgr (talk) 10:35, 13 June 2018 (UTC)
imo, json is in the same box as template-editor (existing group in some wikis, including enwiki). conceptually it's the same, especially since scribuntu modules are a main consumer of json, and falls smack in the middle of what "template editor" is about. peace - קיפודנחש (talk) 17:24, 13 June 2018 (UTC)

Couple of suggestions[edit]

  1. I think a para should be added at the end (just before the FAQ) restating the fact that this is not about WMF removing technical powers from communities. I think communities need a significant amount of reassurance around this issue, and it simply cannot be overstated.
  2. I am not sure that "Admins and other user groups who currently have editinterface will receive the new rights for a short migration period (so that the transition can happen without any disruption) but eventually won't have them, and the software will enforce that no other groups than technical admins can have it." is necessarily the right option. It means there will be a countdown to "the day when admins lose their technical rights", which could be quite controversial and cause great angst. Instead, I would suggest to (on WMF sites) initially implement the technical admin group with no rights at all. (Technically I think you need to add at least one right for a group to exist, but this could be something trivial like "edit".) Give time for communities to assign technical admin rights to all users who require them. Then a day would be set when technical rights are transferred from the sysop group to the techadmin group. I feel that that could be a more palatable option. This, that and the other (talk) 23:38, 12 June 2018 (UTC)

@This, that and the other: I tried to make my feelings about the importance of communities owning their interfaces clear, and also that this is not really related to the WMF. No harm in repeating it, though (or maybe it's not clear / not what you'd expect to hear?) Do you have a suggestion for the text to be added to the FAQ?

The migration plan is pretty much what you said except that 1) the technical admin group will have all rights from the start (functionally this doesn't make any difference; in hindsight the other way would have been simpler to implement but the patches are already written) and 2) there will be a deadline (the change has to happen at some point and tracking when the thousand or so communities are ready seems unfeasible; also with the ongoing attacks I'd rather do it sooner than later). Which is not really a deadline in the sense that admins could be made technical admins just as easily afterwards. If you think the text could be reworded to sound less stress-inducing, I'd welcome concrete suggestions. --Tgr (talk) 10:50, 13 June 2018 (UTC)

Just to be clear[edit]

Tgr, Can I ask for a full list of rights techadmins would be permitted in Special:ListGroupRights?

Would it just be...

editsitecss
editsitejs
editusercss
edituserjs

or something else I missed? (I think 2FA-enable should be there just to play safe.) Based on the texts, my understanding is that editinterface is not part of techadmin as a default settings, and sysop or other equivalent permission to edit MW: namespace is also required.

(PS: Translation unit 14 is bit problematic: links generated in translation page will be linking to /(language) subpages.)

— regards, Revi 15:19, 5 July 2018 (UTC)

$wgGroupPermissions['techadmin']['editinterface'] = true;
$wgGroupPermissions['techadmin']['editsitecss'] = true;
$wgGroupPermissions['techadmin']['editsitejson'] = true;
$wgGroupPermissions['techadmin']['editsitejs'] = true;
$wgGroupPermissions['techadmin']['editusercss'] = true;
$wgGroupPermissions['techadmin']['edituserjson'] = true;
$wgGroupPermissions['techadmin']['edituserjs'] = true;

(see DefaultSettings.php in the Gerrit change). —Tacsipacsi (talk) 20:35, 5 July 2018 (UTC)

Also the group is added to the WMF privileged group list which is used for the oathauth-enable permission amongst other things. Re: translation unit 14, fixed. --Tgr (talk) 20:58, 5 July 2018 (UTC)

If JSON is not for techadmin per FaQ, why do we need JSON in the config? — regards, Revi 12:34, 7 July 2018 (UTC)
I think it will be needed to edit .json pages, and techadmins (who are not necessarily sysops or interface editors) should be able to edit them—if I create a new gadget which stores its config on a JSON page, I have to create the config page (and also edit it later). —Tacsipacsi (talk) 19:30, 7 July 2018 (UTC)
This section was archived on a request by: — regards, Revi 14:37, 9 July 2018 (UTC)

Announcement plan[edit]

I'm planning to ask for translations and wait for a week for them to happen, then send a mass message announcement to the Technical Village Pumps distribution list, and manual notices to the steward noticeboard, enwiki admin newsletter Tech News, and Meta main page news section.

with this text: (moved)

As usual, corrections, recommendations and other feedback welcome. --Tgr (talk) 17:38, 23 June 2018 (UTC)

I've put "Please help translate to your language" ({{int:please-translate}}) at the top. — regards, Revi 11:02, 28 June 2018 (UTC)
Shouldn't you mark it for translation? IKhitron (talk) 11:48, 28 June 2018 (UTC)
@IKhitron: done; it's at Creation of separate user group for editing sitewide CSS/JS/announcement. --Tgr (talk) 15:20, 1 July 2018 (UTC)

Note to self: test first. --Tgr (talk) 15:20, 1 July 2018 (UTC)

This section was archived on a request by: — regards, Revi 09:39, 10 July 2018 (UTC)

Is this mandatory?[edit]

Did you do this change without input from the whole community? As you are saying "will be", it seems you have already done everything and the upcoming "consultation" will be just "hear what community have to say, but anyways we have already taken the decision and it won't change".

Isn't a group like the proposed already exist locally and globally: interface editors? --Zerabat (discusión) 18:05, 1 July 2018 (UTC)

@Zerabat: getting input from all the communities is the exact purpose of this page (the change has not happened yet, although it's "done" in the sense that the code is ready). If by "input" you mean "permission", though, I don't think that's a good idea - many editors don't have the technical knowledge to weight the severity of a security problem, so that decision is better left to the developer community. Who did provide input, see the linked task for example. (There was no formal TechCom RfC, mainly because this is seen as a no-brainer, but TechCom is aware; see T190015#4153956 and T190015#4281274.) I'm not saying this decision definitely won't change, because there is always the chance that someone points out some big mistake or omission that makes the developers involved reevaluate their position - but the ones making the decision will be the developer community (who are better placed to evaluate security issues), and not editors.
I tried to explain all this in one of the FAQ entries, but maybe it should be in a more prominent place?
Re: interface editors, repurposing the interface editor group would indeed be one way to do this; it seems more problematic to me than the current plan, because 1) we probably still want a relatively unprivileged group that can customize interface messages and edit license / summary dropdowns and such, 2) one important goal here is to make people aware that JS editing is a big deal and should be thought of more like a bureaucrat or steward level thing (as in the hand of an attacker it is indeed roughly equivalent to those), and interface editor is an existing group which people treat as not a big deal, and it would be harder to change that than to introduce a new group. --Tgr (talk) 20:55, 1 July 2018 (UTC)
This section was archived on a request by: Zerabat (discusión) 01:34, 16 July 2018 (UTC)

editinterface[edit]

Will Technical Admins get the editinterface permission? If they don't, this group would be rather useless to assign to users who might not have this permission already. I don't think this would be a good idea. --MGChecker (talk) 22:16, 13 June 2018 (UTC)

@MGChecker: Yeah. In the current version they get editinterface, editsite* and edituser*. --Tgr (talk) 20:01, 14 June 2018 (UTC)
Are you aware that it is possible to "transclude" javascript and css from other namespaces than MediaWiki and User with mw.loader.load? You would have to manually change the content model of a page, but it's quite possible, I even know some wikis that use this approach to give non-admins control over site css. --MGChecker (talk) 22:26, 14 June 2018 (UTC)
While that's certainly bad practice, on the technical front there's no defending from this without forcing significant limitations on what JS can be implemented (even if mw.loader.load was filtered for namespace, there's nothing stopping someone from using a raw XMLHttpRequest to load code). That in turn would be politically implausible, since a concern is the perception that this change would represent a technical removal of power from the users in favour of the WMF. While insecure practices should be discouraged as part of this change, preventing them entirely is impractical. {{Nihiltres |talk |edits}} 03:18, 4 July 2018 (UTC)

Criteria for granting 'techadmin' for wikis without crats?[edit]

Wikis with crats probably means they have a community, big enough, to self-govern and set their own rules for the appointment, but what about the wikis without them? How should stewards assign the permissions (for wikis without crat)? I think this should be agreed upon (preferably) before it goes live. — regards, Revi 20:37, 3 July 2018 (UTC)

On wikis with no bureaucrats, the obvious solution would seem to be to give the permission to all admins; if they're small enough the likelihood of the kind of attack that this change defends against is presumably significantly less. As a compromise, let admins on those wikis remove but not re-add the privilege, allowing them to renounce it if they're not going to use it. {{Nihiltres |talk |edits}} 03:24, 4 July 2018 (UTC)
No; small wikis are one of the primary locations for the security breaches that have necessitated this change. I think that these permissions should be assigned in the same way that adminship is assigned on small wikis - after a week's discussion on a temporary basis with increasing time for successive requests. For simplicity, it might be worth allowing a user to request both temporary adminship and interface adminship (I'm making it a thing!) at the same time. – Ajraddatz (talk) 04:45, 4 July 2018 (UTC)
Granting sysop + techadmin with 'no question asked' doesn't sound good - then I don't see the reason behind this change ;P It's fine if we are granting them as an additional migration period, that's fine, but no for indef. — regards, Revi 15:35, 4 July 2018 (UTC)
Well what would you suggest then? If a user wants both temp sysop and temp intop, they should open two current requests on the same page instead of one? The purpose of this change is to reduce access to the people that need it, not remove access entirely. And without some sort of global RfC we couldn't unilaterally restrict this access on small wikis. – Ajraddatz (talk) 15:48, 4 July 2018 (UTC)
Granting sysop+techadmin when they ask for is fine for me, just granting them when they didn't explicitly ask for techadmin wouldn't be prudent. — regards, Revi 08:28, 5 July 2018 (UTC)

The Technical administrators page has some guidelines on what the requirements should be (trusted by the community, knows CSS/JavaScript, has a clue about password and computer security, understands that all external assets must be optin, including Toolforge and such). As for how the decision is actually made, yeah, using the same process as for admin elections makes sense. --Tgr (talk) 15:29, 4 July 2018 (UTC)

Sysop not admin[edit]

I don't have any great name suggestions (script editor?) but I do kindly request that if the word "admin" is to be used in the actual name that it instead be "sysop" a la the sysop bit. We can all call it something else like "technical admin" if we like, but parallelism matters. ~ Amory (utc) 00:47, 4 July 2018 (UTC)

There's precedent to remove the parallel actually; see translationadmin. FWIW I'd still support calling this interface editor even if it's just a subset of the interface. Maybe interface administrator? INTOP for short? :-P – Ajraddatz (talk) 01:51, 4 July 2018 (UTC)
That's a pretty good name. --Tgr (talk) 15:29, 4 July 2018 (UTC)
I think interface editor is probably better. I just don't know why "xx administrator" is not appealing to me. –Ammarpad (talk) 15:14, 5 July 2018 (UTC)
There are already Interface editors on few wikis which is not verbatim to this new usergroup, so it will cause duplicate. — regards, Revi 15:30, 5 July 2018 (UTC)

Interface Editor should auto-get the right[edit]

They should be ok enough to get this right-they are safe enough to do so, and I don't see the reason for the non-admin interface editor not to get this right, unless there are other problems, which I couldn't find one currently.--1233 | Questions?| This message is left by him at 12:59, 5 July 2018 (UTC)

"Interface editor" could be granted to someone to edit translations rather than based on their JS and CSS skills. I don't think auto-granting the right would be appropriate. Anomie (talk) 13:28, 5 July 2018 (UTC)
On Hungarian Wikipedia, there is currently an interface editor who explicitly said at the right request that he doesn’t want to edit JavaScript, only other parts of the MediaWiki namespace. So yes, this is not just a hypothetical case, but the reality. (If it was absolutely safe to grant this to all interface editors, than that right would be recycled instead of creating a new one.) —Tacsipacsi (talk) 14:01, 5 July 2018 (UTC)

Why maintain local access?[edit]

My technical know-how is limited, so apologies if this is a stupid question. As I understand it, part of the problem was that even local administrators (such as myself) had the ability to edit site-wide scripts, and thus cause trouble. The solution being presented is to limit this ability to a small groups of people. Why, then, does it make sense to allow local wikis to elect this group of people? Surely it's no secret that the smaller wikis often have much less stringent procedures for handing out special permissions. Why not make the technical administrator selection process a meta-only process? Vanamonde93 (talk) 05:21, 4 July 2018 (UTC)

I think there is value in having a meta process for at least the small wikis (that's what or the global Wikimedia community if that community creates a global policy through the usual means refers to in the text) but developers are not really well-placed to evaluate that kind of governance change - they don't have the familiarity with the processes of small wikis that local editors and people like the Small Wiki Monitoring Team members do. So that should be a separate discussion that's decided by community consensus, IMO. --Tgr (talk) 15:42, 4 July 2018 (UTC)
@Tgr: I think you may have misunderstood. I'm not saying small wikis should have their own processes. I'm saying none of the individual wikis should be able to grant cross-wiki rights. All of those should be on meta. Vanamonde93 (talk) 09:48, 9 July 2018 (UTC)
@Vanamonde93: I did not misunderstand, I'm saying I agree (at least partially; not sure about large wikis) but that would require a different discussion and probably a different decisionmaking mechanism. --Tgr (talk) 09:54, 9 July 2018 (UTC)

My 2cents worth[edit]

Dear Guys,

With all respect to the developers, I shall start. I understand the inherent risks of allowing site-wide java/commons/js to be compromised by compromised admins accounts / rouge ones. I can't speak for all wikipedias, for my home wiki, there is a very small sysop community of around 78. From what we gathered from the village pump, around 20 of them do edit the relevant parts responsibly and if crats are allowed to give this PERM (and by extension, to themselves), it will be around 33, which is almost half of of sysops. With this, giving separate user rights to prevent "rouge" sysops does seems moot. In addition, for compromised accounts, if they are found, a quick compromised block will do the necessary preventative action (stewards immediate attention might be needed).

As of community appointment / election or whatsoever term the PERM assignment should be, it will need volunteer time to first set up a framework of the process (which need to be approved by consensus), afterwhich there will need more volunteer time for the process to take place. Clearly this cannot be done within the period. We either have to had a temporary migration measure as what revi somehow pointed out, or otherwise I beseech to hold this for a while more for the due process to take place.

Furthermore, for such processes to take place, it will divert the already small amount of time volunteers have towards Long Term Abusers (LTAs), vandals, copyvio violaters, new page patrolling, recent changes patrolling and etc. This in turn will cause more disruption not less to smaller wiki (by community size and involvement). The reverse benefit for meta wide template protection may seems more, but some smaller or lesser manned wikis will be affected.

Thanks and end of my 2 cents --Cohaf (talk) 16:17, 6 July 2018 (UTC)

@Cohaf: Even reducing the chance of large-scale abuse by half would be a pretty big deal; definitely worth the cost. What kind of timeframe do you think would be sufficient for the migration? --Tgr (talk) 10:00, 9 July 2018 (UTC)

@Tgr:perhaps 3-4 weeks will be reasonable, just a short reprieve in some sense for consensus to be able to be reached for appointment of tech admins. This is akin to Continuing Resolution vs Government shutdown, but hopefully this analogy is bad enough that all the backend process can be sorted out and we will be able then to roll out this fullscale, like recent ndaa. but yep, thanks for hearing me out, appreciate the responsiveness--Cohaf (talk) 14:53, 9 July 2018 (UTC)

No truer statement[edit]

Most administrators do not actually want or need the ability to edit CSS and JavaScript.

  • Yep. Basically. Sounds good to me. Make my account less attractive to hacking and make me less likely to accidentally do something dumb? I support. TonyBallioni (talk) 17:00, 9 July 2018 (UTC)
    +1 for preventing TonyBallioni from doing something dumb. Oh yeah, and good security practices too. --AntiCompositeNumber (talk) 01:15, 10 July 2018 (UTC)
    No promises I won't do something dumb elsewhere, though... TonyBallioni (talk) 01:15, 10 July 2018 (UTC)

Strong support[edit]

I realise this is not an RfC but I strongly support this initiative because of the reasons described in the explanation, and I'd say this is also in line with community expectations. I'm surprised to find that all admins can do this, it has the potential for far-reaching consequences if it is misused or hacked, and at least on EN WP based on out discussions, is not something most editors would expect our admins to do. --LT910001 (talk) 20:45, 9 July 2018 (UTC)

Too short transition time[edit]

Two weeks in the middle of the summer is far from enough. Small wikis often have only one or two bureaucrats, who may be vacationing in these two weeks. (Not to speak about the admins who need to ask for the right.) Two weeks would be OK in September, but not in July. —Tacsipacsi (talk) 00:16, 2 July 2018 (UTC)

If the local 'crats are inactive, stewards can grant the new permission instead. – Ajraddatz (talk) 01:21, 2 July 2018 (UTC)
@Tacsipacsi: what would be sufficient time in your opinion? --Tgr (talk) 09:36, 2 July 2018 (UTC)

@Ajraddatz: And what about the communities’ self-government? Stewards should intervene if and only if local bureaucrats are inactive. Being off-wiki for two weeks is not inactivity yet.
@Tgr: If we can’t wait until September (why not? the patch is ready since March, why should we hurry now?), I think the bureaucrats would need at least a month (or four weeks, it’s up to you). —Tacsipacsi (talk) 21:57, 2 July 2018 (UTC)

How exactly is community self-governance harmed if stewards step in when local bureaucrats are inactive or unavailable? We're talking sub-domains of a website on the internet. Stewards exist to implement community decisions, and assigning a permission in accordance with the desires of a community when nobody else is around who can is hardly an infringement on any concept of "self-governance". – Ajraddatz (talk) 22:06, 2 July 2018 (UTC)
I wouldn’t have come up with this if this page didn’t mention the self-government. Stewards do not know the local community, and may not be able to take the right decision based on very few people’s (maybe only one or two, or even nobody’s) opinions. We’re talking about several communities working on several encyclopediæ (or dictionaries, or book collections, or whatever). —Tacsipacsi (talk) 22:39, 2 July 2018 (UTC)
Nope nope nope. Stewards are not to act as bureaucrats on projects that already have them available. Doing so would be very much specifically outside the stewards role. It's in the first paragraph of Stewards. Independent communities are independent communities, not just "sub-domains of a website". --Yair rand (talk) 18:26, 3 July 2018 (UTC)
The concern was raised about what happens if local bureaucrats are unavailable; I said that in such a case stewards could step in to implement community consensus, as stewards currently do if there are no bureaucrats or existing ones are very inactive. Seems like a reasonable statement. And of course, these are just sub-domains of a website, no matter how obsessed people get over them. – Ajraddatz (talk) 18:40, 3 July 2018 (UTC)
On a small wiki the chance of an edit being required to these pages is small. So it should be able to wait. But if it is really needed a steward could do the edit. If a beaurocrat is on holiday, the local admins may also be on holiday, and so may be the community that may discuss what to do. I do agree that 2 weeks is really too short for a community discussion any time. Graeme Bartlett (talk) 03:27, 4 July 2018 (UTC)
It may be too short, but the timeframe is a balancing act between allowing communities time to react and taking steps to resolve a major security issue with our sites that is subject to ongoing exploitation, and will probably be subject to more as it moves further into the public light. And you're completely right that there is little need to make modifications to those pages for small wikis, so a wait is acceptable. I'm just saying that if there is an urgent need to either promote interface administrators (sounds good, right? :P) or edit the CSS/JS pages, then a steward can step in, as has always been the case. – Ajraddatz (talk) 04:56, 4 July 2018 (UTC)

Do we even want to give local bureaucrats rights to grant this right? In many wikis bureaucrats can't even remove admin rights. I think it's bigger deal to give access to code that can break other user's computer (in worst case) than remove normal admin rights. Stryn (talk) 18:34, 3 July 2018 (UTC)

I generally prefer to not centralize more powers to the steward group, especially those that are currently held by local bureaucrats. But I could see the argument that this new group be treated with the level of trust expected of CU/OS holders. If abuse happens with bureaucrats handing out the permission, we could always further restrict it as needed later. – Ajraddatz (talk) 18:43, 3 July 2018 (UTC)
Well someone should get the right to grant the permission. I don't think it matters that much anout the deadmin permission. A steward could do that in an emergency if someone goes wild. The problem will be to understand the local wiki language and policy on the topic. If the policy is risky and stupid, should it then be rejected and the editing granting right not given to any one on that wiki? All the local policies for appointing tech editors whould be tranlated to English (and perhaps some other languages) so that stewards and others can see what to do for that one, or whether they should trust that wiki. Since the effect of the edits is potentially global affecting any user onany wiki, perhaps we need a way to audit all changes to all wikis to see if anything unsafe happens. An alternative is to set it up so that cross site scripting cannot happen, perhaps by logging off the person when they visit an unsafe Wikipedia. Or by somehow limiting the global logon to only safe wikis. Graeme Bartlett (talk) 01:26, 10 July 2018 (UTC)

I also think 2 weeks is too short of a notice. +1 for 4 weeks regardless of the deployment date. Wikis are historically slow to take decisions and pushing them with the threat of loosing the ability to edit their interface is unfriendly to say the least. Strainu (talk) 07:59, 10 July 2018 (UTC)

@Strainu: they wouldn't loose the ability, just not have access to it for a few days. That said, a four-week migration period should be fine. --Tgr (talk)

A few thoughts[edit]

Hello, I like this intention. In many cases I saw someone asked admin with no or very little JS knowledge to insert some piece of code and the admin believed the asker knows what he does. And this is just silly and wrong at all.

Some wikis already have got tech admins and many others are discussing to introduce them, now they will be forced to do so (if I understand it correctly). Will be existing tech admin user groups on those wikis that already do have them be converted in some way? If so, what if they have got some extra privileges (like delete/undelete), will these be preserved? Or what if a community decides to add some privileges like this to their newly created tech admin group?

In my opinion, the same problem can be also achieved using MediaWiki: messages. They are shown on various places within user interface and edit interfaces and with a good knowledge of wikitext+lua hacking serious damage could be made too.

Another thing to discuss are the abuse filter rules. Admins need to edit them, because they belong to anti-vandalism functions, so these should not be switched under tech admin group. But I can imagine someone could misuse them in a bad manner. Are they somehow protected to be safe enough?

Finaly, even though I support the intention, admins are usually voted by community which by their votes decides, whether to trust the candidate or not. Therefore, until now, they could acquire some trust, then successfully candidate and finally (when nobody sees), add an exploit to the Common.js. How this will be prevented with the new user group, when the procedure to gain these rights will not change?

--Dvorapa (talk) 13:36, 9 July 2018 (UTC)

Wikitext (even with Scribunto's Lua in interface messages) and AbuseFilter cannot do the sorts of things that are of a concern here. There are some ways a rogue admin without the new group could still cause the kinds of problems of concern here, but per w:WP:BEANS I'm not going to go into detail. It is intended that those will be closed off too. Anomie (talk) 14:17, 9 July 2018 (UTC)
@Dvorapa: I don't plan to convert any existing group; I think it's better to keep the JS editor group specific to just that and separate from other "technical" privileges (like editing protected templates or abuse filters) as those have much lower risk. If a community wants to add extra privileges to the techadmin group, they can, but turning it into a mixed "JS editors and other technical helpers" group is IMO a bad idea.
Building enough trust to become a (tech)admin is much more costly to the attacker than just stealing a random account. There is no perfect security, but this will make things a lot safer with a very small cost to editors. Disabling JS editing entirely would make things more safe, but at a huge cost; I don't think it would be a good trade-off. --Tgr (talk) 09:44, 10 July 2018 (UTC)

Think about small communities[edit]

Well, yes... it seems we could have a problem here. But think about small communities who wouldn't understand why they can't change a css or js they have copied from another wiki. I think that the solution you propose is good, but implementing it fastly could (could) harm communities that have a limited technical capacity but an even more limited knowledge of where things are decided and where they have to ask for help. I have personally helped smaller communities in their first steps, and usually you can get an admin who could handle the css and js copypasting, but if they need to ask for another step to solve their problem, I thing they would be lost -Theklan (talk) 19:40, 9 July 2018 (UTC)

@Theklan: At the same time, small wikis are the ideal targets for attackers as suspicious edits will be noticed much slower, and compromising one wiki is pretty much the same as compromising all of them. So making JS editing harder for those wikis is not a cost we can easily avoid (and I don't think implementing things slower changes that). They'll just have to rely on global interface editors; in the longer run, I hope we can come up with ways of centralizing CSS/JS between wikis in a safe way. --Tgr (talk) 09:57, 10 July 2018 (UTC)

Bottom 250+ wikis[edit]

You have written "On the top five wikis, 75% of admins have never edited CSS/JS; 92% of admins have almost never done so." But this might be completely opposite if you consider rest of the wikis, except top 15-20 wikis! I am not against this change, just concerned how it will be handled! -- ɑηsuмaη «Talk» 06:55, 10 July 2018 (UTC)

@Ansumang: Of the ~500 small wikis, only 29 had any JavaScript edits in the last twelve months, and only 10 had more than 10 edits. [3] --Tgr (talk) 08:03, 10 July 2018 (UTC)

GlobalGroups[edit]

Will there be a corresponding global group? I think this would be a really useful thing if you intend to take these permissions away from global interface editors. Furthermore, I think there should be a oathauth-forced "permission" assignes to this group to prevent further security problems. --MGChecker – (📞| 📝| Bewertung) 00:28, 13. Jun. 2018 (CEST)

Yeah, there should be a global group. (I imagine we'd just rename global interfaceditors - is it used for much else other than editing scripts?)
Requiring two-factor authentication is definitely something that should happen. There are technical blockers at the moment (T150562 and some UX warts). --Tgr (talk) 10:38, 13 June 2018 (UTC)
Not a huge fan of forced oathauth, but it should be included as an option of course. – Ajraddatz (talk) 18:29, 15 June 2018 (UTC)
@Tgr: I think renaming global interfaceditors (or just adding the permissions to that group) would make sense. That group is mostly just for people who help maintain JS across various wikis (especially smaller ones that don't have local JS coders). Kaldari (talk) 19:42, 12 July 2018 (UTC)

Existing groups[edit]

Since it was not discussed enough in the relevant task, I’d like to ask this here: what is the strategy for the projects that already have a ‘technical administrator’ role? For example, in Russian Wikipedia there was an RfC ‘Flag of technical administrator’ in 2016 that introduced the ‘engineer’ user group in our project. In the patches, it seems like now you are just removing edituserjs/editusercss after the short-term solution, but in the projects like Russian Wikipedia (I can’t say anything about others) there would be a lot more sense to unite ‘technical administrator’ group with existing ‘technical administrator’ (engineer, in our case) group, not create two separate ones.

(Minor note: editcontentmodel right is extremely useful for technical administrators for having some pages, like MediaWiki:Gadget-HotCat.js/local defaults, in the correct format.) stjn[ru] 12:13, 9 July 2018 (UTC)

I believe the better solution will be a new subtask, that allows to merge the new group to any existing group that has editinterface right, for any local community that wants that. IKhitron (talk) 12:56, 9 July 2018 (UTC)

@Saint Johann: I'd like to limit JS editing to a single group that's called the same on every wiki; that makes central abuse monitoring much easier. A wiki could of course choose to grant 'engineer' and 'techadmin' group membership together in a single process. --Tgr (talk) 08:10, 10 July 2018 (UTC)

Okay, but are we able to rename 'engineer' group to 'techadmin'? If yes, can the group rights be wiki-specific, so that we are able to have extended rights for this group compared to default 'techadmin'? Jack who built the house (talk) 10:33, 10 July 2018 (UTC)
@Jack who built the house: there isn't really such a thing as renaming a group (you could change the Russian translation to engineer, I suppose). Wikis can customize what rights the local techadmin group gets, yes. (Although it would be preferable to keep it focused on CSS/JS editing so that it does not have to be granted on template/Lua/abusefilter/etc editors with no intention of editing CSS/JS.) --Tgr (talk) 09:35, 12 July 2018 (UTC)
@Tgr: what he’s talking about, I suppose, is renaming engineer group and references to it to techadmin for Russian Wikipedia on configurational level. Since that group was intended to have the ability to edit interface/CSS/JS for trusted knowledgeable users, it would make little sense to have two groups that do entirely the same, and that seems the consensus in a small discussion we had about it (in Russian). stjn[ru] 13:59, 12 July 2018 (UTC)

Will we have enough techadmins?[edit]

I am afraid medium-sized communities will face the risk of having too few interface editors. While big wikis with over 100 admins will probably be able to deal with it, I am afraid we might get issues in wikis having between 10 and 100 admins.

The issue is that quite few admins are JS/CSS experts who have professional level of both. However, many admins usually have some programming experience and IT skills but not specifically in JS or CSS. This means they will probably be able to understand whether a JS or CSS is malicious or not or do some basic fixes. However, having to explicitly apply for this role and stronger requirement (e.g. 2FA) can drive off many.

I think that we risk having even less people ultimately getting this flag than those already editing JS/CSS. This means having less people who can control and react to potentially malicious changes which I don't thing is really good for JS/CSS security — NickK (talk) 12:28, 9 July 2018 (UTC)

Having looked through history of CSS/JS editing on Ukrainian Wikipedia, I am even more convinced this will be a problem. I found basically three categories of administators:
  • Those who are really good at CSS/JS, i.e. can write complex code from scratch. They are not very numerous (about 10% of all sysops), and most of them don't really like bureaucracy like requesting additional rights. There is a risk some of them will not request this right if the procedure is too complex (voting or long discussion, activity requirements etc.)
  • Those who can do some CSS/JS editing like copying a code from another wiki or fixing small bugs. They are rather numerous (about 40% of all sysops, this includes me) and they make a lot of CSS/JS edits. The risk they will not request rights might be rather high: they are not CSS/JS experts and they do not necessarily need these rights, they just help when they can.
  • Those who never did any CSS/JS editing and probably do not know how to do it. They represent roughly 50% of all sysops, and they will be clearly not interested in these new rights.
I am quite afraid we will end up with much less people actually editing CSS/JS than we currently are — NickK (talk) 23:53, 9 July 2018 (UTC)

@NickK: I sympathize (I'm from a medium-sized wiki myself and maintaining gadgets can be a struggle) but not sure what to do about it. (In the longer term, I think we can make it easier to pool resources between projects, and to allow people to suggest code changes without having the permission to deploy them; see T187749 for some plans.) If you have ideas, I'd like to hear them, and you can certainly structure your own processes in a way to minimize the burden (someone who is really good at CSS/JS and trusted enough to become an admin should probably be able to get the new permissions without much debate; and while removing the right from inactive accounts is strongly recommended, there is no reason to make them go through another election-like procedure to get it back; it should be enough if they demonstrate their identity, e.g. by writing to the admin mailing list from their usual address). --Tgr (talk) 09:23, 12 July 2018 (UTC)

@Tgr: From my own experience, pooling resources between projects will not work perfectly. People who are currently copying JS/CSS from one wiki to another have to keep in mind language differences (all messages have to be localised), sometimes localisation (e.g. different date format), sometimes compatibility (with already existing styles and gadgets). This will still require people to work on this locally.
Suggesting code changes will work only if there are enough people to proceed this requests. Which actually takes us back to the original problem of having enough techadmins.
I actually think that the best way to handle this is appropriate communication and coordination with the communities. There should be some transition time, local communities have to adapt their policies (if this flag is given by crats, there should be some policy on that), administrators should have time to apply etc. The risk of not having enough people to maintain code is quite high but we can avoid it — NickK (talk) 14:08, 12 July 2018 (UTC)

Please inform all wiki communities[edit]

Hi @Tgr:, this is a sensitive issue and the consultation time is very less. So, a proper community consultation is needed. Please post your proposal in village pumps of all wiki's and mailing lists, so that the communities are informed. I just happened to be here by accidentally checking a Facebook post, and am really worried that we were not at all informed. Also, the consultation time needs to be increased to involve more community members. Bodhisattwa (talk) 03:39, 10 July 2018 (UTC)

I am also concerned, Gergő, that this will cause difficulties for smaller wikis and thus I share Galder's concerns above. A lot of issues with templates and whatnot imported from other wikis often comes down to issues with common CSS and JavaScript, tinkering with which can often fix those issues. It may well be defensible to restrict the ability to tinker in this way on larger wikis to those who are very competent with those two languages, but it becomes rather cumbersome for smaller wikis with few administrators, like the one Bodhisattwa and I are both sysops in, when they need to make such changes. If it comes down to adopting the proposal here, I would suggest that, at the bare minimum, administrators on global sysop wikis (only the active administrators under the 'fewer than three...' criterion, and the the rest under the 'fewer than ten...' criterion) automatically obtain the rights granted to this new user group, so as to reduce the strain on smaller wikis when it comes to obtaining the rights or modifying stylesheets and scripts. Mahir256 (talk) 04:04, 10 July 2018 (UTC)
@Bodhisattwa and Mahir256: see #Announcement plan. If you can suggest other places, I can send a notice there as well. Two weeks seem plenty of time to read a 2000-word wiki page and leave comments.
Tinkering with code without understanding it (especially if there is no one in that wiki at all who understands it) tends to result in security vulnerabilities that can be exploited without even having to steal an admin account, so I don't think it's a good idea to support that. Those wikis should just ask global interface editors for help.
For templates needing CSS, TemplateStyles should reduce the burden a lot - TemplateStyles CSS is safe and can be edited by anyone. Templates needing special JS is pretty rare. --Tgr (talk) 09:53, 10 July 2018 (UTC)
@Tgr:, I don't see any Bengali sites listed in your annuncement plan. The Bengali wiki community members are completely unaware of what is going on here. Secondly, admins from small wikis are repetitively expressing their concerns here and in phab about the possible disruption of work there due to this new hierarchy, but looks like the concerns are not addressed. Thirdly, 2 weeks notice is not enough, as mentioned by many editors, if the communities are properly consulted and asked for opinion. But here, I guess, everything seems to be pre-decided and editor communities have no role at all, which is concerning. IMHO, there is no harm to consult the community members properly and give ample time. -- Bodhisattwa (talk) 10:29, 10 July 2018 (UTC)
The main issue seems to be security risk. The accounts of code-ignorant admins can be hacked and misused by tinkering with css/js. OK, but how are the accounts of code-knowledgeable admins going to be secured? If such accounts can be secured, why not all admin accounts, by 2FA or some other methods? Already we have too many hierarchies. This new tier will create an additional level of differentiation among the admins, and additional power centers. In small wikis, editors are few, and admins fewer. In times of pressing maintenance works, even if we are ignorant, we learn. I did not know pywikibot processes. But work was needed in my wikisource for touch-editing six hundred thousand pages, because proofread-status colors are not being shown because of a new developmental work. So I have learned it, and started work. I learned from knowledgeable admins. In small wikis, in times of need, we don't shirk essential work by citing ignorance, we cannot afford to, because, then who will do it? So we learn. Now, under this scheme, for every trivial issue, we will have to approach the stewards, or global interface editors, and what not? And what will happen? These big brothers will keep every issue hanging for 10 days or more; will demand community consensus and link thereof, and what not. Even such links will not suffice. An editor was inactive for more than two years in my wiki, and the community had decided that his adminship should be revoked. When the matter was put to Meta, it was kept hanging for many months. I am an active editor and was an admin until a few days ago. The community has no objection to the renewal of my adminship; but when it came to Meta, it has been put on hold. Maybe it will remain on hold for many months, I don't know. This kind of thing will happen for every little titbit involving some little tinkering with css or js. Large wikis can cope with it, having sufficient manpower. But small wikis will suffer. Dedicated admins will get irritated and move to other pastures, because of this degree of begging to higher-ups for little bits of alms. This whole process is a sure way of damaging small wikis. Hrishikes (talk) 11:56, 10 July 2018 (UTC)

@Bodhisattwa: my bad, I assumed that list would include non-technical village pumps for wikis which do not have a technical one, but apparently it just skips them. I sent out a notice to the wikis which I missed in the first round. (FWIW the announcement was also sent to ambassadors via Tech News, and that included a couple bnwiki users. In general, it's a good idea to ensure there are active tech ambassadors for your wiki.)

If you have ideas on how to reduce the burden on small wikis without sacrificing security, I'd love to hear them; that's what this consultation is for! (And two weeks seems plenty of time for that.) In the end, though, trade-offs have to be made; having strictly zero impact on workflows of interface maintainers in small wikis is not a realistic condition. --Tgr (talk) 09:14, 12 July 2018 (UTC)

Consultation wording and note a on separation[edit]

[This change will not be determined by] community consensus. … Software security decisions are governed by the consensus of the MediaWiki developer community, rather than the consensus of editors … as usual. Next time, please put that much closer to the top; I wasted a considerable amount of time reading and pondering portions of this "consultation" before I got to the FAQ (which is near the bottom). — Godsy (TALKCONT) 23:30, 11 July 2018 (UTC)

That aside: the technical administrators user right/group should only include the rights being separated, not all administrator rights, and be granted in addition to sysop when necessary. This would give communities, especially smaller ones, the option to grant the right to technically skilled individuals without giving them the whole administrator toolset. — Godsy (TALKCONT) 23:42, 11 July 2018 (UTC)

@Godsy:another issue the faq need to be clearer. What you are talking about is what the tech admin is about. Just tech tools. Whether to give it to non sysop and the process is locally decided. See more time wasted again by users, sigh.--Cohaf (talk) 06:45, 12 July 2018 (UTC)

Interface editors[edit]

I think this RFC should also explicitly include the elimination of interface editors - this is a more risky privilege than banhammering users, not less. Max Semenik (talk) 00:25, 14 May 2018 (UTC)

@MaxSem: It sort of does, via 421125 (maybe that part should be clearer in the text). See also the third FAQ question. Is that what you meant? --Tgr (talk) 06:43, 14 May 2018 (UTC)

You could call the new group "interface editors" rather than "technical administrators". Uses the existing nomenclature and is more specific than technical administrator. Is there a need to remove the existing global group, though? – Ajraddatz (talk) 18:26, 15 June 2018 (UTC)
@Ajraddatz: "sort of" means that interface editors will be prevented from editing CSS/JS. Just converting that group into JS editors would be an option (and it's definitely a better name) but then there would be no way to allow somone to edit upload license options and such but not CSS/JS. Maybe that's OK, I don't know how to decide that for hundreds of wikis though. Also, interface editor is considered a low-risk thing (compared to full adminship) and JS editing should be a big deal; at least as big as adminship. So I think the name would mislead people. (As for global interface editors, I see more point in removing that group to keep things simple. Are there any global interface editors, who do not edit CSS/JS?) --Tgr (talk) 19:37, 15 June 2018 (UTC)
Ah of course, sorry my silly brain was doing too many things at once and forgot that there is an interface outside of the CSS/JS pages. I'm fully behind the "technical administrators" name! For the global interface editors, all or almost all of them use it for editing css/js pages - so it could either be renamed to better reflect the scope or just kept in its current incarnation. – Ajraddatz (talk) 19:47, 15 June 2018 (UTC)
Local 'editinterface' users should be removed after the transition period and moved to the 'techadmin' group. It'll be redundant to have two user groups for basically the same task. As for the global interface editor group, in order not to have to enter another entry in the WikimediaMessages extension I'd suggest to keep its naming, adding the relevant new rights if appropriate. Thanks, —MarcoAurelio (talk) 18:01, 11 July 2018 (UTC)
Note that 'editinterface' can be used to edit interface translation messages. Someone doing that may not also need the ability to edit JS and CSS. Anomie (talk) 13:57, 12 July 2018 (UTC)
Then local admins cannot edit spam-(black/white)list, titleblacklist, sitenotice, anonnotice, etc etc without techadmins. Sounds like defeating the purpose of techadmin. — regards, Revi 05:16, 14 July 2018 (UTC)

We’re already discussing this in the ckb Wikipedia[edit]

Currently, there’s an ongoing election of the two users that volunteered for the user right (one of which is me), but what happens next? Where can we point out about it so our user rights are migrated?--Épine (talk) 15:09, 11 July 2018 (UTC)

@Épine: right now the new group does not exist yet; it will be created when the consultation is over (so 23th of July plus/minus a few days); there will be an announcement at that point. At that point you can ask the same people you ask for setting admin rights - if your wiki has bureaucrats, you can ask them, otherwise you can ask stewards. --Tgr (talk) 06:59, 12 July 2018 (UTC)
@Tgr: what about the voting process? If it takes any more time than 23rd I’m afraid that they will declare ours as old. And another question, what will be the new icon for the group? I propose something like this: File:Admin-Crat.png--Épine (talk) 19:59, 14 July 2018 (UTC)

Deploy TemplateStyles[edit]

I think TemplateStyles should be deployed ASAP – this way safe CSS can be exported from Common.css before sysops lose their ability to remove relevant parts from the MediaWiki namespace. For example, I’m a sysop on some wikis where I don’t plan to apply for techadmin rights (because I’m mostly inactive there, and will only ask for it if it’s really necessary), but might want to edit safe CSS, and I’m more likely to fix it if I don’t need to apply (and wait) for rights. (And also if I can’t do this now, who knows when—or whether—will someone.) As far as I know, the extension is ready and can be deployed. —Tacsipacsi (talk) 16:25, 12 July 2018 (UTC)

@Tacsipacsi: the main technical blocker for TemplateStyles was the Tidy/Remex migration and that is over now, so I guess it would be possible. Maybe @Deskana (WMF): has thoughts on it. --Tgr (talk) 11:30, 14 July 2018 (UTC)

Ordinary users become techadmin[edit]

Where "Ordinary users" is mean non-sysop.

Allowed ordinary users become techadmin does violate the original intention of the plan? -- 星耀晨曦 (talk) 10:07, 13 July 2018 (UTC)

@星耀晨曦: only if it's used recklessly. Various non-sysop groups (e.g. interface-editors) already have JS editing privileges so this wouldn't be a change in that regard. It's important to make everyone understand that this is an important privilege and should be handed out sparingly, though. --Tgr (talk) 11:26, 14 July 2018 (UTC)

Some questions[edit]

Is user:xxx.xxx.js or user:xxx.xxx.css also included in this? What if the people those who don't have knowledge to install a user script and don't know to add it in their common js/CSS? --Tiven2240 (talk) 14:28, 15 July 2018 (UTC)

Everyone is and will be able to edit their own user CSS and JS (i.e. User:XY can edit User:XY/foo.css and User:XY/bar.js). This is critical, because this way users can control their own settings and do not need someone else to remove any harmful code, for example; while editing user scripts (normally) can’t cause any harm to other users. The ability to edit other users’ CSS and JavaScript will be restricted to this new group (User:XY will be able to edit User:AB/cde.js only if they are in this group). —Tacsipacsi (talk) 17:11, 15 July 2018 (UTC)