Bluetooth RFCOMM in Web Serial API

[nondebug]

こんにちは TAG-さん!

I'm requesting a TAG review of Bluetooth RFCOMM in Web Serial API.

The Bluetooth RFCOMM (Radio frequency communication) protocol provides emulated RS-232 serial ports. This feature would enable applications to make connections to RFCOMM services on paired Bluetooth Classic devices using the Web Serial API.

• Explainer: https://github.com/WICG/serial/blob/main/EXPLAINER_BLUETOOTH.md
• Specification URL: https://wicg.github.io/serial/
• Tests: In progress
• User research: N/A
• Security and Privacy self-review: https://github.com/WICG/serial/blob/main/security-privacy-questionnaire-bluetooth-rfcomm.md
• GitHub repo (if you prefer feedback filed there): File feedback on this issue
• Primary contacts (and their relationship to the specification):
  • Matt Reynolds (@nondebug, Google Chrome)
• Organization(s)/project(s) driving the specification: Google Chrome
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • Gecko: Negative signals (Request for position on Serial API mozilla/standards-positions#336 Re-request for postion on Web Serial/Serial API mozilla/standards-positions#687)
  • WebKit: Negative signals (https://webkit.org/tracking-prevention/ Web Serial API WebKit/standards-positions#199)
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): Chrome Status: Web Serial support for Bluetooth RFCOMM services

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: We expect to start an experiment with this feature in Chrome 116
• The group where the work on this specification is currently being done: WICG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): Device & Sensors Working Group
• Major unresolved issues with or opposition to this specification:
  • Apple and Mozilla are both opposed to Web Serial API
• This work is being funded by: Google Chrome

You should also know that...

The feature can be enabled in Chrome 116 with the flag chrome://enable-bluetooth-spp-in-serial-api.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @nondebug

[cynthia]

We discussed this during our vF2F today - we can see the appeal of WebSerial (at least the somewhat niche use cases where it could be useful), but had a hard time coming up with a compelling user story where this would get mass adoption. What would be a use case (that is appealing to a reasonably large group of users)?

[tomayac]

We discussed this during our vF2F today - we can see the appeal of WebSerial (at least the somewhat niche use cases where it could be useful), but had a hard time coming up with a compelling user story where this would get mass adoption. What would be a use case (that is appealing to a reasonably large group of users)?

Would LEGO® using this API in their kits count as "compelling user story where this would get mass adoption"?

[maxpassion]

We discussed this during our vF2F today - we can see the appeal of WebSerial (at least the somewhat niche use cases where it could be useful), but had a hard time coming up with a compelling user story where this would get mass adoption. What would be a use case (that is appealing to a reasonably large group of users)?

Would LEGO® using this API in their kits count as "compelling user story where this would get mass adoption"?

Hi @tomayac, in this use case, the Web Serial API is used when connected via USB? If so, it seems did not justify why Serial via Bluetooth is needed.

[tomayac]

Hi @tomayac, in this use case, the Web Serial API is used when connected via USB? If so, it seems did not justify why Serial via Bluetooth is needed.

That's correct. LEGO does not qualify as a use case in this context, sorry for my confusion.

[scheib]

Re cynthia, maxpassion: "compelling user story where this would get mass adoption": I've already seen this by walking into a school and seeing https://vex.com robotics being used - they're used widely. Google also showcased the similar https://spike.legoeducation.com/ this year at Google IO & Connect events.

People expect computing technology to work, even if infrequently. Serial has a variety of applications from education, home automation, enterprise/industrial, maker, and common consumer devices. These range from frequent daily use (e.g. point of sale devices, inventory tools, industrial sensors) to infrequent (e.g. configuration of consumer devices).

In the TPAC 2022 Breakout session Device APIs (Bluetooth, HID, Serial, USB) slides (PDF copy) I discuss the adoption at a larger scale. In the year since that presentation Serial usage has peaked at more than 4 times the usage we'd seen previously.

Bluetooth RFCOMM is a request the Chrome team has had from multiple partners, the top two that come to mind are in education and consumer devices, with weekly and monthly frequency use cases respectively, both from highly recognized global brands. Their devices already use Bluetooth RFCOMM protocol and they won't be changing the hardware/firmware for these. For the web to meet the need we are implementing this approach. The alternative is that developers like these meet the user's needs with e.g. windows apps or fail to meet the needs on Chromebooks. Even on Windows, partners indicate the high value of e.g. not requiring teachers/children to try to install and manage other applications vs just using the web app.

[torgo]

Hi @scheib thanks for that. There's no doubt that communicating with devices, particularly in an educational context as you've elaborated, is a compelling use case for computers. Clearly, however, there is a difference of opinion amongst implementers about whether web applications should be empowered to make such connections.

We've reviewed the Web Bluetooth API positively.

We've also reviewed the web serial API - for which we recognized the use case but also we expressed concerns about multi-stakeholder support.

Speaking personally, I'm a big supporter of these APIs. I've personally demonstrated Web Bluetooth on stage at developer events. I fully get it. However, as TAG I have to acknowledge that the development of these capabilities has not brought other implementers along.

Putting aside the multi-stakeholder considerations, we're not clear on some aspects of the user flow and permission model. The explainer could benefit from spelling out how a device gets connected, how the permissions are requested, etc... ?

[torgo]

As reflected in our minutes from 09-25 week we are closing this as "satisfied with concerns." We're happy with the design and we understand the user need. We remain concerned about the lack of overall support for the underlying web serial and web bluetooth specs themselves. We'd like to encourage you to do more to builld consensus around these specs with other browsers / browser engine makers.