Re: Intent to Ship: Web Serial API

[Fergal Daly]

[+bfcache-dev]

Hi Reilly,

how does WebSerial interact with Chrome's BFCache? Can we make it so that a page that has an open serial connection can safely be put into BFCache and will work when it comes out without breaking user expectations (that they had navigated away from the page)? If not, we need to ensure that pages using WebSerial do not go into BFCache when it would be a problem.

We have put together a doc that hopefully provides enough information for feature teams to figure this out. Could you take a look and figure out what issues there may be? It's a new doc so feedback on the doc itself is also appreciated. 

The simplest course of action is to blocklist all pages that use WebSerial but ideally we can ensure that they work well together. Thanks,

F

On Saturday, December 5, 2020 at 10:16:03 AM UTC+9 Reilly Grant wrote:

Contact emails

rei...@chromium.org

Explainer

https://github.com/WICG/serial/blob/gh-pages/EXPLAINER.md

Specification

https://wicg.github.io/serial/

API spec

Yes.

Design docs

https://web.dev/serial/

Summary

The Serial API provides an interface for connecting to serial devices, either through a serial port on the user’s system or removable USB and Bluetooth devices that emulate a serial port. This API has been requested by the hardware developer community, especially developers building educational tools, as a companion to the WebUSB API because operating systems require applications to communicate with USB-based serial ports using their higher-level serial API rather than the low-level USB API. It also supports non-USB serial ports.

We are requesting a gapless transition from Origin Trial to stable release for the API in order to prevent developers from having to deploy non-web versions of their applications to cover the gap. Throughout the trial we have asked developers to adapt to changes in the API, to which they have been very responsive. There will be one more such change made as part of shipping, which is the following:

As of Chrome 89 the SerialConnectionEvent interface has been removed. When a “connect” or “disconnect” event is fired the target is the SerialPort interface itself (it bubbles to navigator.serial) and so the port can be accessed as e.target instead of e.port.

Blink component

Blink>Serial

TAG review

https://github.com/w3ctag/design-reviews/issues/431

TAG review status

Pending

Link to origin trial feedback summary

https://docs.google.com/document/d/1vcjw-9q14Sr9v7ce3YR5gGzamykv_0Gbv4TDqGPdZCQ/edit

Risks

Interoperability and Compatibility

