---

The purpose of this discussion is to create a process for the interface administrator right on the English Wikipedia. Please take a look at and give feedback on the proposals below. Thanks, Mz7 (talk) 23:02, 7 September 2018 (UTC)[reply]

Direct links to all proposals

1. #Original proposal
2. #Alternative / modified proposal: Grant for admins on request without process
   • #Alternative proposal with waiting period
3. #Alternative proposal, with 'indication of need'
4. #Alternative proposal, quick expiry only

Original proposal

I closed this section as "withdrawn" earlier today (see statement), but after reading the feedback at #Starting another one later, and workshopping, I've decided to re-open the discussion and restructure the RfC so that it encompasses all proposals below, not just the original one. The hope is that one of the alternative proposals will achieve consensus, and we won't have to completely start over. Mz7 (talk) 23:02, 7 September 2018 (UTC)[reply]

Should we adopt the following process regarding the interface administrator permission?

To be clear, this is the text that is currently on the main Wikipedia:Interface administrators page, authored primarily by Enterprisey in the section "Yet another proposed granting process" above. Mz7 (talk) 00:51, 2 September 2018 (UTC) Note: Per #Sysop_as_requirement, at this time only sysops can request this right.[reply]

Straw poll (Sept 2)

Support (Sept 2)

1. Support. After much informal discussion, I think we've refined a proposal to the point where we can make it formal. It's clear that as a community we need to pass something, and I think this is as good a starting point as any. As many others have explained before me, the intent of creating this permission was to improve the overall security of Wikimedia projects. Allowing all administrators access to JS and CSS pages that affect other users increases the risk of attackers compromising an account and running malicious code on another Wikipedia user's computer, which is a situation that has occurred on several occasions before. This proposal limits this access to individuals who have a need for the access.
   Previous proposals made the discussion time frame 24 hours and allowed requests to be rejected if any two administrators object, but many editors thought that was too short and that objections should be open to other editors, not just admins (see the section "RfC: Approving the current proposal"). Enterprisey authored the current proposal, which increases the discussion length to seven days and allows any editor to comment, the result to be determined by a bureaucrat (see the section "Yet another proposed granting process"). There was also debate as to whether we should host nominations at the newly created Wikipedia:Interface administrators' noticeboard or at WP:BN (see the section "Noticeboard?")—this proposal is going with the intadmin noticeboard idea.
   I hope this version of the proposal accommodates everyone's concerns. Again, it's clear we need to pass something at this point; if it needs tweaking (e.g. allowing non-admins to request the right, requiring a consensus of bureaucrats to grant instead of a single 'crat's discretion), we can tweak it in a future discussion. Mz7 (talk) 00:51, 2 September 2018 (UTC)[reply]
