#431: Serial API

Visit on Github.

Opened Oct 15, 2019

Hello TAG!

I'm requesting a TAG review of:

Further details:

  • Relevant time constraints or deadlines: The feature is targeting an Origin Trial in Chrome from versions 80 to 82 (February 2020 through June 2020). Assuming there are no implementation issues, developer or TAG feedback remaining to implement by the end of the trial a stable launch is planned for Chrome 83 (June 2020).
  • I have read and filled out the Self-Review Questionnaire on Security and Privacy. The assessment is here.
  • I have reviewed the TAG's API Design Principles
  • The group where the work on this specification is: WICG

We recommend the explainer to be in Markdown. On top of the usual information expected in the explainer, it is strongly recommended to add:

You should also know that...

I appreciate the effort the TAG puts into reviewing specifications. I am available to answer any questions and can participate in a live video chat to discuss the specification if desired.

We'd prefer the TAG provide feedback as (please select one):

  • open issues in our GitHub repo for each point of feedback
  • open a single issue in our GitHub repo for the entire review
  • leave review feedback as a comment in this issue and @-notify [github usernames]

Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.

¹ For background, see our explanation of how to write a good explainer.

Discussions

2019-11-19

Minutes

Dan: Ran into Suz from Stripe last week and she showed me why these APIs are so important from a maker perspective. It makes it so easy to get some hardware and configure/build your own gadget in contrast to the mass produced privacy infrigting gadgets from large companies. This is different than the enterprise perspective we have heard before. I would like to get her comment on this.

Kenneth: Sanwhan and me looked at that spec and it is in a bad shape, contradictory texts, empty tables. I talked to Reilly at CDS and he has been implementing it for blink and a polyfill on Web USB and is concentration on getting the functionality and API shape right and not on fixing the spec at this moment. He will file a clarifying note in the issue on what we would like feedback on.

Dan: Bump a week?

Ken: Sounds good

2019-11-26

Minutes

Ken: we got an update - haven't looked at it yet. they want to know about open / close, get and set signal, and readable / writable.

Ken: let's bump it

Dan: bump to after the f2f considering we have a lot to get through?

Ken: yes, [some description of how eatly this is and what is missing] I told Reilly at CDS about [what is missing]. Need some descriptions of what these methods and functions are...

Dan: Will reach out to some others as well

2021-01-Kronos

Minutes

Propose close

2021-02-08

Minutes

Sangwhan: it's proposed closed.

Dan: Let's close it at the plenary.

Samngwhan: WebXR hit test, Serial API, WebHID*, WebSocketStream, BackgroundSync, getinstalledrelatedapps -- all proposed closing.

Dan: I suggest we go through those and close them in the plenary.

Sangwhan: RTCICEtrnasport - i had a call with DOM on this and am doing work. TemporalProposal changed very recently.

Amy: FLOC API

2021-03-08

Minutes

Dan: provided feedback that they took concerns into account and documented in security considerations, about allow/blocklists of types of devices. I don't think we can say there's TAG consensus about adding to web platform, but that the API design is okay.

Yves: it's WICG, we will have another say as part of horizontal review. Okay to close now.

Dan: where after WICG? that is feedback we can give:

Hi @reillyeon we're happy with the API design as indicated and looking forward to hearing about the incubation experience within WICG. We'd also like to understand better where this work is intended to end up after WICG. Will this be going to a working group such as Devices and Sensors, for example? Also it remains a concern that Mozilla's position remains as *considered harmful.* We encourage you to work with them and other implementers on mitigation strategies against the issues they have raised.