Page MenuHomePhabricator

Allow users to restrict who can send them direct emails via Special:EmailUser
Closed, ResolvedPublic8 Story Points

Description

Description
If a user has verified their email address on Wikimedia, by default the preference to receive emails from other users is enabled. While this can be a productive tool to communicate it is also a big vector for harassment because this communication is not transparent and available on wiki for administrator's to witness.

The current preference is all or nothing — either all users can send emails, or no users can send emails. As a target of harassment, I want to prevent certain users from sending me email.

Scenario
User:Apples mutes User:Bananas

Acceptance criteria

  • On the 'User profile' tab of Special:Preferences, under the 'Email options' section a box similar to the Echo Mute box should appear, allowing users to prevent other users from sending them direct emails
  • Final copy:
    • Label: Prohibit these users from sending me direct email
    • Hint text: Add more...
  • Update the copy of MediaWiki:allowemail to: Allow other users to email me directly
  • This first version will be a local Mute list only
  • Bananas should not see the "Email this user" link in the left rail on User:Apples or other userspace pages
  • If Bananas directly navigates to Special:EmailUser/Apples they should see the standard error message of "This user has chosen not to receive email from other users" as if Apples had the entire preference disabled:
  • The muting should still work even if the muted user changes their username. See T173475.

Details

Related Objects

Event Timeline

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

