Page MenuHomePhabricator

[Epic] Update Growth Team-owned products that may be affected by IP Masking
Open, MediumPublic

Description

User story:

As a logged out user, I want the option to edit without creating a permanent account AND without my IP address displaying publicly, because I value privacy and don't care to create an account.

As a temporary account holder, I want to understand that I am already logged into a temporary account and what a temporary account is, because then I can edit with confidence.

As a logged in account holder or a "logged out visitor**, I want to clearly differentiate and understand temporary accounts from permanent accounts.


IP Masking will affect lots of our products, features, tools, gadgets, etc. This task is for tracking work to update those that are owned by Growth-Team, ahead of IP Masking being enabled on WMF sites.


Background:

Project documentation: IP Editing: Privacy Enhancement and Abuse Mitigation

What is IP Masking and why is the Wikimedia Foundation masking IPs?
IP masking hides the IP addresses of unregistered editors on Wikimedia projects, fully or partially, from everyone except those who need access to fight spam, vandalism, harassment and disinformation.

With changes to privacy laws and standards (e.g., the General Data Protection Regulation and the global conversation about privacy that it started), the Wikimedia Foundation Legal team has decided to protect user privacy by hiding IPs from the general public. However, we will continue to give access to users who need to see them in order to protect the wikis.


Scope of this Epic:

All of the work needed for the MVP release of IP Masking that relates to features or workflows owned or maintained by the Growth-Team.

See T326816: Update features for IP Masking, particularly What will be affected.
A preliminary investigation conducted by the AHT team (T326759) has found that the following may be affected:

GrowthExperiments

  • Welcome Survey
  • Help Panel
  • Newcomer homepage
  • Suggested edits
  • Mentor dashboard
  • Community Configuration

Other Growth maintained features / projects

Other extensions passively maintained by Growth

Related Objects

StatusSubtypeAssignedTask
In ProgressNiharika
OpenNone
OpenKStoller-WMF
ResolvedEtonkovidova
OpenKStoller-WMF
ResolvedUrbanecm_WMF
ResolvedBUG REPORTkostajh
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
DuplicateNone
OpenCyndymediawiksim
In ProgressCyndymediawiksim
ResolvedCyndymediawiksim
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedSgs
Resolved TThoabala
Resolved TThoabala
ResolvedMRaishWMF
ResolvedRHo
ResolvedJFernandez-WMF
OpenNone
OpenNone
ResolvedBUG REPORTEtonkovidova
ResolvedEtonkovidova
ResolvedEtonkovidova
OpenNone
ResolvedFeatureJdrewniak
Resolvedkostajh
ResolvedKStoller-WMF
ResolvedUrbanecm_WMF
Resolvedovasileva
StalledNone
ResolvedUrbanecm_WMF
Opennettrom_WMF
ResolvedUrbanecm_WMF
Resolved TThoabala
OpenNone
ResolvedUrbanecm_WMF
DuplicateNone
ResolvedKStoller-WMF
ResolvedUrbanecm_WMF
StalledTrizek-WMF
ResolvedUrbanecm_WMF
ResolvedTrizek-WMF
ResolvedUrbanecm_WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedSgs
ResolvedSgs
ResolvedEtonkovidova
DeclinedNone
OpenNone
ResolvedTrizek-WMF
In ProgressNone
ResolvedUrbanecm_WMF

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

@RHo @KStoller-WMF should temporary account users have access to Special:Homepage?

@KStoller-WMF and I have talked about the potential of allowing temp accounts to try a "teaser" version of the homepage with reduced functionality, and some prompt to create an account, but they should not access the current homepage in its current state. It's definitely a key decision we will make after syncing with AHaT and team discussion next week.

Note that with the exception of GrowthExperiments, the other extensions are in our list of "non-maintained projects". On the other hand, we do say that for "non-maintained projects":

Bugs and issues coming up on this projects will ONLY receive attention if the issue is urgent, affects a large number of users and needs to be unbroken immediately.

... which is probably the case for IP masking work.

That aside, addressing IP masking issues across all of these projects might be a significant chunk of work, depending on what product decisions we make, so I assume we will want to clarify scope in Q3, in order to implement the needed changes in Q4, to support a rollout of IP masking work in Q1/Q2 of FY2023-2024.

Coordinating all of the teams and moving pieces for this release will be extensive. I suggest that rather than add more complexity at this point by attempting to provide certain Growth features for temporary accounts, we clearly decide that isn't part of the MVP release. In other words, IP editors currently don't receive Growth features and neither will temporary accounts for the initial IP Masking MVP release. Once the MVP is out, we can decide if we should prioritize "teaser" Growth features for temporary accounts (and we could likely conduct A/B testing with less confusion at that point too). Does that seem logical, or do others strongly feel we need to prioritize allowing temporary account access to a subset of Special:Homepage as part of the MVP?

I don't think that simplifies the other work we need to do though, it sounds like we will still need to review all of the extensions / projects we maintain.

Coordinating all of the teams and moving pieces for this release will be extensive. I suggest that rather than add more complexity at this point by attempting to provide certain Growth features for temporary accounts, we clearly decide that isn't part of the MVP release. In other words, IP editors currently don't receive Growth features and neither will temporary accounts for the initial IP Masking MVP release. Once the MVP is out, we can decide if we should prioritize "teaser" Growth features for temporary accounts (and we could likely conduct A/B testing with less confusion at that point too). Does that seem logical, or do others strongly feel we need to prioritize allowing temporary account access to a subset of Special:Homepage as part of the MVP?

