Talk:CheckUser policy

Archives Proposition 2005 (November 2005) Archive 1 (Prior to June 2005) Archive 2 (Prior to January 2006) Archive 3 (Prior to April 2008) Archive 4 Archive 5

In the case where only one CheckUser is left on a wiki (when the only other one retires, or is removed), the community must appoint a new CheckUser immediately (so that the number of CheckUsers is at least two).

Is it a formal requirement that local communities must appoint a new CU immediately? I mean, if they don't want to, the only CU left will be demoted anyway, so there's no harm either. Not to mention stewards will always revoke both CU-ship at once. NguoiDungKhongDinhDanh 11:53, 29 May 2022 (UTC)Reply

I've been thinking for a while that the wording of that section could be improved as it is not reasonable to require an immediate election. I discussed this with @Risker a while ago and she wrote w:User:Risker/Sandbox42 as a proposed rewording which addresses both the "must" issue you mention and, in addition sets a maximum time of CU-suspension. I'd like to open an RfC about it and get the policy changed on that point, but I'm a bit busy right now. —MarcoAurelio (talk) 18:55, 7 June 2022 (UTC)Reply

@MarcoAurelio: sorry for slow reply on this. Yes I also agree this could be reworded to say something like "within 6 months" and in the meantime I think the remaining checkuser can request assistance from Stewards in order to meet verification requirements, or something similar. Cheers Scott Thomson (Faendalimas) ^talk 14:00, 19 July 2022 (UTC)Reply

The Wikimedia Foundation recently received a recommendation from the Ombuds Commission that this policy be amended. The issue at hand is the appointment of Checkusers and Oversighters and whether the group which appoints them on a project must specifically be an Arbcom or whether another, specialized committee could do it. After review, the Ombuds Commission believes, and the Foundation agrees, that there is room for a wider variety of functionary "Appointment Committees" beyond simply Arbcoms.

Accordingly, we plan to update this policy and the Oversight policy on 26 July 2022. The changes will be as follows for the Checkuser policy (removals in strikethrough and additions in bold):

On wikis with an Arbitration Committee (ArbCom)Appointments Committee whose members have been elected with the support of at least 25–30 members of the local community, CheckUsers may be directly appointed by the ArbitratorsCommittee. Any committee meeting these requirements, including an Arbitration Committee (ArbCom), may fulfil this role. After agreement, a member of the Committee should simply list the candidate on Steward requests/Permissions.

On a wiki without an ArbitrationAppointments Committee that meets the criterion above, or in a project where there is a preference for independent elections, the community may approve local CheckUsers (stewards not counting as local CheckUsers) per consensus. [...]

Suspicion of abuses of CheckUser should be discussed by each local wiki. On wikis with an approved ArbCom, the ArbCom can decide on the removal of access. On wikis without an approved ArbCom, the community can vote removal of access.

We plan to make this change on 26 July 2022. Kbrown (WMF) (talk) 15:17, 18 July 2022 (UTC)Reply

@Kbrown (WMF): I thought this was a community policy. Shouldn't this change come from the community instead? While I do not substantiatively disagree with the change I think this sets a bad precedent. --Rschen7754 18:10, 18 July 2022 (UTC)Reply

I agree with Rschen, and I also am worried that the proposed change is too ambiguous. How about something like the following: (– Ajraddatz (talk) 19:17, 18 July 2022 (UTC))Reply

the community may approve local CheckUsers (stewards not counting as local CheckUsers) per consensus. Local CheckUsers may be appointed by their respective community by consensus. The CheckUser candidate status must request it must request the persmission within the local community and advertise this request properly (village pump, mailing list when available, special request page, etc.). The candidate must be familiar with the privacy policy. After gaining consensus (at least 70%–80% 75% in pro/con voting or the highest number of votes in multiple choice elections [note: should this be removed?]) in the local community, and with at least 25–30 25 editors' approval, the successful candidate should request access at Steward requests/Permissions with a link to the page with the community's decision. If there are an insufficient number of votes for at least two CheckUsers on a wiki, there will be no CheckUsers on that wiki.

On wikis with an Arbitration Committee (ArbCom) whose members have been elected with the support of at least 25–30 members of the local community, CheckUsers may be directly appointed by the Arbitrators. A community may also delegate the appointment and termination of local CheckUsers to a committee that is elected with the support of at least 25 members of the local community and which has received community consensus to manage access to the CheckUser permission. This may include an Arbitration Committee, and existing committees that already engage in the control of the CheckUser permission may continue to perform that function after this policy comes into force without requiring a separate community vote on their scope. After agreement to appoint a user, a member of the Committee should simply list the candidate on Steward requests/Permissions.

