Re-request for postion on Web Serial/Serial API

[NODeeJay]

Since #336 overheated and got closed by @bgrins, also my re-request #336 (comment) on the position got closed.

Based on https://github.com/mozilla/standards-positions/blob/main/CONTRIBUTING.md I am hereby asking Mozilla / @martinthomson to update the position on this topic.

Why:
Many solutions have been provided in the meantime to fulfill this request in a secure and safe way, and also many ways of securing the access itself. Hiding these settings for the experienced users is a better way of implementation, than no implementation at all, for example:

• about:config
• yes I understand the risks.
• Activate WebSerial, WebUSB, Web....
• only activate for SSL sites
  • ignore invalid certificates or present a "I understand the risk page" when an invalid certificate is presented
• only activate in local networks
• only activate for whitelist IP/hostname
• activate for all but blacklist IP/hostname
• or generally the same list of exceptions like for "unsafe" pages
• limit to the following COM ports/port range (this prevents access to system internal devices at all) or
• exclude the following COM ports

Furthermore, I am pointing out your core values:
Our mission is to ensure the Internet is a global public resource, open and accessible to all. An Internet that truly puts people first, where individuals can shape their own experience and are empowered, safe and independent.
Most important here is that you empower us in a safe and independent way!

I therefore kindly urge you to revise your stance on this topic.

Thank you.

As this thread should evaluate possible solutions and their technical integration I urge anyone participating to follow https://en.wikipedia.org/wiki/Wikipedia:Rational_debate aside of the code of conduct and Mozilla guidelines and keep this thread solution oriented. The worst would be another closure.

[bholley]

Just a quick level-set on Mozilla's stance here.

Over the past year or so, we've been experimenting as time permits with various approaches to improve the safety of inherently-powerful APIs, in line with the Web Vision document we published earlier this year. We've prototyped a few different designs for this with WebMIDI, and while that project is still in progress, it seems to be converging on something workable.

We haven't yet made any decisions about extending this approach to other APIs, but it's certainly something we plan to consider as we evaluate the outcomes of the WebMIDI experiment. We'll likely be sharing more about that in the coming months.

[scheib]

Would love a discussion at TPAC next week on this topic. I've proposed a breakout session. [Edit Sep19:] Presentation slides.

[mcarbonneaux]

this standard while be very usefull for many usage!

exemple of usage :
https://jason2866.github.io/Tasmota-specials/

the hability to program esp device directly from the web....

all this api that make abel to manage device from browser make possible to use the browser (ie javascript/typescript) to manage device like iot... in protected environement : the browser !

with adequate protection on usage, policy, consent from user, host filtering...

[aerkiaga]

Just my two cents, I'd like to note that this could be useful beyond the developer-oriented landscape. For example, a research project at my university is creating a cheap ultrasound imaging machine that could be used for training students. The device's client app would be run either as a native app or a web app, using the web serial API in the latter case to communicate with it.

[NuclearPhoenixx]

Just my two cents, I'd like to note that this could be useful beyond the developer-oriented landscape.

Definitely. Obviously it can be used in many cases where serial communication is needed. I'm using it to communicate with an MCU to send data over for gamma spectrometry setups.

But there is literally endless other use cases where something like this is extremely useful. After all, it's way better to use it instead of WebUSB, which (ironically) has more widespread browser support, especially on mobile. That would probably be the closest alternative if you're using USB-to-Serial chips. Doesn't matter here, though, since Mozilla doesn't like any of that. I can completely understand the controversy around Web USB, but it's not like people connect their heart rate monitors to a funny browser interface or something like that.

[nondebug]

Hi folks, updating this thread to note that Chromium is working on adding support for Bluetooth Classic serial ports through Web Serial API:

https://github.com/WICG/serial/blob/main/EXPLAINER_BLUETOOTH.md

[mcarbonneaux]

#337 (comment)

i agree completely with "Many solutions have been provided in the meantime to fulfill this request in a secure and safe way, and also many ways of securing the access itself. Hiding these settings for the experienced users is a better way of implementation, than no implementation at all".

plus is not prorpietary solution is standard proposition from wicg, https://wicg.github.io/serial/.

and seriously i think the need is real, and many solution to protect again risk are know (like explained in the start of the issue), and mozilla implementation is better than chromium one (real open project vs gafa project)...

[Merlin04]

moving my comment to here from the duplicate issue I inadvertently created:

Web MIDI has been implemented for around 7 months now, and it's an API which carries very similar security implications to Web Serial (unrestricted communications with arbitrary hardware devices over a specific channel, of which implications are difficult to communicate to users). The Firefox Web MIDI implementation's solution of add-on gating solves this problem by presenting a flow which (simplifying here) conveys a similar granting of access as one would give when installing software, thus adequately getting informed consent from the user.

With this solution having been deployed and battle-tested for a substantial amount of time, I think that Mozilla should reconsider its position on Web Serial (assuming an add-on gate like Web MIDI).

[mcarbonneaux]

Would love a discussion at TPAC next week on this topic. I've proposed a breakout session. [Edit Sep19:] Presentation slides.

good slides !

@scheib what the return of the discution ?

affectively i think is more secure to access to serial port from web browser because of the way of the browser while prompt you about what serial port you need to access (plus on site basis and eventualy each time you need to access), than native application that have the ability after they are installed to access to all the serial port of the machine at any time without notification.... and mozilla can blacklist harmfull site...

with web api you are more protected than native application access to serial...

[agibson2]

I have seen this used twice in the recent weeks that I had to use Chrome for. One interfaces to bluetooth serial for a soldering iron to show status, tip temperature over time, etc. The other is a configuration for an Electronic Speed Control that seems to just use webserial where you configure it from a website. This is becoming a pretty common need for stuff that I am dealing with.

I hope that it does get considered. There should definitely be some security prompts to let people know something is trying to get serial port access. Someone could have some devices hooked up to their system that they would not want some website to start messing with it for safety reasons. Settings on the device could be changed for example. Configuring Cisco routers, etc via serial ports where you would not expect some website to start messing with it if there was nothing to indicate a site was doing so.

[dommilosz]

I think there is a very real need for it. I often need to use chrome for applications like this. Also chrome has quite monopoly on browser market and it works well there. If we are concerned about unaware user, who don't know the risks it can be implemented as hidden feature until proper security guards are implemented. For example it could be a setting in about:config.

[tanriol]

@bholley Has anything been shared on this topic that would be worth quoting/linking here?

Over the past year or so, we've been experimenting as time permits with various approaches to improve the safety of inherently-powerful APIs, in line with the Web Vision document we published earlier this year. We've prototyped a few different designs for this with WebMIDI, and while that project is still in progress, it seems to be converging on something workable.

We haven't yet made any decisions about extending this approach to other APIs, but it's certainly something we plan to consider as we evaluate the outcomes of the WebMIDI experiment. We'll likely be sharing more about that in the coming months.

[bholley]

At this point I think we're open to shipping WebSerial using the same add-on-gating mechanism as WebMIDI, provided we can come up with sufficiently understandable consent copy. It's not something we're able to resource right now but we'd take a patch.

[scheib]

Great to hear this is an option! It would be nice to see https://mozilla.github.io/standards-positions/#webserial updated to match this position.

[bgrins]

Updated the position in #959