[web-bluetooth] Handling readValue from protected/secure characteristics of not-yet-PIN-paired devices is underspecified (#563)

ariccio has just created a new issue for https://github.com/WebBluetoothCG/web-bluetooth:

== Handling readValue from protected/secure characteristics of not-yet-PIN-paired devices is underspecified ==
After a few days of looking at this, I believe that this is indeed an issue with the spec. [I understand PIN codes are a work in progress for the group](https://github.com/WebBluetoothCG/web-bluetooth/issues/555), and I hope you'll appreciate this.

Essentially, there's no *proper* way to recover when a call to a `readValue` on a characteristic fails because the PIN code has not yet been entered. In current Chrome Canary, this usually causes the promise to immediately reject with a `"NetworkError: Authentication canceled"`, even while the PIN dialog is still open, leaving the app without a promise to wait on for when the PIN is actually entered and full pairing completes. Manually reloading the page after entering the PIN works (of course), since the device is now correctly paired.

The most reasonable way I can think of to deal with this right now is to do the classic wrong thing: wait a few seconds and try again with a recursive retry countdown. I could simply as end users to reload the page after entering the PIN, but that friction is going to increase the bounce rate a lot. 

The Aranet4 is a BLE device (and quite a well built BLE device at that), which I suspect has something to do with it because of on the fly pairing. This, I strongly believe, is not a lower-level issue in the stack. If WinDbg is connected to chrome during the attempted `readValue`, the operating system emits a log message: `"The attribute requires authentication before it can be read or written."`, which indicates to me that everything below the browser is working correctly.

After reading through a couple thousand lines of chromium source and enough of the spec document, I think chrome's implementation is conforming with the draft standard, it's just not yet complete.

What would be the best behavior for a web bluetooth standard? Waiting for the PIN dialog to complete? A different type of exception raised to the user? A mechanism to check before calling `readValue`? 



#### Background, for the curious
- The aranet4 is a CO2 monitor that many aerosol scientists recommend as a high end consumer device, and have been recommending it's use as one possible COVID risk analysis tool. Lots of people around the world have been using it during the ongoing pandemic, and I've been working with them. I have an app to support these efforts (I'm not here to link/advertise it), but people currently have to enter data manually. The aranet4 supports bluetooth, and has good APIs for 3rd parties. [Sample code is available](https://kasparsd.github.io/sensor-pilot/) from @kasparsd. It was written before aranet added secure characteristics in the firmware.
- Chrome currently supports PIN pairing for this device on OSX, and IIRC it works fine in mainline with this app. [The chrome team has been working on it](https://bugs.chromium.org/p/chromium/issues/detail?id=960258), and PIN support now minimally works in canary.

Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/563 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 13 October 2021 20:54:01 UTC