2. Support, with a note (to my peers that preferred creating a process for non-admins) that, as Mz7 said, we can always go back and modify the process to support that in the future. Enterprisey (talk!) 04:55, 2 September 2018 (UTC)[reply]
3. Support - happy with this for now. I think there may be circumstances where non-admins should be allowed to have access, but we can discuss that later if needed. -- Ajraddatz (talk) 05:21, 2 September 2018 (UTC)[reply]
4. Support as well. Like others here, I also think we should look into a process for non-admins once we get this proposal implemented. — AfroThundr ^{(u · t · c)} 06:20, 2 September 2018 (UTC)[reply]
5. Support and hope his will be extended to non admins who need it also. –Ammarpad (talk) 07:03, 2 September 2018 (UTC)[reply]
6. Support reasonable, though I'd prefer that the activity requirements be three or six months rather than twelve months (but making it a simple request at WP:BN to get back the rights if they were removed for activity), and 1 week seems rather unnecessarily long for discussion, though I suppose after the first few rounds new intadmins will be rare. Galobtter (pingó mió) 08:12, 2 September 2018 (UTC)[reply]
7. Support, sounds reasonable.--Ymblanter (talk) 08:30, 2 September 2018 (UTC)[reply]
8. Support sounds great Hhkohh (talk) 09:16, 2 September 2018 (UTC)[reply]
9. Support Seems logical, fair, and a reasonable process to me. ~Oshwah~^{(talk) (contribs)} 09:25, 2 September 2018 (UTC)[reply]
10. Support, and agree with comments above by Galobtter re activity and regaining the bit, and Ajraddatz on non-admins, Though as this is actually a species of admin, a RFIA would probably be the way to go. · · · Peter (Southwood) ^(talk): 13:34, 2 September 2018 (UTC)[reply]
11. Support looks good --Danski454 (talk) 16:30, 2 September 2018 (UTC)[reply]
12. Support. I personally would support reducing the time to 48 hours - I don't think a week-long discussion is really necessary and I don't want to make the process for granting requests like a second RfA. However, this proposal seems reasonable, and I hold no objections to getting this going and then making modifications from there.--SkyGazer 512 ^{Oh no, what did I do this time?} 16:42, 2 September 2018 (UTC)[reply]

    Note: I've supported the option below, as I do think it's better than this option. (#Alternative proposal with waiting period)--SkyGazer 512 ^{Oh no, what did I do this time?} 15:13, 18 September 2018 (UTC)[reply]

13. Support Per my comments above. 48-72h would be better, but, meh. ~ Amory (u • t • c) 18:07, 2 September 2018 (UTC)[reply]

    Expanding on my comment here rather than in the oppose section. Regarding the idea that this will be just another RfA process (JARfA?), I think the better analogy is WP:EFM: users with a demonstrated technical ability and use/need ask, and folks assess the need based on that. Quiet, technical, and like the edit filter, something most people don't interact with, so free from drama. Second, separating this ability from RfA can only make RfA better; it means the risk of any given sysop will be lowered, so while it won't make RfA perfect, a little less risk can only help. Thirdly, just because we've existed with a risky situation doesn't mean we should continue it; the risk is on par with a Bureaucrat account. Kevin expands below on just some of the things one could do with this ability, but there are more. Wikipedia is the 5th most visited site in the world, and I am consistently surprised we haven't had an incident where someone does something "for the lulz." ~ Amory (u • t • c) 12:03, 3 September 2018 (UTC)[reply]

14. Support not perfect but it gets things moving. --Rschen7754 18:08, 2 September 2018 (UTC)[reply]
15. Support – a clean and straightforward process. We need more of those. — JFG ^talk 21:35, 2 September 2018 (UTC)[reply]

    Extra remark: like other commenters, once this process is in place, and if at all possible technically, I'd like to see it open to tech-savvy non-admins. — JFG ^talk 21:42, 2 September 2018 (UTC)[reply]

16. Support Logical, efficient, and fair. ^Semi_Hypercube ✎ 22:20, 2 September 2018 (UTC)[reply]
17. Support for non-admins, but oppose for admins - see oppose below. WJBscribe (talk) 22:45, 2 September 2018 (UTC)[reply]
18. Support. I don't fully agree with all elements of this proposal, but I think something needs to be adopted that can be amended later. I don't agree with the community's decision that only admins should hold this permission, but as long as that decision is the consensus of the community, this policy is acceptable to me. At risk of violating BEANS, I suggest that some of the opposes may not quite appreciate the degree of access that IAdmin has – with a click or two, IAdmins can assign themselves CU/OS and mass-access highly sensitive data that way; violate the privacy of and run malicious code on the computer of every person who views Wikipedia (until discovered); run cryptocurrency mining rigs on Wikipedia readers' computers (this has happened on other WMF projects); etc. I personally doubt that this will turn IAdmin requests into an RfA 2.0 – just look at the ease with which all of the temporary IAdmins have been granted the permission above. I also think this process is insufficient for non-admins – I envision a proper RfA-like process for those who are trusted enough to pass an RfA but don't meet some of the other requirements (content creation/etc.). For admins, a lightweight noticeboard request and comment is appropriate in my view. Kevin (aka L235 · t · c) 23:34, 2 September 2018 (UTC)[reply]
19. Support to get something going. As far as the opposition comments so far, this was designed with "higher expectations for membership" (than administrator) in mind, and it is not the first time such a technical control has been implemented globally (for example bigdelete was removed from admins, not at the request of the local community - but unlike bigdelete the local community has been empowered to issue iadmin access to users). I'm not strongly opposed to the idea of non-admin iadmins - but would rather get this in to production before what I anticipate will be a much more contentious discussion for such a future amendment option. — xaosflux ^Talk 01:19, 3 September 2018 (UTC)[reply]
20. Support, but prefer the shorter procedures proposed below. We need to get ourselves out of the limbo of not being able to grant this permission formally. Deryck C. 11:55, 3 September 2018 (UTC)[reply]

    We can also do that by just allowing crats to assign the permission to any admin who asks, can't we? So why do you support this specific proposal? Regards SoWhy 13:45, 3 September 2018 (UTC)[reply]

    @SoWhy: What Deryck is trying to say is, that right now, there exists no process of granting this permission on a permanent basis, and that having no process at all is worse the having a flawed process. He's just supporting the fact that this group needs a process, and it needs it now. That's how I interpret his rationale.—CYBERPOWER (Chat) 13:54, 3 September 2018 (UTC)[reply]

    @Cyberpower678: That might be a possible interpretation but saying "I support proposal X because it creates a process" does not explain why you support X and not Y or Z. Hence my question. Regards SoWhy 15:20, 3 September 2018 (UTC)[reply]

    Where's Y and Z. I only see X, while the opposers are creating Y.—CYBERPOWER (Chat) 15:52, 3 September 2018 (UTC)[reply]

    @SoWhy: I would much rather crats simply granted interface-administrator to any admin who asked for it at their own discretion, but User:Xaosflux has refused on behalf of crats to even grant the permission temporarily [1] [2] unless there is a community mandate. So I am willing to support any proposal that instructs crats to grant interface-administrator to current admins. If anyone drafts a simpler proposal I am happy to support that as well, like how I have supported all the draft proposals above. Deryck C. 16:16, 3 September 2018 (UTC)[reply]

    @Deryck Chan: just to note, I am the author of the temporary access processes currently running on this page. If the community wants to approve "must grant to any sysop at anytime without question" then you don't really need bureaucrats involved: start the us-vs-them fight with the developer team by requesting a configuration change to allow admins to addself/removeself from this group (though I expect it will end up at meta:Limits to configuration changes. — xaosflux ^Talk 16:30, 3 September 2018 (UTC)[reply]

    Oh stop it, there is no "us vs them" Back to the point, there are two issues here. First, everybody who was a sysop as of last month had the rights of what is now an interface administrator, so I believe these users should be allowed to claim their permission through an expedited process. Second, we do have a number of permissions such as rollback and filemover and where we trust individual admins with full discretion to grant rights to any user, subject to policy but not community discussion; I think the process for bureaucrats to grant interface administrator rights should be kept simple in a similar vein. Deryck C. 17:22, 3 September 2018 (UTC)[reply]

21. Support no obvious issues that would cause me to prevent the intadmin pool from being expanded at this time. Anything else can be hammered out later. --SarekOfVulcan (talk) 16:08, 3 September 2018 (UTC)[reply]
22. Support addresses my concerns raised in the above discussions. Amory's comment above on how this is different from an RFA clone aleviated most of my concerns on that front. I am strongly opposed to giving this ability to all admins which seems to be the main alternative offered by the oppose rationales. This is not a situation to wait around for problems to appear if we gave it to all admins: compromised or malicious accounts can run malicious code on readers' computers and threatens data or economic loss for readers that we cannot fix. That we've been lucky so far is no reason to keep doing it. This bit should be given to as few people as possible, and only for as long as they continue to use it. I am open to non-admins going throught this same process for the bit but appreciate the concerns raised by Kevin. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 17:26, 3 September 2018 (UTC)[reply]
23. Support: I don't understand why people are opposing. As Kevin explains, the risks of this right are enormous so removing it from admin privileges was both the right move and not something we have authority to overturn. As Deryck Chan says, we need a process imminently so that we have at least a sizeable quantity of iadmins while we squabble over the precise details. I would probably support a slightly more lax procedure but opposing doesn't argue for a less strict procedure; it just stops any procedure from being put into practice. I also think fears this would become RfA2 are unwarranted, as this is a very technical area that I wouldn't expect many users without substantial technical knowledge to watch closely. — Bilorv_(c)(talk) 19:11, 3 September 2018 (UTC)[reply]
24. Support Admins need to stop seeing this as the masses rising with pitchforks with some kind of RfA sequel (maybe we are :'/), but more importantly, it's as Anomie said above. We're gravely underestimating what a compromised here-there might do. I doubt this proposal will be opened up to non-admins in the near future, every unbundling has an impressive amount of resistance; but the point about security questions is undebatable. --QEDK (後 ☕ 桜) 19:55, 3 September 2018 (UTC)[reply]

    Support: It's not a perfect solution, but it's definitely a step in the right direction. I need more time to thoroughly review this after reading more of those who opposed. Neovu79 (talk) 08:43, 4 September 2018 (UTC)[reply]

25. Support Better is the enemy of good enough. --Ahecht (TALK
    PAGE) 15:25, 4 September 2018 (UTC)[reply]
26. Support - with even more conditions. IAs should be required to identify with the WMF. My concerns and reasons are noted below, under Oppose #1 by Courcelles. - wolf 18:58, 4 September 2018 (UTC)[reply]

    I would strongly oppose identification with the WMF as a requirement. Bureaucrats, those granting the right, are not required to identify. That aside, in all the time in which all administrators held this right, has it ever been used maliciously? Bottom line: the fewer roles that require identification to the WMF, the better; anonymity should be respected unless, quite frankly, the WMF forces those wishing to serve in a certain capacity to identify. — Godsy ^(TALK_CONT) 19:26, 4 September 2018 (UTC)[reply]

    "...has [IA] ever been used maliciously?" - Not that I know of. Can you say for certain is hasn't? If not, we should do everything we can to ensure there is never a first time. But should that occur, we should be able to hold those responsible for the abuse accountable. That might require more than a simple desysop and a block. That's where identification comes in. Perhaps every anonymous user with access to this right should identify, considering the kind of access we're talking about here. - wolf 22:05, 4 September 2018 (UTC)[reply]

27. Support this looks fair enough. This process isn't RfA, the bureaucrat isn't being asked to assess the consensus of the discussion. It just provides people with an opportunity to comment on the request. I don't think this should be given to all admins either. Admins who don't have the relevant technical experience shouldn't have the right. Hut 8.5 21:23, 4 September 2018 (UTC)[reply]

    It's not RfA v.2 indeed, but still a bureaucrat has to assess consensus of the commenters. Otherwise, you're suggesting that, even if the consensus of the commenters shows clearly the user is not suitable for the right, the bureaucrat can just disregard that and assign the permission since he "...isn't being asked to assess the consensus of the discussion.". –Ammarpad (talk) 07:17, 5 September 2018 (UTC)[reply]

    I'm suggesting it comes down to a judgement call by a bureaucrat. Obviously the bureaucrat will read the comments and take them into account when making the judgement call, but it is still down to the judgement of the bureaucrat and not the commenters. Hut 8.5 19:59, 5 September 2018 (UTC)[reply]

28. Support I've said what I needed to say many times on this page, but in summary: Demonstrated need is the biggest requirement, not trust (admins already have proven that), and we need time to evaluate that someone meets this criteria. A week of waiting seems trivial for someone who doesn't regularly edit site/user JS/CSS (most of these accounts already have access!). I'd even be okay with 4 or 5 days, but definitely need more than 24 hours which was the original proposal. — MusikAnimal ^talk 03:53, 5 September 2018 (UTC)[reply]
29. Support seems fair. Dreamy Jazz 🎷 ^{talk to me | my contributions} 18:44, 8 September 2018 (UTC)[reply]
30. Support Could be better, but this isn't bad. I think a shorter discussion time would be bad, a week is about right since it allows people who only edit on certain days of the week to be able to have a say. Ideally it wouldn't be arbitrarily limited to admins and there would be some provision for removing it from someone who remains active in other areas but hasn't made use of the right itself in a while (as in some of the counterproposals below). Anomie⚔ 00:11, 9 September 2018 (UTC)[reply]
31. Support. Being totally open is a nice idea but the internet is no longer nice (for example, an admin was detained by state authorities until the admin divulged their password). Johnuniq (talk) 01:40, 9 September 2018 (UTC)[reply]
32. Support. I'm not crazy about another RfA-like process, but I am willing to trust bureaucrats to ignore irrelevant material and make a sound decision. If process becomes problematic, we can revisit.--agr (talk) 01:59, 9 September 2018 (UTC)[reply]
33. Support because of two very useful security measures: Automatic removal after inactivity, and demonstration of experience. This reduces the amount of unnecessary "hacking targets" and adds a level of community scrutiny for the dangerous privilege. A positive side-effect is that anyone with the rights will be aware of the enormous amount of trust and responsibility pressing on their shoulders. ~ ToBeFree (talk) 18:09, 9 September 2018 (UTC)[reply]
34. Support. Looks fair and reasonable. Anarchyte (work | talk) 00:00, 10 September 2018 (UTC)[reply]
35. Support. Seems to be the best among the lot. —Gazoth (talk) 03:39, 10 September 2018 (UTC)[reply]
36. Support. It invites community participation, it invites the basic question of use/competence (filtering out "hat collectors"), and it's fairly lightweight. I doubt it will needlessly produce IAs, and it includes a balanced timeline for removal via inactivity, so minimizing the attack surface further seems needless to me. I'd support a two-factor authentication requirement as well once some of the UX limitations with that are hammered out, but we can always amend the process later. This isn't "perfect", but it's sane and balanced. ((Nihiltres |talk |edits)) 16:19, 17 September 2018 (UTC)[reply]
37. Support To allow only those administrators who really need the user right. Anatoliatheo (talk) 09:07, 21 September 2018 (UTC)[reply]

Oppose (Sept 2)

Very weak oppose because of removal criterion #4, which appears to imply that interface-administrator is necessarily a position of higher trust than sysop. I can imagine an emerging troop of editors who hold templateeditor + interface-administrator but not sysop because they're technically highly competent to be trusted to edit important code, but not sufficiently diplomatically talented to be trusted with the delete and block buttons. #4 would also tie the hands of AN and ArbCom, preventing them from letting a user continue as interface-administrator but revoking sysop, which is something the community might like to try at some point in the future. Deryck C. 21:18, 2 September 2018 (UTC)[reply]

Though another discussion was closed which requires all applicants of the permission to be an admin to begin with. So that's not really debatable.—CYBERPOWER (Chat) 22:15, 2 September 2018 (UTC)[reply]

The proposed policy is a starting point more than it is a final policy and is more to get things going for those admins who want the tool back (even if they didn't want to take Xaosflux up on the opportunity to have the interim tool). There are a number of questions like "non-admins" that I think are reasonable, but I think there is a significant divide on that question that we should talk about it separately to "give the ones who knew how to use it before and had the permission before", which is the current proposal. --Izno (talk) 23:46, 2 September 2018 (UTC)[reply]

Point taken. Switch to support for now since it's better to have a granting policy than not to have one. Deryck C. 11:54, 3 September 2018 (UTC)[reply]

1. Far too complicated a process for my taste, which is to just give it to all admins who ask. Courcelles (talk) 21:37, 2 September 2018 (UTC)[reply]

   The main objection to this approach when we discussed it before is that there will inevitably be administrators who ask for the right but never use it. As interface administrators essentially have the ability to run code on another user's computer, the intent of the process was to limit the size of the user group only to those that truly need it. The worry is that by opening it up to "any admin that asks", we risk inflating the user group in the long run and ending up with the same security problem we did before. Mz7 (talk) 23:37, 2 September 2018 (UTC)[reply]

   "...just give it to all admins who ask.". Sorry, but no. Make that hell no. We have, what? About 1200 admins? Do you trust every one of them right now? Every one? Including the ones that got the bit back in the days when it was given to anyone who asked for it? (RfAs passed in a couple days with a !vote of 6-0... not exactly "running a gauntlet"). What about admins that have shown some truly disturbing behaviour? Admins that have had their bit taken and returned? More than once? Would you trust every one of them with say, your banking info? But you would allow any one of them fuck around with your computer? "The ability to edit CSS/JS that is executed in other users' browsers is very powerful and potentially dangerous in the hands of a malicious user" Sorry, but no. We have many good admins, some great admins in fact. But just becasue they passed an RfA doesn't mean you truly know them, and it certainly doesn't mean you can trust all of them with that particular type of access. (and yes, I know these comments will be unpopular in some circles) - wolf 21:40, 3 September 2018 (UTC)[reply]

   I don't think the issue is trust... it's attack surface. I can't count how many times this has been reiterated on this page. Granting access upon request defeats the purpose. — MusikAnimal ^talk 03:55, 5 September 2018 (UTC)[reply]

2. I agree with Courcelles above. I'm really not crazy about following RFA's format either as I mentioned in the comments below. SQL^{Query me!} 21:51, 2 September 2018 (UTC)[reply]

   It only follows RFA format in the length of time. Maybe the policy should make it clearer that it is not RFA 2 and that the only judgement in the request for IA is whether the admin has technical trust rather than just the social trust garnered at RFA? --Izno (talk) 23:46, 2 September 2018 (UTC)[reply]

   There is an encouragement to keep it to technical ability, but no requirement to do so. I'm not sure what to say if you don't think that there are strong parallels here to RFA. The process described sounds identical to me. SQL^{Query me!} 00:31, 3 September 2018 (UTC)[reply]

   I get that, though I would say the intent is rather to mirror the process for WP:EFM rather than RfA. ~ Amory (u • t • c) 01:14, 3 September 2018 (UTC)[reply]

3. Oppose per Courcelles. I don't see why any admin who needs this cannot just have it, as they always have done so. I don't see the need for non-admins to have it either. Aiken D 22:19, 2 September 2018 (UTC)[reply]
4. Oppose per Courcelles. I'm OK with this for non-admins requesting the right, but not for admins. This used to be something all admins could do, there was no enwiki consensus to remove this ability from admins, and it seems to me on that basis any admin in good standing should be able to request restoration of the ability to edit these pages. WJBscribe (talk) 22:46, 2 September 2018 (UTC)[reply]

   Regarding "all admins had this and now don't", realistically, if user scripts had been built today rather than 15 years ago (if they were built at all!), this user right would have been required from the start. Most admins neither need nor want this. I don't think it's unreasonable to ask admins to have some technical skill and to Know What They Are Doing; as it happens, most don't (and most probably have a reasonable approach on the point). --Izno (talk) 23:46, 2 September 2018 (UTC)[reply]

   On the other had, should we approve this proposal, that would essentially be a consensus that not all sysops should have it. At any rate, giving IA to any sysop and using the above process for non-sysops would have the opposite effect of the intent behind the change — it'd open up the right to edit these pages to more users, not fewer, creating a larger threat. ~ Amory (u • t • c) 01:14, 3 September 2018 (UTC)[reply]

   That's assuming all admins request this permission. I trust admins to only request it if they have a genuine need for it, which will be a small subset of the total number of admins. WJBscribe (talk) 23:56, 3 September 2018 (UTC)[reply]

   @WJBscribe: kind of like how they only hold on to sysop if they have a genuine need.... From last months inactivity report of admins that "kept" that access see 1, 2, 3, 4, 5 examples of actual behavior. — xaosflux ^Talk 00:04, 4 September 2018 (UTC)[reply]

   Actually, I more had in mind edit filters as a comparison. It's not like every admin adds that for the sake of it... WJBscribe (talk) 11:14, 4 September 2018 (UTC)[reply]

5. Like the previous four above me, it seems like an invitation for RFA round two. I'm fine with this process for those who are not admins, but admins have already had this ability and it should be readily given to them. Killiondude (talk) 23:13, 2 September 2018 (UTC)[reply]

   Re: admins have already had this ability, the point is that this ability was recently removed from all admins for security reasons, and now it can be added back to admins who request it and demonstrate a need. It would be unfair to give it more-or-less automatically to newly-minted admins, while the corps of current admins would have to request it specifically. — JFG ^talk 23:50, 2 September 2018 (UTC)[reply]

   Yes, I am aware of the background and proposal. I like Izno's thought above in reply to SQL. Killiondude (talk) 00:16, 3 September 2018 (UTC)[reply]

   I don't see this as necessarily a bad thing, there are quite a few admins who are not trusted by the community, or for whom this would essentially be their first RFA. --Rschen7754 02:34, 3 September 2018 (UTC)[reply]

6. Oppose - Per Courcelles and WJBscribe. - FlightTime (open channel) 23:47, 2 September 2018 (UTC)[reply]
7. Oppose Just make it the same as for the AbuseFilter. Most admins have never been vetted to be allowed to edit this, most admins are not vettted for the mediawiki namespace. This results in just another RfA-type process, frustrating the hell out of people, and capable people not getting access because some people have axes to grind, or because you have some broken mops in the cupboard. This is a slippery slope towards limiting access to the MediaWiki namespace or module namespace. We only need clear process for when the right was removed from you, that you are not allowed to self-reinstate. --Dirk Beetstra ^{T C} 03:38, 3 September 2018 (UTC)[reply]

   In addition to my earlier post (thinking about it a bit further), I will move to Strongly Oppose - I think that ALL admins should standard have this bit enabled (or at the very least enable it at will per my original comment), and only have it removed when they have grossly misused or abused it (where re-instating the right without discussion would be abuse of rights). The reason for that is that when someone with the bit does break the wiki I expect a large editor base to be able to revert to an earlier version, not just the few who have been specifically granted the bit. Admins have had this right for a long time, and most stay away from editing (as they stay away from the MediaWiki namespace) because they know of themselves that they do not have the capability to work in that area and that if they would break something there that the community would at least WP:TROUT them (I've seen enough blacklist requests of admins that knew that they could but did not want to because they were afraid to break something). The risk of them breaking something is minimal, and is outweighed by the need to quickly revert. --Dirk Beetstra ^{T C} 07:26, 3 September 2018 (UTC)[reply]

   The right was removed because it posed a demonstrable security risk to the Wikimedia projects. It’s not just about whether we can trust administrators not to misuse this ability, it’s about reducing the pool of accounts that attackers can compromise to run malicious code on someone else’s computer. To return the permission to all adminisrators would reintroduce the security flaw that was identified by the technical community. Mz7 (talk) 07:50, 3 September 2018 (UTC)[reply]

   @Mz7: Absolutely NOT convincing at all, and more a reason to strongest possible oppose to NOT hand it out to all administrators.  1) In all the years that administrators had this ability no account was compromised and subsequently used to insert malicious code.  2) even if we hand this out to a sub-significant number of accounts, those would be the accounts to hack (do you really think that a hacker who wants to exploit this would be so stupid as to try to hack a random admin account?).  3) if one of the now granted iadmin bit accounts is being hacked and that account starts to damage Wikipedia, there is only a small number of other accounts that can repair the situation (and blocking the compromised account is obviously not enough, admins cannot undo).  (and 4) there is no reason to hammer all opposers of this process as if we do not know why it was taken out).  --Dirk Beetstra ^{T C} 08:15, 3 September 2018 (UTC)[reply]

   While I'm on the oppose side for this specific RFC, I want to make sure I point out this threat is absolutely not imaginary, and has actually happened. example SQL^{Query me!} 08:41, 3 September 2018 (UTC)[reply]

   I know, the same goes for the not-imaginary f*ck up on that could occur on the MediaWiki namespace: once a mistaken edit on the meta spam blacklist resulted in all domains with a 't' to be blacklisted on all 700+ MediaWiki wikis (and many outside). The solution was a quick revert and then solve the problem, but that needs a significant pool of editors that can do said revert. Realizing where the mistaken edit (which complex broken regex?) took place may take time (there was significant time between the blacklisting and de-blacklisting, the blacklisting admin may already have been in bed).

   The paradox is difficult to solve - you want a small pool of editors that possibly could get hacked, but you want a significant pool of editors that can solve a problem in case one of the editors does get hacked, or one of the editors screws up. Or you have to completely take the right. --Dirk Beetstra ^{T C} 08:54, 3 September 2018 (UTC)[reply]

   I'm with ya there, and I probably placed my reply in a bad place. I just wanted to make sure we were all aware that this isn't a 'what if' situation. SQL^{Query me!} 09:13, 3 September 2018 (UTC)[reply]

   I think I'm just not convinced that anything but total removal of 'our' rights to edit the interface is going to solve this issue. We have about 300 active administrators here, but I think a 'healthy base' of interface admins would probably amount to at least half of that. You don't want a hacked piece of code to stay for anything more than 2-3 minutes, and a broken piece of software not more than about 30 minutes. With our current base of 6 interface admins I doubt that a smart choice of hacking an account (which leaves 5) of which 2 others are also asleep (assuming that those three are on the same side of the planet), 1 having dinner, and 1 doing something important at work .. that may be quite a bit longer. --Dirk Beetstra ^{T C} 10:17, 3 September 2018 (UTC)[reply]

   Meh - if there is a hacked piece of code, then that's enough of an emergency that the 30 or so pretty active stewards can act too and so can the crats. Granted, the amount should probably be more like ~15 or something, not 6, but I don't think 150 interface admins are needed. Galobtter (pingó mió) 10:25, 3 September 2018 (UTC)[reply]

   I think a solid base of 20 or so should be able to handle requests in a fairly timely fashion, and any incidental changes that arise. I'll add too that I think the worry is less about an accidental screw up and more that someone malicious can do something that would require devs to fix. Interface admins won't necessarily be able to undo it, but having fewer accounts capable of doing something like that reduces the threat. ~  Amory (u • t • c) 14:26, 3 September 2018 (UTC)[reply]

   (edit conflict) If the risk is really so low that it is always quickly resolved, then there was no much reason to separate it, and to minimize the number of people who could possibly break it in the first place.  Still, I am also fine with the bureaucrats just handing out the bits 'at their own discretion' to people who can reasonably show that they need it. --Dirk Beetstra ^{T C} 14:32, 3 September 2018 (UTC)[reply]

   In reply to User:Xaosflux: I also would not be opposed to having non-admins this particular bit, but that I think that that does need a separate process.  --Dirk Beetstra ^{T C} 07:26, 3 September 2018 (UTC)[reply]

   This has repeatedly been said on this page (not just by me), but the issue is not trust, it's a matter of security, to reduce the attack surface (accounts that could be compromised in order to cause damage). AbuseFilter is child's play compared to what JavaScript can do. Can you use edit filters for monetary gain, to cause permanent damage to the site, to people's privacy, and consequently even potentially endangering people's lives? Of course not. Can you with JavaScript? Yes. No, it hasn't happened on enwiki yet, but it has elsewhere, and we shouldn't wait for it to happen here and then decide to change our ways. — MusikAnimal ^talk 04:34, 5 September 2018 (UTC)[reply]

   @MusikAnimal: OK, we are now getting seriously in WP:BEANS territory, but this is implementing a false security. Again, whether we have 1, 10, or 100 editors with access to iAdmin, it does not matter except for maybe the amount of effort it takes to find someone with access to attack that is not having sufficient security levels (and if it is a proper hacker, they are not stupid). But still, my main problem is with the procedure of how to get the bit when you need it. --Dirk Beetstra ^{T C} 08:10, 5 September 2018 (UTC)[reply]

   Interface admin was carefully thought out by the technical community, including the security experts (not me :). It's the best we have right now. All I can say is a smaller pool of accounts to hack definitely helps, even if it's easy to see which accounts those are. — MusikAnimal ^talk 16:21, 5 September 2018 (UTC)[reply]

