Every group removal is logged on the wiki's 'rights' log
For select groups, the log entry is relayed to central wiki's 'rights' log as well

See: T6055: Interwiki rights logs should be duplicated at related wikis. Alternation of user rights in another wiki is a MediaWiki core (not CentralAuth) feature.

I believe this needs some thought with regards to CU & OS. Global policy requires at least two active CU/OS and asks for the community to appoint a new one immediately if there are only two CU/OS and one of them retires or is removed, otherwise stewards also have to demote the remaining one. Relying on stewards to somehow notice the log action would be a bad idea. Even the local community and/or the affected user might not notice the demotion immediately, e.g. if the user has been inactive for a couple of months. We would need some kind of notification to check if the wiki still has two CU/OS and to take additional action (e.g. removing CUwiki access).

In T418579#11662657, @Johannnes89 wrote:

I believe this needs some thought with regards to CU & OS. Global policy requires at least two active CU/OS and asks for the community to appoint a new one immediately if there are only two CU/OS and one of them retires or is removed, otherwise stewards also have to demote the remaining one. Relying on stewards to somehow notice the log action would be a bad idea. Even the local community and/or the affected user might not notice the demotion immediately, e.g. if the user has been inactive for a couple of months. We would need some kind of notification to check if the wiki still has two CU/OS and to take additional action (e.g. removing CUwiki access).

With this off-boarding process in mind, I added an AC that some group changes will be relayed to Meta. This, in itself, won't add any notification, but will make it easier to look for such changes (instead of monitoring logs of multiple wikis).

I expect that such changes will happen very rarely, primarily at the times when we deploy the requirements.

Am I right that following the rights log (even filtered to a specific performer) is not something stewards would like to do? Then, I think it should be possible to relay such log entries to a subpage of Steward requests using some simple bot running on Toolforge. How does that sound?

In T418579#11660921, @Bugreporter wrote:

Every group removal is logged on the wiki's 'rights' log
For select groups, the log entry is relayed to central wiki's 'rights' log as well

See: T6055: Interwiki rights logs should be duplicated at related wikis. Alternation of user rights in another wiki is a MediaWiki core (not CentralAuth) feature.

A similar thing has been already implemented for https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/1237589 I think we'll be able to reuse the underlying code (especially that in core) for this purpose.

