| Revision as of 18:51, 28 September 2023 editBeeblebrox (talk | contribs)Autopatrolled, Administrators112,480 edits →The "contacting a checkuser" section.: new sectionTag: New topic← Previous edit | Latest revision as of 17:48, 18 November 2024 edit undoLowercase sigmabot III (talk | contribs)Bots, Template editors2,293,704 editsm Archiving 1 discussion(s) to Misplaced Pages talk:CheckUser/Archive 7) (bot | ||
| (45 intermediate revisions by 24 users not shown) | |||
| Line 5: | Line 5: | ||
| | algo = old(180d) | | algo = old(180d) | ||
| | archive = Misplaced Pages talk:CheckUser/Archive %(counter)d | | archive = Misplaced Pages talk:CheckUser/Archive %(counter)d | ||
| | counter = |
| counter = 7 | ||
| | maxarchivesize = 150K | | maxarchivesize = 150K | ||
| | archiveheader = {{Automatic archive navigator}} | | archiveheader = {{Automatic archive navigator}} | ||
| Line 12: | Line 12: | ||
| }} | }} | ||
| == Potential Checkuser involvement in ] == | |||
| == Academic question == | |||
| In the 2024 RFA review, ] in the Phase 2 of Admin recall involves Checkuser confirmation. Feedback from active CU would be appreciated on how feasible this would be. ] (]) 17:13, 11 May 2024 (UTC) | |||
| In real life I am conducting academic research and publishing on the topic of privacy. (See, for example, https://link.springer.com/chapter/10.1007/978-3-030-91081-5_6) I have a couple questions in my capacity as a member of the reading public, not as a Misplaced Pages editor. | |||
| == Transparency in the Checkuser Process == | |||
| Do checkusers ever copy fingerprint data (IP and/or user agent string) and save it anywhere for future reference? The policy says that such data is not logged, but it is silent on the question whether such data may be copied and retained manually, such as in notes, a private wiki, or shared via a mailing list. | |||
| The checkuser process is not open to auditing. From a technical perspective, there is no page to confirm that the checkuser process was performed because it likely involves not only the internal technical aspect handled by the MediaWiki tool but also a human element in analyzing user behavior patterns. I believe there should be a task list available that can at least ensure the technical checkuser was conducted and found no connection. It is not clear to me that it was done just because the administrator said so. I think this step is necessary to prevent human errors. ] (]) 23:12, 31 May 2024 (UTC) | |||
| <s>Does anybody know where to find the http access log retention policy for Misplaced Pages? I am also interested to know what data is logged when people read Misplaced Pages, if any, and how long any such data is retained.</s> Found it here: https://meta.wikimedia.org/Data_retention_guidelines | |||
| Thank you. ] <sup>]</sup> 17:57, 4 January 2022 (UTC) | |||
| :Something like this was asked before: ]. I'm going to have to mainly refer you to that answer. It's mentioned overleaf that there is a checkuser wiki and a checkuser mailing list. I would also recommend the privacy policy if you haven't seen it, perhaps particularly ] or ]. -- ] <sup>]</sup> 19:51, 4 January 2022 (UTC) | |||
| ::Thank you. I was sort of afraid of that. Those answers in Archive 47 are concerning and somebody should get in touch with WMF Legal and go over that to tighten things up. ] <sup>]</sup> 20:53, 4 January 2022 (UTC) | |||
| :@]: As an aside, that paper is heavily aligned with what I (used to) do at my previous company - would I be able to trouble you for a copy, if you'd be so kind? -- ] (] • she/her) 20:35, 4 January 2022 (UTC) | |||
| :: There's a free copy right here: https://cpsc.yale.edu/sites/default/files/files/TR1558.pdf. Also, we are working on a new paper that describes using some better math to improve the security properties. This first paper is just a proof of concept. ] <sup>]</sup> 20:43, 4 January 2022 (UTC) | |||
| :::@]: Thank you kindly! {{p}} -- ] (] • she/her) 20:49, 4 January 2022 (UTC) | |||
| :You can't get any personal information from IP addresses. Not even using Bash. So why you do care? ] (]) 03:08, 13 October 2022 (UTC) | |||
| ::Someone's employer or rough geographic location would be considered personal information. Both of those are things that can be derived from IPs. ] (]) 03:12, 13 October 2022 (UTC) | |||
| :::It's even worse when you have a sequence of IP addresses. If you know the neighborhood where somebody lives, what coffee shop they frequent, and where they work, as well as the timing of their activity, that information has a lot of entropy. ] <sup>]</sup> 03:26, 13 October 2022 (UTC) | |||
| :@] that's not entirely true. The CU process can (and is) audited by other checkusers, both internal to enwiki and across projects via the ] (which I happen to be serving on at the moment). You are certainly correct, however, that non-checkusers have no direct visibility into the process; this is an area where preserving user privacy trumps transparency. ] ] 23:40, 31 May 2024 (UTC) | |||
| == How many times has this tool been used on my account? == | |||
| ::I understand that other checkusers can authenticate themselves but I was talking about a more transparent automatic tool that will simply show that the technical evaluation was actually done, but available to everyone without giving details of how the tool or the automated technical evaluation works internally. ] (]) 23:51, 31 May 2024 (UTC) | |||
| :::I get the desire to know this, but even divulging that a check has been done (other than a checkuser talking about a check they did themselves) is considered a violation of the privacy policies. ] ] 23:56, 31 May 2024 (UTC) | |||
| ::::I believe it's technically OK to say that 'a checkuser' has checked something, that is, saying that a check was done without disclosing in any way which other party ran the check. The governing policy concerns 'non-public personal data'; if an account being checked is considered personal data then there's a whole load of people in trouble. There are numerous other potential problems with this proposal however, some of which would easily potentially violate privacy, others would potentially compromise effectiveness in combating disruption. -- ] <sup>]</sup> 00:17, 1 June 2024 (UTC) | |||
| :::::What I propose is an automated tool that confirms the execution of the checkuser without revealing any private data. Even though there is a group of checkusers verifying the process, this is not sufficient. For greater transparency, it should be publicly shown that the checkuser was indeed carried out and not merely a decision based on other factors. ] (]) 12:47, 2 June 2024 (UTC) | |||
| ::::::On-demand reporting of checks can in fact reveal non-public data, for example closely linked accounts. It can also provide undesirable notice to a bad person that we're on to them. A lot of blocked sockpuppets might have no checks registered against their account. And a non-positive check result is very rarely a declaration of innocence. But basically checkusers are not going to say they've run a check when they haven't. They're just not. Why would they even? -- ] <sup>]</sup> 14:48, 2 June 2024 (UTC) | |||
| == "]" listed at ] == | |||
| ] | |||
| The redirect <span class="plainlinks"></span> has been listed at ] to determine whether its use and function meets the ]. Readers of this page are welcome to comment on this redirect at '''{{slink|Misplaced Pages:Redirects for discussion/Log/2024 July 5#CheckUser}}''' until a consensus is reached. <!-- Template:RFDNote --> ] (]) 06:40, 5 July 2024 (UTC) | |||
| == Using CU template on talk pages? == | |||
| Any way to find out, and the name of the Checkuser who performed the check? Or does this only get revealed in special circumstances? ] 13:08, 15 October 2022 (UTC) | |||
| :In my experience, checkusers don't make a habit of talking about that kind of thing. I can think of several reasons why that might make sense. Users making such requests are normally directed to the relevant oversight people if they suspect abuse of the tool (yes, I know). In cases where there may be another checkuser involved, I seem to recall their checkuser activity may fall under the definition of non-public data in itself, though I'd have to look that up to be sure. What I am happy to say is that the overwhelming majority of users, regular or otherwise, who have never acted suspiciously or been credibly accused of sockpuppetry, will have zero checks logged. -- ] <sup>]</sup> 13:50, 15 October 2022 (UTC) | |||
| ::That certainly matches my understanding. As a CU, I'm allowed to disclose that I checked an account (that happens all the time at SPI), but I'm not allowed to disclose what checks other CUs have run. If you have specific concerns, my suggestion is to ], but I suspect you'll need to give them an exceptionally good reason before they would divulge that information. -- ] ] 15:04, 15 October 2022 (UTC) | |||
| I have recently seen articles where there were very clearly cases of ] present. Might one invoke something like the <nowiki>{{checkuser needed}}</nowiki> template in such cases? Should one expect this to be followed up on? ... Or is '''privately''' reporting suspected IP socks (as opposed to an official SPI) ''always'' the best modus operandi? ] (]) 22:02, 5 September 2024 (UTC) | |||
| :::Hmm. Okay. Thank you both for your replies. 😀 ] 16:25, 15 October 2022 (UTC) | |||
| :::{{ping|RoySmith}} Super late reply, but I wanted to point out that ] states in verbatim: {{tq|Checkusers are permitted, but not required, to inform an editor that their account has been checked. The result of a check may be disclosed to the community (on a community process page like ]).}} I understand this to mean that checkusers have discretion under policy inform someone that their account has been checked, even if the check was performed by another checkuser. Whether this permits a CU from disclosing the name of the CU is less clear, and the policy of course states that this is "permitted, but not required"—it is indeed quite rare that CUs will agree to disclose anything from the CU log outside of reporting results at SPI. ] (]) 06:20, 9 November 2022 (UTC) | |||
| ⚫ | : |
||
| :::::Checkusers absolutely are forbidden from posting ''other'' CUs who have made checks on an account. ] (]) 14:39, 9 November 2022 (UTC) | |||
| ::::::Indeed; ] is the relevant clarification from legal (and should perhaps be linked somewhere?). --] (]) 14:48, 9 November 2022 (UTC) | |||
| :::::::{{ping|Blablubbs|Primefac}} To be clear, that clarification applies only to disclosing the ''names'' of checkusers that have previously run checks on an account—is that right? For example, if I decline to check an account at SPI by stating publicly that "another CU has already looked into this account", would that be permissible? ] (]) 23:28, 10 November 2022 (UTC) | |||
| :As a matter of policy and practice, CUs do not publicly disclose the IP address an account is operating from (barring extremely exugent circumstances or incidental disclosure by users drawing inference from the block log) so using that template the way you describe is unlikely to result in a CU being able to assist. ] | ] 22:27, 5 September 2024 (UTC) | |||
| == Proposed policy == | |||
| ::Thank you, @]. Now, would reporting the details to one (or multiple; in case of urgency...) CUs via email be likely to result in an investigation? And are there any steps after one or multiple such users have not responded? ] (]) 22:34, 5 September 2024 (UTC) | |||
| {{archive top|I'm going to go ahead and close this section per ], as I think enough has been said. Under current practice, stewards will only lock accounts if there is evidence of cross-wiki abuse. Because of this, the current practice on enwiki is to only report sockpuppets of ''cross-wiki'' sockmasters to ]. If an account uses sockpuppets on enwiki and no other project, then it is unlikely that a steward will agree to lock that account. This page is not the right place to propose a change to that common practice—if such a change is truly desired, the best place would be in a discussion with the stewards . Respectfully, ] (]) 06:14, 9 November 2022 (UTC)}} | |||
| :::There are very few circumstances in which CUs will use their access to confirm that an IP and an account are the same, even for themselves. Mostly because it's not necessary. If it's obvious enough to investigate, it should be obvious enough for a block. Just file an SPI but without a CU request. Or if there's active, ongoing disruption use AIV. ] | ] 23:11, 5 September 2024 (UTC) | |||
| If someone is found to be a sockpuppet via CheckUser here, I propose you always report that to ]. Users who have been blocked here have gone on to edit other wikis, and it just creates more work to block or investigate over and over again, including on smaller ones (e.g. ]) where we don't even have local CheckUsers. Is there something that I'm missing here about why this wouldn't be desirable, other than the added overhead on CheckUsers here? ―]<span style="color:red">❤]☮]☺]☯</span> 00:02, 8 November 2022 (UTC) | |||
| == Device fingerprint == | |||
| :Oh hell no. ] (]) 00:06, 8 November 2022 (UTC) | |||
| ::Because? ―]<span style="color:red">❤]☮]☺]☯</span> 00:42, 8 November 2022 (UTC) | |||
| :::As GN said, socking on one wiki is not automatically cross-wiki abuse. Reporting socks to SRG increases the workload on the Stewards, given that we have to confirm the results of the local investigation, decide if global action is necessary, run checks on loginwiki if appropriate, and then deal with the inevitable appeals. We don't have the bandwidth to deal with frivolous requests that don't actually involve cross-wiki abuse. You are welcome to establish consensus on enwikiquote that accounts blocked for sockpuppetry on the English Misplaced Pages should also be blocked on enwikiquote and block them yourself. ] (]) 03:45, 8 November 2022 (UTC) | |||
| ::::Why wouldn't you write a useful response like this initially instead of forcing someone else to solicit meaningful feedback? ―]<span style="color:red">❤]☮]☺]☯</span> 05:18, 8 November 2022 (UTC) | |||
| :Accounts aren't locked unless they've caused cross-wiki disruption (or belong to someone known to cause cross-wiki disruption). It's not used as a first resort, especially since different projects have different rules on what constitutes blockable sockpuppetry. ] (]) 00:08, 8 November 2022 (UTC) | |||
| ::So the policy is to wait until they've edited on other wikis? I don't understand this: if User X is abusing multiple accounts, then Sockpuppet Y, Sockpuppet Z, etc. shouldn't be editing Wikiquote and Wikibooks, etc. anyway. Am I wrong? ―]<span style="color:red">❤]☮]☺]☯</span> 00:44, 8 November 2022 (UTC) | |||
| :::You are indeed wrong. Like I said, other projects have different rules on what constitutes blockable sockpuppetry. Further, a block on one project does not correspond to a block on all projects (for good reason!) and if User X has only edited enwiki, then there is no policy-based reason for Sock Y to not be able to edit enwikiquote or Sock Z not to be able to edit enwikiversity. ] (]) 01:10, 8 November 2022 (UTC) | |||
| ::::Which project allows or encourages sockpuppets? ―]<span style="color:red">❤]☮]☺]☯</span> 02:54, 8 November 2022 (UTC) | |||
| :::::Not many, commons sort of does. But local blocks don't necessitate global action unless there is cross-wiki abuse. We will not lock accounts whose actions do not necessitate a lock. Pursuing this further is a waste of time, that is not going to change. ] (]—]) 03:55, 8 November 2022 (UTC) | |||
| ::::::How does Commons allow or encourage sockpuppets? ―]<span style="color:red">❤]☮]☺]☯</span> 05:18, 8 November 2022 (UTC) | |||
| :::::::Could you please focus on the original responses and not get sidetracked on which projects "allow or encourage" sockpuppets? That isn't even what I said in the first place, and is ignoring the main thrust of my response. ] (]) 22:43, 8 November 2022 (UTC) | |||
| ::::::::I'm responding to what someone else wrote and I did respond to your above comment. What, in principle, would you like me to write? As you pointed out, global locks only occur after there has been cross-wiki abuse. Okay, noted. ―]<span style="color:red">❤]☮]☺]☯</span> 22:47, 8 November 2022 (UTC) | |||
| :What GN said. So therefore, what ACN said. ] (]—]) 00:22, 8 November 2022 (UTC) | |||
| *It's impossible to overstate how problematic this would be. Stewards would be overwhelmed with request that are not within their purview. They would have no choice but to just start ignoring the flood of reports, accomplishing nothing. ] (]) 04:35, 8 November 2022 (UTC) | |||
| *{{yo|GeneralNotability}} {{tqq|Further, a block on one project does not correspond to a block on all projects (for good reason!)}} What's the good reason? ] (]) 18:26, 8 November 2022 (UTC) | |||
| *:{{u|Levivich}}, practically speaking, if a block anywhere equated to a block everywhere, that would allow any project to dictate blocking policy for all the others. Policies differ - for example, enwiki disallows the use of the names of organizations as account names, while other projects allow that. Or paid editing - Commons does not require paid-editing disclosures, while other projects do. ] (]) 22:41, 8 November 2022 (UTC) | |||
| *::Thanks. I'm curious why you think that's a ''good'' reason. Why shouldn't we have one block policy for all projects? (You know, like a universal code of conduct...) What's the benefit of allowing projects to set differing local policies about behaviors that are serious enough to be blocked over? Particularly given the interdependence of projects, like en, commons, data, source, quote, wikt... I don't get why it's good that when someone is blocked here for, say, making stuff up, or harassment, or pretending to be multiple people in order to influence content, or whatever, they can just go off to wikidata or wherever and continue the problematic behavior there. To ask the converse of a question asked above: if someone is blocked on another wiki for socking, why would we want them editing at enwiki? The only reason I can think of is that we don't trust that the decisions made on other wikis are made well, and vice versa. ] (]) 22:53, 8 November 2022 (UTC) | |||
| *:::First of all - you're inverting what I said :) My comment was on the capacity of local policies having a global impact, not on whether we should have global policies. And even if we did have a global policy...I'd consider that to be a minimum, one which projects could build on top of. As for {{tq|we don't trust that the decisions made on other wikis are made well}}, well...yes, decisions on other wikis are not always made well. They aren't always made well here, either! Also, consider - there's ] ] ] ] where other language Wikipedias might consider the enwiki version of the story to be "making stuff up"/disinformation (if memory serves, there are or have been versions of those linked articles on other languages where the unpleasantness was downplayed or caveated with things like "according to Western sources"). Do we want a block for not toeing the official narrative in those countries/languages to be global? ] (]) 00:27, 9 November 2022 (UTC) | |||
| *:Just because someone is disruptive in one place in one way does not mean that person cannot provide value elsewhere. E.g. someone fundamentally not understanding appropriate media uploads at ] is not necessarily someone who cannot write some good recipes at ]. ―]<span style="color:red">❤]☮]☺]☯</span> 22:49, 8 November 2022 (UTC) | |||
| *::And, different projects may have fundamentally different views of what constitutes disruptive behavior. It's not hard to imagine a project which forbids editing on certain days of the year due to their religious significance, and blocks people who violate that rule. Would that be a good reason to also block them on enwiki? -- ] ] 23:27, 8 November 2022 (UTC) | |||
| *:::Does that or something like that actually happen? I find it extremely hard to imagine. A WMF project closed for religious holiday? ] (]) 23:32, 8 November 2022 (UTC) | |||
| *:::"It's not hard to imagine a project which forbids editing on certain days of the year due to their religious significance" Wait, what? ―]<span style="color:red">❤]☮]☺]☯</span> 00:14, 9 November 2022 (UTC) | |||
| *::::I, uh, find that very hard to imagine. ] (]) 00:32, 9 November 2022 (UTC) | |||
| *:::::We've had a project block people simply because they displayed a pride flag on their global userpage before. Granted, the admin who did that wheelwarred with a steward and ended up ], but hey. <span style="font-family: Verdana;">]</span> (]) 00:39, 9 November 2022 (UTC) | |||
| {{archive bottom}} | |||
| Do CUs have access to ] data? -- ] (]) (PING me) 18:49, 17 November 2024 (UTC) | |||
| ==Should administrators be desysopped for undoing a checkuser block?== | |||
| {{atop | |||
| | status = | |||
| | result = OP has been blocked. For those looking for the referenced thread, it's ] ] ] 16:41, 7 July 2023 (UTC) | |||
| }} | |||
| Many years ago, the arbcom reminded users that checkusers have access to hidden information most of us don't. while it's accepted that undoing an arbcom decision lead to desysopping arbcom editors are usually held in an official light given they're nominated by a more rigorous process than the run of the mill RFA where all editor can simply support or oppose the request. That being said I would like to clarify | |||
| #are checkusers a subdivision of arbcom? | |||
| #given that a checkuser block can be restore like any other edit, would it be more prudent to AGF on the part person who reversed the block and simply restore the block? hundreds of accounts get indeffed and all too often the creator of these accounts end up in a vicious cycle of sock/block they can't escape. | |||
| #how exactly would regular admin unblocking a checkuserblock undermine the site's integrity? ] (]) 13:52, 7 July 2023 (UTC) | |||
| :This a crazy RfC. Much of the English is imprecise and borders on incomprehensible. I don't see why we should we be wasting our time on such an ill-considered RfC.--] (]) 14:03, 7 July 2023 (UTC) | |||
| ::@] Seems related to their Admin Review and ANI threads chasing after Daniel Case. I've left a comment at ANI. I'm just going to remove the RFC tag. This isn't even asking for a change to policy, just questioning it. -- ] (]) 14:23, 7 July 2023 (UTC) | |||
| {{abot}} | |||
| == CheckUser VRT Role Account == | |||
| Hi, | |||
| I’m not sure what would need to happen to set this up — or if it would be technically prohibitive — but I was wondering if it would be possible to set up a CheckUser role account, similar to ], for the purpose of sending emails through Misplaced Pages to the CheckUser VRT queue. | |||
| My reason for asking this is because the email linked to my WP account is an anonymous one, which I can reply to emails ''sent'' to, but can’t ''initiate'' emails from that specific address directly (or at least, I don’t think I can). Therefore, if I sent an email from my email client to the CheckUser email address, it wouldn’t be able to be verified to my account; whereas one sent through the Misplaced Pages interface would be. | |||
| Best, ] (]) 11:52, 1 September 2023 (UTC) | |||
| == The "contacting a checkuser" section. == | |||
| ⚫ | :What we have is described at ] ] ] 18:53, 17 November 2024 (UTC) | ||
| Currently, it advises users to look at the "active users" list, which shows which user who happen to have CU bits have done literally anything lately, while ] shows who has been recently active ''as a CU''. Should we replace and/or just add a link to the stats? Thoughts? ] (]) 18:51, 28 September 2023 (UTC) | |||
Latest revision as of 17:48, 18 November 2024
 | The project page associated with this talk page is an official policy on Misplaced Pages. Policies have wide acceptance among editors and are considered a standard for all users to follow. Please review policy editing recommendations before making any substantive change to this page. Always remember to keep cool when editing, and don't panic. | Shortcuts |
 | Text and/or other creative content from this version of Misplaced Pages:User access levels was copied or moved into Misplaced Pages:CheckUser with this edit on 10 January 2017. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. |
 Archives | |||||||