More as a reminder for when the documentation page gets written for this after implementation than anything more urguent, but it might be worthwhile to note that there are ways a restricted user can find out they are specifically restricted, including (but not necessarily limited to):

  • sockpuppet accounts
  • {{you've got mail}} and similar messages on user talk pages
  • the restricting user asking third parties to email them
TBolliger updated the task description. (Show Details)Aug 23 2017, 6:51 PM
kaldari updated the task description. (Show Details)Aug 23 2017, 7:01 PM
This comment was removed by TBolliger.
dbarratt set the point value for this task to 8.Aug 24 2017, 6:32 PM

@dmaza and I decided to make this an 8. We can re-evaluate when there's a UI plan.

👍

We'll work on the UI on Monday. I predict a liberal use of the <marquee> tag.

The muting should still work even if the muted user changes their username. See T173475.

Now we've finally reached a level where treating this as an security bug becomes laughable…

Restricted Application added a subscriber: jeblad. · View Herald TranscriptAug 25 2017, 1:17 PM
dbarratt claimed this task.Aug 25 2017, 1:17 PM

Change 374361 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Allow users to restrict who can send them direct emails via Special:EmailUser

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

Ugh.. I tried to do a squash merge and that didn't work. :(

TheDJ added a subscriber: TheDJ.EditedAug 29 2017, 8:33 AM

Some points regarding this change. I think it is a very good improvement however... Special:EmailUser was also used as an indicator by experienced users who tried to help users who lost their passwd to check if the user in question had a verified email configured and would thus be able to receive password reset emails.

  1. I don't think that this is going to be problematic and I guess with the acceptance criteria as defined, you could still figure that out from going to Special:EmailUser/Name directly.
  2. Maybe we should have that specific information discoverable somewhere else ?
  3. "This user has chosen not to receive email from other users" is a level of information disclosure about who you have blocked and can easily be bypassed by having a (disclosed or not) alternative account. It might be wiser, to just present the form to send an email and only upon submit, have it bounce. That makes it harder for the sender to figure out if they have been muted, which might be safer for the receiver.

Another feature idea:
Make it possible to block mail from entire usergroups.

Anomie added a subscriber: Anomie.Aug 29 2017, 2:01 PM

More as a reminder for when the documentation page gets written for this after implementation than anything more urguent, but it might be worthwhile to note that there are ways a restricted user can find out they are specifically restricted, including (but not necessarily limited to):

  • sockpuppet accounts
  • {{you've got mail}} and similar messages on user talk pages
  • the restricting user asking third parties to email them
  • Just look at the output of API action=query&list=users&usprop=emailable&ususers=...
  • Just look at the output of API action=query&list=users&usprop=emailable&ususers=...

Example:
https://meta.wikimedia.org/w/api.php?action=query&list=users&usprop=emailable&ususers=DBarratt%20(WMF)

I thought the response was broken, but that's apparently the format per T29881: the 'emailable' property (from API) should be true or false (currently empty string or undefined)

"This user has chosen not to receive email from other users" is a level of information disclosure about who you have blocked and can easily be bypassed by having a (disclosed or not) alternative account. It might be wiser, to just present the form to send an email and only upon submit, have it bounce. That makes it harder for the sender to figure out if they have been muted, which might be safer for the receiver.
Another feature idea:
Make it possible to block mail from entire usergroups.

True, it would be possible for a malicious user to use a sock to circumvent this Mute list. T138165: Allow users to restrict which user groups that can send them direct emails via Special:EmailUser will prevent some sock email harassment. We've also considered a whitelist, but don't yet have a tracking ticket.

As for the question of showing the email form at Sp:EmailUser or not — there are valid arguments for both designs. I have a slight preference to not show the form at all — the error message already exists and is common for users who do not want any email at all. This also will also help users from posting the "you've got mail" template on the other's talk page and situations of "hy didn't you respond to my email?"

Happy to hear other opinions on the "show the form + bounce the email" vs "hide the form".

I thought the response was broken, but that's apparently the format per T29881: the 'emailable' property (from API) should be true or false (currently empty string or undefined)

Side note, use formatversion=2 to get actual booleans in JSON format. That's not the default for historical reasons.

dbarratt added a comment.EditedAug 30 2017, 2:54 PM

@TBolliger Just to confirm, we are making a new tab for this field correct?

TBolliger added a comment.EditedAug 30 2017, 5:07 PM

@dbarratt — yes, a new tab. I will create another ticket for the next sprint to polish up the UI.

Edit: I updated T174606: Move Echo Notification Mute & Special:EmailUser Prohibit to new Prohibit/Mute tab, update copy, add links on other tabs to reflect these desired changes

I should probably add a config variable for this like echo.

dbarratt added a comment.EditedSep 1 2017, 3:58 PM

@Anomie How do you feel about just adding a new method to CentralIdLookup since what we are doing here is almost exactly the same as T173475?
Something like

$nameToId = array_fill_keys( array_flip( $names ), false );
$ids = array_filter( $this->lookupUserNames( $nameToId, $audience ), function ( $id ) {
    return $id !== false;
} );

return array_values( array_unique( $ids ) );

?

Anomie added a comment.Sep 1 2017, 4:27 PM

You'd probably want two methods, one for names to IDs and one for IDs to names.

I don't have any really compelling reason to object, but I do note that you'd need to come up with distinctive names for the new methods so it doesn't wind up confusing to others looking at the class in the future.

@kaldari Your code review would be much appreciated. :)

dbarratt added a subscriber: Samwilson.

Based on the conversation with @kaldari and @Samwilson we'll add the blacklist to the existing email section. If we want to move it to a new tab, we can have that discussion in T174606: Move Echo Notification Mute & Special:EmailUser Prohibit to new Prohibit/Mute tab, update copy, add links on other tabs.

@TBolliger Only question left is whether to show the field all the time or only show it if email is enabled. It is possible to do this right now, but it doesn't change the form until you click "Save". T174606 would make it happen immediately, but @kaldari mentioned that most people will not be enabling email and then immediately looking for how to block people.

TBolliger added a comment.EditedSep 7 2017, 5:43 PM

Based on the conversation with @kaldari and @Samwilson we'll add the blacklist to the existing email section. If we want to move it to a new tab, we can have that discussion in T174606: Move Echo Notification Mute & Special:EmailUser Prohibit to new Prohibit/Mute tab, update copy, add links on other tabs.
@TBolliger Only question left is whether to show the field all the time or only show it if email is enabled. It is possible to do this right now, but it doesn't change the form until you click "Save". T174606 would make it happen immediately, but @kaldari mentioned that most people will not be enabling email and then immediately looking for how to block people.

OK, I agree with this. Let's get it out and examine if we should move them to another tab. I'll update T174606 to reflect this.

I agree with @kaldari — Safe to assume that 99.99% of the time this will be a reactive preference, not proactive. Let's have the list appear only if the allowemail preference is enabled. The list can display when a page refresh occurs.

Can you please send a screenshot of what the UI looks like, just to make sure all the copy works well together?

Change 374361 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Allow users to restrict who can send them direct emails via Special:EmailUser

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

Change 374361 merged by jenkins-bot:
[mediawiki/core@master] Allow users to restrict who can send them direct emails via Special:EmailUser

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

dbarratt closed this task as Resolved.Sep 14 2017, 4:22 AM

@TBolliger This is done and it looks like will be in the September 19th deploy. After that we can enable it on Meta.

We're not aware of any reason (social or technical) that we shouldn't enable this on all Wikimedia wikis, once T173475: Echo Notification Mute (Block List) can be bypassed by changing username and T176365: Update Email Mute copy have been resolved.

Any concerns?

We're not aware of any reason (social or technical) that we shouldn't enable this on all Wikimedia wikis, once T173475: Echo Notification Mute (Block List) can be bypassed by changing username and T176365: Update Email Mute copy have been resolved.
Any concerns?

@TBolliger enabling this feature on all wikis is not blocked by T173475: Echo Notification Mute (Block List) can be bypassed by changing username since that is not a bug of this feature, only Echo notifications.