8. Oppose Per Courcelles. Further, I still haven't understood when or where did the community gain consensus to remove this right from administrators. Pending that, the default should be what Courcelles or Rob suggests – that administrators should be granted this right on request. Lourdes 05:02, 3 September 2018 (UTC)[reply]

   The right was removed from administrators on all Wikimedia projects as a consensus of the Wikimedia technical community, not by local projects, because it posed a significant computer security flaw. Mz7 (talk) 07:50, 3 September 2018 (UTC)[reply]

9. Oppose per above. Admins were able to do this for years and no one blew up the wiki—those who shouldn't be screwing with something tend to know they shouldn't do that, and don't. If needed even occasionally or just for a few specific tasks, an admin should be able to request the right and just have it granted. They've already demonstrated community trust by passing RfA. Besides, given how people currently treat the RfA process and those who dare step into it, I don't want to make any more processes that are anything at all like it. Seraphimblade ^{Talk to me} 05:43, 3 September 2018 (UTC)[reply]
10. Oppose - Per Courcelles and WJBscribe. Limiting the access is probably a good idea to prevent mistakes (I don't need or want the access, I have no interest) but any admin that requests it should automatically get it. This shouldn't be a "super admin" bit. I would even support admin being able to enable and disable the bit themselves, like abuse filter. I don't have a problem if the default state is "not enabled", but admin do not need Crats to decide if they are technically capable as we've already walked through the gauntlet and the community has decided our judgement can be trusted. Having the Crats decide who can and can't obtain the bit would be putting a new duty on Crats that I'm not convinced is a good idea. I'm neutral as to non-admin obtaining the bit, and see little harm, but there would need to be some process of community approval rather than just Crat approval, imho. Dennis Brown - 2¢ 11:48, 3 September 2018 (UTC)[reply]
11. Oppose per Courcelles and Dennis Brown. Admins are already trusted users and thus should be able to request any such right that allows them to improve the wiki without a new RFA-style process for creating "admin+" or "super admins" as Dennis aptly puts it. IA should be the same as the edit filter: Available when needed but not assigned to the majority of admins. That said, I personally still believe the whole IA change misguided anyway because clearly the last 15+ years have demonstrated the risks are minimal. But if we have to have this change, at least don't force admins to jump through hoops to get it. Regards SoWhy 13:42, 3 September 2018 (UTC)[reply]
12. Oppose this talk page is a relative backwater. I still support having a 48 hour hold at BN, which is much more watched and transparent (and less likely for notices to be ignored.) That, and the fact that even if this were grant on demand means that we’d still have something like a 99% reduction in users with access means the security concerns here are really overstated: any restrictions here are good. The question of how good is relative and needs to be balanced with community usefulness. The safest would be to let no one have it, but it also wouldn’t be useful then. TonyBallioni (talk) 15:45, 3 September 2018 (UTC)[reply]

    @TonyBallioni: as far as visibility goes, there are just over 1000 watchers at BN, this proposal requires notices at AN (~4500 watchers) and VPT (~3100 watchers). — xaosflux ^Talk 16:09, 3 September 2018 (UTC)[reply]

    @Xaosflux: it’s the noise to request ratio. Any post at BN will have significantly more attention than a post at VPT/AN because things don’t get posted there often. Also, I generally have misgivings about letting people who are primarily technical contributors have control over technical things that impact other users: there is often a real disconnect, and having it not be as visible to the entire community runs the risk that we’d have artificially higher standards than the community as a whole wants. TonyBallioni (talk) 16:22, 3 September 2018 (UTC)[reply]

    @TonyBallioni: I got the impression from some of the earlier discussion that general notifications aren't useful - but this could easily be integrated to T:CENT or MediaWiki:Watchlist-messages. Alternatively, adding WP:BN to the places to notify could be added in without otherwise cluttering up BN. — xaosflux ^Talk 16:33, 3 September 2018 (UTC)[reply]

13. Oppose anything beyond a hold and a clearly-stated need. Specifically, oppose requiring admins to go through an RFA-like process just to get access to do something the community never even agreed to remove from their toolset. I understand restricting access to this, but a hold and need accomplishes that. ~ Rob₁₃^Talk 16:39, 3 September 2018 (UTC)[reply]

    @BU Rob13: what sort of potential opposition are you trying to say should be invalid? It should be trivial for 'crats to apply "less weight" to opposition along the lines of "I don't like BU Rob13", but I don't think we should disregard something like "Oppose, BU Rob13 was admonished by ArbCom last week for edit warring in the MediaWiki space". — xaosflux ^Talk 16:50, 3 September 2018 (UTC)[reply]

    I'm saying anything along the lines of oppositions based on lack of trust should be invalid. If we genuinely don't trust an admin to be able to use this, they shouldn't be an admin. I trust admins not to mess with this/request this if they aren't technically able. I trust them not to edit war, etc. ~ Rob₁₃^Talk 19:17, 3 September 2018 (UTC)[reply]

14. Oppose This is a technical right and yet, unlike other technical rights, this is being reserved for admins who can have it at the asking so long as there isn't political resistance from the hoi polloi. If WMF, in the depths of their ignorance, will not simply allow admins to edit JS/CSS, then we need a thought-out selection process for technical editors or we're just passing out candy. Chris Troutman (talk) 17:53, 3 September 2018 (UTC)[reply]
15. Oppose - Given the result of the section above requiring Sysop, we really only need to answer three questions when evaluating an IA request: Has anything come up since the RFA that massively changes the trust the community has placed in them? Are we confident that the same person is in control of the account? Does the user have the technical skill to evaluate complex JS/CSS to ensure it does what it is expected to do and is not malicious? Those are the only germane questions. The solution, therefore is not to create another pseudo-RfA, and subject users to another broken inquisition-like process where anything and everything should be dredged up. Instead the discussion should be shorter, lasting only 2-3 days, and advertised only to the boards that can speak to those questions (VPT and BN), and not to broader community boards, where people will bring up points unrelated to the questions above. We also need an aggressive clerking system to filter out and strike comments that are not very explicitly germane to one of the above questions. This proposal results in a new RfA being formed that will ultimately discourage qualified admins from applying. (On a sidenote, it is a perfect application process for non-admins if sysop as a requirement gets overturned. I'd hate to force someone like Enterprisey to go through an RFA just so they can apply for this. Tazerdadog (talk) 19:55, 3 September 2018 (UTC)[reply]
16. Oppose This should be looked at by bureaucrats and nothing more. Give the right to them if they ask unless there is a history of problematic usage of the right. If you want non-admins to have this right, then set up a different process. Nihlus 21:19, 3 September 2018 (UTC)[reply]
17. Oppose - Bureaucrats should grant this as necessary. No need to create another RfA-like process. — Godsy ^(TALK_CONT) 03:22, 4 September 2018 (UTC)[reply]
18. Oppose per WJBScribe. The need to be able to understand js/css script is unnecessary. Can I write code? No. Can I read an edit request on a js/css talk page, confirm that the person making the request understands what they are doing and that there is consensus to make the change? Yes. That is all that is required, and therefore the permission should be given to all admins on request. (Also it would allow me to change css/js on my alternative account without the need to log in separately.) Voice of Clam (formerly Optimist on the run) (talk) 14:06, 4 September 2018 (UTC)[reply]
19. Oppose per Voice of Clam, TonyBallioni, and SoWhy. I can see this quickly devolving into RfA 2.0, we don't need that. Supporting the alt proposal below. — Insertcleverphrasehere ^{(or here)} 00:28, 5 September 2018 (UTC)[reply]
20. Oppose Making people jump through hoops again just to do something that they had been able to do for years is downright silly. It should be a simple process, not another vote. OhanaUnited^{Talk page} 01:04, 5 September 2018 (UTC)[reply]
21. Oppose In general, I don't think that the RfX processes here are really set up to check someone's technical and security skills, they focus on social/policy skills. The former are more important than the latter for Interface admins while the latter get more focus in regular admins. Maybe I'd agree with an RfA-like process for non-admin Interface admins but not in general. Jo-Jo Eumerus (talk, contributions) 15:25, 5 September 2018 (UTC)[reply]
22. Oppose per Courcelles and WJBscribe, and the above in general—I think the bureaucrats can, and should, handle this. Ale_Jrb^talk 14:28, 9 September 2018 (UTC)[reply]

    Addendum: I think it's a good idea to note, regarding security, that the only part of this proposal that meaningfully improves security is the one week delay—and that is already pointlessly long. If someone doesn't notice their account is fully compromised after 48 hours, I'm unconvinced that an extra couple of days will make a difference. A technical restriction, such as "must have had 2FA enabled for >1 month", could serve a useful purpose. However, if an already-trusted account (which basically all sysops fall into by definition) is compromised, then the need to post here for an RfA-style process as opposed to a bureaucrat request is irrelevant, as the decision will be de facto based on the account history regardless. If it's instead a question of who is trusted to make the changes, then I'm also opposed to a second version of RfA for granting technical rights, but it's also no longer reasonable to claim that the main purpose is improving site security. Ale_Jrb^talk 21:56, 11 September 2018 (UTC)[reply]

23. Oppose Does looks like RfA 2.0. Give it to only those who are truly interested. Kraose (talk) 07:35, 10 September 2018 (UTC)[reply]
24. Oppose, far too bureaucratic and inefficient. WaggersTALK 11:48, 10 September 2018 (UTC)[reply]
25. Oppose per Courcelles and WJBscribe. I don't think turning this into another RfX process is good. Yes, this was taken away for security reasons, but I think the security concerns were mostly unfounded. I think any admin should be able to get this tool if requested, and I think it should be similar to the abuse filter tool where they can turn on the bit themselves. If people really want a "check and balance" I'd be fine with having it required that crats twiddle the bit. I don't know that it would make any difference either way, though. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 20:25, 11 September 2018 (UTC)[reply]
26. Oppose Well-intentioned but too bureaucratic a process. If we can't trust admins to not intentionally obtain and misuse the interface administrator permission, they cannot be trusted to not jump through the hoops put up by this process and then do the same either. Restricting the permission to admins who self-certify that they know what they are doing and that they need access to the tools suffices to limit unintentional misuse. And that frankly is the best we can hope to do unless we decide to go the whole-hog and require revelation of real-life identities and signing of legally-enforceable agreements from holders of these permissions. Abecedare (talk) 21:49, 11 September 2018 (UTC)[reply]
27. Oppose per Nihonjoe and Abedecare. Too much bureaucracy. De728631 (talk) 01:11, 12 September 2018 (UTC)[reply]
28. Oppose Credit admins with the intelligence to ask for it if they need it, and are comfortable in using it. Stephen 02:19, 12 September 2018 (UTC)[reply]
29. Oppose, I appreciate the intent behind reducing potential attack surfaces, but the proposed RFX process is unnecessarily bureaucratic and encourages "hat collecting." Titoxd^(?!?) 02:26, 12 September 2018 (UTC)[reply]

Discussion (Sept 2)

• I figured, since #Yet another proposed granting process seems to have a good amount of support, now was a good a time as any to start the formal RfC. If you think I was too hasty and we still need to discuss this informally, I would be happy to collapse this section and deactivate the ((rfc)) template. Mz7 (talk) 00:51, 2 September 2018 (UTC)[reply]
• Is the presumption that an administrator should receive this user right unless there is a compelling reason they should not, or does there need to be a strong consensus for handing out this user right? That is unclear from the proposal. ~ Rob₁₃^Talk 03:09, 2 September 2018 (UTC)[reply]

  For reference, the RfA header has At the end of the discussion period, a bureaucrat will review the discussion to see whether there is a consensus for promotion. - As far as "presumptions" go the tech guidance was that this should have higher expectations for membership - so I'd expect that a consensus would need to emerge for actual support, and that the lack of such consensus would not be sufficient. — xaosflux ^Talk 03:18, 2 September 2018 (UTC)[reply]

  I agree with xaosflux's interpretation. · · · Peter (Southwood) ^(talk): 13:27, 2 September 2018 (UTC)[reply]

• Derp, I just closed a discussion further up where the right is requested at the WP:BN. The section is #Sysop as requirement.—CYBERPOWER (Chat) 16:55, 2 September 2018 (UTC)[reply]

  @Cyberpower678: I think the venue is more flexible and the more important part of that section was establishing the prerequisite adminship component, thoughts?. — xaosflux ^Talk 17:03, 2 September 2018 (UTC)[reply]

  True.—CYBERPOWER (Chat) 17:36, 2 September 2018 (UTC)[reply]

  I don't think there's any basis for requiring 6 months to pass before the issue of whether or not adminship is required to request this right is revisited. I think imposing such a limit lies outsides the remit of the person closing a discussion. If consensus changes sooner, so be it... WJBscribe (talk) 22:43, 2 September 2018 (UTC)[reply]

  6 months was not a hard restriction. It's simply advisory so the more important issues of establishing process for requesting are set up first. But knowing enwiki, that can take forever.—CYBERPOWER (Chat) 15:57, 3 September 2018 (UTC)[reply]

• I made this edit today regarding whether there should be consensus to provide the tool... I'm happy to make it a separate heading under this discussion or in a separate discussion on what kind of consensus (no, not % range like with RFA) should be expected out of the community consult for a bureau to promote. Someone can revert me if that one feels bad. I also made a slightly earlier edit to clarify that the bureaucrat should be uninvolved, which I don't expect to be contentious. --Izno (talk) 20:02, 2 September 2018 (UTC)[reply]
• I'm concerned to see us using another week-long RFA-Like process here, with as much of a broken cesspit as RFA is. I see that there's at least encouragement to focus on the editor's technical ability, which is a step in the right direction. SQL^{Query me!} 21:27, 2 September 2018 (UTC)[reply]

  @SQL: with admin being a prerequisite (currently) I'm not worried about this turning in to a big drama-fest, we've had 9-mini requests on this page so far and they have all been as calm as they could be. — xaosflux ^Talk 22:39, 2 September 2018 (UTC)[reply]

  @Xaosflux: - I'm not sure a handful of temporary requests in the very earliest days while we're still drafting the policy is really enough data to make me feel that mirroring RFA won't end up with something like RFA down the road. SQL^{Query me!} 22:50, 2 September 2018 (UTC)[reply]

• I think this is a good idea to separate that ability from the admin flag: it mitigates the risk of a mishap since most admins don't routinely edit the interface. I don't see however why this needs to be more complex than a "Hi, I need the bit because xxx" followed by " Done" conversation. Reading the proposal, it looks however like this is turning into another of our crazy processes and there's no need for that: there has been virtually no admin abuse and we can assume that someone that wants the bit is trying in good faith to fix something that is broken. Regarding non amdmins, is there really a need for editing the interface that can't be solved using the ((editprotected)) process? -- Luk ^talk 09:03, 3 September 2018 (UTC)[reply]

• Since there are now three alternative / counter proposals, can we maybe close this RFC that is unlikely to result in consensus anyway (imho) and start a new RFC where people can !vote on all four proposals and also indicate their preferences which proposal is their first, second, third etc. choice? Regards SoWhy 10:18, 6 September 2018 (UTC)[reply]

  Second that. Lourdes 10:36, 6 September 2018 (UTC)[reply]

  I've restructured the RfC so that it explicitly encompasses the proposal below. I hope this is a satisfactory way to avoid having to start completely over with a new RfC. Mz7 (talk) 23:10, 7 September 2018 (UTC)[reply]

  Mz7, I'm very confused as to what is going on here. I thought you had closed the above RfC, now it is open again. Mainly commenting as I had changed CENT because of it, and now I see a revert there to this RfC, which hasn't been commented on in 3 days. TonyBallioni (talk) 15:12, 8 September 2018 (UTC)[reply]

  @TonyBallioni: I'm sorry about the confusion. I'm also a little frustrated with trying to organize this. The reason I've reopened this is to have all of the current proposals on this page closed together as one giant RfC, instead of it being just one RfC about one proposal. Maybe I could have done this without re-opening the section I closed, but I thought it was important that the closer consider comments in this section. Mz7 (talk) 17:11, 8 September 2018 (UTC)[reply]

  Makes sense, and I was not critiquing you (you've done a wonderful job herding cats here.) I was just trying to figure out what was going on/if the above was still being actively considered. Thanks for all your work TonyBallioni (talk) 17:16, 8 September 2018 (UTC)[reply]

  I think it's safe to say the "original proposal" probably won't pass at this point, and it may be a good idea to restructure the discussion to reflect this. Enterprisey (talk!) 04:33, 16 September 2018 (UTC)[reply]

Alternative / modified proposal: Grant for admins on request without process

A number of editors have expressed their opposition to the proposed implementation for creating too many hurdles and a number of supporters have explicitly only supported just to have any process in place, however flawed. I thus propose that instead of implementing a flawed process and trying to fix it later, we KISS and just implement a simpler process now and think about a more difficult process if (and only if) this process does not work out:

I think this addresses the concerns of those favoring a stricter process by imposing shorter limits on acceptable inactivity, thus reducing risks of accounts being inactive while having the right. After all, if you can get the right by just asking, you won't mind relinquishing it whenever you are inactive for a period of time. Thoughts? Regards SoWhy 17:48, 3 September 2018 (UTC)[reply]

Discuss Alternative / modified proposal

@SoWhy: I think the best place for one-time edits would be to use the edit request process on the associated talk-pages, they would be more likely to be seen by watchers of those pages. — xaosflux ^Talk 18:27, 3 September 2018 (UTC)[reply]

@Xaosflux: Yes but that requires that those pages are monitored. Not all those pages are watchlisted at all or by all IA permission holders. On the other hand, they probably all monitor the IANB, so requests there will likely be seen by more editors. Regards SoWhy 19:10, 3 September 2018 (UTC)[reply]

I missed this comment earlier, but I'm with Xaosflux on this. We shouldn't pull history away from the relevant talk pages, and folks should continue to use edit requests, as they do now. My intent when making the board was to help fuel a discussion above. To quote myself below, [t]he initial intent of IANB was to have 1. a place where IA nominations (and removals) could be discussed (like the edit filter) and 2. to discuss bigger-picture edits, perhaps involving coordination amongst editors. ~ Amory (u • t • c) 11:46, 4 September 2018 (UTC)[reply]

• Thanks for starting this, SoWhy. I at least think there is some support for a “hold” period between the request and the earliest it can be granted to allow for potential objections, similar to how we handle resysop requests or requests for edit filter helper and edit filter manager for non-admins. It was originally 48 hours when we were workshopping this proposal, but I guess we thought that was too short and made it a week; now that we’ve opened this up to the whole project, I think it’s clear we shouldn’t have thought that. Mz7 (talk) 18:45, 3 September 2018 (UTC)[reply]
  • Imho, if there is a reason not to trust an admin with the IA permission, they shouldn't be an admin at all, IA or not. What reason could there be to trust someone with deleting basically all pages except a few, blocking everyone and protecting everything but not with editing JS / CSS pages if they expressed a wish to do so? Regards SoWhy 19:06, 3 September 2018 (UTC)[reply]
    • I think that’s a fair point. I support a hold mainly as a compromise between those who want a full vetting process and handing it out on request. TonyBallioni (talk) 19:08, 3 September 2018 (UTC)[reply]
    • I don’t think I agree with that. This permission gives the ability to run code on millions of computers. Many well-respected technical editors who have opined here have placed the potential for misuse even higher than checkuser/oversight. With that in mind, I just think it isn’t a bad idea to vet for technical competence and demonstrated need. Mz7 (talk) 19:13, 3 September 2018 (UTC)[reply]
      • It does but again, why trust an admin with the ability to wipe out thousands of pages or block thousands of users if they feel like it and not edit the JS / CSS? I don't expect many admins will request this permission anyway, just like only a few admins use the edit filter right. Regards SoWhy 19:18, 3 September 2018 (UTC)[reply]
        • Well, I think deletion/block rampage is less likely to be as disruptive as the ability to install malware on thousands of computers and potentially violate the privacy of other users. I’m not sure I agree with your equivalence. Mz7 (talk) 19:21, 3 September 2018 (UTC)[reply]
        • To be clear, I think a 48-hour hold is a good compromise, as Tony suggests. Mz7 (talk) 19:38, 3 September 2018 (UTC)[reply]
          • In regards to what Mz7 stated, this happened already before. Miraheze is an ad-free wikifarm that hosts wikis and is run by members of this community. They had to deal with a security incident where one of the wikis had malicious JS installed in the common.js file that resulted in the users' own computers transmitting, Username, IP, UA, and CSRF tokens to a third party party server. So while admins here are held to an extremely high standard, it's very possible for one of us to do that, if we had malicious intent, or if one of us is not technically inclined, and proxied an edit on behalf of someone that said it does X, but it actually did Z, the damage is then done, and likely irreversible. I'm saying this as an argument in regards of why security is absolute paramount, but I'm not commenting on whether all admins should have been stripped of their rights after such long-standing. I'm still very neutral on this.—CYBERPOWER (Chat) 20:10, 3 September 2018 (UTC)[reply]
• This proposal sounds the most pragmatic one till now. There's no need for a holding period, given that being an admin would be a pre-requisite. A holding period would go against the basic premise of handing over the right on request. Lourdes 18:54, 3 September 2018 (UTC)[reply]
• I’d support with a 48 hour hold in case there are reasonable objections, but would support this over the proposal above. TonyBallioni (talk) 19:06, 3 September 2018 (UTC)[reply]

The only reason I can think of is if the admin is currently under discussion at AN/ARBCOM with the threat of desysopping. But even then, a 24-hour-period like for resysops should suffice. Regards SoWhy 19:18, 3 September 2018 (UTC)[reply]

• Tracking 2mo/6mo activities may be a bit awkward. — xaosflux ^Talk 19:11, 3 September 2018 (UTC)[reply]

I'm no expert but I'm pretty sure a bot could do that, no? Regards SoWhy 19:18, 3 September 2018 (UTC)[reply]

• A 48 hour hold is a minimum here, due to the security reasons that added interface admins in the first place. Otherwise, a malicious actor could simply compromise the admin account, ask for and receive Iadmin, and the security flaw was never actually patched on enwiki. I think we also want some level of vetting for technical competence on top of a hold, but that's a separate discussion. Tazerdadog (talk) 20:19, 3 September 2018 (UTC)[reply]
• For those that think this will end in every admin just having the permission anyways, and there being no reduction in users able to edit JS - let's look at the abusefilter permission, which admins can self-grant, is complicated, and in the wrong hands can easily be very dangerous. There are 159 abusefilter users, 148 of which are admins. That's approximately 12% of admins. SQL^{Query me!} 20:28, 3 September 2018 (UTC)[reply]
  • Another busy project, commons handles it this way as well, FWIW: Commons:Commons:Interface_administrators "Every Administrator who can make plausible a need to edit the interface will be granted temporary or permanent Interface administrators right on request at the Bureaucrats' noticeboard per bureaucrats discretion." SQL^{Query me!} 20:42, 3 September 2018 (UTC)[reply]
  • On the other hand, 148 is 26% of sysops with at least one logged admin action in the past three months, and 38% of those who made at least five logged admin actions. That jumps to 35% and 52%, respectively, for one month. ~ Amory (u • t • c) 20:49, 3 September 2018 (UTC)[reply]
    • On a third hand, if we're going to try to use that as an honest statistic we should probably remove inactive AF users as well. SQL^{Query me!} 20:54, 3 September 2018 (UTC)[reply]
• Strong support (with a 48 hour hold). ~ Rob₁₃^Talk 20:59, 3 September 2018 (UTC)[reply]
• I agree this is a simpler process than the one above, and I would prefer to raise the inactivity threshold of not editing CSS/JS pages to 1-2 years. I think many of the admins who eventually get IA permissions are maintainers of individual tools like WikiLove or Geonotices. If things go well, they might not need to edit any CSS/JS page for months on end, but it will be nice for them to keep the ability to edit the tools so they can respond to any new requirements quickly (e.g. upstream MediaWiki changes breaking their tools) without waiting another few days for bureaucrats to grant them the bit back first. Deryck C. 09:33, 4 September 2018 (UTC)[reply]
  • The proposed removal only works without a holding period of course. Timely removal of access for security reasons makes sense but only if the right can be regranted without delay. I'll whip up a modified alternative below. Regards SoWhy 09:47, 4 September 2018 (UTC)[reply]
• Also I agree with this much simpler situation. It should be fairly easy to check when was the last time CSS/JS pages were edited by the person, and if that is 'a long long time ago' (1 year or more?) then a discussion with the editor can be started to see whether removal is better (but without restrictions towards getting it back later) (and if that actually is warranted based on the number of iadmins we have - I still think we need a healthy base of them to repair broken stuff). --Dirk Beetstra ^{T C} 09:41, 4 September 2018 (UTC)[reply]
  • If the additional bit can be removed and regranted easily, why wait a year? From a security perspective, the concept should be more like typing su - on a *NIX machine, i.e. only using elevated access if necessary and relinquishing it when you don't need it. If one knows they can "type su -" whenever they need it, they have no reason to keep the permission while not using it, thus decreasing the security risks. Regards SoWhy 11:54, 4 September 2018 (UTC)[reply]

    • @SoWhy: I'd be fine with interfaceadmin's having "removeself" access from the group so they can remove their own access whenever they want. The tech team should have no pushback on that, but we need a community approval to submit this as a configuration request. — xaosflux ^Talk 14:40, 4 September 2018 (UTC)[reply]

      • • @Xaosflux: Makes sense but that's something we can discuss once we have established how to grant it. My proposal does not specify how the access is removed and thus is compatible with "removeself". Regards SoWhy 14:49, 4 September 2018 (UTC)[reply]
    • I'm fine with self removal and/or a reminder after 2 months as well. Should just not be too short. In the end it will also depend on how many inactive bits will be lying around. --Dirk Beetstra ^{T C} 16:20, 4 September 2018 (UTC)[reply]
• I strongly oppose this proposal. It misses the point of why this separate group was created in the first place. Anomie⚔ 00:22, 9 September 2018 (UTC)[reply]
• Oppose. There is a real problem which is not even acknowledged in the proposal. Admin accounts at enwiki have been compromised and malware has been added to script pages at other wikipedias. Johnuniq (talk) 01:41, 9 September 2018 (UTC)[reply]
• Oppose as well. The proposal appears to be missing the point: The previous lack of any additional requirements has been the reason for introducing the separate usergroup in the first place. Implementing this proposal would effectively disable the new security measure. ~ ToBeFree (talk) 17:44, 9 September 2018 (UTC)[reply]
• Oppose, per Anomie. Enterprisey (talk!) 04:35, 16 September 2018 (UTC)[reply]
• Support as this is the least-bureaucratic approach (and preferably without the 48-hour delay). OhanaUnited^{Talk page} 07:21, 16 September 2018 (UTC)[reply]
• Weak oppose. I'd like to see the option of community participation for the first-time approval of an IA, and I'd like to see at least the question raised of intended use and competence. Even a 48-hour first-time-approval hold is an invitation for the community to raise concerns or catch problems. I do appreciate that this proposal minimizes the difference between IAs and "regular admins", though. ((Nihiltres |talk |edits)) 16:31, 17 September 2018 (UTC)*Support with a 48 hour hold. Anatoliatheo (talk) 05:41, 21 September 2018 (UTC)[reply]

Alternative proposal with waiting period

Because of popular demand, here's a proposal that tries to address the comments above while still keeping it simple:

This adds a waiting period for first-time requesters while still making it simple to gain and lose the permission for already experienced admins without having to wait 48 hours each time, thus promoting a voluntary removal. Regards SoWhy 09:56, 4 September 2018 (UTC)[reply]

Discuss alternative proposal with waiting period

• Can you reword request one-time edits at WP:IANB? I made the board following some discussion above, mostly as a way to see what it would look like, but also with the idea that something that exists (e.g., BN) would always be chosen over something that didn't yet exist. One-off edits should still be made at the relevant talkpage, as currently happens now, and folks should use an edit request template, as currently happens now. The initial intent of IANB was to have 1. a place where IA nominations (and removals) could be discussed (like the edit filter) and 2. to discuss bigger-picture edits, perhaps involving coordination amongst editors. We shouldn't pull history away from the talk page of interface pages, and the way things are going here, I think it likely the IANB need not exist. ~ Amory (u • t • c) 11:43, 4 September 2018 (UTC)[reply]
  • As I pointed out above, a noticeboard (whichever name it uses) is probably better in terms of visibility than talk pages, considering that now all people available to make a certain edit have all those pages watchlisted. An alternative using some form of ((edit protected)) for these pages feeding a category that can be monitored by people with IA access would be a viable alternative of course. I'll amend the proposal but the specifics of which template to use should not matter for the proposal. Ideally, there should be an explanation page that informs editors of how to make such requests. Regards SoWhy 11:58, 4 September 2018 (UTC)[reply]
• Support per my comments above and my thanks to SoWhy for taking initiative here. TonyBallioni (talk) 13:43, 4 September 2018 (UTC)[reply]
• Support as an acceptable compromise. I would also like to thank SoWhy for starting this. I still prefer requiring at least a statement of demonstrable need, but this is an acceptable starting point for a process that I hope addresses the concerns that we would be making another RfA. Mz7 (talk) 19:24, 4 September 2018 (UTC)[reply]
• Strong oppose 1) Doesn't establish a proof of need process, but rather one which is time-based. 2) Doesn't guarantee actual usage of rights and gives a 6-month interim period. My suggestions include: 1) Require a proof of need and present technical requirements. 2) Have stricter requirements for removal, such as two months of no logged action and not using the IA right as well. 4) Finally, implement the proof of need only on first-time requesters with later ones being subjected to a simple 24-hour wait or similar. I think this is too sensitive a right to grant to anyone (we do not seem to exactly get that fact), and needs to be treated as such, sort of like how EFM is held only by a handful, out of which few are active and mere fewer are non-admins. --QEDK (後 ☕ 桜) 19:50, 4 September 2018 (UTC)[reply]
  • If I wanted to, I could give myself EFM right now. I have no desire or need for it, so I don’t, but appealing to EFM as saying it is better than this proposal ignores the fact that this proposal is stricter than the EFM process for admins. TonyBallioni (talk) 20:04, 4 September 2018 (UTC)[reply]
    • My point was simply, it's more sensitive then EFM, so we should regulate it as such. Whether the process is of relatively more or less strict that how EFM is managed is of no relevance to what I said. You should have read into more of the point where I stated about how few of them are active and closely guarded EFM is among admins. With thanks. --QEDK (後 ☕ 桜) 20:10, 4 September 2018 (UTC)[reply]
      • I’m sorry, and I’m not trying to be rude, but I’m having a lot of trouble parsing your syntax in both posts. What the first post seems to say is that this is a security risk, so it should be regulated like EFM is (which is not at all for admins). I’m not sure what you are trying to say in your reply after the first sentence. TonyBallioni (talk) 21:22, 4 September 2018 (UTC)[reply]
        • @QEDK: Gadget scripts ought to be stable, but gadget maintainers need to be able to respond quickly if an upstream change breaks their gadget. If we revoke IA after only two months of not editing interface scripts, it will prevent IAs from responding quickly to requests, or worse, create a perverse incentive for IAs to keep changing their gadgets in order to keep their IA rights. Deryck C. 09:32, 5 September 2018 (UTC)[reply]
          • If someone is not making such changes for a period of 2 months, there is absolutely no need of holding such a right till that point either. If upstream changes break a gadget and you aren't an active maintainer, you probably should hand it off to someone more active. @Tony, I didn't mean to say as regulated as well, I'm simply clarify again, that if self-granted, most of them stay as-is over a period, without the right actually coming of use, and non-admins getting the right are even more regulated so their contribution is absolutely miniscule. --QEDK (後 ☕ 桜) 09:46, 5 September 2018 (UTC)[reply]
            • @QEDK: I'm afraid you misunderstood my point: many gadgets do not require any edits to their scripts for many months at a time. If we remove IA after two months of not editing sitewide script pages, most gadgets will have IA permission stripped from all their maintainers and therefore nobody to respond to an upstream change when one happens. Deryck C. 10:57, 5 September 2018 (UTC)[reply]
