Wikipedia talk:Interface administrators

This is the talk page for discussing improvements to the Interface administrators page.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

WT:INTADMIN

Archives: 1, 2, 3: 30 days

Explicitly mention that Bureacrats have/can grant Interface admin rights?

According to User:Izno, 'crats can grant interface admin rights, but this page doesn't mention that anywhere that I could easily see. I would have directly fixed it myself, but am not deeply familiar with the permissions or implications. ~ 🦝 Shushugah (he/him • talk) 23:04, 8 June 2022 (UTC)[reply]

@Shushugah It is the second bullet on Wikipedia:Bureaucrats already; this page is similar to Wikipedia:Administrators in the regard to how it explains things. — xaosflux ^Talk 00:31, 9 June 2022 (UTC)[reply]

Clarify the right can be refused

Per my comments at BN the existing policy imposes a waiting period without actually granting bureaucrats the ability to say no, or defining when they can. To clarify that issue, I propose adding the following text to the policy: The request will remain open for 48 hours for first-time requests, and if there is community consensus against granting, bureaucrats may decline to grant access.

Don't think this needs a formal RfC, but not going to update without starting a discussion. TonyBallioni (talk) 00:47, 16 June 2022 (UTC)[reply]

(see Special:PermaLink/1093342938) It should be for "at least" 48 hours, the # of hours isn't capped. These typically don't get much advertisement, etc - so I don't expect there to be much of a gauge of "community" consensus that would need to arise to defeat it in such a short time. I'd like to not make this too "bureaucratic", something along the lines of if a 'crat has concerns, then an additional/extended consensus discussion should occur. Keeps the expectation that the default is YES, leaves a safety valve, but ultimately puts it in the hands of the community. — xaosflux ^Talk 00:57, 16 June 2022 (UTC)[reply]

Yeah, I'm fine with whatever and agree with what you're saying. I just don't think we've ever had one opposed before, even by a crank, so worth clarifying that there's a way for it to be refused, so I think we should at least say something relating to that somewhere. TonyBallioni (talk) 01:00, 16 June 2022 (UTC)[reply]

Even if it's perhaps against my personal interest, I support both the basic idea of the clarification ('crats should have some discretion) and Xaosflux's interpretation. {{Nihiltres |talk |edits}} 01:27, 16 June 2022 (UTC)[reply]

Hmm, I'm not sure this is needed. The current policy states: All editors may discuss the applicant, but the final decision rests with the reviewing bureaucrat. I interpret that to mean that individual bureaucrats may accept or decline any request at their discretion, regardless of what the community-at-large thinks (although I'm sure bureaucrats would not deliberately ignore a clear community consensus). This is similar to how WP:PERM operates: regardless of what people comment, the final decision on requests is by the reviewing admin. The proposed wording seems to restrict the ability of bureaucrats to decline only to situations where there is community consensus against granting, so it seems like this change would have the effect of limiting what bureaucrats can currently do. Mz7 (talk) 01:47, 16 June 2022 (UTC)[reply]

I think that 'crats should have the discretion to decline a request, either based on the community comments or their own findings. I support any changes or clarifications needed to implement that. If it turns out an RFC is needed, please ping me as I don't anticipate watching this discussion. Thryduulf (talk) 02:00, 16 June 2022 (UTC)[reply]

I feel that "the final decision rests with the reviewing bureaucrat" is fairly explicit that a Crat can either grant or refuse the request. And the grounds for refusal are given in the Background section. If a user meets the criteria: "highly trusted, have at least a basic understanding of JS and CSS, are aware of the privacy expectations of Wikimedia wikis, and have a decent understanding of how to secure their accounts" they will be granted the right, if they fail in one of those criteria they will be refused the right. There is a discussion as to if Nihiltres can be trusted given that they made a mistake; and the consensus is that they can be trusted because they cleaned up their mistake and have made no others. The process seems to be working fine. If people wish to amend the wording to make it clearer, they can do so; as long as they are not altering the implications of the wording then there is no need to seek consensus. Wording such as: "If the consensus is that the administrator is not highly trusted, or does not have at least a basic understanding of JS and CSS, or is not aware of the privacy expectations of Wikimedia wikis, or does not have a decent understanding of how to secure their accounts, then the right will not be granted" could be added for clarity.