I guess the question is "who decides what counts as a valid Appointments Committee?" If I get some English Wikipedia WikiProject together and have them vote up an "Alternative ArbCom," who is in charge of deciding that that committee isn't a legitimate appointment body? GeneralNotability (talk) 20:54, 18 July 2022 (UTC)Reply

Yeah, that seems a little strange. More to the point, what would stop me from getting 25 of my IRC buddies to hold an AppCom formation RfC on the Ships In Bottles Noticeboard at 3am on a Wednesday and appoint ourselves CUs by unamimous consensus? JPxG (talk) 09:47, 20 July 2022 (UTC)Reply

Noting that Checkusers have also been discussing this on our mailing list. Some of the points are noted above. Using Chatham House Rule, I'll include additional points:

• The policy as a whole is outdated in significant ways that do not reflect current realities of our projects.
  • VOTING: Some discussion of whether the current minimum of 25 supports is sufficient for access to this highly sensitive tool. Some discussion of whether there should be higher/more specific requirements for voters to meet in order to participate in CU elections (e.g., similar or equivalent to those for stewards). This could include minimum number of contributions, limits to only voters with accounts registered a certain period before the election, or other local requirements.
  • WIKIS WITH ONLY ONE CHECKUSER: The policy poorly addresses what happens when one or more CUs on a project are removed according to local or global policy (e.g., insufficient activity, resignation, removal for cause, etc) so that only one CU remains. (Consideration of a proposal to reflect what is mostly current practice is addressed in the section above.)
  • USING GLOBAL POLICY TO ADDRESS AN ISSUE OF A SINGLE PROJECT: There is currently only one project that has proposed even considering the need for a separate "appointments committee". Some feel it is overkill to modify a global policy to accommodate one project.
  • NEED TO ADDRESS RELEASE OF CHECKUSER DATA IN ORDER FOR CHECKUSER TO COMPLY WITH LOCAL LEGISLATION: This issue has been previously discussed on the CU mailing list in the past few months, and many felt that a formal process could/should be included in the CU policy.
• The majority of CUs commenting on this felt that this is a community policy and changes should be made in the usual manner for global community policies that are hosted on Meta. That is, unless there is a hardline legal reason that the policy would need to be changed, the WMF's role would be to suggest or recommend changes and/or to voice support or opposition to a proposed change.
• Unclear who would be responsible for determining whether any proposed "appointments committee" is actually accepted as such. The WMF? The local community via local policy? (And how would *that* policy be decided?) The Ombuds Committee, a non-elected body? Can a local Arbcom delegate this responsibility to a "subcommittee" that is the equivalent of an appointments committee?

My own opinion is that there's no value in modifying this section without revamping the policy as a whole; this is actually a lower priority than other updates that are needed. I also believe that this is a community policy and that, while the WMF is very welcome to suggest changes, there's no strong privacy-related or legislatively-related reason for this change that would justify that the WMF mandate this change. Finally, I would very much like to hear from the Ombuds as to their views on this proposed change, including the reasons for those views. Risker (talk) 05:45, 19 July 2022 (UTC)Reply

• Two more issues that should probably be considered:
  • Inactivity: 1 year with no edits/logged actions (as the vague wording has been interpreted) is too lax, especially when there are only 2 CUs.
  • Voting: some wikis leave their CU nominations open for months in order to hit the minimum of 25. This is probably not a fair election. --Rschen7754 06:45, 19 July 2022 (UTC)Reply

  In response to your two more issues you mention I agree that inactivity needs to be tightened, also on voting my view is the CU election should be a 14 day election, if they cannot hit 25 in 2 weeks then they probably do not need the tools on the wiki, such wikis can go to the Stewards when in need. Cheers Scott Thomson (Faendalimas) ^talk 13:17, 19 July 2022 (UTC)Reply

Concerning your last point, "COMPLY WITH LOCAL LEGISLATION": in Confidentiality agreement for nonpublic information there is: Exceptions to nonpublic personal data. Nonpublic personal data does not include any information which (a) [...] (d) is required by law to be disclosed by you, but you promise to give WMF prompt notice of such legal requirement and comply with any protective order imposed on such disclosure. Der-Wir-Ing ("DWI") talk 08:42, 19 July 2022 (UTC)Reply

