As a user, I want to enable the anti-theft deterrent (aka kill switch) during the first run experience. Note - As anti-theft is predicated on having a FxA account, the user will need to be prompted to create an account if the user does not have one already

Is this must-have since for RedTai we have partner to customize the UI?

it is a must have for redTai

I'm not sure where this will fit in the flow. Is it something that we want enabled in or builds? Or behind a setting to toggle it? Flagging Tiffany for UX input

Just to clarify, I am assuming that this would be an opt-in to Find My Device as opposed to a specific 'kill switch' opt-in? During the sign in flow for Firefox Accounts, we can add a opt-in check box for FMD. However, the create account flow currently requires the user to confirm their email address before they can enable FMD. Is this something we need to work around or if the user is creating an account, they can just enable FMD in settings instead? Vishy do you have any insight on this?

(In reply to jsavory from comment #4) > Just to clarify, I am assuming that this would be an opt-in to Find My > Device as opposed to a specific 'kill switch' opt-in? Yes, this is an opt-in for Find My Device, with additional copy around FMD being an anti-theft deterrent. I would not use the term "kill-switch" > > During the sign in flow for Firefox Accounts, we can add a opt-in check box > for FMD. However, the create account flow currently requires the user to > confirm their email address before they can enable FMD. Is this something we > need to work around or if the user is creating an account, they can just > enable FMD in settings instead? Vishy do you have any insight on this? Is there a better option to what we have? (ask user to create FxA and then wait on email verification). One option I can think off is when the user signs in (at a later time after email verification) to remind the user to enable FMD

My guess is that asking the user to wait on an email verification to create an account would be too much of a barrier to entry. We could have a notification reminder after the user confirms their email address after FTE though. ni? on John for insight on the UX of Firefox Accounts, as this bug is more of a Firefox accounts flow. John - what are your thoughts on including an opt-in/out box during FxA sign up and creation as well as the notification afterwards?

Hi Gregor, For KillSwitch, we need eng to take charge the FTU changes. Do you know who can do that before mid-Dec?

(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #7) > Hi Gregor, > For KillSwitch, we need eng to take charge the FTU changes. > Do you know who can do that before mid-Dec? We need ready to go UX specs before we can start working on this from engineering. Please ping us again once this is all ready. Should this only land on the 2.2r branch? Whats the story on master?

(In reply to Gregor Wagner [:gwagner] from comment #8) > (In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #7) > > Hi Gregor, > > For KillSwitch, we need eng to take charge the FTU changes. > > Do you know who can do that before mid-Dec? > > We need ready to go UX specs before we can start working on this from > engineering. Please ping us again once this is all ready. > Should this only land on the 2.2r branch? Whats the story on master? Quick answer to this: yes, 2.2R. Michael knows more about the plan on master.

2.2R or Master? The last I heard, code to support Red Tai (e.g. KS) should land on 2.2R. At some point in the future some code will uplifted from 2.2R to Master. First Time Experience my change in 2.5 or later releases, so I think it makes sense to keep the Red Tai FTE on 2.2R.

Is there a reason why we wouldn't want this on master for smartphones? Or just that it hasn't been scoped & designed yet? 2.2R and master's FTE will probably diverge significantly in the coming dev cycle as I plan to tackle bug 1036697 and a broader refactoring (possibly NGA implementation) of FTU app.

(In reply to Michael:mtreese from comment #10) > 2.2R or Master? The last I heard, code to support Red Tai (e.g. KS) should > land on 2.2R. At some point in the future some code will uplifted from 2.2R > to Master. First Time Experience my change in 2.5 or later releases, so I > think it makes sense to keep the Red Tai FTE on 2.2R. FYI I have landed all my KillSwitch Gecko/Gaia changes on both. Specifically because of what Sam just said.

KS will be required for all US phones in the future, that is, KS will need to be on Master when there is a 2.5 or later US phone. Except for the additional maintenance, AFAIK it should not be a problem to land KS FTE on both 2.2R and Master.

KS feature required for 2.6

Flagging for ux wanted, we can make a plan to implement once its clear what it will be.

Re-adding NI for John. I believe he would be the one to help with designs or point you to someone from account that can.