Talk:CheckUser policy

From Meta, a Wikimedia project coordination wiki
(Redirected from Talk:CheckUser)
Jump to: navigation, search
This page is for discussions related to the CheckUser policy page.

  Please remember to:

  Archives: 1 2 3 4 5

Wikimedia Community Logo.svg


New steward practice?[edit]

[1] Sorry, but this just seems silly to apply to all projects. We have hundreds of projects with fewer than five active editors. Those projects shouldn't have to meet some arbitrary requirement for "discussion" of possible socking (most of which is spam production anyway). And let's be honest, stewards are doing those checks and blocking those accounts anyway. The broader community is responsible for coming up with the criteria, and it shouldn't be a discussion on a closed mailing list. The lack of a community discussion in communities with a small number (or no) editors shouldn't be the reason that a steward refuses a request for CU. Risker (talk) 04:31, 4 April 2015 (UTC)

@Risker: There is no change of practice, that edit should not be taken in isolation, the bigger change should be taken in account with Avraham's prior edit, and the better diff would be this. If you can think of improved writing that takes into account the long held wording, go for it.  — billinghurst sDrewth 04:43, 4 April 2015 (UTC)
It is a change in practice, and it is routinely ignored as well, though. Immortalizing a non-existent practice is terrible practice. And again, this is a very negative change for very small communities, which make up the majority of our projects. Risker (talk) 04:50, 4 April 2015 (UTC)
A policy change should come about through consultation, not edit creep. If you would prefer we go back to the pre-Avraham edit and restart the conversation. To note that the stewards conversation was that changes to policy should be made by the community, not by edit creep, hence the readdition.

The reality is that we never to rarely ever get CU requests from the small communities, we get them from the mid to larger without checkuser access. It is not unknown for (disgruntled) users to bring their requests to stewards without involving admins. The larger communities with checkusers have (community discussion) processes for requesting CU, so should we have the same rights for input on these mid to large size wikis? Instead your position could be that we only have discussion held at meta (hidden away) rather than where existing communities can see and have input.

There is no change of practice for stewards, it is about having an enabling policy where stewards can enable community input contrary to a policy that does not.  — billinghurst sDrewth 05:05, 4 April 2015 (UTC)

Well, that was the opinion of you and one other steward, even though James OKed the change. But by all means, edit war over the wording on the page. Regardless of what the policy says, there is no way that any steward in their right mind would request community consensus before performing a check, and no way we would honour a request to CU a user based solely on community consensus. As for the need for community consultation to bring this page up to current practice, I'll start an RfC tomorrow sometime to clarify these parts and also the loginwiki. Hopefully we can establish some sort of consensus instead of staying in limbo on these issues. Ajraddatz (talk) 05:19, 4 April 2015 (UTC)
"There is no change of practice for stewards" that is completely false. Maybe not a change in Billinghurst's practice, but no other steward follows that. --Rschen7754 16:12, 4 April 2015 (UTC)
I don't think such practice can be enforced. In case of uncontroversial checks (such as vandals or spambots) it will just take time to organise a local discussion (and the smaller is the community, the more time it will take to organise a meaningful discussion). In case of controversial checks (involving active users) there will most likely be no proper conensus, as an active user involved will naturally try to block the check. I think that instead of local consensus a better justification, and local discussion may be an option, but diffs by involved users or any other proof should be allowed as an alternative option — NickK (talk) 19:42, 4 April 2015 (UTC)

User:Billinghurst, if you are insisting that this "requirement" to have a local community consensus in order to fulfill a SRCU request is enshrined in the previous version of the policy, can you point to any sentences in the policy that back up your assertion? --Rschen7754 02:25, 5 April 2015 (UTC)