• Support seems like an acceptable compromise. ^Semi_Hypercube ✎ 20:48, 4 September 2018 (UTC)[reply]
• Support, this looks good to me. The interface admin right was created so that admins who didn't need this right but who's accounts became compromised would be less of a risk. As far as I can tell, it was never intended to be a separate, higher, vetting process (RFA 2.0). Admins are entrusted by the community to use these tools responsibly, if they have need, there is no reason why the 'crats can't just grant it on request. — Insertcleverphrasehere ^{(or here)} 00:34, 5 September 2018 (UTC)[reply]
• Oppose, almost there. This proposal is actually a nice compromise, minus that it does not require a demonstrated need, for what is the most sensitive user right available. I'd like to see that in the print, however fine it may be. Interface admin is not for hat collecting. We need to see a good reason as to why they want to use it, and some evidence they'd know how to. I also would prefer 3 or 4-day waiting period. 48 hours would cover only a weekend, when many people are away from the wiki. A week long process (from the first RfC above) indeed is rather long -- that I agree with. — MusikAnimal ^talk 04:16, 5 September 2018 (UTC)[reply]
  • EFM does not require a demonstrated need as well and is also very sensitive. The reason IA was created was, from all that was written, to reduce security risks by limiting the pool of users who actually have it. But the underlying assumption of this proposal is that admins are already trusted users (and almost all of them had this right for years without problem) and thus can and should be relied upon not to request this right if they do not plan to use it (again similar to WP:EFM). Imho, if there really are admins who request this right solely for "hat collecting", they are not suitable to be admins, IA or not and should be dealt with based on this. Adding a "need" requirement also might make it seem like that admins cannot be inherently trusted to do that. As for waiting period, this proposal authorizes crats to grant the right after the period. It does not force them to. If there are any reasons to wait longer, we can rely on their judgment to just do so. Even on the weekends we can usually expect someone to say something within 48 hours if there are concerns (plus, admins can be resysoped after 24 hours and that is not problematic either). Regards SoWhy 07:22, 5 September 2018 (UTC)[reply]
    • EFM I don't think is a good example, as it pales in comparison to why you can do with interface admin. Powerful, yes, but a matter of security? No. Anyway, all I'm asking is to explicitly say you should have a "demonstrated need". Some vetting of technical competency may be appropriate, but this is less important. I just don't want to give the impression that this right is easily attainable upon request, and can be used for one-off purposes when it would take less time and effort to simply ask existing interface admins to do it for you. Again, I'm not talking about trust -- admins already proved that with their RfA (in general :) — MusikAnimal ^talk 16:41, 5 September 2018 (UTC)[reply]

  MusikAnimal, would you consider supporting on the basis that we should get something passed and modify it later? If someone gets the permission but doesn't actually need it, I'm sure the 6-month activity requirement will kick in. Enterprisey (talk!) 05:55, 26 September 2018 (UTC)[reply]

  @Enterprisey: We have a fair number of int-admins right now, so I don't see the rush. I personally would like to see "demonstrated need" as an explicit requirement, and at least a 3-day waiting period (even WP:EFH requires 3 days!). I'm not running the show, though. If consensus is in favour of this proposal, let's do it. reply-link didn't work for this comment, by the way! :( — MusikAnimal ^talk 18:35, 26 September 2018 (UTC)[reply]

  Yeah, I would also like to see that; however, I think we're definitely in a minority, and thus I believe a version requiring demonstrated need won't pass. Enterprisey (talk!) 18:40, 26 September 2018 (UTC)[reply]

  MusikAnimal, adding on to my earlier comment, we can always see what happens during the first few days with this process, and comment on requests if there isn't any "demonstrated need". Enterprisey (talk!) 19:09, 26 September 2018 (UTC)[reply]

• OpposeSupport per MusikAnimal, will change to support if a requirement for demonstrated need is added. Enterprisey (talk!) 04:19, 5 September 2018 (UTC)[reply]

  Changed to support. Let's just pass something. Enterprisey (talk!) 05:52, 26 September 2018 (UTC)[reply]

• Support There's no need for demonstration of need. As Tony points out, the basic philosophy here should be equivalent to the one while granting the EFM bit. Admins are expected to have the sense to apply only if they wish to contribute. If an admin applies to get this bit purely for show, then the 2 month/ 6 month delimiter is enough to ensure their redundant bit is removed. Lourdes 06:08, 5 September 2018 (UTC)[reply]
• Support. Better than all the previous proposals. Deryck C. 09:33, 5 September 2018 (UTC)[reply]
• I would prefer the waiting period to be a maximum of 24 hours, but this is a good compromise, so I Support this proposal. I am absolutely opposed to using any sort of process similar to RFA to grant this permission to admins. We should not be modeling anything after that fetid cesspit. I get why this was implemented, and on smaller projects with looser rules for granting +sysop, and less eyes - it makes a lot of sense. SQL^{Query me!} 12:12, 5 September 2018 (UTC)[reply]
• Comment This is basically the same as directly above. However, I don't understand why we need a waiting period. If I am technically capable, and I have not screwed up parts of the interface before (or someone else's css) then if there is need to edit, there is 'need' to edit now. If I have to wait for 2 days, I would suggest the edit and add a ((editprotect)) (the iadmin equivalent of that) and forget about the whole thing. If this involves a gadget I maintain, and due to unforeseen changes in the MediaWiki software the gadget needs a code-tweak, then waiting 2 days annoys the heck out of all of the editors that use the gadget. I can see the requirement for demonstrated need (within reason, again, an editprotect request is an answer to every instance of demonstrated need, unless there are at a certain moment no iadmins at all), but not the waiting time. --Dirk Beetstra ^{T C} 14:44, 5 September 2018 (UTC)[reply]
  • A waiting period is required to give administrators time to recognize that their accounts have been compromised before an attacker is able to be granted this userright. --Ahecht (TALK
    PAGE) 16:42, 5 September 2018 (UTC)[reply]
    • Waiting period is not needed, showingneed is. And as most editors who edit sitewide .cs/.css do that so occasional (onceevery month at most) that a fast expiry (order of days) is better for maintaining site security. Hence Oppose. --Dirk Beetstra ^{T C} 16:51, 6 September 2018 (UTC)[reply]
