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

RESOLVED WORKSFORME

Status

Firefox OS
Gaia::Settings
P1
blocker
RESOLVED WORKSFORME
5 years ago
2 years ago

People

(Reporter: lecky, Unassigned)

Tracking

unspecified

Firefox Tracking Flags

(blocking-b2g:-)

Details

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
Severity: normal → blocker
Priority: -- → P1
(Reporter)

Updated

5 years ago
Flags: needinfo?(wchang)
(Reporter)

Comment 1

5 years ago
hi,wayne

please help check the issue.
(Reporter)

Updated

5 years ago
Flags: needinfo?(brg)
(Reporter)

Comment 2

5 years ago
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?
(Reporter)

Updated

5 years ago
Summary: [B2G][Helix][Settings][zhaotao]Lockscreen password should be required to disable lockscreen → [B2G][Helix][Settings][Security Bug][zhaotao]Lockscreen password should be required to disable lockscreen
(Reporter)

Updated

5 years ago
blocking-b2g: --- → hd?
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.
Flags: needinfo?(wchang) → needinfo?(firefoxos-ux-bugzilla)
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?
Flags: needinfo?(brg)

Comment 5

5 years ago
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.
Flags: needinfo?(joechengla)
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?(fdjabri)
(Reporter)

Updated

4 years ago
Summary: [B2G][Helix][Settings][Security Bug][zhaotao]Lockscreen password should be required to disable lockscreen → [B2G][Helix][Settings][Security Bug][shijinde]Lockscreen password should be required to disable lockscreen
(Reporter)

Comment 6

4 years ago
Created attachment 814699 [details]
1 open lockscreen.png
(Reporter)

Comment 7

4 years ago
Created attachment 814700 [details]
2 open passcode lock.png
(Reporter)

Comment 8

4 years ago
Created attachment 814701 [details]
3 close lock screen.png
(Reporter)

Comment 9

4 years ago
hi,i have upload several pictures to better illustrate the issue.
William can you check beatrizs comment v.s. helix?
Flags: needinfo?(whsu)
Keywords: qawanted

Comment 11

4 years ago
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!
Flags: needinfo?(whsu) → needinfo?(brg)

Comment 12

4 years ago
--------- Remove QAwanted --------
Keywords: qawanted

Updated

4 years ago
Flags: needinfo?(fdjabri) → needinfo?(rmacdonald)
(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.
Flags: needinfo?(brg)
(Reporter)

Comment 14

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

What do you think about this problem, beatriz?

Thanks
Flags: needinfo?(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.
Flags: needinfo?(brg) → needinfo?(pdolanjski)

Comment 16

4 years ago
Hi, Beatriz,

No problem.
Thanks for your help and second confirmation! :)
Have a nice day!
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.
blocking-b2g: hd? → -
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?
Flags: needinfo?(pdolanjski) → needinfo?(bhuang)
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.
Flags: needinfo?(rmacdonald)
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.
Flags: needinfo?(bhuang) → needinfo?(arthur.chen)
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.
Flags: needinfo?(arthur.chen)

Updated

4 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 22

3 years ago
Removing flag on old bug.
Flags: needinfo?(joechengla)

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.