In T382082#10403527, @JJMC89 wrote:

In T382082#10403117, @Niharika wrote:

We only want to allow global IP reveal blocks, not local ones, because if someone is abusing IP reveal on any wiki, they should not be able to use it on other wikis.

This is basically what we were discussing with Legal yesterday. I believe local IP reveal blocks should be permitted because if a local admin or Checker detects abuse, they should not have to wait for a steward or global sysop to take action against them.

Per policy, only Stewards and Trust & Safety are permitted to remove access.

I don't think this is an (immediate) problem. As far as I understand things, unserialize only poses a problem when it is given an untrusted input (as it can construct objects, and that involves running code). ArticleFeedback reads logging.log_params, which should be (reasonably) trusted.

In T381273#10371500, @Slst2020 wrote:

Has this worked for you in the past, then started failing today?

@Daimona Do you have any thoughts on this?

This was discussed during the December Stewards meeting. Stewards agreed on continuing this, We should also add a new global block option that would control whether emails are allowed to be sent (since sending an email from the wiki is the appeal process).

In T331193#10369672, @Ravitej_Neeli wrote:

@srishakatux I am working on this task, its very easy one!

I just ran into this as well. For some reason, this works for me from Python 3.9, but not Python3.11.

Uploaded https://gitlab.wikimedia.org/toolforge-repos/ircservserv-config/-/merge_requests/17.

I'm happy to help with setting this up, if someone grants me the permissions on that channel.

In T380308#10365300, @Niharika wrote:

I like it. @mszabo @Urbanecm what do you think?

In T381028#10363708, @Reedy wrote:

Deleting a global (user) account isn't the same as deleting a user account (which we don't really do)...

Thank you for the ping, @KColeman-WMF! Generally, the design seem like a step towards the right direction. I am wondering about a couple of things:

In T380743#10353886, @Xaosflux wrote:

So back to the list, I can also see reasons why when blocking a network globally we wouldn't want to block 'send email' locally as that will prevent use of Special:Contact (which is used for appeals as well).

In T380763#10354217, @Frostly wrote:

I completely agree that community consensus is not necessarily needed just because someone objects, but I also think that there are many relevant times when community consensus is legitimately needed for major changes to core or extension functionality.

In T380763#10354286, @Pppery wrote:

However, I disagree with the premise here entirely - the usage of the Community-consensus-needed tag means someone thinks the feature request needs a community discussion. That's different from personally disagreeing with it - I disagree with a lot of proposed features that I know are in the authority of the developers to implement or not, and usually express that with a token rather than with any tags.

In T378401#10352985, @ArielGlenn wrote:

kludging things enough for an integration test to fake a creation of a local account on another wiki, with a global account, with the right logging table entry etc, just felt like it was too fragile.

Note that prior to @Frostly 2023 changes, the tag was limited to configuration changes even more explicitly. It read:

Courtesy CC to @Xaosflux, who applied the tag on a feature task earlier today.

In T380743#10353501, @Xaosflux wrote:

I think this needs wider discussion, not a discord chat

As of now, completing this task means submitting the block will always trigger two blocks: one global, one at meta-wiki. With the "also block locally" checkbox, this makes sense, but after this change, not so much. Can we whitelist blocks partially?

Thanks! Seems to work now :).

