When the user activates the "Kill-Switch" mode from the website, the device should be locked with the user's FxA password instead of the 4 digit pin.

This is going to impact lockscreen ?

Current LockScreen can't use any real password except the 4 digit pin, according to it's functions and UX design. I think this is also related to the plan about using complicated password instead the current simple passcode, which also impacts keyboard + system, too. Since you need a real keyboard to type such password. For that part, we have had some immature studies about keyboard + lockscreen, and there were some demos in my recollection. However, it needs an overview to see how to make it works under the current architecture. If you have any ideas please CC Tim (keyboard) and me.

Any way we can make this happen soon ? Kill switch is a priority feature.

The most easy way (without digging into the current architecture) is FMD team write a special iframe as a very simple LockScreen. And control it totally without using the current code path, like with a new KillSwitchManager and KillSwitchWindow. In this way, we can make sure such requirement could be satisfied with the most isolated way known by FMD team. And for LockScreen part, you just need to disable it at the moment "Kill-Switch" mode launched, and this simple locker could takeover all of the protection logic. The risk is there are some potential racing about LockScreen and KillSwitch at the moment of enabling or disabling them, but that's what I have now. NI Tim and John to leave more opinions.

I have no opinion on how we implement this (other than obvious basic pattern requirements).

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #4) > The most easy way (without digging into the current architecture) is FMD > team write a special iframe as a very simple LockScreen. And control it > totally without using the current code path, like with a new > KillSwitchManager and KillSwitchWindow. In this way, we can make sure such > requirement could be satisfied with the most isolated way known by FMD team. > > And for LockScreen part, you just need to disable it at the moment > "Kill-Switch" mode launched, and this simple locker could takeover all of > the protection logic. > > The risk is there are some potential racing about LockScreen and KillSwitch > at the moment of enabling or disabling them, but that's what I have now. > > NI Tim and John to leave more opinions. Is there any documentation available for this, or does it basically means we have to completely swap the lockscreen with a killswitch-specific one without proper Gaia-level support for changeable Lockscreen?

We had done a similar feature at 2.0 for Madai by our partner according to my similar suggestion. Basically it's just a window beneath the LockScreen window, and controlled by another manager just like other kinds of window in System app. And your "proper Gaia-level support for changeable Lockscreen" never exists (yet). That's why I suggested you avoid to dig in it if you only just want to provide a new security screen with keyboard, which seems available via creating an simple iframe and an input field to invoke keyboard. To implement this in the current LockScreen, you may encounter complicated panel transitioning and racing issues, and you must align the current fake keypad with the real keyboard for UX consistent. I don't say it's impossible, I just respond your comment about how important this feature is, and therefore we should reduce the risks and implement that with a clear way without workaround with legacy code. And the unfortunate truth is LockScreen currently holds too much irrelevant features and components inside it. This, pluses the legacy code, ridiculous integration tests, and those urgent feature requests during each releases, even I already have some overall plans for re-organizing that and have implemented it experimentally, for this basically always one-man team it's still in very slow progress. So unless your change is only about one "widget" (ex: clock or music player) on LockScreen, to change any panel-level things would be risky.

So, you have some example to share ...

I can find an architecture diagram and maybe the bug for you (if it's not confidential; I'm not sure now) tomorrow morning.

