Page MenuHomePhabricator

If a user has never triggered a logged action on a wiki, they should not be able receive emails by non-privileged users from there
Closed, ResolvedPublic3 Estimated Story Points

Description

Documentation


Background & Current Functionality

Wikimedia accounts use unified login across all wikis. If a user never visits a wiki, then they do not technically have an account created, therefore the 'Email this user' link is not visible on their userpage and Special:EmailUser will not accept their username as valid. However, when a user visits a page on another Wikimedia wiki while logged-in (via on-wiki or off-wiki link, Google search, or direct navigation) the system 'creates' their account on that wiki, and they can therefore be contacted via email.

For example:

  • User:Apples created their account on English Wikipedia, has confirmed their email address and uses the default user preferences. They have never visited Japanese Wikipedia (intentionally or unintentionally.) If User:Bananas (a user with a confirmed email address) visits Special:EmailUser/Apples on Japanese Wikipedia, the website will show the account as invalid and Bananas will not be able to email Apples.
  • User:Carrots created their account on English Wikipedia, has confirmed their email address and uses the default user preferences. While logged in, they followed a link from a Google search to Wikiquote. If User:Durian visits Special:EmailUser/Carrots on Wikiquote, the website will show the account as valid and Durian will be able to email Carrots.

Acceptance Criteria

  • If a user has never edited or triggered a logged action AND they did not create their account on that wiki, they should not be able receive Special:EmailUser emails sent from that wiki.
  • Users in the groups bureaucrat, steward, wmf-supportsafety, and global-renamer should still have the ability to send email to these users.
    • This should be a new right assigned to these groups.
  • If a user is not in the specified groups, the 'Email this user' link in the side navigation of a user page should not appear
  • If a user is not in the specified groups, navigating directly to Special:EmailUser/Foobar should display an error message
    • If the user does not have a confirmed email or is anonymous: display the standard "No send address" error page
    • If the user has a confirmed email address and is not a bcrat/steward/wmf-susa/global-renamed: display a new error message in this style.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
TBolliger added a subscriber: SPoore.

I updated the task with a pretty significant change that @SPoore and I discussed today. Please let us know your thoughts. We believe that if a user creates an account on a wiki, they should still be able to receive emails even if they have never edited.

Wouldn't it be a better idea to include all logged actions than to just evaluate edits?

I would agree with this in theory — but other than 'Thanks' for logged actions can non-autoconfirmed users do?

If a user has never edited AND they did not create their account on that wiki, they should not be able receive Special:EmailUser emails sent from that wiki.

Just to clarify: You talk about the one-time, active account creation and not about unintentional local account creations while visiting other wikis?

Wouldn't it be a better idea to include all logged actions than to just evaluate edits?

I would agree with this in theory — but other than 'Thanks' for logged actions can non-autoconfirmed users do?

The only other options for logged actions by non-autoconfirmed users in practice are changetags, createaccount, and possibly more in non-WMF wikis. This way, you also make sure users can be contacted in their home wiki no matter if they have edited there, if you check the createaccount log without introducing some new mechanics. Furthermore, deletions and blocks by global sysops in wikis they have never edited. are a possibility

Just to clarify: You talk about the one-time, active account creation and not about unintentional local account creations while visiting other wikis?

Yes.

Wouldn't it be a better idea to include all logged actions than to just evaluate edits?

I would agree with this in theory — but other than 'Thanks' for logged actions can non-autoconfirmed users do?

The only other options for logged actions by non-autoconfirmed users in practice are changetags, createaccount, and possibly more in non-WMF wikis. This way, you also make sure users can be contacted in their home wiki no matter if they have edited there, if you check the createaccount log without introducing some new mechanics. Furthermore, deletions and blocks by global sysops in wikis they have never edited. are a possibility

Right. Good call. I'll update the ticket to reflect this. From an discussion point of view, I'll keep it as "never edited" for sake of simplicity.

