Provide an option to bond device before connecting to device

[beaufortfrancois]

As you can read at https://bugs.chromium.org/p/chromium/issues/detail?id=670281#c18, it would be nice to provide an option to bond BLE device before connecting to device (especially on Android).

I see two options:

1. device.gatt.connect() always call Android function device.createBond before connecting.
2. device.gatt.connect({bond: true}) will call Android function device.createBond before connecting.

I think I would prefer 1 2. {bond: true} option.

[jracle]

Thanks for your input François!

I don't catch your last sentence, sorry. Which option do you prefer : 1 or 2 ?
It'd be simpler if bonding were triggered implicitly IMO.

Cheers

[Emill]

Automatic bonding might be good for some use cases (like mouse and keyboard) but should definitely not be default or mandatory. If one wants to bond one should be able to bond at any time (not need to decide before connection starts).

Also, Mac and iOS does not support programmatic bonding.

[beaufortfrancois]

@jracle I've updated my comment. Sorry for the confusion ;)

I guess @Emill suggests a third option:

3. device.createBond() will call Android function device.createBond before or after connection.

I'll let the other Web Bluetooth team members chime in.

[g-ortuno]

As @Emill points out we still have a problem with macOS :/

Also isn't this a duplicate of #137?

[jyasskin]

How's #352 look?

[Emill]

Not that I'm really a fan of Apple's principles, but Apple seems to like the idea to pair on demand rather than upon connection start. See https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf, paragraph 3.9, page 23:

The accessory should not request pairing until an ATT request is rejected using the Insufficient Authentication error code. See the Bluetooth 4.0 specification, Volume 3, Part F, Section 4 for details.

If, for security reasons, the accessory requires a bonded relationship with the Central, the Peripheral should reject the ATT request using the Insufficient Authentication error code, as appropriate. As a result, the Apple product may proceed with the necessary security procedures.

Similarly, if the iOS device acts as a Central and a GATT server, it may reject an ATT request using the Insufficient Authentication error code. The accessory should initiate the security procedure for pairing in response.

[jyasskin]

Yeah. We could ask @jracle to have their HID devices expose a characteristic that replies to reads with "Insufficient Authentication". Then their website would attempt to read that characteristic, triggering the pairing process on all platforms.

[jracle]

Hi @jyasskin ,

actually our BLE mice and keyboards implement 2 services : HID over GATT and a proprietary one.

The former expose characteristics that will trigger device replying with "Insufficient Authentication" when characteristic is accessed without security level required by peripheral. Mice will require encryption, and keyboards will require encryption + pass-key entry.

We've seen issues at stack level on Chrome OS, when pairing from web-page was failing to share connection with OS, and leaving web-page was disconnecting device. It has been fixed. Now on Android we need apparently to create bond at software level..

[beaufortfrancois]

I can confirm with my MX Master mouse the existence of the HID over GATT service (0x1812) and the proprietary service (00010000-0000-1000-8000-011f2000046d).

Since Web Bluetooth has blacklisted HID over GATT, websites can't trigger the "Insufficient Authentication" flow as characteristics are not accessible.

[beaufortfrancois]

For info, I'm able to see that the HID Information GATT Characteristic requires permission from nRF Connect:

W BtGatt.GattService: readCharacteristic() - permission check failed!

[jyasskin]

Yep. If the proprietary service had any characteristic that replied with "Insufficient Authentication", then the web page could trigger the bonding flow, which would then make the OS recognize the HID service. We may have a bug around that in Android, but once we fix the bug, you'd get consistent behavior across platforms. If we only have Android try to bond eagerly, you'll still need a different flow on Mac.

[Emill]

There is a simpler way to force pairing if no API is available if you control the peripheral. Just send an SMP Security Request when you need to pair. In the Flic firmware, we need to pair at a specific stage in our own custom protocol we run over BLE, so on iOS we write a specific value to a specific custom characteristic which makes the peripheral send the Security Request and iOS will pop up a pair dialog.

FYI I wrote some info regarding how HID works on Android at https://bugs.chromium.org/p/chromium/issues/detail?id=670281#c25.

[jracle]

Thanks guys for your replies! The UX we want to achieve with our input devices is, following advertisement of our website via Eddystone-URL, say, web-site opens, and user is able to configure his device from the web page. If device is not yet paired, pairing should happen. Reason for that push from ourselves is the pain people have to go to bluetooth settings (on various OSes), and perform a couple of operations, that can be handled simply by an app / website. That pain is reported in all of our consumer studies..

Now our BLE devices are in the field, lots of them with the characteristics I depicted above. Indeed, our proprietary characteristic doesn't require security,.. but that's on purpose : it serves both in applicative (I mean at firmware level) and bootloader mode, so that in latter mode, user can perform firmware update (signed / secured) without a need to pair device (having another pairing process happening + a device entry that will change at every firmware update and stay in his device list..).

I understand HID-over-Gatt had to be blacklisted for security reasons, but that'd be a stopper for us if we were not able to request bonding of device through web-bluetooth, specifically in Physical Web scenario.

[jhaenchen]

Is there any new info about how I should use HID devices over Bluetooth? It seems oh so very reasonable to use the HID protocol to do a million different things, many of which have nothing to do with audio streams or keyboard inputs.

chrome.hid won't allow you to interact with HID pages associated with keyboard or mouse input, but they will allow everything else. Can we allow a similar filtering system for web bluetooth?