Page MenuHomePhabricator

Checkuser watchlist feature
Open, LowPublic


Author: mapellegrini

It should be possible to program a checkuser watchlist feature. The watchlist consists of IP addresses or ranges of interest. A hypothetical design would be like this:

*        User:ABC
*   IP range for User:XYZ

When a checkuser runs a check, if any of the IP addresses returned match an item or range in his watchlist, the associated information should be displayed next to it. A hypothetical example would be the following results from check User:FooBar (block) (1 Aug 2016, 12:00 -- 2 Aug 2016, 12:00) [57] (~86 of all users) (block) (18 Jul 2016, 12:00 -- 28 Jul 2016, 12:00) [14] (IP range for User:XYZ)

The watchlists can be user-specific (each person with checkuser access has his own watchlist), or global (all the checkusers share the same watchlist), or both.



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:41 PM
bzimport added a project: CheckUser.
bzimport set Reference to bz19796.
bzimport added a subscriber: Unknown Object (MLST).

mike.lifeguard+bugs wrote:

I'd strongly suggest these be shared (cross-wiki if possible, but that may have to be done via mailing list if it can't be implemented in software).

lar wrote:

This would be HIGHLY useful. Interwiki CU coordination now is via our mailing list which works but oculd be better.

I would like to see all 3. A private watchlist just for myself, a watchlist that is shared with every CU on this particular wiki, and a global one across all wikis where Stewards can administer permissions. Let me, as the author of an entry, choose which visibilities are active, requiring at least one to be active at all times, and let entries show who authored them, when, and what wiki they were on at the time. Separate out the watchlist visibility permission from CU itself so it can be assigned to Stewards, allowing them to see per wiki and global watchlists regardless if they turned on the CU permission on a given wiki or not.

Agreed; cross-wiki cu activities can use all the help it can get, and this would be fantastic.

Nishkid64 wrote:

This would greatly improve cross-wiki CheckUser communication. I fully support any efforts toward creating a user-specific and global CU watchlist.

If done, this would likely be global only, but not cross-wiki.

mike.lifeguard+bugs wrote:

(In reply to comment #5)

If done, this would likely be global only, but not cross-wiki.

Sorry, I'm not sure what the difference between "global" and "cross-wiki" is here. Can you clarify?

mapellegrini wrote:

There are three levels of watchlist being proposed/discussed right now:

  • User level - a user's ranges/comments are visible only to that user
  • Global level - a user's ranges/comments are visible to all checkusers on that wiki
  • Cross-wiki level - a user's ranges/comments are visible to all checkusers on all wikis

mapellegrini wrote:

Note - the possibility that this feature could violate the WMF privacy policy was brought up on the checkuser mailing list. Mike Godwin was asked to comment, and he said that such a feature would not violate the policy.

mike.lifeguard+bugs wrote:

(In reply to comment #7)

  • Global level - a user's ranges/comments are visible to all checkusers on that


Using the word "global" to describe this is wrong - it is not global at all (that is why I didn't understand the difference between "global" and "cross-wiki" -- there isn't any such difference). This should more correctly be called "shared" or "shared locally" if there is a need to differentiate between this and cross-wiki sharing.

For steward use, cross-wiki sharing is really critical - without that it will be nearly useless for us.

lar wrote:

Agree with Mike

Suggest instead that the terms be

  • "personal" - User level - a user's ranges/comments are visible only to that user
  • "local" - One wiki level - a user's ranges/comments are visible to all checkusers on that wiki
  • "Global" - Cross-wiki level - a user's ranges/comments are visible to all allowed users on

all wikis

I wonder if getCentralDB() like functions could be used, and WMF sites could borrow the centralauth DB if it is to tedious to make another one.

Nothing in the description sounds like a watchlist to me. Can someone please edit the description to clarify what is being asked for? Is this just asking for a way to tag IP addresses for CheckUser interfaces?

@kaldari I updated the details to clarify.

I think this is NOT something that would be done through CU extension itself. Instead, IMHO, we need to extend CU in such a way that a thing like this can be easily done through a JS tool (much like Twinkle), that updates the CU results page based on some external source.

The problem, of course, is that the watchlist is going to contain private information and needs to be stored somewhere; that means we need a place to store content that only CUs can see (much like an Abusefilter that is not public; but restricted to only CUs).

In theory a tool that hooks into checkuser wiki could be used for this purpose. The way that I see a JS tool working is:

  • A CU can using the tool mark an IP / range as being relevant and of interest with some information such as "this is XYZ". This would, via some method, save this info is some kind of structured way on checkuser wiki.
  • When a CU loads results the checkuser wiki page with the info is loaded and parsed. Any ranges that match results would then be marked as being of interest and with the info stored on checkuser wiki.
  • A CU could through some method remove or amend this information when they see it in the results page if it's no longer relevant or now out of date.

The checkuser wiki is WMF specific, but that would be okay for a WMF specific JavaScript gadget / tool. All CUs can have accounts there and it's the one already existing place where all CUs (assuming the CU is logged in) can access information without non-CUs seeing it.

However, I could see this being an issue to properly maintain. First, ranges that are not often frequented or where the CUs who are checking do not know if the information is still relevant could easily become out of date. Later down the line a CU looking for what sockmaster the account is related to sees this info, and without a clearly visible way to say this is old information, could easily jump to conclusions about the account they were checking. A mitigation to this could be time limiting the info, but this won't always work and relies on good maintenance of this information which may not be easy for wikis with not many CUs. Furthermore, a CU from another wiki would be able to see this info. While not necessarily an issue this would have to be considered and it made clear to CUs that this could be seen by all WMF CUs. Also I'm pretty sure that it isn't going to be easy to access information on the checkuser wiki as I suspect CORS will prevent access.

If CUs on the wiki effectively use reasons for their checks and/or if T190666 is implemented and CUs use that to note the results of checks (i.e. this was XYZ) then checkusers can look at the checkuser log to find what sockmasters have used this range in the past. This has a clear timestamp for the checks and doesn't also have any particular notation that this information is up to date thus reducing the risk of CUs old and outdated info as the basis for a block.