Page MenuHomePhabricator

IP Masking: Update Recent changes filters user registration filters for IP Masking
Closed, ResolvedPublic4 Estimated Story Points

Description

Recent changes/Watchlist make it possible for users to filter edits by user registration status, see screenshot:

image.png (680×1 px, 110 KB)

The "Unregistered" filter currently only treats IP users as unregistered. We want "Unregistered" to also include edits made by temporary accounts.

Acceptance Criteria:

Given I'm on a wiki where IP Masking is not enabled,
When I view Recent Changes or Watchlist filters,
Then the Unregistered filter includes edits made by IP editors,
and the filter description is: Editors who aren't logged-in.
(nothing changes)


Given I'm on a wiki where IP Masking is enabled,
When I view Recent Changes or Watchlist filters,
Then the Unregistered filter includes edits made by IP editors and Temporary accounts
and the filter description is: Editors who aren't logged-in and editors who are using temporary accounts.
(logic change and description change)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@KStoller-WMF I filled as a separate task to track the product decision about the filters. In particular, I'm not sure if we want any copy changes of the messages used in the filters if temp users are active (particularly along "logged-in"). If we want to change that copy, it'd be great to come with one that works well even if temp accounts are not enabled, but if that's not possible, we can use a dynamic copy too.

KStoller-WMF added subscribers: RHo, Trizek-WMF, Niharika.

Hmmmm, I guess I'm not sure if communities would actually want to lump Temporary accounts into Unregistered, or have the ability to filter those separately? @Trizek-WMF - any thoughts on this?

Do we want to consider adding a new filter? Something like: Temporary with the explanation:Editors logged into temporary accounts.

But perhaps we need to wait for this decision here: T337103: Decide a standard approach for classifying temporary, IP and registered users before deciding?

@Niharika / @RHo - Let me know if you have thoughts, or if a decision has been made on how temporary accounts are classified. Thanks!

Hmmmm, I guess I'm not sure if communities would actually want to lump Temporary accounts into Unregistered, or have the ability to filter those separately? @Trizek-WMF - any thoughts on this?

I'm not Trizek, but my understanding is that once IP Masking gets enabled on a wiki, it is no longer possible to save unregistered edits. If that's true, I think the Unregistered filter (as defined today) would be empty. Or am I missing something here?

Do we want to consider adding a new filter? Something like: Temporary with the explanation:Editors logged into temporary accounts.

I think it would make sense to change the wording (perhaps to what you propose) if IP Masking is enabled. What do you think?

But perhaps we need to wait for this decision here: T337103: Decide a standard approach for classifying temporary, IP and registered users before deciding?

@Niharika / @RHo - Let me know if you have thoughts, or if a decision has been made on how temporary accounts are classified. Thanks!

I think this is task is similar to, but different from, T337103. In the case of Recent changes or Watchlist, only recent edits are shown (up to 30 days old edits). This means that once IP Masking is enabled for more than a month, old-IP edits won't appear in those views. This is different to Special:Log or page history, as those views include historical data, that might be even decades old. In other words: We might want to take a different product decision here and in T337103, because in this case, we don't need to take old edits into consideration.

once IP Masking gets enabled on a wiki, it is no longer possible to save unregistered edits. If that's true, I think the Unregistered filter (as defined today) would be empty.

That's my understanding as well. I was thinking that patrollers might appreciate the ability to filter those edits independently during the 30 days after initial release, but perhaps that's not really worth the extra effort.

What do you think of this approach:

Update the "Unregistered" filter copy (and logic) to:
Unregistered & Temporary
Editors who aren't logged in & editors using temporary accounts.

And then eventually after IP Masking has scaled to all wikis we will want to update the copy to:
Temporary
Editors using temporary accounts.

In other words: We might want to take a different product decision here and in T337103, because in this case, we don't need to take old edits into consideration.

That makes sense, but it seems like we should try to be as consistent with language as possible. If it's decided that we are considering temporary accounts as "Unregistered" then my suggestion above seems odd.

That approach sounds good to me, thanks @KStoller-WMF! Do we need to wait for T337103 before working on this one?

