In T374718#11700758, @kostajh wrote:

In T374718#11700683, @EggRoll97 wrote:

I think something that ought to be clarified here is how flexible the gating currently is. Is this new ipinfo-view-arbitrary-ip right able to be assigned to other privileged groups that a local community might define, or is it more of a hard-set of admins and functionaries only? Asked this question more informally and was told it might be best to toss this in as a comment.

We have approval only for sysop, checkuser, and steward. Which groups do you have in mind?

I think something that ought to be clarified here is how flexible the gating currently is. Is this new ipinfo-view-arbitrary-ip right able to be assigned to other privileged groups that a local community might define, or is it more of a hard-set of admins and functionaries only? Asked this question more informally and was told it might be best to toss this in as a comment.

While I don't doubt that this styling is consistent with the normal styling of OOUI, I don't think this is a net positive for those working with abuse filters on projects. As others have said, there should be a revert on this, unless someone is able to whip up a quick fix to this to enable people to get back to their normal workload. Broken on my PC on Chrome v144.0.7559.133.

In T409396#11348758, @Johannnes89 wrote:

In T409396#11348665, @Tamzin wrote:

Are there AbuseFilter trips whose very existence is nonpublic? I thought it was only that with some the filter information (other than its name) is nonpublic. If so, I would think it's fine to show the disallow tally to anyone.

The number of AF hits is indeed public information. But I still believe it's better to limit this feature to admins. Similar to to the number of blocks users might feel stigmatized if their UserInfoCard publicly shows x disallowed edits (those might be false positives or there were other legitimate reasons for hitting the filter).

In T405999#11239400, @Soda wrote:

In T405999#11239184, @EggRoll97 wrote:

In T405999#11236909, @Soda wrote:

This, in all probability, should not have been deployed given the current state of the discussion. Imo it needs wider input from the community, 3 people on enwiki cannot be called a consensus enough for such a sensitive change. I agree that the chances of abuse are low, but that does not preclude having a more robust discussion about this.

I think the consensus was sufficient here. There was more than a full week before it was put into Phabricator, and multiple days after that before the change was deployed. The edit filter noticeboard has 351 people as watchers, and of those, 57 visited in the last 30 days, providing ample opportunity to leave any comments in opposition. It's not as if this was held in an obscure area, it's a noticeboard linked to in the noticeboard template, and yet still, there was not a single actual objection to this proposal.

The reverse applies as well, for such a discussion. If it was getting only 3 supports, it shows that there isn't strong support for this action even on a noticeboard where folks are more likely than not to support it. With respect to Phabricator, I think folks bringing and subsequently scheduling and deploying site-wide changes have a significant responsibility to evaluate the consensus and make sure their actions have the clear-cut backing of the community (think implementing a close in enwiki terms). Also, folks will raise objections in egregious cases (where no links to discussions were provided), but the lack of dissent on phab is typically not a strong signal of nobody having objections, but rather people going "Yeah, everything mostly looks right, no technical concerns, EggRoll97 knows what they are doing".

In T405999#11236909, @Soda wrote:

This, in all probability, should not have been deployed given the current state of the discussion. Imo it needs wider input from the community, 3 people on enwiki cannot be called a consensus enough for such a sensitive change. I agree that the chances of abuse are low, but that does not preclude having a more robust discussion about this.

Also getting the same error as mdaniels5757 on account creation on enwiki. Tried at Meta and got "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Please resubmit the form." Tried to exit Special:CreateAccount, log out, and go back to it, and received the same message.

Done successfully.

Should be on all production wikis assigned to bureaucrats.

I see this as generally being bundled with the sysop group on most wikis, so I don't see any problem with enabling this to the sysop group on testwiki.

Legal confirmed per Gerrit comment, now waiting on deployment. I plan to get this deployed this week.

Stalled on re-confirmation from Legal of the ANPDP exception.

Removed ipinfo-view-full as well, as not permissible by IP address access policy (requires administrator, bureaucrat, checkuser/oversight, or global group access), implemented without ip viewing-related rights.

The only problem I see here is the checkuser-temporary-account right being assigned to this group. Per https://meta.wikimedia.org/wiki/Limits_to_configuration_changes that right is exclusively assigned as a stand-alone. Ukwiki admins are of course welcome to assign it to new arbitrators (through the "Temporary account IP viewers" group), though, which would do essentially the same thing, but including it in a group that can be manually assigned without a check for the legal requirements would be a prohibited change. I can, however, proceed with the user group with all other rights requested to be assigned, as nothing appears to prevent any of the remaining rights from being assigned to ArbCom members.

In T380332#10389104, @Bugreporter wrote:

There is one user in EFM (ProcBot II) and one in EFH (Queen of Hearts mobile) not meeting requirement described in https://foundation.wikimedia.org/wiki/Policy:Wikimedia_Access_to_Temporary_Account_IP_Addresses_Policy#Patrollers_and_other_users. Both are alternative accounts, but policy does not mention any current way to assign such access to alternative account (other than gaining them local admins - yeah, any crat can assign a brand-new user as sysop, even without discussion, and it will get IP reveal access immediately by policy), not even with community approval.

Previously, there are user in enwiki get EFM with less than 200 edits (before Global EFH exists, and now removed as redundant). If a user with 300- edits and no CU/OS (the user mentioned before was once a CU in another wiki) gets EFM or EFH, they will have access to protected variables, but not meeting the Wikimedia Access to Temporary Account IP Addresses Policy.

This is now added to EFH and EFM on enwiki.