Gecko: Negative (https://mozilla.github.io/standards-positions/#webserial)

WebKit: Negative (https://webkit.org/tracking-prevention/)

Web developers: Strongly positive (https://discourse.wicg.io/t/serial-api-moving-from-web-of-sensors-cg-to-web-incubator-cg/2940)

Debuggability

Developers are able to debug script using this feature using the existing DevTools console and debugger. For debugging device communication issues it is often convenient to use the tee() method provided by the ReadableStream to split the streams going to or from the device and print them to the console for inspection.

Is this feature fully tested by web-platform-tests?

Partially. WebIDL conformance and Permissions Policy tests are already upstreamed. More extensive Web Platform Tests have been prototyped in the Chromium wpt_internal directory and should be exportable to upstream Web Platform Tests by leveraging the work that Robert Ma has done on standardizing how we implement Mojo-based test-only APIs. This will be completed ASAP.

Tracking bug

https://crbug.com/884928

Launch bug

https://crbug.com/967863

Sample links

https://googlechromelabs.github.io/serial-terminal

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6577673212002304

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/GcqEnSW5yHs/r7G3iMmDCQAJ

Intent to experiment #1:

https://groups.google.com/a/chromium.org/g/blink-dev/c/AiGJihoCbl4/m/OmA24108DwAJ

Intent to experiment #2:

https://groups.google.com/a/chromium.org/g/blink-dev/c/P5uKC_HTStw/m/VjYdUfg-BQAJ

Intent to experiment #3: https://groups.google.com/a/chromium.org/g/blink-dev/c/NGgprfPEbG0/m/nhNCiN0ZBgAJ

This intent message was generated by Chrome Platform Status and edited by hand.

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

[Reilly Grant]

I've met with the BFCache team to figure out how to support BFCache with WebUSB, and supporting it with Web Serial will have similar challenges. I've filed https://github.com/WICG/serial/issues/109 to track defining the integration points so that we can avoid continuing to blocklist all pages that are using Web Serial as we currently do.

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

[Fergal Daly]

Thanks!

F

[yo...@yoav.ws]

LGTM1

This seems like an important addition to the web platform, that enables unique use-cases that were previously reserved to native apps, with their associated deployment pain. Thanks for working on this!!

[Mike West]

LGTM2.

Similar to the WebHID API, I'm happy with the work the team has done to address security and privacy concerns. The interaction model has proven effective, there's a good story around user-facing indicators, and we have the ability to cut off access to devices when that proves to be particularly dangerous. The implementation puts the user in control, and I'm excited to see it launch.

With regard to the gapless OT, there's good evidence of developer feedback, and equally good evidence that the API has changed in response. Given that we have confidence in the shape of the API, it seems reasonable to me to move it directly from OT to stable without enforcing a gap in availability. So, that bit specifically LGTM.

-mike

[Chris Harrelson]

LGTM3

--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38f9b23b-2c71-4556-9337-e97b4f206b1en%40chromium.org.

[Reilly Grant]

On Thu, Dec 17, 2020 at 12:00 PM Mike West <mk...@chromium.org> wrote:

LGTM2.

Similar to the WebHID API, I'm happy with the work the team has done to address security and privacy concerns. The interaction model has proven effective, there's a good story around user-facing indicators, and we have the ability to cut off access to devices when that proves to be particularly dangerous. The implementation puts the user in control, and I'm excited to see it launch.

A nuance from the "Security considerations" section of the specification that may have been missed in your analysis is that while we can implement a block list for USB serial devices in particular because of the out-of-band identifiers that USB provides there is no solution for generally blocking access to any serial device (such as one connected via a generic adapter) as the serial protocol itself does not provide a means to identify the connected device.

[Mike West]

Thanks, Reilly! I framed this comment poorly, and I appreciate the clarification.

I meant to convey my understanding is that serial-over-{USB,Bluetooth} runs any available vendor and product IDs through the same blocklist as WebUSB and Web Bluetooth, giving us some ability to mitigate risk for identifiable devices. Is that accurate?

In cases where these identifiers are either generic or unavailable (in the case of "actual" serial ports soldered to a board), we're relying on direct user control via the chooser-based UX as the primary mitigation.

-mike

[Reilly Grant]

On Thu, Dec 17, 2020 at 10:50 PM Mike West <mk...@chromium.org> wrote:

Thanks, Reilly! I framed this comment poorly, and I appreciate the clarification.

I meant to convey my understanding is that serial-over-{USB,Bluetooth} runs any available vendor and product IDs through the same blocklist as WebUSB and Web Bluetooth, giving us some ability to mitigate risk for identifiable devices. Is that accurate?

In crrev.com/c/2613792 I have implemented a Web Serial-specific blocklist which currently only supports matching against USB devices but is extensible to Bluetooth and other device types. There are platform limitations preventing us from recognizing useful properties of Bluetooth devices at the moment. This is something we can work on going forward and will likely be unblocked by work to improve support for Bluetooth serial devices in crbug.com/1043300.

[Reilly Grant]

Do API OWNERS approve the requested gapless transition from Origin Trial to stable?

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

[Chris Harrelson]

Yes, gapless LGTM, per what Mike said.

[كورونا كورونا‎]

--

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 blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMbt1NbytkDMXtdXtZDmabga498HzNxQuvdrzEehGFP0Jg%40mail.gmail.com.

[Reilly Grant]

Thanks. Over the holidays I forgot that he'd already approved it.

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

[Nick Bond]

Is this ready for production use now or is it still experimental? Will the Spec change?

Thanks!

Nick

[Reilly Grant]

Yes, this API is ready for production use. The specification may change but only in ways that align with our principles, which focus on maintaining compatibility with existing web content. The folks on this thread who gave me the original LGTMs to ship this API will hold me to that.

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

[Nick Bond]

Great news! Excellent work to you and your team on this one. You're helping to bring the native experience to the web.