(In reply to Alexandre LISSY :gerard-majax from comment #6) > (In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #4) > > The most easy way (without digging into the current architecture) is FMD > > team write a special iframe as a very simple LockScreen. And control it > > totally without using the current code path, like with a new > > KillSwitchManager and KillSwitchWindow. In this way, we can make sure such > > requirement could be satisfied with the most isolated way known by FMD team. > > > > And for LockScreen part, you just need to disable it at the moment > > "Kill-Switch" mode launched, and this simple locker could takeover all of > > the protection logic. > > > > The risk is there are some potential racing about LockScreen and KillSwitch > > at the moment of enabling or disabling them, but that's what I have now. Agree the risk existing. > > > > NI Tim and John to leave more opinions. > > Is there any documentation available for this, or does it basically means we > have to completely swap the lockscreen with a killswitch-specific one > without proper Gaia-level support for changeable Lockscreen? I cannot provide more information on this topic since TV doesn't have Lockscreen. We had removed it. I believe the whole window manager depends on it.

Well, since now you're one of System owners and have some plans for Window Manager, it would be my failure to not info you about such possible changes.

And NI Frederik: if your plan to use all same passcode helper and hashing function conflicts with such "second" password of whole device? Since in the discussions of Bug 1176180, you mentioned that your design is for a universal password for whole device, so the helper no need to adapt different passcodes from different sources.

Alexandre: unfortunately the bug is confidential (Bug 1016182). I don't know if you can view it. Anyway, I attach the architecture diagram link here: https://docs.google.com/drawings/d/116q-56lDNe3TI3UCc7rN-iaoqcgWiwo-7I1MkLjqALo/edit?usp=sharing However, it's not clear for this bug. So I just made another architecture proposal for this bug specifically: https://docs.google.com/drawings/d/1ur-5nx-gAtT9BXufz2czjV91yjJSxU1GQCtK8gopa6M/edit?usp=sharing And if you're interested in how many states the current LockScreen needs to maintain, here is the diagram (not fully covered): https://docs.google.com/drawings/d/1G9t2K4g2RbK7cYGMxDl7xJbFb0WPdK5KF-nS9KZ1e4k/edit?usp=sharing

I do have access to bug 1016182. Thanks.

I suggest we tackle this from a different angle. FindMyDevice's current remote-lock features sets a new passcode. Is the killswitch supposed to be a change for the remote lock to use a passphrase instead of a 4 digit code? Doing this would be very easy because the PasscodeHelper architecture that is on its way to master (bug 1123325) allows setting a string as passcode. It can be 4 digits, but it could also be a strong passphrase. We woul also have to surface this in the UI of lockscreen and settings, e.g., by exposing a toggle that sets lockscreen.passcode.type to "full" (in contrast to undefined or "digits"). If this is set, the lockscreen could show a full keyboard instead of a numpad. Looks a lot cleaner to me and would bring us support for strong passphrasses and improves FxOS security in general.

(In reply to Frederik Braun [:freddyb] from comment #15) > I suggest we tackle this from a different angle. > > FindMyDevice's current remote-lock features sets a new passcode. Is the > killswitch supposed to be a change for the remote lock to use a passphrase > instead of a 4 digit code? Doing this would be very easy because the > PasscodeHelper architecture that is on its way to master (bug 1123325) > allows setting a string as passcode. It can be 4 digits, but it could also > be a strong passphrase. The current information we have is that this should be the Firefox Accounts password. Which makes me raising two questions: - would it be considered as "strong enough" ? - is it even a good idea from a security point of view to store such kind of credential locally? I personnaly don't think so.

I agree that it would be wiser to push a more secure one-time password to the device than the account password for FxA. In any case, if we built upon the PasscodeHelper in shared/passcode_helper.js (which I *strongly* recommend), it will be stored as a hash (PBKDF2, 1000 rounds, random salt, …)

(In reply to vkrishnamoorthy@mozilla.com [:Vishy] from comment #0) > When the user activates the "Kill-Switch" mode from the website, the device > should be locked with the user's FxA password instead of the 4 digit pin. This doesn't seem like a high priority use case to me, so Im guessing this is a partner request. But I've been pushing for full password support (as opposed to passcode) since pre-basecamp, so it would be great time to solve that if we going to support locking. Either way we will need a way to enter the password to unlock the device, so perhaps we can finally solve bug 877541 as part of this bug?

This is a product requirement as the 4 digit pin is not strong enough a deterrent if the phone is stolen. The nuance here is that 1) In the normal mode the phone is locked with a 4 digit pin. 2) When the device is stolen (or lost) the user initiates "Kill-Switch mode" from the service (find.firefox.com) 2.a) Device now requires the FxA password to unlock the device 3) User recovers the device and unlocks it with FxA password 3.a) Kill-switch mode is disabled and phone is back to normal mode 3.b) Lockscreen is now protected with 4 digit pin As part of this feature, we could also revisit bug 877541