I agree with Xaosflux that "at least" should be added before "48 hours". As it stands it could be interpreted that after 48 hours the request is automatically closed, and if the request has not been granted, it could default to not being completed, so a fresh request would need to be made. SilkTork (talk) 02:04, 16 June 2022 (UTC)[reply]

Should it be "grant if there is consensus" or "don't grant if there is consensus against"? and if there is community consensus against granting, bureaucrats may decline to grant access. could be interpreted as "bureaucrats must grant if there is no consensus". Jo-Jo Eumerus (talk) 10:54, 16 June 2022 (UTC)[reply]

@Jo-Jo Eumerus similar to WP:PERM we don't normally have a consensus measuring discussion around these, the prior RfC consensus leaned towards 'crat discretion; just like if I declined someone at WP:PERM - if a consensus arrived via discussion some other admin would do it. — xaosflux ^Talk 13:40, 16 June 2022 (UTC)[reply]

"the final decision rests with the reviewing bureaucrat" feels pretty unambiguous to me. It feels like a normal item that you would get at WP:PERM, with an added previso of at least 48 hours given for the community to comment if there is reasons to deny. Whilst WP:BN isn't the most trafficked place, it certainly gets enough views to know if the community as a whole has reasons to deny the request. If the time is a big deal - make it a week. Requests at WP:PERM only require the closing admin to see if the user can be trusted and other users can weigh in on the request. Although, and if there is community consensus against granting, bureaucrats may decline to grant access, this suggests to me that a crat wouldn't have a choice but to award the perm if there was no further discussion about it. Lee Vilenski ^{(talk • contribs)} 11:27, 17 June 2022 (UTC)[reply]

We are volunteers, so we always have a choice.

The default is that the right will be given as long as there are no objections because the right used to be part of every admin's toolkit. It was decided (not by the community if I recall, but by WMF) that letting every admin, including those randomly appointed by Jimbo way back when, have access to the tool might be problematic. While more recently appointed admins would be deemed to have the common sense not to switch on the chain saw if they didn't know how to use it, there was clearly a suspicion by WMF that some of the early admins were idiots. As such the situation is that an admin has to request the tool, and that request should in itself be sufficient to allay any concerns - however, just to be sure, there is a 48 hour hold so people can come forward with evidence that the admin is in fact an idiot. If nobody does come forward, we can simply flick the switch (or leave it for somebody else if we don't fancy it, or don't understand the implications).

By policy we are not allowed to give ourselves the right, though technically we can. It's kind of interesting that we are trusted enough not to give ourselves the right, but not trusted to give ourselves the right. I assume it is simply an error that we have been left with the ability to grant ourselves the right. SilkTork (talk) 13:31, 19 June 2022 (UTC)[reply]

@SilkTork it is mostly that it is extra layers of technical controls that would be needed to also add in a "but not to yourself" check that aren't really necessary - if someone with granting access was up to no good could they could just give access to an alt account and bypass the whole thing anyway. — xaosflux ^Talk 13:48, 19 June 2022 (UTC)[reply]

I agree with your generally process overview - basically if a processing 'crat declines it can be a subtle statement of "it's possible that you actually are an idiot", of which other 'crats can overrule by just granting it (especially following some community input). — xaosflux ^Talk 13:50, 19 June 2022 —(UTC)

On a side note, the MediaWiki developers provided the capability, but left it up to the local wiki communities to decide on how to assign the privilege (see Wikipedia:Village pump (miscellaneous)/Archive 59 § New user group for editing sitewide CSS/JS and m:Creation of separate user group for editing sitewide_CSS/JS). All the decisions on the granting process were made by the community (see the archives for this talk page). isaacl (talk) 16:28, 19 June 2022 (UTC)[reply]

