Wikipedia:Interface administrators' noticeboard

Archives

Archive 1 Archive 2 Archive 3

This page has archives. Sections older than 30 days may be automatically archived by Lowercase sigmabot III when more than 3 sections are present.

The following interface administrator(s) are inactive:

• DErenrich-WMF (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)

— JJMC89 bot 23:18, 28 March 2025 (UTC)

WMF access, exempt. — xaosflux ^Talk 09:12, 29 March 2025 (UTC)

Just a note, that the already required 2FA access for group members, is now being enforced by the software. If an int-admin doesn't have 2FA enabled, your int-admin permission will be listed as "disabled" (only when you view your own groups) - and the access will not be available until you enable 2FA. Thank you, — xaosflux ^Talk 22:55, 29 March 2025 (UTC)

What's stopping the attacker setting up their own 2FA, if you have it disabled? Re-enabling intadmin after 2FA is disabled should require some kind of third party (e.g. crat or steward), otherwise this seems like security theater. The only scenario where this might help is when the attacker wants to "quietly" use your privileges without you noticing. That might make a bit of sense for oversight access, but for intadmin, what can the attacker do beside leave a very public trail of edited pages? Suffusion of Yellow (talk) 23:10, 29 March 2025 (UTC)

I'm just the messenger here. Feel free to open more feature requests to help improve the process. — xaosflux ^Talk 23:30, 29 March 2025 (UTC)

Yep, more a question for the crowd, than you specifically. Suffusion of Yellow (talk) 23:43, 29 March 2025 (UTC)

I think the point here is to force folks to adopt what is a genuine improvement in account security (in case they weren't already). We should not be dismissing this as needless security theater even if a specific attack scenario ("what if the account was already compromised") was not considered. Sohom (talk) 23:34, 29 March 2025 (UTC)

I ... guess. But I hope it's made clear at the time you are disabling 2FA that re-enabling it will let your account regain access to intadmin privileges. Otherwise it might provide a false sense of security: "I'm not going to use the bit anyway in the next few months, so I'll just disable 2FA now." Suffusion of Yellow (talk) 23:49, 29 March 2025 (UTC)

Notably, currently the only supported way to change authentication devices is to remove/reactivate - we certainly wouldn't want everyone doing that having to go see granters again (who also would have no way to know that the request wasn't from a theoretical compromised account). — xaosflux ^Talk 00:23, 30 March 2025 (UTC)

Moved from Wikipedia:Village pump (technical)/Archive 219 § Gadget to hide decorative sticky elements

 – Aaron Liu (talk) 16:18, 28 April 2025 (UTC)

Per Special:GoToComment/c-AntiCompositeNumber-20250420003300-RfC:_allowing_editors_to_opt-out_of_seeing_floating_decorative_elements, we should have a gadget labeled "Hide decorative sticky elements" that consists of the following CSS file:

.sticky-decoration {display:none !important;}

Aaron Liu (talk) 01:49, 20 April 2025 (UTC)

I had made a thingy at User:HouseBlaster/sandbox.css. I propose and support simply making that into a gadget. Best, HouseBlaster (talk • he/they) 02:01, 20 April 2025 (UTC)

For reference, the line of CSS I gave is the same exact thing but with 200% the spaces. Though, I also just changed my line of CSS to say "sticky-decoration" instead of "floating-decoration". Aaron Liu (talk) 04:19, 20 April 2025 (UTC)

There was no opposition to the suggestions of creating a gadget to opt-out and for other editors to edit user pages to implement the class, but these issues did not have significant discussion. does not support the creation of a gadget, so I suppose you're taking up the suggestion? A one liner isn't really what we should support gadgets for, and it really is a one liner. Izno (talk) 04:36, 20 April 2025 (UTC)

Normally I would agree with you. I think that telling people, in an official guideline, to go and check a box in their preferences is far superior to telling them to fiddle with their CSS. Best, HouseBlaster (talk • he/they) 04:40, 20 April 2025 (UTC)

I agree, especially since this is a matter of accessibility. jlwoodwa (talk) 07:21, 20 April 2025 (UTC)

Just curious, but the RfC was about user pages, but are there any legitimate uses of these "position: <absolute|sticky|fixed>;" elements elsewhere? I know I have been meaning to get the up/down skip buttons used on WP:HD and WP:TEA adjusted so they don't obscure the mobile/desktop toggle. Commander Keane (talk) 07:31, 20 April 2025 (UTC)

The skip buttons you mention were brought up in the RfC statement as one example of legitimate use. Aaron Liu (talk) 14:46, 20 April 2025 (UTC)

Support making that into a gadget as well. * Pppery * _{it has begun...} 13:46, 20 April 2025 (UTC)

