Hi, I'm working on Prevent extensions from setting preferences for temporary accounts and I wanted to make sure I'm taking the right direction regarding temp users on GrowthExperiments.

In T326877, I read "IP editors currently don't receive Growth features and neither will temporary accounts for the initial IP Masking MVP release."
Do I understand right that, as for now, we do now want the Temp Users to access the Growth experience?

If so, the tickets that I will be creating following my investigation will provide the insight you need for this patch, i.e., where to change code to reflect the introduction of temp users (prevent them to access the GrowthExperiments experience AND from saving Users Options preferences.)

Thank you,

In T327420#8886947, @AGueyte wrote:

Hi, I'm working on Prevent extensions from setting preferences for temporary accounts and I wanted to make sure I'm taking the right direction regarding temp users on GrowthExperiments.

In T326877, I read "IP editors currently don't receive Growth features and neither will temporary accounts for the initial IP Masking MVP release."
Do I understand right that, as for now, we do now want the Temp Users to access the Growth experience?

Hi there, @KStoller-WMF can confirm but no, we do NOT plan to turn on Growth experiments for temp accounts at this stage.

If so, the tickets that I will be creating following my investigation will provide the insight you need for this patch, i.e., where to change code to reflect the introduction of temp users (prevent them to access the GrowthExperiments experience AND from saving Users Options preferences.)

Thank you,

In T327420#8887600, @RHo wrote:

In T327420#8886947, @AGueyte wrote:

Hi, I'm working on Prevent extensions from setting preferences for temporary accounts and I wanted to make sure I'm taking the right direction regarding temp users on GrowthExperiments.

In T326877, I read "IP editors currently don't receive Growth features and neither will temporary accounts for the initial IP Masking MVP release."
Do I understand right that, as for now, we do now want the Temp Users to access the Growth experience?

Hi there, @KStoller-WMF can confirm but no, we do NOT plan to turn on Growth experiments for temp accounts at this stage.

That is my understanding as well.

@AGueyte it might make sense to create separate tasks for each extension and file them as subtasks of T327420: Growth: Engineering testing for IP Masking?

FWIW, for GrowthExperiments, most of the work will be in the LocalUserCreated hook. That's where we opt new user accounts into Growth features. We'll want to modify that check so that we exclude temporary users from Growth feeatures.

@KStoller-WMF can confirm but no, we do NOT plan to turn on Growth experiments for temp accounts at this stage.

Confirmed, we do NOT plan to turn on Growth experiments for temp accounts at this stage.

Re: PageTriage, not in scope for this task, but including a checkbox filter for "created by a temporary user" might be nice:

The MVP for IP Masking is to maintain parity with logged out/IP editors, with the notable exception of enabling Echo notifications for Temporary accounts. Even then, they will not be able to access and change the default preferences. Given this, I am updating the task description removing the open question about thanks functionality and welcome notification. cc: @KStoller-WMF

I updated this task to note:
Any PageTriage work will be owned by Moderator Tools:

• T339252: Investigate impact of IP Masking on PageTriage

I added two tasks identified as needed:

• T341389: Mentor dashboard: Ensure temporary accounts are not listed in Mentee overview.
• T341390: Mentor dashboard: Ensure temporary accounts are not recommended as praiseworthy mentees in Personalized praise.

StructuredDiscussions will be the most complex project to work with. Similar to VisualEditor, it makes edits via the API. As of now (tested at dewiki beta), the API attributes the edit to the IP address, instead of creating a temporary account (which is the intended behaviour). Ideally, after submitting, the temporary banner should as well (alternatively, a refresh can be triggered). Making the temporary account fully transferrable across domains would require a hop over login.wikimedia.org; it is unclear whether preserving one temp account when project-hopping is a MVP requirement.

@Niharika Is preserving one temp account when project-hopping a MVP requirement?

Controversial pondering ahead: any chance we should consider prioritizing deprecating StructuredDiscussions rather than making IP Masking work with StructuredDiscussions? I recognize that's significantly more work, but it's a shame to continue to invest in accommodating StructuredDiscussions if the long term plan is to phase it out.

In T327420#8998782, @KStoller-WMF wrote:

@Niharika Is preserving one temp account when project-hopping a MVP requirement?

I'm pretty sure this was an explicit requirement.

Other tools (VisualEditor, the mobile editor, DiscussionTools) also have this problem and Editing is building tooling to handle it in T338002: Let action=edit API instruct the client to redirect to another location after saving the edit. We can probably reuse that.