I don't think that simplifies the other work we need to do though, it sounds like we will still need to review all of the extensions / projects we maintain.

Agree that the 'teaser' features should wait till after post-MVP needed tasks. Per off-Phab discussion, should we create some sub-tasks to do a high-level product, QA, and Eng review of the impact of the change for Growth maintained projects?

Once the MVP is out, we can decide if we should prioritize "teaser" Growth features for temporary accounts (and we could likely conduct A/B testing with less confusion at that point too). Does that seem logical, or do others strongly feel we need to prioritize allowing temporary account access to a subset of Special:Homepage as part of the MVP?

That makes sense. In practice, that will mean updating a bunch of code to check not just if the user is logged-in, but also if the account is a non-temporary one. We could probably make a task for that and start it whenever we have time.

Agree that the 'teaser' features should wait till after post-MVP needed tasks. Per off-Phab discussion, should we create some sub-tasks to do a high-level product, QA, and Eng review of the impact of the change for Growth maintained projects?

That sounds like a good idea to me!

Other non-maintained projects that will be affected:

  • RC and watchlist (the "user type" filter will need to be extended with the new type)
  • NewUserActions, NewUserNotif? I'm not really sure what these are used for, but we should make sure they interpret "new user" in a way that makes sense for their use case
  • Nuke - it can mass delete edits by IP, that functionality probably needs to be adjusted (maybe this is a good time to transition it to the Moderator Tools team?).

OTOH PageTriage will be owned by Moderator Tools at that point, I think?

Per off-Phab discussion, should we create some sub-tasks to do a high-level product, QA, and Eng review of the impact of the change for Growth maintained projects?

We definitely should. It might also be helpful to brainstorm some general guidelines / suggestions on what to look for (e.g. engineering-wise the usage of the LocalUserCreated hook needs to be reviewed).

We also need more clarity on some of the technical implementation plans, I think. E.g. what does it mean that preferences are not accessible for temp users? (Will a direct link to Special:Preferences still work? Will an options API request work?) What happens when a user without a session makes a write API request (a common scenario in Flow)?

Other non-maintained projects that will be affected:

  • RC and watchlist (the "user type" filter will need to be extended with the new type)
  • NewUserActions, NewUserNotif? I'm not really sure what these are used for, but we should make sure they interpret "new user" in a way that makes sense for their use case
  • Nuke - it can mass delete edits by IP, that functionality probably needs to be adjusted (maybe this is a good time to transition it to the Moderator Tools team?).

OTOH PageTriage will be owned by Moderator Tools at that point, I think?

Per off-Phab discussion, should we create some sub-tasks to do a high-level product, QA, and Eng review of the impact of the change for Growth maintained projects?

We definitely should. It might also be helpful to brainstorm some general guidelines / suggestions on what to look for (e.g. engineering-wise the usage of the LocalUserCreated hook needs to be reviewed).
We also need more clarity on some of the technical implementation plans, I think. E.g. what does it mean that preferences are not accessible for temp users? (Will a direct link to Special:Preferences still work? Will an options API request work?) What happens when a user without a session makes a write API request (a common scenario in Flow)?

I created an initial rough draft of testing from Product/Design perspective here as a start, and included questions in there about what happens when specific URL is accessed when that person is a temp account. Please feel free to edit and add if it is useful.

Thank you @RHo that document will be extremely helpful!

I created subtasks: T327419: Growth: Product testing for IP Masking & T327420: Growth: Engineering testing for IP Masking to cover the testing / audit work that needs to be completed. Perhaps engineers can brainstorm and add to T327420?

@MShilova_WMF Should we convert this task to the Epic that all Growth + IP Masking work falls under?

MShilova_WMF renamed this task from Update Growth Team-owned products that may be affected by IP Masking to [Epic] Update Growth Team-owned products that may be affected by IP Masking.Jan 19 2023, 5:04 PM
MShilova_WMF added a project: Epic.

@KStoller-WMF , yes, that is a great idea. Especially, given that we now have a new dedicated IP-Masking bar on our roadmap. I converted this task to an epic and added related tasks as child tickets.

Other non-maintained projects that will be affected:

  • RC and watchlist (the "user type" filter will need to be extended with the new type)
  • NewUserActions, NewUserNotif? I'm not really sure what these are used for, but we should make sure they interpret "new user" in a way that makes sense for their use case
  • Nuke - it can mass delete edits by IP, that functionality probably needs to be adjusted (maybe this is a good time to transition it to the Moderator Tools team?).

OTOH PageTriage will be owned by Moderator Tools at that point, I think?

I met with Kirsten last week and mentioned that we'd likely be happy to tackle the PageTriage work for this. I'm not sure about Nuke but happy to discuss.

Just a note that any special pages that call SpecialPage::requireLogin can be updated to call SpecialPage::requireNamedUser if necessary. From a quick search, it looks like this may affect GrowthExperiments and Echo.

RHo updated the task description. (Show Details)

I updated the task description to add more details and clarify that the AHT team conducted an initial audit that helped identify work that would be needed by the Growth team, but that ultimately the Growth team will be responsible for all features and extensions that we own or maintain (even if they weren't listed in that initial AHT audit).