Page MenuHomePhabricator

Create an API for sending yourself an arbitrary HTML email
Open, MediumPublic

Description

There is a need for external tools in our ecosystem to send user-friendly emails to their users (such as notifications or reports). Using a MediaWiki API via OAuth would be the optimal solution for two reasons:

  • It would avoid exposing the email address to the tool. While OAuth provides a simple and reasonably transparent way of exposing email addresses, most tools are probably not prepared to handling them securely, handling email address changes (e.g. re-fetching the address every time before using it) complicates the code, and handling personal information might have legal compliance implications. Also, users might be unwilling to trust tools with their email address, and we might want to avoid acculturating users to giving out their email address easily.
  • Using an API is much easier for a simple client than setting up email sending (especially decent email sending, with SPF records and such), so this way the wiki could shoulder the burden of operating the mail sending infrastructure. And probably the wiki domain is trusted more by email clients (especially when using professional commercial mass mailing services is not an option, e.g. due to data protection concerns) so the emails will work better (in terms of e.g. not being marked as spam).

Email sending is already possible via ApiEmailUser and the sendemail grant, but that is limited to fairly dumb text-based emails, which might have been acceptable in the 1990s, but not so much today.

Potential concerns:

  • Spam is the usual concern with emails; since the API would only be usable to send emails to users who accepted the OAuth grant, it would be less of a concern, but probably some mechanism would still be required to ensure users can identify where the email comes from and easily unsubscribe. (In some areas this might be a legal requirement as well.) Could happen via List-Unsubscribe, or a forced footer.
  • Phishing (and general confusion about who is sending the email) is a risk, even via a somewhat trusted service that needs opt-in from the user, in particular because the email is coming from the wiki operator. Maybe it can be mitigated by choosing the sender name or subject prefix well, or by forcing some boilerplate header / footer.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

This seems reasonably easy to do as a volunteer project, but it would be great to have feedback (especially from Security) on whether it is a viable idea or the risk of phishing or other misuse is too high.

Anomie added a subscriber: Anomie.

Personally I find the justifications here rather unconvincing. But I'll leave the decision to PM-types.

most tools are probably not prepared to handling them securely, handling email address changes (e.g. re-fetching the address every time before using it) complicates the code, and handling personal information might have legal compliance implications

Generally I'd say the tool shouldn't be storing the email address at all. When it needs to send an email, it should fetch the address and send the mail at that time rather than trying to store it.

Also, users might be unwilling to trust tools with their email address,

Then they shouldn't authorize the tool to have the email address, and live with the lack of whatever report the tool wants to send. T59505: Allow more flexibility in what permissions are authorized seems potentially relevant here.

and we might want to avoid acculturating users to giving out their email address easily.

I think that level of social engineering isn't something we should be getting into.

Using an API is much easier for a simple client than setting up email sending (especially decent email sending, with SPF records and such), so this way the wiki could shoulder the burden of operating the mail sending infrastructure. And probably the wiki domain is trusted more by email clients (especially when using professional commercial mass mailing services is not an option, e.g. due to data protection concerns) so the emails will work better (in terms of e.g. not being marked as spam).

Most hosting providers and ISPs include such infrastructure, as far as I know. Including Toolforge. If someone is in a situation where none of that applies, they're likely also responsible for every other aspect of systems administration as well.

Email sending is already possible via ApiEmailUser and the sendemail grant, but that is limited to fairly dumb text-based emails, which might have been acceptable in the 1990s, but not so much today.

First, I'd say that using that via OAuth to send a report to the user is probably a misuse of the functionality. The tool should probably be using its own account to hit ApiEmailUser to send a message to the user, rather than using the user's account to send a message to that user.

I'd also question whether text-based email is actually not acceptable for a report. But that's a question of style over substance, and I lean heavily to the "substance" side.

chasemp added a subscriber: chasemp.

Follow up with a Security-Team concept review when you are ready for more input. thanks!