Locking Ports

[reconbot]

27 brings in language about busy ports or ports in use by the system.

It should be noted that a "busy port" is not necessarily a locked port. Having two processes listen to the same port is very possible, osx, linux and windows. They allow sharing and locking of serialports by processes.

Different JavaScript contextes (different tabs, service workers, etc) accessing the same port might be a different situation altogether.

[larsgk]

...so should we work on reviving this WebSerial? (I am all for it if WebUSB doesn't deliver on USB Serial)

ontopic: The thing you are talking about (sharing port data) can give many problems - ranging from security/sniffing to corrupting the TX/RX buffers. One could consider something like "time share" but that would require some strict rules on the protocol implementation in the given client device. If you are talking about being able to observe data from many processes, it would still require some duplication of buffers (at least) and most probably some trust logic imposed on the listener side (e.g. no sniffing on crypto key HW)

[reconbot]

Call open() or CreateFile() from two different processes and you have two listeners. Most people don't want that but all operating systems support it. Multiple js contexts in a single browser is a different scenario and I think it's worth discussing.

offtopic: I've been maintaining node SerialPort for the past few months, so SerialPorts have been on my mind. With the recent announcement of chrome apps being end of lifed (outside of chromebooks), I'm worried about the existing educational tools that rely on having some sort of web SerialPort interface. Electron has been the most common goto for a "web based" SerialPort access but it's not possible to use that in most educational environments.

If the permissions model of WebUSB allows for arbitrary SerialPorts (which it isn't clear what will hapen) then I believe our work here would still be useful.

Long story short, I want this to be ready when we can make use of it.

[larsgk]

(last offtopic .. not to spam the thread ;)): .. we used node-serialport in http://www.empirikit.com/ - so I think we are aligned ;)

[monteslu]

@larsgk we should absolutely be reviving WebSerial. Echoing what @reconbot said, chrome.serial is being used in production in several applications. Aside from just communication, we're able to do things like write firmware to various microcontrollers with it.

WebUSB is a different beast entirely. In fact, it's not really a replacement for chrome.usb.

[marcoscaceres]

Aside from just communication, we're able to do things like write firmware to various microcontrollers with it.

That's unfortunately, and precisely, what killed Web Bluetooth from getting into Gecko (the ability to override firmware) :( "With great power...". Similar capabilities would doom this on the Web, as it would never get approved by Mozilla's security folks.

We need a better security story.

[monteslu]

Naw, it's fine. WebBLE/Webusb have a TLS requirement, user prompt for permission, user device selection dialog, and even goes as far as requiring dom event on the same tick.

Firmware writing is just standard rx/tx and signaling.

[reconbot]

I agree, its not a special privilege. If there's more security measures needed let's make an issue for it.

On Tue, Aug 23, 2016, 10:14 PM Luis Montes notifications@github.com wrote:

Naw, it's fine. WebBLE/Webusb have a TLS requirement, user prompt for permission, user device selection dialog, and even goes as far as requiring dom event on the same tick.

Firmware writing is just standard rx/tx and signaling.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/whatwg/serial/issues/35#issuecomment-241938530, or mute the thread https://github.com/notifications/unsubscribe-auth/AABlbph3xp06-ELTmOlpPNOpJvcpA5-xks5qi6j6gaJpZM4JrSmx .

[marcoscaceres]

WebBLE/Webusb have a TLS requirement, user prompt for permission, user device selection dialog, and even goes as far as requiring dom event on the same tick.

That wasn't enough for Mozilla 😭

I agree, its not a special privilege. If there's more security measures needed let's make an issue for it.

Ok, but we need to then be prepared to argue that with implementers later on. As I mentioned, both Web Bluetooth (and also Web USB) have been rejected by Mozilla's security teams. It will be hard for me to champion this internally unless we, as community, can argue that this won't brick any devices.

If there's more security measures needed let's make an issue for it.

That would be good.

[larsgk]

Two things I felt we missed last time this spec was worked on are:

1. user stories (simple ones, e.g. "As a larger HW/SW vendor with legacy USB CDC devices already in the market...", "As an arduino hobbyist....",) to help scope ease of use, feasibility of using e.g. certificates for listing/connections, etc.

2. reference apps using a polyfill to let people play with it before it's even in the code (could polyfill on top of chrome.serial [for now ;)], a webSocket bridge or other)

   ...this actually goes for most HTML specs..too much waterfall in the spec'ing ;)

[fbender]

I'm all in favor for aggressively locking a port to an origin and a particular handle (i.e. API consume) when in use, at least in the first iteration/version of the spec. We can later extend it with language (and a mechanism) for concurrent access if needed. I for myself see no particular reason to allow it – if you need to access a serial port from multiple "tabs" (of the same origin), put the consumer into a Shared Worker or Service Worker and talk to the worker instead.

I would even think about limiting the API to a Service Worker (at least in the first iteration) since their lifetime is different from a website's one and we may be able to prevent prematurely closing a connection while writing … (also see below.)

I agree, its not a special privilege. If there's more security measures needed let's make an issue for it.

Ok, but we need to then be prepared to argue that with implementers later on. As I mentioned, both Web Bluetooth (and also Web USB) have been rejected by Mozilla's security teams. It will be hard for me to champion this internally unless we, as community, can argue that this won't brick any devices.

The goal of the API is to expose Serial Rx/Tx. If that happens to allow to flash firmware, then there's no way around that (it cannot be detected and distinguished from other data streams by any means).

If you are concerned about bricking, then I'd advise to add some form of leightweight transaction system to the writing part of the API, i.e. you have to create a stream of data that you then commit, i.e. it is sealed and handed to the writer API, which is flushed in one piece to the port/OS buffer via the user agent's internals. That may not be ideal for some use cases, so you still need a "regular" streaming API. But having a transactional API would be nice for the flashing use case.

[tzikis]

@larsgk there are already various apps using the (to be deprecated?) chrome.serial.* API. couldn't we just use these instead?

In terms of security, I don't see any way going forward to satisfy Mozilla's security team, and the -often reasonable, sometimes not*- paranoia surrounding Web API vulnerabilities, without severely crippling the API and making it a moot point.

I wonder, would it make sense to have the WebBLE, WebUSB & WebSerial APIs offered for signed extensions provided by the Mozilla/Chrome store, in a way that they can be disabled/blacklisted?

*in this case unreasonable, and mostly because the web/sec people are paranoid because of lack of knowledge of how hardware works, IMHO

[larsgk]

@tzikis I think the chrome.serial API is great (and stable) but has a few things we might want to change, e.g. it works very "singleton-ish" where we might want promises in stead.

About blacklisting: It might not be a bad idea that HW vendors who know they don't want a webapp to be able to reach their HW could just add VID/PID combos to a common blacklist that has to be respected. That leaves everyone else with a nice and easy API. There might be one exception though: solutions using FTDI, STM, etc. chips that share VID/PID with a huge range of other devices (some may want blacklisting and some don't) will require a bit more brainstorming. One option could be to also always require user acceptance the first time a website wants to access any device - and hope that's enough. Another option could be to also require trusted certificates (green lock https) or localhost - something similar to https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features

