Unmasking Policy Draft

NOTICE:

This is a sandbox page.

It is not approved or active policy. It is a draft, and as such, may be incomplete.

This policy is based on English Wikipedia's CheckUser policy, which is described below.

In the course of managing sockpuppetry cases, certain classes of permanent ban, and Persistently-Abusive Individuals, site staff have needed to access IP addresses of users as part of investigations and to implement IP bans. For any large site, the ability to both see and IP addresses and ranges is quite ordinary. However, while Wikidot offers the ability to ban IPs, it offers no way to see such visitor information.

Of course, this information should not be exposed publicly, nor used inappropriately, as this is private information. But it is still necessary for site staff to make limited use of this information for legitimate disciplinary and anti-harassment purposes. As such, we can look at how a larger, reputable site such as English Wikipedia treats this information.

Wikipedia CheckUser Policy

Within MediaWiki (its host wiki software), a select group of trusted users have the capability to retrieve the IP address(es) associated with a user account, or to see other technical information associated with an account or IP address.

Wikipedia's policy says that:

CheckUser data may be used to investigate, prevent, or respond to:

1. Vandalism;
2. Sockpuppetry;
3. Disruption (or potential disruption) of any Wikimedia project; and
4. Legitimate concerns about bad-faith editing.

The tool may never be used to:

1. Exert political or social control;
2. Apply pressure on an editor; or
3. Threaten another editor into compliance in a content dispute.

Regarding Wikipedia's policy regarding logging, they say the following:

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).

Additionally, there is an automatic log of all checks done using the tool. Such a tool would not be produced automatically for us, so we must be rigorous in logging it properly.

All trusted users with this capability have signed a Wikimedia Foundation confidentiality agreement regarding nonpublic information. When such a lookup is performed as part of a legitimate investigation, such as a sockpuppet case, they may only reveal the relevant details of the information, leaning towards less information than more, especially when revealed publicly.

To quote from their policy again:

Checkusers may state that different named accounts are operated from the same IP or range, so long as the actual IP address(es) are not specified, or if only non-specific details are given (such as the name of the country, region, or large ISP associated with the IP address). If the checkuser's statement could not lead to another person divining the personal identity of the user accounts in question, such disclosure would be permissible. However, on the English Wikipedia, checkusers are discouraged from making a public statement that connects one or more IP addresses to one or more named accounts, since an IP address is often much more tightly linked to a specific person. (In the case of larger IP ranges, this discouragement is not as great because larger ranges mean a less specific connection can be drawn.) When announcing the results of their checks, checkusers will employ a variety of means to avoid connecting a user to an IP address, but in some cases it is hard to avoid doing so. This policy encourages English Wikipedia checkusers not to allow such connections to be made from their results, but the global privacy policy allows them to do so in the case of serious disruption, and this policy allows checkusers to prioritise compliance with Wikipedia policy over the personal privacy of a user who has abusively edited the encyclopedia.

We can describe this policy as such:

Revealing Information

Inn comparing banned user account "Alice" with potentially-innocent user account "Bob", it would be inappropriate to say:

Alice is connecting from 1.2.3.4 and 1.2.3.5, Bob is connecting from 127.127.127.0.

Because Bob may be an unrelated bystander here, exposing his IP information publicly without his consent is not acceptable. Likewise Alice, despite being banned, is entitled to basic levels of privacy.

Instead, an unmasking report should say something like:

Alice and Bob do not have any IP addresses in common.

or

Alice and Bob are likely not the same user.

This reveals nothing about their specifics, and gets to the core of the issue. Of course, it's possible that they are sockpuppets, the nature of IP checks is that they can only really give you answers of "yes" and "unsure".

What if Alice made the Bob sockpuppet but was very careful to only visit that account from a public library computer? Or we see that two users connected from the same address, but it was a large cellular / mobile network, meaning they could just, by happenstance, be living nearby each other with no actual malicious involvement?

Sometimes additional information may be provided, in cases where it may be pertinent. Such information should tend towards being nonspecific, especially when posted publicly:

Alice and Bob do not share any IP addresses in common, but their main addresses are in nearby cities.

or

Alice primarily connects to the wiki from an address in New York City.

Since both of these descriptions are vague, it would be difficult for someone with this information alone to determine where these users live.

However, vagueness is contextual. If Bob is public about / well-known for living in Yamanashi City, Japan, saying that Alice "lives nearby" is providing too much public information on the user, given the city's small population (~30k at time of writing). In such a case, it would be better to keep such information limited to disciplinary staff only, and say only that Alice "is nearby another known user" on public logs, if that.

Policy Proposal

Given the above, the proposed policy for unmasking users on the SCP Wiki, which, if approved, is to be created at unmasking-policy.

Unmasking Policy

In the course of managing sockpuppetry cases, certain classes of permanent ban, Anti-Harassment cases, and Persistently-Abusive Individuals, site staff have needed to access IP addresses of users as part of investigative work and to implement IP bans. Wikidot has the capability to ban both individual IP addresses and address ranges, but unlike typical websites, site staff actually have no capability to retrieve visitor information (including IP addresses) from the platform.