You'll know more about this than me isaacl. My understanding is that the right already existed within the admin toolkit, but that the "MediaWiki developers" (I'm not quite sure where they stand in the Wikipedia world, but as they are MediaWiki - which is a part of WMF - I tend to think of them as part of WMF rather than Wikipedia, though I think that is possibly a murky area - are some developers volunteers and some paid by WMF?) took the right away from Wikipedia admins because they decided it was a security risk. My understanding (and please correct me if I am wrong), is that this was done without consultation with the Wikipedia community. My understanding (and, again, correct me if I am wrong - this is not an area I tend to get involved in) is that the Wikipedia community then looked at a way for the right to be restored to admins, and the consensus was that the right could be restored on application with a simple 48 hour pause to see if there were any objections. Essentially, every admin on Wikipedia could apply for the right and, pending nobody declaring that any of them were idiots, it could be given to them. We could, in theory, restore the right to every admin on Wikipedia in a 48 hour period. And, I suppose, the "MediaWiki developers" (WMF?) would be perfectly OK with that as we would have followed the agreed Wikipedia procedure. Or, do you suspect that there would be an objection because there would be a risk that some of the admins are not to be trusted (by the WMF, as I assume they are trusted by the community otherwise they would not still be admins)? SilkTork (talk) 18:13, 20 June 2022 (UTC)[reply]

@SilkTork tangentially related, WMF (the owners of the servers) require that anyone that wants int-admin must use 2FA - so all those admins would need to activate that first. — xaosflux ^Talk 18:52, 20 June 2022 (UTC)[reply]

While I wouldn't have been surprised if this were the case, the only guidance I can find came from Tgr in their role as a MediaWiki developer. As far as I recall (and as I can see in a quick skim of the archive), there was consensus support on English Wikipedia for requiring two-factor authentication for interface admins, in recognition of the extreme power of being able to cause malicious Javascript to run within user browsers. isaacl (talk) 20:55, 20 June 2022 (UTC)[reply]

The 2FA is a global requirement for every project, there are a few roles requiring it - see the banner at meta:Interface_administrators. — xaosflux ^Talk 22:21, 20 June 2022 (UTC)[reply]

Thanks for the reference; that makes sense to me. I see that the note was added in December 2018, after the granting process had reached consensus here. isaacl (talk) 22:59, 20 June 2022 (UTC)[reply]

The meta page I linked to has links to the corresponding Phabricator ticket and wikitech mailing list discussion. As far as I can tell, Tgr created the feature on their own initiative in order to improve security, which involved creating a new user privilege (which yes, made it possible to keep admins from editing the site-wide Javascript and CSS pages). It's true that the MediaWiki developers considered the rollout to be under their purview, as a security matter, and so only held what was in essence an advisory consultation on meta. Wikipedia talk:Interface administrators/Archive 2 § RfC: Approving the updated proposal has the English Wikipedia discussion for the final process (replacing the stop gap process, which the community put in place to ensure that someone would able to edit the pages in scope during the interim) which did, as you stated, approve a process where "[b]ureaucrats are authorized" to grant the interface administrator permission upon request after a 48-hour waiting period. Whoever is responsible for security at the WMF might have opinions, but as far as I can tell, the community remains free to decide for itself on the process. isaacl (talk) 21:32, 20 June 2022 (UTC)[reply]

This seems fine (both the original proposal, and the "at least" for the time). More specifics beyond that required seems unneeded, but TB is right that best to have a "why do we need this" then need to hash out the changes at the same time as the problem. Nosebagbear (talk) 12:34, 24 June 2022 (UTC)[reply]
I'm okay with the proposed change to the wording of the policy for clarity purposes; I see no harm in making details more clear if they seem to be ambiguous, and adding a WP:SNOW clause to the policy's wording seems reasonable. I agree with what Nosebagbear stated above, in that "[m]ore specifics beyond that required seems unneeded, but TB is right that [it's] best to have a 'why do we need this'". ~Oshwah~^{(talk) (contribs)} 02:52, 4 July 2022 (UTC)[reply]

