Stewards' noticeboard/Archives/2023-04

CheckUser activity proposal

For all readers of this noticeboard and the stewards themselves, there is now an GRfC about CheckUser activity requirements globally. Please see and comment at Requests for comment/CheckUser activity RFC. -- Amanda (she/her) 22:13, 15 April 2023 (UTC)

Need assistance for admin removal, admin procedure on Swahili wikipedia

Hi 1) on Swahili wikipedia we have to remove user:Manguboy as admin after 12 months of inactivity. This period was agreed per vote in 2020, see sw:Wikipedia:Wakabidhi/5#A.)_Pendekezo_la_kuwa_na_wakabidhi_hai_KURA_IMEFUNGWA.

2) Is it possible that we can make such changes ourselves at swwiki? Presently we still have the system that active admins just continue; as bureaucrat I can give new ones the rights (we just elected 4 additional ones) but for removal we always have to come here. Cheers Kipala (talk) 02:36, 27 April 2023 (UTC)

On de-wp we changed this recently. https://phabricator.wikimedia.org/T331921 Developers demand a "community concensus". Der-Wir-Ing ("DWI") talk 02:40, 27 April 2023 (UTC)

1) You can request admin removals at SRP#Removal of access linking your local inactivity policy.

2) Per Limits to configuration changes#Changes that are likely to be declined swwiki [1] will likely be determined not large enough to allow Bureaucrats to remove administrator access. There are just a few content wikis where this ability is granted to local crats: Bureaucrat#Removing access. Johannnes89 (talk) 05:54, 27 April 2023 (UTC)

@Kipala Assuming you have a published inactivity policy, and that someone is inactive - for "smaller" projects the process is to just list them at Steward_requests/Permissions#Removal of access and a steward will usually handle it within a day. — xaosflux ^Talk 09:16, 27 April 2023 (UTC)

This section was archived on a request by: Information provided. — xaosflux ^Talk 09:47, 15 May 2023 (UTC)

Aromanian Wikipedia administration status

Hello all,

I would like to ask if there is a possibility to add me as the administrator of Aromanian Wikipedia (roa-rup.wikipedia.org), since the current administrator is not responding and I would like to be able to translate the Wikipedia system messages into Aromanian, since they have been left in Romanian.

Thank you! Moscopolitanus (talk) 09:38, 28 April 2023 (UTC)

@Moscopolitanus there is no active sysop on this wiki [2] (and it appears there has not been one since 2007). Filtru abuz which you contacted [3] is just the local account for the Abuse filter extension.

You might want to read MVR and roa-rup:Wikipedia:Requests for adminship to learn how to apply for adminship at your local wiki. --Johannnes89 (talk) 12:20, 28 April 2023 (UTC)

This section was archived on a request by: Information provided. — xaosflux ^Talk 09:48, 15 May 2023 (UTC)

Need assistance with posting RFC notice

I have been blocked on bnwiki and started an RfC reagrding this issue. I need to iniform the bnwiki admins on the admin's noticeboard. Can anyone help me post the notice on that page using a neutral tone? If needed, I will write the text in Bangla for them who can help me. -- BIDROHI ^Hello.. 06:38, 14 April 2023 (UTC)

I’m requesting steward action to lift my unjust block on bnwiki as stated in this RfC. I’ve been blocked without the slightest hint of the reason, and there is no public discussion about this. This block is keeping me away from my constructive wikimedia organizing activities; for example, I’m currently leading my team in this campaign on bnwiki and am planning another campaign in the next few months. I have not engaged in any type of non constructive editing and since this uncalled block involves something that the involved admins claim is based on off-wiki evidence, I'd be glad to cooperate with stewards in the investigation, as the RfC states, the admin action needs to be questioned. BIDROHI ^Hello.. 16:01, 22 April 2023 (UTC)

IP masking policy

Tracked in Phabricator:
Task T309992

Hello, all:

I'm in the process of getting translations for foundation:Policy:Access to temporary account IP addresses and Access to temporary account IP addresses FAQ. Thank you to those of you who have been helping me with that. There are a few details that aren't settled yet, including the format for temporary usernames and what the log will look like, but I wanted you all to be able to see this sooner, so it's not quite complete.

As you know, IP Editing: Privacy Enhancement and Abuse Mitigation ("IP masking") has been in the works for about five years now. We're headed towards the point where there will be a visible change. I don't have an exact timeline, but so far, I have been promised that it won't be on any of the content wikis before October 2023 (and maybe not even so soon), and that it won't be on any of the big content wikis during the first month (and maybe longer). In the meantime, please be thinking about which tools will break and which processes might need to be changed. Legal's policy says that the Stewards will be able to block IP access for individuals (apologies if this is news to you – I'm not sure what the past conversations said), so it's possible that the Stewards policy will need a minor update.

