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

Other rigths for the new group

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

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

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

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

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

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?

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

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?

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

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 (u • t • c) 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

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?

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

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

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

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

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

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

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

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

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 – (📞| 📝| ) 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

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?

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

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

[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 ^(TALK_CONT) 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 ^(TALK_CONT) 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

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

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

Tracked in Phabricator:
Task T199909

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

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

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)

Questions and comments from Incubator

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

• 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)

Paid editors

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

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)

Group name and the word "administrator"

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)

Separate secure account as an alternative

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)

Semantics and scope of the problem statement

Hello,

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)

Activity requirement

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)

Should be separate from but not necessarily higher than admin

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

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)

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

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)

Making assigning of techadmin membership central by default?

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)

2FA

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 (talk • contribs) 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)

Will this change be implemented on all wikis?

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 or.wiki 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)

So it’s July 23

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 ([4], [5], [6], [7]). 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:

• bs.wikiquote.org bad namespace (ie. probably wrong title in Distribution list/Global message delivery
• chr.wikipedia.org bad namespace
• cv.wikipedia.org protected
• cy.wikibooks.org bad namespace
• diq.wikipedia.org bad namespace
• got.wikipedia.org protected
• gu.wiktionary.org bad namespace
• mk.wikibooks.org bad namespace
• mk.wikisource.org bad namespace
• ml.wikibooks.org bad namespace
• ur.wikipedia.org bad namespace
• commons.wikimedia.org opted out

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

• lez.wikipedia.org protected
• mk.wikisource.org bad namespace
• to.wikipedia.org protected
• wuu.wikipedia.org 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)

Page moves

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?

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)

Bureaucrat revoke techadmin

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)

Temporary membership

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)

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

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)

Safer?

• 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)

editcontentmodel right

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 (u • t • c) 19:50, 5 August 2018 (UTC)

Offer the new permission to all current sysops by default

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)

What if

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)

Since March

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)

Next steps

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: 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)

Interface administrators Icon

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)

• not bad Tiven2240--Cohaf (talk) 18:14, 8 August 2018 (UTC)

  We're thinking about this over on enwp: see here. Enterprisey (talk) 02:48, 16 August 2018 (UTC)

@Enterprisey: Thanks for notification. @Cohaf and Tiven2240: --Alaa :)..! 08:31, 17 August 2018 (UTC)

"admin accounts are stolen regularly"

How regularly? --bdijkstra (talk) 11:41, 15 August 2018 (UTC)

Example lists for en.wikipedia:

• Compromised admin accounts: en:Wikipedia:Former_administrators/reason/compromised
• Abused admin accounts: en:Wikipedia:Former_administrators/reason/for_cause

ToBeFree (talk) 19:48, 16 August 2018 (UTC)

• other wikis??--Cohaf (talk) 18:05, 20 August 2018 (UTC)

• Hmm, I don't think regularly is best word here, maybe sometimes is better to describe the real situation. For example on the Finnish Wikipedia no admin accounts were stolen in last 9 years when I've been active. And there was all this time 35-50 admins at same time. Stryn (talk) 18:17, 20 August 2018 (UTC)

• • That's exactly the point I'm trying to made, we need to have global data for this statement to be true. Currently only enwiki data are provided, making it seems like a local issue. The statement is slightly over-hyperbolic and I agree with "sometimes" as a better statement. --Cohaf (talk) 19:39, 20 August 2018 (UTC)

The point you have to remember is that enwiki is actually one of the most global projects here in many ways. It's used everywhere in the world, and has contributors from everywhere in the world. And break-ins there can find their way out across the WMF universe better than from any other project except maybe Commons and Meta. And in any case because of SUL vulnerability somewhere is vulnerability everywhere. StevenJ81 (talk) 22:06, 20 August 2018 (UTC)