Controversial pondering ahead: any chance we should consider prioritizing deprecating StructuredDiscussions rather than making IP Masking work with StructuredDiscussions?

Would be great but I don't think it's realistic.

Should temporary accounts to be able to thank other users (whether temporary or not)? This is more tricky than it might sound like, as we might need to create the temporary account while thanking. It would be easier to prevent temporary accounts from thanking other users.

We could just allow thanking for temp users, but not for anonymous users; that would be trivial (I think it's what happens if we don't touch the code at all) and seems like a nice thing to do.

Some things that come to mind (have not reviewed the code):

• We should review special pages which are only available for logged-in users - some should only be available for named users (e.g. Special:Homepage but I'm sure there are more).
• Same for APIs.
• Same for permissions in general - some permissions for the user group should be reassigned to named.
• We should check if T310320: Account creation + Growth tools: improve UX for newcomers who create an account while mid-edit is affected.
• Do we want to allow temp users to opt into Flow? I assume not. (Especially given T248309: StructuredDiscussions (Flow): Prevent users from enabling Flow on their user talk page (beta feature).)
• MW-extensions-Nuke
• Recent changes / watchlist probably needs "temp user" and "named user" filters, instead of the current "logged-in user". Should be trivial (unless we run into some kind of query performance issue).
• Recent changes probably needs links to relevant functionality (like revealing IP addresses) - I assume AHT handles that?
• When should MediaWiki-extensions-NewUserActions actions fire? Given that the goal of the extension is to be flexible, it should probably be configurable, but maybe not for the MVP.
  • How did we end up as owners of that extension when it's not used on Wikimedia wikis at all? (Although apparently proposed to be used: T117958 but not much movement on that.)
• MediaWiki-extensions-NewUserNotif should be limited to named users. Notifying admins when a temp user is created makes no sense.
  • How did we end up as owners of that extension when it's not used on Wikimedia wikis at all?
• Will the precision of ORES filters be negatively affected by the "anon" flag (which IIRC has a significant weight in vandalism scores) being misleading for temp users? Does ORES need to be retrained with a "temp" parameter? This isn't really our problem (we only own the MediaWiki extension for ORES, and that's only presenting the scores, not calculating them) but we should probably make sure the ML team is aware.

In T327420#8998167, @RHo wrote:

The MVP for IP Masking is to maintain parity with logged out/IP editors, with the notable exception of enabling Echo notifications for Temporary accounts. Even then, they will not be able to access and change the default preferences. Given this, I am updating the task description removing the open question about thanks functionality and welcome notification. cc: @KStoller-WMF

! In T327420#8999029, @Tgr wrote:
Should temporary accounts to be able to thank other users (whether temporary or not)? This is more tricky than it might sound like, as we might need to create the temporary account while thanking. It would be easier to prevent temporary accounts from thanking other users.

We could just allow thanking for temp users, but not for anonymous users; that would be trivial (I think it's what happens if we don't touch the code at all) and seems like a nice thing to do.

Thanks for the info. I asked the question, as allowing temp users to thank others and be thanked would (in this case) likely result in less work for us. Of course, if it's a strong requirement to not give them this capability, we can, I was just curious about the post-MVP plans here.

In T327420#8998782, @KStoller-WMF wrote:

Controversial pondering ahead: any chance we should consider prioritizing deprecating StructuredDiscussions rather than making IP Masking work with StructuredDiscussions? I recognize that's significantly more work, but it's a shame to continue to invest in accommodating StructuredDiscussions if the long term plan is to phase it out.

As @Tgr notes, that would be wonderful, but probably not realistic to complete in time for IP Masking. I'm not sure what the structure of Flow-enabled wikis is as of today, but maybe we can get some pilot deprecation wikis to at least get the process started? Disabling new Flow pages created might be an achievable goal to set. There also might be some wikis that actually wouldn't require the full service (such as preserving existing topic subscriptions), and it might make sense to ask "What would it take to disable Flow" at some wikis?

In T327420#8999072, @Tgr wrote:

Some things that come to mind (have not reviewed the code):

Thanks for all the additional notes @Tgr! Some of the comments seem to be resolved already -- see below for my comments.