I am insisting on nothing beyond that a change to the policy is made openly by the community rather than by edit creep. If you are asking which bit of the policy disappeared the component is included in
my bolding in statement  — billinghurst sDrewth 03:17, 5 April 2015 (UTC)
Which is a bit different. Your text is "To do so, start by having a local discussion, as a form of community consensus", which is less inclusive than the wording "You also need a community consensus (like above)". (And it's not clear what "like above" refers to; certainly it can't require 25-30 editors supporting). For example, the community could have decided that socking was automatic grounds for CU in a local policy, like Wikidata did a while back. --Rschen7754 03:45, 5 April 2015 (UTC)
Maybe a bit off-topic, but I feel that this whole policy needs a new writting, of course, if there's community consensus for it and its approval. -- M\A 18:26, 5 April 2015 (UTC)
That and the OS policy too; I think there were some points made in the ML archives that might be useful. --Rschen7754 18:34, 5 April 2015 (UTC)
  • I'm still not seeing the basis for saying that a community consensus, or even a community discussion, is required before stewards will consider doing a check. This is a new requirement that was not part of the initial expectations until...well, until a steward added it without discussing with the broad community. While local communities may have such rules (in fact, I believe even some communities with their own checkusers have such rules), they are local rules, not rules governing the entire Wikimedia constellation of projects, and they are unenforceable and undesirable on small wikis. They are probably unenforceable and undesirable on many "medium-sized" wikis (those with 20-200 users). I sense that what has happened is that some stewards are familiar with local rules for some projects they work on and are trying to impose those rules on other projects. Risker (talk) 22:29, 5 April 2015 (UTC)
    Risker. You are missing the aspect that it has always been in the policy since the beginning, and it was removed by copy edit, and it was returned. Now we are back to the original policy. There has been no change in practice and we are still at no change in practice.  — billinghurst sDrewth 22:36, 5 April 2015 (UTC)
    And I think you're missing that it was removed in the first place because it has no place in common practice. Instead of reverting it saying that discussion is needed, why not be positive and start that discussion? Ajraddatz (talk) 23:17, 5 April 2015 (UTC)
    Billinghurst, please provide a recent example of "There has been no change in practice and we are still at no change in practice." - specifically, where another steward besides yourself has declined a SRCU request for there being "no consensus" to run a check. --Rschen7754 00:26, 6 April 2015 (UTC)
    I have always thought that our policies are descriptive, not prescriptive, i.e. they describe common practices, not prescribe them. Ruslik (talk) 16:09, 8 April 2015 (UTC)
    Exactly, Ruslik.
    1. More stewards than not (a consensus, perhaps) already have expressed that "community consensus" is not part of their decision process when they decide to accept or reject a CU request.
    2. Requiring that discussions are held prior to requesting a CU on Meta would impose an extra, and unnecessary, burden on the small and medium wikis who require stewards to perform checks. Unnecessary, as the stewards, in my experience, have shown that they are pretty good at deciding which requests are valid and which are not without the need for extra bureaucracy.
    3. Not that it makes that much of a difference, but WM Legal did approve the change. Moreover, some, if not all, of our larger projects with internal CU processes (for example: EnWiki, Commons, Simple English, if Google Translate worked, then so too DeWiki, ) do not require "consensus" or discussion; merely a request. The CU (or clerk) decides whether or not to follow up on it.
    In summation, this is not "policy creep" but "policy clarification" as it reflects what I believe most of the stewards do (the consensus behavior, dare I say). It, combined with the other changes I made, makes more sense than the words that were there before, it is in line with how CU is used on other large projects, and it is accepted by Legal. To leave confusing verbiage, including words which are not carried out in practice, for the sake of no change without bureaucratic process is counterproductive in my opinion, and the clearer version I posted a few weeks ago should be used without further bureaucratic bloat. -- Avi (talk) 02:54, 14 April 2015 (UTC)
    Whether stewards choose to enforce that provision or not, or to what degree or method they choose to enforce it can vary. But we can't just remove a significant phrase like that from a global policy, even if we don't like it. It is a community policy and the fact that it was apparently discussed on a private mailing list is irrelevant as that cannot be used to gauge consensus, since private mailing lists are not open to all community members. --Rschen7754 04:57, 14 April 2015 (UTC)
    The historical reason (two revisions, @Anthere: and then @Datrio:) given for the addition of the phrase in question was "…probably means that no request may be done by one user only (but must be approved by others) and a motive always given.". It was from a time when Meta (and most projects) were much smaller than they are now. Moreover, it is no longer relevant as it is now handled by having an explicit reason given in the request, and the check run by a second party (the steward). I continue to believe that to enforce it would be counterproductive, bureaucracy for the sake of bureaucracy, and as it is more honored in the breach than the observance, it is time that it is removed so that the policy matches the practice. -- Avi (talk) 06:14, 14 April 2015 (UTC)

