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

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 7 days and sections whose most recent comment is older than 30 days.

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)

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)

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)

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)

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)

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)

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)

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)