Page MenuHomePhabricator

Temporary Accounts: Update StructuredDiscussions (Flow)
Open, MediumPublic

Description

User story:

As a logged out user, I don't want my IP address displaying publicly, because I value privacy and don't care to create an account.

Decision needed:

Should we update StructuredDiscussions to accommodate temporary accounts? No, this would require work on a complex extension that is slated for sunsetting T332022: [Epic] Undeploying StructuredDiscussions (Flow).
Should we prevent logged out edits to StructuredDiscussions threads?
Should we schedule the sunsetting work of StructuredDiscussions to align with the temporary accounts rollout? For example, provide further communication about sunsetting flow, and lock existing Flow threads at a certain date.


Background:

Project documentation: IP Editing: Privacy Enhancement and Abuse Mitigation

Scope of this task:

This task and all subtasks are for tracking work related to Flow changes needed to adhere to the compliance requirements related to IP Masking / Temporary Accounts.

NOTE: How can we minimize the effort invested in Flow, knowing that ideally we want to move projects away from the use of Flow in the future? T332022: [Epic] Undeploying StructuredDiscussions (Flow)

Testing notes:

StructuredDiscussions will be the most complex project the Growth team will need to work on for IP Masking.

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.

QA Testing notes:

  • a temp user cannot make their first edit on a Flow page. The warnings incorrectly inform a temp user about its status.

Screen Shot 2023-07-26 at 2.33.18 PM.png (966×1 px, 134 KB)

  • A temp user can "add" any topic to a watchlist, although watchlist is not reachable for temp users. A Flow page has the watchlist star that can be clicked by a temp users:

Screen Shot 2023-07-26 at 2.50.46 PM.png (792×1 px, 100 KB)

Acceptance Criteria for MVP release:

TBD

Event Timeline

Re-checked on dewiki beta - e.g. of Flow pages - https://de.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Flow_Test or https://de.wikipedia.beta.wmflabs.org/wiki/Flow_test_talk:Abc (Flow extension is not installed on cswiki beta) - the issues mentioned in the task description are still present.

Relevant to this task:

We talked about whether it's easier to just disallow anonymous editing in Flow. For reference, this is how it looks:

normaldisallowed
Screenshot Capture - 2023-08-08 - 20-22-51.png (297×620 px, 33 KB)
Screenshot Capture - 2023-08-08 - 20-22-19.png (350×624 px, 42 KB)

It's not super straightforward to do because Flow uses the edit right for permission checks and we can't take that away, but hopefully still fairly straightforward.
Either we can use a permission hook to disallow anon edits to Flow pages, and hope that Flow checks permissions in a way that allows for that; or we can change FlowActions and declare a new flow-edit right.

@Tgr to confirm, if we disallow anonymous editing on Flow boards, Temporary accounts will still be able to post on Flow boards once the Temporary account is created via an edit elsewhere, correct?
That seems to be the case currently: https://de.wikipedia.beta.wmflabs.org/wiki/Thema:Xni4va4cbopwngf2

@Tgr to confirm, if we disallow anonymous editing on Flow boards, Temporary accounts will still be able to post on Flow boards once the Temporary account is created via an edit elsewhere, correct?
That seems to be the case currently: https://de.wikipedia.beta.wmflabs.org/wiki/Thema:Xni4va4cbopwngf2

I'm not @Tgr, but yes, that should be the case, as we'd only affect the permissions for anonymous users, not temporary accounts.

This task was discussed in Growth's weekly priority meeting. I mentioned that, if possible, I want to limit the effort we invest in Flow as we want to move projects away from the use of Flow in the future. (Related work: T332022: [Epic] Undeploying StructuredDiscussions (Flow)).

However, before moving forward with a decision, ideally I can get a basic level of effort estimate from engineers on these two approaches:

  • Disallowing anonymous editing in Flow. We would want to present an informative error message to logged out / IP editors when they attempt to add a message in Flow.
    • Already supported: Once a temp account is created, then temp accounts can post in Flow discussions, it just can’t be their first edit.
  • Fully support temporary account edits in Flow. A logged out user could post in Flow which would trigger the creation of a temporary account. In other words, we support Flow in basically the same way that we are supporting DiscussionTools. T332432: Update DiscussionTools for IP masking

