Wikipedia talk:CheckUser/Archive 7

Archive 1

←

Archive 5

Archive 6

Archive 7

Academic question

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 Wikipedia editor.

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.

Does anybody know where to find the http access log retention policy for Wikipedia? I am also interested to know what data is logged when people read Wikipedia, if any, and how long any such data is retained. Found it here: https://meta.wikimedia.org/wiki/Data_retention_guidelines Thank you. Jehochman ^Talk 17:57, 4 January 2022 (UTC)

Something like this was asked before: Wikipedia_talk:Arbitration_Committee/Noticeboard/Archive_47#Questions_to_Committee_on_data_handling_procedures. 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 this section or this one. -- zzuuzz ^(talk) 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. Jehochman ^Talk 20:53, 4 January 2022 (UTC)

@Jehochman: 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? -- TNT (talk • 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. Jehochman ^Talk 20:43, 4 January 2022 (UTC)

@Jehochman: Thank you kindly! -- TNT (talk • 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? Alexysun (talk) 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. TonyBallioni (talk) 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. Jehochman ^Talk 03:26, 13 October 2022 (UTC)

How many times has this tool been used on my account?

Any way to find out, and the name of the Checkuser who performed the check? Or does this only get revealed in special circumstances?  Tewdar  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. -- zzuuzz ^(talk) 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 contact arbcom, but I suspect you'll need to give them an exceptionally good reason before they would divulge that information. -- RoySmith (talk) 15:04, 15 October 2022 (UTC)

Hmm. Okay. Thank you both for your replies. 😀  Tewdar  16:25, 15 October 2022 (UTC)

@RoySmith: Super late reply, but I wanted to point out that Wikipedia:CheckUser#Notifying the account that is checked states in verbatim: 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 Wikipedia:Sockpuppet investigations). 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. Mz7 (talk) 06:20, 9 November 2022 (UTC)

@Mz7 Thanks for the followup. This sounds like something that we should get clarified. -- RoySmith (talk) 14:35, 9 November 2022 (UTC)

Checkusers absolutely are forbidden from posting other CUs who have made checks on an account. Primefac (talk) 14:39, 9 November 2022 (UTC)

Indeed; m:Talk:Access to nonpublic personal data policy/Archives/2021#Clarification of the ANPDP is the relevant clarification from legal (and should perhaps be linked somewhere?). --Blablubbs (talk) 14:48, 9 November 2022 (UTC)

@Blablubbs and 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? Mz7 (talk) 23:28, 10 November 2022 (UTC)

Proposed policy

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

If someone is found to be a sockpuppet via CheckUser here, I propose you always report that to m:Steward requests/Global. 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. q:) 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? ―Justin (koavf)❤T☮C☺M☯ 00:02, 8 November 2022 (UTC)

Oh hell no. AntiCompositeNumber (talk) 00:06, 8 November 2022 (UTC)

Because? ―Justin (koavf)❤T☮C☺M☯ 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 Wikipedia should also be blocked on enwikiquote and block them yourself. AntiCompositeNumber (talk) 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? ―Justin (koavf)❤T☮C☺M☯ 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. GeneralNotability (talk) 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? ―Justin (koavf)❤T☮C☺M☯ 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. GeneralNotability (talk) 01:10, 8 November 2022 (UTC)

Which project allows or encourages sockpuppets? ―Justin (koavf)❤T☮C☺M☯ 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. Vermont (🐿️—🏳️‍🌈) 03:55, 8 November 2022 (UTC)

How does Commons allow or encourage sockpuppets? ―Justin (koavf)❤T☮C☺M☯ 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. GeneralNotability (talk) 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. ―Justin (koavf)❤T☮C☺M☯ 22:47, 8 November 2022 (UTC)

What GN said. So therefore, what ACN said. Vermont (🐿️—🏳️‍🌈) 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. Beeblebrox (talk) 04:35, 8 November 2022 (UTC)
• @GeneralNotability: Further, a block on one project does not correspond to a block on all projects (for good reason!) What's the good reason? Levivich (talk) 18:26, 8 November 2022 (UTC)

  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. GeneralNotability (talk) 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. Levivich (talk) 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 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 no shortage of topics 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? GeneralNotability (talk) 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 c: is not necessarily someone who cannot write some good recipes at b:. ―Justin (koavf)❤T☮C☺M☯ 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? -- RoySmith (talk) 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? Levivich (talk) 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? ―Justin (koavf)❤T☮C☺M☯ 00:14, 9 November 2022 (UTC)

  I, uh, find that very hard to imagine. GeneralNotability (talk) 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 globally community banned, but hey. stwalkerster (talk) 00:39, 9 November 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should administrators be desysopped for undoing a checkuser block?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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

1. are checkusers a subdivision of arbcom?
2. 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.
3. how exactly would regular admin unblocking a checkuserblock undermine the site's integrity? Shim119 (talk) 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.--Bbb23 (talk) 14:03, 7 July 2023 (UTC)

@Bbb23 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. -- ferret (talk) 14:23, 7 July 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The "contacting a checkuser" section.

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 Wikipedia:Arbitration Committee/Audit/Statistics shows who has been recently active as a CU. Should we replace and/or just add a link to the stats? Thoughts? Beeblebrox (talk) 18:51, 28 September 2023 (UTC)

That makes sense to me. I'd go with prominently adding the stats, on the basis that more choice of information is good. -- zzuuzz ^(talk) 21:23, 28 September 2023 (UTC)

I'd say both. Show the stats while letting them see who is currently active. Better to know that someone who has been using it frequently is around right now than know one or the other. TonyBallioni (talk) 01:47, 29 September 2023 (UTC)