RFC: Increase inactivity requirement

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is clear consensus to increase the inactivity requirement to 12 months. As a result, interface administrators who have made no edits or other logged actions for at least 2 months, or who have made no edits using the permission for at least 12 months, should have their user right removed. Those who opposed this change argued that the current inactivity level suffices, citing the sensitive nature of the permission and its ease of restoration through a request at WP:BN. (non-admin closure) – DreamRimmer (talk) 02:30, 29 February 2024 (UTC)[reply]

Proposed:

In: Interface administrators who have made no edits or other logged actions for at least 2 months or who have made no edits using the permission for at least 6 months should have the user right removed.

Change to Interface administrators who have made no edits or other logged actions for at least 2 months or who have made no edits using the permission for at least ~~6 months~~12 months should have the user right removed.

Recent discussion: Special:PermaLink/1200817440

Proposed reasoning: interface-admin actions are not very high, but are generally productive. For editors that are still generally active, but have less frequent interface updates having them have to re-request when needed is counterproductive. We currently have <10 int-admins, and this change is not expected to cause us to have 'too many' as the total-inactivity threshold is still low. — xaosflux ^Talk 11:23, 30 January 2024 (UTC)[reply]

Support

As proposed. — xaosflux ^Talk 11:23, 30 January 2024 (UTC)[reply]
I have no problem with the proposed change. The 2 month requirement could be seen as unnecessarily stringent too — Martin (MSGJ · talk) 12:20, 30 January 2024 (UTC)[reply]
Support Per what I said in the other discussion about being an infrequent user as a gadget maintainer and there being very few intadmins. Galobtter (talk) 14:01, 30 January 2024 (UTC)[reply]
Support - Also why do we have a two-month requirement? It seems WAY too strict. I think that editing requirements more similar to WP:INACTIVITY would better suit interface administrators: (1) Has made neither edits nor administrative actions for at least a 12-month period. (2) Has made fewer than 100 edits over a 60-month period. Somebody tell me why this wouldn't work supposing (2) were bumped up to 1000 edits or so. Schierbecker (talk) 17:03, 30 January 2024 (UTC)[reply]
The idea behind the 2-month requirement is probably to ensure that the user is still around. A completely dormant account is a bigger risk, since its legitimate user won't know if there are attempts to break in, as well as the fact that a user who abandoned their account won't suddenly changes the password; a completely inactive account is indistinguishable from a dormant one. Animal lover |666| 00:33, 2 February 2024 (UTC)[reply]
Support, though I'm fine with the 2-month general inactivity requirement. It's hard to overstate how potentially dangerous the intadmin right is, so it makes sense to remove it at the first sign of overall inactivity. It's just that use of the intadmin bit itself doesn't really come up super often, so the tool-use requirement needs a bit of calibration. Writ Keeper ⚇♔ 17:12, 30 January 2024 (UTC)[reply]
Support. I think there are multiple intadmins whose primary activity is to be the maintainer of a major gadget. Updates to that gadget can go more than 6 months without a deploy sometimes, so it is easy to lapse intadmin. {{IAER}}s aren't always great for updating major gadgets either. Sometimes the gadgets have custom deploy scripts that only one or two people know how to use. –Novem Linguae (talk) 17:31, 30 January 2024 (UTC)[reply]
'Support Volume of requests is not high. Hawkeye7 (discuss) 01:10, 31 January 2024 (UTC)[reply]
Support, in deference to Xaosflux's judgement. I'm not familiar with interface admin actions enough to be able to evaluate this independently, but I trust Xaosflux as one of the admins most active in that area, and the proposal sounds reasonable. {{u|Sdkb}} ^talk 05:16, 31 January 2024 (UTC)[reply]
Support, relatively strict overall activity requirements should remain in place, but there is much less need for "edits using the permission" to be so tightly monitored. CMD (talk) 05:26, 31 January 2024 (UTC)[reply]
Support Low volume of requests & security considerations, it's the logical thing to do -Fastily 06:50, 31 January 2024 (UTC)[reply]
Support Seems like a very reasonable change. The Wordsmith^{Talk to me} 16:54, 31 January 2024 (UTC)[reply]
Support users who are still active on the wiki shouldn't need to re-request rights if they don't use them too frequently but are still around --DannyS712 (talk) 22:19, 31 January 2024 (UTC)[reply]
Support, seems reasonable, and doesn't add any extra risks. There are extra risks with unused accounts, so let's keep that separate. -- zzuuzz ^(talk) 00:14, 1 February 2024 (UTC)[reply]
Support I think this is reasonable. The amount of actions is indeed pretty low, and if a person has an activity spike, they can easily dominate the amount of actions handled compared to the others. —TheDJ (talk • contribs) 09:47, 1 February 2024 (UTC)[reply]
Support per above. Stifle (talk) 12:03, 1 February 2024 (UTC)[reply]
Support Even retaining the "2 months" looks too strict. In general we need closer scrutiny that this and other admins don't get rusty but a very short deadline for using the tools is not the way to do that. North8000 (talk) 18:12, 1 February 2024 (UTC)[reply]
Support - there are only 3 legitimate reasons to make such requirements, in my opinion: to keep the site safe from account break-ins, to prevent low-activity users from taking action which violates recent changes to the rules, and go prevent the illusion of many users with the right from deterring nee users from requesting (or being granted) the right. The first is handled by the requirement of any action, the second is of low relevance (it's more of a concern for regular adminsbip), and with only 10 such users it should be clear we need many more. Animal lover |666| 00:48, 2 February 2024 (UTC)[reply]
Support: the purpose of the activity requirements are to ensure that the iadmin is active and has use for the tools. Adding bureaucracy and waiting time to active gadget maintainers who may not happen to use the tools every 6 months is not desirable. We have (and under the change still would have) quite few iadmins so the security risk is low (I'd say there's a higher risk in crat accounts/crat activity requirements). — Bilorv (talk) 21:39, 4 February 2024 (UTC)[reply]
Support: This seems like a minor, well thought out, and reasonable change. ++Lar: t/c 00:12, 6 February 2024 (UTC)[reply]
Support The proposed amendment is understandable. Jerium (talk) 13:25, 6 February 2024 (UTC)[reply]
Support Seems quite reasonable now that we have been able to see what the workload on interface administrators really is. Callanecc (talk • contribs • logs) 04:10, 11 February 2024 (UTC)[reply]
Support Seems reasonable to me. The benefits outweigh the risks, as they say. DarmaniLink (talk) 05:10, 19 February 2024 (UTC)[reply]
Support People who are clearly still here shouldn't be penalized for not making reckless changes to fulfill a quota. Twelve months is a sufficient time period to extend this to, given the requirement that they make an edit or logged action within the last two months still exists. EggRoll97 ^(talk) 05:14, 21 February 2024 (UTC)[reply]
If a userright was created because it's meant to be used sparingly and for exceptional reasons, it's reasonable you could go a year without using it. –xeno^talk 18:21, 24 February 2024 (UTC)[reply]

Oppose

Weak oppose, Given the absurdly low bar that we have for recieving intadmin privileges amongst administrators, and the relative sensitive nature of the permission, it makes sense to have a higher than normal activity requirement. While I don't have any issues with the current cohort retaining permissions indefinitely, the fact that an admin could theoretically have zero technical contributions for over a year (and with just 6 normal edits over the same period) and still be able to make major unsupervised changes to widely used gadgets is scary to me. Sohom (talk) 08:51, 1 February 2024 (UTC)[reply]
Weakly. Basically what Pppery said in the previous IANB convo (this comment, although I think 6 is the right number): an IA account is a security risk, and if it ain't being used, it's better to revolve the doors a bit. I'm fine if Xaosflux drags his feet a bit when the de-intadmin-ing comes up—it's not dire—but if anything it's an argument to up the number of Bureaucrats. If it's a gadget or script that needs doing, a slight wait for a 'crat to show up at BN ain't a bit deal. There's no waiting period for renewal, no stigma for renewal with a need that previously going inactive affects, and the presumably rotating cast is a subset of a subset, and a well-known one at that. I'm not a 'crat, but I imagine the double-asking that 2FA is still on might be the most annoying part. As for the (not-up-for-this-RFC) 2 month thing, I could see 3 months being better. ~ Amory (u • t • c) 20:20, 1 February 2024 (UTC)[reply]
On the other hand, more crats = more people with intadmin-level access (since crats can self-assign), no? Galobtter (talk) 20:30, 1 February 2024 (UTC)[reply]
Well, I spent maybe two whole minutes debating whether to end that sentence with an exclamation point or not to emphasize the cheekiness of it, so time poorly spent! But sure, that's an argument you could make to just match the IA policy with the Crat policy (plus 2FA), or vice-versa I guess. Solving different problems. A (non-security-related) counter-point is that, for any given sysop, IA is dramatically easier to obtain. ~ Amory (u • t • c) 20:50, 1 February 2024 (UTC)[reply]
The premise of this request is that there is a shortage of interface admin work needing doing. The fact that we are less than six months after the time when there were 3-month-old interface-protected edit requests (!) shows that said premise is false. * Pppery * _{it has begun...} 01:50, 2 February 2024 (UTC)[reply]
Oppose: I agree with Sohom Datta's concerns (but don't find them "weak"). Having this permission removed for inactivity would basically mean nearly nothing to anyone, since if an admin who got busy in real life came back, they could just request the permission again and be nearly automatically regranted it, absent some compelling reason to not regrant it (like misuse of it earlier that arguably should have resulted in its removal-for-cause). — SMcCandlish ☏ ¢ 😼 13:25, 21 February 2024 (UTC)[reply]

