Page MenuHomePhabricator

Return local contributions by temporary accounts given an IP address or range
Closed, DuplicatePublic

Description

Background

For full details see T337089: [Epic] Implement global user contributions feature.

User story

As a user patrolling a single wiki, I want to see local contributions from a temporary account, so that I can investigate potential wiki abuse.

Acceptance criteria
  • Submitting the form on Special:GlobalUserContributions with an IP address or range fetches local revisions from temporary accounts using those IP addresses
  • Pending final designs, results are displayed in a paginated list and sorted by descending timestamp
  • Deleted revisions are only displayed to users who have the rights to see them
  • Revisions by hidden temporary accounts are only available to users who have the rights to see them

Event Timeline

Change 1005158 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/extensions/CheckUser@master] WIP Display local results on Special:IPContributions

https://gerrit.wikimedia.org/r/1005158

@KColeman-WMF and I discussed an alternative approach to seeing local contributions from temp accounts from the same IP using Special:Contributions. Here are some of my thoughts based on what we discussed.

When a user enters an IP address is Special:Contributions, they would see:

  1. If they have the IP reveal permission:
    1. If there are only historical contributions from an IP actor, just those contributions
    2. If there are IP actor contributions and temp account contributions, all of those contributions
  2. If they don't have the IP reveal permission:
    1. Only historical contributions from an IP actor, if there are any

1B would be tricky to implement because we'd be fetching data from the core tables and the CheckUser tables, which makes paging tricky. This would be particularly bad if we had to disable then re-enable temp accounts for some reason (see T356524) - in which case we would have to interleave these results if sorting by timestamp.

