921013 - [B2G][Helix][Settings][Security Bug][shijinde]Lockscreen password should be required to disable lockscreen

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::Settings, defect, P1)

Description

[lecky]

User Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; aff-kingsoft-ciba; Zune 4.7)

Steps to reproduce:

【Detail Description*】：Lockscreen password should be required to disable lockscreen
【Repro Steps*】：
1、first enable lock screen and passcode lock in Settings->phone lock
2、turn off the screen,then trun on the screen, enter lockscreen password,
3、in Settings->phone lock,disable lock screen


Actual results:

【Real Result*】：lock screen is disabled and no lockscreen password input required
【Test Count*】：5
【Found Count*】：5
【Gaia commit ID*】:8059864bd278645ab5d2598b5ed595154136c253
【Gecko commit ID*】:0265cd51b4dc64ca100353482ada2025df6f5f53


Expected results:

【Expect Result*】：To disable locksreen,user should be required to input correct lock screen password.

By the way,to disable passcode lock,the user is required to input correct lock screen password now.

I think to disable lock screen,the same behavior should performed.

Comment 1

[lecky]

hi,wayne

please help check the issue.

Comment 2

[lecky]

HI Beatriz:
 We think this issue would lead to personal info lead for terminal user.
 Could you help us to push it be solved on V1.1HD?

Comment 3

[Wayne Chang [:wchang]]

Agreed this should be the case but we are not making any UX changes for v1.1.

Flagging UX in case this has not been brought to your attention yet.

Comment 4

[Beatriz Rodríguez [:brg]]

This feature is working fine in v1-train, testing with unagi, commits Gecko-f057c26.Gaia-f3b30b1.
Can you check what it is misssed to make it work in v1.1hd?

Comment 5

[Stephany Wilkes]

Per Beatriz in comment #4, this sounds like an issue that cannot be reproduced, but I am flagging Francis (UX) and Joe, whose team worked on this in Oslo, to clarify the expected behavior.

Comment 6

[lecky]

Attachment: 1 open lockscreen.png

Comment 7

[lecky]

Attachment: 2 open passcode lock.png

Comment 8

[lecky]

Attachment: 3 close lock screen.png

Comment 9

[lecky]

hi,i have upload several pictures to better illustrate the issue.

Comment 10

[Wayne Chang [:wchang]]

William can you check beatrizs comment v.s. helix?

Comment 11

[William Hsu [:whsu]]

Hi, Wayne,

After I double checked this problem, I can easy reproduce this problem on "V1.0.1", "V1.1.0", "V1-Train"(Beatrizs mentioned), and "V1.2".
So, Beatrizs might misunderstand this problem.

As current behavior,
If user enabled "Passcode Lock" then try to disable"Lock Screen", FxOS will not have a prompt message(Passcode).
If user enabled "Passcode Lock" then try to disable"Passcode Lock", FxOS will have a prompt message and user need to input the passcode.

So, we could request UX to review this case since it is current behavior.

-----------------------------------------------------------------------------
Hi, Beatriz,

Could I have a question?
In last reproduce step, Lecky meant to disable the "Lock Screen", not "Passcode Lock"
Do you misunderstand anything since I can reproduce this problem with the build you mentioned?
Many thanks!

Comment 12

[William Hsu [:whsu]]

--------- Remove QAwanted --------

Comment 13

[Beatriz Rodríguez [:brg]]

(In reply to William Hsu [:whsu] from comment #11)
> As current behavior,
> If user enabled "Passcode Lock" then try to disable"Lock Screen", FxOS will
> not have a prompt message(Passcode).
> If user enabled "Passcode Lock" then try to disable"Passcode Lock", FxOS
> will have a prompt message and user need to input the passcode.
> 
> So, we could request UX to review this case since it is current behavior.
> 
> -----------------------------------------------------------------------------
> Hi, Beatriz,
> 
> Could I have a question?
> In last reproduce step, Lecky meant to disable the "Lock Screen", not
> "Passcode Lock"
> Do you misunderstand anything since I can reproduce this problem with the
> build you mentioned?
> Many thanks!
I feel so embarrassed, Sorry William. You are right. I misunderstood the issue. Your explanation is perfect discribing the behaviour(I just rechecked it with v1-train). 
Thanks for including UX team and lets wait for their opinion in case we want to change current behavior in the future releases of the OS.

Comment 14

[lecky]

Hi, this problem is very serious for users. and maybe casue some security problems.

What do you think about this problem, beatriz?

Thanks

Comment 15

[Beatriz Rodríguez [:brg]]

(In reply to lecky from comment #14)
> Hi, this problem is very serious for users. and maybe casue some security
> problems.
> 
> What do you think about this problem, beatriz?
> 
> Thanks
We agree it is strange but working in the same way in all branches(Thanks William!). Lets ask Peter to know if it make sense to chage it or not.

Comment 16

[William Hsu [:whsu]]

Hi, Beatriz,

No problem.
Thanks for your help and second confirmation! :)
Have a nice day!

Comment 17

[Wayne Chang [:wchang]]

HD-'ing here as consistent across all releases/devices, if Peter or Rob feels this should be blocking for any release, please use leo+ for v1.1/v1.1HD or koi+, 1.3+.

HD+ will be used for device hw/visual specific bugs.

Comment 18

[Peter Dolanjski [:pdol]]

I think this is the right decision, but it probably makes sense (in a future release) to make this behavior consistent with the disabling of the password.  Bruce, this falls under settings, what do you think?

Comment 19

[Rob MacDonald [:robmac]]

Sorry for the delay. I actually think this is a blocking issue as it deals with safety and security. It allows someone who steals your phone to easily circumvent the lock screen. Other platforms have been heavily criticized for issues with circumventing pass codes and were forced to issue urgent patches. We don't want to put ourselves or our users in a similar position.

Comment 20

[Bruce Huang [:bhuang] (inactive)]

This is one of those things that is a minor issue in practice but could stir up a lot of negative feedback.  
ni Arthur to see the level of effort needed to add the password entry.

Comment 21

[Arthur Chen [:arthurcc][inactive after 6/30]]

Actually we already have a patch from a contributor couple months ago in bug 811624. I reviewed it but failed to do the followup. I think we can try to have bug 811624 landed.

Comment 22

[Stephany Wilkes]

Removing flag on old bug.