Discussion

An important balance for security is that we should not have too many of these users, and the current requirements were built along those lines. It has been quite some time now, and we are not seeing administrators using this role as some sort of hat-collection (not surprised, as we don't expect that sort of behavior from our admins...). Some of our int-admins deal with infrequent issues such as maintaining certain gadgets. — xaosflux ^Talk 11:30, 30 January 2024 (UTC)[reply]
Are we restoring rights to intadmins (if any) who lapsed under the six-month policy but never fell afoul of the new proposed policy? Schierbecker (talk) 17:53, 30 January 2024 (UTC)[reply]
Given that they could already just ask for it back at BN, I doubt that's necessary. Writ Keeper ⚇♔ 17:58, 30 January 2024 (UTC)[reply]
Agreed. I think keeping the rfc simple and as-is is a good idea. –Novem Linguae (talk) 17:59, 30 January 2024 (UTC)[reply]

No, this is really just to stop future revolving doors at WP:BN. — xaosflux ^Talk 18:06, 30 January 2024 (UTC)[reply]
AIUI the system at the English Wikisource is a bit different, and it has some security advantages: They have a list of folks who are eligible for this user right, and when you need it, you set the bit, do your work, and then remove it. When you don't need it, you're not doing your everyday work with all your privs enabled. I don't know how much hassle this would be, especially if you have to ask someone else to enable it for you, but it might be worth thinking about. WhatamIdoing (talk) 00:23, 7 February 2024 (UTC)[reply]
@WhatamIdoing I just checked the last year of the userrights log at enwikisource and don't see a single instance of that behavior - and only enwikisource 'crats can change that flag; additionally I see an enwikisource intadmin with no use in over a year there --- so I don't think this is what you are thinking of? Perhaps you are thinking of the 'flood' flag? — xaosflux ^Talk 00:32, 7 February 2024 (UTC)[reply]
Billinghurst should be able to tell us if my memory is wrong. It's been a long time since I heard about this. WhatamIdoing (talk) 02:04, 7 February 2024 (UTC)[reply]
Comment: We don't typically do much editing in that space. Before we more formally discussed, we had a short term right allocation on request to the community, with light touch assessment by 'crat, noting a lot smaller community of admins, and less fiddlers. We didn't and have not had self-set IA. We have self-set AF and flood rights for admins. Typically we don't want that many permanent IA rights, and don't typically have a need. — billinghurst sDrewth 02:29, 12 February 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.