On 1/2/17 08:12, Ryan Feeley wrote:
> 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)
Without wanting to get too carried away, are there other email-related
settings we might like to include in the design here? I know we've
already got "Communication Preferences", and we've talked about giving
users the ability to opt in to an always getting sign-in confirmation
emails.
Cramming a bunch of vaguely-related "email settings" into a single
settings panel doesn't sound awesome, but just want to sanity-check in
context of broader plans.
> 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?)
Indeed, if you add a recovery email, then you can access a users account
if you (a) know their password, and (b) can read any one of the linked
email accounts.
I don't think it *doubles* the risk - after all, you still have to know
the account password. But it certainly expands it some non-zero amount.
It feels like an OK tradeoff to me on balance.
Cheers,
Ryan
> On Tue, Jan 31, 2017 at 11:36 AM, Richard Newman <rnew...@mozilla.com
> <mailto:rnew...@mozilla.com>> 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"
> <rfke...@mozilla.com <mailto:rfke...@mozilla.com>> 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
> <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
> <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
>
> <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
> <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 list
> Dev-fxacct@mozilla.org <mailto:Dev-fxacct@mozilla.org>
> https://mail.mozilla.org/listinfo/dev-fxacct
> <https://mail.mozilla.org/listinfo/dev-fxacct>
>
>
> _______________________________________________
> Dev-fxacct mailing list
> Dev-fxacct@mozilla.org <mailto:Dev-fxacct@mozilla.org>
> https://mail.mozilla.org/listinfo/dev-fxacct
> <https://mail.mozilla.org/listinfo/dev-fxacct>
>
>
_______________________________________________
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct
