Closed Bug 1030448 Opened 6 years ago Closed 6 years ago

From lock screen set by FMD, you can :receive notifications, turn on/off blue tooth, enable airplane mode, and access USB storages

Categories

(Firefox OS Graveyard :: FindMyDevice, defect)

x86
macOS
defect
Not set

Tracking

(b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S6 (18july)
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: kglazko, Assigned: ggp)

References

Details

Attachments

(7 files)

The STR is a bit complicated, and dependent on this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1029879

Bug 1029879 doesn't block, but when the phone is in that state, notifications slip through.

All you have to do is lock your phone from the FMD website and don't touch it/re-lock it. Don't let the device sleep, either. Simply send a text from a different phone. You will be able to see the notification for the text message when it arrives. You will also be able to drag down the notification bar, clear notifications, etc.

I am adding two attachments for your viewing.
QA Contact: kglazko
Keywords: qawanted
from a product perspective this is a blocker as it has security/privacy consequences
blocking-b2g: --- → 2.0?
Depends on: 1029879
This was discussed in triage but I guess the edit didn't make it, blocking.
blocking-b2g: 2.0? → 2.0+
emailing lockscreen folks to see if we can get some help with investigation.
Target Milestone: --- → 2.0 S5 (4july)
Flags: needinfo?(timdream)
So, to edit this bug, in this "pseudo-lost mode", ones' files are also accessible if USB device storage is enabled on the device.
Summary: Notifications Slipping Through in 'Lost Mode' → From lock screen set by FMD, you can :receive notifications, turn on/off blue tooth, enable airplane mode, and access USB storages
It's too late to make this work for 2.0. I recommend we push Find My Device to 2.1 so we won't delay release of 2.0. I don't have any resource to handle this really really late 2.0 feature request even if I want to get this shipped. Scheduling this kind of work will also put 2.1 planning features at risk.

Let's work this out from e-mail from Howie.
blocking-b2g: 2.0+ → 2.0?
Flags: needinfo?(timdream)
So, this isn't a blocker, we've worked through some nuances:

Case 1:
- if passcode lock is enabled, fmd is enabled, device is unlocked and screen is on
- then, if the owner sends the fmd-lock remotely
- the device will lock, but notifications will be visible until the screen turns off
- after the screen has turned off once, the notifications are never visible again
To be clear, if an attacker has an unlocked device, they can already access texts etc. So the vulnerability occurs between sending the fmd-lock signal, and the display shutting off.
Case 2:
- fmd is enabled but passcode lock is *not* enabled, fmd is enabled, and screen is on
- then, if the owner sends the fmd-lock remotely
- the device will lock, but notifications will be visible until the screen turns off
- after the screen has turned off once, the notifications are never visible again
To  be clear, if an attacker has an unlocked device, they can already  access texts etc. So the vulnerability occurs between sending the  fmd-lock signal, and the display shutting off.
blocking-b2g: 2.0? → ---
Target Milestone: 2.0 S5 (4july) → ---
Attached file gaia pull request
Despite the fact that this is not a blocker, it's still a nice thing to fix.

One possible solution to this is to just make the lockscreen respond to the 'lockscreen.lock-immediately' setting we had introduced for FMD. While the Lockscreen Window Manager already listens for changes to that setting, it looks like that is _not_ enough, and we actually need the lockscreen itself to lock when that setting changes.

I had initially considered fixing this issue by raising a 'screenchange' event in apps/system/findmydevice_launcher.js, which would simulate a power button press, but it looks like this is enough. I wouldn't mind using 'screenchange' if that's preferable, though.

This is a workaround, and once bug 898348 lands we should make it a priority to develop an actual IAC API for FMD <--> lockscreen communication (bug 992277), but this should suffice for 2.0. Tim, what do you think?
Attachment #8449093 - Flags: review?(timdream)
And just to be clear: this is not a late lockscreen feature request, but rather a FMD/lockscreen integration issue that I introduced myself [1] when working around a conflict caused by a lockscreen refactor. As far as we're concerned in FMD, the lockscreen is fine as it is -- we're just interacting badly with it.

