User:Jasper Deng/How to use CheckUser

This is a manual for CheckUsers.

Prerequisites for running a check

 * 1) Wiki policies vary but in general you must have a reasonable concern that running a check will help prevent further disruption to your wiki, especially sockpuppetry. If you are unsure, let another CheckUser or steward do the check, or abstain completely from running a check. All checks must adhere to the global CheckUser policy (if there is no local policy with further restrictions) and the foundation's privacy policy.
 * 2) Of course, you must have the CheckUser right on your wiki. Stewards may run checks on wikis without their own CheckUsers. If you are a steward, then to give yourself CheckUser rights on such a wiki, go to m:Special:UserRights, enter [your username]@wikiname, where the wikiname is usually the language followed by the wiki kind. The suffix "wiki" means a Wikipedia, except for 'mediawikiwiki' which means MediaWiki.org and 'commonswiki' which means Wikimedia Commons. The suffix "wikiversity" means Wikiversity. The suffixes "wikisource", "wiktionary", "wikibooks", and the like mean those kinds of wikis. This wiki, for example, is denoted by enwikiversity.
 * 3) Only accounts with activity (any log entries including creation of account (except Special:AbuseLog entries) or edits) in the last 3 months can be checked.

Running a check

 * 1) On a wiki where you have CheckUser access, go to Special:CheckUser.
 * 2) In the user field, type in the username (without the 'user:' prefix), IP address, or CIDR range.
 * 3) * IP: any IPv4 or IPv6 address or range. You can check a range of IP addresses by appending the CIDR prefix (up to /16 for IPv4 (65,536 addresses), up to /64 for IPv6 (~1.8446*1019 addresses) before revision 7352, up to /48 for IPv6 (~1.2089*1024 addresses or 65536 /64s) after revision 7352). For notation, see IPv6 or IPv4.
 * 4) * XFF: you can check a client IP address provided by X-Forwarded-For headers by appending /xff (for example, 127.0.0.1/xff).
 * 5) Select the information you want to retrieve.
 * 6) * Get IPs: returns IP addresses used by a registered user.
 * 7) * Get edits from IP: returns all edits made by a user (registered or anonymous) from an IP address or range. For logged-in accounts, this also displays log entries (blocks, deletions, etc. and Special:EmailUser uses (but not including email addresses or the email contents, and only providing a hash in place of the recipient username)).
 * 8) * Get users: returns user accounts that have edited from an IP or range.
 * 9) In the reason field, type in the reason you are accessing the confidential data. Try to succinctly summarise the situation (for example, "cross-wiki spam"); this will be logged in a log visible only to users with the checkuser-log permission (see below).

Viewing the log

 * 1) Go to Special:CheckUserLog on a wiki where you have CheckUser access.
 * 2) Select whether you want to search by the user who did the check (the initiator) or the user or IP address on which the check was performed.
 * 3) Click Search.

Connecting user accounts

 * 1) Run CheckUser on all accounts which you have good reason (per above) to believe are sockpuppets of each other.
 * 2) If the IP addresses are a near-exact match, it is very likely that the users are the same unless the addresses are open proxies, in which case you should block the proxy IPs.
 * 3) If the IP addresses are not the same, check the WHOIS and geolookup. The users are not likely to be related if using completely different locations and/or ISPs. Ensure that the difference between any IP addresses matches a reasonable size for the degree of dynamism of the IP addresses when calling accounts related based on separate ranges.
 * 4) For any IPv6 address beginning with 2002:: (2002::/16) or 2001:0:: (2001::/32), you must lookup the embedded IPv4 address for reliable geolocation and WHOIS information.
 * 5) If you encounter any tunnelbroker IPv6 addresses, there is little you can do to connect the users unless they are using the same tunnel (especially the same /64 subnet).

Finding other sockpuppets in the same IPv4 address range(s)

 * 1) Determine the size of the range you have reasonable concern about socking based on your previous results. An individual range check may not exceed /16 in IPv4. You may wish to check a larger range for more-dynamic IP addresses, but remember that you should only run a check if you have reasonable concerns about sockpuppetry. Checks should not exceed the range size specified in the WHOIS entry for the IP addresses in question, as different ranges are likely different ISPs. Even if one ISP has several adjacent ranges, the abuse is likely to be confined to ranges containing IP addresses you have found in previous checks, especially if the sockmaster has many already-known sockpuppets, with exceptions for highly-dynamic addresses of wireless networks. As another exception to the previous, you may be a little more liberal with checking webhost ranges if you find the use of proxies.
 * 2) Perform a check on the suspect range as mentioned above.
 * 3) Sift through any accounts found. You may use the mass blocking tool to block accounts you believe are related. If the abuse is sufficiently long-term and you find sufficiently little potential of collateral damage, you may perform a rangeblock of the entire range.

Finding other sockpuppets in the same IPv6 address range(s)

 * 1) Again, determine the appropriate range size to check. IPv6 range checks cannot exceed /48, but it should be a minimum of /64, as each user has at least a /64 to his/her own.
 * 2) Perform the range check.
 * 3) Any accounts found on the same /64, unless it's a webhost range or certain tunnelbrokers that pool all users in a single /64, are almost certainly the same if created not far apart from each other (in timing) or the ISP you're checking gives static ranges (most do).