I used word "central" in AC, but in practice, I'm thinking it'll be configurable which wiki we refer to (so it's more of "remote wiki, which happens to be a central wiki in CA" than "central wiki").

In T418579#11663007, @mszwarc wrote:

In T418579#11662657, @Johannnes89 wrote:

I believe this needs some thought with regards to CU & OS. Global policy requires at least two active CU/OS and asks for the community to appoint a new one immediately if there are only two CU/OS and one of them retires or is removed, otherwise stewards also have to demote the remaining one. Relying on stewards to somehow notice the log action would be a bad idea. Even the local community and/or the affected user might not notice the demotion immediately, e.g. if the user has been inactive for a couple of months. We would need some kind of notification to check if the wiki still has two CU/OS and to take additional action (e.g. removing CUwiki access).

With this off-boarding process in mind, I added an AC that some group changes will be relayed to Meta. This, in itself, won't add any notification, but will make it easier to look for such changes (instead of monitoring logs of multiple wikis).

That's certainly an improvement!

I expect that such changes will happen very rarely, primarily at the times when we deploy the requirements.

Agree, most of the demotions will likely happen immediately after deploying these changes.

Am I right that following the rights log (even filtered to a specific performer) is not something stewards would like to do?

I believe there are IRC channels where metawiki rights changes and other log entries are relayed, but I'm not sure and I don't know if people pay attention to that (I don't use IRC).

Then, I think it should be possible to relay such log entries to a subpage of Steward requests using some simple bot running on Toolforge. How does that sound?

Leaving some notification about the removed permissions at m:Steward requests/Permissions#Removal of access or the steward's noticeboard would be helpful! (probably not needed immediately after deployment, we can actively monitor removals that week, but useful later when people pay less attention)

Before actual removal we should send an email to affected users so that they can set up 2FA.

On the contrary you shouldn't send an email. If months of having the group not function due to lack of 2FA (as is currently the case) didn't cause the user to notice and enable 2FA then per the principle of least privilege they don't need to be in the group at all and hence shouldn't be in it.

We should also consider what to do if we add a new 2FA requirement to some user groups. See task description of T150898: Force OATHAuth (2FA) for certain user groups in Wikimedia production and Beta wikis. (For private wikis we may even want to require user to enable 2FA before reading any internal pages.)

In T418579#11666325, @Bugreporter wrote:

Before actual removal we should send an email to affected users so that they can set up 2FA.

This was already done last week

In T418579#11666339, @Bugreporter wrote:

We should also consider what to do if we add a new 2FA requirement to some user groups. See task description of T150898: Force OATHAuth (2FA) for certain user groups in Wikimedia production and Beta wikis. (For private wikis we may even want to require user to enable 2FA before reading any internal pages.)

We expect that it would look similar to how 2FA enforcement (new code) is deployed currently:

• First, there's status quo (no 2FA requirement for the group)
• 2FA enforcement is enabled in non-demoting mode: users cannot use their rights unless they have 2FA enabled, new group member without 2FA cannot be appointed, current members with 2FA cannot disable it
• After some time, automatic demotion is enabled

This is one of the reasons why we're keeping the concept of "disabled groups" with the new 2FA enforcement system, so that such transition period will be doable in future.

Change #1247567 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Add option to allow for autodemotion from restricted groups

https://gerrit.wikimedia.org/r/1247567

Change #1247568 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Implement script to automatically demote users from restricted groups

https://gerrit.wikimedia.org/r/1247568

Change #1247975 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] DemoteIneligibleUsers: Add option to relay logs to other wikis

https://gerrit.wikimedia.org/r/1247975

Change #1247567 merged by jenkins-bot:

[mediawiki/core@master] Add option to allow for autodemotion from restricted groups

https://gerrit.wikimedia.org/r/1247567

Change #1247568 merged by jenkins-bot:

[mediawiki/core@master] Implement script to automatically demote users from restricted groups

https://gerrit.wikimedia.org/r/1247568

Change #1247975 merged by jenkins-bot:

[mediawiki/core@master] DemoteIneligibleUsers: Add option to relay logs to other wikis

https://gerrit.wikimedia.org/r/1247975

Locally, I have added all my local users to groups in $wgRestrictedGroups, ran the maintenance script and checked that:

• They have been removed from groups they are not eligible for, unless the group had 'canBeIgnored' => true. The latter condition makes sense to me as users might have explicitly been added to such groups despite them not meeting the requirements and we wouldn't want to remove them.
  • This included groups with the has_2fa restriction. I notice that if a user has 2FA but their account is unmerged on the wiki you are running the maintenance script on, they will count as not having 2FA and be demoted. I notice that I cannot add the same user to 2FA restricted groups with Special:UserRights on the wiki they are unmerged, so I guess this is expected behaviour.
• They have not been removed from groups they are eligible for.
• A log item is created on the local wiki.
• A log item is created on the central wiki, if --relay-log <group>=<wiki> is passed and the user has been removed from <group>.

When run in production, I wonder how many users we might need to check for eligibility (and potentially remove) and whether we need to do this in batches. @mszwarc?

In T418579#11701801, @dom_walden wrote:

When run in production, I wonder how many users we might need to check for eligibility (and potentially remove) and whether we need to do this in batches. @mszwarc?

In Q3, I expect that up to a hundered users will be checked per wiki and up to a dozen of users are going to be demoted per wiki (typically less than that). Those numbers won't change significantly unless we start requiring 2FA from administrators, which is not planned (neither for Q3 nor Q4).

Is this task actually resolved? I believe we still need to agree on a proper solution for how to notify stewards when CU/OS are demoted? Or should this be discussed in T414907: Enforce 2FA-requiring groups using $wgRestrictedGroups?

In T418579#11713620, @Johannnes89 wrote:

Is this task actually resolved? I believe we still need to agree on a proper solution for how to notify stewards when CU/OS are demoted? Or should this be discussed in T414907: Enforce 2FA-requiring groups using $wgRestrictedGroups?

Sorry, a few details of this might have been implicit in the comments to this task or in other places. Given that there's no task focusing on notifying stewards, I created a new one, let's discuss there: T420214: Ensure stewards are notified when checkusers and oversighters are automatically demoted due to lack of 2FA

Let's keep this task resolved as the script itself is done and anything beyond replicating log entries to Meta-Wiki should be implemented elsewhere.