New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 649651 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Chrome
Pri: 1
Type: Bug

Blocked on:
issue 701992

Blocking:
issue 580406
issue 672263



Sign in to add a comment

bluetooth: IsPaired returns true for any connected device even those that don't support pairing.

Project Member Reported by ortuno@chromium.org, Sep 23 2016

Issue description

IsPaired() returns true if the device is paired or if the device is trusted. But any device for which we've called BluetoothDevice::Connect is marked as trusted[1] so we basically return true if we've connected to the device in the past even if the device doesn't support pairing.

This was done because in terms of UI there was no point in separating the concepts and at that point there were no other users of the API so it made sense. Now that there are other clients we should probably separate those two concepts.

When separating these two concepts we need to make sure clients that rely on this behavior e.g. System tray, are refactored as well.

Regarding security:

According to Luiz the Trusted property does not affect interactions with LE devices so we should be good on the Web Bluetooth side. But he advised that we should stop doing this.

profiles/input/device.c (for classic HID devices) and profiles/input/hog.c (for le HID devices) require authorization and the Trusted property only affects authentication.

[1] https://cs.chromium.org/chromium/src/device/bluetooth/bluez/bluetooth_device_bluez.cc?sq=package:chromium&dr=C&rcl=1474586563&l=740
 
Does this need to be Restrict-View-Google?

Comment 2 by ortuno@chromium.org, Sep 25 2016

Labels: -Restrict-View-Google
Blocking: 672263
Is anyone actively working on this issue as of now? This bug is blocking us (crbug.com/672263).
Noup. Feel free to send patches though :)
Cc: mcchou@chromium.org st...@chromium.org

Comment 6 by st...@chromium.org, Feb 7 2017

Cc: hennessywill@chromium.org xiaoyinh@chromium.org snanda@chromium.org
Labels: -Pri-3 M-58 Pri-1
Owner: mcchou@chromium.org
Status: Assigned (was: Available)
Miao, please take a look when you get a chance.

Hi Miao, have you had a chance to look at this bug yet? We need it for M59.
Cc: jlklein@chromium.org khorimoto@chromium.org jhawkins@chromium.org
Hi Miao, can you please provide a quick status update on this bug and when you roughly expect to resolve it? Thanks!
Status: Started (was: Assigned)
Cc: r...@chromium.org
Cc: -st...@chromium.org
The "trusted" is a BlueZ specific property that allows the remote device to be connected without authentication, and it is rw property in BlueZ, but currently we do not expose the write op to Chrome API.

The add "trusted" property is easy, but the hard part would be going through each clients of CrOS BT and make sure the change is adopted accordingly in their code.

Here are the action items for this issue:
0) Add IsTrusted to BlueZ device APIs. The implementation of other platforms should not be changed.
1) Modify existing unittests to address the change of excepted behavior.
2) Coordinate with function clients to make sure the above changes won't change the current behaviors. The clients include Web Bluetooth API, Chrome UI, ARC++ BT, Proximity.

0) and 1) should be in the same CL, and 2) should be taken care of separately.
fwiw: Web Bluetooth doesn't user IsPaired or IsTrusted but please make sure that DisconnectGATT keeps working as it is now.
Re#13,

Yes. Once separating Paired and Trusted, DisconnectGATT should call IsPaired instead, and nothing should change from Web Bluetooth perspective.
Blockedon: 701992
Status: Fixed (was: Started)
Cc: drustsm...@google.com
Is 2) in #12 also done?

Sign in to add a comment