• @Risker: as has been supposed in the chat on the mail list. Yes the actions of the French WP have caused this policy change. We received several requests over the their NomCom process. The OC does not have the mandate to recommend changes to policy at whim, this came about as a direct result of the case regarding the French WP and their NomCom process. What it came down to in the end was we had to determine if the process that the French WP had in place was in violation of policy and if so what to do about it. The problems with the French ArbCom are not something we have a say over it is outside our mandate. Many of the comments above were also raised by our various members and this led to a back and forth between WMF and the OC over this issue. In the end we recommended what Karen presented. It allows the process the French WP has developed to continue. I agree the whole policy needs an overhaul, and I do feel like we are playing catch-up here. I would be interested in a major overhaul of the policy and try to develop a workable document that is more to the communities needs. In the mean time we have to deal with issues as they arise. Chair Ombuds Commission Scott Thomson (Faendalimas) ^talk 13:40, 19 July 2022 (UTC)Reply

  Hello @Faendalimas: By reading the above, it'd appear that it is the OC opinion that the French Wikipedia method to appoint or demote users to CU/OS access is against the global policies, otherwise no change in the policy would be necessary, right? —MarcoAurelio (talk) 14:03, 19 July 2022 (UTC)Reply

  heya @MarcoAurelio: yes under current global policy there are two options in reality, appointment by ArbCom or Community Vote. What is the current practice on the French WP is neither of these. As such it is in violation of current policy. Hence the recommended changes above. Cheers Scott Thomson (Faendalimas) ^talk 14:16, 19 July 2022 (UTC)Reply

  While I am no longer on the OC and live in a common law jurisdiction, is there any reason why frwiki's practice cannot be "read in" to the current text? IMO an appointment body that meets the voting requirements of an ArbCom would seem to fall within the intent of the policy, especially when you consider that the policy has not been updated in a long time. – Ajraddatz (talk) 16:26, 19 July 2022 (UTC)Reply

Hi all, a quick update: as I'm sure has become obvious at this point, we've scrapped the intended 26 July implementation date. We're working on a big response for y'all. That response will probably make some suggestions as to what we could change in the proposed text to resolve the concerns that have been expressed, as well as talk about the reasoning behind the proposal and about the "whole policy needs an overhaul first" thing. I don't have an expected publish date for that response yet, but I'm hopeful we'll have it ready in the next week or so. Apologies for how long it's taking; Legal and I are taking extra time to make sure our thoughts are legally viable as well as consistent with community expectations. Kbrown (WMF) (talk) 12:34, 28 July 2022 (UTC)Reply

And here's that response:

Thanks for all your thoughts. We've reviewed the concerns people have expressed here and elsewhere and believe they have merit. We spoke with the Legal team and we want to address two points in particular, regarding how to amend the policy and how to ensure this amendment won’t be abused as well as some other points of feedback.

First, with regard to how to amend the policy, the checkuser and oversight policies are in a somewhat unusual position. They have some requirements that are dictated by law and other aspects that are open to community editing. For example, checkuser policies cannot permit data sharing that’s prohibited by the privacy policy and generally need to align with legal requirements for non-public data. Similarly, oversighted content presents a risk of abuse that could lead to legal claims against the Foundation or negligent users, so it needs a similar level of protection as to who can access the tool. On the other hand, details of the policies and how they’re handled are open to community tweaking and the Foundation does not dictate their precise wording. In this case, we found the review of the French language system for appointing checkusers and oversighters to be consistent with the Foundation’s legal obligations, but the Ombuds Commission expressed the concern that the checkuser and oversight policies as written did not permit the structure that French set up. The Ombuds Commission recommended that the policies be amended to allow this system (as it seems like it’s working well for French and there’s no legal reason others can’t do similar). We had intended to help effect their recommendation by making that change. Basically, our intention was to write into policy an already-existing appointment method that had been signed off on by OC and WMF Legal; this sort of descriptive (as opposed to prescriptive) policy-writing has been pretty common in the movement through the years. We still wanted to get community feedback from folks experienced with these tools though, and, we agree that given that there are objections to this proposal, it should go through a typical discussion process and be implemented by consensus. We’re hopeful that we can adjust the proposal to meet any concerns and reach that consensus. On re-reading the notifications we put out about this change, I think they may have been worded too bluntly and given the impression that we thought this was completely a WMF thing rather than a WMF-and-the-community thing, so apologies for that.

