Web: Site-Wide Email Verification (Security Enhancement)

[androolloyd]

Who

Any user of the Gitcoin platform

What

When a user creates or updates their profile, their email needs to be verified.

Why

The current system has no verification check in place to ensure the user making this change has access to the submitted email. This change will prevent users from being able to impersonate another users/or non users email.

In the case of email delivery, for non transactional emails(newsletters), users must double opt in under GPDR legislation, before you can deliver emails to them.

To enable this change the following updates are required:

• A Banner displaying at the top of the site, alerting to users that their email has not been verified
• A system to invalidate email verification tokens
• a system of checks to ensure GDPR Compliance requirements
• Impersonation prevention(checks to ensure the emails being requested aren't in use), otherwise Barrack Obama could be getting Gitcoin emails without consent
• Bounty invites
• Tips
• A system to manage emails added to the Gitcoin system, something along the lines of how Facebook does it, where emails you add are still associated with your account until you remove them, letting a user have multiple emails associated, active, pending, or otherwise
• Suggest adding a new model that handles emails specifically and normalize any database fields that leverage email(active, pending style system)
  
  
  
  • Updates to any DB queries that are users based on email column will need to be modified to leverage the new model and ensure that they are based on active addresses
  
  

[owocki]

in the case of emails weve received from the github API, are those not already verified?

[androolloyd]

In some instances they can be, however, for newsletters a double opt in is still required, as well as when users are updating their email preferences, they will have to verify that email change as well.

I raised this exact question when talking to @danlipert about this functionality, as you have to verify the email at some point after creating a GitHub account(but note, I believe you can create a Gitcoin account with a non verified GitHub account)

[androolloyd]

Minimum Viable Approach: Size 8

Banner displaying at the top of the page when a new email is pending verification
Create and Store a verification token with a 12-24 hour expiration

Validate the token via a new route: => /user/email/verify/:token

Double opt solution for any emails that leverage user data to generate, newsletters, even if email is verified

• first consent is opting inside the app
• second consent is clicking a link inside the verification email
• second consent opt in can happen as apart of the verification email as long as the content of the email is adequately framed to indicate what the consent is doing
  
  
  
  • user updates email settings and opts into newsletters for example
    
    Update all email fields with the new email when it has been verified (for transactional emails)
    
    Update db queries that lookup users by their email(tips, bounties, etc) to ensure verified accounts are getting emails, and they have opted into receiving emails about bounties
  
  

[androolloyd]

Transaction Emails vs Marketing Emails:
Transactional emails as long as they are limited in scope and don't contain any marketing content are exempt from double opt in

An example of what CAN NOT be done:

Hi, thanks and welcome to Gitcoin, based on your preferences ..........

The above could however be sent after garnering double-opt in for providing users network updates based on their profile settings.

5 Questions to Ask yourself Before You Send Transactional Email
Before you send any transactional email to EU citizens, ask yourself these five questions:

1) Does my customer really need this email?

Whether you're sending transactional email or not, it's always a good idea to stop and ask yourself if your customer really needs the email. If the answer is "no", then think twice before you send it.

2) Does the transactional email contain marketing content?

The differences between marketing and transactional emails are very clear. However, the lines become blurry when you begin to add marketing content into your transactional emails. If you're sending transactional email to EU citizens, then you should avoid mixing any marketing content into your transactional emails.

3) Should I give my customers an unsubscribe option?

While an unsubscribe link is required for marketing emails, it's not required for transactional email. This is because it usually doesn't make sense to provide an unsubscribe link in a transactional message. However, that doesn't mean that you shouldn't use one.

If you're uncomfortable with adding an unsubscribe link to your transactional email, consider adding an Email Preference Center. This way, you can give your EU citizens a way to opt-out of certain transactional emails that may not truly be necessary.

4) Do I have a privacy policy?

You can use your Privacy Policy to explain why your EU citizens are receiving transactional email that they didn't explicitly consent to receive. It's also a good idea to include a Privacy Policy in the footer of your email.

5) Will my customers understand why they are receiving this email?

Finally, the email footer is a great place to explain to recipients why they are receiving your transactional emails.

A good footer explanation might read something like this:

"This email was sent to {{[email protected]}}. This is a required notice about {{insert reason}}; it is not a marketing or promotional email. That is why this email does not contain an unsubscribe link and why you are receiving this email even though you may have unsubscribed from our marketing emails."

Adding a simple message like this at the bottom of your email may help prevent confusion, especially in situations when EU customers already unsubscribed from your marketing messages.(https://www.mailjet.com/gdpr/consent/)

[danlipert]

@androolloyd this is a really great writeup, glad to have you help us to navigate GDPR and such - @frankchen07 what do you think about getting this in the roadmap in the next couple of sprints?

[frankchen07]

@danlipert & @androolloyd, thanks for bringing this up. I've added it to the sprint page, and will be discussing shortly where it fits in on the roadmap.

Seeing as it's GDPR related, I'm thinking the consequences are high if we're not doing it right?

[androolloyd]

They can be difficult to deal with yes: https://www.gdpreu.org/compliance/fines-and-penalties/

[ririen]

First of all, there are also a few technical issues to consider when implementing this.

Many mailboxes use aliases, for example gmail considers dotted and non-dotted email addresses as the same. There are also several other flavors in which Google has a strange policy.

• john.[email protected]
• jo.hn.sm.[email protected]

• j.o.h.n.s.m.i.t.[email protected]

• john.[email protected]

• john.[email protected]
• john.[email protected]

All of them lead to one mailbox, while Internet systems treat them as different when registering and entering data.

Google is no exception, there are many other mail portals that offer aliases. So you need to think about the following solutions:

1. With the confirmation message, you must specifically inform about which email address the message was sent to, and tell the user to check whether this address has been entered in the settings. Otherwise, there will be confirmation of fake accounts by real people who do not realize that someone in the settings gave an alias to their email address.

2. After verifying your email address via the link, never add an automatic account login. Otherwise, an unauthorized person can access the data using aliases.

   – This is generally a specific matter. It would be best to encompass all aliases and treat them as 1 email address during verification, however, even you cannot systemically comprehend all the different mailboxes.