I'm happy to answer questions when I know them, and to ask others when I don't know them, so please let me know what else you want to know. Whatamidoing (WMF) (talk) 15:05, 19 April 2023 (UTC)

Thanks for the notification! :-) Vermont (🐿️—🏳️‍🌈) 16:34, 20 April 2023 (UTC)

A (slightly) more technical update has been posted at IP Editing: Privacy Enhancement and Abuse Mitigation/Updates#April 2023: The Plan for IP Masking. Whatamidoing (WMF) (talk) 22:08, 29 April 2023 (UTC)

@Whatamidoing (WMF): If I read “Legal's policy says that the Stewards will be able to block IP access for individuals” correctly and Access to temporary account IP addresses FAQ seems to prove me right, it's meant that only Stewards can remove IP access. With (tens of) thousands of accounts who might qualify (e.g., all reviewers of flagged revisions on dewiki) this increase the workload for stewards pretty much. And I don't see a good reason why trusted local functionaries, e.g. CheckUsers whose work is closed related to these activities, cannot be entrusted with removing such access on a local level. Imo, the principle of subsidarity should be taken into concern here as well. What do other stewards think about it? Pinging Vermont who had responded here. I took that into one of our next calls with WMF, i.e. Thursday. Best, —DerHexer (Talk) 15:48, 2 May 2023 (UTC)

@DerHexer, I imagine that Legal would be happy to extend this to others, especially if you can recommend other groups that they should include. I haven't spoken with them about this in particular, but I believe the key point is that this will be handled by trusted people in the communities and not the WMF. Whatamidoing (WMF) (talk) 18:37, 2 May 2023 (UTC)

At the least, I think that adding someone to a local block-ip-info group should go to all sysops; reason being: they can already site block someone and revoke their access that way and shouldn't have to use a hammer when a better tool exists. — xaosflux ^Talk 18:50, 2 May 2023 (UTC)

@NKohli (WMF), do you know whether it will be possible for an editor to reveal IP addresses while the account is blocked? I'd defer to the folks here, but offhand it sounds like a bad idea to me. Whatamidoing (WMF) (talk) 23:16, 2 May 2023 (UTC)

@Whatamidoing (WMF) event "partially blocked" users get blocked from using ip-info tool with the error you do not have permission to perform the action because your account is blocked (just confirmed on testwiki). So if an admin just partially blocks someone from any page, they lose this tool — xaosflux ^Talk 23:31, 2 May 2023 (UTC)