TBolliger renamed this task from If a user has never edited on a wiki where they did not create their account, they should not be able receive emails sent from that wiki, except from a few usergroups to If a user has never edited or triggered a logged action on a wiki where they did not create their account, they should not be able receive emails sent from that wiki, except from a few usergroups.Nov 1 2017, 6:59 PM
TBolliger updated the task description. (Show Details)

I propose to rename that to "If a user has never triggered a logged action on a wiki, they should not be able receive emails by non-privileged users from there." The title is getting out of hand ^^

MGChecker renamed this task from If a user has never edited or triggered a logged action on a wiki where they did not create their account, they should not be able receive emails sent from that wiki, except from a few usergroups to If a user has never triggered a logged action on a wiki, they should not be able receive emails by non-privileged users from there.Nov 1 2017, 8:15 PM

@TBolliger Just to clarify, we are not only looking at edit count, but any other logged action?

Correct, all logged actions.

Pageviews are not logged, correct?

Pageviews are not logged, correct?

That appears to be correct.

@TBolliger I don't understand the usefullness of this feature:

User:Apples created their account on English Wikipedia, has confirmed their email address and uses the default user preferences. They have never visited Japanese Wikipedia (intentionally or unintentionally.) If User:Bananas (a user with a confirmed email address) visits Special:EmailUser/Apples on Japanese Wikipedia, the website will show the account as invalid and Bananas will not be able to email Apples.

If User:Apples hasn't added User:Bannanas to a blocklist on English Wikipedia, then User:Bananas can just go to English Wikipedia and email User:Apples.

It seems like a better solution would be to just make the blocklist global?

@dbarratt — This ticket is meant to solve two things: 1) sockpuppets sending emails on other wikis & 2) reduce the labor required to set email preferences on all wikis.

A global email blacklist would solve #2 but not #1.

@dbarratt — This ticket is meant to solve two things: 1) sockpuppets sending emails on other wikis & 2) reduce the labor required to set email preferences on all wikis.

A global email blacklist would solve #2 but not #1.

This issue wouldn't solve #1 anyways because a socket puppet could just email User:Apples on English Wikipedia.... or am I missing something?

Thus T138165: Allow users to restrict which user groups that can send them direct emails via Special:EmailUser. All these preferences – prohibit, autoconfirmed tickbox, 0-edits — have minorly different use cases, but the core importance is that we want users to allow constructive emails while walling-off unwanted emails.

I'll state publicly here (as I have elsewhere) that I think the per-wiki preferences configuration is incredibly unintuitive and archaic. I acknowledge there is logic and legacy rationale behind it, but I think it's a inherently flawed system if we have unified login. At the same time, I think it will be a thankless, Sisyphean effort to gain consensus, design, build, test, and release a more intuitive global preferences solution.

We still have T167902: Build a unified, cross-wiki Mute feature for multiple types of on-wiki and email communication on our backlog, which would be an avenue for us to address cross-wiki preferences just for communications preferences.

@TBolliger ok, so, just to clarify, this feature is obsolete when T167902 is implemented? If that's the case, then I'll add a note in the code that it's a stop-gap measure that will be resolved with T167902.

@TBolliger ok, so, just to clarify, this feature is obsolete when T167902 is implemented? If that's the case, then I'll add a note in the code that it's a stop-gap measure that will be resolved with T167902.

T167902 is not prioritized, and I would not assume we will ever build it. If we do, it'll be 2019 at the earliest.

Build the fix for this ticket to last.

T167902 is not prioritized, and I would not assume we will ever build it. If we do, it'll be 2019 at the earliest.

Build the fix for this ticket to last.

Well I guess technically MediaWiki-extensions-GlobalPreferences would also render this feature obsolete.

That would solve it, but my concern is it is designed for power users and adds an extra level of complexity to preferences.

Some extra commentary on why we're building a few smaller changes: there are several ways users can receive unwanted emails:

  • On a wiki where they edit vs. a wiki where they do not edit
  • From a specific known user vs. a horde of sockpuppets
  • Direct email from Special:EmailUser vs. emails sent from Echo notifications