We could instead add a toggle to Special:Contributions, which could either be in "IP actor mode" or "temp account mode". The toggle would be visible by to users with the IP reveal right and be set to "temp account mode" by default (if temp accounts are enabled, otherwise the mode wouldn't exist).

I think the advantage of the approach outlined in this task description is that it avoids complicating Special:Contributions (from and UX and technical perspective).

Having a local mode for the new GUC tool is much cleaner technically; however there may be a strong UX reason to do this in Special:Contributions instead.

@KColeman-WMF and I discussed an alternative approach to seeing local contributions from temp accounts from the same IP using Special:Contributions. Here are some of my thoughts based on what we discussed.

When a user enters an IP address is Special:Contributions, they would see:

  1. If they have the IP reveal permission:
    1. If there are only historical contributions from an IP actor, just those contributions
    2. If there are IP actor contributions and temp account contributions, all of those contributions
  2. If they don't have the IP reveal permission:
    1. Only historical contributions from an IP actor, if there are any

1B would be tricky to implement because we'd be fetching data from the core tables and the CheckUser tables, which makes paging tricky. This would be particularly bad if we had to disable then re-enable temp accounts for some reason (see T356524) - in which case we would have to interleave these results if sorting by timestamp.

We could instead add a toggle to Special:Contributions, which could either be in "IP actor mode" or "temp account mode". The toggle would be visible by to users with the IP reveal right and be set to "temp account mode" by default (if temp accounts are enabled, otherwise the mode wouldn't exist).

I think the advantage of the approach outlined in this task description is that it avoids complicating Special:Contributions (from and UX and technical perspective).

Having a local mode for the new GUC tool is much cleaner technically; however there may be a strong UX reason to do this in Special:Contributions instead.

Thanks for explaining this @Tchanders! I am going to explore how this alternative approach could work from a UX perspective and will update this task accordingly.

My initial thoughts are that it might be confusing for a user to see scenario 1 in special:contributions. But equally, I am not sure it makes sense to show only local wiki contributions in a tool that is designed with global contributions in mind (and named as such). I will share UX explorations here!

@Tchanders It would be useful to have a user story for this task. This is my working assumption:

User story:
As a user patrolling a single wiki, I want to see local contributions from a temporary account, so that I can investigate potential wiki abuse.

@Tchanders It would be useful to have a user story for this task. This is my working assumption:

User story:
As a user patrolling a single wiki, I want to see local contributions from a temporary account, so that I can investigate potential wiki abuse.

This aligns with what I was thinking - have added it to the task description. We can keep discussing and edit it if necessary.

Hi @Tchanders,

Having looked into this further, I agree it makes sense to proceed as outlined in the task description. The UX is somewhat confusing if we combine historical IP edits with temp account edits on Special:Contributions, see mockups:

1. Special:Contributions searching local wiki for IP edits:

special-contribs-ip.png (627×1 px, 145 KB)

2. Special:Contributions searching local wiki for IP range edits:

special-contribs-ip-range.png (627×1 px, 158 KB)

I do wonder what the entry points will be for users performing local IP contribs searches (how will they know to search in GUC)? Do we need to let users who have IP reveal permission know that they can search locally on GUC (i.e. link to new GUC from Special:Contributions page)?

EDITED: I wanted to add that as much as this is confusing UX, having a local setting as default in a global tool (GUC) is also slightly odd. Interested to hear further thoughts from others?

A major use case for the local project is:

  • There is some disruption from some network
  • A range-block may stop the disruption
  • Check for collateral damage (i.e. non-disruptive contributions from the network) first
  • Decide if the range-block is the best option

Thanks for clarifying the use case @Xaosflux.

For completeness I am adding a mock-up showing how GUC would look if we added a 'global search' checkbox (in this example it's unchecked so that the user can search a local project only).

1. GUC searching local wiki as default:

guc-search-query-v2.png (801×1 px, 33 KB)

2. GUC returning local wiki results:

guc-search-results-IP-v2.png (1×1 px, 186 KB)

It does seem odd from a UX perspective to set local search as the default on a global tool - we could possibly rename GUC as something more appropriate if it's performing both a local wiki and global wiki IP search.

@Tchanders Do you have further thoughts on the approach we should take?

I am favouring keeping the workflow similar to the way it is currently (i.e. Special:Contributions performs local search, GUC performs global search). This is to avoid changing the expected UX of where people currently perform local vs global user contribution searches. It also makes contextual sense given the naming of the two pages.

Reedy renamed this task from Return local contributions by temporary accounts given an IP address or range to Return local contributions by temporary accounts given an IP address or range.Mar 18 2024, 6:15 PM

@KColeman-WMF I discussed this with @Urbanecm_WMF today and it needs some discussion with the community.


I think two things will help avoid disruption, whichever approach we choose:

  • Adding a link to it from the revealed IPs wherever they are displayed:

image.png (211×418 px, 48 KB)

  • Having visual consistency between the results and the existing Special:Contributions results

Conceptual questions that arose:

  • Is the project we're calling "GUC" a commitment to build a replacement for the entire GUC tool inside MediaWiki, or is it just meant to fill in the gap that is left by no longer being able to see all contributions from an IP/range?
  • If the first one - in which case global temp account/IP contributions are in the GUC replacement, and local temp account/IP contributions are in Special:Contributions - how do we communicate that the results for temp accounts/IP contributions are only from the last three months, whereas results from IP editors and from single temp account editors are results from all time?

Thanks for the update @Tchanders

Conceptual questions that arose:

  • Is the project we're calling "GUC" a commitment to build a replacement for the entire GUC tool inside MediaWiki, or is it just meant to fill in the gap that is left by no longer being able to see all contributions from an IP/range?
  • If the first one - in which case global temp account/IP contributions are in the GUC replacement, and local temp account/IP contributions are in Special:Contributions - how do we communicate that the results for temp accounts/IP contributions are only from the last three months, whereas results from IP editors and from single temp account editors are results from all time?

With regards the conceptual questions:

  • According to the project plan, the goal is to "build a global user contributions feature in a special page", and it's my understanding that we are aiming for feature parity with the current GUC tool(s).
  • As we discussed on our call today, we will need to consider how and where to communicate the gaps in data once a 3 month period passes (i.e. users will see temp accounts with IPs, alongside older temp account edits with no IPs). I'd also like to understand what the use cases are for users needing to see IPs that are no longer 'recent' (within 90 days of searching)?

@KColeman-WMF Here are some scenarios, as discussed. The lists show the data visible on the Special:Contributions pages - not exactly how it will look.

What edits happen, when and by whom:
DateAuthor's usernameAuthor's IP
30 Dec 20241.2.3.41.2.3.4
31 Dec 20241.2.3.41.2.3.4
1 Jan 2025~TempUser11.2.3.4
2 Jan 2025~TempUser11.2.3.0
3 Jan 2025~TempUser21.2.3.4
1 Feb 2025~TempUser21.2.3.4
2 Feb 2025~TempUser21.2.3.0
What steward sees if we show temp user contributions in Special:Contributions/IP

Special:Contributions/1.2.3.4

Depending on timing, the IP appears to have more edits, that later disappear as the connection between the temp account and the IP is lost.

Views the page on 10 Feb 2025:

  • 30 Dec - 1.2.3.4 edited
  • 31 Dec - 1.2.3.4 edited
  • 1 Jan - ~TempUser1 (1.2.3.4) edited
  • 3 Jan - ~TempUser2 (1.2.3.4) edited
  • 1 Feb - ~TempUser2 (1.2.3.4) edited

Views the page on 20 Apr 2025:

  • 30 Dec - 1.2.3.4 edited
  • 31 Dec - 1.2.3.4 edited
  • 1 Feb - ~TempUser2 (1.2.3.4) edited

(Edits from January are no longer known to be from IP 1.2.3.4)

Views the page on 30 July 2025:

  • 30 Dec - 1.2.3.4 edited
  • 31 Dec - 1.2.3.4 edited

(Temp account edits are no longer associated with this IP)

Special:Contributions/1.2.3.4/24

Depending on timing, the IP appears to have more edits, that later disappear as the connection between the temp account and the IP is lost.

Views the page on 10 Feb 2025:

  • 30 Dec - 1.2.3.4 edited
  • 31 Dec - 1.2.3.4 edited
  • 1 Jan - ~TempUser1 (1.2.3.4) edited
  • 2 Jan - ~TempUser1 (1.2.3.0) edited
  • 3 Jan - ~TempUser2 (1.2.3.4) edited
  • 1 Feb - ~TempUser2 (1.2.3.4) edited
  • 2 Feb - ~TempUser2 (1.2.3.0) edited

Views the page on 20 Apr 2025:

  • 30 Dec - 1.2.3.4 edited
  • 31 Dec - 1.2.3.4 edited
  • 1 Feb - ~TempUser2 (1.2.3.4) edited
  • 2 Feb - ~TempUser2 (1.2.3.0) edited

Views the page on 30 July 2025:

  • 30 Dec - 1.2.3.4 edited
  • 31 Dec - 1.2.3.4 edited

Special:Contributions/~TempUser1

For comparison, on Special:Contributions/<tempusername>, the IP data is lost, but we still know about the edit.

Views the page on 10 Feb 2025:

  • 1 Jan - ~TempUser1 (1.2.3.4) edited
  • 2 Jan - ~TempUser1 (1.2.3.0) edited

Views the page on 20 Apr or 30 July 2025:

  • 1 Jan - ~TempUser1 edited
  • 2 Jan - ~TempUser1 edited

Special:Contributions/~TempUser2

Views the page on 10 Feb 2025:

  • 3 Jan - ~TempUser2 (1.2.3.4) edited
  • 1 Feb - ~TempUser2 (1.2.3.4) edited
  • 2 Feb - ~TempUser2 (1.2.3.0) edited

Views the page on 20 Apr 2025:

  • 3 Jan - ~TempUser2 edited
  • 1 Feb - ~TempUser2 (1.2.3.4) edited
  • 2 Feb - ~TempUser2 (1.2.3.0) edited

Views the page on 30 July 2025:

  • 3 Jan - ~TempUser2 edited
  • 1 Feb - ~TempUser2 edited
  • 2 Feb - ~TempUser2 edited
Tchanders added a subscriber: Urbanecm.

Merging this in as a duplicate of T358852, since we've decided to take the approach of showing local contributions for temp accounts on a given IP/range in Special:Contributions, having discussed the above with @KColeman-WMF and @Urbanecm .

Change #1005158 abandoned by Tchanders:

[mediawiki/extensions/CheckUser@master] WIP Display local results on Special:IPContributions

Reason:

We'll show this info in Special:Contributions instead: T358852

https://gerrit.wikimedia.org/r/1005158

Change #1005158 restored by Tchanders:

[mediawiki/extensions/CheckUser@master] WIP Display local results on Special:IPContributions

https://gerrit.wikimedia.org/r/1005158