Rendered at 02:59:05 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
greyface- 5 hours ago [-]
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 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.
geekuillaume 9 hours ago [-]
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.
tzs 11 minutes ago [-]
That makes me curious.
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?
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
atopal 6 hours ago [-]
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.
firesteelrain 5 hours ago [-]
Edge has had it for a while too.
wasting_time 3 hours ago [-]
In case you don't know, Edge is a "Chromium-based browser" like GP mentioned.
le-mark 9 hours ago [-]
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.
lxe 7 hours ago [-]
Woah this is a MASSIVE deviation from FF's previous philosophy on allowing WebSerial. This is a GOOD thing!
codys 1 hours ago [-]
I hope this signals a departure from us being stuck without web usb in firefox too. It's a shame that I've been stuck using chrome for it.
And maybe we'll get web bluetooth too.
skybrian 9 hours ago [-]
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:
Hopefully it will just work, if not please file a bug! I tested with a variety of hardware and sites but of course I couldn't try everything...
jononor 5 hours ago [-]
WebSerial in Firefox?! Finally! One of the very few things I use chrome for.
trainyperson 10 hours ago [-]
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.
nathanmills 4 hours ago [-]
WebUSB next? I would like to be able to configure my keyboard but it can only be done via their website which requires WebUSB.
tech234a 9 hours ago [-]
On iOS the page promotes the App Store version of Firefox, which is based on WebKit and doesn’t support Web Serial.
darkwater 8 hours ago [-]
Blame Apple for that.
5 hours ago [-]
singiamtel 10 hours ago [-]
Amazing feature for beginners. Is it possible to do this using Arduino?
gregstoll 4 hours ago [-]
Yup! Arduino is one of the things I tested with. (I worked on this for Mozilla)
As long as you can download the environment for offline use.
maxlin 4 hours ago [-]
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.
nathanmills 4 hours ago [-]
What makes it aggressive?
nathanmills 29 minutes ago [-]
Downdooters, what about my question did you dislike? Is it just you don't want any resistence to anything you say?
Insimwytim 7 hours ago [-]
The design of this webpage is horrendous.
monegator 7 hours ago [-]
what the fuck since when they are allowing webserial / webusb?
I've always agreed with the reservations about browsers being able to control peripherals. I'd rather download a python script i can inspect.
wildzzz 2 hours ago [-]
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.
Rohansi 5 hours ago [-]
You could always just not allow any websites to use these features. They require your permission first.
rebelwebmaster 3 hours ago [-]
It uses add-on gating similar to what they do for Web MIDI, so it's not exposed to users unless they specifically opt into it.
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.
froyooh 1 hours ago [-]
Old shit is shit
cxr 9 hours ago [-]
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.
nl 3 hours ago [-]
> 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.
arikrahman 8 hours ago [-]
This is why I use Clojure/ClojureScript to sidestep the issue entirely, while still being able to use the ecosystem if I have to.
> 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...
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.
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?
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.
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.
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.
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.
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.