The change email feature as originally designed would be helpful for retaining users who know to change their email address before it is too late.
I took a stab at fitting my proposed design into the new accordion sections here: https://irccloud.mozilla.com/file/YDaId9S5/change-email.png (when in pending state, the new change email section would be hidden, the pending message would persist) This does not help users who have lost access to their email and realize it too late. Letting users add "recovery" emails during registration might do that, but I am unclear how this would work without doubling the risk associated with a Sync account (two emails, means double the access points, no?) On Tue, Jan 31, 2017 at 11:36 AM, Richard Newman <[email protected]> wrote: > I think it's worth outlining some properties of the system in this > possible new world. > > Some ideas/questions for discussion: > > - The old email address never becomes available for registration again. > That is, email -> FxA user never changes from one user to another. > - Can multiple email addresses be associate with an account? If so, can > more than one of them be 'live'? > - If so, is the state of adding a new email address and disabling logins > and confirmation emails to the old one — so nobody with possession of the > old email mailbox can log in — sufficiently equivalent to changing your > email address? > > I think UX-wise we've been moving more towards name + avatar than showing > your email, so with the exception of Android accounts, it might be enough > to simply loosen the association between email and account. > > > > > On Mon, Jan 30, 2017 at 11:05 PM -0800, "Ryan Kelly" <[email protected]> > wrote: > > Hi All, >> >> >> One of the items on our Q1 OKR list is: >> >> "Enable users to add a second email and change their primary" >> >> This is an item that we've talked about a lot in the past, but never >> really dug into moving on. Let's pick up the thread and try to scope >> out what we can realistically achieve on this in Q1. >> >> I'm sure we've had a long rambling discussion about this topic on the >> list in the past, but be damned if I can find it. Does anyone happen to >> have a reference to it in their mail history? >> >> In the meantime, some high-level scoping questions, mostly for :rfeeley >> and :adavis but naturally feel free to chime in: >> >> * How will we measure the success of this feature? Is it simply based >> on the rate at which people add/change emails, or do we expect it to >> show up in other metrics e.g. a decrease in bounce rate? >> >> * What UX will we expose to the user here? Will we e.g. expose the >> ability to have multiple email addresses, or keep that hidden as >> an implementation detail? >> >> * How will we secure this feature? If the user has lost access to the >> email associated with their account, does allowing them to change it >> violate the security properties of e.g. sign-in confirmation? Or will >> send a confirmation email to the *original* email address as well? >> >> >> Also, some links to previous bugs on this topic, for reference: >> >> * An old, long, rambling bug on implementation approach: >> https://github.com/mozilla/fxa-auth-server/issues/957 >> >> * Some notes on why this might be tricky on Android: >> https://bugzilla.mozilla.org/show_bug.cgi?id=1173566 >> >> * Some prior UX from :rfeeley: >> https://www.lucidchart.com/documents/view/9c9a4647-615f-4b7c-a4db-71ae10afcd04 >> >> * A new user request for this feature: >> https://bugzilla.mozilla.org/show_bug.cgi?id=1334107 >> >> This is very much still in the scoping phase, so any and all comments >> welcome. >> >> >> Cheers, >> >> Ryan >> _______________________________________________ >> Dev-fxacct mailing >> [email protected]https://mail.mozilla.org/listinfo/dev-fxacct >> >> > _______________________________________________ > Dev-fxacct mailing list > [email protected] > https://mail.mozilla.org/listinfo/dev-fxacct > >
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