1- https://github.com/mozilla-b2g/gaia/commit/57a86742e
Attachment #8449093 - Flags: review?(timdream) → review?(gweng)
Could we have some unit tests for these changes? If you can write some simple test for the LockScreenWindowManager it seems can be r+ without problems.
Flags: needinfo?(ggoncalves)
Thanks, Greg! Updated the PR to include tests.
Flags: needinfo?(ggoncalves)
Comment on attachment 8449093 [details] [review]
gaia pull request

Okay, the patch is fine with tests. Thanks.
Attachment #8449093 - Flags: review?(gweng) → review+
Keywords: checkin-needed
Blocks: 1029879
No longer depends on: 1029879
travis reported failures see https://travis-ci.org/mozilla-b2g/gaia/builds/29093358 - is this related to this change ?
Keywords: checkin-needed
I don't think it is, but I rebased on current master and restarted a Travis run to be on the safe side.
Another run, another error in the same suite: https://travis-ci.org/mozilla-b2g/gaia/jobs/29311145 . Note that the test that had failed in the other run passed this time. I really think these are unrelated intermittent issues, so it should be fine to land.
Keywords: checkin-needed
Target Milestone: --- → 2.0 S6 (18july)
Assignee: nobody → ggoncalves
master: https://github.com/mozilla-b2g/gaia/commit/7ec07ef85d57036bd950d82f8c79a91cea0c9d0f
Status: NEW → RESOLVED
Closed: 6 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Attached file v2.0 pull request
NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): 1030448
[User impact] if declined: Low, this addresses an unlikely case
[Testing completed]: Manual and Travis
[Risk to taking this patch] (and alternatives if risky): None
[String changes made]: None
Attachment #8452256 - Flags: approval-gaia-v2.0?(bbajaj)
Kate, can you please help verify this issue once it lands on 2.0 ?
Flags: needinfo?(kglazko)
Attachment #8452256 - Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0+
Keywords: checkin-needed
Yes, would that be tomorrow when it lands? 

Best,
Kate
Flags: needinfo?(kglazko)
Keywords: qawanted
v2.0: https://github.com/mozilla-b2g/gaia/commit/1774027323bb072b4ebdfea9883572bcf2535c87

BTW, checkin-needed isn't needed on uplifts. Please avoid setting it to avoid cluttering up bug queries.
This issue has been successfully verified on Flame 2.1&2.0.And there found a new UI Bug 1106473.
See attachment: verified_v2.1.MP4.
Reproduce rate: 0/5

STR:
1.Sign in FMD on both device and PC.
2.Send a lost mode message to the device.  
**Locked screen is shown and the Lost mode notification appears immediately.
3.Slide to the right to unclock screen.
**Password keypad appears,user can input password. 

Flame 2.0 versions:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141130000204
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141130.032432
FW-Date         Sun Nov 30 03:24:44 EST 2014
Bootloader      L1TC00011880

Flame 2.1 versions:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141130001203
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141130.034738
FW-Date         Sun Nov 30 03:47:49 EST 2014
Bootloader      L1TC00011880
Status: RESOLVED → VERIFIED
This issue has been successfully verified on Flame 2.1&2.0.
See attachment: verify_v2.1_1.MP4 and verify_v2.1_2.MP4.
Reproduce rate: 0/3

STR:
1.Sign in FMD on both device and PC.
2.Send a lost mode message to the device.  
**Locked screen is shown and the Lost mode notification appears immediately.
3.Send a message to device,or a miss call,or plug in USB cable,or try to slide down notifications bar.
**Can't see the message or other notifications and can't see USB storage after the Lost mode notification appears.

Flame 2.0 versions:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141130000204
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141130.032432
FW-Date         Sun Nov 30 03:24:44 EST 2014
Bootloader      L1TC00011880

Flame 2.1 versions:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141130001203
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141130.034738
FW-Date         Sun Nov 30 03:47:49 EST 2014
Bootloader      L1TC00011880
You need to log in before you can comment on or make changes to this bug.