Support, I guess. Though, this seems like a fool's errand, as editors can and will create new elements regularly, and these won't be with the class sticky-decoration (or whatever class name), so the gadget will do nothing. Gonnym (talk) 13:55, 20 April 2025 (UTC)

The new section (WP:DecoFloat) created by that RfC which thus is now a guideline says that such new elements should have that class, and another thing unopposed (though not really discussed) in the RfC is that editors should be able to drive by and add the class. I'm sure opt-outers would gnome every example of such stickies. Aaron Liu (talk) 14:46, 20 April 2025 (UTC)

That's all fine. As an editor who fixes lint and other errors, I doubt most people that add those annoying features are going to add the class, which then falls upon gnomes and other editors to fix those horrible features. So we require at least two steps for editors to not view these, and yet still non-registered users can't hide them. Gonnym (talk) 14:49, 20 April 2025 (UTC)

I feel like most of this was already discussed in the RfC. There's no independent merits you've brought up that only apply to the gadget proposal and not the RfC. Aaron Liu (talk) 15:01, 20 April 2025 (UTC)

Well then, you know what. I completely oppose on the ground that I think this will do nothing and is completely pointless. Hope that helps. Gonnym (talk) 18:29, 20 April 2025 (UTC)

If the usage on user pages is deemed a significant accessibility issue, then personally I think the elements in question should be hidden by default, and users can opt into seeing them. If there isn't enough usage to make it a significant accessibility issue, then I think the drawback of adding an additional gadget isn't warranted. isaacl (talk) 16:58, 20 April 2025 (UTC)

Don't let the perfect be the enemy of the good. jlwoodwa (talk) 17:12, 20 April 2025 (UTC)

Managing accessibility concerns is about managing tradeoffs. Neither approach is perfect. In my opinion, if the accessibility issue is significant, then the better tradeoff is to let people opt into the problem, rather than opt out of it. isaacl (talk) 18:00, 20 April 2025 (UTC)

We just had this discussion at the RfC... Elli (talk | contribs) 20:28, 20 April 2025 (UTC)

Just raising a specific point regarding the relative tradeoffs for managing accessibility, which was not discussed during the previous RfC. (As noted in the summary, detailed discussion of a gadget did not take place.) isaacl (talk) 18:03, 21 April 2025 (UTC)

It's only a significant issue for a significant but small percentage of users; I think it's worth the drawback (I presume you just mean the preferences table and the in-this-case-tiny burden on intadmins). The significant drawbacks of having such elements be hidden by default have been discussed in the RfC. Aaron Liu (talk) 17:57, 20 April 2025 (UTC)

Since we're apparently doing the bold-face thing, I support making this into a gadget. If anyone thinks it should be default-on, we can have an RFC about that later. In the meantime the gadget will help those who wouldn't know display: none; from background: url(https://fsb.ru/1x1.png) enable an accessibility feature without worrying. Suffusion of Yellow (talk) 21:04, 22 April 2025 (UTC)

Moved this here so that we can get an implementable result on whether to add this gadget, hopefully that's not improper. Aaron Liu (talk) 16:20, 28 April 2025 (UTC)

I will note that as of the moment, we have 3 usages of the class across user CSS pages (two of which are the same user). Do we want to wait for more widespread usage before declaring it a gadget ? Sohom (talk) 22:04, 28 April 2025 (UTC)

For context, .rootpage-Wikipedia_Articles_for_deletion .afd-help sees 58 uses, .ambox-Orphan has 185 uses, non of them have standalone gadgets Sohom (talk) 22:14, 28 April 2025 (UTC)

Neither of those is an accessibility issue though. jlwoodwa (talk) 22:14, 28 April 2025 (UTC)

Yes, agreed, I was think out aloud. I don't disagree that we should have this gadget at some point, but I feel like doing it now feels premature given that we have a total of 26 user-pages wrapping elements and 2 CSS pages that use this. Personally, the outcome I would want would be for us stay this proposal for a few more months and then come back to it when we have significant adoption (both across userpages and user CSSes). In the current state, the guideline/gadget will be making a false promise (hiding sticky elements for a majority of the cases). Sohom (talk) 22:29, 28 April 2025 (UTC)

The following interface administrator(s) are inactive:

• DErenrich-WMF (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
• Galobtter (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)

— JJMC89 bot 23:20, 28 April 2025 (UTC)

• First is exempt, later is  Done — xaosflux ^Talk 00:19, 29 April 2025 (UTC)

  That said, this "exempt" situation propping up every month is problematic, so I might as well ask: @DErenrich-WMF: do you still need interface admin rights here? You don't seem to have used them since September. @JSutherland (WMF): Did you really intend to grant Daniel permanent interface admin rights? Most WMF grants of rights on community wikis are temporary. * Pppery * _{it has begun...} 00:55, 29 April 2025 (UTC)