Add additional emails (Phase 1)

[rfk]

adavis writes
Feature document being written here:
https://docs.google.com/document/d/1DOUWRbxU8ah6AL3gUTrlYKFY42jt_czOHbu4wL4E-sc/edit#

[vladikoff]

from mtg:

• count bounces, how many people we are losing due to unknown accounts after reset password? (might be a good thing for flowEvents)
• Ryan Feeley says it is a basic feature we should have.
• Secondary email address? Backup email address?
• Or have an experience to explain how to migrate data - "recreate a new account, resync".
• if Auth or Confirm Signin bounces, do we give the user to recreate a new account.

[vladikoff]

Some notes on this here: https://bugzilla.mozilla.org/show_bug.cgi?id=1334107

[davismtl]

Updated first post of feature card to add feature document in progress.

[davismtl]

from mtg:

• change email or add email? Add is first logical step.
• If you lose access, you are locked out.
• If you change your email, will it become available for others to use? Not in early phases. Need to figure out security implications.

Summary
Phase 1:

• Allow to add a backup email (and confirm it)
• Notify primary email that a secondary email has been added
• Only allow to change email with a verified session (Please login from a Firefox browser)
• Allow to delete backup email
• Blast login confirmation to both emails
  @ryanfeeley to start user flow diagrams and wireframes and will add to feature document

Phase 2:

• User can login with either email
• Only blast primary and display a message on confirmation screen

Phase 3:

• Allow to change primary email (and delete primary)

Phase 4

• Communicate this feature to the masses as a security check / enhancement

TBD

• Add multiple backup emails

[davismtl]

I updated the feature document with the above notes.
@ryanfeeley Please add mockups and flow diagrams to the document.

[ryanfeeley]

@davismtl Working on this now. It appears as though "recovery email" as a term is growing in popularity. https://trends.google.com/trends/explore?q=recovery%20email,secondary%20email,backup%20email

How should we validate the clearest term for this given that users who reset their password will reset their data with or without a recovery email?

[davismtl]

@ryanfeeley Yeah, recovery email might not be best since it won't really allow you to recover your data if you forgot your password. It will prevent you from losing access to your account if you are locked out of your primary email account.

I looked at my Google Account to see what they use. I see the following:

Alternative emails seems to be relevant. They define it like this:

Though, the definition seems quite similar to that of their Recovery email :-/

It feels like a combination of the two of them.

Other email addresses that you can use to sign in to your account and in case you have lost access to your primary email account. This address is also where Firefox can contact you if there's unusual activity in your account.

Thoughts?

[ryanfeeley]

@davismtl I'm leaning toward "secondary" because the feature adds redundancy to sign-in confirmations, but the label doesn't make any implicit promises. So far I'm here with the UX. I need to add the middle states (likely in modals).


[davismtl]

@ryanfeeley
My only concern with this design is that it limits someone to adding only 1 extra email. Engineering said there would not be much difference between adding 1 email vs allowing a user to add multiple emails. (and we talked about adding that ability)

Can we have a design that provides flexibility to allow to add multiple emails in a future phase?

That being said, then the word secondary doesn't make much sense if a user can add multiple emails.

[davismtl]

from mtg:

• vijay and vlad have started to break out the issues
• @ryanfeeley to review UI/UX. (reminder, relook at LinkedIn UI)

[davismtl]

from mtg:

• @ryanfeeley added mockups to the feature doc
• needs to create modal mockups
• will maybe add (primary email) text
• will maybe put a place holder for changing primary email (coming soon/ under construction)
  • might be a good signal for measuring the number of users that want to change their primary
• will determine if we want to limit on the backend to just 1 secondary email
• security emails sent out to both
• password reset will only be available to primary email in phase 1
  • We need to explore implication of allowing it for secondary email. We would prefer to first master changing primary email.

[davismtl]

from mtg:

• lot's of reviews done
• server side and db side are almost ready
• @ryanfeeley will propose new copy for this
• action item schedule a meeting to go through an edge case that has security implications

[davismtl]

from mtg:

• database side is done and merging in 83
• auth-server changes are landing in 84
• Copy change for blue buttons. (add email)
• @vbudhram @ryanfeeley and @davismtl to talk this afternoon

[davismtl]

from mtg:

• we discussed edge cases:
  • password reset emails will be sent to primary and secondary email
• auth-server changes are still landing in 84 (off by default via feature flag)

[davismtl]

from mtg:

• merging auth server in train 85

[davismtl]

@vbudhram was the merging of auth server in train 85 the last part to getting phase 1 out?

[davismtl]

Has the feature doc been copied over to Github yet? If so, where can we can find it? @ckarlof was looking for it.

[rfk]

Has the feature doc been copied over to Github yet?

I don't think so, and I think we need to find a better system for managing that. I'm thinking about e.g. a "sync_feature_docs.js" script that will just crawl the feature cards, find the corresponding feature-docs, export them to markdown, and make sure what's in github is up-to-date.

[davismtl]

from mtg:

• auth server has a few more merges to land
• deployed a test environment: https://emails3.dev.lcip.org/
• to get ready for QA by Wednesday

[rfk]

FYI, at :ckarlof's suggestion, I have reached out to :ulfr and :pauljt from the security team to do a review of this and subsequent phases of the feature. I'm confident we've done a good job of the various security edge-cases, but for something this central it seems worth getting some extra input on that front.

[rfk]

• QA is looking at the dev box right now \o/
• @rfk and Julie to sync up on security-review stuff
• Open question re: what happens when you initiate pasword reset from your secondary email
  • decision: no, for now this will give an error, but we may revisit in next iteration.

[davismtl]

from mtg:

• QA looked at it. Kanchan wrote a great summary. Result: Green light
• 2 bugs: 1 is resolved, the other was unrelated
• content server unit tests and functional tests are ready to ship
• security reviewed our logic and it seems ok
• can we enable this for mozilla emails only for a stage rollout? Yes...
• security requested logic diagrams. @vbudhram will file bug to do that.
• we have no concerns for rate limiting since our current rate limiting will kick in.
• we may ask softvision to do another QA run when it's in stage
• have it pref'd on in 87 for softvision

[davismtl]

FEATURE CARD MOVED TO NEW PRODUCT BOARD. ADD NEW COMMENTS HERE:

https://projects.growthhackers.com/s2/Jrhe3MU7hhqwkWOgS3SP9Q

[brianking]

That growthhackers link is broken. Is there somewhere public we can still follow along with the progress of this?

[davismtl]

@brianking , that card is no longer available because the feature is released. You can visit this address to add an email to your account via Firefox:
https://accounts.firefox.com/settings/emails?service=sync

For users who don't use Sync but rather only use FxA via reliers like Addons.Mozilla.org, we are currently slowly rolling out a fix to make it possible to add/change email:
https://projects.growthhackers.com/cards/verify-session-in-settings/HPwwNCs385RkSqQMbrWMdg

On the topic of changing primary emails, you can now also do that too now (although behind a feature flag):
https://support.mozilla.org/en-US/kb/change-primary-email-address-firefox-accounts

Hope this helps