Mozilla's response to "Request for Mozilla Position on an Emerging Web Specification", June 2020:
> For raw device access as envisioned in a number of APIs (Web USB, Web Bluetooth, Web NFC, and Web MIDI), the risks of exposing those APIs to users cannot be reasonably conveyed. This is pretty much an intractable flaw of allowing raw, non-semantic access to devices regardless of the protocol used to do so.
> The specific issue is: it's not intuitive that allowing malicious-site.com to access your Bluetooth keyboard might give that site access to your stored passwords, give them the ability to hijack your DNS settings, or allow them to encrypt your hard drive and hold it ransom. And if it's not immediately obvious how those things are possible, that only serves to demonstrate how completely non-intuitive the risks are and how intractable trying to explain them in a permission prompt would be.
I like that your comment, which is at the very top of this comment section, quotes a statement concerning Web USB, Web Bluetooth, Web NFC and Web MIDI.
The linked post is about WebSerial. The concerns about Web USB, Web Bluetooth, Web NFC and Web MIDI mostly don't apply. Most users have USB and Bluetooth devices connected, many have MIDI devices. Pretty much nobody who isn't in the specific target audience for WebSerial is going to have a serial device connected. And even if the concerns did apply, you should probably quote a statement which talks about WebSerial.
I understand and previously agreed with Mozilla's hard line privacy and security stance.
Recently I've changed my mind. I've been building a thing using everything in the web platform, even if it is Chrome only and it is great. You can build apps the blend local and remote systems together in ways that make new things possible - and it is on an open-standard runtime.
But as a long time Firefox user I hate that I have to warn people at some critical features won't work.
I think from a platform point of view having features in the web platform that let it compete with other platforms is worth the trade off.
Now with Webxxx, the user needs to make sure that it is the right URL, not a fake teanns instead of teams, so he is unsure every time he has to use it. Some random download, once it works, can be reused and you have more trust that it works after the trial was positive.
And if it is open source, you can review the code before compiling. I can't review the code of some random server, as my browser only receives a random wasm binary for example.
I'm saying I think it is important for free and open systems to be competitive with closed ecosystems, and to take advantage of the power of local systems.
I believe in a world where we - as developers - can build systems that have both maximum safety and maximum utility for users.
Currently there are two ways of distributing software that takes full advantage of the hardware users have:
1. AppStores, with centralized, permission based certification of developers in an attempt to make apps safe.
2. Binary downloads, relying on the operating system to make them safe for users.
I believe there should be a third way - a platform that sandboxes users from the worse things that are possible and breaks reliance on cloud platforms.
I think the web platform is the closest to achieving this. I think the security and privacy concerns are valid and well-founded, but I think the trade-offs in pushing permission-based systems are worthwhile.
Take this project as an example. The alternative to web-serial is to download a random executable binary and firmware written by who knows to your computer, with full read/write permissions. I think that is a riskier outcome for users than enabling this API.
The web is not a software distribution platform, it's a platform for distributing thin clients to propriatory walled gardens that will break your use cases or just ban you at will. Users have absolutely no control over the web, so no I don't see it as a superior alternative
I think it is uncharitable to say "your convenience". It's more like "your vision as a creator". We're talking about developer intent that isn't possible otherwise. You can say "good, it shouldn't be", but don't characterize it as convenience.
I think that response increasingly makes no sense (as time passes). Mozilla prevents people from building apps that access their devices because it might be possible to do something malicious.
I am so tired of being treated like a drooling idiot "for my own good".
The worry is real: there has historically not been a meaningful security barrier between a USB device and software running on the machine it's connected to. Firmware hasn't been developed with the assumption that the machine is malicious, there's probably lots of firmware which you can get RCE on by sending a weirdly formatted USB packet. Lots of devices have pretty unrestricted firmware update via USB functionality. And security is often fairly lax the other direction too; at least Linux implicitly assumes that hardware you connect is trusted, and there are lots of old, insecure drivers for USB devices out there.
Do users understand that by clicking "allow" on a website, an attacker can re-flash their mouse with firmware which causes the mouse to present itself as some obscure USB device which activates a vulnerable driver? That by clicking "allow" on a pop-up from a website, the website can abuse their mouse to install a key logger or botnet? Should a user be expected to understand this?
I don't know how valid this fear is in practice. Has anyone done a study?
WebSerial was just introduced in Firefox 151. It was already available for 5 years in Chromium based browser. It's so new in Firefox that even caniuse is not up-to-date: https://caniuse.com/web-serial.
It would not be quite as seamless as having serial support included out of the box in the browser, but couldn't you get most of the way there by writing a native application that provides provides a network interface to the serial ports and then a JavaScript library for use in the browser than talks to that application over the network (maybe even making the JavaScript library API match the Web Serial API so code written for Chromium's actual Web Serial requires little of no porting)?
The native apps for Linux, Windows, and MacOS would be pretty simple, and would be independent of browser vendor or version.
This might even allow some flexibility that serial implemented in the browser doesn't have, such as allowing control of serial ports on a different host.
I'd have expected that when people saw that Web Serial in Chromium opened up some great possibilities for things like browser based Arduino development but other browser makers were not on board someone would had thoughts similar to what I've described.
Does this exist and I just missed it? Is there some major difficulty I've overlooked?
1. I go to your site
2. I download your service for my platform (that now has to be developed and shipped for N platforms your site wants to support
3. I install said service and make sure it's running
4. I go back to site and it's connected (or it's not and now you have to support a whole host of troubleshooting docs based on platform.
Web serial version that's now in Firefox and has been in chromium:
1. I go to your site. It works
What you described is something that has been done for awhile. Most recent thing I've used I can think of is Lenovos Driver install utility (you install their connector app, go to their support page, it connects to your app and then shows what drivers you need)
You could do that, but then either you're asking users to install a native app, which isn't very "webby," or you're shipping something with Firefox that isn't based on web standards*, which absolutely isn't webby.
*Unless you're thinking of something I'm not, the API couldn't exactly match the Web Serial API because of same-origin policy, and if you made an exception to that policy to make the polyfill work, you'd punch a giant security hole in the browser.
interestingly, MDN web docs claims at the top of the Web Serial page (https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_...) that Chrome does not support it, even though the support table at the bottom shows that it supports all of the features (Firefox doesn't) and has for longer than Firefox
That's because Chrome on Android has a partial implementation of Web Serial. The banner on top is to get information at a glance vs the detailed breakdown of the compatibility table.
Using serial comms from the browser is really important in educational robotics programs. Both First and Vex platforms support it. Kids can access the web based coding environment on their chromebooks, and send code to the robots with a usb cable.
We recently restarted our middle school robotics club. The school had a lot of old Vex EDR equipment for which the coding software is windows only so that really limited what we could do related to coding. Glad to see Firefox getting up to speed on this.
They were crazy overzealous about not allowing these technologies for a long time. I'm pretty sure I had many posts about this complaining over the years.
I'm delighted about this and also really hated the debate that had surrounded it.
Bring up WebSerial and WebUSB and oh no, all of a sudden, my 'document browser should not be accessing hardware' - yes we get it, you think the web is a collection of documents and are technically - in the most strictest sense possible correct. Hyper TEXT Transfer Protocol and all that.
Of course I've been watching Netflix and YouTube on my Firefox 'document browser' for years, because if I couldn't then there would literally no hope of anyone using Firefox in the real world, but WebUSB and WebSerial people are nerds who we can argue the toss about document browsers with and prove wrong.
Great to see Firefox getting on board. I wrote an alternative to Arduino's serial plotter that works in Chrome. Hopefully it's not too hard to get Firefox working too? Patches welcome:
Not a full time apple user but how does third party orion browser supports Firefox addons on apple but Firefox itself doesn't support their own addons?
I used WebSerial + WebSockets during hardware to prototype some connected hardware (on boards that didn’t have WiFi).
Plug in to USB, fire up the web app, and then press a button in NY to light up LEDs in SF – it was exciting stuff!
I never tried actually programming the boards over WebSerial; that obviously opens up many more use cases. I’m thinking about the success that p5.js has had in the creative coding community, largely driven (I think) by a low barrier to entry since it just requires a web browser to get started.
It's handy for situations where you have inexperienced people needing to flash microcontrollers. Meshtastic is a great example, it's meant for a wide variety of users from people that can actually write code to people that have only maybe heard of a raspberry pi in passing. You buy a transceiver on Amazon, go to the meshtastic website, plug in the transceiver, and hit "flash". Also, I don't want to have to download yet another custom Arduino IDE. I don't need to actually modify the running code, I just want the binary on the device so I can move on with playing with it.
I'm aware it's handy. Lots of handy things have been used to distribute malware. Now we just need someone to intercept ESPHOME's flasher so that it sends a modified payload
I don't believe this is a good solution: users will obviously click on that add-on install dialog box without being better informed and protected against malicious / buggy / attacker controlled web sites.
Hopefully they will move to a better solution that offers some integrity guarantees instead, like https://rwc26.waict.dev/ that they have an early implementation of in nightly builds.
Feels a bit out of place that the website tries to aggressively make me download Firefox, with multiple links on the site for it. Like it's the 2000's again and I'd need ActiveX or something. But it's to use a standard.
Sure, the standard is cool, have used it to flash Meshtastic to some LoRa boards, before advancing to use VS Code + ESP-IDF to flash in my own LoRa code.
> Feels a bit out of place that the website tries to aggressively make me download Firefox
It's firefox.com, feels like the perfect place to encourage people to download Firefox. That would be like going to a car dealership and being put off by people trying to sell you a car
it feels more out of place that it's a specific company getting to shove their name up as priority billing for the feature when this entire page should be focusing more on WebSerial support being in Firefox as a whole and not one dude's little devboard company.
> [...] the website tries to aggressively make me download Firefox, with multiple links on the site for it.
> What makes it aggressive?
The parent comment already contained the answer to your question (the multiple links are what makes it aggressive, in GP's opinion). Your comment might have been seen as more constructive if it engaged with that directly.
That's a start at improving something. But it won't rid itself of the Playskool/Fisher-Price gimmick factor or have any lasting effect until we can convince JS developers to write their own tools in a standards-compliant dialect and use standardized APIs so that contributors can use the runtime they already have installed instead of being cajoled and browbeaten into installing NodeJS or Bun or Deno or whatever to do what the browser runtime is perfectly capable of: opening a project directory, executing the code comprising the build script, and outputting the build artifacts when it's done.
> do what the browser runtime is perfectly capable of: opening a project directory, executing the code comprising the build script, and outputting the build artifacts when it's done
Unfortunately Firefox doesn't support the FileSystem API so to do this you need to resort to uploading the entire source code directory each time you change a source file.
I understand Firefox's privacy and security first thinking on this, but I think it is misguided. It's led to the webplatform being eclipsed by other, propriety options, or people forced to ship "Chrome-based only" features.
> Unfortunately Firefox doesn't support the FileSystem API so to do this you need to resort to uploading the entire source code directory each time you change a source file.
Right, it's so much less onerous to have people download and set up an entirely separate fickle toolchain—and needing to trust that the install triggers in the package.json of some transitive dependency won't exfiltrate your personal data or install some nefarious ineradicable background service onto your system, versus the two extra clicks you'd have to subject yourself to if you wanted to re-run the build.*
Wait, no.
> people [are] forced to ship "Chrome-based only" features
No they're not. By your own admission they could make their build scripts work with the standardized HTML5 APIs that are well-supported in all major browsers. They choose not to.
And you're not really responding to the substance, anyway—which is that JS programmers (frequently writing for browser runtimes, even) require that you install NodeJS, Bun, or Deno (because they hardcode the build scripts internals against one of those runtime's APIs). If programmers really were writing build scripts that you could run in Chrome but unfortunately not Firefox, then even that would be an improvement over the status quo. But that's not what we're talking about, because that's not happening.
* most of which are destined to be one-shot executions, anyway
You seem very angry and I clearly don't understand what you are talking about.
> And you're not really responding to the substance of the comment anyway, which is that JS programmers—frequently writing for browser runtimes, even—are demanding that you install NodeJS, Bun, or Deno (because they hardcode the build scripts against those runtimes' APIs).
Do you mean things like the Typescript + Webpack/whatever toolchain? Because broadly speaking that seems orthogonal to the target browser.
Using tools outside the browser to build something for the browser is mostly an optimization, for both the developer and the end user.
If someone has a web app with maybe 100 NPM packages, doing things like tree-shaking offline before shipping to a browser is important.
> And you're not really responding to the substance of the comment anyway, which is that JS programmers—frequently writing for browser runtimes, even—are demanding that you install NodeJS, Bun, or Deno (because they hardcode the build scripts against those runtimes' APIs).
If they are targeting Web APIs and using runtimes to build for those APIs what is the problem?
There are plenty of tools that need version X.XX+ of GCC to build and won't build using MSVC or something. It's a bit annoying but hardly outrageous.
> For raw device access as envisioned in a number of APIs (Web USB, Web Bluetooth, Web NFC, and Web MIDI), the risks of exposing those APIs to users cannot be reasonably conveyed. This is pretty much an intractable flaw of allowing raw, non-semantic access to devices regardless of the protocol used to do so.
> The specific issue is: it's not intuitive that allowing malicious-site.com to access your Bluetooth keyboard might give that site access to your stored passwords, give them the ability to hijack your DNS settings, or allow them to encrypt your hard drive and hold it ransom. And if it's not immediately obvious how those things are possible, that only serves to demonstrate how completely non-intuitive the risks are and how intractable trying to explain them in a permission prompt would be.
https://github.com/mozilla/standards-positions/issues/95#iss...
The linked post is about WebSerial. The concerns about Web USB, Web Bluetooth, Web NFC and Web MIDI mostly don't apply. Most users have USB and Bluetooth devices connected, many have MIDI devices. Pretty much nobody who isn't in the specific target audience for WebSerial is going to have a serial device connected. And even if the concerns did apply, you should probably quote a statement which talks about WebSerial.
Recently I've changed my mind. I've been building a thing using everything in the web platform, even if it is Chrome only and it is great. You can build apps the blend local and remote systems together in ways that make new things possible - and it is on an open-standard runtime.
But as a long time Firefox user I hate that I have to warn people at some critical features won't work.
I think from a platform point of view having features in the web platform that let it compete with other platforms is worth the trade off.
And if it is open source, you can review the code before compiling. I can't review the code of some random server, as my browser only receives a random wasm binary for example.
This doesn't preclude it being open source in anyway. Infact with a WASM toolchain you could even compile in the browser.
I'm saying I think it is important for free and open systems to be competitive with closed ecosystems, and to take advantage of the power of local systems.
I believe in a world where we - as developers - can build systems that have both maximum safety and maximum utility for users.
Currently there are two ways of distributing software that takes full advantage of the hardware users have:
1. AppStores, with centralized, permission based certification of developers in an attempt to make apps safe.
2. Binary downloads, relying on the operating system to make them safe for users.
I believe there should be a third way - a platform that sandboxes users from the worse things that are possible and breaks reliance on cloud platforms.
I think the web platform is the closest to achieving this. I think the security and privacy concerns are valid and well-founded, but I think the trade-offs in pushing permission-based systems are worthwhile.
Take this project as an example. The alternative to web-serial is to download a random executable binary and firmware written by who knows to your computer, with full read/write permissions. I think that is a riskier outcome for users than enabling this API.
I am so tired of being treated like a drooling idiot "for my own good".
Do users understand that by clicking "allow" on a website, an attacker can re-flash their mouse with firmware which causes the mouse to present itself as some obscure USB device which activates a vulnerable driver? That by clicking "allow" on a pop-up from a website, the website can abuse their mouse to install a key logger or botnet? Should a user be expected to understand this?
I don't know how valid this fear is in practice. Has anyone done a study?
It would not be quite as seamless as having serial support included out of the box in the browser, but couldn't you get most of the way there by writing a native application that provides provides a network interface to the serial ports and then a JavaScript library for use in the browser than talks to that application over the network (maybe even making the JavaScript library API match the Web Serial API so code written for Chromium's actual Web Serial requires little of no porting)?
The native apps for Linux, Windows, and MacOS would be pretty simple, and would be independent of browser vendor or version.
This might even allow some flexibility that serial implemented in the browser doesn't have, such as allowing control of serial ports on a different host.
I'd have expected that when people saw that Web Serial in Chromium opened up some great possibilities for things like browser based Arduino development but other browser makers were not on board someone would had thoughts similar to what I've described.
Does this exist and I just missed it? Is there some major difficulty I've overlooked?
1. I go to your site 2. I download your service for my platform (that now has to be developed and shipped for N platforms your site wants to support 3. I install said service and make sure it's running 4. I go back to site and it's connected (or it's not and now you have to support a whole host of troubleshooting docs based on platform.
Web serial version that's now in Firefox and has been in chromium: 1. I go to your site. It works
What you described is something that has been done for awhile. Most recent thing I've used I can think of is Lenovos Driver install utility (you install their connector app, go to their support page, it connects to your app and then shows what drivers you need)
*Unless you're thinking of something I'm not, the API couldn't exactly match the Web Serial API because of same-origin policy, and if you made an exception to that policy to make the polyfill work, you'd punch a giant security hole in the browser.
We recently restarted our middle school robotics club. The school had a lot of old Vex EDR equipment for which the coding software is windows only so that really limited what we could do related to coding. Glad to see Firefox getting up to speed on this.
And maybe we'll get web bluetooth too.
Bring up WebSerial and WebUSB and oh no, all of a sudden, my 'document browser should not be accessing hardware' - yes we get it, you think the web is a collection of documents and are technically - in the most strictest sense possible correct. Hyper TEXT Transfer Protocol and all that.
Of course I've been watching Netflix and YouTube on my Firefox 'document browser' for years, because if I couldn't then there would literally no hope of anyone using Firefox in the real world, but WebUSB and WebSerial people are nerds who we can argue the toss about document browsers with and prove wrong.
https://github.com/skybrian/serialviz
Plug in to USB, fire up the web app, and then press a button in NY to light up LEDs in SF – it was exciting stuff!
I never tried actually programming the boards over WebSerial; that obviously opens up many more use cases. I’m thinking about the success that p5.js has had in the creative coding community, largely driven (I think) by a low barrier to entry since it just requires a web browser to get started.
I've always agreed with the reservations about browsers being able to control peripherals. I'd rather download a python script i can inspect.
https://hacks.mozilla.org/2026/05/web-serial-support-in-fire...
Hopefully they will move to a better solution that offers some integrity guarantees instead, like https://rwc26.waict.dev/ that they have an early implementation of in nightly builds.
Sure, the standard is cool, have used it to flash Meshtastic to some LoRa boards, before advancing to use VS Code + ESP-IDF to flash in my own LoRa code.
It's firefox.com, feels like the perfect place to encourage people to download Firefox. That would be like going to a car dealership and being put off by people trying to sell you a car
> What makes it aggressive?
The parent comment already contained the answer to your question (the multiple links are what makes it aggressive, in GP's opinion). Your comment might have been seen as more constructive if it engaged with that directly.
Unfortunately Firefox doesn't support the FileSystem API so to do this you need to resort to uploading the entire source code directory each time you change a source file.
I understand Firefox's privacy and security first thinking on this, but I think it is misguided. It's led to the webplatform being eclipsed by other, propriety options, or people forced to ship "Chrome-based only" features.
Right, it's so much less onerous to have people download and set up an entirely separate fickle toolchain—and needing to trust that the install triggers in the package.json of some transitive dependency won't exfiltrate your personal data or install some nefarious ineradicable background service onto your system, versus the two extra clicks you'd have to subject yourself to if you wanted to re-run the build.*
Wait, no.
> people [are] forced to ship "Chrome-based only" features
No they're not. By your own admission they could make their build scripts work with the standardized HTML5 APIs that are well-supported in all major browsers. They choose not to.
And you're not really responding to the substance, anyway—which is that JS programmers (frequently writing for browser runtimes, even) require that you install NodeJS, Bun, or Deno (because they hardcode the build scripts internals against one of those runtime's APIs). If programmers really were writing build scripts that you could run in Chrome but unfortunately not Firefox, then even that would be an improvement over the status quo. But that's not what we're talking about, because that's not happening.
* most of which are destined to be one-shot executions, anyway
> And you're not really responding to the substance of the comment anyway, which is that JS programmers—frequently writing for browser runtimes, even—are demanding that you install NodeJS, Bun, or Deno (because they hardcode the build scripts against those runtimes' APIs).
Do you mean things like the Typescript + Webpack/whatever toolchain? Because broadly speaking that seems orthogonal to the target browser.
Using tools outside the browser to build something for the browser is mostly an optimization, for both the developer and the end user.
If someone has a web app with maybe 100 NPM packages, doing things like tree-shaking offline before shipping to a browser is important.
> And you're not really responding to the substance of the comment anyway, which is that JS programmers—frequently writing for browser runtimes, even—are demanding that you install NodeJS, Bun, or Deno (because they hardcode the build scripts against those runtimes' APIs).
If they are targeting Web APIs and using runtimes to build for those APIs what is the problem?
There are plenty of tools that need version X.XX+ of GCC to build and won't build using MSVC or something. It's a bit annoying but hardly outrageous.