For FTDI/STM-chip solutions, there will never be a completely 100% secure solution that also is easy to use/implement for legacy HW - but to get industry adoption, we can't just make it impossible to do like seems to be the case with the currently proposed WebUSB.

[tzikis]

yeah, and just to add that the same thing goes with physical Serial devices, and possibly Serial-over-Bluetooth as well

we shouldn't assume that a serial device will have a known, unique VID/PID, because that's simply not the case

and yes, a blacklist seems like a sane way. the same goes for HTTPS-only etc, and user-prompt too, but like @marcoscaceres the problem is that the Mozilla (and AFAIK, Google) security teams didn't deem them good enough. that's why I suggested providing the API to extensions with a way to disable them as a possible compromise

[reconbot]

@larsgk I've created #36 for user stories

@marcoscaceres I've created #37 for Security Concerns

Back to locking;

@fbender I like your idea of keep ports both system locked and tab locked ("context" locked?) and allowing an opening up of them later. I think ensuring the browsers close the ports when their objects go out of scope will solve most issues around this approach.

I don't think it's necessary to limit "the API to a Service Worker" as that increases the complexity of using a SerialPort and most devices will pick up where they left off on reconnection. Allowing people to make use of a service worker to manage a SerialPort between multiple tabs/windows is a good idea.

[lyzadanger]

@fbender

I would even think about limiting the API to a Service Worker (at least in the first iteration) since their lifetime is different from a website's one...

On the one hand, I think this all fits with some of the other APIs that are being grouped under the SW umbrella.

On the other...I wonder what real-world usage will feel like. A lot of device hackery goes on on local networks. The overhead of getting TLS going with a self-signed cert that, say, Chrome will tolerate requires a grody amount of hackery (and client config as well). For example, I recently thought Aha! I will implement WebPush* locally on a little dev board capable of running a Node.js webserver. Boy, howdy, was that hard because of the HTTPS wrangling.

I mean, the ServiceWorker-family approach does sort of feel natural. But I'm curious as to thoughts about what the workflow would look like for your average dev.

Obviously, I'm a developer end-user, not knowledgeable about serialport stuff beyond the very basics. :)

* another API that requires the use of a ServiceWorker

[monteslu]

If you are concerned about bricking, then I'd advise to add some form of leightweight transaction system to the writing part of the API, i.e. you have to create a stream of data that you then commit, i.e. it is sealed and handed to the writer API, which is flushed in one piece to the port/OS buffer via the user agent's internals. That may not be ideal for some use cases, so you still need a "regular" streaming API. But having a transactional API would be nice for the flashing use case.

This might be a non-starter for programming microcontrollers via serial. Many boards require control signaling, changing baud rates, and precise timing over bi-directional streams. If I understand what you proposing, I'm not sure how that translates into a transaction.

[reconbot]

I also don't think a transactional api as part of the core is necessary or safer, a pull stream interface perhaps (eg, read x number of bytes and then stop reading please) but as discussed in the security issue #37 there's no way to separate out signaling from regular communication as it's up to the device to provide their own protocols for such things.

I'm going to close my issue and open another one about locking with regards to port lifecycles and scope #38

[fbender]

Many boards require control signaling, changing baud rates, and precise timing over bi-directional streams.

That is good to know. May you please add specific and extensive examples to the ticket about use cases (I think it's #36 but I can't check right now)? Please make sure you include precise timing requirements since we need to add that to the spec (to ensure broadest compatibility)!

I'm kind of thinking about a dedicated "Device Worker" now to ensure low latency, similar to Script Workers of the WebAudio API. Maybe generalize that concept into a general-purpose "low latency worker" and derive from that to add lifetime guarantees to reduce the risk of bricking … but that's probably overkill for WebSerial as I assume the timing requirements are not that bad, likely not more strict than the 16ms-display-rule. But please enlighten me if I'm wrong!

If I understand what you proposing, I'm not sure how that translates into a transaction.

It doesn't, hence we need a regular streaming API nonetheless. Easiest way to add some sort of transactional API would be to have e.g. holdBuffer(bool on_off) and flushBuffer() methods that allow you to prepare a write and only sending it to the device in one continuous chunk. Though User Agents could probably provide better optimizations if this extra feature API were to be "truely" transactional (NB. rollbacks are obviously impossible to implement on a browser level).