Sounds like a technical proposal lacking a social conversation.

One would think that such a ticket is doomed to fail with a lack of
reasoning to what is the problem being solved.

I cannot see the WMF community accepting such a proposal, and suggest that
it be declined at this point.

Keep in mind that mediawiki is not dictated by the WMF sites. Just because a particular community chooses not to use part of the software doesn't mean that the software shouldn't be available to other sites. (I am thinking specifically for non-WMF sites that require email addresses during account creation.)

In T117801#1783835, @Billinghurst wrote:

Sounds like a technical proposal lacking a social conversation.

One would think that such a ticket is doomed to fail with a lack of
reasoning to what is the problem being solved.

I cannot see the WMF community accepting such a proposal, and suggest that
it be declined at this point.

I agree. This seems like the sort of thing that would need some sort of discussion somewhere (meta?) to verify that the community feels that disclosure of this sort of information to checkusers is justified.

In T117801#1783850, @Bawolff wrote:

In T117801#1783835, @Billinghurst wrote:

Sounds like a technical proposal lacking a social conversation.

One would think that such a ticket is doomed to fail with a lack of
reasoning to what is the problem being solved.

I cannot see the WMF community accepting such a proposal, and suggest that
it be declined at this point.

I agree. This seems like the sort of thing that would need some sort of discussion somewhere (meta?) to verify that the community feels that disclosure of this sort of information to checkusers is justified.

So we have a setting in the checkuser extension that disables displaying it by default. Doesn't mean that third parties who have their own communities should be denied the ability to use if it they choose.

So we have a setting in the checkuser extension that disables displaying it by default. Doesn't mean that third parties who have their own communities should be denied the ability to use if it they choose.

phab doesn't have any collision detection. I wrote my comment before I saw yours about wanting it for third parties not wmf. I don't have any particular objection about it being an option, although I'll note that the bug is more likely to be fixed if you go in detail about your usecase.

Not a problem, I am in the process of moderating/moving users from a phpBB site to a mediawiki site with significantly more functionality. I first noticed that phpBB has email based checkuser like ability, which can be leveraged effectively to stop spammers and vandals. I also saw a recent post at https://en.wikipedia.org/w/index.php?title=Wikipedia:Bureaucrats'_noticeboard&oldid=689080570#Compromised_accounts where users may have an email address on file, but have user to user email disabled. In the case where email is set, but not enabled CheckUsers would have the ability to look up an address in a worst case scenario. Anyone with DB access can also do it, but its much more complex.

I am aware of the related case, and believe that the exposure of email addresses lessens security through mediawiki rather than enhances it, irrespective of whether it is WMF internal or not. The WMF espouses security and privacy, so adding email addresses to the product output should always be challenged as it opens up greater chance of compromising accounts, not less.

Wouldn't a separate extension be better for that addition to CU function? One that could be separately queried and utilised on a more minimal basis rather than bundling into checkuser? I don't see how exposing an email address to checkuser is the answer. I have done significant number of checkusers over the years, and one for one email addresses per check is not required for >> 99.9% of cases, so I see it as overexposing email addresses, especially when there is no guarantee of secure use.

There is the ability through abuse filter to check whether an account is email confirmed or not, and maybe that is something that could be considered in this situation rather than populating an email address.

I would much rather see a scoped argument and use case than a wishful statement.

In T117801#1783844, @Betacommand wrote:

Keep in mind that mediawiki is not dictated by the WMF sites. Just because a particular community chooses not to use part of the software doesn't mean that the software shouldn't be available to other sites. (I am thinking specifically for non-WMF sites that require email addresses during account creation.)

Yes, and if the process as outlined at https://www.mediawiki.org/wiki/How_to_report_a_bug is utilised then 1) there is no opportunity for confusion, and 2) the strengths and weaknesses of the proposal can be understood.

An alternative to exposing the users email address is to expose a hash of the user's email address in a similar way to how the recipient and content of an email are hashed or allow CUs to run a check on an account for other accounts with the same email address. This access should be logged and also should not be automatic (i.e. it's a new checktype or an extra button to be pressed).

Personally I prefer my second idea, but how to implement that is less clear. I was thinking adding a new checktype for things like comparing email addresses may be an idea. This could later be expanded to more than just comparing email addresses, but at first would just be email addresses. The account would only show if the email was an exact match.

This could also be a separate extension, but IMO it does make sense to include this in CheckUser.

I don't really see a reason why CheckUsers need to have access to the email address directly. CheckUsers cannot change the email address and being able to read the email directly doesn't seem to be enough of a reason IMO to make this needed. Personally I would not support revealing the email address of a user outright, though if this was an opt-in config that could be possible.