Ready for review: https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/536730

Acceptance Criteria:

• If a user attempts to enter information in one field (i.e. username or email address) rather than both fields when the password reset preference is enabled for the associated account, a message should appear at the top of the page: "Both username and email address are required to receive a temporary password via email."

This is correct.

• There should be a required indicator on the right of both the input fields

These do not appear. There isn't any indication on the fields themselves. @ifried Is this ok?

• Once the user has successfully entered both a username and email address, they should be redirected to the message view, regardless of whether the information submitted is correct

If the username is incorrect, you are told (There is no user by the name "blah"...). If the username is correct but email incorrect, you are redirected to the success message but no password reset email is sent.

Regarding the new option in Special:Preferences:

• When a user has the option unchecked, that user can have their password reset with only a username, email or both.
• When a user has the option checked, that user can only have their password reset with both a username and email or just an email.

The same applies whether you are logged in as the same user you want to reset the password for (not sure why you would do this), a different user or not logged in at all.

If you don't have an email for the account, the checkbox is disabled (cannot be checked).

Testing was done on beta and my local machine. I don't believe this has been enabled on production.

@MaxSem Thanks for your work on this! I just have one question. The following criteria was not implemented: "There should be a required indicator on the right of both the input fields." Is this because it is technically infeasible?

@MaxSem @dom_walden I just tested this on https://en.wikipedia.beta.wmflabs.org/. It appears that the message is displayed if someone just enters a username (correct behavior). However, if someone just enters the email address, the message is not displayed (incorrect behavior). Rather, they are directed to the next screen (see below), which says, "If this email address is associated with your account, then a password reset email will be sent."

In T232512#5624890, @ifried wrote:

@MaxSem @dom_walden I just tested this on https://en.wikipedia.beta.wmflabs.org/. It appears that the message is displayed if someone just enters a username (correct behavior). However, if someone just enters the email address, the message is not displayed (incorrect behavior). Rather, they are directed to the next screen (see below), which says, "If this email address is associated with your account, then a password reset email will be sent."

I think somewhere between this task and T234401 something fell between the cracks.

I think if we show the validation message when just entering an email this potentially allows bad actors to find out the email addresses of users with PRU enabled. If the bad actor enters an email address and they see the validation message, they know some user must be using that email address. To prevent this it would have to behave the same way for all emails (regardless of whether they exist or have PRU enabled or not), by redirecting to the next screen as if it had sent a password reset.

@dom_walden is spot-on I think. The behavior he describes is definitely what we talked about but maybe it got mixed up somewhere.

@dom_walden @aezell @MaxSem

For the password reset project, we want to prioritize the experience of good faith actors over bad faith actors. We don't want to unnecessarily frustrate or confuse users who are simply trying to reset their password. Furthermore, according to the ticket requirements, any email address should direct users to the next screen (not just the email address associated with the username), so we're not actually informing harassers of the correct email address. This is the basis for the third point in the Acceptance Criteria: "Once the user has successfully entered both a username and email address, they should be redirected to the message view, regardless of whether the information submitted is correct."

We discussed this behavior in a previous team meeting, though Dom may not have been present at that meeting (and, if so, I'm sorry for not reaching out to share this information with you!).

To illustrate why this decision was made, let's take a look at this example: I decide to enable the Password Reset Update preference, and then I have minimal account activity. Two years later, I decide that I want to be active on a wiki again, but I've forgotten my password. So, I go to Special:PasswordReset to reset my password. I don't remember my username, so I enter my email address. This would normally be fine, but there's one problem... I have forgotten that I enabled the Password Reset Update preference. For this reason, no email is sent. Of course, I could then go rummage through my email and try to find my old username, but I could have grown discouraged, forgetful, or bored before that occurred. In this scenario, we could be preventing users from contributing to our projects.

For this reason, we decided to prioritize good faith actors over bad faith actors (whenever we need to choose between the two) for this project. This decision was made after lots of discussion, which included Danny, Prateek, and others. Thus, the first two points of the acceptance criteria are meant to address good faith actors, and the third point is meant to address bad faith actors. Let me know your thoughts. Thanks!

That works for me. It's about degrees of risk here. If we feel that prioritizing it as you've described is acceptable level of risk, then I think that's fine. There is no risk-free option except to completely remove the feature so managing the risk with clear eyes is the best approach to me.

@aezell Yup, I completely agree that it's about degrees of risk⁠—and neither option is perfect, unfortunately. With the option that I'm proposing, there is certainly a small risk, in that we're giving harassers more information (i.e., letting them know the rules for resetting the password). However, I think there's a bigger risk in confusing good faith actors. In particular, I don't want to compromise the main purpose of Special:PasswordReset, which is to provide an easy way for users to access their accounts & keep contributing to our projects.

For this reason, I'm moving this ticket back into QA. And, @dom_walden or @MaxSem, feel free to reach out if you have any more thoughts/questions following this discussion. Thank you!

Update: We are currently discussing the next steps as a team. We'll update this ticket when we have a plan.