with respect, can we have data from other wikis. This seems a little red herring as well as hastly generalisation. I am just commenting without any issue the process now as my homewiki IA policy is just completed. I sense a little slippery slope also. If data was better presented,I.e. how many admin accounts are compromised across how many wikis, consequences and collateral damage well listed out, it will be more convincing. my 2 cents.--Cohaf (talk) 21:45, 21 August 2018 (UTC)just to add, if enwiki is the breach, why not do IA for enwiki only?--Cohaf (talk) 18:37, 22 August 2018 (UTC)

I agree Cohaf here, that we should have data from other wikis; enwiki is not all Wikimedia projects, and actually Stryn's example of Finnish Wikipedia is a good one to be a counterexample. Sænmōsà 12:18, 22 August 2018 (UTC)

Migration period over

I deployed the change to remove JS editing rights from anyone except interface-admin (and some global groups) a few minutes ago. Thanks to everyone who helped to make the migration process smoother! If you see any unexpected problems, please ping me (ideally through a Phabricator task but talk page or IRC works too). --Tgr (talk) 11:28, 27 August 2018 (UTC)

Announcement (which I forgot to put up for translation, d'oh) was sent out: Creation of separate user group for editing sitewide CSS/JS/announcement 3 --Tgr (talk) 13:01, 27 August 2018 (UTC)

Footnote

Content page has a note: "On the top five wikis, 75% of admins have never edited CSS/JS; 92% of admins have almost never done so.". I don't doubt this is true but I couldn't find any related information in the provided link: [8]. Did I miss something there or is the link wrong? Rmhermen (talk) 14:43, 27 August 2018 (UTC)

You have to click “Show Older Changes” in the yellow bar below related objects listing for the anchor to work (i.e. the relevant comment to appear). —Tacsipacsi (talk) 15:00, 27 August 2018 (UTC)

Global interface editor request page

Now that wikis exist which don't (yet) have interface admins, should there be a request page here on Meta-Wiki for the global interface editors? (If it already exists, I couldn't find it.) --bdijkstra (talk) 15:03, 27 August 2018 (UTC)

Assuming that you are talking of a page where wikis without bureaucrats can ask to have certain editors made into interface administrators: I've seen such requests on Steward requests/Permissions. Jo-Jo Eumerus (talk, contributions) 05:58, 28 August 2018 (UTC)

That page is for permission request, and edit request belongs to SRM. — regards, Revi 06:10, 28 August 2018 (UTC)

For the time being, such request belong to Miscellaneous queue. — regards, Revi 06:09, 28 August 2018 (UTC)

My suggestion

I think it might be a good idea to revoke editing of JavaScript from the admin users and instead move it to a new user group which is the same as admin but has those same Superuser privileges that we will be revoking, or we could provide a set of individual groups like "Site Developer" or "Site Stylesheet Desginer / Page Designer / Artist" etc.

OR we can add a feature that temporarily revokes access to dangerous features after an admin has signed in from a new IP or location, or if their activity looks off. We could also make a voting system where different users or staff who are allowed to may vote on a change before it is put into effect, and we could highlight the changes to make it easier to read. Anyone who can read JavaScript or CSS can ensure that the site's code is always safe to run and doesn't contain anything NSFW in the page styles.

And one last thing: If you want, keep off-site backups of most/all of the site, maybe take 1 snapshot per day, and keep 3 days worth of that. Then when something is wrong you can respond in a timely manner, shut the site down to try and recover what you can, and everything else is pulled off of the backup drive once the server is back up.

Just a thought. Leave a comment please and let me know what you think. — The preceding unsigned comment was added by Someguywithamouse (talk)

@Someguywithamouse: It seems you've not followed what happened and didn't read the archives of this talkpage or the corresponding page.

What you're suggesting in your first paragraph is exactly what happened. Ability to edit sitewide .js/.css page and host of other rights have been removed from administrator usergroup and added to newly created interface administrators usergroup. Read the archives and the usergroup's description page –Ammarpad (talk) 13:32, 8 September 2018 (UTC)

• to be fair, this is getting TLDR area already but really that's the point of interface admins. To OP, that's the exact point this change is helping. --Cohaf (talk) 13:53, 8 September 2018 (UTC)

