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

wiki

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.