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

[KellyClowers]

Actually you are right. Why not do it? Heck, let's give websites Ring -1 privileges on the CPU, it can make remote debugging so much easier!

[tjhorner]

That's an absolutely insane false equivalency. You can't seriously compare sandboxed, limited access to hardware devices authorized by the user to granting websites unfettered hypervisor access. This is just a disingenuous argument.

Adding any new feature will increase attack surface, and how low level a feature is does not necessarily dictate how much risk is involved. Most vulnerabilities in browsers these days are because of poor memory management, not due to the nature of the APIs that are implemented. For example, the very recent CVE-2024-9680 was due to a bug in the AnimationTimeline API. It is ostensibly a high-level API, but resulted in arbitrary code execution in which the attacker could do pretty much anything.

So just because a feature allows lower-level access to hardware devices does not mean it's any more likely to introduce a vulnerability than any other feature. The risk introduced by a feature must be evaluated against the usefulness of it, and so far it seems Web USB, Web Bluetooth, etc. have filled a niche that has seen adoption with some great use cases, for example:

• Arduino has a web-based IDE which can flash directly from the browser. This is advantageous because Arduino hardware is often used in educational settings, where weak and often locked-down devices like Chromebooks or netbooks are ubiquitous. It simplifies setup for educators, administrators, and school IT, and in fact hardens security posture.
• iFixit's soldering iron can be configured from the web without installing any native software.
• Pixel phones can be recovered from a bricked state using a web-based tool, without the need to install any additional software.
• ESPHome and the related ESP Web Tools project are often-used in the home automation space to facilitate quick configuration or flashing of firmware onto ESP-based devices.

I'm sure there are others I've missed; these are just from the top of my head. What all of these things have in common are that end users do not need to install an additional piece of software to work with their device, and the hardware manufacturers do not need to worry about maintaining a tool (including: updating dependencies that have bugs, being careful with memory management, etc.) for many different platforms. See my previous comment for more thoughts on that.

As this suite of APIs sees more mainstream adoption, Firefox will be seen as lagging behind other browsers.

[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.

[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

[nayz]

Please consider adding native support for this. Hate having to switch to Chrome, just to use a web installer.

[z4xh]

https://nvd.nist.gov/vuln/detail/CVE-2024-9680

Animations were a security problem, should they have been removed? No, they were patched like any reasonable solution to a security problem. Could the same be done for Web Serial? Absolutely!

[zoonman]

I hate to say this but over course of recent years every change that Firefox team brings is sort of questionable.

Chrome and Safari provide better support of web-standards, work faster and become more and more usable. TBH, I use Safari more and more. Also, it renders fonts a little bit nicer.

Instagram reels section just hangs in Firefox.

Mozilla developed a super-fancy Rust but can't use it to make the browser secure.

There are real problems but developers add a weather widget to a new tab.

Dear developers, if you don't get focus back onto your customer's demands you will lose Firefox.

[Nebula-System]

at the end of the day it really is just simply this ^^^

they aren't focusing on what the community wants and are doing questionable and, frankly bad or pointless decisions and they're really gonna start losing users over it soon if they don't get their act together

[zoonman]

Meanwhile Arduino released in-browser IDE that works with every other browser except Firefox https://blog.arduino.cc/2024/10/28/the-web-based-arduino-lab-for-micropython-editor-is-out-with-chro...

Arduino is the most popular platform amongst the ideal target audience for Firefox.

It is sad to see how Firefox turns into Internet Explorer.

[spap]

Having to install Google Chrome on Linux in order to replace Stock Android on a pixel device with a more privacy-respecting OS is soooo twisted 😵... C'mon Firefox! 😉