I'm pretty sure that communities will refer to "IPs" for a while. I think it is quite clear that temps accounts are perceived as the replacement of IPs.

Hence, I think it is safe to switch directly to the new terms, instead of having a step in between. It will avoid translation work, and we won't forget to update the patch either. :)

I think there will be a case for a while where there may be a mix of IP and temp accounts existing, esp as the MVP will not happen for all wikis at once, but the temp account is afaik a global creation. So for example, there could be a scenario where someone on say fawiki makes an edit without an account that creates a temp account, then goes to enwiki whilst in that temp account and makes another edit. In that case, what Recent Changes filter on enwiki would capture this person's edit?

I think there will be a case for a while where there may be a mix of IP and temp accounts existing, esp as the MVP will not happen for all wikis at once, but the temp account is afaik a global creation. So for example, there could be a scenario where someone on say fawiki makes an edit without an account that creates a temp account, then goes to enwiki whilst in that temp account and makes another edit. In that case, what Recent Changes filter on enwiki would capture this person's edit?

@RHo the idea is that we will try to isolate IP Masking enabled wikis from those where it is not enabled. So if wiki A has IP Masking enabled but wiki B doesn't, then a temporary account created on wiki A will show up like any other IP address on wiki B. We don't want wiki B users to encounter temporary accounts because they will not necessarily have the tools to handle them. But if the same temp user goes to wiki C which has IP Masking enabled, then it will persist as the same temporary account on wiki C.

once IP Masking gets enabled on a wiki, it is no longer possible to save unregistered edits. If that's true, I think the Unregistered filter (as defined today) would be empty.

That's my understanding as well. I was thinking that patrollers might appreciate the ability to filter those edits independently during the 30 days after initial release, but perhaps that's not really worth the extra effort.

What do you think of this approach:

Update the "Unregistered" filter copy (and logic) to:
Unregistered & Temporary
Editors who aren't logged in & editors using temporary accounts.

And then eventually after IP Masking has scaled to all wikis we will want to update the copy to:
Temporary
Editors using temporary accounts.

Would it possibly be confusing to see this copy on wikis where IP Masking hasn't been enabled yet? How about keeping the current wording of "Unregistered" and update the logic to include temporary accounts where IP Masking is enabled (what @Urbanecm_WMF suggested in the task description)? Based on user feedback you could eventually change this. Technically speaking temporary accounts are not really "registered" accounts and one could argue they can be labelled as "Unregistered".

In other words: We might want to take a different product decision here and in T337103, because in this case, we don't need to take old edits into consideration.

That makes sense, but it seems like we should try to be as consistent with language as possible. If it's decided that we are considering temporary accounts as "Unregistered" then my suggestion above seems odd.

I agree that being consistent is good but I will point out that T337103 is mostly thinking about this on the technical front and that decision may not reflect what is intuitive for the end users.
@kostajh would you recommend the team wait on the outcome on T337103 before deciding on the terminology here?

In other words: We might want to take a different product decision here and in T337103, because in this case, we don't need to take old edits into consideration.

That makes sense, but it seems like we should try to be as consistent with language as possible. If it's decided that we are considering temporary accounts as "Unregistered" then my suggestion above seems odd.

I agree that being consistent is good but I will point out that T337103 is mostly thinking about this on the technical front and that decision may not reflect what is intuitive for the end users.
@kostajh would you recommend the team wait on the outcome on T337103 before deciding on the terminology here?

Yes, I think it would make sense to mark this as stalled until we have resolution on T337103: Decide a standard approach for classifying temporary, IP and registered users.

I think there will be a case for a while where there may be a mix of IP and temp accounts existing, esp as the MVP will not happen for all wikis at once, but the temp account is afaik a global creation. So for example, there could be a scenario where someone on say fawiki makes an edit without an account that creates a temp account, then goes to enwiki whilst in that temp account and makes another edit. In that case, what Recent Changes filter on enwiki would capture this person's edit?