I made this chart on meta to show how each of these are addressed by our features.

Change 391751 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Prevent new users from being sent emails

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

@TBolliger

Users in the groups bureaucrat, steward, wmf-supportsafety, and global-renamer should still have the ability to send email to these users.

I added the new user right to bureaucrat since that is built into MediaWiki, the other roles: steward, wmf-supportsafety, and global-renamer will need to be added in a SWAT deploy. I think we should do this before the train rolls out so when it does the users in these groups will automatically have the proper permissions.

@TBolliger

Users in the groups bureaucrat, steward, wmf-supportsafety, and global-renamer should still have the ability to send email to these users.

I added the new user right to bureaucrat since that is built into MediaWiki, the other roles: steward, wmf-supportsafety, and global-renamer will need to be added in a SWAT deploy. I think we should do this before the train rolls out so when it does the users in these groups will automatically have the proper permissions.

I believe those groups only exist on Meta Wiki.

Sounds good.

I believe those groups only exist on Meta Wiki.

uhh... that means only bureaucrat on all other wikis will be able to email new users on their wikis. Is this the expected behavior?

I believe those groups only exist on Meta Wiki.

uhh... that means only bureaucrat on all other wikis will be able to email new users on their wikis. Is this the expected behavior?

Correct. This is expected behavior.

We can expand this in the future if needed.

As stewards are a global group (too), it will be no problem to assign it to them for all wikis.

How about Send email to users with no logged actions

If we want to update the 'sendemail' description, we could update it to Send email to other users with logged actions

How about Send email to users with no logged actions

Done.

If we want to update the 'sendemail' description, we could update it to Send email to other users with logged actions

Uhh... I don't have a preference, what do you think @dmaza?

Let's not overcomplicate this. Let's leave the existing description as-is.

My comment from Gerrit:

Technical comments aside, lots of users just make edits and their first logged actions come much later in their wiki careers. You'll be effectively blocking sending them emails, which is not good. I suggest you to use other criteria such as autoconfirmed status.

My comment from Gerrit:

Technical comments aside, lots of users just make edits and their first logged actions come much later in their wiki careers. You'll be effectively blocking sending them emails, which is not good. I suggest you to use other criteria such as autoconfirmed status.

I agree, which is why this barrier is editing OR logging, not editing AND logging or just logging by itself. The first acceptance criteria reads as such:

If a user has never edited or triggered a logged action AND they did not create their account on that wiki, they should not be able receive Special:EmailUser emails sent from that wiki.

Is this not how the feature is programmed to work?

If a user has never edited or triggered a logged action AND they did not create their account on that wiki, they should not be able receive Special:EmailUser emails sent from that wiki.

Is this not how the feature is programmed to work?

After taking a quick look at the patch: At the moment, it only analyzes the logging table.

If a user has never edited or triggered a logged action AND they did not create their account on that wiki, they should not be able receive Special:EmailUser emails sent from that wiki.

Is this not how the feature is programmed to work?

After taking a quick look at the patch: At the moment, it only analyzes the logging table.

if (
	$target->getEditCount() === 0
	&& ( $sender === null || !$sender->isAllowed( 'sendemail-new-users' ) )
) {
	// Determine if target has any other logged actions.
	$db = wfGetDB( DB_REPLICA );
	$log_id = $db->selectField(
		'logging',
		'log_id',
		[
			'log_user = ' . $target->getId(),
			'NOT (log_type = "newusers" AND log_action = "autocreate")',
		],
		__METHOD__,
		[ 'LIMIT' => 1 ]
	);

	if ( !$log_id ) {
		wfDebug( "User has no logged actions on this wiki.\n" );

		return 'nowikiemail';
	}
}

Yes, this is an OR.
If the user you are emailing ($target) has an edit (getEditCount()), they will bypass this completely.
If the user does not have an edit, we query the database to see if they have any logged actions. If the query returns no rows (false) then we know they have no logged actions and we throw an error, otherwise we continue to the end of the method which allows the user to send an email.