• Support. Nobody needs to volunteer their work here, and all that having additional permissions does is make it easier to help. Also, SQL says very wise things: we should at all costs avoid creating any process that could become similar to RFA. —Kusma (t·c) 19:58, 5 September 2018 (UTC)[reply]
• Support, secure enough without making the whole thing a bunch of unnecessary bunch of hoops to jump through. As Kusma says, we're asking people to volunteer their time here—let's not make it needlessly hard for them to actually do that! Seraphimblade ^{Talk to me} 04:27, 7 September 2018 (UTC)[reply]
• Oppose per MusikAnimal. A need for the user right has to be explicitly stated for assigning rights per principle of least privilege. —Gazoth (talk) 10:51, 7 September 2018 (UTC)[reply]
• Support, I think the 48 hours waiting period is a bit much but it's simple enough. I trust admins not to request the permission on a whim, and bureaucrats to expedite the process if there's an urgent need and no one to act. -- Luk ^talk 12:47, 7 September 2018 (UTC)[reply]
• Support. This is the most restrictive policy I'd be willing to accept. ~ Rob₁₃^Talk 13:33, 7 September 2018 (UTC)[reply]
• Oppose per MA, although rather than "demonstrated need" I'd say something like "demonstrated use and understanding." ~ Amory (u • t • c) 16:13, 7 September 2018 (UTC)[reply]
  • Just comment at the BN post if you don’t think someone has the need for it. There is a 48 hour hold for a reason. If we didn’t have it, I could see opposing for this reason making sense, but right now it seems like such language can’t gain consensus (see below) and that this proposal is the compromise that has the best chance of passing. TonyBallioni (talk) 19:34, 7 September 2018 (UTC)[reply]
  • What is the reason for the 48 hour hold? The proposed policy only says that Bureaucrats are authorized to grant the permission to any administrator asking for it after that hold, but does not give any guidance as to what should be disqualifying, it doesn't even reference there being a community discussion. It does reference the policy at Wikipedia:Administrators#Restoration of adminship, which is very clear (nearly to the point of being repetitive) about the instructions for Bureaucrats regarding community discussion and granting conditions, especially the negative conditions. This gives no such explanation; at the very least, I think the implicit should be made explicit. ~ Amory (u • t • c) 20:01, 7 September 2018 (UTC)[reply]
    • I think it is overall save enough to leave it to the judgement of the Bureaucrats. If THEY see an active editor acting regular, there is no need for the 48 hour. (if an editor is quietly waiting for his RfA to finish, then Bureacrats are not waiting for 48 hoursto seewhether maybe the account got hacked JUST before theend of the RfA ...). If they are off andon, not editing as regular, then an out-of-the-blue request may warrant a return question or waiting. I mean that we can leave that to their discretion. --Dirk Beetstra ^{T C} 20:41, 7 September 2018 (UTC)[reply]
    • It is at their discretion, and I highly doubt if there is a consensus amongst users who are knowledgeable in this subject area that someone should not have the rights, they would grant (or more likely, the person would just self-withdraw.) TonyBallioni (talk) 23:33, 7 September 2018 (UTC)[reply]
• Oppose I am a new user and wasn't aware of this right before spotting this page on my watchlist but it sounds like a very dangerous ability to be giving out like sweets at Halloween. Wikipedia is listed as fifth most popular website with 495 million unique vistors a month, so it is a prime candidate for hack attacks. The ability to inject attack code into 495 million computers is not something to ever be taken lightly. As others on this page have said the right is only used a handful of times a year, I am shocked that such lax protocols are even being considered. To grant this right you are not only trusting the individual (and their ability to use the tools correctly) but also the strength of their password, firewall and virus protection among other security interface points. The threat is minimal with only a handful of users with the right at any one time but it grows exponentially as more users are added. This right should be locked down to as few people as possible. I'd propose adding a cap to the number of users that can hold this right at any one time. The cap will stop people requesting access as just a status symbol and strong rules on usage levels will constantly reduce numbers below the cap for someone new to request access when needed. From Hill To Shore (talk) 12:10, 8 September 2018 (UTC)[reply]
  • @From Hill To Shore: and what if the right would just expire after a couple of hours or days? --Dirk Beetstra ^{T C} 14:54, 8 September 2018 (UTC)[reply]
    • I suspect that a very short expiration would be difficult to administer. In my view it is the maximum number of people with the access right that is the issue, and the expiry is purely a mechanism to keep the numbers within the cap. Another way to look at it would be to only prune the access list when a new request would take you over the cap. The access list is reviewed and those who haven't used the right in a set time are removed. This would reduce administration as you only clean the list when you hit the cap (or an account loses its admin access), not at fixed points in time. From Hill To Shore (talk) 15:46, 8 September 2018 (UTC)[reply]
  • @From Hill To Shore: Hi (and Welcome!), when every administrator had the ability to edit these page until earlier this year, there were no incident that I can recall. While I agree with you that this may seem dangerous to let individuals edit the site without hard scrutiny, having protocols that are too strict will impede the ability to undo an erroneous or malicious edit quickly. If something bad happens, we will be able to review this process but I think we need to balance reducing the risk of something bad happening and keeping in mind that people here are volunteers, acting in good faith, that are not expected to be on call at any time. -- Luk ^talk 15:23, 8 September 2018 (UTC)[reply]
    • I believe that the number should be capped. However, if there is agreement with this principle, it would be for the community to set the level of the cap. Consensus would have to find a balance between having enough people available to make emergency edits and limiting the number of avenues for a hacker to get in. From Hill To Shore (talk) 15:46, 8 September 2018 (UTC)[reply]
      • @From Hill To Shore: bits can behanded out with expiry, no further action needed. Only if editors keep asking and asking longer periods are warranted. But the most 'need' that I haveseen until now is a couple of hours every 2 weeks. Others 'need' it one hour every 6 months. Advantage is that targetting the right account to hack is difficult, if you have the bit for a year, a hacker has a year to hack your account. --Dirk Beetstra ^{T C} 17:10, 8 September 2018 (UTC)[reply]