|
|||||||
|
This page has archives. Sections older than 180 days may be automatically archived by Lowercase sigmabot III when more than 5 sections are present. |
Potential Checkuser involvement in admin recall
In the 2024 RFA review, one of the subproposals in the Phase 2 of Admin recall involves Checkuser confirmation. Feedback from active CU would be appreciated on how feasible this would be. Soni (talk) 17:13, 11 May 2024 (UTC)
Transparency in the Checkuser Process
The checkuser process is not open to auditing. From a technical perspective, there is no page to confirm that the checkuser process was performed because it likely involves not only the internal technical aspect handled by the MediaWiki tool but also a human element in analyzing user behavior patterns. I believe there should be a task list available that can at least ensure the technical checkuser was conducted and found no connection. It is not clear to me that it was done just because the administrator said so. I think this step is necessary to prevent human errors. Wilfredor (talk) 23:12, 31 May 2024 (UTC)
- @Wilfredor that's not entirely true. The CU process can (and is) audited by other checkusers, both internal to enwiki and across projects via the Ombuds Commission (which I happen to be serving on at the moment). You are certainly correct, however, that non-checkusers have no direct visibility into the process; this is an area where preserving user privacy trumps transparency. RoySmith (talk) 23:40, 31 May 2024 (UTC)
- I understand that other checkusers can authenticate themselves but I was talking about a more transparent automatic tool that will simply show that the technical evaluation was actually done, but available to everyone without giving details of how the tool or the automated technical evaluation works internally. Wilfredor (talk) 23:51, 31 May 2024 (UTC)
- I get the desire to know this, but even divulging that a check has been done (other than a checkuser talking about a check they did themselves) is considered a violation of the privacy policies. RoySmith (talk) 23:56, 31 May 2024 (UTC)
- I believe it's technically OK to say that 'a checkuser' has checked something, that is, saying that a check was done without disclosing in any way which other party ran the check. The governing policy concerns 'non-public personal data'; if an account being checked is considered personal data then there's a whole load of people in trouble. There are numerous other potential problems with this proposal however, some of which would easily potentially violate privacy, others would potentially compromise effectiveness in combating disruption. -- zzuuzz 00:17, 1 June 2024 (UTC)
- What I propose is an automated tool that confirms the execution of the checkuser without revealing any private data. Even though there is a group of checkusers verifying the process, this is not sufficient. For greater transparency, it should be publicly shown that the checkuser was indeed carried out and not merely a decision based on other factors. Wilfredor (talk) 12:47, 2 June 2024 (UTC)
- On-demand reporting of checks can in fact reveal non-public data, for example closely linked accounts. It can also provide undesirable notice to a bad person that we're on to them. A lot of blocked sockpuppets might have no checks registered against their account. And a non-positive check result is very rarely a declaration of innocence. But basically checkusers are not going to say they've run a check when they haven't. They're just not. Why would they even? -- zzuuzz 14:48, 2 June 2024 (UTC)
- What I propose is an automated tool that confirms the execution of the checkuser without revealing any private data. Even though there is a group of checkusers verifying the process, this is not sufficient. For greater transparency, it should be publicly shown that the checkuser was indeed carried out and not merely a decision based on other factors. Wilfredor (talk) 12:47, 2 June 2024 (UTC)
- I believe it's technically OK to say that 'a checkuser' has checked something, that is, saying that a check was done without disclosing in any way which other party ran the check. The governing policy concerns 'non-public personal data'; if an account being checked is considered personal data then there's a whole load of people in trouble. There are numerous other potential problems with this proposal however, some of which would easily potentially violate privacy, others would potentially compromise effectiveness in combating disruption. -- zzuuzz 00:17, 1 June 2024 (UTC)
- I get the desire to know this, but even divulging that a check has been done (other than a checkuser talking about a check they did themselves) is considered a violation of the privacy policies. RoySmith (talk) 23:56, 31 May 2024 (UTC)
- I understand that other checkusers can authenticate themselves but I was talking about a more transparent automatic tool that will simply show that the technical evaluation was actually done, but available to everyone without giving details of how the tool or the automated technical evaluation works internally. Wilfredor (talk) 23:51, 31 May 2024 (UTC)
"CheckUser" listed at Redirects for discussion
The redirect CheckUser has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Misplaced Pages:Redirects for discussion/Log/2024 July 5 § CheckUser until a consensus is reached. Ahri Boy (talk) 06:40, 5 July 2024 (UTC)
Using CU template on talk pages?
I have recently seen articles where there were very clearly cases of WP:LOUTSOCK present. Might one invoke something like the {{checkuser needed}} template in such cases? Should one expect this to be followed up on? ... Or is privately reporting suspected IP socks (as opposed to an official SPI) always the best modus operandi? Biohistorian15 (talk) 22:02, 5 September 2024 (UTC)
- As a matter of policy and practice, CUs do not publicly disclose the IP address an account is operating from (barring extremely exugent circumstances or incidental disclosure by users drawing inference from the block log) so using that template the way you describe is unlikely to result in a CU being able to assist. HJ Mitchell | Penny for your thoughts? 22:27, 5 September 2024 (UTC)
- Thank you, @HJ Mitchell. Now, would reporting the details to one (or multiple; in case of urgency...) CUs via email be likely to result in an investigation? And are there any steps after one or multiple such users have not responded? Biohistorian15 (talk) 22:34, 5 September 2024 (UTC)
- There are very few circumstances in which CUs will use their access to confirm that an IP and an account are the same, even for themselves. Mostly because it's not necessary. If it's obvious enough to investigate, it should be obvious enough for a block. Just file an SPI but without a CU request. Or if there's active, ongoing disruption use AIV. HJ Mitchell | Penny for your thoughts? 23:11, 5 September 2024 (UTC)
- Thank you, @HJ Mitchell. Now, would reporting the details to one (or multiple; in case of urgency...) CUs via email be likely to result in an investigation? And are there any steps after one or multiple such users have not responded? Biohistorian15 (talk) 22:34, 5 September 2024 (UTC)
Device fingerprint
Do CUs have access to device fingerprint data? -- Valjean (talk) (PING me) 18:49, 17 November 2024 (UTC)
- What we have is described at mw:Extension:CheckUser RoySmith (talk) 18:53, 17 November 2024 (UTC)