User:Alexis Jazz/Avoiding collateral damage by checkusers

(English) This is an essay. It expresses the opinions and ideas of some Wikimedians but may not have wide support. This is not policy on Meta, but it may be a policy or guideline on other Wikimedia projects. Feel free to update this page as needed, or use the discussion page to propose major changes.

Checkusers are, surprise, humans. As such, they inevitably make mistakes. If you are using the same wireless access point and a similar device with a vandal that is, for example, your pesky little sibling because your parents gave you matching phones or you share a laptop, you are screwed. Sharing a laptop does not mean an account is compromised: if the both of you have a local user profile, you may never use the account of the other person. But to the checkuser, you are identical. You have the same IP and same browser, so you must be a sock.

On the other hand, when an investigation by checkuser is requested, the checkuser will sometimes confirm a relation but fail to mention that the relation is not based on checkuser data, as happened in the case of Baluperoth. When a user is suspected of sockpuppetry, they face an uphill battle to be exonerated. Though "uphill battle" is a rather rosy way to put this: from the few examples of (suspected) checkuser mistakes I have seen, the victim simply gave up. Unless there is a trusted user who will advocate for you like Jkadavoor did for Baluperoth, you have no chance. And even if there is, your chances seem to be slim. In fact, that trusted user (as in Jkadavoor's case) immediately becomes a target of suspicion. This is extremely toxic.

Wikimedia needs checkusers, checkusers are human and humans make mistakes. The only way to help this situation that inevitably leads to injustice is more transparency.

• When declaring accounts related, the checkuser should always note publicly which of the following categories of sources contributed to establishing that relation:
  • Checkuser data
  • Behavior
  • Public off-wiki information (e.g. social media profiles)
  • Nonpublic off-wiki information (e.g. mail that is believed to originate from the user)

The actual information (which may violate privacy) doesn't have to be noted but can be if it doesn't violate privacy and is deemed useful.

• If the user questions the checkuser analysis, all information that was used to establish the connection should be send to the user by e-mail. The only exception to this should be behavior which only needs to be revealed in broad strokes (e.g. "all involved accounts are interested in subject X"), as to avoid teaching actual vandals how to evade detection. If the user is immediately unblocked upon questioning checkuser analysis, there will be no need to mail the user.

This does require the user to enable e-mail in their account. Global locks for accounts that checkuser deems related but that did not abuse wiki should be postponed in this case. If privacy rules prevent the checkuser from sharing the checkuser data with the user, the user should be unblocked. Privacy can't be violated by sending a user their own data, so if a checkuser feels they may violate privacy by sharing checkuser data, they are clearly uncertain about the relation and good faith has to be assumed.

If the user decides to share the report on-wiki that was mailed to them, checkuser must confirm upon request whether the report as shared is the report that was sent to the user.

Such transparency will help in various situations:

• A connection was established erroneously
• Non-checkuser admins who assume that a connection made by a checkuser was based on checkuser data when it was actually DUCK
• A vandal has impersonated a legitimate user and fooled the checkusers (this is not hypothetical, but I must protect the privacy of the victim who expressed the wish to leave the matter behind)
• The user was hacked and their home network was abused. Even if this may not warrant an immediate unblock, it will allow the user to investigate and resolve the problem. If the user is never told why exactly they were blocked, they won't resolve the issue either.

In case of Baluperoth, a connection was established erroneously and a non-checkuser admin assumed the connection was established based on checkuser data when it was merely DUCK.