• Oppose The "original" proposal is better, although I think it should pick up #1 from "Removal of permissions". Anomie⚔ 00:25, 9 September 2018 (UTC)[reply]
• Oppose There is a real problem which is not even acknowledged in the proposal. Johnuniq (talk) 01:43, 9 September 2018 (UTC)[reply]
• Support as a reasonable compromise. Ale_Jrb^talk 14:38, 9 September 2018 (UTC)[reply]
• Support as a minimum requirement for granting the right. An acceptable compromise for me, that I won't oppose. A 48-hour waiting period is better than nothing, and removing the right after 2/6 months of inactivity appears to be reasonable. ~ ToBeFree (talk) 17:53, 9 September 2018 (UTC)[reply]
• Support although I prefer the version without the waiting period, bearing in mind that the applicant will still have to wait for a bureaucrat to action their request. WaggersTALK 11:52, 10 September 2018 (UTC)[reply]
• Support. I like this idea better than the one I originally supported - I don't see why we need to start an RfA 2 for admins to have a right that they've been fine having ever since Wikipedia came into existence.--SkyGazer 512 ^{Oh no, what did I do this time?} 02:17, 11 September 2018 (UTC)[reply]
• Support as the lesser of the available evils. I don't think we need time limits and it should be freely available to all admin who request it, on demand. Admin have already passed RFA, and all current admin passed with the understanding they would have access to this. Moving the bar doesn't improve security, only good passwords do. Dennis Brown - 2¢ 18:19, 11 September 2018 (UTC)[reply]
• Support as a reasonable compromise, with the 48 hour waiting period serving as a safety-valve to consider issues that may arise in exceptional cases. Fwiw, I don't think "demonstrated need" would be a useful addition to this proposal because, (1) I trust that few if any admins will request the permission simply for the sake of hat-collecting, and (2) almost any candidate who has passed a recent RFA is intelligent enough to cook-up a reasonable sounding "need" for the permission if they are so inclined; so IMO adding that requirement would add bureaucracy and arguments over acceptable standards for "demonstrated need" without actually improving security. See also my oppose to the original proposal. Abecedare (talk) 22:07, 11 September 2018 (UTC)[reply]

  If an admin comes up with a "need" for the proposal that isn't really a true need, I'm reasonably confident that the watchers of BN (or IANB, etc) would spot it. Enterprisey (talk!) 05:34, 13 September 2018 (UTC)[reply]

• Support, reasonable compromise but I note Xaosflux's concerns about how you would track 2/6 month activity. Titoxd^(?!?) 02:20, 12 September 2018 (UTC)[reply]
• Support. Per the above. Admins have already been vetted and trusted by the community, and can do much malicious damage anyway, so if there's a problem with that then it should be tackled at its root, rather than making this process unnecessarily onerous.  — Amakuru (talk) 22:59, 12 September 2018 (UTC)[reply]
• Support This is all the bureaucracy I'm prepared to support surrounding this permission. Courcelles is travelling (talk) 23:25, 12 September 2018 (UTC)[reply]
• Oppose per MusikAnimal and others; given the enormous damage potential, requesters can and should be required to briefly state what they need the right for. I don't understand the hand-wringing about this requirement, which is quite common for other user rights (e.g it's the first of the three standard RfA questions regarding the general admin bit). Regards, HaeB (talk) 02:13, 13 September 2018 (UTC)[reply]
• Strong Oppose. People volunteer their time here. The 48-hour delay (I would call it delay period, not dressing it up as "wait period") is akin to bringing cupcakes to a bake sale only to be told "thank you for the cupcakes, you have been baking them for the bake sale for many years but we just wasn't sure if you put any poison into the cupcakes this year so we'll set them aside for 2 days while others look at the cupcake (without tasting it). Please come back afterwards and we'll sell those (now stale) cupcakes". If we're treating admins who already went through gruelling RfA like suspects, then it's no wonder why people don't bother running for RfA these days. OhanaUnited^{Talk page} 07:13, 16 September 2018 (UTC)[reply]
  • OhanaUnited, based on your other statements here, it seems that you would prefer this to any of the myriad of other RfA2.0/demonstrated need/5 days max proposals. I certainly understand your view, but I think opposing this compromise is likely to do more to undermine your general stance than anything else: if this one fails we aren’t likely to get a “anyone can have it whenever” approach, and we’d be likely to just end up with some convuluted process that is significantly stricter than this. A strong oppose here rather than a “2nd choice” doesn’t make much sense to me. TonyBallioni (talk) 13:28, 17 September 2018 (UTC)[reply]
• Weak support. I agree with MusikAnimal: I'd like to see at least an assertion that the applicant is a) competent and b) plans to use the permission. That said, I think this proposal is still otherwise acceptable; I imagine that in practice most applicants will justify their purpose and competence in their application. ((Nihiltres |talk |edits)) 16:38, 17 September 2018 (UTC)[reply]
• Support - probably the best proposal here. L293D (☎ • ✎) 19:38, 20 September 2018 (UTC)[reply]
• I'm OK with parts of this, the short-term tracking seems a bit too-fast, and I don't like the "no-wait" option - but here's the real catch - other then an accusation of a compromised account, what do you expect to occur during any wait period? Is it assumed that even if there is a majority objection 'crats should grant on-demand? — xaosflux ^Talk 19:46, 20 September 2018 (UTC)[reply]

  I am also concerned about this. If a majority objecting means the 'crat shouldn't grant the permission, we should mention that somewhere in the policy. Enterprisey (talk!) 17:39, 21 September 2018 (UTC)[reply]

  Hmm, my reading of the proposal was that a bureaucrat may grant or deny the request purely at their discretion; it's not a "as long as you ask for it you get it". If any of you are familiar with concealed carry in the United States, I see this as a "may issue" system as opposed to a "shall issue". The 48-hour wait allows community comments to be considered by the bureaucrat that responds to the request, but they are not necessarily binding on the final decision. Mz7 (talk) 23:22, 25 September 2018 (UTC)[reply]

  I've opened yet another proposal that says this explicitly. Enterprisey (talk!) 00:01, 26 September 2018 (UTC)[reply]

  For posterity, I've closed it; we can focus on passing this one. Enterprisey (talk!) 06:01, 26 September 2018 (UTC)[reply]

• Strong oppose Doesn't require the requestor/candidate to have a demonstrated need for the rights granted by the group. — JJMC89 (T·C) 03:10, 27 September 2018 (UTC)[reply]

Alternative proposal, with 'indication of need'

And with 'limited time', I mean up to a week. (and with this, one could even hand this out for a day to a non-admin). --Dirk Beetstra ^{T C} 15:01, 5 September 2018 (UTC)[reply]

Comment: I have ran this query. In the last 3 months only 40 .js/.css pages in the MediaWiki namespace were edited. Spot check on some of them for edits in that period: vector.css got 1 edit, timeless.css got 2 edits in 1 day, RefToolbarLegacy.js 2 edits 1 month apart. That hardly seems to warrant anyone getting 'permanent' access to iadmin. For most actions a couple of hours is more than enough. If security is a big deal, no-one should have access, and only request short-term access when they need it (and there it should be given fast).

• slight adaptation. --Dirk Beetstra ^{T C} 17:22, 8 September 2018 (UTC)[reply]

• Support as proposer. An added benefit of an ever-moving pool of iadmins would be that it limits the time a hacker would have to get access to the account. --Dirk Beetstra ^{T C} 15:01, 5 September 2018 (UTC)[reply]
• Oppose there needs to be a waiting period to ensure that the requesting account hasn't been compromised. Since you have no limit on minimum recent activity, this period needs to be quite long (some less active admins could easily go a week without checking Wikipedia). Having a 1-week waiting period for a permission that is only granted for a week is absurd. --Ahecht (TALK
  PAGE) 16:40, 5 September 2018 (UTC)[reply]

  Sure. You hack a reasonably unused admin account. Do some regular editing, request permission, wait two days with some regular editing and get permission. Or do you expect a hacker to compromise an account of an admin and run the risk to be exposed by the real owner? A waiting period does not accomplish a lot. --Dirk Beetstra ^{T C} 18:18, 5 September 2018 (UTC)[reply]

  If you want to ensure an account is unlikely hacked, then do a CU before assigning. --Dirk Beetstra ^{T C} 18:20, 5 September 2018 (UTC)[reply]

• Oppose Complicated and broad; one can't rely on the personal judgement of individual bureaucrats for such an assessment. Lourdes 07:41, 6 September 2018 (UTC)[reply]
  • @Lourdes: it is intentionally broad, and there is not much to judge. The request could be 'I want to tweak something in this and this js, I need about 2-3 days'. And it is easy to check whether the editor kept to their request during that time or afterwards. For years nothing broke with every admin having access, and now the world is falling if someone asks access for 2-3 days for a specific need in good faith? --Dirk Beetstra ^{T C} 08:08, 6 September 2018 (UTC)[reply]
• Support. Slightly less cautious and therefore less restrictive than the proposal above. On balance, I am happy to have either of them become policy. Deryck C. 09:35, 6 September 2018 (UTC)[reply]
• Oppose I prefer the option directly above. SQL^{Query me!} 13:09, 7 September 2018 (UTC)[reply]
• Oppose prefer above for simplicity. People are free to raise issues of need during the holding period BN. TonyBallioni (talk) 13:16, 7 September 2018 (UTC)[reply]
• Oppose as overly bureaucratic. Can we really not trust admins to identify when they need this tool? ~ Rob₁₃^Talk 13:34, 7 September 2018 (UTC)[reply]

  No. Enterprisey (talk!) 15:42, 7 September 2018 (UTC) - Struck, and apologies to Beetstra for casting aspersions. Enterprisey (talk!) 18:48, 7 September 2018 (UTC)[reply]

  @BU Rob13 and Enterprisey: I'm not sure whether Enterprisey is being sarcastic here, but Beestra's case did not demonstrate anything about trusting admins to self-identify need, but rather a disagreement over the level of caution the granting of this right should entail. Beestra has demonstrated that IA will be useful for what he's doing, but was told to go the inconvenient way round because some members of the community want to avoid giving out IA at all costs. We have a full spectrum of opinions in this page ranging from every admin should be able to get it, to only admins with a recurring problem that doesn't have an alternative solution can hold it temporarily. Deryck C. 18:04, 7 September 2018 (UTC)[reply]

  A trusted user needing it to implement their bot sounds like demonstrated need to me. Our bot policy actually explicitly prohibits doing it the way the community has apparently told him to. ~ Rob₁₃^Talk 18:09, 7 September 2018 (UTC)[reply]

  @BU Rob13: indeed, it baffles me that users who use this 2-3 times in a year have 'a demonstrated need', whereas I, with this causing me massive inconvenience (and many admins with me to follow), do not. This whole situation is clearly about status and trust, not 'need'. I doubt that any ofthe now granted iabits have ANY continued need, with the frequency that.css and .js is being edited in mainspace (and we should NEVER edit s.o. elses .js or.css, that needs to be done through a sandbox so a user always has control over their own .js/.css so they are aware of the risks there). Call my recent edits a massive WP:POINT violation on my side, but people should look at themselves first then. Calling causing inconvenience to a, so it is said, trusted editor, is a WP:POINT violation in itself. --Dirk Beetstra ^{T C} 18:28, 7 September 2018 (UTC)[reply]

  @Beetstra: wasn't the primary emphasis for your ask explicitly that you wanted to edit "s.o. elses .js or.css"? This is not meant to evaluate the validity of your request, fwiw I think it seemed like a reasonable request. — xaosflux ^Talk 19:24, 7 September 2018 (UTC)[reply]

  @Xaosflux: touché, though most are really my socks (except one, which technically is not). --Dirk Beetstra ^{T C} 20:15, 7 September 2018 (UTC) (p.s. with less than 20 edits to side-wide css/js over the last year, do you need permanent access to this bit?). --Dirk Beetstra ^{T C} 20:22, 7 September 2018 (UTC)[reply]

  How did the many non-sysop users deal with such pages in their bot account's userspace? I would have thought the logging in/logging out game to be par for the course. ~ Amory (u • t • c) 20:04, 7 September 2018 (UTC)[reply]

  @Amorymeltzer: First, I am one of the few with on-wiki config files (allowing a lot of control to other editors). I think that only other addmin bot operators have this. For a non-admin bot-operator this level of control on-wiki is near impossible (except if you downgrade your trust to a levelthat you can attain, e.g. template-editors or confirmed users). Otherwise, you can only do it through off-wiki settings, hidden to everyone. Note that I was going to implement either regular sysop-protected files (notsure if json or regular pages) for my bots. I wanted to pull my pages out of the system where they are difficult to access for any admin at the moment, but for now it is too much work for me to get it done (it requires several actions on multiple wikis). --Dirk Beetstra ^{T C} 20:15, 7 September 2018 (UTC)[reply]

  Yeah, bots aren't usually implemented this way. And the bot policy explicitly forbids non-bot edits from the bot account. Actually, I'm going to be slightly POINTy myself and warn you as a BAG member not to edit from your bot account again except for an approved bot task, Beetstra. Please do take this in the spirit it's intended, which is mostly so you can point to the warning you got from a BAG member not to engage in bot policy violations in your next request for the user right. ~ Rob₁₃^Talk 22:34, 7 September 2018 (UTC)[reply]

  @BU Rob13: and @Beetstra: to be clear, see Wikipedia:BOTUSERSPACE, where bots editing their own pages are explicitly allowed - this is also getting QUITE off topic, if you seriously want to discuss this bot's operations and issue BAG "warnings" for policy violations, please take it up at WP:BOTN. — xaosflux ^Talk 01:55, 8 September 2018 (UTC)[reply]

  @BU Rob13: sorry, but just what we needed here. Overly bureaucratic. I would just throw WP:IAR back at you, as I see (saw) giving back control over the bots back to admins as an improvement for the encyclopedia (but actually, the bots work perfectly fine as they are ...).

  (@all) how about the security risk of having (elite?) editors who edit the interface once every 2-3 weeks (if not several months) .. those accounts spend most of their time staring in the headlights of an incoming hacker (it seems that we agree that editing .js/.css in other editors userspace is not needed ...). --Dirk Beetstra ^{T C} 05:07, 8 September 2018 (UTC)[reply]

@Xaosflux: This is neither a test edit nor a bot process, so that section does not apply. Only those two types of edits are allowed by bot accounts in their own userspace. @Beetstra: To be very clear, my comment was meant for you to use to demonstrate "need" in a future request for IA. In a very real sense, what you were told to do when you applied for IA above is a policy violation, which the editors in that discussion did not understand. That is sufficient to get the right. ~ Rob₁₃^Talk 11:44, 8 September 2018 (UTC)[reply]

