Requests for comment/CheckUser activity RFC

This is a subpage; for more information, see the Requests for comments page.

Since the inception of the CheckUser policy, a key component has been that there is never one CheckUser on a project. This provision is so that there is at least one other person to review the actions of the other in a native language, should it be necessary. The current reading of the policy is that they are there to audit the other's use. The problem is that this only sometimes happens. There is a security concern also when an account becomes inactive. This proposal will assist in eliminating these concerns.

It is proposed that the CheckUser policy be amended to require that CheckUsers have a minimum of 5 checks during any 12 month period where:

The checks must not be on themselves, their bot, or for testing purposes
The user is not exempt by being part of a body that assigns, removes, or audits the use of CheckUser for that community
The user has been assigned local CheckUser
The wiki is a content project

Proposed by: -- Amanda (she/her) and User:Martin Urbanec 22:08, 15 April 2023 (UTC)[reply]

FAQ

What if someone loses their rights for inactivity? Can they regain them?

No, a fresh election would be required, as is standard practice when removing the rights of a CU at SRP.

Which wikis would be immediately affected by this policy should it come into force when it is proposed?

cswiki, dawiki, enwikinews, fiwiki, kowiki, mlwiki, and specieswiki would either have zero or one CUs remaining, requiring the removal of all CheckUsers on those wikis. 24 of 191 (~12.6%) CheckUsers that exist globally would be up for removal.

What does this change ensure?

That there are active checkusers on the relevant wiki, able to provide a second opinion should the community or another CheckUser need it.

This is going to remove all CUs from my wiki. What can we do to stop it? Can I exempt my wiki by a local vote?

No, the CheckUser policy is a global policy with no opt-out clause. The only way to retain CheckUsers locally is to have your local CheckUsers become active again or elect more to be CheckUsers.

Why is this RfC happening now?

Global Interface Editors, Global Rollbackers, Global sysops, Stewards, and Global Abuse filter maintainers/Global Abuse filter helpers all have clear activity requirements. This proposed change clarifies the inactivity wording.

Will this change not encourage CheckUsers to run inappropriate checks?

Usage of CU is strictly regulated by the CU policy, the access to nonpublic personal data policy, and relevant local policies. Should a CheckUser or Steward notice inappropriate use, especially to meet the requirement, they can report it to the Ombuds Commission.

Discussion

Support as proposer. -- Amanda (she/her) 22:08, 15 April 2023 (UTC)[reply]
Oppose. I do agree that inactive checkusers should be removed, but I don't think this is a good criterion for a global policy concerning a local role. I think it would be important to understand the dynamics of concerned wikis (like cswiki or dawiki) first. Because I can imagine a number of ways a CU can be active without doing checks, like discussing results on a mailing list or reviewing logs of checks made by more active CUs. I am not sure what is actually happening in these cases, so it would be useful to check with the concerned communities on how they handle this. It might also be the case that they have a valid removal process (e.g. via ArbCom), so I would rather support a policy more like AAR first — NickK (talk) 22:28, 15 April 2023 (UTC)[reply]
One of the proposers (Martin Urbanec) is a cswiki CU who will lose their local rights (though we don't know if they're the inactive one), so presumably they understand the dynamics there. Legoktm (talk) 03:51, 16 April 2023 (UTC)[reply]
Oppose as User:NickK above. Also: Inactive accounts may or may not be security issue - there are cases where active account with persistent cookies can be easily hijacked. But security of the advanced permissions account is a question orthogonal to the CU activity and the events logged there. « Saper // talk » 22:39, 15 April 2023 (UTC)[reply]
Support Mainly, I think this misses an important project-specific (as opposed to user-specific) criterion. Perhaps we should have a separate criterion that says that only projects that have made 10 or more CU requests to stewards for the previous two years should be eligible to create the CU position; and similarly, projects can only retain CUs if they can demonstrate there have been a minimum of 5 policy-based checks or series of checks PER CHECKUSER per year. I understand what NickK is saying. I think that it would be helpful to have some very generic statistics on CU usage on low-usage wikis such as those identified above. I'll point out that there is only supposed to be one Checkuser mailing list, the global one, on which any CU can post in any language; this is for security purposes. I think AmandaNP has not mentioned some of the reasons that it's worthwhile to have minimum use standards. They would include skills maintenance (particularly as the CU interface has been undergoing considerable change), and concerns re user security. Risker (talk) 22:45, 15 April 2023 (UTC)[reply]

