User:Blablubbs/8ball

From Wikipedia, the free encyclopedia

This page is inspired by User:ST47/8ball, which I always found very helpful as a reference point when I was a clerk. After becoming a CU, I quickly realised that translating (often quite complex) technical relationships into templates is a somewhat daunting task, and – as ST47 points out – simple technical heuristics aren't necessarily sufficient to accurately "translate" the results. In more complicated cases, I've come to conceptualise the "categories" of technical relationships as a range of (counter-)probabilities. Essentially, I ask myself:

1. Are there scenarios that would produce the observed outcomes if these accounts are not operated by the same person?
2. How likely are these scenarios?


I then assign response templates based on the answer to these questions.

Template Answer Notes What to do with it?
 Confirmed There are no reasonably plausible alternative scenarios.
  • The obvious caveat for all of these, and especially for "confirmed" results, is "... that I can come up with".
  • False positives can and do happen. Use your judgement and don't hesitate to follow up if you think I may have gotten it wrong.
  • If I use this, I have probably blocked the accounts in question. If I have not blocked, I have probably explained why. If I have done neither of those things, you may get mildly annoyed at me (optional), assume that the accounts in question are all the same person, and then proceed to evaluate what sanctions, if any, are appropriate.
  • As always, you should still consider the possibility of a false positive, but as this is the strongest possible technical result, behavioural evidence need not be as strong as it might otherwise have to be in order to justify a block.
  • Use the |confirmed parameter for tagging.
 Technically
indistingusihable
The accounts have identical or near-identical technical characteristics, but it is plausible that they are operated by distinct individuals.
  • The line between this and "confirmed" is not always very clear, and comes down to judgement.
  • I may use this, for example, if I think that there is a decent chance that two individuals are operating their accounts from the same public computer.
  • It is not uncommon for accounts participating in class projects to show up as "technically indistinguishable".
  • Use behaviour to evaluate whether you believe the accounts to be operated by the same person.
    • If yes, sanction as appropriate and use the |confirmed parameter for tagging.
    • If no, consider whether there might be illegitimate coordination (WP:MEAT). If you determine that this has occured and block, use |proven or blocked for tagging.
 Likely There are some alternative scenarios, but I believe them to be significantly less probable than one person operating multiple accounts.
  • There is a myriad of technical constellations that can produce this.
  • This is a fairly strong, but not a conclusive, result.
  • If I use this, I have probably blocked the accounts in question; if not, see if you find the behavioural evidence reasonably consistent with abuse of multiple accounts, and sanction as appropriate.
  • Use |proven for tagging.
 Possilikely (a mix between possible and likely) There are alternative scenarios, and I believe them to be somewhat less probable than one person operating multiple accounts.
  • I always had an irrational dislike for this result as a clerk, so I try not to use it. I usually try to go with either "possible" or "likely" instead, sometimes with modifiers ("very possible", "weak likely", etc.)
  • This is a positive result, but only barely.
  • Carefully evaluate behaviour and take appropriate action.
  • Absent very strong behavioural evidence, blocked is probably the most appropriate tagging choice.
 Possible There are alternative scenarios, and I believe them to be equally probable as one person operating multiple accounts.
  • While it may be tempting to read this as a "negative" CU result, I consider it very much neutral: Consider that if you were to draw random pairs of accounts, their technical data is far more likely to show up as "unlikely" or "unrelated" than as "possible".
  • In practical terms, the significance of "possible" varies. When comparing based on a multitude of datapoints for all accounts in question, it implies that there is a nontrivial degree of technical separation between the accounts, but one that could be plausibly achieved by a single individual. When comparing accounts with datapoints that are few or far apart, it may well just be the result of insufficient data to make a stronger determination.
  • Evaluate the case strictly based on behaviour, and sanction appropriately iff there is clear evidence of abuse.
  • Absent very strong behavioural evidence, blocked is probably the most appropriate tagging choice.
 Unlikely There are alternative scenarios, and I believe them to be more probable than one person operating multiple accounts.
  • This indicates a relatively high degree of confidence that we are indeed looking at separate individuals.
  • However, the result doesn't indicate it is impossible – merely improbable – that a single person is operating multiple accounts.
  • Evaluate behaviour, and keep in mind that this does not preclude illegitimate coordination.
  • If you do decide to block, you will probably want to explicitly justify why you're doing so despite the CU result.
  • blocked is almost certainly the appropriate tagging choice.
Red X Unrelated There are alternative scenarios, and they are far more probable than one person operating multiple accounts, to the point where I believe that the only reasonable explanation for the technical outcome is that the accounts are indeed being used by separate people.
  • Failure to detect CU evasion (and occasionally random coincidence) can result in false negatives
  • I don't use this if I think there is a significant possibility that someone is deliberately trying to evade and may explicitly note this, but please do ask for clarification if you have reason to believe that I may have failed to detect evasion.
  • Evaluate behaviour, and keep in mind that this does not preclude illegitimate coordination.
  • You will need strong behavioural evidence to overcome this result.
  • When a whole bunch of ostensibly unrelated accounts are doing very similar things (especially if they're all getting angry over the same matter), you may wish to look up some related keywords on Twitter or other venues that have a tendency to organise outrage.
  • blocked is almost certainly the appropriate tagging choice.
 Inconclusive The available data does not allow me to draw any meaningful conclusions about the relationship between the accounts.
  • This usually happens because one or more of the accounts under investigation are using proxies.
  • I will frequently make more specific statements even when proxy use is apparent.
  • Proxy use does not necessarily indicate deliberate CU evasion, but can be a valuable datapoint in and of itself.
  • Evaluate the case based on behaviour.
  • Absent very strong behavioural evidence, blocked is probably the most appropriate tagging choice.
 Stale

There is no data available for me to evaluate.

  • Data retention guidelines mean that CU data expires after some time.
  • Evaluate the case based on behaviour.
  • If accounts have been inactive for extended periods of time, they may not be worth investigating. Consider moving on and revisiting the case if they wake up again.
  • Absent very strong behavioural evidence, blocked is probably the most appropriate tagging choice.