@BU Rob13: if you truly think the spirit of Wikipedia:Bot_policy#Valid_operations_without_approval prohibits using a bot flagged account to manually edit its own configuration page hosted in its own userspace, to make a Small change, for example to fix problems or improve the operation of a particular task as in changing from User:Bot/config1.css to User:Bot/config1.json let's follow this up at WP:BOTN or WT:BOTBOL. This is certainly the wrong venue for this discussion. — xaosflux ^Talk 16:07, 8 September 2018 (UTC)[reply]

@BU Rob13: We should not need to 'demonstrate need', use is enough (I should reword my proposal). That is the problem. The elitarian 'do it in a different way' by editors who themselves have hardly any reason to use more than once every two weeks.

@Xaosflux: I still think that that type of editing falls under IAR. I can hardly see it as controversial to improve Wikipedia in this way, and would call enforcing that as policy overly bureaucratic. Seems to go around here, bureaucracy. --Dirk Beetstra ^{T C} 17:01, 8 September 2018 (UTC)[reply]

Oppose The original proposal in this RFC is better. This also lacks any provision for removal based on inactivity beyond encouraging 'crats to do so when handing it out. This could work as a process for (temporarily) regaining the permission after it was removed for inactivity-in-the-area after being granted per the original RFC. Anomie⚔ 00:28, 9 September 2018 (UTC)[reply]

@Anomie: the crux of my proposal there is that expiry shouldbe fast (and the bar togrant next to zero), order of hours to days. On most accounts that I checked activity means an hour or two now, then hundreds (to thousands) of hours of inactivity. I trust that if ever we get iadmins with long periods of having the bit (for which the need seems unlikely .. we really never edit .css and .js in NS#8), that I think that or there should still be a 'refresh cycle' every 6-12 months, or except that that account loses the bit when s.o. notices their inactivity (in this field). --Dirk Beetstra ^{T C} 04:00, 11 September 2018 (UTC)[reply]

• Weak Support: This proposal adds a security measure and removes another. The right should ideally be removed after 2/6 months of inactivity, and there should be demonstrated need, to avoid exactly the abuse cases which have led to the creation of the user group. ~ ToBeFree (talk) 17:59, 9 September 2018 (UTC)[reply]
  • @ToBeFree: my point is that if you leave the bit for 2-6 months on an account (that anyway uses it less than once every 2 weeks), a hacker has the same time to hack that account. You know that the bit will stay there long. Give it 1 day, a hacker has to have comprimised your account, wait until you get thebit (which maynot even happen), be there at that moment, and then has only limited time. Moreover, the community is more likely to see things happening in that one day - they will have lost their interest after a day or two .. --Dirk Beetstra ^{T C} 03:51, 10 September 2018 (UTC)[reply]
    • @Beetstra: Sorry, I have somehow managed to overlook the whole "limited time" part of the proposal. I like it. It seems to solve all the possible problems that I had been afraid of. Full support. ~ ToBeFree (talk) 19:47, 10 September 2018 (UTC)[reply]
• Oppose There's an obvious vicious circle here: an applicant can't "demonstrate use" without having had the permission before. They might be able to "demonstrate need" but that opens a separate can of worms regarding exactly what constitutes a satisfactory "demonstration". As admins, these are users who have already established the trust of the community. Jumping through additional hoops is unnecessary. WaggersTALK 12:01, 10 September 2018 (UTC)[reply]

  @Waggers: 'demonstrate need' should be a nearly non-existant bar, it would be more of where they intend to use it now, not something that needs to be judged whether there are other solutions. And no, if I now say thatI wrote a gadget that I want to install, without ever having used the bit before then the admin should simply be be trusted. --Dirk Beetstra ^{T C} 03:52, 11 September 2018 (UTC)[reply]

• Oppose Admins can be trusted to know when thy do/do not have need. — Insertcleverphrasehere ^{(or here)} 02:07, 11 September 2018 (UTC)[reply]
  • @Insertcleverphrasehere: Isn't that not what I suggest? Trust admins to have the bit when they have need for it, but expire fast for security reasons (not have it for months on them with the risk that their account gets hacked). --Dirk Beetstra ^{T C} 03:52, 11 September 2018 (UTC)[reply]
    • Apologies, I didn't realise that it had been amended. Struck for now. — Insertcleverphrasehere ^{(or here)} 04:45, 11 September 2018 (UTC)[reply]
• Oppose. While I understand that "demonstrate use" is implied as being somewhat of a low bar to clear, I foresee the same issues that Waggers points out above occurring. Titoxd^(?!?) 02:18, 12 September 2018 (UTC)[reply]
• Oppose New admins can't really "demonstrate use". OhanaUnited^{Talk page} 07:17, 16 September 2018 (UTC)[reply]
• Oppose. "Demonstrated use" is bad wording, at least, and could be interpreted poorly—as other comments on this proposal indicate. Even if I assume the best-case scenario for "demonstrated use", I can't support the bureaucratic weight of a system that encouraged highly time-limited access as this one does. ((Nihiltres |talk |edits)) 16:44, 17 September 2018 (UTC)[reply]
• Oppose per Waggers. Seems too complicated, confusing, and unnecessary. I see little problem with the proposal above, which I support.--SkyGazer 512 ^{Oh no, what did I do this time?} 14:46, 18 September 2018 (UTC)[reply]

Alternative proposal, quick expiry only

As above the main 'problem' seems to be that the people have problems with administrators needing to explain themselves what they want to do, etc., here a proposal without any need for explanation of why one would need the bit.

I still believe that keeping the bit for long time on administrators drastically increases the chance that the account gets compromised while having the bit. This also minimizes the risk of compromised accounts having long-term access to the bit (short term access is easier to monitor and decreases the window of access). --Dirk Beetstra ^{T C} 07:04, 13 September 2018 (UTC)[reply]

• Support. Minimal bureaucracy, sounds good to me, no risk of hat collection. Thanks for proposing this. Enterprisey (talk!) 08:44, 13 September 2018 (UTC)[reply]
• Support - A better compromise than the waiting period one. It sounds quick, easy, limits the elevation of privileges, and avoids unnecessary bureaucracy. SQL^{Query me!} 07:29, 15 September 2018 (UTC)[reply]
• Support what Enterprisey said. Combines quick assignment and removal with minimal bureaucracy. I still prefer my original alternative but this would be good as well. Regards SoWhy 14:33, 15 September 2018 (UTC)[reply]
• Support Avoids bureaucracy but with minimal security issues, reminds me a lot the unix sudo command, elevated permissions only when needed, taken away when not. A good compromise. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 20:43, 15 September 2018 (UTC)[reply]
• Oppose There should still be some process for establishing technical skill, which RFA doesn't cover. This would work well as a process after an admin has established that. To those who say "admins should know their skill level and not request it if they don't know what they're doing", you may wish to read Dunning–Kruger effect. Anomie⚔ 20:44, 15 September 2018 (UTC)[reply]

  This may not be an issue, because limited-time grants should bring more scrutiny on edits made with the permission. Enterprisey (talk!) 22:45, 15 September 2018 (UTC)[reply]

  This friendly system leaves the door wide open. If someone compromises an admin account (which has happened several times) or coerces an admin into revealing their password (which has happened at another Wikipedia), all they have to do is politely ask for the interface permission and they immediately get it. So why have the extra permission at all? Johnuniq (talk) 23:42, 15 September 2018 (UTC)[reply]

  Johnuniq, actually, since reading this page I see quite a few people with varying opinions on a waiting period, and since it seems largely independent from each individual proposal, we should probably just postpone the question of a waiting period to a later RfC. Thoughts? Enterprisey (talk!) 00:12, 16 September 2018 (UTC)[reply]

  I've asked for a waiting period to be added. I would support in either case. Enterprisey (talk!) 00:06, 16 September 2018 (UTC)[reply]

  @Anomie: with years of having hundreds of admins having access to technical parts of the 'pedia we hardly ever saw overconfident admins we never saw edit filters bringing wikipedia to a halt, adding '.' to the spam blacklist (though .. a technical capable and experienced one ..,), or breaking the layout by installing a wrong .css. In fact, admins who don't know how edit filters work don't edit them (don't even set the bit ..), admins regularly comment on the blacklist that they know they can do it, but don't have the skills. And the chance of you screwing it up is still not zero - I trust no-one, with or without skills to not screw it up, there are bugs in software releases, and deployments of MediaWiki have been rolled back. All that your investigation of skills does (if even) is to create a second RfA, where anything goes. (and anyway, the capability was removed as a security measure, and now you (ab)use that situation to mitigate even good faith fuck-ups). --Dirk Beetstra ^{T C} 03:35, 16 September 2018 (UTC)[reply]

  @Johnuniq: and what does a waiting period accomplish? Either the above discussion on skills (if it is even on skills ...), but certainly not any significant level of security. I would, if I would be a hacker, take that chance. Ask for the bit and wait for 48 hours (pretending to be normal), hoping that the owner does not notice (and if I study the editor a bit, I may even increase my chances by chosing a Friday afternoon, knowing that the admin's activity in the weekend drops sharply). And if I fail on this admin, I will try another one. And I don't think that our bureaucrats are not capable of noticing suspicios things and they do not sit there waiting for flipping bits (I recall I had to wait hours to see my admin bit flipped). I can agree with up to a 24 hour waiting period, but I do not believe in that providing significant extra security. --Dirk Beetstra ^{T C} 03:35, 16 September 2018 (UTC)[reply]

• Support. This one also looks reasonable to me. This wording presumes handing out short periods of validity but leave open the possibility of handing out long validity to IAdmins who need it regularly. Deryck C. 04:35, 16 September 2018 (UTC)[reply]
• Oppose the community as a whole is fine with the risks of assigning this permanently. There’s already an acceptable compromise. A 5 day grant over and over is too complicated. I will never need this and will never request it. Most admins in the same boat will do the same. I would have supported a more complex process earlier on, but at this point I’m tired of the endless proposals. This one has the disadvantage of making reasonable requestors request it over and over. Just go with the previous reasonable compromises. TonyBallioni (talk) 04:56, 16 September 2018 (UTC)[reply]

  It would be a five day grant only a few times, before the crat would just hand it out permanently. Most admins would only need it temporarily, anyway. Enterprisey (talk!) 04:58, 16 September 2018 (UTC)[reply]

  @TonyBallioni: There are now 'permanent' bits out there on users that have used it in MediaWiki space over the last year 3 times (i.e. on 3 different days). If the community as a whole is fine with the risks of assigning it permanently, then why not plainly give all admins the bit - no questions asked, make my '1-5 days' '1 year'. Apparently there is then no risk to having it permanently on admins. The only risk we have is that one of the admins with the bit gets their account hacked ... so if we have 20 accounts with the bit on all the admins that we have, do you think that a hacker who wants to abuse this would go after one of the hundreds of accounts without the bit? That just does not make sense. You're not mitigating the risk there, if accounts have the bit shortly, then it is difficult to coordinate your attack. If most of the accounts have it shortly, and only those accounts who use it really once every week (the ones that really request it over and over) get it permanently we may get 2-3 accounts with permanent access, not 20 of which most lie around doing nothing for >99% of their time (362 days in 365). One of the others is using it on about 25 days in 365, still >90% inactive. (and yes, for edits in userspace .css/.js there are other solutions, e.g. through sandboxing and letting the owner do the job, no-one NEEDS the bit for editing s.o. else's .css/js, it is only inconvenience). --Dirk Beetstra ^{T C} 06:20, 16 September 2018 (UTC)[reply]

  Of course we’re mitigating risk if we go from 1200 to 20 people who have access to this. That’s what none of the tech people here get: the most perfect security situation would be for only sysadmins or some other extremely limited group to be able to do this. It would also be a huge burden. The question is not what is perfect security but what is reasonable security to balance with function. An approximately 98% (1200 to ~20) reduction in the attack surface is by any standard a huge reduction of risk. Considering that commons policy on this is basically “if you want it, sure.” I don’t really think it would do much harm for en to also be loose with granting but have some basic controls. TonyBallioni (talk) 13:38, 17 September 2018 (UTC)[reply]