Oppose The problem exists, but the proposal doesn’t solve it. A CU can be checking activities without doing checks themselves, orcan be doing checks but not monitoring activities. With the proposal, the second CU can be inactive 11 months without consequence. I also see no reason why this should apply to CU but nit OS, which can have simular issues. --Krd 23:05, 15 April 2023 (UTC)[reply]

What could solve the issue could sond like „If on a project there are less than 2 CUs who each have done edits or logged actions within the last 30 days, all CUs are removed on that project. The same applies for OS.“ Krd 23:09, 15 April 2023 (UTC)[reply]

This is causes exactly the problem I'm trying to avoid where 1 CU has completely checked out of running any checks for like 4 years and is not active in CU business at all, but still has edits. -- Amanda (she/her) 23:24, 15 April 2023 (UTC)[reply]

Then perhaps a combination of both is needed. Krd 23:49, 15 April 2023 (UTC)[reply]

Question: aren't all local checkusers part of the group that "audits the use of CheckUser for that community" - one of the reasons multiple checkusers are required on a project, even if just one audits one other. — xaosflux ^Talk 23:17, 15 April 2023 (UTC)[reply]

I was trying to dive for simpler English than getting all English-legalistic for a cross language proposal. By technicality of policy, it's only meant for CUs to "mutually control and confirm their actions", not audit. -- Amanda (she/her) 23:22, 15 April 2023 (UTC)[reply]

The CUs of a project are not a "body" like arbcom, the french appointment committee or the ombuds commission. Der-Wir-Ing ("DWI") talk 23:35, 15 April 2023 (UTC)[reply]

Question: I'm unclear on what criterion 2 means. Should it be read as "the 5 checks per 12 months requirement does not apply to members of a body that [...] CheckUser" or should it be read as "members of a body that [...] CheckUser are not exempt from the 5 checks per 12 months requirement"? Wugapodes (talk) 23:42, 15 April 2023 (UTC)[reply]

The former. Bodies that take it under their wing to change permissions and audit are meant to be exempt from the requirement. -- Amanda (she/her) 23:47, 15 April 2023 (UTC)[reply]

