[RPP] Detect if the screen lock is on

RESOLVED FIXED

Status

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: marta, Assigned: agnieszka.baranowska)

Tracking

({privacy})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
In case user wants to be able to remotely lock his phone we need to detect if the screen lock was activated.
(Reporter)

Comment 1

4 years ago
And if it was not - we need to take him to settings and get him to activate the screen lock
(Reporter)

Updated

4 years ago
Assignee: nobody → marta
(Reporter)

Updated

4 years ago
Summary: RPP: Detect if the screen lock is on → [RPP] Detect if the screen lock is on

Updated

4 years ago
Keywords: privacy

Updated

4 years ago
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → All
(Reporter)

Updated

4 years ago
QA Whiteboard: STATUS: pending
Priority: -- → P4
(Reporter)

Updated

4 years ago
QA Whiteboard: STATUS: pending → STATUS: ?
(Assignee)

Comment 2

4 years ago
To detect if user has active 'lock screen' and 'passcode lock' it's quite simple - we need to check parameters 'lockscreen.enabled' and 'lockscreen.passcode-lock.enabled'.
In situation when user won't have active lock screen or passcode lock, do you agree Marta that we display custom panel with two inputs to enter passcode (second input for confirmation) instead of taking user to Settings app beacuse AFAIK we can launch Settings app (via Web Activities API) but only main window - it doesn't allow to redirect to 'Screen lock' window?
(Reporter)

Updated

4 years ago
Flags: needinfo?(huseby)
(Reporter)

Updated

4 years ago
Assignee: marta → agnieszka.baranowska
QA Whiteboard: STATUS: ? → STATUS: not started
(Assignee)

Comment 3

4 years ago
Existing application 'Find my Device' has a opportunity to send lock command with passcode. This passcode will be used if user hasn't had active screen lock or passcode lock. Maybe we should extend lock command and add passcode parameter.
(Reporter)

Comment 4

4 years ago
As explained in the email - this functionality should not be allowed in the current state. Once we implement the hidden SMS then the option of setting the lock with a passphrase in the SMS will be feasible, as long as we allow only one time SMS (so once the message is sent phone locks itself and stops reacting to new messages)
(Reporter)

Updated

4 years ago
QA Whiteboard: STATUS: not started → STATUS: implementation work
As Marta stated, as long as we're not using hidden SMS messages, we should not allow remote locking if the user has not set a passphrase.  Normally I would say that we should look into hidden SMS support but considering the tight deadline and current circumstances, I think we need to push this feature off until v2.2.
Flags: needinfo?(huseby)
(Assignee)

Comment 6

4 years ago
I have another idea. Lock command leaves as it is now (FmD: LockDevice testPassKey123). SMS listener receives lock command and invokes lock command from Find My Device app with random generated passcode. If user doesn't have active passcode lock, the generated passcode is used. In reply user (phone from which lock command was sent) received SMS with text:
1) case: user has active passcode lock
FmD: <deviceId> locked remotly at time: <time>
2) case: user has active passcode lock
FmD: <deviceId> locked remotly with code: <passcode> at time: <time>
(Reporter)

Comment 7

4 years ago
Yes, agreed. Great solution.
(Assignee)

Comment 8

4 years ago
Marta, do you agree that if we implement solution with random generated passcode, we don't need to check if screen lock is on (we don't have to worry about it). We make change in implemention of lock command, which deals with a case when user don't have active lock screen or passcode lock.
Can we close the bug with this comment?
(Reporter)

Comment 9

4 years ago
Is this lock code our custom one or done with the use of FmD lock?
(Assignee)

Comment 10

4 years ago
I invoke FmD lock command which has three parameters - one of them is passcode.
(Reporter)

Comment 11

4 years ago
We cannot change the fmD lock command. We can only invoke it. So the only thing that you can do is create a passcode if it is not available and pass the argument to fmd lock, so that as far as fmd lock is concerned the passcode is always there
(Assignee)

Comment 12

4 years ago
Ok, when I wrote "We make change in implemention of lock command" I meant that we will change invocation of FmD lock command - so far we invoked with null as passcode, now we put there random generated passcode.
(Reporter)

Comment 13

4 years ago
agreed.
(Reporter)

Comment 14

4 years ago
The required code is now included in the patch for bug 1060164
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Reporter)

Updated

4 years ago
QA Whiteboard: STATUS: implementation work
Priority: P4 → --
You need to log in before you can comment on or make changes to this bug.