@Whatamidoing (WMF) sorry, I was misreading 2 different tools here, that is about the ip-info lookup tool (which really doesn't give out any private information today) - but yes I imagine we should block ip unmasking if user is blocked, regardless of this other grouping. — xaosflux ^Talk 23:34, 2 May 2023 (UTC)

Quick update: It sounds like Legal's okay with broadening this group. Do you have any advice on the best level (e.g., bureaucrats vs admins)? Whatamidoing (WMF) (talk) 04:56, 16 May 2023 (UTC)

@Whatamidoing (WMF) want to make sure we're all on the same page now. Are you asking specifically about which group(s) should be allowed by default to manage membership of the local (no-ipinfo) group? That is the group that, if you are a member of, you will not be allowed to use the ipinfo-* permissions on a local project that you may have from other groups. — xaosflux ^Talk 10:02, 16 May 2023 (UTC)

Yes. Whatamidoing (WMF) (talk) 04:45, 18 May 2023 (UTC)

Whatamidoing, putting this in perspective: being added to (no-ipinfo) blocks a user's access to these permissions:

• Access given to all autoconfirmed users

  Access a basic view of the IP information attached to revisions or log entries (ipinfo-view-basic)

  Retrieve information about IP addresses attached to revisions or log entries (ipinfo)

  Making this trivially easy to get with alternative accounts

• Access given to to administrators and checkusers

  Access a full view of the IP information attached to revisions or log entries (ipinfo-view-full)

  If a project has a problem with their admin/CU this is likely fairly low on the list of problems.

• Access given to to administrators and checkusers

  View a log of who has accessed IP information (ipinfo-view-log)

  Even more then the prior one, if your checkuser needs to have this blocked, they probablly need to stop having all other checkuser powers

So what I think I'm getting at is that this local group is mostly useless, as the use cases that would lead to it getting used somewhere aren't that useful. Am I missing something here? — xaosflux ^Talk 15:13, 16 May 2023 (UTC)

It's possible that they're going to merge the -basic and -full rights (or keep them separate, but they'll do the same thing).

In addition to your list above, the -full user right will be available to any registered account with 300 edits + 6 months (or locally approved alternative). An admin or CU might not be likely to violate various rules against outing people, but even experienced contributors sometimes fall afoul of w:en:WP:OUTING. Whatamidoing (WMF) (talk) 04:51, 18 May 2023 (UTC)

@Whatamidoing (WMF) ok well, as this is about blocking some local permission, local administrators are probably fine to deal with this. Reasoning, if this could have a wide use case given then options of "use this" or "just siteblock someone", if the admins only have the later tool they will probably just use that. — xaosflux ^Talk 09:53, 18 May 2023 (UTC)

@Whatamidoing (WMF) as far as the 300/6 - assuming that is just going to be some autopromote group, and that such a group's membership can just be revoked by admins as well? (Going back to the use case of is this block ipinfo basically useless locally)? Who should be able to manage this is a question that should be answered, but the missing question is when would this (no-ipinfo) ever be used? — xaosflux ^Talk 10:28, 18 May 2023 (UTC)

If it will be an implicit group (like autoconfirmed) I suppose it could still be useful locally to undo that. — xaosflux ^Talk 10:29, 18 May 2023 (UTC)

I'm not sure whether it's going to be structured technically so that it's like autoconfirmed but can be overridden by assigning a second user right, or if it'll be something that you get, and that can be taken away. But regardless of the mechanism, it'd be normal in MediaWiki to create config/variable that says who can set/revoke it, so we could set any group we wanted. Admins rather the buros, I think? Whatamidoing (WMF) (talk) 04:56, 20 May 2023 (UTC)

@Whatamidoing (WMF) perhaps crat by default, but for WMF wiki's this seems like something for admins; additionally if this is something we expect T&S to be pushing on users it may need a global group (as opposed to trying to manually put it on a user on hundreds of projects for example) - that one would certainly be stewards. — xaosflux ^Talk 16:54, 20 May 2023 (UTC)

Local admins. Many projects don't have crats, and for those that do the role varies significantly.

Xaosflux, in terms of the global bit, are you talking about a way to globally block people from IPinfo? Vermont (🐿️—🏳️‍🌈) 18:35, 20 May 2023 (UTC)

@Vermont yes, since a lot of this seems to be getting driven from WMF - the question is that if WMF is going to have a reason that someone needs to not have ipinfo on "all projects", we're going to need that (no way we're going to createlocal on hundreds of projects then add that group on hundreds of projects to someone). So either a global noipinfo for that case, or account locking is all that will be practical. From the use cases above, most of that would be a non-issue, except for the new auto-promote type group. — xaosflux ^Talk 19:48, 20 May 2023 (UTC)

Yep...it (hopefully) shouldn't be too difficult to make a global group to prohibit access to the ipinfo roights. Vermont (🐿️—🏳️‍🌈) 20:11, 20 May 2023 (UTC)

An interesting point. @NKohli (WMF), I think this is another point for your long list of details. If someone is "anti-trusted" on one wiki, we might want a way for that to filter up to others (even if it's just a bot posting messages). Whatamidoing (WMF) (talk) 18:06, 22 May 2023 (UTC)

phab:T337189 is open for building the global version of no-ipinfo. Policy/process for blocking someone globally on this would be needed. — xaosflux ^Talk 18:19, 22 May 2023 (UTC)

Most editors will never get access; most editors who do get access will only have access on one wiki. In such cases, removing access at the local wiki is effectively the same as removing access everywhere.

But people like us (probably less than 1% of all accounts) will have access on many wikis. Even on my staff account, which has somehow accumulated more than 24,000 edits across all wikis during the last 9.9 years, I'd have full IP access on five wikis if the current rules were in place now, and getting access on another seven would not require much effort. So if you decided that you really didn't trust me not to misuse access to IP addresses, you probably would want a way to remove that ability everywhere.

Two obvious decisions to be made:

1. This could be fully automated (e.g., handled by MediaWiki, by cron job, by bot), and it could require human intervention (e.g., after a discussion about whether the behavior prompting removal at wiki #1 might have been a purely local problem). Which do you all think is better?
2. If it's not fully automated, would you rather have automated reports (e.g., a bot posts each day a list of every removal, at all wikis, during the last 24 hours) or human requests (e.g., upon suggestion by the admin that removed the user right)?

Whatamidoing (WMF) (talk) 01:29, 23 May 2023 (UTC)