@RHo the idea is that we will try to isolate IP Masking enabled wikis from those where it is not enabled. So if wiki A has IP Masking enabled but wiki B doesn't, then a temporary account created on wiki A will show up like any other IP address on wiki B. We don't want wiki B users to encounter temporary accounts because they will not necessarily have the tools to handle them. But if the same temp user goes to wiki C which has IP Masking enabled, then it will persist as the same temporary account on wiki C.

Right thanks @Niharika, in that case could this be captured somewhere once this is confirmed and the behaviour updated? At the moment testing on de.wiki betalabs that is not the case. I made an unregistered edit on dewiki beta and it created a temp account *Unregistered 27619. Then navigating to eswiki beta (which afaict does not have temp accounts enabled) I was able to make an edit as *Unregistered 27619.

@RHo it's pending a technical investigation and will require whoever works on CentralAuth to confirm and implement this behavior. It will be captured on the officewiki page once it's confirmed we can do this. Thanks. :)

Edit: The task for discussing this is T342475: Define temporary account behavior on Wikimedia wikis which have IP masking disabled

What do you think of this approach:

Update the "Unregistered" filter copy (and logic) to:
Unregistered & Temporary
Editors who aren't logged in & editors using temporary accounts.

And then eventually after IP Masking has scaled to all wikis we will want to update the copy to:
Temporary
Editors using temporary accounts.

Would it possibly be confusing to see this copy on wikis where IP Masking hasn't been enabled yet?

We can change the wording conditionally, and only mention temporary accounts on project(s) where they are enabled (currently, only certain beta cluster wikis).

[...] Technically speaking temporary accounts are not really "registered" accounts and one could argue they can be labelled as "Unregistered".

I don't think that's correct. As far as I can see, at the technical level, temp. accounts behave pretty much like registered accounts do: they have a session cookie, a record in the user table, an user ID, an username (an automatically generated one, but still), User::isRegistered returns true for them, etc. They don't have a password, access to watchlist or preferences, but none of that is because of a technical decision or a technical limitation -- it is by a product decision (we could assign a password to a temp account, for example). That being said, I agree that non-technical users are likely (hopefully) going to interpret temp accounts as unregistered editing.

In other words: We might want to take a different product decision here and in T337103, because in this case, we don't need to take old edits into consideration.

That makes sense, but it seems like we should try to be as consistent with language as possible. If it's decided that we are considering temporary accounts as "Unregistered" then my suggestion above seems odd.

I agree that being consistent is good but I will point out that T337103 is mostly thinking about this on the technical front and that decision may not reflect what is intuitive for the end users.
@kostajh would you recommend the team wait on the outcome on T337103 before deciding on the terminology here?

Yes, I think it would make sense to mark this as stalled until we have resolution on T337103: Decide a standard approach for classifying temporary, IP and registered users.

Ack. AFAICS, there doesn't seem to be anything else we can do to make RC prepared for IP Masking -- this appears to be the only case in which RC does something based on the registeredness (which is the bit that's changed/affected by IP Masking).

FYI @KStoller-WMF

I'm making the following suggestion to unblock this task:

Given I'm on a wiki where IP Masking is not enabled,
When I view Recent Changes or Watchlist filters,
Then the Unregistered filter includes edits made by IP editors,
and the filter description is: Editors who aren't logged-in.
(nothing changes)


Given I'm on a wiki where IP Masking is enabled,
When I view Recent Changes or Watchlist filters,
Then the Unregistered filter includes edits made by IP editors and Temporary accounts
and the filter description is: Editors who aren't logged-in and editors who are using temporary accounts.
(logic change and description change)

Change 959679 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/core@master] RC Filters: Treat unnamed accounts as unregistered

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

Urbanecm_WMF set the point value for this task to 4.Nov 14 2023, 11:33 PM

Change 959679 merged by jenkins-bot:

[mediawiki/core@master] RC Filters: Treat unnamed accounts as unregistered

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

Checked on cswiki beta - works as expected:

Screen Shot 2023-11-16 at 2.48.16 PM.png (1×2 px, 415 KB)

Closing this task as Resolved (added to T341839: [QA task] IP masking - temp users testing in production.