Everything Food & Drink:Checkuser
|This page documents an official Everything Food & Drink project policy, a widely accepted standard that all users should follow. Before editing this page, please make sure that your revision reflects consensus.
If in doubt, consider discussing changes on the talk page.
On Everything Food & Drink, Checkuser is a tool allowed to be used by a small number of users who are permitted to examine userinformation and other server log data under certain circumstances, for the purposes of protecting Everything Food & Drink against actual and potential disruption and abuse. Checkuser itself simply produces log information for checking; it can require considerable skill and experience to investigate cases even with the tool.
Checkuser tools are entrusted to a restricted number of users (listed below), who can both execute Checkuser inquiries subject to their own discretion and monitor and crosscheck each others use of the function.
Users with Checkuser permissions
- Active project CheckUsers
The Checkuser feature accesses non-public information. The Everything Food & Drink takes privacy of its editors extremely seriously, and there may at times be a conflict between the high priorities given to both protecting the Wiki from damage and disruption, and privacy of even problematic users. This is a very delicate area and at times no solution is ideal; the following cover some of the principles and common practices on English Wikipedia. If in doubt please ask an experienced Checkuser.
- Checkusers have a wide range of discretion to use their access provided it is for legitimate purposes – broadly, those which relate to preventing or reducing potential or actual disruption, and to investigation of legitimate concerns of bad faith editing. (Checkuser policy)
- Checkusers may accept requests publicly or otherwise, as they see fit.
- Requests should not be accepted on the basis of "fishing" – that is, requests by users without a good and specific cause. On their own cognisance they may however perform privately as part of their role, any checks within the bounds of Checkuser policy – that is to say, any check which is reasonably performed in order to address issues of disruption or damage to the project.
- "With permission of the affected user",
- "Where the user has been vandalising articles or persistently behaving in a disruptive way, data may be released to assist in the targeting of IP blocks, or to assist in the formulation of a complaint to relevant Internet Service Providers", and
- "Where it is reasonably necessary to protect the rights, property or safety of Everything Food & Drink, its users or the public."
Requirements to use the Checkuser function
- When an IP or IPs have a suggestive editing behavior where use of a proxy or anonimizer is likely being used.
- There is a reasonable suspicion that another user is illegitimately using a second account.
- There is a site wide threat on the grounds that a user or IP is vandalizing or disrupting multiple projects.
- Reverse user check for collateral block because of forum actions.
- Verification of User identity when identifying to Everything Food & Drink. A Checkuser may run all checks.
- New Users with similar user names and close creation time. (only temporary as we are still a small wiki)
- User/IP is committing Personal Attacks or for legal requests.
- Enforcement of a legal request that has already been approved by staff.
Guidance given to Checkusers
- Even if the user is committing abuse, it's best not to reveal personal information if possible.
- Generally, do not reveal IPs. Only give information such as same network/not same network or similar. If detailed information is provided, make sure the person you are giving it to is a trusted person and will not reveal it themselves.
- If the user has said they're from somewhere and the IP confirms it, it's not releasing private information to confirm it if needed.
- If you're in any doubt, give no detail.
If you are requested to perform a check, always ask for the evidence of the user that a check is needed and appropriate, and confirm for yourself that there is indeed a valid basis that you can explain if needed. Do not assume, no matter who asks.
ALL checks MUST be endorsed by someone OTHER than the Checkuser performing the check. Requests ( AT THE CURRENT TIME ) may be filed at Administrators' noticeboard/Incidents
"Fishing" is broadly defined as performing a check on accounts where there is no credible evidence to suspect sockpuppetry or abuse. Checks are inappropriate unless there is evidence suggesting abusive or sock-puppetry. Checking an account where the alleged sockmaster is unknown, but there is reasonable suspicion of sockpuppetry or abuse is not fishing - a suspected sock-puppet's operator is sometimes unknown until checked. Please note that a check coming up negative does not mean that the original basis for the check was invalid.
IP information disclosure
This can happen in several ways:
- A user is disruptive through multiple IPs, or a mixture of IPs and accounts. It is hard to block all of these (often on the same article) without obvious inference being drawn by onlookers.
- A user is disruptive on multiple accounts, and it is reasonably plausible they will create more accounts, requiring the blocking of the underlying IP range that these accounts are using.
Checkusers will often use a variety of techniques to avoid drawing such connections (new checkusers should ask and pick these up), but in many cases it is hard to avoid in a practical sense. Users who engage in problematic conduct to the point that requests for administrative action or blocking are raised and considered valid for Checkuser usage, and where Checkuser then determines that the user probably has engaged in such conduct, must expect that the protection of the project is given a higher priority than the protection of those who knowingly breach its policies on editorial conduct, if the two conflict or there is a problematic editing history.
IP information retention
As configured by Bureaucrat userboxess, Checkuser keeps IP and other information on users for a fixed period, due to privacy concerns related to older log data that is potentially less useful. In general if a matter is not current, it is less likely to require administrative intervention.