USB Serial is such a great thing, finally ending those annoying Electron apps that are only used for one thing. There’s a list of tools that now use the browser to set up devices, and it’s fantastic.
ESPHome(+ hundreds projects that use it as a base), Betaflight, ELRS, Flipper just to name a few.
I understand that WebKit lacks support since it’s developed by Apple, and I would also be cautious if it granted any access to peripherals.
But Firefox? Firefox has severely lacked support for hardware "connections" and has been unfriendly for developers for a long time, so I simply stopped using it (one of the reasons). Reason they state for not adding support it is that user consent is not enough to access the device, which is just nonsense, they could have made it enabled under the developer flag or similar. Blink proved that it can be made secure.
I have a filling they are stubborn for no reason and are not seeing use cases that would make their browser usable.
> Reason they state for not adding support it is that user consent is not enough to access the device, which is just nonsense,
There was a kinda major security issue [1] where malicious websites used WebUSB to access FIDO/U2F keys.
This was bad because U2F credentials are supposed to be impossible to phish, as the browser's U2F API puts the domain name in the request to the token - but by using WebUSB, a site could request a token for any domain name.
And as both U2F and WebUSB popped up quite similar looking user consent boxes, it's pretty much impossible to avoid some users getting confused.
Google's solution, believe it or not, was to blocklist a load of devices for WebUSB [2] - so now anyone making U2F devices has to get Google to add every new product they release to the blocklist.
Everyone loves the fact the browser is a secure sandbox, letting users run untrusted code. I don't get why people want to poke so many holes in the sandbox.
> Everyone loves the fact the browser is a secure sandbox, letting users run untrusted code. I don't get why people want to poke so many holes in the sandbox.
My thoughts precisely. I want browsers to be welding holes shut, not opening new ones.
I’d think differently if user consent were required to load any scripts past a certain complexity threshold (e.g. if they’re heavier than that of an early-mid 00s website, hold off on execution until the user approves), but with how easily users can be taken to sites they never asked to go to every added bit of deep system integration a browser gains is a massive liability. The web is too built up around the idea of implied consent to be doing anything too fancy.
It does. Mozilla doesn't trust users to not be manipulated by malicious websites into doing so against their own interests. At GP link 2, Mozilla writes their rationale for concluding that WebUSB is bad:
> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
Personally, I'd be happy enough with an implementation of WebUSB that only worked with websites accessed over localhost or on the local network. I want to write data over USB to ESP32s and Teensys 3D printers and so on through an integrated local webserver.
3. You click 'allow' because you do want the website to access your Yubikey. Then you press the button on the Yubikey when the light starts flashing, because that's what you do.
yeah, this sounds to me like apparently some people think once again computer owners can't be trusted to grant a permission to anything because some clueless people can be tricked into shooting themselves in the foot.
IMHO I don't buy that this is worth nerfing everything. Without using the exact analogy from the above metaphor, what if we banned cooking appliances, because a bad actor might call people and trick them into turning the stove up to "High" and placing a roll of paper towels on the flame?
I use the WebUSB to manage my keyboard's configuration, and that popup is hard to misconstrue. Also what is even the overlap between users of USB security keys (the main attractive USB target I saw cited) and people who click mindlessly without reading anything?
This isn't just clueless people clicking mindlessly without reading anything. The user wants to log in with their U2F key. They get a box asking if the website can access their U2F key.
Even if they read and understand every word in the box, consult their security training (which tells them "when you log in with a U2F key a box will pop up asking you to select a device, that's normal") the only indication they're doing anything wrong is that the device selection box looks a bit different to normal.
I can count the times I've needed WebUSB or WebSerial on one hand, and I own microcontrollers. I don't think the fingerprinting risks are worth it for the dozens of end users that don't need to download an electron app to interact with physical hardware.
Implementing the feature and then locking it behind a dev toggle is madness. That's wasting hundreds of hours of dev time that could've gone into something useful to expose a feature nobody will be able to find anyway.
These Chrome-only APIs can stay with Chrome for all I care as a developer. You need one Chromium browser standing by for when websites are actually broken in Firefox anyway, just use that when doing web USB stuff. It's a neat tech demo, but not something that a browser should be doing.
The fact that nobody has made a Firefox addon to add WebUSB capabilities probably shows that this is not worth the dev time for the people that do use the feature.
Is is really handy if you have a programmable keyboard that use a web configurator/firmware builder. E.g. ZSA's Oryx. Downloading the firmware and then flashing with another program gets old pretty quickly.
That said, I don't really like the browser having USB access, etc. I agree that the potential privacy/security issues are not worth the comfort it provides.
(Yes, I know you can script your way around it by monitoring a download directory, etc.)
> Is is really handy if you have a programmable keyboard that use a web configurator/firmware builder. E.g. ZSA's Oryx. Downloading the firmware and then flashing with another program gets old pretty quickly.
I have five of those keyboards, and I haven't flashed them in years. "Downloading the firmware and then flashing with another program gets old" yes, but you don't deal with it every day? or even every month?
Flashing every day isn’t too uncommon if you’re often changing the key map, macros, and other configuration. I probably flashed my QMK keyboard an average of 10 times per day for the first week, and then that tapered off to once or twice a day for a while.
I doubt you have this same sentiment about continuous integration in the context of work. Same concept. Eventually you get every thing dialed in and you keep it there.
Could you explain why are you flashing your keyboard so often? I have QMK keyboard, and I never felt like I’m missing anything by using it as is out of box. It also has a hardware switch for Mac/PC layouts, which is the only feature I could imagine having to flash it for, if that wasn’t available
Changing the layout of key map layers for convenience, and macros, back when I assembled my first QMK keyboard. Haven’t touched it in years now, though.
It's gotten a lot easier than it used to be. The Glove80 is configured by downloading a firmware file and dropping it into a mounted folder. That's not very onerous at all.
That sounds terrible to me. Can you also load your old file back into the app, say, if you want to check what the existing key mappings are? Still, I don't see the point of jumping through those hoops when WebUSB isn't something that automatically happens without the user explicitly granting access to a specific device in a dialog. People are acting like a Facebook ad can just enumerate all your USB devices and turn on your microphone or something.
This problem has been mostly fixed by newer keyboard adopting UF2: the bootloader presents itself as a USB flash drive, so uploading new firmware to your keyboard is literally a drag-and-drop.
The only drawback is that it is a little bit of a hassle if you're the type of person who changes out their macros every single day. But then again, if you need it that frequently installing the configurator tool locally isn't a huge deal I guess.
> if you need it that frequently installing the configurator tool locally isn't a huge deal I guess.
This sucks because the manufacturer has to forever keep supporting multiple native apps (given that mech keyboard users are pretty technical, not just Win/Mac but also Linux are necessary). Mac OS in particular is an insane moving target, and they tend to completely break app compatibility with every single major release.
What ends up happening is they'll ship JUST a program for Windows and shrug at everybody else.
The problem is that these firmware images are user-specific. Think of ergonomic keyboards[0], with a lot of dual-use keys, key combinations, macros, and layouts tailored to the user's intended use case. The configuration is baked into the firmware itself, so you can't just serve a single firmware image to everyone via LVFS.
In general, I don't want my browser to have direct usb access, but ZSA Oryx is the one place I'm annoyed by Firefox not supporting it. Honestly, I'd prefer having a native desktop app to configure my keyboard. But for my ZSA keyboard, I haven't found something as good as the web app for linux.
> I can count the times I've needed WebUSB or WebSerial on one hand
There are many things that would be possible with WebUSB that current browsers make impossible. My personal example is label printers: I would love for my SaaS app (PartsBox, https://partsbox.com/) to be able to print labels, but there is no way to access a printer from a browser other than through the "Print…" dialog, which is no good if you need to send ZPL2 commands to a Zebra label printer.
WebUSB is not necessarily the best imaginable solution to that problem but it would help.
I don't want to tell my users to use Chrome. But Firefox doesn't make my life easy (see also https://bugzilla.mozilla.org/show_bug.cgi?id=896666 — a bug opened 12 years ago, about Firefox closing websockets when the user clicks a download link).
Yes, and how would you talk to those from a web browser?
Again, the "Print" dialog is not the right way for labels: there is no way of guessing of what it will do to your formatting, or whether it will choose to print A4-sized stuff on labels.
So every website that prints labels should solve that separately?
There is an age-old problem here: how to take content on the screen and produce a printed artifact. It’s not easy, and everyone hates printer drivers, and kernel permissions, etc.
But if you want any portability of content at all, you need something like a print dialog and something like a printer driver. All the WebUSB stuff is just embedding those problems into the application.
What are the fingerprinting risks? Can websites gather any data without user consent?
I used WebUSB to flash GrapheneOS onto my Pixel, and to flash WLED on an ESP32 and it felt like magic. I'm erring on the side of this being a net positive.
"Hello GrandMa1950, please plug in your security key and select the device called /dev/ttyUSB0 in the pop-up, so we can authenticate your log in. Thank you!"
I'm fairly sure that would work. The FUD is likely well warranted.
Sigh. That's no different than "Please install this App" or even "Please read me this code". Yes, user-mediated authorization is an extremely difficult nut to crack. There will always be holes. There will always be unsophisticated users. But if you agree (and you do, right?) that people want to use external USB devices on their own devices, then you have already accepted that risk.
Freaking out because of the specific technology used to deploy the software is mostly just whining. This being HN, at least 60% of the resistance to web apps having extended capabilities is because of the company building the browser.
My experience with WebSerial/WebUSB/whatever I used (I don't know) is:
- go to espresense.com
- hook up an esp32 via usb
- click connect, click flash
- done
- repeat 10 times for all the base stations I needed
It reduces the friction of flashing a dev board to ~0. I absolutely loved it. I'm only annoyed that I had to open Chrome to do it (my daily driver is Firefox).
You are misrepresenting your own link. Not to mention this is a biased list.
Chromium does not include any of the many built in privacy features, add-block features, etc..., that Brave does by default.
Don't get me wrong, Brave's crypto junk is garbage, but atleast you could understand the rational for it. They seem to actually want to make a privacy focused, general purpose, browser fork, and they need funding from it from somewhere.
The only bullet here that might have to do with "safety" is:
> In 2021, Brave's TOR window was found leaking DNS queries, and a patch was only widely deployed after articles called them out. (h/t schklom for pointing this out!)
Its pretty well known that the official TOR browser is what you should probably use if you need TOR.
"The need funding from it somewhere" is the concerning part. Don't let desperate people run your browser. They already got caught injecting their own referral codes into links then just said "oh sorry."
I'm not here to claim that Brave is without issues. The whole crypto stuff is stupid. However, they have seemed to responsibly moved on from their previous failures, and that's okay with me. None of their previous failures intentionally attempted to affect user privacy or sell user data. That's what we are talking about here.
Brave is objectively better for user privacy than base Chromium. That is without question. If you disagree, please provide evidence to those claims.
Say what else you will about browsers, but they do offer a sandboxed execution environment across all major OSes, only limited by browser capabilities.
There's an argument to be made for limiting some of these permissions to "installed" PWAs, but these beat random Electron apps running with full user permissions in terms of security.
> If random electron apps is not connecting to the entire internet, loading completely random code from any website in the world, not they don't.
Why not? Nothing in terms of sandboxing prevents them from doing so, unlike webapps.
> Before USB4, USB came with DMA.
DMA is mainly a threat to the host, not the device, isn't it?
> USBC an hold a ton of power. One sandbox exploit, and the entire web can fry your machine.
How so? There isn't a "fry this device" USB protocol command. Obviously you could drain a printer's ink etc., but that's just another facet of "don't give random websites/PWAs access to sensitive hardware" that the browser UX indeed has to get right.
Isn't webusb almost a decade old at this point? Downloading sketchy flashing software is also a good way to get malware. I trust Chrome more than I do 5 separate toolchains and eclipse clones lol.
Yes, it's beyond many, and people are clearly both willing to write and grateful for easier alternatives. Why celebrate gatekeeping?
And even then, just because I could write a small utility doesn't mean I will, 99% of the time. I think being able to easily benefit from others work is generally great.
The problem isn't a widget in platform native tooling, the problem is there's only going to be one, and that platform is Windows 7 and nothing else (including newer modern versions of Windows).
The fingerprinting risks, to a layman, seem to be a red herring?
Have the user consent occur before the point of enumeration.
Or lock it behind the user already having installed the pwa and require confirmation (i.e. a browser site gets a flat denied message, a installed PWA gets a permission prompt).
Sort of depends on Firefox supporting installing PWAs though..
For webserial this feels like it would make sense... WebUSB does feel like an overreach and too much.
Consent is combined with device selection, at least in Chrome.
That leaks at most one bit unless the user selects a device (i.e. whether Web USB is supported or not, as a delayed error due to the user clicking "deny" would be distinguishable from an immediate one), and usually much less since that bit is very correlated with "is Chrome/Chromium-like".
Because pyside and PyQT suck in their own way. I mean sure if you only know python, or need python for other stuff, they are fine I guess.
I've had a rather big project (well, a proof of concept turned into a real project, the usual haha) built with pyside6 and looking back, I'd much rather have used electron/ts/JS. But we needed python for other stuff so I guess it made sense at the time.
Fingerprinting risks? Is there some device enumeration capability that I don't know about? I thought you had to explicitly grant access to the specific supported device in a browser popup window.
Same – but I'm almost certain I would have given up if it weren't for Web USB, rather than install some dubious local unsandboxed software or running some Python script pulling in tons of dependencies.
You know fingerprinting is impossible to avoid, right? Adding WebUSB to the mix does not make users more fingerprint-able, because we've long, long been saturated at users being 100% fingerprint-able just because we can correlate their rough location from their IP address to the time of day they access certain resources.
This is something that bothers me about Firefox fans talking about privacy and security in the browser. There really never was any. You fundamentally cannot be private on the Internet that we currently have, at least when stood up against motivated actors. But on the web, at least you're not blasting your identity to absolutely everyone. In direct contrast to every major native OS that makes it pretty easy to get not only the user's name, but their preferred email address. Or every major mobile OS that just hands app developers a tracking ID for every user. No need to fingerprint! The OS gives it to you! Oh, they fingerwag at you, "don't correlate these IDs month-to-month when we reset them!" Yeah, I get it. <wink wink>.
So, when a browser that has been losing users year-over-year for the last 16 years and is now in "also ran" status blocks functionality for the browser, the one place where user identity is at least made hard, telling people they think it's better for developers to make native apps for the functionality, it's really hard to take them seriously on their word that they are privacy-conscious.
How do you get from "it's possible to correlate somebody's application usage times and IP geolocation" to "fingerprinting is impossible to avoid"?
IP tracking is somewhat avoidable using things like Tor and iCloud Private Relay (not so much most VPNs, though), and even if it isn't, I'd still much rather be in an anonymity set the size of a densely populated ZIP code than one of size one.
> every major mobile OS that just hands app developers a tracking ID for every user.
Which ID does iOS hand to developers? I was under the impression this hasn't been a thing anymore for several OS versions now.
> I have a filling they are stubborn for no reason and are not seeing use cases that would make their browser usable.
This is untrue. Privacy and security issues have been raised. Web Serial is not a web standard and cannot become one until Mozilla or Apple sees these issues resolved. Google cannot make this into a web standard unilaterally; standards need consensus.
I don't exactly understand the privacy and security implications here.
A website can prompt for precise location at any point. A website can prompt me to provide a certificate with my cryptographically proven identity at any point. A website can PROMPT for XYZ at any point.
Why should WebUSB be treated any different. If I give access to a device, I give access to a device. If I don't, they can't touch or identify it.
Because explaining exactly what can happen when you grant WebUSB access is not as clear as with a geolocation prompt. You can't get meaningful consent from users - not all prompts are equal.
The whole objective of WebUSB is to not generalize it. Meaning in theory someone could, if you explicitly allow access to a device, reflash your ESP32 with a HID mouse device that automatically uploads a sensitive file to the attacker.
But if the user was going to do this anyways (flash some unvetted binary to their device), the web still provides MORE security than having the user download flasher.exe + badbinary.elf
> But if the user was going to do this anyways (flash some unvetted binary to their device), the web still provides MORE security than having the user download flasher.exe + badbinary.elf
I've very very often heard people complain (even some in this very thread!) that you can't get people to (or people outright refuse to) download programs and run them if they're not delivered by Steam or similar. I've also very often heard people complain that ordinary users of web browsers will click anything and everything standing between them and what they want to do without either reading it or bothering to think about what they're doing it.
Given these two points, I'd argue that giving direct access to USB devices to any random website is (from a security standpoint) disastrous for the average user. A user who clicks the "Yes, give access to this USB device to 'website.com'" prompt is almost never going to intend to -say- flash the firmware on that device... and would almost never have any idea if it was or was not possible to do so.
If you even know what an ESP32 is, you can get a browser extension to use WebUSB. Very few users need this feature built-in, let alone enabled by default.
Maybe hasn't been done, but I agree with some of the other comments around here that if this were truly important, someone would've done it. Or at least if a browser is going to support it, it should only be enabled via some hidden dev setting.
> if this were truly important, someone would've done it
That's basically a variant of the efficient market hypothesis for open source software. I highly doubt it's accurate, for various reasons.
Things that people retrospectively consider absolutely essential and a no-brainer to prioritize get shipped years after the initial release of some software all the time.
In this case, it's probably because the alternatives are good enough, even if it's just that Firefox users open Chrome in specific instances where they want to connect to special hardware.
Tell me what "getting access to a device" exactly means? Is it reading some data, all data, changing some state, etc?
Compare that with an api that asks "Are you ok to disclose your location to example.com?" or "Do you allow example.com to send you notifications?". This is night and day.
> Firefox has severely lacked support for hardware "connections" and has been unfriendly for developers for a long time, so I simply stopped using it (one of the reasons).
How many devices are you setting up per day?
I just can't imagine jettisoning Firefox for browsing the web because of webusb.
There are more than twice as many Linux desktop users than there are firefox users in total. People have left firefox for many reasons. The incompetence, user hostility, lack of principles, and technical lag are rampant and pervasive.
Even seemingly trivial missing features can push people to another browser if they're otherwise largely indifferent already.
I don't think it's unreasonable to assume that to some people, the inconvenience of juggling two browsers alone outweighs the benefits of using Firefox for most browsing.
Neither can I, but you know what I can imagine? Walking away from Firefox because it yet again shows it has no interest in being a strong browser for the only folks that actually use it, namely power users who care about privacy, security, and controlling their own browser experience while enabling them to make the coolest shit with the latest, cutting edge Web APIs.
"Leaving Firefox" because of WebUSB would be silly, but "finally leaving Firefox" because they refuse to add yet another thing that intersects with your interests? Absolutely. At some point you just have to go "this is an abusive relationship holding me back".
Precisely this. I've not even used WebUSB, but while reading this post, I was reminded of similar pain points with Firefox. I found myself thinking of what browser I could switch to while reading comments before finding this thread. I'm a long-time die-hard Firefox user as well.
I've been waiting years and years for service worker module support, and I am sure there are plenty of other things that are important and not being done so that's just one example
> power users who care about privacy, security, and controlling their own browser experience while enabling them to make the coolest shit with the latest, cutting edge Web APIs
I agree with this part entirely.
Except I don't consider WebUSB to be a "Web API", despite the name. And if it has any effect on privacy and security, it's a negative one.
My physical hardware becoming suddenly unprogrammable because the company hosting the flashing site went out of business isn’t okay. It should be a software that I can download and is not dependent on any external servers.
If the device depends on their servers to work in the first place, I love not having to download and trust the software though!
I want code running in a browser to stay in its sandbox, a large motivation for web apps in the first place is that they stay safely sandboxed and ephemeral. I think browsers accessing hardware is a terrible mistake, they make a terrible “OS” and trying to use the web as the default platform for all apps has set our industry back decades.
I like the sandboxing properties of my browser, and wish I could run as many of my local applications and utilities in it or in something comparable.
Part of that is being able to access hardware, and missing that functionality will expose data on my computer to malicious or compromised applications or scripts.
Hardware access obviously has to be on a very strict opt-in basis. For all the things Apple is regularly trailing behind other browsers or outright botching, I think letting only "installed PWAs" send push notifications and persist state more than 7 days between visits is directionally the right thing to do, and hardware access would be much less critical limited that way.
> I understand that WebKit lacks support since it’s developed by Apple
> But Firefox? Firefox has severely lacked support for hardware "connections" and has been unfriendly for developers for a long time
A lot of accusations to simply say "I want Chrome-developed Chrome-only APIs to be called standard and implemented by everyone without any objections".
I'd read it more as "I don't particularly care about what ends up as the standard or who ends up writing it, I just wish that it's nearly as capable as the non-standard implementation that exists and is useful."
Mozilla's objection is to having the capability at all, on the basis of "USB devices are too easy to hack" and "users are too dumb to give informed consent, regardless of what we tell them". And GP's objection to Mozilla's objection ultimately comes down to having the capability or not.
Mozilla's objection, among others, isn't "users are too dumb to give informed consent, regardless of what we tell them".
It's "we have dozens of APIs that require user consent and it's nearly impossible to contain this barrage, or to make sure that users fully understand the implications of consent for the more complex APIs and integrations"
Why do people in these discussions pretend that it is only WebUSB that needs a permission and consent?
There’s also the possibility of social engineering that compounds with lack of technical understanding to produce some nasty results.
It’s been proven that many users will click “Allow” for just about any dialog when instructed to if a sufficiently juicy carrot is promised as a reward. With WebUSB this could easily result in hapless users’ phones and whatnot getting malware/spyware installed on them… elderly and kids seem particularly vulnerable.
Okay, fine, there are a few other proposals regarding information about or control over the local device that Mozilla disapproves of on similar grounds. But it still comes down to "We don't think users can ever understand the security risks involved with this kind of access", which I've abbreviated as "users are too dumb". You can argue that "they're not dumb, they're just human/inattentive/fatigued by warnings/whatever", but it still comes down to having the knowledge or not. (After all, if it were just "We don't want a single click to give immediate access", they could just make the prompt/warning harder to mindlessly click through.)
Of course, the alternative to the user getting a browser prompt to communicate with their USB device is for the user to download a program to communicate with their USB device. So if they're set on doing whatever they are attempting to do, then it's not like they can ever avoid the risk of threats they don't understand, since desktop sandboxing is still mostly nonexistent.
Stop projecting your own view of users on what Mozilla is saying.
> Of course, the alternative to the user getting a browser prompt to communicate with their USB device
It's amazing you write this literally after I wrote "Why do people in these discussions pretend that it is only WebUSB that needs a permission and consent?"
It's actually exasperating to see almost the same people go "oh yes, permission dialogs in Android are overly broad, and people just click yes without reading, yes cookie consent popups are annoying, people just click yes" and then turn around and say "how dare Firefox assume people are stupid to read and understand the consent popup for WebUSB (and WebHID, and WebSerial, and WebMIDI, and NFC, and Network Information, and Bluetooth, and Location, and FileSystem Access, and Camera, and generic sensors in general, and...)"
I’ve heard both opinions at the same time because they’re both true.
A technical audience will actually read prompts and understand what they’re consenting to. I, for one, actually read cookie prompts and will say no to as much as I can.
Most people don’t, and the number of people who don’t is growing, because we keep adding prompts.
It was basically built so password manager extensions could communicate with password manager apps to do things like yubikey support etc. before browsers started handling webauthn
Yes, I have done this for (a fraction of) WebBluetooth. Albeit the extension API does not make it easy, and i don't know if you can implement the entire Web* API surface, but at least it is good enough for proofs of concept.
Extension + a native program for the extension to talk to. The native program has to manage accessing the usb device and providing an interface to the browser extension.
But more generally you can just run webserver on 127.0.0.1 and interact with it from extension (although I didn't test this particular use-case, it works fine from website, but extension might have its own nuances).
The latter poses some security problems, though, which the native messaging API avoids (e.g. random websites being able to connect to the native application and pretending to be your extension).
> There’s a list of tools that now use the browser to set up devices, and it’s fantastic.
Honestly, I hate this trend. What happens when the company goes out of business and the web app you need to configure your hardware is taken down? A dedicated desktop app that doesn't have online dependencies is the only way to go.
I shouldn't need internet access to change the function layer on my keyboard.
ESPHome(+ hundreds projects that use it as a base), Betaflight, ELRS, Flipper just to name a few.
I understand that WebKit lacks support since it’s developed by Apple, and I would also be cautious if it granted any access to peripherals.
But Firefox? Firefox has severely lacked support for hardware "connections" and has been unfriendly for developers for a long time, so I simply stopped using it (one of the reasons). Reason they state for not adding support it is that user consent is not enough to access the device, which is just nonsense, they could have made it enabled under the developer flag or similar. Blink proved that it can be made secure.
I have a filling they are stubborn for no reason and are not seeing use cases that would make their browser usable.
https://developer.mozilla.org/en-US/docs/Web/API/Serial
https://mozilla.github.io/standards-positions/