Related discussion happening as part of this task: T346108: [EPIC] IP Masking: StructuredDiscussions (Flow)/LiquidThreads Community discussion

I'll move this task to Triaged for now.

This task was discussed in Growth's weekly priority meeting. I mentioned that, if possible, I want to limit the effort we invest in Flow as we want to move projects away from the use of Flow in the future. (Related work: T332022: [Epic] Undeploying StructuredDiscussions (Flow)).

However, before moving forward with a decision, ideally I can get a basic level of effort estimate from engineers on these two approaches:

  • Disallowing anonymous editing in Flow. We would want to present an informative error message to logged out / IP editors when they attempt to add a message in Flow.
    • Already supported: Once a temp account is created, then temp accounts can post in Flow discussions, it just can’t be their first edit.

Bumping this, as I think we still need a rough estimate / scope for this.

I would also suggest that we add another variation, which is to disallow temp accounts from using Flow as well. The reason for doing that is to avoid needing further work in related tooling that hooks into Flow changes (especially anti-abuse tooling).

  • Fully support temporary account edits in Flow. A logged out user could post in Flow which would trigger the creation of a temporary account. In other words, we support Flow in basically the same way that we are supporting DiscussionTools. T332432: Update DiscussionTools for IP masking

Without having looked closely: is it possible to do something similar to what is implemented in Wikibase, and use TempUserCreator to create the temp account on edit?

I would also suggest that we add another variation, which is to disallow temp accounts from using Flow as well.

If a project is not actively using Flow, we can freeze all flow boards via setting $wgFlowReadOnly instead.

KStoller-WMF renamed this task from IP Masking: Update StructuredDiscussions (Flow) to Temporary Accounts: Update StructuredDiscussions (Flow).Mar 6 2024, 10:25 PM
KStoller-WMF updated the task description. (Show Details)

I would also suggest that we add another variation, which is to disallow temp accounts from using Flow as well. The reason for doing that is to avoid needing further work in related tooling that hooks into Flow changes (especially anti-abuse tooling).

I updated the description to allow for other approaches including what you suggest.

Based on recent community conversations, in which there is general acceptance or support for deprecating Flow, and seeing how limited the usage of Flow is currently, I personally think we should align the Flow deprecation with the rollout of Temporary accounts.

In other words, rather than any remediation work on Flow to accommodate IP Masking, we instead invest in sunsetting the feature. Perhaps the freezing of Flow boards can be one step in that process. Clearly the Temporary accounts project is the higher priority, so we would need to ensure the Flow deprecation work aligned with the Temporary accounts timeline.

That being said, I don't think I'm the final decision maker here, so I'll connect more with Product and Engineering directors to see if there is agreement on that approach.
@kostajh - what are your thoughts on that approach?

I would also suggest that we add another variation, which is to disallow temp accounts from using Flow as well. The reason for doing that is to avoid needing further work in related tooling that hooks into Flow changes (especially anti-abuse tooling).

I updated the description to allow for other approaches including what you suggest.

Based on recent community conversations, in which there is general acceptance or support for deprecating Flow, and seeing how limited the usage of Flow is currently, I personally think we should align the Flow deprecation with the rollout of Temporary accounts.

In other words, rather than any remediation work on Flow to accommodate IP Masking, we instead invest in sunsetting the feature. Perhaps the freezing of Flow boards can be one step in that process. Clearly the Temporary accounts project is the higher priority, so we would need to ensure the Flow deprecation work aligned with the Temporary accounts timeline.

That being said, I don't think I'm the final decision maker here, so I'll connect more with Product and Engineering directors to see if there is agreement on that approach.
@kostajh - what are your thoughts on that approach?

Freezing the Flow boards seems like the easiest option, if communities are OK with that. $wgFlowReadOnly still allows for deleting/undeleting content, though, and that might be an issue in this scenario:

  1. Flow boards are in read-only mode
  2. Temp accounts feature is enabled
  3. Admin deletes an older post from an IP actor

At that point, I think we would encounter an error (T349219: [M] Investigate: Which workflows create an IP actor?). I don't have an idea at the moment on how to deal with that.

$wgFlowReadOnly still allows for deleting/undeleting content

That would be fairly trivial to disable presumably. With enough warning, we could lock down that feature too. In exceptional cases staff could delete content.