From what I understood, MacOS will automatically trigger a pairing process when attempting to read/write a "protected" characteristic. @jeromelebel can you confirm?

Moving to a later milestone because we haven't seen folks trying to use the API with devices that need pairing.

#352 gives the UA the option of bonding while connecting. It seems like that's the best we can do, given the absence of a "request bonding" function on MacOS.

(Cross-referencing #346)

Moving to a later milestone because we haven't seen folks trying to use the API with devices that need pairing.

Sorry @jyasskin for that, at Logitech we do!!

Our BLE devices, talking there about existing mice and keyboards, implement HID over GATT service, that requires pairing. They also expose proprietary characteristic that does not always require bonding.

I successfully used web-bluetooth on Mac OS and Chrome OS (with few issues due to the stack or pending bugs). I opened an issue on Android (670281), that led to a discussion with @beaufortfrancois while you were OOO.

Of course my experience on Mac OS is also that here bonding is implicit, and is triggered by system upon insufficient privilege error.

@jracle: You mentioned that macOS works fine. Is it because macOS pairs as soon as it sees the HID services or does the website write to any characteristics that require pairing for which macOS initiates the procedure?

Here's what I get on macOS when connecting my MX Master mouse from https://googlechrome.github.io/samples/web-bluetooth/device-disconnect.html?namePrefix=MX:

...
Feb 01 10:44:09.240	ATT Send	FC:E9:FE:31:4E:62	0x0040	Read Request - Handle:0x0021
Feb 01 10:44:09.740	ATT Receive	FC:E9:FE:31:4E:62	0x0040	Error Response - Attribute Handle: 0x0021 - Error Code: 0x05
Feb 01 10:44:09.741	SMP Send	FC:E9:FE:31:4E:62	0x0040	LE SMP Pairing Request Command 
Feb 01 10:44:09.763	SMP Receive	FC:E9:FE:31:4E:62	0x0040	LE SMP Pairing Response Command 
Feb 01 10:44:09.764	SMP Send	FC:E9:FE:31:4E:62	0x0040	LE SMP Pairing Confirm Command 
Feb 01 10:44:09.785	SMP Receive	FC:E9:FE:31:4E:62	0x0040	LE SMP Pairing Confirm Command 
Feb 01 10:44:09.937	SMP Send	FC:E9:FE:31:4E:62	0x0040	LE SMP Pairing Random Command 
Feb 01 10:44:10.314	SMP Receive	FC:E9:FE:31:4E:62	0x0040	LE SMP Pairing Random Command 
Feb 01 10:44:10.438	HCI COMMAND	00:00:00:00:00:00	0x401C	[2019] LE Start Encryption - Connection Handle: 0x0040
Feb 01 10:44:10.439	HCI EVENT	00:00:00:00:00:00	0x0000	Command Status - LE Start Encryption
...

For info, full log are available at http://pastebin.com/raw/XS3xVMfM

The Error Code 0x05 is BLE_HCI_AUTHENTICATION_FAILURE which indicates that when macOS tries to discover all services/characteristics/descriptors, it stumbles upon one that requires authentication and simply triggers the SMP Pairing Request.

From what I can guess, the handle 0x0021 is the characteristic "HID Information" value, the first one declared in the HID GATT service.

• Conclusion: I think macOS always reads GATT Characteristics for the HID Service when it connects.
• Question: Shall we do the same on other platforms for consistency?

@Emill is that something you've experienced as well?

Thanks a lot for your findings @beaufortfrancois , you were quicker than me to try (I'm waiting for my new macbook pro.. with touchbar.. and enough disk space.. to come, hopefully I'll have enough space to debug)..

Indeed it seems that [CBCentralManager connect:...] attempts reading HID characteritics.

One thing in our case is that we can't act upon HID service, being black-listed by web-bluetooth.. I don't know if in that case we could make an exception on other platforms, attempting pairing if that service is encountered. That would make consistency across platforms, while still keeping the option to pair other services.

@jyasskin @scheib For the sake of consistency across OSes, shall we read HID characteristics when connecting to a device that contains a HID service? This would trigger a pairing request.

I agree with @scheib that the goal of Web Bluetooth should explicitly not be to pair a HID mouse/keyboard with the system, but rather allow websites to access common peripherals. https://webbluetoothcg.github.io/web-bluetooth/#security-and-privacy even blacklists a website to access HID characteristics. Note that anyone can create a peripheral that exposes both a HID service and a custom service, that is constructed so that what you write to the custom service is immediately echoed back on the HID service, i.e. you could control the user's keyboard or mouse over the web using web bluetooth if the user is near a device you have placed there, as long as the user is tricked into accepting the BLE connection. Such attacks can easily be done at public areas.

I don't think* Apple folks are doing this unintentionally. According to the WWDC 2013 - Session 703, it looks like the HID Over GATT Profile is special and built into the system so that it works just like with Bluetooth Classic devices.

So, you will be able to discover Bluetooth flow energy HID devices directly from the Bluetooth settings pane like a Bluetooth Classic would be.
And once you are paired with Bluetooth Energy HID Device, iOS will automatically manage the connection and reconnect to it if the connection goes away therefore giving this illusion that it works just like a normal Bluetooth device that customers are used to.

Moreover, Chrome OS already pairs BLE HID devices when connected from Web Bluetooth. We already submitted a patch to improve that experience.

Here's the current state. I'm sure you'll undestand why I'd love consistency there.

Thanks guys for your inputs!

@Emill I get your points concerning security hole we introduce here (mentionned here as well for the other readers). You also state in issue #346 that device could issue a pairing request to force host present system pairing dialog. That is also something to consider. Moreover, how does the rogue website would be served to user's machine? If it goes through physical web, it should be passed to Google's proxy for analysis no?

Now as @beaufortfrancois says, we also look for consistency across OSes. Also I think Apple just implemented what was defined in HOGP spec (done with Logitech back in 2011).