Stewards' noticeboard

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
←Stewards Stewards' noticeboard Archives→
Shortcut:
SN

Welcome to the stewards ' noticeboard. This message board is for discussing issues on Wikimedia projects that are related to steward work. Please post your messages at the bottom of the page and do not forget to sign it. Thank you.


Stewards
Wikimedia steward Icon.svg
Requests
For stewards
Noticeboards
 SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 2 days and sections whose most recent comment is older than 30 days.

IP masking policy[edit]

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)Reply[reply]

Thanks for the notification! :-) Vermont (🐿️—🏳️‍🌈) 16:34, 20 April 2023 (UTC)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
@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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
Yes. Whatamidoing (WMF) (talk) 04:45, 18 May 2023 (UTC)Reply[reply]


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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Cross-wiki user talk vandalism[edit]

For the past few weeks, someone has been vandalizing the user talks of TimothyBlue and CX Zoom across hundreds of projects. See the global contribs of 46.155.136.181 and 46.154.86.21 (may be more). I did some when I found out about this but it was too much for me alone, so I ended up posting it to GSR a week ago. It appears that that wasn't enough either as most still remain. Some are on large wikis where GS doesn't work. ~StyyxTalk? 20:40, 4 May 2023 (UTC)Reply[reply]

Hi, here are some of the vandalised user talk pages deleted by GS so far on piwiki: pi:Special:Log/delete. And one usertalk remains up there: pi:User talk:Czello, which someone might want to delete globally because it also is a result of vandalism. Thanks! —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 20:51, 4 May 2023 (UTC)Reply[reply]
Yep, I forgot to continue this, my bad! I'll finish the work :) Superpes15 (talk) 21:05, 4 May 2023 (UTC)Reply[reply]
@Styyx:@CX Zoom: I deleted them on all the GS-wikis (only a small bunch of non-gs wikis remain, but there we usually don't intervene, unless it's an emergency). I'll look for other vandalism made by other similar IPs. --Superpes15 (talk) 21:46, 4 May 2023 (UTC)Reply[reply]

About 3 deleted global accounts which have unattached local accounts[edit]

Hello, I found that there are 3 global accounts being deleted still have unattached local accounts, they are 1, 2 and 3. The first and the second account are blocked by at least 2 wikis and the third account is a defamatory username with a block in one wiki. However, these accounts should be global locked instead of being deleted as global account deletion for vandals should not be performed at all due to interfering with the ability to lock the account in case of a spread of the abuse according to Steward handbook#Global account deletion. As a result, I would like to know why these accounts are deleted and should those global accounts being recreated and then global locked. 132.234.229.38 00:22, 24 May 2023 (UTC)Reply[reply]

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Stewards%27_noticeboard&oldid=25064037"