Closed
Bug 927482
Opened 11 years ago
Closed 7 years ago
[B2G][Lockscreen][Passcode] Slow resetting when entering an incorrect passcode for many times
Categories
(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: sarsenyev, Unassigned)
References
Details
(Whiteboard: [systemsfe] [perf-reviewed])
Attachments
(1 file)
(deleted),
video/quicktime
|
Details |
Description:
When entering an incorrect passcode for many times, the passcode field is very slow on resetting the incorrect result.
Repro Steps:
1) Updated Buri BuildID: 20131016040202
2) Open "Settings" from the home screen
3) Navigate to "Screen lock" menu under "Privacy & Security"
4) Toggle the "Passcode lock" to "on" position
5) Set a passcode and confirm with "Create" button
6) Press the "power" button for sleeping option
7) Press the "power" button again to wake up the phone
8) Tape an incorrect passcode for 7-10 times
Actual:
The incorrect passcode is resetting very slow
Expected:
The incorrect passcode resetting quickly as for the first time
Environmental Variables:
Device: Buri v1.3 Central Mozilla RIL
BuildID: 20131016040202
Gaia: 3d4f1107e6e91e5f5649edc0f2565ac837111d7d
Gecko: 9f63bbc00527
Version: 27.0a1
Firmware Version: US_20130912
Notes:
Repro frequency: 100%
See attached: video attachment
Same issue with the latest Buri Aurora 1.2 MOZ RIL
Device: Buri v1.2 Aurora Mozilla RIL
BuildID: 20131016004005
Gaia: 5ef3535021286ccab7af639897feaaf5955720a0
Gecko: 75b0b968f3ed
Version: 26.0a2
Firmware Version: US_20130912
The issue doesn't reproduce on the latest Leo 1.1
Device: Leo v1.1 Mozilla RIL
BuildID: 20131016041201
Gaia: 680f3b86b1e4ff1411ece6ba397b8b0e56b4b31c
Gecko: 3cbd02abb840
Version: 18.0
Keywords: regression,
regressionwindow-wanted
Updated•11 years ago
|
Whiteboard: [c= p= s= u=][perf-reviewed] → [c= p= s= u=]
Regression window:
Doesn't reproduces on Buri 1.2 Master build
Device: Buri Master v1.2 Mozilla RIL
BuildID: 20130912040201
Gaia: 9ffd2899eb91388f7fc1ce6f7a895a6f5f922c05
Gecko: a98569f21abe
Version: 26.0a1
Firmware revision:US_20130912
The issue reproduces on:
Device: Buri Master v1.2 Mozilla RIL
BuildID: 20130913040201
Gaia: 8ccb741b6adcfe9a78b842c17e5874242c0f8b86
Gecko: b9029b1de410
Version: 26.0a1
Firmware Version: US_20130912
Keywords: regressionwindow-wanted
Updated•11 years ago
|
blocking-b2g: --- → koi?
Comment 3•11 years ago
|
||
I believe this is a "feature" implemented in bug 888911. If that not correct please reopen this bug.
Status: NEW → RESOLVED
blocking-b2g: koi? → ---
Closed: 11 years ago
Resolution: --- → WONTFIX
Comment 4•11 years ago
|
||
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #3)
> I believe this is a "feature" implemented in bug 888911. If that not correct
> please reopen this bug.
That's umm...strange as a security approach, but okay. Did anyone from UX review this?
Flags: needinfo?(firefoxos-ux-bugzilla)
Comment 5•11 years ago
|
||
This is actually quite a common approach to slow down the brute force attack for password. Even the UNIX login does that. Android pattern lock does that. Etc.
Comment 6•11 years ago
|
||
(In reply to Hubert Figuiere [:hub] from comment #5)
> This is actually quite a common approach to slow down the brute force attack
> for password. Even the UNIX login does that. Android pattern lock does that.
> Etc.
Fair enough. I'll pull the needinfo then.
Flags: needinfo?(firefoxos-ux-bugzilla)
Updated•11 years ago
|
Whiteboard: [c= p= s= u=] → [c= p= s=2013.10.25 u=]
Comment 7•11 years ago
|
||
UX has not reviewed this, nor were we even aware of the feature in bug #888911. We should review this. An increasingly lengthy delay may not necessarily be clear to the user as to *why* it's happening, which it would be nice to check for.
We don't generally just say "common approach" justifies new UX (as one person points out what's a common approach on iOS, while for someone else it's Android, while for someone else it may be something unrelated to mobile devices). Given the amount of work that has gone into the lock screen in the past release, I'd like to review this.
Updated•11 years ago
|
Flags: needinfo?(pdolanjski)
Flags: needinfo?(fdjabri)
Comment 8•11 years ago
|
||
Thanks Stephany. I'm going to reopen this given your comment to evaluate the UX make improvements in alignment with what UX desires.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 9•11 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #8)
> Thanks Stephany. I'm going to reopen this given your comment to evaluate the
> UX make improvements in alignment with what UX desires.
Meant to say - evaluate the UX improvements we need to make to be in alignment with what UX wants in this implementation.
Comment 10•11 years ago
|
||
I've reviewed this with Francis Djabri, a member of the UX team, and the product owner for System Front-end, Peter Dolanjski. Here is our compiled feedback.
First, in future, module owners should consult with UX for something this user facing, for review before landing. Everything doesn't need a spec, but UX input should be given for something like this.
UX *is* a fan of this feature for the purpose of mitigating brute force attacks. BlackBerry used to do this by forcing the user to type "blackberry" after x incorrect password attempts. This would break up the entry to help discourage such attacks.
But the implementation here needs some usability improvements. The key missing piece is informing the user why there is a delay. When a delay is introduced, we need to tell the user "incorrect password, try re-entering in x seconds" (potentially with a count down) or something to that effect.
If we can add some UX for this, we suggest also considering how we might present a prompt that will let the user know that their device will be wiped after x number of failed attempts. In a stolen device scenario this is the only way to stop brute force attacks completely. This feature is already in the Systems Front-end backlog. It's not top priority, but they may deliver it at some point.
Flags: needinfo?(pdolanjski)
Flags: needinfo?(fdjabri)
Updated•11 years ago
|
Whiteboard: [c= p= s=2013.10.25 u=] → [c= p= s=2013.10.25 u=][systemsfe]
Updated•11 years ago
|
Keywords: perf,
regression
Updated•11 years ago
|
Whiteboard: [c= p= s=2013.10.25 u=][systemsfe] → [systemsfe]
Updated•11 years ago
|
Whiteboard: [systemsfe] → [systemsfe] [perf-reviewed]
Comment 11•10 years ago
|
||
On the recently (2.0+) master this is unable to reproduce. Maybe you can check it again and we can close this old bug.
Flags: needinfo?(sarsenyev)
Comment 12•10 years ago
|
||
The person needinfo'd no longer works here, so I'm switching to qawanted.
Flags: needinfo?(sarsenyev)
Keywords: qawanted
Comment 13•10 years ago
|
||
Issue is still reproducible on today's Buri 2.1 master. Note step 8 of original repro is:
> 8) Tape an incorrect passcode for 7-10 times
Following the above quoted step will reproduce the bug.
Tested on:
Device: Buri
Build ID: 20140618040513
Gaia: 431aed0a7c7560c6eacd35ea69aa0a7a4ebe72c7
Gecko: 37f08ddaea48
Version: 33.0a1 (2.1 - Master)
Firmware Version: v1.2device.cfg
Updated•10 years ago
|
Flags: needinfo?(jmitchell)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+][lead-review+]
Comment 15•7 years ago
|
||
Firefox OS is not being worked on
Status: REOPENED → RESOLVED
Closed: 11 years ago → 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•