> If this is set, the lockscreen could show a full keyboard instead of a numpad. If we do this while remaining both passcode and password, namely both keypad and keyboard at the same LockScreen state machine, it would be the most difficult part to handle them perfectly. That's the reason why I mentioned to separate these two different panels in a totally different path at Comment 13. I think Bug 877541 is more complicated than this. It asks current LockScreen to migrate to a new password mechanism with full keyboard supports, while this bug only asks to show such panel + keyboard at a very specific scenario. The difference is, for the first bug we have no chance to avoid the risks I've mentioned, from the requirements to rewire some new state managements into the current codebase, while for the second one we can create a simpler screen for it, and thus there is no need to handle the old-new styles and code migration issues. So I think for 2.5, it's safer to only take care the requirement of this bug, and I, or any other people interested in, continue the work for the migration for Bug 877541.

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #20) > > If this is set, the lockscreen could show a full keyboard instead of a numpad. > > If we do this while remaining both passcode and password, namely both keypad > and keyboard at the same LockScreen state machine, it would be the most > difficult part to handle them perfectly. That's the reason why I mentioned > to separate these two different panels in a totally different path at > Comment 13. I was thinking we would just override the PIN with a long password and not have them work in parallel. But you're right; In parallel sounds really tricky to be squeezed into 2.5. @Vishy: I do not think we have even access to the FxA password. It is never meant to be stored in the clear (security best practices violation) on either the device or the FxA/FMD server. A one-time password sounds like the best solution.

