Web Bluetooth Bug Fix and Enhancement

[Michael Duffy]

I would like to contribute to the Chrome project with a bug fix and enhancement for Web Bluetooth.

I am asking if anyone would be willing to help in this endeavor (general guidance by those who know the code well).  Please feel free to contact me directly:  mduf...@gmail.com

https://bugs.chromium.org/p/chromium/issues/detail?id=1269819

https://issuetracker.google.com/issues/206022560

Web Bluetooth Session Specific Pairing for Enhanced Security

The way pairing currently works in Web Bluetooth is that the JavaScript API will scan for a GATT server advertising a specific service UUID and then the list of available devices appears in a selection dialogue.

There is currently a bug in this process where multiple devices will be listed even though there is is just one device advertising the service.  I have entered a bug on this issue:

Issue 1269819: Web Bluetooth "Scanning..." / "wants to pair" Dialogue Reports Multiple Devices
https://bugs.chromium.org/p/chromium/issues/detail?id=1269819

Rather than having Chrome scan for all devices that are advertising a service based on a general service UUID, it would be incredibly MORE SECURE if the JavaScript method in the Web Bluetooth API could scan for a specific session UUID advertised by the GATT server on the local device.

This meets the specific use case where a user is interacting with a browser and his/her own mobile device; e.g., an Android application running a GATT server.  A server could send a specific session UUID to both the user's browser and his/her Android application.

This also would be helpful in the use case where a user registers a device (e.g., a blood pressure monitor, digital scale, etc.) and that device automatically pairs with the user's web application.  With each session a different session UUID would be sent to the device and confirmed by the web application based on a specif user

The current architecture that requires a  "Scanning..." / "wants to pair" Dialogue is incredibly inelegant.

The change to make this work would be incredibly simple.  Instead of:

    let device = await navigator.bluetooth.requestDevice({filters: [{services: [serviceUuid]}]});

The JavaScript method would be changed to:

    let device = await navigator.bluetooth.requestDevice({filters: [{sessUuid: [sessionUuid], message:[Start your Acme Blood Pressure device.]} ]});

Rather than a dialogue box being displayed for selection, the pairing would be automatic if the sessionUuids matched.

If no sessionUuid is being advertised, the default message would be displayed.

[Reilly Grant]

Filtering based on a session UUID seems like a reasonable feature request but automatically connecting to a device with a matching session UUID seems to be easily exploitable to create Bluetooth connections without the user's permission.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

--
You received this message because you are subscribed to the Google Groups "web-bluetooth" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-bluetoot...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-bluetooth/33264dc9-a2aa-4e71-a651-0b3af6b86920n%40chromium.org.

[Michael Duffy]

Good morning Reilly.

I hope you can offer some brief guidance.

I would like to focus on the simple use case of Chromium on Windows connecting to a GATT server running on a local Android device.

If a dynamically generated session UUID is sent to both the browser and the Android device the automatic pairing would be incredibly secure; in fact it would be more secure than a user picking the wrong device from the pairing list (perhaps from a nefarious neighbor).

I am exploring the Chromium source code and attempting to find the point in the code that triggers the Bluetooth pairing screen ("wants to Pair").

The JavaScript function 

      let device = await navigator.bluetooth.requestDevice({filters: [{services: [serviceUuid]}]});

triggers the screen and I assume launches an adapter that filters nearby devices .

Where in the code does this happen?

When I grep the code for "serviceUuid" I get 1,252 matches in 268 files.

When I grep the code for "service_uuid" I get 1,043 matches in 353 files.

It is a little overwhelming. Can you please provide some guidance?

Thx in advance.

 Mike

[Michael Duffy]

Found it.  Thx!

[Reilly Grant]

The core method you are looking for is WebBluetoothServiceImpl::RequestDeviceImpl().

As to the question of pairing using a session UUID. I agree that this helps resolve potential issues with nefarious devices attempting to trick the user into selecting them, however a core principle of the Web Bluetooth API permissions design is that the user needs to choose whether or not the site can connect to the device. It cannot be automatic, just as a site cannot automatically turn on your camera or microphone.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-bluetooth/a8dca3f4-5b95-4696-b1fa-7eef1813ab63n%40chromium.org.