Second, regarding the concern of abuse, we suggest two additional language changes that may help address this point. First, we should add the following bolded language: “Appointments Committee whose members have been elected with the support of at least 25–30 members of the local community in an open election process.” This would mean that a project or group collecting 25-30 members to select a committee would not be able to do so unless they held a general vote on that wiki and were successful. Second, we suggest adding the following bolded language to indicate that there can only be one appointments committee per project: “Any committee meeting these requirements, including an Arbitration Committee (ArbCom), may fulfill this role, but there may only be one Appointments Committee per wiki.

In discussion elsewhere, people have noted that it's odd that the suggested changes say Appcoms can appoint but only Arbcoms can remove. That's also a good catch. It's written the way it is because that was Ombcom's recommendation; as we understand it, their reasoning is that if Appcom members don't hold CUOS - as they currently don't on Frwiki - then they cannot adequately investigate misuse of the tool(s). We're not 100% opposed to removals by Appcoms being allowed, but we also find the Ombcom reasoning persuasive on this and want to make sure those implications are considered.

I also want to acknowledge the concern that this number of voters may not be enough to accurately select checkusers and oversighters. We would be hesitant to raise this requirement too much given that many languages are small, but if there’s community consensus to raise it (or perhaps to raise it only for wikis having a certain number of active users) please feel free to do so via a distinct proposal as it would not be a legal problem for the Foundation if that requirement became more strict.

Lastly, there were a few comments that the policies need a bigger overhaul. This is a fair point but beyond the recommendation of the Ombuds Commission and not something we’ve looked into in detail in terms of what would be possible given current applicable laws. If there’s interest among community members in proposing other policy changes please feel free to do so and we’re happy to take a look at them to flag if they’d pose any legal problems for the Foundation. If there’s interest in having the Foundation spearhead a broader checkuser policy overhaul, we can look into what resources the Privacy and T&S teams would need to do that and try to schedule the project for the short to medium term future.

Could you let us know if these suggestions resolve the concerns that have been expressed? We are open to making further changes as needed to the proposed changes. Kbrown (WMF) (talk) 16:00, 3 August 2022 (UTC)Reply

I appreciate the clarifications and explanation of the WMF's position. --Rschen7754 07:33, 4 August 2022 (UTC)Reply

@Kbrown (WMF): Previously I have opened Requests for comment/Amendment of CheckUser policy and Oversight policy, which may contain issues and proposals you may concern. GZWDer (talk) 15:49, 13 August 2022 (UTC)Reply

Hi folks! After considering your comments here and elsewhere, and incorporating some tweaks to our proposed changes based on those comments, we think there is consensus to implement the following changes (removals in strikethrough, initially-proposed additions in italics, and tweaked additions in bold-italics):

On wikis with an Arbitration Committee (ArbCom) Appointments Committee whose members have been elected with the support of at least 25–30 members of the local community in an open election process which, at a minimum, meets all the same requirements as an election for each individual checkuser, CheckUsers may be directly appointed by the Arbitrators Committee. Any committee meeting these requirements, including an Arbitration Committee (ArbCom), may fulfil this role, but there may only be one Appointments Committee per wiki. After agreement, a member of the Committee should simply list the candidate on Steward requests/Permissions.

On a wiki without an Arbitration Appointments Committee that meets the criterion above, or in a project where there is a preference for independent elections, the community may approve local CheckUsers (stewards not counting as local CheckUsers) per consensus.

[...]

Suspicion of abuses of CheckUser should be discussed by each local wiki. On wikis with an approved ArbCom, the ArbCom can decide on the removal of access. On wikis without an approved ArbCom, the community can vote removal of access.

We'd make the corresponding update to the Oversight policy, as well.