It has been about a week with no further responses. At this point,is there any reason not to bring the wording in line with what is the common practice? -- Avi (talk) 21:23, 21 April 2015 (UTC)

  • With no further responses to the statements above, there appears to be no significant opposition to my restoring the wording I added previously, supported by a plurality of respondents, and approved by the WMF. -- Avi (talk) 21:22, 27 April 2015 (UTC)

Checkuser request[edit]

I hereby request to verify that I am not User:The Last Honest Man or User:2600:1017:B40B:560:5923:E719:3E34:A508 because I have been blocked for this false reason. 92.225.94.224 14:54, 2 October 2016 (UTC)

This is not a place to request a check. If you want to ask for a check on English Wikipedia you have to place the request over there. -- Tegel (Talk) 15:01, 2 October 2016 (UTC)
Thanks for your answer, but I am blocked there and even my talk page, so I have no other possibilyties at all than here. https://en.wikipedia.org/w/index.php?title=User_talk:92.225.94.224&action=history It is really very discouraging to be blocked for no reason. 92.225.94.224 15:05, 2 October 2016 (UTC)
I can't go into the reason why you are blocked on another wiki. If the talk page access is removed, have a look here if that can help you in any way. This is the talk page for the CheckUser policy and not a place to discuss individual checks. -- Tegel (Talk) 15:09, 2 October 2016 (UTC)

IP-block[edit]

Some users seems to not be able to think through the consequences of blocking whole ranges, and block telecom providers in their own country. I'm not quite sure how this should be handled, but when someone with access to IP-blocks hear that they can do a IP-block and be rid of a minor problem they think this is safe. Please DO NOT tell them to do so. A range block like /16 can easily escalate to several thousand users if they are NAT'ed. I even have examples on users blocking more than a million addresses and claiming that it is safe because some CU-user said so. Of course you don't. — Jeblad 19:16, 2 October 2016 (UTC)

As someone who's been doing this a lot I can say that my solution was to forward the affected users (via the block reason) to a page like this one, so they at least know what's wrong and what can be done about it. That being said, I mostly block that way networks, which are unlikely to host local users: not national and—at least as much as it can be guessed from whois and other similar info—not end-user networks, but rather collocation, hosting, etc. For the national networks and those that seem end-user related, the blocks are much shorter in duration and relaxed in their restrictions, but there is still an appropriate page with explanation and instructions. While this solution is far from ideal, it seems to work reasonably well for our project, cutting significantly on the open proxy vandalism and harassment with few complaints so far. But it likely wouldn't work that well on more active projects, where also many users are expected to edit from abroad, and it'll certainly not work at all on e.g. the English Wikipedia or Commons.
— Luchesar • T/C 06:28, 7 October 2016 (UTC)

Jakobludwigfelixmendellshon block[edit]

i beleive that check user is complete rubbish.It blocked me for no reason--Jakobludwigfelixmendelsshon (talk) 13:33, 13 January 2017 (UTC)

The CheckUser extension can't block you. There is always some user behind of it, and blocks are not doing without a good reason. --Stryn (talk) 19:33, 13 January 2017 (UTC)

Limited Checkuser for all users?[edit]

I think it would help prevent sockpuppets a lot more if all users had a limited check-user-like ability. Now, clearly not all users should have access to the actual content of the check user information (they shouldn't have access to the underlying technical data including client IP address, HTTP user agent, cookies, etc.). Instead, what if all users had the ability to see if any two accounts had ever shared the same client IP address? All you would get are "plausible" (they shared the same IP at least once), or "impossible" (they never shared the same IP). It wouldn't prove that the two accounts are actually the same person (more detailed look at the technical data by an actual check user would be needed for that along with their behavior), but it would be enough to at least examine it closer. Also it couldn't be used when one of the accounts is an IP account (as that would reveal the underlying technical data about the non-IP user). Can anyone identify any potential privacy problems with this? -Obsidi (talk) 18:31, 5 May 2017 (UTC)