This policy empowers staff to run the "unmasking utility", a tool which reveals the IP address(es) of specific users. Use of this tool is strictly limited:

• Unmasking should only be done for one of the following reasons:
  • Fighting vandalism or spam.
  • Fighting sockpuppetry or in the course of effectuating site discipline (e.g. bans).
  • As a response to significant threats against the site or users.
• Unmasking may never be done to exert political or social pressure, or to threaten, harm, doxx, or out people, users or staff (including banned users).
• Unmasking is generally performed in conjunction with Disciplinary or Anti-Harassment actions, but it is not a punishment. Unmasking should only be done as a means to an existing, legitimate end, such as investigating a case or enforcing a punishment.
• Unmasking requires permission to be used. Approved staff members may not unmask a user and then request approval.
  • However, some situations permit such emergency use, meaning it may be used immediately, with staff review and approval coming later. Such situations are:
    • Situations involving gross vandalism, harassment, malicious content, immediate risk of harm, or other severe rules violations where staff believes time is of the essence.
    • Cases for already-permabanned or harassment-banned users, or users previously approved for unmasking, who are known to engage in chronic ban evasion, harassment, sockpuppeting, or other abusive behaviors.
    • Other reasons covered by internal Anti-Harassment Team policy.
  • In emergency situations not covered by the above, the action must be done as administrative fiat.
• Staff are encouraged to express any concerns they may have over a use of unmasking in chat, and ensure there is substantial reason for any use of it.

Unmasking may only be done by a member of the Disciplinary Team, an Administrator, or any specially designated individual decided by a consensus of staff members on O5. The current list of specially-designated users is:

• [maintained bullet list of users here]

Only the above users may perform an unmasking. Any users outside of this list performing this action on an emergency basis should be combined with an invocation of administrative fiat authorizing them to do it.

In order to be effective, the details of how the "unmasking utility" works are sensitive and to be only known by the Disciplinary Team, Anti-Harassment Team, and Technical Team, or others who have demonstrated a need to know and been approved for it.

Only approved mechanisms and reasons for unmasking may be used, even if by an otherwise authorized user. Ad hoc or unapproved unmasking of users, whether by site users or staff, is considered a serious disciplinary offense. For instance, a user posting third-party links on the site which have the purpose of harvesting user data, or a staff member using the unmasking utility without informing other staff or for personal reasons are committing offenses.

Performance of this action may only occur after one of the following is met:

• A consensus of staff at large (for cases of significant importance) on O5 or in staff chat.
• A consensus of the Disciplinary Team on O5 or in staff chat.
• A consensus of the Anti-Harassment Team (for harassment cases only).

The approval must specify the specific users to be checked and the reason they are being checked. The executing users should then report a minimal but necessary portion of the information.

They must avoid sharing specific details with any users not needed; for instance to institute an IP ban the checking user may only need to contact one administrator to input that information into the admin panel. Or, if comparing two users to determine if they are sockpuppets, they should give a response indicating their relation, rather than unnecessary private details.

+ Examples of appropriate/inappropriate unmasking

Appropriate Details

Alice and Bob do not share any IP addresses in common.

Alice and Bob are likely not the same user.

Alice and Bob are sockpuppets, both have connected from the same IP address.

Alice and Bob live in the same geographic area and log in at similar times, but do not have any overlap in IP addresses.

Alice only connects to the site on a mobile network.

Alice is connecting from 1.2.3.4 and 1.2.3.5. [Only when being communicated via direct message to a specific admin inputting an IP ban.]

Alice mostly connects from the San Francisco metro area. [Such location information should be non-public if possible.]

Alice only connects from a specific university. [Specifics should not be shared if possible.]

Inappropriate Details

Alice is connecting from 1.2.3.4 and 1.2.3.5. [When being communicated to staff or a specific team, like Disciplinary.]

Alice and Bob are both connecting from 1.2.3.4. [When being communicated to staff or a team.

Alice connects from Sarasota, Florida. She has no overlap with legitimate user Bob, who lives in London. [Bob is not suspected beyond this check, so sharing any information about him is inappropriate.]

Alice connects from ACME Corp. headquarters in Toronto, Canada. [Far too much unnecessary detail.]

All uses of unmasking must be logged on Unmasking Records page.

In short, all unmasking of users must meet the following criteria:

• It must be performed for a legitimate purpose, as illustrated above.
• It must be approved by staff at the time, and carried out within a reasonable timeframe. Approval by staff is one-time and contemporaneous, old unmasking requests are invalid in the present, new approval must be received.
• It must be using approved methods by staff.
• It must be carried out by an approved staff member.
• The unmasking must be logged on the Unmasking Records page.
• The unmasking must also be logged on O5, unless this is a PAI case or staff decides that such logging would not be in the interests of site security. Logging on O5 does not need to include any details about the results of the check.
• The results of the unmasking must only be transmitted in the most minimal fashion possible, to protect user privacy.
• If any variations from established protocol occur, even by accident, it must be promptly reported to staff. Except for PAI cases, such variations should also be logged on O5.

Note that the SkipIRC network is run independently from the site, so the SkipIRC Privacy Policy is separate from this document.

[timer]