(In reply to Frederik Braun [:freddyb] from comment #21) > (In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #20) > > > If this is set, the lockscreen could show a full keyboard instead of a numpad. > > > > If we do this while remaining both passcode and password, namely both keypad > > and keyboard at the same LockScreen state machine, it would be the most > > difficult part to handle them perfectly. That's the reason why I mentioned > > to separate these two different panels in a totally different path at > > Comment 13. > > I was thinking we would just override the PIN with a long password and not > have them work in parallel. But you're right; In parallel sounds really > tricky to be squeezed into 2.5. > > > @Vishy: > I do not think we have even access to the FxA password. It is never meant to > be stored in the clear (security best practices violation) on either the > device or the FxA/FMD server. A one-time password sounds like the best > solution. My initial thought was for the lockscreen to verify the FxA password with the FxA server using the existing flow. But OTP sounds like a good option ni:jrconlin to weigh in from a server perspective

Honestly, I was kinda wondering how we'd do this. The user password should only ever live (or really, even processed) on a FxA box. I figured that we would kick the user to FxA, have them log in, and then process the assertion to verify that the logged in user was the same as the owner of the device. This is how we're doing the First Time User login and linking to Find My Device This would require an active network connection, obviously. In a closed system, it might be possible to create a hashing mechanism that would take the user email and password, do various mathy thing to them and compare the hashes against an FxA provided value, but that's also fraught with security issues. The Find My Device server absolutely has no password information on it at all, or ever.

(In reply to JR Conlin [:jrconlin,:jconlin] from comment #23) > Honestly, I was kinda wondering how we'd do this. > > The user password should only ever live (or really, even processed) on a FxA > box. I figured that we would kick the user to FxA, have them log in, and > then process the assertion to verify that the logged in user was the same as > the owner of the device. This is how we're doing the First Time User login > and linking to Find My Device This would require an active network > connection, obviously. Yeah, that would work. Except that you'd be locked out of your device if you are offline. Especially since you can not make it go online without unlocking ;-) jrconlin, What do you think about one time passwords?

True, if you're in a radio dead zone, you couldn't unlock your phone. Granted, if your phone was already in a radio dead zone, you'd have a pretty hard time remotely locking your phone as well. But, let's presume that your phone was stolen by a yeti and you've climbed the side of Everest that doesn't have coverage to reclaim it. You pick up the phone, but need to unlock it to tell your loved ones you'd like yellow flowers on the casket because the yeti just showed up at the mouth of the cave. Sadly, you're still out of luck because, well, no coverage, and you're still tastier than your phone was. For what it's worth, I'm generally against things like one time passwords because they increase the number of ways that bad people can do bad things to your account. Yes, I'm paranoid, but I've got lots of historical proof for why it's a bad idea. If we limit to just unlocking the local device while out of network contact, we're talking about an unlock PIN (albeit perhaps a bit different or longer than normal) similar to what the user enters now, correct? Why not just do that? (Yes, a user could have "1111" as their pin and enter "111111" as their lost mode lock code. Feel free to use other well known patterns. If you want to assign the user something nice and high security like "$g0\jOH#^?1$Al4YBs7N" I so want to see you type that in correctly into a password field with a phone keyboard.)

(In reply to JR Conlin [:jrconlin,:jconlin] from comment #25) > True, if you're in a radio dead zone, you couldn't unlock your phone. Fair enough ;) > For what it's worth, I'm generally against things like one time passwords > because they increase the number of ways that bad people can do bad things > to your account. Yes, I'm paranoid, but I've got lots of historical proof > for why it's a bad idea. Just to clarify...if we want the user to go through Firefox Accounts on this remote-lock lockscreen, I would be heavily against OTP for FxA. I do not want to open a second door to FxA. What I thought was that FxA could just push an OTP to the device that it's going to require for the next unlock. I'd be indeed interested to get to know your side of why one time passwords are a bad idea, but this said, I am not heavily opposed to require an authentication with the FxA server once the device has been remotely unlocked. (P.S.: I, myself, have a very long and horrible-to-type FxA password and am OK with this, since I only need to use it rarely. I think the more often we require the user to type it, the less likely is it that users will choose a strong password.)

Ok, now I need help. This lockscreen stuff is not making any progress. I need a solution at least for demo purpose. Right now, I'm just forcing the current lockscreen to be locked but with the Passcode Helper introduced in bug 1100945 I'm wondering: how can I set the passcode value in setting from Gecko ? Yes, I need to do all in Gecko from a security feedback.

If you're asking about strong passcode I'm afraid I can't help, since I only know how to set passcode in mozSettings. But I don't know how to and what it means to set passcode "in Gecko". You may need to ask Frederick. And if you're asking how to implement the UI component, I want to know if you consider the propose I've commented? It will really simplify the patch, and prevent possible regressions.

https://hg.mozilla.org/try/rev/55177806c639#l4.75 This is what I mean, by "in Gecko". Frederic is on PTO until September 4th. And no, I won't do the lockscreen, I already have much than enough on my place.

Without any description in text, I could only guess you want to set the "new" (strong) password to replace the passcode at line 78? If so, you could try to set new password via PasscodeHelper.setPasscode: https://github.com/mozfreddyb/gaia/blob/123f83ce7ae176b61c89c11862d9001d97daeb9b/shared/js/passcode_helper.js#L63

(In reply to [OFF 20/08-26/08] Alexandre LISSY :gerard-majax from comment #27) > Ok, now I need help. This lockscreen stuff is not making any progress. I > need a solution at least for demo purpose. Right now, I'm just forcing the > current lockscreen to be locked but with the Passcode Helper introduced in > bug 1100945 I'm wondering: how can I set the passcode value in setting from > Gecko ? > > Yes, I need to do all in Gecko from a security feedback. For demo purposes, can we just use pincode?

(In reply to [OFF 20/08-26/08] Alexandre LISSY :gerard-majax from comment #27) > Ok, now I need help. This lockscreen stuff is not making any progress. I > need a solution at least for demo purpose. Right now, I'm just forcing the > current lockscreen to be locked but with the Passcode Helper introduced in > bug 1100945 I'm wondering: how can I set the passcode value in setting from > Gecko ? > > Yes, I need to do all in Gecko from a security feedback. I totally misunderstood your comment sorry. I _think_ you set a setting in Gecko like this: https://mxr.mozilla.org/mozilla-central/source/b2g/components/PaymentProviderStrategy.js#79 22 XPCOMUtils.defineLazyServiceGetter(this, "gSettingsService", 23 "@mozilla.org/settingsService;1", 24 "nsISettingsService"); ... 79 gSettingsService.createLock().set(kRilDefaultPaymentServiceId, 80 serviceId, 0); Maybe you knew that already. The more difficult part will be that after the passcode_helper landed, the passcode is no longer stored in cleartext (which is a good thing!). Instead a salted digest is stored. If you want to set the passcode in gecko, you will need to do the same thing that Gaia does, which is outlined here: https://github.com/mozilla-b2g/gaia/blob/master/shared/js/passcode_helper.js#L49 You could just copy the code, but to use WebCrypto (which passcode helper uses to calculate the hash), you need a window object. In another bug, I have seen this used in Gecko like this: let browserWindow = Services.wm.getMostRecentWindow("navigator:browser"); let crypto = browserWindow.crypto; Hopefully that will all you need to implement - sorry for the braindump!

Just a note that if we do just rely on the passcode we need to fix bug 1181571.

Just got confirmation that the original requirement (on requiring FxA) stands and passcode is not sufficient.

Vishy: would a 6 or 8-digit pin satisfy our partner's requirements here? Greg: How hard would it be to modify the lockscreen to use a 6 or 8-digit PIN when the kill switch had been activated? Alexandre: can the FMD website push the unlock code to the device when the kill switch is activated, and also tell the user what the unlock code both when they lock the phone and later when the log in after finding it? I know that jrconlin said he didn't want to use a one-time password, but given the time contraints, I'm afraid that going with a longer pin might be the best we can do here.

If we don't need to launch a real keyboard, but just make the pin code longer, it will be much easier to implement. But I still need to know how much UI need to be changed besides that, since there are no UI spec or draft in this bug yet.

(In reply to David Flanagan [:djf] from comment #35) > > Alexandre: can the FMD website push the unlock code to the device when the > kill switch is activated, and also tell the user what the unlock code both > when they lock the phone and later when the log in after finding it? > > I know that jrconlin said he didn't want to use a one-time password, but > given the time contraints, I'm afraid that going with a longer pin might be > the best we can do here. I can't tell, I don't know anything about the website. What I can tell for sure is that it means we need to modify the API I just landed ...

The pull request attached above by autolander adds a setPinLength() function to apps/system/lockscreen/js/lockscreen_inputpad.js. This screenshot shows what it looks like when accepting a 6-digit pin. This patch is only a proof-of-concept showing that longer pins are possible without much disruption to the lockscreen app. I assume that when the killswitch is activated, something is going to be set in the settings db. At the same time we can set a longer unlock pin in the settings db as well. If that is done, then we can modify the lockscreen to listen to those killswitch settings. When set, the lockscreen can use the setPinLength() function defined here to change to a longer pin. And when the killswitch setting is cleared because the user has entered the longer pin, then we can call setPinLength() again to revert to the normal 4-digit pin.

Comment on attachment 8655130 [details] [gaia] davidflanagan:variable-length-lockscreen-pin > mozilla-b2g:master Greg: does this patch look reasonable to you? It doesn't have tests yet, but I tried to keep it minimal and clean.

Comment on attachment 8655130 [details] [gaia] davidflanagan:variable-length-lockscreen-pin > mozilla-b2g:master Thanks. From the code I feel we should avoid to do too much things in one single function (set pin + rendering) which may also do nothing in some cases (the condition). I have commented it on the PR. But if this get handled well I think it's good to implement like that. It of course needs an UX endorsement, and it would better if we can refer specs or draft in this bug, since I worry the rest part David mentioned may have some side-effects and racing need to be managed carefully.

I don't know the lockscreen code well at all, but I'd propose that we do this without adding a new lockscreen state: - when FMD locks the device, we store a new, longer pin in the settings db using a setting that is different that the regular lockscreen pin. - when the user slides the thing on the lockscreen, we modify that state to check whether either one of the pins is set. If there is a long pin, it calls setPinLength(6) and enters the state where the pin entry screen appears. If there is only a short pin, it calls setPinLength(4) and enters that same state. If neither pin is set, then it just unlocks. - then we also modify the code that verifies the pin the user enters so that it checks the long pin or the short pin, depending on which one is set. - and we add code so that if the long pin is set and correctly entered, we delete that property, so that the FMD lock is removed and the user goes back to whatever lockscreen pin (or lack of pin) they had before they lost their phone. Does that sound like it would work? By integrating this all with the existing states of the state machine, I think we should dramatically reduce the risk of introducing security holes, right?

Yes, to avoid get tangled by the current state management should be enough to prevent introducing new secure risks. However, I have found the possible steps here need to be implemented carefully, otherwise we may have some new racing risks, although it could be irrelevant to security. This is because in the current version, PIN length is a constant value, namely to read and (although we don't) modify it is being expected as synchronous operations. However, in FMD killer-switch mode, the value will need to be set on demand by a remote actor outside LockScreen, therefore it will unavoidable become an asynchronous value that to read and observe it, not to mention the following flows, need also to be implemented in the asynchronous way. For example, if we notify the pin length changed by mozSettings or IAC, no matter it becomes longer or shorter, we must ensure the LockScreen will be ready to await that, or the device may be less protected (since it's a default 4 digits ping code), especially in some edge cases like: - device rebooting: since the LockScreen needs to costs 3 seconds to read mozSetting after rebooting, see Bug 1173284 (but you may need to request the permission from sec-team). - if an unauthorized user already invoke the passcode pad with 4 pin code length, we need to reset the whole UI of passcode pad (another place need UX spec to confirm the details) with the new length. This may involve some animation racing, like what will happen if user presses home button to perform the lowering keypad animation, and it is just at the moment the device receive the "longer pin code" command? - or even worse: when he or she successfully (unfortunately for the device owner) enter the 4 pin code, and the unlocking animation is performing while the longer "pin code command" finally comes at almost the same moment, what should happen? Although in the name of security we should stop unlocking as quick as we can, but since it's a new state we need to deal with, I don't know if we need or be able to handle it well according our current assumptions. So basically I think the approach is correct and these issues should be resolvable in the long term, but I just want to be careful enough to prevent us jump into another security regression pitfall by changing things as asynchronous while they're not before (like Bug 1173284, although it was not caused, but exposed by that), especially when we're under the pressure of release schedule.

As per the meeting on Sept 2, 2015, the device will be locked with a 6 digit passcode. Here is the user flow 1. User loses the device and logs on to find.firefox.com using FxA username and password. 2. User clicks on "Lost Mode" 3. Website will prompt the user to enter a 6 digit numeric passcode. 4. FMD website will then lock the device remotely with this 6 digit passcode 5. When the user recovers the device, the user should enter the 6 digit passcode to unlock the device. 6. Once unlocked, the lockscreen reverts back to the original 4 digit passcode (if the user has set one) 7, If the user has forgotten the 6 digit passcode, the user can create a new one from the website.

The only UX needed for this flow is the 6 digit passcode on the lockscreen and David has provided a screenshot of this in comment 39 that looks good and works for me. ni? Amy to check the visuals as well of the 6 digit passcode on the lockscreen.

(In reply to Jacqueline Savory [:jsavory] UX from comment #45) > The only UX needed for this flow is the 6 digit passcode on the lockscreen > and David has provided a screenshot of this in comment 39 that looks good > and works for me. > > ni? Amy to check the visuals as well of the 6 digit passcode on the > lockscreen. This looks good to me. Thanks!

Thanks for the update. Greg will working on the actual implementation but he have also raised some questions offline to me. UX. Greg, do we need a spec other than the screenshot in comment 39? Please ni UX for what specifically you need to work on this. (In reply to Jacqueline Savory [:jsavory] UX from comment #45) > The only UX needed for this flow is the 6 digit passcode on the lockscreen > and David has provided a screenshot of this in comment 39 that looks good > and works for me. Please also follow up and documenting the edge cases you talked about. Thanks.

For engineering it's not enough: your step 4 to 6 is what I concerned at Comment 43. So either UX can confirm what the animation and responses it should be at such cases, or you just grant us (and QA) to "design" that parts according to what we implement it. I can even list them now, just to think what if the immediate locking command comes at any possible stage (according to what described in Comment 44): 1. command comes at all connections are disabled (like in AriPlane mode), and later on the unauthorized user connect to the internet: --> what should show on LockScreen? The old "lock message" from FMD or just prompt the keypad with 6 pin? 2. command comes at the time the unauthorized user already types the incorrect 4 pins, and the keypad is frozen because of the "penalty time": --> should we change the pad even it's in the penalty time? Or we do that after the time, and immediately raise another pad with 6 pin? --> or maybe we just lower the pad and shows the FMD message, and to show the 6 pin code pad only after user try to unlock it again? 3. command comes at the time the unauthorized user already types the *correct* 4 pins, and the unlocking animation is performing: --> should we abort the animation and immediately re-lock it, and then to show the FMD message on LockScreen? --> or since it still has some risk about leaking the information, so we better to cover another element on the whole screen until LockScreen is ready? 4. command comes at the time the unauthorized user is using secure app like camera or emergency call --> should we kill the app and then show the 6 pin keypad or no keypad screen locker with the FMD message? --> or we just leave it and show the 6 pin keypad only when the one tries to unlock the device? Some of these are with animation racing risks. Even though for an unauthorized user device runs in clumsy is not in our concern, to prevent potential animation management problems we still need to clarify them. And I think there is no one want to solve "regressions" that are actually not regressions, but induced by undefined behaviors. Besides that, this feature now looks lack of two critical parts to implement it: 1. the spec diagram just as other features in our release, including animations in different cases 2. the sure way to let LockScreen know it should be with a longer pin code. Namely, which mozSetting should LockScreen listens to? I know Alexandre is working on that, and the Gecko code may already be there, but if I can know that in plain text that will be good.

Hi Alexandre: In the WIP patch I use a mozSetting, the "'lockscreen.passcode.strength'", to let front-end side knows which strength of password the current system is using: https://github.com/mozilla-b2g/gaia/pull/31846/files#diff-9be2ed595d4818d6cc827495cda29c82R86 It could be "normal", "enhanced" or "password". If in the future we have real password for keyboard app + lockscreen frame, it could be set as "password". And currently, the "normal" is for 4-pin code while "enhanced" is for 6-pin code, since I don't have seen any necessity to expose arbitrary length of passcode, so I think to make it as an enum is better. Do you feel it's good to the Gecko patch?

I feel that it's one more setting and that I don't like it. Is there really no other way ?

Sorry to be so nitpicky. But if we do end up using a setting, can we make it more expressive, e.g., "pin-4", "pin-6" and "passphrase" (phrase implying that it's more complicated than a word)?

Alexandre: Since we're in a middle stage toward the full password and now we need two different kinds of passcode, I feel that the semantics looks not so clear, if we hook the format implicitly on other values. For example, if we bind it with the 'lockscreen.lock-immediately' used by FMD, the reader must know there is an implicit assumption is that the pin code will be longer after that, and that makes me feel not good. But yes, to add one more mozSetting is bad as well. So I just don't know which sounds more sensible. Frederik: I want to avoid being too specific since 4 and 6 pin seems not with very strong security reason (why not 5, or 7, or even 10 pin?) . It looks like just a de facto length, so I keep it somewhat vague. But if it's a convention like AES-256, I can change that.

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #53) > I want to avoid being too specific since 4 and 6 pin seems not with very > strong security reason (why not 5, or 7, or even 10 pin?) . It looks like > just a de facto length, so I keep it somewhat vague. But if it's a > convention like AES-256, I can change that. Yeah, that's a good point. My worry was about code readability and maintainability. A middleground could be "short-pin", "long-pin", "passphrase", but I don't want to hijack this bug with something as insignificant as this :-) I'm sure you'll make a good decision.

Sorry about the lack of spec for this one, my understanding was that we would use the same system that ‘lost mode’ currently uses as I believe it acts in the same way as ‘kill switch’. But I see from your list of questions that there are still some outstanding issues: 1. I believe that as soon as the device can connect to the internet, it would immediately display the new 6 digit passcode and the ‘lock message’ together, as in the other cases. 2. I think its better to display the 6 pin code as soon as possible, so I would suggest lowering the keypad and wait for the user to unlock it again. 3. I think in most cases we should abort the animation and immediately re-lock the screen again, I think simply locking it as fast as possible is best. 4. The device should definitely lock if the user is using the camera, however emergency call I think should remain, and lock again immediately after the the call has ended if possible. I can put a spec together, but I’m not sure it would add much value. It might be more efficient for me to answer your questions directly, but if you would prefer to have one, let me know and I’ll create it. In the meantime, please feel free to keep asking questions as they arise and I’ll be happy to answer. In terms of the animations, I’m not sure I know exactly what you need. Do you need us to define the animation that occurs when kill switch is activated? I think its best to have a single one as it would be difficult to define every case.

Thanks for explanation, but I need to clarify that it's not my personal insist to ask the spec diagram for a new feature: every feature in plans and eventually landed during releases has their spec, and that's important since QA and us need to test the feature according to a full document, not bug comments which may be more fragile and vague. I know spec may also change over time, especially when it misses some detailed things from the beginning. However, the communication cost is still cheaper to pick, discuss and fix the undefined behaviors when we're planning and design the feature, if you compare it to finding and fixing in the following "regression" bugs. And to have a spec summarizes that means we can make sure how the feature works in this release. It is definitely not just "adding not much value", and UX's work like that is always important to us. And about the animations: in my WIP patch now it will not trigger any animation when it is changing the 4-pin pad to 6-pin pad, and will not raise the keypad if it is hidden, too. These are because I'm not sure what is your expect, so I can't decide what is a good way to do the transition, and that is also another reason why I ask a spec for. If you can make sure what kinds of animations are required as in your elaborations, and draw it in the spec as other features in the past releases, it will be very helpful. Otherwise, QA and me can only guess what kinds of animations during the pad changing and the command coming, and hope there is no one feel bad about that in the future.

Sorry Greg, I didn’t mean to imply that you were asking personally, I understand that this is for the project and not something that just you are asking for. Thank you for the explanation, I am always happy to hear that the work the UX team is doing is valued. Speaking of, I put a quick spec together, as always feel free ask questions or let me know if there is anything I missed: https://mozilla.box.com/s/ifh9728xik95urxjz7n5ch77n85hdhxh In terms of the animations, unfortunately they won’t be in my spec as they are determined by the visual design team. NI? on Amy, can you provide an answer here in terms of which animations we should display at the points that Greg has mentioned.

Hi Greg, In terms of animation. I would follow the same behaviour as a 4-digit pin code (see link). https://youtu.be/plAKJvZ1jYw "in my WIP patch now it will not trigger any animation when it is changing the 4-pin pad to 6-pin pad" I'm not too clear on what you mean by this. I would assume that the actual transition from a 4-pin to 6-pin would be hidden from the user and it will appear as a 6 digit pin-code on lockscreen once it's activated. If there is any other scenario that I have missed, please let me know. Amy

(In reply to Amy Lee [:amylee] UX from comment #58) > Hi Greg, > > In terms of animation. I would follow the same behaviour as a 4-digit pin > code (see link). > > https://youtu.be/plAKJvZ1jYw > > "in my WIP patch now it will not trigger any animation when it is changing > the 4-pin pad to 6-pin pad" > > I'm not too clear on what you mean by this. I would assume that the actual > transition from a 4-pin to 6-pin would be hidden from the user and it will > appear as a 6 digit pin-code on lockscreen once it's activated. > > If there is any other scenario that I have missed, please let me know. > > Amy Hi Amy, The scenario is when the screen showing the 4-pin lockscreen (maybe the phone is stolen) and then the actual owner kills it through the website. What will the animation look like? It is new feature so I believe that's why we need to think about all the possible cases. And echo to Greg that spec will be very very important, otherwise there's no reference or single source of truth for QA to verify.

Hi Wesley, If the user activates the kill switch from the website, the 4-digit pin code screen would jump back to lockscreen (no transition animation). From the lockscreen, if the user unlocks the device after the kill switch is active, it will present the 6-digit pin code screen. The animation between the pin code screen and lockscreen would be the same as going from the lockscreen to the pin code screen (It looks like lockscreen toggle disappears and the pin-code appears with no transition). Jacqueline to confirm UX. I can put together a spec to show this tomorrow, but essentially when the kill switch is triggered, the pincode screen switches to the lockscreen with the same transition of when the lockscreen transitions to the pincode screen. Let me know if I missed anything. (In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #59) > (In reply to Amy Lee [:amylee] UX from comment #58) > > Hi Greg, > > > > In terms of animation. I would follow the same behaviour as a 4-digit pin > > code (see link). > > > > https://youtu.be/plAKJvZ1jYw > > > > "in my WIP patch now it will not trigger any animation when it is changing > > the 4-pin pad to 6-pin pad" > > > > I'm not too clear on what you mean by this. I would assume that the actual > > transition from a 4-pin to 6-pin would be hidden from the user and it will > > appear as a 6 digit pin-code on lockscreen once it's activated. > > > > If there is any other scenario that I have missed, please let me know. > > > > Amy > > Hi Amy, > > The scenario is when the screen showing the 4-pin lockscreen (maybe the > phone is stolen) and then the actual owner kills it through the website. > What will the animation look like? > It is new feature so I believe that's why we need to think about all the > possible cases. And echo to Greg that spec will be very very important, > otherwise there's no reference or single source of truth for QA to verify.

Hi, I've posted an animation spec for Kill Switch. You can find it here: https://mozilla.app.box.com/files/0/f/4684857770/1/f_39108695865 Let me know if you need anything else.

Yes, as Amy stated the animation should be the same going from the lockscreen to the pin code screen should be the same for both 4 and 6 pin screens as well as going from pin code to lockscreen and lockscreen to pin code

This is the first version behaves "like the same with 4 pin version". I have updated the patch and post the video here: https://www.youtube.com/watch?v=vFnTHU_NW8U I don't want to be in a long term process of fixing the UX with a late start, so I try to implement it and you may give what your opinion. And I can say there are some technical difficulties during my tring due to the legacy code, so the current method and the result you can see in the video is the safest way to implement the panel switching.

Please flag Amy when you need review of the animations. I'm not sure if this is just a demo of the animation, but the user should be brought back to the lockscreen when the kill switch is activated, even if they are currently on the pin screen.

Hi Greg, As highlighted in the animation spec and Jacqueline had commented, the user should be brought back to the lockscreen when the kill switch is activated, even if they are currently on the pin screen. In terms of the keyboard sliding up, that is correct. Thanks

I've updated the patch to align what Amy mentioned and the spec. I will set a further UX review when the progress and discussion are stabilized.

required for KS 2.6

Killswitch was reviewed, but was killed in the end.