We should review special pages which are only available for logged-in users - some should only be available for named users (e.g. Special:Homepage but I'm sure there are more).

For GrowthExperiments, that should be already handled via T338150: Prevent GrowthExperiments extension from saving preferences for Temp user (5ba832b3c11 in particular). The only other usage in the extensions listed above seems to be in Echo, which is supposed to be accessible for temp. users, so it presumably should stay as-is.

As for the APIs, AFAIK there is no requireLogin helper function, as there is for special pages, so that should be handled by the regular isRegistered / isAnon calls.

Same for permissions in general - some permissions for the user group should be reassigned to named.

I don't think that's an issue since rMWdd2f898f86ee: Add temporary users to a 'temp' group, and stop adding them to 'user' -- temp users should now be a member of the temp and * groups only. This means permission changes should be only needed when allowing temporary users to use the feature, rather than making temp users on par with IP users (Echo is the only current such case, and it does not have any permissions assigned to all users as far as I can see.

Do we want to allow temp users to opt into Flow? I assume not..

Definitely not. It would be a design change as temp users don't have access to their preferences. Additionally, temp users need to re-opt in at least every $EXPIRYDAYS days, which is not convenient.

MW-extensions-Nuke

Seems to be already filled and taken care of by Moderator Tools as part of T340631: Does Nuke need substantial feature changes to retain current functionality with IP Masking?. I am unsure whose responsibility Nuke will end up in (I've added this as a question for the Tuesday meeting).

Recent changes / watchlist probably needs "temp user" and "named user" filters, instead of the current "logged-in user". Should be trivial (unless we run into some kind of query performance issue).

Good point. I'm a bit worried about the performance here (we've already seen some issues with the speed of RC filters, and calling User::isNamed instead of evaluating whether rc_user evaluates to true probably won't help with that.

In addition to what @Tgr noted, we should also review onLocalUserCreated hooks, as those may or may not require User::isNamed as a new check. List of entries to check is available.

I updated the task to clarify that Growth doesn't need to audit Nuke:

MW-extensions-Nuke: IP masking work to be owned by Moderator-Tools-Team: T340631: Does Nuke need substantial feature changes to retain current functionality with IP Masking?

I re-checked the current behavior for these two features:

(1)

Thanks

The only usage of logged-in status in Thanks is to disallow logged out users from giving/receiving thanks for their edits. This brings two product questions:

(2) [] MW-Extensions-ORES
Presently, ores_classification table on cswiki and dewiki seems to be never updated (RC ores filters don't work).

In T327420#9125461, @Etonkovidova wrote:

I re-checked the current behavior for these two features:

(1)

Thanks

The only usage of logged-in status in Thanks is to disallow logged out users from giving/receiving thanks for their edits. This brings two product questions:

Specs	Current behavior - cswiki beta, dewiki beta
[X] Should temporary accounts to be able to thank other users (whether temporary or not)? This is more tricky than it might sound like, as we might need to create the temporary account while thanking. It would be easier to prevent temporary accounts from thanking other users. Answer: No, Temporary account should not be able to thank for MVP	Temporary users are able to thank
[X] Should temporary accounts be able to be thanked by other users (whether temporary or not)? This should be reasonably easy to implement, as for a temporary account to be thankable, it has to exist already (an edit was made through it). Answer: No, Temporary account should not be able to be thanked for MVP.	Temp users can receive Thank notifications

Thanks for mentioning this. I was under the impression that we (eventually) changed the answer and allowed temp users to thank/be thanked, since that's the easiest solution given we've notifications etc. available already, but that impression can be incorrect.

(2) [] MW-Extensions-ORES
Presently, ores_classification table on cswiki and dewiki seems to be never updated (RC ores filters don't work).

That seems to be the case for other wikis as well. For example, enwiki's last revision in ores_classification dates 20230706161553. For those reason, it doesn't seem to be IP-Masking related?

In T327420#8998782, @KStoller-WMF wrote:

StructuredDiscussions will be the most complex project to work with. Similar to VisualEditor, it makes edits via the API. As of now (tested at dewiki beta), the API attributes the edit to the IP address, instead of creating a temporary account (which is the intended behaviour). Ideally, after submitting, the temporary banner should as well (alternatively, a refresh can be triggered). Making the temporary account fully transferrable across domains would require a hop over login.wikimedia.org; it is unclear whether preserving one temp account when project-hopping is a MVP requirement.

@Niharika Is preserving one temp account when project-hopping a MVP requirement?

Sorry, I missed this ping. Tgr is correct. This is a requirement.

In T327420#9126423, @Urbanecm_WMF wrote:
Thanks for mentioning this. I was under the impression that we (eventually) changed the answer and allowed temp users to thank/be thanked, since that's the easiest solution given we've notifications etc. available already, but that impression can be incorrect.

From a Growth PM perspective, I don't see the harm in allowing temp users to thank/be thanked. That seems like the simplest solution, and it seems odd to spend the time to remove it. However, that goes against the "make temp accounts similar to IP editing defaults" requirement, so @Niharika, perhaps you can chime in here?

In T327420#9129012, @KStoller-WMF wrote:

In T327420#9126423, @Urbanecm_WMF wrote:
Thanks for mentioning this. I was under the impression that we (eventually) changed the answer and allowed temp users to thank/be thanked, since that's the easiest solution given we've notifications etc. available already, but that impression can be incorrect.

From a Growth PM perspective, I don't see the harm in allowing temp users to thank/be thanked. That seems like the simplest solution, and it seems odd to spend the time to remove it. However, that goes against the "make temp accounts similar to IP editing defaults" requirement, so @Niharika, perhaps you can chime in here?

About thanking temp users: I think this decision really boils down to whether you think it would be helpful to thank temp editors? Maybe it makes them feel appreciated and entices them to create official accounts? If so, then maybe the wording for the Thanks notification for these users could be modified to convince them to create an account.

About letting temp users thank other users: I think this decision should be tied with the decision to Mute temp users. One of the motivations behind the mute features was to be able to mute people who make excessive use of "thanks" feature to spam someone. If temp users cannot be muted, then we shouldn't let them spam an account with Thanks notifications.

In T327420#9126423, @Urbanecm_WMF wrote:

In T327420#9125461, @Etonkovidova wrote:

(2) [] MW-Extensions-ORES
Presently, ores_classification table on cswiki and dewiki seems to be never updated (RC ores filters don't work).

That seems to be the case for other wikis as well. For example, enwiki's last revision in ores_classification dates 20230706161553. For those reason, it doesn't seem to be IP-Masking related?

Yes, it's not IP-masking related. ORES tables on beta are often in a non-up- to-date state. Actually, the point of my checking was: cswiki beta and dewiki beta cannot be used to check ORES behavior.

Thanks for the feedback, @Niharika!

Thanking temp users:
It seems odd to spend time removing a feature that has been shown to be successful, so I'm in support of allowing temp accounts to be Thanked. I think it's a simple way of sharing some positivity and showing that there is a community if editors behind the wikis, and perhaps a Thanks notification could encourage some temp accounts to create regular accounts.

Temp users sending Thanks:
Based on the technical complexity and potential for abuse, I don't think temp users should be able to thank other users. However, I'm curious to explore showing the Thank "button" but then displaying a message that encourages the temp user to create a regular account to send Thanks.

☝️ Thoughts on that approach, @Urbanecm_WMF @Trizek-WMF ? If that seems like a good approach, I'll log a task to finalized design and copy.

In T327420#9132354, @KStoller-WMF wrote:

Thanking temp users:
It seems odd to spend time removing a feature that has been shown to be successful, so I'm in support of allowing temp accounts to be Thanked. I think it's a simple way of sharing some positivity and showing that there is a community if editors behind the wikis, and perhaps a Thanks notification could encourage some temp accounts to create regular accounts.

👍 This sounds good to me. We can certainly rephrase that message for temporary accounts.

Temp users sending Thanks:
Based on the technical complexity and potential for abuse, I don't think temp users should be able to thank other users. However, I'm curious to explore showing the Thank "button" but then displaying a message that encourages the temp user to create a regular account to send Thanks.

Tbh, I don't feel like the abuse potential for temp. accounts and thanking is higher. In my opinion, the underlying issue is not muting temp accounts, but the fact that it is incredibly easy to receive dozens of temporary accounts as a matter of seconds/minutes (as opposed to generating registered accounts, which is not terribly difficult to do en-masse, but still requires more effort than with temp accounts).

As a result, regardless of whether a temp account can be muted or not, currently it is very easy to trigger a lot of notifications to harass other people, be it thanks, mentions, reverts, linking a page created by the harassed individual, talk page messages or regular edits. I agree that poses a significant abuse potential, but I also think that if the ability to mass-generate temp accounts w/o limitations is resolved, then the abuse potential would be resolved as well.

This is not meant as a strong objection, but I feel like we're trying to resolve (one of many) consequences of having the abuse vector I described above opened, instead of closing the abuse vector down.

FWIW, we did have issues with thanks even for registered accounts, cf. T169268.

In T327420#9132354, @KStoller-WMF wrote:

Thanking temp users:
It seems odd to spend time removing a feature that has been shown to be successful, so I'm in support of allowing temp accounts to be Thanked. I think it's a simple way of sharing some positivity and showing that there is a community if editors behind the wikis, and perhaps a Thanks notification could encourage some temp accounts to create regular accounts.

Temp users sending Thanks:
Based on the technical complexity and potential for abuse, I don't think temp users should be able to thank other users. However, I'm curious to explore showing the Thank "button" but then displaying a message that encourages the temp user to create a regular account to send Thanks.

☝️ Thoughts on that approach, @Urbanecm_WMF @Trizek-WMF ? If that seems like a good approach, I'll log a task to finalized design and copy.

I think we have a solid plan, as it follows the current practices (IP can't thank). It is better to keep things as they are for established users.
Allowing registered accounts to thank temp accounts is a nice addition; it can indeed increase the number of encouragements.

In T327420#9133023, @Urbanecm_WMF wrote:
In my opinion, the underlying issue is not muting temp accounts, but the fact that it is incredibly easy to receive dozens of temporary accounts as a matter of seconds/minutes (as opposed to generating registered accounts, which is not terribly difficult to do en-masse, but still requires more effort than with temp accounts).

As a result, regardless of whether a temp account can be muted or not, currently it is very easy to trigger a lot of notifications to harass other people, be it thanks, mentions, reverts, linking a page created by the harassed individual, talk page messages or regular edits. I agree that poses a significant abuse potential, but I also think that if the ability to mass-generate temp accounts w/o limitations is resolved, then the abuse potential would be resolved as well.

I agree that we shouldn't make this decision based only on the potential abuse vector of sending Thanks to trigger excessive notifications.

Funny story: when I was in high school, the school administration mandated that no one was allowed to wear sweatpants, because a lot of people wearing sweatpants were getting de-pantsed. Rather than addressing the actual issue (jerks de-pantsing people wearing comfortable pants), they made the easier "don't wear sweatpants" rule. Let's not take a similar approach to Thanks. 😄

In other words, I think ideally we should address the root issue that might cause abuse here and ensure that one person can't generate a ton of temp accounts in a row. But I think that's more of an AHT dilemma (@Niharika) than a Growth dilemma.

On the Thanks side, I'm honestly not super opinionated, but my suggestion was based on several factors:

1. ensuring Thanks isn't an abuse vector
2. ensuring there are small (not obnoxious) ways we are encouraging temp accounts to create regular accounts
3. ensuring (where it makes sense) Temp account UX is similar to the current IP editor UX
4. ensuring we aren't picking an unnecessarily complex technical solution (unless there is a true product need for that solution)

So my suggestion was partially based on the note in the task description about "Should temporary accounts to be able to thank other users?"

This is more tricky than it might sound like, as we might need to create the temporary account while thanking. It would be easier to prevent temporary accounts from thanking other users.

But re-reading that, I think I originally misunderstood the intent of that statement.
@Urbanecm_WMF Is my current understanding correct:

• Showing Thanks to logged out users would be complex, because it would require we allow them to create an account / login while thanking.
• Once a temp account is created, it's actually the easiest technical solution to simply allow them to send Thanks.

In T327420#9137471, @KStoller-WMF wrote:

So my suggestion was partially based on the note in the task description about "Should temporary accounts to be able to thank other users?"

This is more tricky than it might sound like, as we might need to create the temporary account while thanking. It would be easier to prevent temporary accounts from thanking other users.

But re-reading that, I think I originally misunderstood the intent of that statement.
@Urbanecm_WMF Is my current understanding correct:

• Showing Thanks to logged out users would be complex, because it would require we allow them to create an account / login while thanking.
• Once a temp account is created, it's actually the easiest technical solution to simply allow them to send Thanks.

Thanks for your comment, Kirsten! Indeed, I could've made that more clear in the statement. Your understanding is correct: once a temp account exists, letting the thank button be there is easiest, but it doesn't appear when no temp account exists (ie. before making any edit).

I can see how this can be confusing (the difference between logged out and logged into a temp account is nearly nonexistent, as everything happens automatically), so I see how disallowing thanks even for temp. accounts would make sense. Based on the factors you've listed in the comment, it seems the best fitting solution is allowing temp accounts to be thanked, but not to thank other users. If that matches your understanding, we can fill a task for this and call the engineering testing resolved?

In T327420#9139682, @Urbanecm_WMF wrote: If that matches your understanding, we can fill a task for this and call the engineering testing resolved?

Yes! I've added: T345679: Update the Thanks extension to be compatible with the IP Masking project