• Oppose Quick expiry resulting in multiple requests is a classic example of bureaucracy. OhanaUnited^{Talk page} 07:19, 16 September 2018 (UTC)[reply]
  • @OhanaUnited: You, as an example, have used/needed it on two days over the last year. That would have been two requests. I can see your point if editors have to request it 5 times a month because they need to use/need it and it has already expired because the 5 days of the previous request are already over (but I have given that provision, if editors really have to request it on a near regular basis because the first period has expired, it should be given for longer (or maybe even permanently then). For most editors, who are like you, requesting it 4-5 times a year is not too much of a burden, and having that bit on those editors 24/7 is actually a security risk - those accounts that are not using it too often are the accounts to attempt to hack. Having 20 of such accounts is becoming significant. (and I have, until now, only found 1 editor who uses/needs it more than 1 time a month ..). --Dirk Beetstra ^{T C} 13:35, 16 September 2018 (UTC)[reply]
    • That's because we don't know when, or how often, the Geonotice requests come in. And their duration is different. Some event organizers request weeks in advance, others only want to post for an event in the upcoming weekend. If there's a long lead time, the suggested expiry period makes it cumbersome to request interface admin for a short period just to post and again to take the notice off. OhanaUnited^{Talk page} 16:43, 16 September 2018 (UTC)[reply]
      • and still, betwee; those two points, your iadmin bit is inactive while a hacker has all the time to gain access to your account. --Dirk Beetstra ^{T C} 18:38, 16 September 2018 (UTC)[reply]
• Oppose editors that gain support for access and are active shouldn't have to continuously reapply, also the guideline is vague - which may lead to inconsistent application depending on the specific 'crat doing the processing. — xaosflux ^Talk 16:50, 16 September 2018 (UTC)[reply]
  • There is no process to gainsupport for access. Well, that was the RfA we already passed. And 'continuous reapply: you have used/needed it maybe onceevery 1-2 months. That hardly wualifies as continuous, 97% of the time your bit is waiting for a hacker to gain access to your account. --Dirk Beetstra ^{T C} 18:38, 16 September 2018 (UTC)[reply]
• Oppose I cannot support any proposal that requires repeated applications to make edits. We cannot minimize the security risk of the permission past the lower bound of the risk of compromise of a bureaucrat account (since bureaucrats have the technical ability to grant the permission at will). As bureaucrats have their permission indefinitely, our risk is always at least that number of accounts. Increasing the risk slightly by having slightly more permanent users is less trouble than regularly requiring confirmation of IAs, and I'd argue—as requests would be far more infrequent—reduces the risk that a compromised administrator account could slip through the process on false pretenses, by increasing the scrutiny applicable to requests. ((Nihiltres |talk |edits)) 16:59, 17 September 2018 (UTC)[reply]
• This is easily the worst of the proposals, and we would need to elect more bureaucrats to handle something like this. --Rschen7754 00:31, 18 September 2018 (UTC)[reply]
  • @Rschen7754: do you know how little global .css and .js are edited? --Dirk Beetstra ^{T C} 03:28, 18 September 2018 (UTC)[reply]
    • More than the number of administrators we promote? Because maybe, since bureaucrats indirectly always have access to interfaceadmin, we should get rid of all the crats on this wiki and hand it over to stewards. --Rschen7754 03:36, 18 September 2018 (UTC)[reply]
      • No. It really is in the hundreds of edits a year. And the crux is one page, which gets 95% of that (and for whichis more a settings page for which another format would work very well, even plain text). Most editors would onle need to request once every so many months. And seen my provision to hand it out for longer to editors with very regular need (e.g. those that would be requesting twice or more a month, though I haven't seen such editors yet) the load will be rather small. One to two requests a week ... at max. (and with no deadlines attached, there is no problem for those to wait a couple of hours or a day). --Dirk Beetstra ^{T C} 04:04, 18 September 2018 (UTC)[reply]
• @Beetstra: Thanks for proposing this as an alternative. I want to first apologize for my comments earlier, back in the original proposal discussion – I know it felt to you like I was hammering down opposes, and I guess I got a little too frustrated. Just to clarify, would your proposal specifically prevent bureaucrats from assigning the right indefinitely? Or could a bureaucrat plausibly give the right indefinitely as part of the "longer period" part of your proposal, i.e. for users who persistently demonstrate a compelling need for the right? Mz7 (talk) 07:52, 21 September 2018 (UTC)[reply]
  • @Mz7: I would not oppose that, but I guess we would have to see whether that specific need would actually arise (I would expect bureacrats normally to give that after three grants in quick succession). The three months inactivity clause will clear it out, whether it is on a 1 year, 3 year or infinite term. I would also not oppose to give it out for e.g. one month on first time because an editor expresses to need it today and in three weeks (which may be happening with the geonotices (which was a situation that I was not aware of when I wrote this)). --Dirk Beetstra ^{T C} 15:03, 21 September 2018 (UTC)[reply]
  • (screwed up ping to user:Mz7 --Dirk Beetstra ^{T C} 15:05, 21 September 2018 (UTC))[reply]

Comments (quick expiry only)

• Comment I've notified several editors who've made proposals on this page before of this new proposal: Anomie, BU Rob13, SoWhy, Cyberpower678, Deryck Chan, and WJBscribe. Enterprisey (talk!) 22:40, 15 September 2018 (UTC)[reply]

General discussion

It's a little discouraging that we've had a lot more discussion on images to be used than the pros and cons of the different aspects of each proposal with respect to the risks they address. So I thought I would start a list; feel free to add on and modify it. isaacl (talk) 18:43, 8 September 2018 (UTC)[reply]

Side note: There’s been a bit more discussion than what’s currently on this page. Some of it is archived at Wikipedia talk:Interface administrators/Archive 1. Mz7 (talk) 21:53, 8 September 2018 (UTC)[reply]

Yes, I participated in it. Twice I've asked for a discussion on what risks are being mitigated by various parts of each proposal, and both times there's been no follow up. I understand people just like to vote on whole proposals. Personally I think doing this analysis would have helped avoid the proliferation of proposals. Anyway, it's in the past now; nonetheless, I thought it may still be useful to examine how the proposals address the various risks. isaacl (talk) 00:58, 9 September 2018 (UTC)[reply]

Risk: number of interface-admin-privileged accounts to attack being larger than desirable

Approaches to address this:

• Limit interface administrators to those who edit the affected files regularly (regularly to be defined)
  • Pros: relatively low impact to editors, depending on how the standard for "regularly" is set.
  • Cons: may still leave a large number of accounts to attack. Due to the nature of the files, it may be difficult to set a standard that many otherwise qualified editors can meet
• Beyond a number of core interface administrators (for situations requiring quick response), provide time-limited grants of interface administrative privileges. Re-approvals of grants are done via a light-weight process.
  • Pros: greatly reduces number of accounts to guard
  • Cons: adds some delay to editors who need to maintain the affected files
• Rely on interface administrators to relinquish their privileges when not needed
  • Pros: same as time-limited grant, but allowing for an open-ended access period
  • Cons: may need a significant cultural shift to achieve (given that the percentage of inactive admins today who have not relinquished their privileges). Given a strong setting of expectations from the onset, this might be possible, but it would potentially set up confrontations between editors who want to retain privileges and those who feel that enough time has elapsed to give them up
• Remove interface administrative privilege from accounts that have been inactive for a period of time (to be defined)
  • Pros and cons: see below

Risk: interface-admin-privileged accounts being unknowingly compromised

Approaches to address this:

• Require 2-factor authorization in order to reduce risk of compromise
  • Pros: significant increase in security
  • Cons: operationally problematic due to a lack of a backup verification method in case the second factor is lost
• Remove interface administrative privilege from accounts that have been inactive for a period of time (to be defined)
  • Pros: Encourages interface administrators to log in regularly, which should help them detect any unauthorized access (if they are looking for it). Potentially easier to audit for problematic patterns of access. Intruders are less likely to attack frequently used accounts for fear of detection.
  • Cons: Intruders can still target accounts just before their privileged access expires. Unless auditing is implemented, this can go undetected.

Risk: administrative overhead discourages editors from obtaining privileges to Wikipedia's detriment

Approaches to address this:

• Granting process should focus on a specific set of criteria to demonstrate advantage of granting access
  • Pros: assuming interface administrators are required to already be admins, no need to focus on trust and so only technical need has to be evaluated
  • Cons: if there is a desire to allow non-admins to be interface administrators, an evaluation of trust needs to be done
• Beyond a number of core interface administrators (for situations requiring quick response), provide time-limited grants of interface administrative privileges. Re-approvals of grants are done via a light-weight process.
  • Pros and cons: see above
• Grant interface administrative privileges on demand to admins
  • Pros: very low overhead
  • Cons: see cons for "Rely on interface administrators to relinquish their privileges when not needed"

Closing

Discussion above has slowed, and there are lots of ideas spread among the sections above, I suggest an uninvolved admin (or small group) review the above and get a closure together - which could incorporate provisions from each of the sections. Some of the criterion that I think should be included (not all equally important) are below. There may be more or less as determined by the closer(s).

• A prior closing indicated that at this time this access was limited to current admins - does this stand?
• What venue should be used for requesting this access?
  • Is any advertising of this request required in other venues? (e.g. cross-posting, T:CENT, watch lists, etc)
• Are requests open for community discussion, if so of what scope, by who, and over what time frame (min?/max?)?
• If a discussion is allowed, how should the discussion impact bureaucrats granting this access? That is, is an affirmative showing of support (with a percent guideline?) or lack of significant (percent?) opposition necessary?
• Barring a specific request for expiring access, should access grants be time limited or indefinite?
• Are there multiple processes for requesting access? If so, they should be clearly defined.
• What are the revocation criteria? (some examples are at Wikipedia:Interface_administrators#Removal_of_permissions))
  • Are there to be any special activity requirements?
• In light of the section at the end of this page, any special guidelines for bot accounts?

Thank you! Does anyone have anything to add as for what we are looking for from a closure? — xaosflux ^Talk 15:17, 30 September 2018 (UTC)[reply]

---

As that page is widely edited, and it is basically a 'settings' page (not true script), would it not be worth to turn that into a regular MediaWiki page so it can be edited by all admins again? The current situation with that particular page is rather disruptive, and many editors basically now need the bit solely to edit that page. --Dirk Beetstra ^{T C} 14:50, 18 September 2018 (UTC)[reply]

Is this technically possible? I had thought that something more involved was necessary (phab:T198758), but if not we should just do it. I don't think anyone in this discussion has objected to admins using geonotice as before.--Pharos (talk) 15:10, 18 September 2018 (UTC)[reply]

There is a text on the notices page that states 'Currently, MediaWiki:Gadgets-definition specifies the geonotices to be listed at MediaWiki:Gadget-geonotice-list.js.' I have to parse this gadget better, but I have the feeling that there is a JSON parse of that .js. Movi g the .js to a .json andpointing the script there may be sufficient. .json is freely editable (by admins). --Dirk Beetstra ^{T C} 15:29, 18 September 2018 (UTC)[reply]

So, one option is having a bot regularly (~5 minutes) copy the text of some fully-protected page into MediaWiki:Gadget-geonotice-list.js. This isn't optimal from a security standpoint, but at least we could block the bot instantly if it edits any other page. Enterprisey (talk!) 21:16, 18 September 2018 (UTC)[reply]

The advantage to JS here is that it is behind ResourceLoader, which wouldn't be the case for JSON. We might want to give phab:T198758#4473145 a try, just to see if that works (using something other than geonotice for testing!). I'm confused how wikitext is any better than JSON, as it would seem we'd have to source it on every page load, too? I'll ask Tgr about it. If that doesn't work, then Enterprisey's idea to use a syncing bot seems like a viable alternative, at least until the core issue is resolved. I would be happy to help with that. — MusikAnimal ^talk 22:08, 18 September 2018 (UTC)[reply]

Wikitext has transclusion; but ResourceLoader loads the source, not the rendered version, so of course that didn't work. The bot is not a bad approach security-wise, as long as it actually verifies that the content is JSON (and it is set up safely). --Tgr (talk) 00:33, 19 September 2018 (UTC)[reply]

I don't think it would be too bad to IAR our way through a intadmin-bot BRFA, but we should have a VPPR discussion about it first. I don't think waiting for the current granting-process discussions to conclude would be necessary, either, as this is a somewhat different issue. Enterprisey (talk!) 08:00, 19 September 2018 (UTC)[reply]

Proposal: Bot-synced geonotices

As a temporary measure until T198758 is fixed, a new fully-protected page will be created at Wikipedia:Geonotice/list.json, and a bot with the intadmin permission will copy the text of that page to MediaWiki:Gadget-geonotice-list.js every five minutes. This means all admins will be able to update geonotices again. The bot will verify that the text has only JSON and that it won't cause issues when copied; the bot will still have to go through a BRFA. Enterprisey (talk!) 19:03, 22 September 2018 (UTC)[reply]

• Support as proposer. This is safe because we can instantly block the bot on sight if it ever performs any other action besides regular updates. A supervisor bot can be written to ping AN and IRC in that event. Also, I have notified AN, VPPR, and VPT of this discussion. Enterprisey (talk!) 19:03, 22 September 2018 (UTC)[reply]
• @Enterprisey: do you mean something like Wikipedia:Geonotice/list.json not Wikipedia:Geonotice/list.js? Is there an existing iadmin (or at least an admin) that is offering to run this bot (c.f. Wikipedia:Bot_policy#Bots_with_administrative_rights) ? — xaosflux ^Talk 19:49, 22 September 2018 (UTC)[reply]

  Yes, and Musik said he was interested. Enterprisey (talk!) 19:59, 22 September 2018 (UTC)[reply]

  It would be pretty trivial to write. Instead of a block, you could also use a go/no go page (I use this for a lot of mine). SQL^{Query me!} 19:59, 22 September 2018 (UTC)[reply]

  Yes, that may also work. What I'm concerned about is someone else taking over the account; I imagine they wouldn't care very much for the go/no go page in that case. Enterprisey (talk!) 20:01, 22 September 2018 (UTC)[reply]

  Bot "go" pages can easily be admin edit protected as well. — xaosflux ^Talk 02:40, 23 September 2018 (UTC)[reply]

  Completely agreed. (I was saying if someone took over the bot account, they would of course disregard the go/no go page and a block would be necessary. It makes perfect sense to fully protect the go/no go page.) Enterprisey (talk!) 03:18, 23 September 2018 (UTC)[reply]

• Support. The point of a separate interface-admin permission is to protect the wiki from sneaky or overwhelmingly obvious scripting vandalism. It's not meant to prevent admins from editing geonotices, so we ought to find a way around that if possible, and this is an easy route. Just make sure the bot isn't a normal admin (if that's possible) so that the account couldn't unblock itself if a rogue human got control of it. Nyttend (talk) 03:25, 23 September 2018 (UTC)[reply]

• PS, Enterprisey pointed me to Special:ListGroupRights#interface-admin, which notes that the interface administrator user group doesn't have any general admin rights except editing MediaWiki pages; interface admins can't unblock themselves unless they're also administrators. Nyttend (talk) 04:04, 23 September 2018 (UTC)[reply]

• Support I think this is a smart way to restore some abilities to admin while safe guarding the broader intadmin permissions. Best, Barkeep49 (talk) 03:59, 23 September 2018 (UTC)[reply]
• Support only until T198758 is fixed, as a nice temporary measure that should however never have been required, and that is a short-term solution for a problem that eventually must be fixed via a MediaWiki software update. ~ ToBeFree (talk) 04:09, 23 September 2018 (UTC)[reply]
• Support until json can be used by sitewide scripts. --Dirk Beetstra ^{T C} 04:21, 23 September 2018 (UTC)[reply]
  • Thought: for additional security on the bot-account (though I expect it to be excessive), we could use an edit-filter to make sure that the bot can only edit only the specific page it is supposed to edit, blocking all other edits (in case there are editors not willing to grant the bit for security reasons). --Dirk Beetstra ^{T C} 06:23, 25 September 2018 (UTC)[reply]
• Support as most sensible interim solution. — AfroThundr ^{(u · t · c)} 06:00, 23 September 2018 (UTC)[reply]
• Sounds like a sensible solution - and it introduces error handling to a page that is easy to break, I've got a few ideas that would belong at a BRFA - so will look for one to be open. This process should/can be tested up on testwiki as well to make sure it works good before bringing here. — xaosflux ^Talk 15:02, 23 September 2018 (UTC)[reply]

  To echo what some others have said, this should be a temporary solution, it is far from ideal and could break down at anytime. — xaosflux ^Talk 04:34, 30 September 2018 (UTC)[reply]

• Support as a convenient workaround until we have a better system. I indeed am interested in authoring such a bot. It should be fairly straightforward — MusikAnimal ^talk 01:26, 24 September 2018 (UTC)[reply]

  @MusikAnimal: feel free to open a BRFA - you know they can be open for a long time! - to field any task specific questions. — xaosflux ^Talk 02:22, 24 September 2018 (UTC)[reply]

• Support. A viable workaround for the meantime. –Ammarpad (talk) 08:39, 24 September 2018 (UTC)[reply]
• Support Sounds like it should work. ^Semi_Hypercube ✎ 23:07, 24 September 2018 (UTC)[reply]
• Support It is very valuable that geonotice is in the hands of a relatively broad group, like it has been in the past..--Pharos (talk) 02:24, 25 September 2018 (UTC)[reply]
• Support. This is a sensible solution, though we should keep IAdmin access for a few geonotice maintainers in case the bot stops. Deryck C. 10:37, 25 September 2018 (UTC)[reply]
• Support - It's obviously not ideal to have to resort to such a workaround in the first place, but this will definitely work until T198758 is resolved. ~Oshwah~^{(talk) (contribs)} 11:25, 26 September 2018 (UTC)[reply]
• No objection —TheDJ (talk • contribs) 09:47, 27 September 2018 (UTC)[reply]
• Support. Certainly seems like a good idea and don't see why not.--SkyGazer 512 ^{Oh no, what did I do this time?} 19:29, 27 September 2018 (UTC)[reply]

• So, I supported above, so would someone else review and close this. Note, this will not result in an access change directly - but will be used to show community support for this use case in Wikipedia:Bots/Requests for approval/MusikBot II 2. — xaosflux ^Talk 04:32, 30 September 2018 (UTC)[reply]