@Tchanders FTR, this is fairly low priority, but it probably should be done at some point (I recall this being expressly requested during one of the Stewards consultations, but I'm not sure where exactly). That said, this probably doesn't need to block major pilots.

In T380468#10347099, @JJMC89 wrote:

In T380468#10346384, @Urbanecm wrote:

The idea is to only assign the group after all the criteria are met (eligibility + agreed to the terms of data use), rather than immediately on meeting eligibility criteria. In effect, the logging would change in the way I suggested.

The idea makes sense, but not logging the group change is not the way to implement it. Users being in a non-implicit group without the corresponding log entry is confusing.

In T380308#10340196, @mszabo wrote:

I'm not seeing a bug here. We could add a help text to the IPInfo table on temporary account contributions pages to clarify that the data shown is associated with the most recently used IP address.

In T380468#10344999, @JJMC89 wrote:

Autopromotion to checkuser-temporary-account-viewer is not logged

-1: User group changes should always be logged.

In T380309#10342854, @Strainu wrote:

@mszabo will this CR also fix the display at https://ro.wikipedia.org/wiki/Special:IPInfo/~2024-14596 ?

Recreating from personal account.

I'm highly suspicious of the mw.util.isIPv4Address( info.subject ) call in IPInfo. In this case, subject is the account name, not an IP address. Indeed, ~2024-14596 is not an IPv4 address, but it is not an IPv6 address either.

In T380309#10340135, @Niharika wrote:

@Urbanecm this seems to be the same issue as T380308: IP Information view in Special:Contributions is confusing for Temporary accounts with more than one IP in that the accordion is displaying information from the most recent IP in IP Info.

With the introduction of Temporary accounts, this now becomes more important. Having Special:MassGlobalBlock would allow Stewards to easily block Temporary accounts created by a LTA (example).

@ArielGlenn asked me to take a look at the changes here. My understanding is that the backfilling would attempt to determine the IP for the creator via CheckUser, and that would work (per @JJMC89's request) for both self-created accounts and assisted-created accounts. Should this fail (due to a CU bug, for example), then the account would still be created, but using 127.0.0.1 as a placeholder IP.

I think IP Info should not pretend it is able to merge information about different IPs together. I think it would be reasonable to restrict ourselves to a link to Special:IPInfo, which can list all the different IPs and data for it. For some reason, Special:IPInfo contains far less details than IP Contributions itself.

In T380221#10333824, @Xaosflux wrote:

I think this is a duplicate of T374718

@kostajh I remember we talked about IPoid together. Do you have any thoughts on why it might do this?

At first, I thought this might be because IPoid takes time to ingest all data. However, for this IP in particular, this was first observed on November 15 (3 days ago). According to the quoted IPoid results, the data was last updated at 1731947776 Epoch time, which is Monday, November 18, 2024 4:36:16 PM GMT (aka 3 hours ago). So, updating seems to work, but we are getting different data for some reason. Why?

In T334625#10001827, @kostajh wrote:

@Niharika what do you think we should do here?

xref T380221: Allow authorised users to see IP Info for actors if the IP exists in the CheckUser or AbuseFilter tables, or has contributions

xref T380221: Allow authorised users to see IP Info for actors if the IP exists in the CheckUser or AbuseFilter tables, or has contributions (and especially T380221#10333285, where i suggest allowing queries for any IP)

In T380221#10333285, @Urbanecm wrote:

Personally, I'd be open to removing the restriction for good, and allowing people to query IP Info for any IP (Temporary account), regardless of whether it actually edited. This might seem unnecessary, but IPs often make an action that is rejected prior to saving (by an AbuseFilter, spam filter or the like). When looking at those events, IP Info data can be useful, but cannot be generated natively. This is even more visible in the Temporary accounts world – there is always some reason for a Temporary account creation, and that reason always is "the user attempted to make a write action". Sometimes, that attempt is not successful, but that can be a valid reason to want to see IP Info data. Given this and the other is very similar to each other, I'm not filling a separate task for "allow data to be queried for any actor", but I do see a lot of usecases where that would be helpful.

xref T380221: Allow authorised users to see IP Info for actors if the IP exists in the CheckUser or AbuseFilter tables, or has contributions, where I suggest widening the restriction (and in T380221#10333285, removing it altogether).

Cross-linking a similar task: T332163: Ensure that IPInfo instrumentation is enabled on Special:DeletedContributions

Personally, I'd be open to removing the restriction for good, and allowing people to query IP Info for any IP (Temporary account), regardless of whether it actually edited. This might seem unnecessary, but IPs often make an action that is rejected prior to saving (by an AbuseFilter, spam filter or the like). When looking at those events, IP Info data can be useful, but cannot be generated natively. This is even more visible in the Temporary accounts world – there is always some reason for a Temporary account creation, and that reason always is "the user attempted to make a write action". Sometimes, that attempt is not successful, but that can be a valid reason to want to see IP Info data. Given this and the other is very similar to each other, I'm not filling a separate task for "allow data to be queried for any actor", but I do see a lot of usecases where that would be helpful.

Hi @Tchanders, I filled this task following feedback given in the checkuser mailing list. Fortunately, I do not see anything in the relevant policy that says IP Info can be only used on users with live edits. Is this something we can consider in the Temporary accounts line of work?

...edit conflicts, sorry about that.

Thanks!

Thanks @SLyngshede-WMF. For the record, the urbanecmtest account looks to be disabled in practice, rather than just according to ldap.toolforge.org. For example,pwdPolicySubentry is currently checked by Wikimedia Cloud on SSH attempts, which means I'm currently not able to SSH in as urbanecmtest. This seems to be done via ssh-key-ldap-lookup.py.

Thanks @SLyngshede-WMF. I tested again. The account in Phabricator seems unblocked, but https://ldap.toolforge.org/user/urbanecmtest continues to say "account disabled". Is it possible there are some issues that prevent the action from propagating down to LDAP?

Thanks @Dreamy_Jazz! Indeed, it does seem to be reproducible only at RecentChanges. I apparently got confused when testing by the buttons disappeared after the reveal, and misattributed the observations. Thanks for catching that!

In T377765#10308466, @Tamzin wrote:

Meantime, would it be possible for a sysadmin to reverse the protection of 1165 on enwiki?

In T377765#10261625, @Pppery wrote:

I would go further still, and use only the warning and not the checkbox. Since the checkbox seems to show up on every abuse filter edit even ones that have nothing to do with protected variables having it on every save is scary.