Support While I appreciate the concerns above about a project not having a sufficient quantity of requests for CUs to be able to meet the activity requirements, in that situation I would question whether there is a sufficient justification for the project to have CheckUsers in the first place. This is especially the case when considering that looking into a single account would usually result in more than one logged action. I would support (in case it comes up later) a modification to the proposal that allows declining to run checks count for part (not all) of the logged actions but my support isn't conditional on that and I understand why it wasn't included. I would also support (in case it comes up later) lowering the number of checks to 3 in 12 months but my support isn't conditional on that either. Callanecc (talk) 00:00, 16 April 2023 (UTC)[reply]
Support GeneralNotability (talk) 00:17, 16 April 2023 (UTC)[reply]
Support this is a step towards resolving two problems with CU Wikimedia-wide: first, there are projects where one CU has turned the CU tool into a fiefdom and they are unchecked. Second, there are projects that used to be active enough to sustain CUs, but now do not have enough activity to elect new CUs, and where the existing CheckUsers only retain their permissions based on what amounts to a grandfather clause.
Should these be stricter as some have alluded to above? Yes. Would anything stricter likely pass? Probably not. This also doesn't solve problems such as projects that don't need CUs electing them anyway (example: simplewiki, where the CU position is essentially a stepping stone to a future steward campaign) but we shouldn't let the perfect be the enemy of the good. This proposal as a whole does good things, and I end up here supporting it. TonyBallioni (talk) 00:32, 16 April 2023 (UTC)[reply]
If the CU tool is being used as a fiefdom, shouldn't we be removing those users for cause rather than waiting for inactivity? Legoktm (talk) 03:46, 16 April 2023 (UTC)[reply]
I was speaking to the social part of it, which might not be a policy violation in itself. When people operate in a vacuum and have powers that no one else in their environment have, it becomes a fiefdom that has negative impacts on the social structure of a project even if used in a policy-compliant manner. Essentially when you have one person who is doing all the work in an area of restricted access, it can't help but become a fiefdom where one person views their positions as the policy rather than what the policy actually says. We see this outside of the CU sphere on content projects fairly regularly and it is a general problem Wikimedia has. The difference with CU is that when this happens, there's a risk to people's privacy, especially in countries with less than stellar human rights records and the like. Having inactivity requirements is a small check that ensures that at least two people are active, which helps prevent this phenomenon. I'd prefer it be a higher standard, but I understand the counterargument that you don't want to encourage unnecessary checks. TonyBallioni (talk) 04:27, 16 April 2023 (UTC)[reply]
Support. Inactivity was one of the major issues that led to Requests for comment/Site-wide administrator abuse and WP:PILLARS violations on the Croatian Wikipedia. --Rs chen 7754 00:41, 16 April 2023 (UTC)[reply]
I will note that if this fails, perhaps the solution is to simply bring the activity policy down to 6 months of complete inactivity. Rs chen 7754 05:49, 16 April 2023 (UTC)[reply]
Comment Currently tend to oppose. It simply is a wrong incentive. Personal data should be handelt not only with strict words in policies, but also with a strict design of the function. Would support an ammended version, which specifies, that there must be a minimum amount of checks, whether to use the check user function. Habitator terrae (talk) 01:12, 16 April 2023 (UTC)[reply]
Your comment doesn't make sense. There are 5 checks minimum during a 12 month period to not be affected by the proposed rule. -- Amanda (she/her) 03:21, 16 April 2023 (UTC)[reply]
Support The CheckUser role has two halves. The first half is using the tool to investigate abuse. In my opinion, the more important half is reviewing CheckUser logs and their fellow CheckUsers' activities. This is the reason there must be, at an absolute minimum, two CheckUsers at any time. The expectation of activity is, therefore, required and expected. CheckUsers that are inactive should not retain the role as they are not fulfilling the more important function of monitoring their own. There may be some projects that have 5 or 6 CUs, but only 1 is active and, as such, is unmonitored. It's my opinion this RfC seeks to codify a "circuit breaker" to prevent this exact circumstance and is needed. Operator873 ^connect 01:41, 16 April 2023 (UTC)[reply]
Comment As far as I know, merely viewing Special:CheckUserLog doesn't get logged. It's a valid question as to whether a CheckUser who only keeps an eye on other CheckUsers' use of the tool is being active enough for the right, but I disagree that it means the other CheckUser is unmonitored per se. On my home wiki, I'm certainly the less active of the two CheckUsers, more of a backup/second opinion, but I take my responsibility to monitor the tool's use seriously. As worded, this policy would incentivize me to redundantly look at more personal information than strictly necessary, or it could delay some requests while the other CheckUser load-balances more of them to me to ensure he retains his own rights. If the goal is to ensure, at a minimum, use of Special:CheckUserLog, then maybe visits to that page should be logged? – Minh Nguyễn ^💬 02:15, 16 April 2023 (UTC)[reply]
Is "checks" here referring to all the usage of the CU tool required to respond to a request, or literally just checking a single user as part of a response to a request? If the latter, then I could see myself supporting this proposal, if only because most requests require so many checks these days. Minh Nguyễn ^💬 02:21, 16 April 2023 (UTC)[reply]
@Mxn: It's just 5 single user checks. So one investigation could cause 5 entries in the log and it would pass the requirement. -- Amanda (she/her) 03:20, 16 April 2023 (UTC)[reply]

I think it should, other than proposed, refer to any request, with a response by a check user, may it be by checking the user or declining the request. Otherwise the rights of CUs depent not only on wether they decide, but also on what. Habitator terrae (talk) 04:49, 16 April 2023 (UTC) PS: A compromise could be to also make a log-note for declining requests.[reply]
Oppose That would put pressure on volunteers, motivate harassing ‘inactivity’, and trigger unnecessary checks just to reach the minimum number. Furthermore, i doubt the problem. How do you know that audits “only sometimes happen”? —MBq (talk) 05:07, 16 April 2023 (UTC)[reply]