On Tue, Aug 1, 2023, 06:01 Balazs Engedy <[email protected]> wrote:
> For clarity, are the per-device permissions persisted across visits? If > so, what device attribute(s) do we use to form a device identifier to key > that permission on? > Yes, the Bluetooth device MAC address. On Thursday, July 27, 2023 at 7:06:37 PM UTC+2 Reilly Grant wrote: > >> That behavior is to be expected. The "2" and ":59:NN PM" are being >> received as separate events based on how the converter chips decide to pack >> serial data (which arrives one byte at a time) into Bluetooth or USB >> packets which contain multiple bytes. >> Reilly Grant | Software Engineer | [email protected] | Google Chrome >> <https://www.google.com/chrome> >> >> >> On Thu, Jul 27, 2023 at 9:02 AM Mike Taylor <[email protected]> >> wrote: >> >>> LGTM1 to ship. >>> >>> (I'll leave you to figure out why the BT Serial port sometimes sent >>> "2:59:NN PM" and sometimes received ":59:NN PM" :)) >>> On 7/26/23 6:15 PM, Matt Reynolds wrote: >>> >>> Here's a short demo video that shows the permission UI: >>> >>> https://drive.google.com/file/d/1Y_Ito9P-EourYa7ofL_qQMOmmvBIhwpT/view >>> >>> Demo source: >>> >>> https://nondebug.github.io/bluetooth-serial-port-demo/ >>> >>> Off-screen I connected a HC-06 wireless Bluetooth serial transceiver >>> <https://amzn.com/dp/B01FCQZ8VW> to a USB serial adapter >>> <https://amzn.com/dp/B07BBPX8B8>. The demo uses Web Serial API to >>> connect to both devices, then sends data over USB and shows that it is >>> received from the HC-06 over Bluetooth. >>> >>> >>> On Wed, Jul 26, 2023 at 2:13 PM Mike Taylor <[email protected]> >>> wrote: >>> >>>> LGTM1 - thanks for the well-written explainer. >>>> On 7/26/23 4:20 PM, Alex Russell wrote: >>>> >>>> Sounds good; thanks for explaining. >>>> >>>> On Wednesday, July 26, 2023 at 1:02:00 PM UTC-7 Reilly Grant wrote: >>>> >>>>> On Wed, Jul 26, 2023 at 10:03 AM Alex Russell < >>>>> [email protected]> wrote: >>>>> >>>>>> A screenshot would go a long way. >>>>>> >>>>>> Exciting to hear there's a partner that want this. >>>>>> >>>>>> Also, was there consideration of an OT? A strong reason to avoid? >>>>>> >>>>> >>>>> The change to the API is very small and we had strong developer >>>>> feedback during development that the API worked for them. I also feel that >>>>> this kind of feature is a poor fit for an Origin Trial because it's not >>>>> something where you can measure the impact with or without the capability >>>>> as the capability is fundamentallyﾠnecessary for the existenceﾠof the web >>>>> app. At that point the only benefit of an OT would be to ship an end-user >>>>> application early, but it wouldn't be a true experiment. >>>>> >>>>> >>>>>> On Wednesday, July 26, 2023 at 9:55:25 AM UTC-7 Reilly Grant wrote: >>>>>> >>>>>>> On Wed, Jul 26, 2023 at 9:05 AM Alex Russell < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> I'm going to have to stay recused on this vote, but just want to >>>>>>>> lend my fullest non-voting support to shipping ASAP. This is excellent >>>>>>>> work, and I can see you've dotted i's and crossed t's in anticipation >>>>>>>> of a >>>>>>>> full shakedown here. Thanks for doing it. >>>>>>>> >>>>>>>> It might be helpful for others evaluating the proposal to have a >>>>>>>> demo or video to look at regarding the permissions UI/UX that this >>>>>>>> will sit >>>>>>>> behind; is it possible to add something like that to your Explainer? >>>>>>>> And >>>>>>>> are there users who can vouch for the utility of this feature for their >>>>>>>> use-cases? >>>>>>>> >>>>>>> >>>>>>> Unfortunately the hardware our partner is working on is still >>>>>>> confidential so I can't share a real-worldﾠuse case. They're very >>>>>>> excited >>>>>>> about being able to use a web app. We can put together a demo video >>>>>>> with a >>>>>>> generic Bluetooth serial device but it will be pretty boring because >>>>>>> theﾠpermissions UIﾠlooks identical toﾠselecting a wired serial port. We >>>>>>> only support connecting to devices that are already paired with the >>>>>>> system >>>>>>> so it doesn't use the more complex scanning UX that you see for Web >>>>>>> Bluetooth.ﾠﾠ >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> On Tuesday, July 25, 2023 at 1:47:30 PM UTC-7 [email protected] >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Contact emails >>>>>>>>> >>>>>>>>> [email protected], [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>>> Explainer >>>>>>>>> >>>>>>>>> https://github.com/WICG/serial/blob/main/EXPLAINER_BLUETOOTH.md >>>>>>>>> >>>>>>>>> Specification >>>>>>>>> >>>>>>>>> https://github.com/WICG/serial/pull/189 >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> Support Bluetooth RFCOMM services in the Web Serial API. The >>>>>>>>> Bluetooth RFCOMM (Radio frequency communication) protocol provides >>>>>>>>> emulated >>>>>>>>> RS-232 serial ports. This feature enables applications to make >>>>>>>>> connections >>>>>>>>> to RFCOMM services on paired Bluetooth Classic devices using the Web >>>>>>>>> Serial >>>>>>>>> API. >>>>>>>>> >>>>>>>>> Blink component >>>>>>>>> >>>>>>>>> Blink>Serial >>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESerial> >>>>>>>>> >>>>>>>>> TAG review >>>>>>>>> >>>>>>>>> https://github.com/w3ctag/design-reviews/issues/854 >>>>>>>>> >>>>>>>>> TAG review status >>>>>>>>> >>>>>>>>> Pending >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> Web Serial API is only implemented in Chromium. Other browser >>>>>>>>> vendors have expressed negative views regarding the API and are >>>>>>>>> unlikely to >>>>>>>>> implement it. >>>>>>>>> >>>>>>>>> This feature will not affect compatibility in existing apps. The >>>>>>>>> feature only adds support for connecting to new types of devices. >>>>>>>>> There are >>>>>>>>> no changes for currently-supported devices. >>>>>>>>> >>>>>>>>> Gecko: Negative ( >>>>>>>>> https://github.com/mozilla/standards-positions/issues/687) >>>>>>>>> Previous thread: >>>>>>>>> https://github.com/mozilla/standards-positions/issues/336 >>>>>>>>> >>>>>>>>> WebKit: Negative ( >>>>>>>>> https://github.com/WebKit/standards-positions/issues/199) See >>>>>>>>> also: https://webkit.org/tracking-prevention/ >>>>>>>>> >>>>>>>>> Web developers: Positive ( >>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1043300) >>>>>>>>> Other Web developers have asked for this feature privately. >>>>>>>>> >>>>>>>>> Other signals: >>>>>>>>> >>>>>>>>> >>>>>>>>> Activation >>>>>>>>> >>>>>>>>> Developers can take advantage of this feature immediately. A >>>>>>>>> polyfill is not possible because Bluetooth Classic devices cannot be >>>>>>>>> accessed through any other web platform API. >>>>>>>>> >>>>>>>>> Security >>>>>>>>> >>>>>>>>> See >>>>>>>>> https://github.com/WICG/serial/blob/main/security-privacy-questionnaire-bluetooth-rfcomm.md >>>>>>>>> and Security Considerations in >>>>>>>>> https://github.com/WICG/serial/blob/main/EXPLAINER_BLUETOOTH.md >>>>>>>>> >>>>>>>>> WebView application risks >>>>>>>>> >>>>>>>>> N/A >>>>>>>>> >>>>>>>>> >>>>>>>>> Debuggability >>>>>>>>> >>>>>>>>> Debuggability is identical to wired serial ports. >>>>>>>>> >>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>> >>>>>>>>> No, this feature will be supported on desktop platforms only to >>>>>>>>> begin with, matching the existing state of support for the Web Serial >>>>>>>>> API. >>>>>>>>> Support for Android could be added in the future since unlike USB >>>>>>>>> serial >>>>>>>>> devices, Android provides an API for Bluetooth RFCOMM. >>>>>>>>> >>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> No, the majority of this extension to the API is implemented in >>>>>>>>> the browser process (connecting to Bluetooth devices through the >>>>>>>>> native >>>>>>>>> platform APIs) and so isn’t testable with WPT. >>>>>>>>> >>>>>>>>> Flag name >>>>>>>>> >>>>>>>>> chrome://flags#enable-bluetooth-spp-in-serial-api >>>>>>>>> >>>>>>>>> Requires code in //chrome? >>>>>>>>> >>>>>>>>> Yes >>>>>>>>> >>>>>>>>> Tracking bug >>>>>>>>> >>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1043300 >>>>>>>>> >>>>>>>>> Launch bug >>>>>>>>> >>>>>>>>> https://launch.corp.google.com/launch/4232649 >>>>>>>>> >>>>>>>>> Estimated milestones >>>>>>>>> >>>>>>>>> 117 >>>>>>>>> >>>>>>>>> Anticipated spec changes >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> >>>>>>>>> https://chromestatus.com/feature/5686596809523200 >>>>>>>>> >>>>>>>>> Links to previous Intent discussions >>>>>>>>> >>>>>>>>> Intent to prototype: >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/kOOZ3RIh0Ik >>>>>>>>> >>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>> <https://chromestatus.com/>. >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/07d9fd57-e4c6-49d9-afac-5adc1c905eabn%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/07d9fd57-e4c6-49d9-afac-5adc1c905eabn%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMZfB1NqbXRQj1MC50k3ga0QZTtqNBgpdg_k0fkG77j0NQ%40mail.gmail.com.