We don't believe there's currently consensus in this discussion for implementing any general CU policy overhauls (though as noted previously, we're open to working on that in the future if there's a desire), for stating at a global level exactly how AppComs should function, for changing how CU is removed (Arbcom vs AppCom), or for raising the bar for required support for CU appointments. Of course, if you feel strongly that any of those should happen, you are more than welcome to open a discussion with the community (and, ideally, pinging user:WMFOffice so we're aware) on those topics; we're just proposing making an update, not saying this is the only update that can happen.

We'd like to implement these policy updates in the near future unless there are continued objections or unless we've missed any dealbreakers. Could you please give this revised proposal a read-through and let us know what you think? Thanks so much! Kbrown (WMF) (talk) 14:06, 19 September 2022 (UTC)Reply

"in an open election process which, at a minimum, meets all the same requirements as an election for each individual checkuser" - frequently arbitrators on enwiki get below 70% in SecurePoll which would fail that wording. Rschen7754 18:05, 19 September 2022 (UTC)Reply

Oh, a very good point Rschen7754! I'm compiling thoughts about this revised proposal for review by Legal, so I'm adding that one to my list for us to think about. Currently also on my list are:

• What about projects that don't elect their CUs at all (i.e. they use Arbcom appointment)? What standard does this policy require from them?
• Not every project has exact thresholds and procedures for CU elections that could be applied as laid out here, so what standard does their AppCom use? Kbrown (WMF) (talk) 12:56, 20 September 2022 (UTC)Reply

If I may make an observation here. In the part "Suspicion of abuses of CheckUser should be discussed by each local wiki. On wikis with an approved ArbCom, the ArbCom can decide on the removal of access. On wikis without an approved ArbCom, the community can vote removal of access. Suspicion of abuses of CheckUser should be discussed by each local wiki. On wikis with an approved ArbCom, the ArbCom can decide on the removal of access. On wikis without an approved ArbCom, the community can vote removal of access." This may be a little problematic. If a CU goes rogue its likely that it will require investigation of their logs, which requires access to the CU tools. In which case issues such as this are more likely to need to be sent to the Stewards or OC as the case may be. In the absence of an ArbCom that is.

"In the absence of an ArbCom that is." How would an Arbcom help? I mean, only one of the 12 arbcoms can read the CU logs on their project.

Anyways, including a list of persons and groups who are technically able to do some investigations could help here.

Also, the text more or less implies, that on a project with arbcom the community can not decide. That would lead to some cases where the arbcom is not allowed to grant CU right (insted done by public voting) but the arbcom would be responsible for removing them. --Der-Wir-Ing ("DWI") talk 14:55, 29 September 2022 (UTC)Reply

There may be Arbcoms whose members are not even have the sysop flags, or which intentionally consist of members who have expertise in conflict resolution but not too much technical understanding. In any case most Arbcom members outside the English Wikipedia may have not sign any confidentiality agreement. I think it doesn't make any sense at all to entitle them to make any call based on evidence they may not even see. I think the whole approach is moot except for one wiki were it already is the status quo. --Krd 15:10, 29 September 2022 (UTC)Reply

Fair point, yes it would require that at least one ArbCom member could investigate. I had been told ArbComs could handle this. If that few can actually do this effectively then investigating the actions of CUs in those cases its needed will have to be with the stewards or oc as relevant. Cheers Scott Thomson (Faendalimas) ^talk 15:44, 29 September 2022 (UTC)Reply

Hello User:Oshwah, hello readers all, how do you think about deleting the word "that" from the phrase "Determine from which IP addresses that an account has performed edits, logged actions, or password resets on the Wikimedia wiki;"? After the deletion, the phrase would read "Determine from which IP addresses an account has performed edits, logged actions, or password resets on the Wikimedia wiki;". I am de-N, en-2, maybe my point of view is affected by the 2 (<4) in "en-2". --Himbeerbläuling (talk) 13:18, 4 March 2023 (UTC)Reply

Himbeerbläuling - I don't see the use of the word "that" in the particular sentence to be unnecessary. I think it supports the sentence just fine in this context, but I also don't feel that keeping the word is mandatory or essential in order for the sentence to retain the same meaning. I stand neutral with the idea of removing the word. ~Oshwah~^{(talk) (contribs)} 01:51, 13 April 2023 (UTC)Reply

I think it's better without it and have removed it. Emufarmers (talk) 00:08, 18 April 2023 (UTC)Reply

Hi. In CheckUser policy#Appointing local CheckUsers it says
"The CheckUser candidate status must request it within the local community [...]". I assume it's meant to be something like
"The CheckUser candidate must request the status within the local community [...]" or perhaps
"The candidate must request the CheckUser status within the local community [...]" since a status cannot make requests, but a candidate can. TilmannR (talk) 13:50, 5 March 2023 (UTC)Reply

Thanks for pointing this out. Done. Emufarmers (talk) 00:14, 18 April 2023 (UTC)Reply

Hello, is it allowed as a Checkuser, to use the Checkuser tooling for getting the IP address of a blocked account, and then block this IP address as well? I'm not talking about autoblock, but a Checkuser actually imposing a manual block of this IP address such that the IP address blocked becomes visible in the log files of blocked users. The fact that the IP address was blocked without any edits, the time it was blocked, the Checkuser who blocked it and the blocking reason could users who watch the log files lead to the conclusion which (recently blocked) account might be behind the IP address. Is this allowed or is this a violation of the Checkuser policy? Temp account II (talk) 09:00, 8 October 2023 (UTC)Reply