To put it another way:
If the user you are sending an email to has 0 edits AND 0 logged actions, you may not send an email to them.

Which is the same as:
If the user you are sending an email to has at least 1 edit OR at least 1 logged action, you may send an email to them.

To put it another way:
If the user you are sending an email to has 0 edits AND 0 logged actions, you may not send an email to them.

Which is the same as:
If the user you are sending an email to has at least 1 edit OR at least 1 logged actions, you may send an email to them.

Thank you David. This is the expected behavior.

Sorry, I missed that line.

No worries! :)

@TBolliger FYI we're going to give all authenticated users this permission with the feature change (since they already have permission now), then we'll update the permissions for WMF in a SWAT deploy.

@TBolliger FYI we're going to give all authenticated users this permission with the feature change (since they already have permission now), then we'll update the permissions for WMF in a SWAT deploy.

Change 391751 merged by jenkins-bot:
[mediawiki/core@master] Prevent new users from being sent emails

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

dbarratt moved this task from Review to Done on the Anti-Harassment (AHT Sprint 11) board.

@TBolliger I created T182541 to update the permissions on WMF wikis, please prioritize appropriately.

It's fine if this goes out without the permissions update, basically no functionality will change until we update the permissions.

Quick question, how would this affect global userpages of stewards and etc? For example, say a steward has global profile. On that global profile they say "you can contact me via email if it is a private matter". Now say there's a wiki that they haven't edited on, and there's a user on that wiki who needs to contact said steward. They now are no longer able contact the steward on that wiki because said steward has made no edits on that wiki?

Quick question, how would this affect global userpages of stewards and etc? For example, say a steward has global profile. On that global profile they say "you can contact me via email if it is a private matter". Now say there's a wiki that they haven't edited on, and there's a user on that wiki who needs to contact said steward. They now are no longer able contact the steward on that wiki because said steward has made no edits on that wiki?

Correct, the user will no longer be able to email the steward via email on that wiki. This is already true on wikis where stewards have never visited.

Wouldn't that create issues tho, since the user kinda needs to contact
the steward?

Wouldn't that create issues tho, since the user kinda needs to contact the steward?

Potentially, but this could be alleviated by the stewards updating their global userpage to direct people to Special:EmailUser on Meta Wiki, or via IRC or talk page.

If this becomes a major problem we could build an except for this new feature just for stewards, but seeing as they do not have profiles on wikis where they have never visited I can't imagine this will be any different. Still, it's possible to fix if need be.

Noting in passing that this disabled the ability of enwiki users to email role accounts (User:Oversight and similar) which are expressly intended to receive emails only. Seems to me that the much better solution would have been to allow people to stop bot emails at their global preferences, or to select wikis from which they receive emails at the same point. This created unnecessary distress as people could not submit suppression requests.

We solved the problem by having the role account make an edit. That should not have been necessary - the entire purpose of the role account was that it would never edit, only receive emails.

Noting in passing that this disabled the ability of enwiki users to email role accounts (User:Oversight and similar) which are expressly intended to receive emails only. Seems to me that the much better solution would have been to allow people to stop bot emails at their global preferences, or to select wikis from which they receive emails at the same point. This created unnecessary distress as people could not submit suppression requests.

We solved the problem by having the role account make an edit. That should not have been necessary - the entire purpose of the role account was that it would never edit, only receive emails.

This is tracked at T184207: Role accounts unable to receive email.

We will be rolling this back in T184470.

This was initially supposed to be a quick preventative solution to potential email harassment, but the workarounds (software and social) are piling up. Global Preferences will make it easier to manage email preferences across wikis.

<soapbox>Global Preferences is a step in the right direction but I still believe there is more we (Anti-Harassment Tools and Wikimedians in general) can do to make communication preferences more straightforward and understandable. I want us to think how we can allow users to proactively set sane limits on who can communicate with them off-wiki, rather than letting people disable preferences after unwanted or harassing emails have been received.. </soapbox>