Alright I just read through it. I didn't see that by the time I posted it because it wasn't on the front page when I checked. --Someguywithamouse (talk) 17:39, 8 September 2018 (UTC)

French Wiktionary

I have now made a request for the number of interface administrators in all projects, and found out that in the French Wiktionary 27 users have this group, and a third of them do not even have 50 edits in last six months. All administrators were included in this group, except those who explicitly refused it (wikt:fr:Wiktionnaire:Wikidémie/juillet_2018#New_user_group_for_editing_sitewide_CSS/JS). I believe that such an approach is a disregard for security and makes the creation of this group meaningless. In this case, it is necessary either to oblige local bureaucrats not to include everyone in this group, or revoke this right from local bureaucrats.

List of projects with more than 10 interface admins
frwiktionary_p 27 ruwiki_p 17 hewiki_p 16 commonswiki_p 15 dewiki_p 15 srwiki_p 15 thwiki_p 15 frwiki_p 14 fiwiki_p 13 zhwiki_p 13 enwiki_p 12 wikidatawiki_p 12 metawiki_p 10

Also I would like to hear the opinion of JackPotte, who included all administrators into this group. — putnik 23:13, 20 October 2018 (UTC)

Hello, my point of view is that the administrators destitution of these rights in August, for which the community had already voted for since 2004, occurred at a rare time where some recent edits were not patrolled after one month, which is the limit before their autopatrolling (so we could have included unseen vandalisms). So I had wisely judged that it wasn't the time to open more than 27 votes, which would have "wasted" the few community free time, by making them revote for the elected ones. The new group is not meaningless because we had planned to separate the elections for it in the future, starting from August.

Moreover, I have never seen any security breach on any French Wiktionary account, so I consider this risk a lower priority than the distributed bot attack (with dozens of IPs in various ranges), against which we have already struggled on the site (and which is visible by patrolling).

Concerning the JavaScript maintenance, it's notorious that the gadgets are broken every year by the different MediaWiki migrations and that we are not enough skilled interface admins to manage these reparations on the French Wiktionary (I could find you the callings for reinforcement on the French Wikipedia, here on Meta, and the list of the broken scripts with the incidents durations which are huge). In addition, the number 27 doesn't seem to me to high in absolute, because if each of us spends one hour per day on the site, it would barely cover the 24 hours of a day to be reactive.

Finally I would like to expose the fact that destituting the local volunteer bureaucrats without their community consultation, for such a small matter, is not even an option I would have brought because it would be indubitably noxious to the site. Especially considering that I'm the only one to blame for these 27 ticked checkboxes after one week of concertation, and that I have never signed any subordination contract which would authorize this destitution if I wouldn't give spontaneously my free time to obey to someone about that (or in this case, guess an order implied by an informative message). No more than I didn't sign to a daily vandalism cleaning of my works, but it's admitted because their authors are irresponsible, and we don't sue them for now. What kind of organization would make pay the well-willing builders because it couldn't stop an hypothetical piracy of their accounts?

In conclusion, I'm asking for solutions from Meta, instead of repressions against the people who are miraculously running the greatest French dictionary of the world, with a professional quality for free. JackPotte (talk) 09:13, 21 October 2018 (UTC)

@JackPotte: I do not demand to re-vote for each administrator. But everyone who receives these right must understand the risks associated with it, and be prepared for them. If you grant the right to an administrator who has never edited JS/CSS and who not aware of new group, then he/she does not know what the threats may be. There is a huge gap between granting this right to every administrator who requested it, and just granting it to every administrator. You say that previously there were no problems with security in the French Wiktionary, but there were no such problems in other projects before, and only recently they have become quite widespread. At the same time, having included all administrators to this group, you made the French Wiktionary the most vulnerable to potential attacks from all Wikimedia projects. — putnik 15:51, 23 October 2018 (UTC)

OK, I got it. JackPotte (talk) 16:42, 23 October 2018 (UTC)