1088028 - Device can still receive files from an unpaired device

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[Stephanie Ouillon [:arroway] (needinfo me)]

Build Information
Gaia-Rev        1e48e3e40e0780c0cd07a3457e5fe2efeeb542d1
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/09fb60a37850
Build-ID        20141023001201
Version         34.0
Device-Name     flame
Base image: ***Please update this field to say if you're running the v180 or the v188 base image***


Description
I run a 2.0 Firefox OS (device A) on a Flame device, and the 2.1 version on another one (device B).
On device B, I can unpair device A, but not the opposite (because of a bug, apparently).
After unpairing, device B is still able to receive files from device A.

Steps to Reproduce
1. Pair the two devices
2. Unpair device A on device B (device B doesn't have device A in the paired devices list anymore).
3. From device A (who is still showing device B in the paired devices list), share a file over BT

Expected Results
Device B should be unpaired with device A and not received the file.

Actual Results
Device B is prompted to accept receiving the file from device A.

Other Notes
The security risk is not that high because the user
1) must have accepted to pair his device at least once before
2) is still prompted to receive the file. But he could be tricked if he is being sharing files with another device, and accept the files without knowing who is sending it.

Reproduction Frequency: always

Comment 1

[Ben Tian (inactive)]

Bug 947060 made the change for NFC that utilizes bluetooth file transfer since
1) user confirmation is still required before file receiving, and
2) bluetooth file transfer spec doesn't require authentication (i.e., pairing) be mandatory to use (bug 947060 comment 2)

Comment 2

[Stephanie Ouillon [:arroway] (needinfo me)]

In the case I have been testing, NFC wasn't involved. So I think there might be an issue with the way devices are unpaired and the paired devices list is maintained. If the user chose to unpair his phone with a device, he doesn't expect the device to reappear in the list without having going through the pairing process again.

Comment 3

[Tony Chung [:tchung]]

[Blocking Requested - why for this release]:

the user thinking they are unpaired with another device, should not be sending/receiving files anymore.  that is a potential security risk, and broken functionality.   

qawanted to see if this is a regression from 2.0

Comment 4

[Chris Kreinbring [:CKreinbring]]

The bug repros on Flame 2.2, 2.1, 2.0 and 2.0 base engineering with shallow flash.
Actual result: After unpairing from another device, the DUT will be re-paired with that device if it sends a file to the DUT.

Flame 2.2
BuildID: 20141027112840
Gaia: 0888735b2c5932624808147b85a60d698d9d7352
Gecko: da125623d9cb
Platform Version: 36.0a1
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Flame 2.1
BuildID: 20141027120841
Gaia: 7eb79fe53aff075fe36fb4dd12ab01558af0b3cd
Gecko: b58fcede2bec
Platform Version: 34.0
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.0
BuildID: 20141027083953
Gaia: 5e532a84e762b1bb6231756182cf1465671a061e
Gecko: 124f0bed1700
Platform Version: 32.0
Firmware Version: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 2.0 Base
BuildID: 20140904160718
Gaia: 506da297098326c671523707caae6eaba7e718da
Gecko: 
Platform Version: 32.0
Firmware Version: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 5

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Tony Chung [:tchung] from comment #3)
> [Blocking Requested - why for this release]:
> 
> the user thinking they are unpaired with another device, should not be
> sending/receiving files anymore.  that is a potential security risk, and
> broken functionality.   
> 
> qawanted to see if this is a regression from 2.0

1. The user still need to press 'OK' because confirmation dialog still shows up, if user needs to confirm again, will that be a security risk?
2. Android platform, OPP file transfer by default is authentication off. So from UX side, they only need to confirm once. Can you cross reference different devices?

Comment 6

[[e-mail], [e-mail]]

I suspect the unpaired device is not unpaired really because I see bug 1090041 recently. So that the phone still can receive file transferring request from the unpaired device. Just suspicion.

Comment 7

[Tony Chung [:tchung]]

(In reply to Shawn Huang [:shawnjohnjr] from comment #5)
> (In reply to Tony Chung [:tchung] from comment #3)
> > [Blocking Requested - why for this release]:
> > 
> > the user thinking they are unpaired with another device, should not be
> > sending/receiving files anymore.  that is a potential security risk, and
> > broken functionality.   
> > 
> > qawanted to see if this is a regression from 2.0
> 
> 1. The user still need to press 'OK' because confirmation dialog still shows
> up, if user needs to confirm again, will that be a security risk?
> 2. Android platform, OPP file transfer by default is authentication off. So
> from UX side, they only need to confirm once. Can you cross reference
> different devices?

So i agree that the user still needs to manually accept the button after trying to unpair.  less scary.  but the fact that i'm sitting here with a phone i thought i "unpaired", and you might be shooting over requests to send me files is freaky to the user.   

but given this isnt a regression, and the user needs to manually confirm the transfer, lets minus this for 2.1, but take it for 2.2 nom.

Comment 8

[howie [:howie]]

Triage: This is undefined UX behavior, not blocking. UX please help to consolidate the behavior. Also see bug 1066461, which is a conflict bug with this one.

Comment 9

[Jenny Lee]

Hi all, please see Bug 1066461 attachment 8521308 [details] for spec addressing issue described in this bug. User is allowed to receive file from unpaired device.Thanks!

Comment 10

[[e-mail], [e-mail]]

This is polishing issue for improving UX. A meaningful issue for fixing.

Comment 11

[Ben Tian (inactive)]

Per spec in comment 9, the latest m-c gecko allows receiving files from an unpaired device.

Resolve this bug as WFM.