Fully support Web USB and Web Serial

[ali1234]

Web-based IDEs like Arduino and Github Codespaces are now commonplace. They are hobbled in Firefox due to an inability to access development boards without installing extra system software, which rather defeats the purpose of having an IDE that runs in your browser. This is not the case on Chrome, where Web USB and Web Serial can be used. (Clarification: they *could* be used on Chrome, but often are not because developers don't want to maintain two separate codebases.)

I will preempt the response I have received every previous time I brought up this topic: Web USB and Web Serial present no more of a security risk than web camera or location data, and Firefox already has a permissions system to protect those. On the other hand, the software you have to install to make Arduino IDE work in Firefox starts a webserver that shares your serial port over a websocket, just so that your browser can connect to it. It isn't clear if there are any protections at all on that websocket.

I will also note than the current prevalence of web-based development environments is in part due to Mozilla's insistence that everything should be able to run in the browser, along with projects like Firefox OS.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_API

https://developer.mozilla.org/en-US/docs/Web/API/USB

[Espionage724]

[deleted and changed stance]

[KERR]

The irony of having to use Chrome to flash GrapheneOS (a privacy-first Android ROM) via webUSB is disappointing!

[Nebula-System]

that's sad, i'm about to be looking into changing my phone's OS or rooting it, and i'll probably find more of this.

on another note: to those in this thread with email updates enabled, there's a new FOSS browser very early in development, Ladybird, so keep an eye on it as either it'll be a great replacement for firefox in a couple years if they add web serial and web usb, or the competition will force mozilla to do something. here's hoping.

until then, mozilla needs to listen.

[KellyClowers]

Absolutely do not support these. That is Chrome nonsense that no one should be using. The vulnerability footprint of browsers is enormous already, add low level protocols like that is immensely stupid. No web site should ever be able to have that kind of access to local hardware. Which is exactly why Mozilla doesn't support it currently. 

[KellyClowers]

God I hope they never do. If you need that kind of access make a real native program, don't deliver it through a website.

[domints]

You should keep the discussion civil, and you've only shown disrespect and lack of decency so far. I kindly ask you to stop spitting out such hateful words.

[PseudoNym2112]

A whole new browser is a *very* ambitious task.

What about some of the existing FF forks? I wonder if LibreWolf or IceCat would consider adding opt-in support for WebUSB?

Maybe FF main would pick it up from a fork if one of those communities seemed to be doing well with it?

[Nebula-System]

maybe, we can only hope.

[Nebula-System]

please kindly stop taking over a thread with (presently) unexplained, and unkind accusations.

adding these protocols is a valuable tool for access to local external hardware with user's consent, and the security measures are in exactly that: the user's consent, the activation of them. any proper implementation would require human user input before webserial could be activated which is what chrome also does, and the whole feature could, and should, be locked behind an about:config flag as it's a feature many common users (seemingly such as yourself) do not need, as they have no reason nor purpose. the people here are advocating for adding it behind such a flag, for our specific use cases, as being behind an about:config flag would keep common users safe while giving us the tools we want, that firefox needs to be able to compete in terms of browser market share in the modern era.

please kindly source the reasons for your argument and explain them in the future, and explain why you are so passionate about being against this, as lack of civility nor explanation add nothing to the discussion. if you have tangible constructive concerns, please tell us so we may counter with ways to mitigate those concerns, or new things mozilla should add to ensure it's not a security risk.

[tjhorner]

Consider that Web APIs which provide access to hardware devices are significantly safer in terms of security than the present alternative: instructing the user to download a random executable that likely needs to run with administrative privileges on the machine. With Web USB, Web Serial, etc. access is limited to only the devices the user specifies (+ only to that specific origin), and I certainly trust web browser vendors more to not introduce silly bugs that lead to compromise of my machine — I mean, have you seen the quality of the utilities that hardware vendors come up with?

It's a win-win for users and manufacturers: users do not need to worry about installing highly privileged, potentially buggy software on their machine and instead just use a simple webpage; manufacturers do not need to worry about platform-specific implementations of hardware APIs, maintaining the utility software, pushing updates to users, etc.

I would also like to add that devices can implement a specific descriptor that defines the origins that the device trusts to access it. Why not begin with an implementation which allows only a device's trusted origins to access it, and hide a "show all devices" option behind about:config? This would eliminate a big chunk of risk.

[Nebula-System]

exactly this, thanks for putting more words to the point

[ukoda]

I'm working on a high end consumer audio product that charges via USB and was looking at using a web app to configure the product without forcing the user to install an app on their phone or PC that they will probably only ever use once during initial set up.  Web USB serial access is a perfect fit for this use case.  I have been using Firefox since before it was called Firefox, back when it was in beta around ver 0.7, so find it disappoint I would have to give the classic "We only support Chrome and Edge" response to visitors looking to set up their product.

[SuibianP]

How does that help with security on the end user side?

If a user is not deemed capable enough to know what a WebUSB/WebSerial permission dialog entails, most likely they are not clear what a downloaded exe/dmg can do to their machine either. And as is well known to all, whatever a malicious JS program can do using WebUSB/WebSerial/WebHID, a native program can do just as well, plus much more.

[z4xh]

An example of legitimate hardware that uses the Web Serial API is iFixit's soldering iron. I run Linux, Mac, and sometimes Windows - expecting iFixit to develop and maintain a native application for these platforms separately does not make sense. Sure, a bloated electron-based app could be made, but that defeats the point since that's essentially chrome anyways. Being able to use Firefox instead would be so much better.

Yes, this is a device that does get very hot. Is this the best example, maybe not. I think in this case, where the manufacturer expects you to use a web browser to configure their device, it is their responsibility to ensure any data received over serial is validated. It is not the responsibility of Mozilla to outright refuse to implement Web Serial because it might be "unsafe".

[k2here]

I think by now people have provided enough 'sample situations'/'use cases' that state its usefulness as well as the need by community. Now its up to the mozilla 'devs'/'decision making team' to think about this which till now has been seen that they are avoiding to keep this one in their books in the name of "security reasons".  While many of us have argued that there are other features as well as situations where security is managed in certain ways which also pose security risks. So if they wanted to they could do it in those ways like about: config and debugging and other ways . But any response from mozilla side is simply put not implementing because of xyz policy or security reasons. We all can now read in between the lines that this is a humble way to say STFU we are not going to work on this feature. Now working on something like these features requests or other things has become a management decision instead of community feedback(opinion take it that way) But then this was our experience yours might be different. It has been ages following this thread and my hope is lost so moving on good luck to those who are still here for this one. Have a good one ahead, Good bye! (not dying just resignign/unsubbing this thread xd).

Always wear your smile, it suits you! - K2