Firefox does not support talking to arbitrary USB devices (whereas Chrome has WebUSB to do that). However, Firefox does support talking to U2F security keys over USB.

This project programmed a microcontroller to pretend to be a U2F security key. The goal was to talk to the microcontroller over USB through Firefox.

They use the Javascript Credentials APIs (https://developer.mozilla.org/en-US/docs/Web/API/Credential_...) and some cleverness to send data to and receive responses from the microcontroller.

You essentially have to make one of your /dev/hidraw devices completely world readable (inviting all sorts of keylogging shenanigans) before the browser can interact with the firmware.

Its creepy beyond creepy in terms of usage, and offline customization tools are all Electron based so there's not much advantage.

One reasonable workaround is to construct your desired keyboard layout with a template json file on the website, download the resulting json and then flash the firmware to your keyboard via sudo-level flashing tool.

Still, I wish there was a less creepy way.

Several microcontrollers come pre-shipped with MicroPython and an emulated flash drive where you can drop Python code to alter the running main()

I imagine you could easily do the same with keyboards, except the FS throws an error when you're writing invalid JSON and the emulated FS has emulated security properties so only admin users can write to it. No need to sudo, just authorise the permission prompt when you download/copy the new config to the virtual flash drive.

Afaik it's only any Via support per se that the keyboard firmware has allowing for such on the fly customization, rather than QMK. With QMK it's all manual flashing (I was somewhat surprised that it was easier than I was expecting to customize the layout/layers/lights with code though, largely thanks to the supportive community).

There should be - there's three LEDs (capslock, numlock and I forget the third one) on standard keyboards which can all be set from the OS side... and at least caps lock (I think!) can be set from Javascript, so it's essentially an 1 bit wide communications bus, three bits if it's an ordinary OS tool.

That one feels quite legacy to me, every time I active it it's by accident and I don't understand why stuff is behaving weirdly.

[1]: https://en.wikipedia.org/wiki/Scroll_Lock

(I believe this is actually the original purpose of ScrLk, but most applications these days don’t use it.)

I can go to https://usevia.app on a locked down employer-managed chromebook and hit my QMK keyboard with no trouble whatsoever. And needless to say I can't touch the /dev nodes at all on this box.

The point of flatpak, wayland, etc is to prevent software from having access to everything. Making all USB devices readable and writable again circumvents the entire sandboxing concept of modern systems.

    brw-rw---- 1 root disk 8, 2 Mar 14 11:51 /dev/sda2

Similarly, I can use fwupd to update the firmware of my machine without ever becoming root, but as a user I certainly don't have the device permissions to do it. So how? The system has a policy rule that says that every active, local user that is in the wheel group can run an update. The fwupd daemon that runs as root will then execute the update for the user.

What is difficult about understanding that?

By giving the browser access to your USB devices, the browser could act as a keylogger even when you're using other applications.

Further, as there's no proper way to sandbox this, you wouldn't just be giving the browser keylogging capabilities, but any native app running under your user.

Then you'd better uninstall your browser, because this is already the case right now.

The fact that Chrome makes use of that capability and Firefox does not constitute a privilege/security boundary.

It's true though that it's difficult to ensure only a certain process has access to it, though the default value set to ptrace_scope by e.g. Ubuntu is a step towards helping that.. But in principle the service can know which executable is issuing the request.

All in all this seems quite a big effort for perhaps not that great benefit. In the meanwhile I'll be using Chromium for WebSerial and WebUSB needs.

``` export USER_GID=`id -g`; sudo --preserve-env=USER_GID sh -c 'echo "KERNEL==\"hidraw\", SUBSYSTEM==\"hidraw\", ATTRS{serial}==\"vial:f64c2b3c*\", MODE=\"0660\", GROUP=\"$USER_GID\", TAG+=\"uaccess\", TAG+=\"udev-acl\"" > /etc/udev/rules.d/99-vial.rules && udevadm control --reload && udevadm trigger' ```

so that means the device can be read and written by the user and group, but not by others.

    SUBSYSTEMS=="usb", ATTRS{idVendor}=="vendor_id", ATTRS{idProduct}=="product_id", MODE="0660", TAG+="uaccess"

> For any rule adding the uaccess tag to be effective, the name of the file it is defined in has to lexically precede /usr/lib/udev/rules.d/73-seat-late.rules.

If your application is running as a different user, or in a Flatpak or snap, you may need some additional or alternative configuration.

[0]: https://wiki.archlinux.org/title/Udev#Allowing_regular_users...

In my experience it’s been great. Most of the WebUSB utilities I use are also available as self-installed apps, but I use them so infrequently that it’s much easier to use the web version than to go through the process of installing an update and using the app. It’s also one less app I have to install.

I would have expected this to be popular with the people who are tired of having an app for every different thing.

Convenience and security don’t fit together

I think browsers are the bigger target and they provide the much bigger attack vector given that the purpose is being connected to the internet.

Using an internet tool to access local resources is using the wrong tool for the job.

Do you know if your trusted web app fell for one?

I also do not understand why you refer to "trusted web app" whereas in my comment above I have stated that I need a sandbox to run the code; I clearly don't trust it enough. The whole point is that the browser allows me to run untrusted code safely. And supply chain attack is one of the main reasons why I don't trust it enough.

>I also do not understand why you refer to "trusted web app" whereas in my comment above I have stated that I need a sandbox to run the code

Because you referred to apps stealing code from a different origin. I talk about the app you use to access the usb device per web usb.

Previously it was about a malicious app attacking per browser exploit.

This tine the app is allowed to access the data but because of the supply chain attacks your data gets stolen.

Irrelevant. As a user I do not care how many dependencies an app has. I care about my own data security and browsers have an excellent sandbox.

> Because you referred to apps stealing code from a different origin

I referred to apps stealing data from a different origin. Think my open web mail tab containing my email. That's an attack that browsers can prevent.

> I talk about the app you use to access the usb device per web usb.

That's what is supposed to happen. I explicitly want this vendor app to talk to vendor hardware.

> Previously it was about a malicious app attacking per browser exploit.

A malicious web app needs a browser exploit to access my data which costs millions of dollars on the black market. A local app does not need any exploit to access my data.

> the app is allowed to access the data but because of the supply chain attacks your data gets stolen

The app is never allowed to access my data. It doesn't matter whether supply chain attacks are involved or not.

Browser technology stopped being internet tech only quite a while ago.

It might not have been the best idea, but that's where we are. So my first choice would nowdays also be webusb if possible.

That was already a bad idea.

> It might not have been the best idea, but that's where we are.

You aren’t forced to use it for local resources.

Supply chain attacks are quite common.

...and the domain taken over by a scammer who puts up a fake app that does unspeakable things to your USB device.

Taken out of context (and meaning), this sounds kinda naughty! :D

On one hand, I really want WebUSB, but at the same time, I REALLY don't want the average person to have WebUSB.

Practice has shown that consent popups do not work and people will manage to give consent to anything without even realizing it ("I never clicked on anything", they say, while I swipe away 50 spam push notifications and remove push permissions from about a dozen "news" sites).

Honestly, I kind of like the Internet Explorer version of permissions, where you needed to mark certain sites as "trusted" to enable certain features. The process is hard to discover, takes a decent amount of time, is a bit confusing, done in a system-styled modal popup with reasonably scary and large warning icons.

If people had to go through this process to mark a site as "trusted" in order to use WebUSB, WebBluetooth, and the other dangerous APIs, far fewer would do it by accident. The UX would still be better than installing a native app and you get sandoxing as a bonus, so I think the tradeoff would be worth it.

I really do want the general public to have access.

Many people need to interface with devices and we are sadly in a situation where Apps served by closed App Store are the only option.

If I want to distribute a way to allow the wider public to access a device that no longer has official support, WebUSB is by far the easiest way.

In an alternative world where Chrome did not support it, the average person would need to be able to install and run [python or other scripting language].

If the developer was really keen then they might offer a desktop app or go through the long and expensive process of submitting it to an App Store.

I think WebUSB can have a secure UI and I also can’t think what devices the average user has plugged in that could be compromised. I am pretty sure you can’t use WebUSB to take control of a keyboard or mouse (HID), storage, wifi, audio, smart card of U2F devices.

But it’s super useful for proprietary label printers, random toys/gadgets and programming/flashing microcontrollers.

Granting permission to pages should be, as you say, an explicit user-initiated flow via a permissions panel. The same should be so for sandboxed desktop applications. Does an application want to continuously record your screen? Then it should be granted this permission explicitly via a permissions control panel. It shouldn't be able to show a modal dialogue where people just click "yes". Many times, with good reason: they simply don't understand the technicalities of what they're being asked.

This is the endless struggle of all time. It's like some people have some sort of super-messing-things-up power. If you don't make something LITERALLY impossible to achieve, they will find a way to do it by accident. Always. They will go out of their way to find things to do by complete accident, and they will never have any idea what they're doing! They'll follow guides to change settings they don't understand, trigger functionality they don't understand, grant access they don't understand, no matter how complex you try to make the process, no matter how many warnings you add, and no matter how hard you try to guard against exactly this kind of idiocy.

And this sucks. Because there are people out there who do know what they're doing, who do things on purpose, and who would appreciate to have power that it just so happens that an Idiot should never be given. It is practically not possible to expose that power without being flooded by Idiots who did something Stupid with it.

Apple recently implemented some web APIs in a strategy that shows they actually understand designing for people: The APIs only work if you "install" the website. It makes it possible to access useful PWA features... but it doesn't allow any arbitrary website to do so, there's an extra process normal humans understand to enable it.

An installed PWA is also persistently visible: It's on the homescreen. So it's a visible reminder of that permission grant and a clear sign of something a user wants to have some sense of access to them.

The only way to design software safe for Idiots is to design software where it is not possible to make a mistake, not possible to have an accident, and not possible to compromise anything even on purpose.

Unfortunately, non-Idiots don't tend to appreciate that kind of babyfied experience, so we tend to end up with some compromise where the things that Idiots will inevitably mess up should ideally be the least consequential possible things that can also provide some sort of value to non-Idiots.

As a result some of the more advanced experiences that are entirely inappropriate to grant Idiots are simply not available, because if they were, then Idiots would find a way to cause really bad accidents.

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/

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.

[1] https://www.yubico.com/support/security-advisories/ysa-2018-... [2] https://github.com/WICG/webusb/blob/main/blocklist.txt

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.

"But welding your front door shut doesn't bother me at all."

Yeah, that's the problem right there.

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

1. You intend to log into an (evil) website using your Yubikey U2F token.

2. A popup appears that looks like this: https://developer.chrome.com/docs/capabilities/usb#get_acces... saying the website wants to connect to your Yubikey.

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.

4. Your unphishable credential just got phished.

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?

Now take a look at this browser popup box, inviting the user to grant access for webusb: https://developer.chrome.com/docs/capabilities/usb#get_acces...

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.

Because what's a sandbox to you is an universal API layer to some.

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.

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

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?

That sounds like a failure in design of the keyboard and/or your own personal use case instead of the designed-for use case.

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.

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.

[0]: https://www.zsa.io/voyager , for example

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

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.

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.

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.

No, you need to explicitly grant access to every hardware device a website wants to touch. The FUD in this topic is a little out of control.

I'm fairly sure that would work. The FUD is likely well warranted.

https://chromium.googlesource.com/chromium/src/+/967d11212c9...

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.

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

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.

Brave is objectively better for user privacy than base Chromium. That is without question. If you disagree, please provide evidence to those claims.

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.

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

I don't need to download an Electron app to interact with physical hardware, full stop, WebUSB or not.

Is that where we're at now? That writing a small utility to configure a widget over serial in platform native tooling is beyond us?

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.

Note this is beyond the capabilities of web extensions, you'd also need the user to install a cooperating native program.

At which point people are just going to make the native program an electron UI and bypass the browser entirely.

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.

The same goes for Web Bluetooth.

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.

Before USB4, USB came with DMA. If your sandbox has ever an exploit, that's close to instant rooting capabilities exposed to the entire web.

USBC an hold a ton of power. One sandbox exploit, and the entire web can fry your machine.

This is too dangerous of a capability to be exposed to a public network with tons of malicious actors and bots.

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.

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

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.

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.

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.

Here is the Mozilla discussion: https://github.com/mozilla/standards-positions/issues/336

And here is the WebKit discussion: https://github.com/WebKit/standards-positions/issues/199

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.

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

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.

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.

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.

Relatedly; apparently even Google has locked down WebUSB because it substantially weakened client security: <https://news.ycombinator.com/item?id=43362586>.

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.

At their market share, what's the downside to them of something remaining Chrome proprietary forever?

How many devices are you setting up per day?

I just can't imagine jettisoning Firefox for browsing the web because of webusb.

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.

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

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

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.

If the device depends on their servers to work in the first place, I love not having to download and trust the software though!

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.

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

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.

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?

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.

It's not only WebUSB that requires user permission, but it is only USB/serial access where Mozilla has decided that a permission prompt is inadequate.

No, it's not.

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.

> 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?"

I have the answer here: https://news.ycombinator.com/item?id=43363010

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...)"

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.

Web browsers need to remain incapable of... formatting my disks

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

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

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.

WebUSB should enable the same for more types of devices, but of course there should be appropriate permission mechanisms.

https://news.ycombinator.com/item?id=23679063

To me it seems should be impossible use it for tracking after they added the prompt.

Perhaps the solution is a separate tool, maybe just a separate browser, specifically for this use case?

Flash Browser, heck it could even come with additional tools to help do this. Preconfigured white or black lists, bookmarks to the most common flashing tools, reference material. Make it an even better experience than bolting webusb on to the browser raw.

Javascript is a language to add animation to those documents.

wow. I guess that does work.

I feel like giving an adversary infinite opportunity to try and decrypt the private key in their possession will backfire eventually, but what do I know?

For example, another way of doing it is to derive the private key from the key handle via deterministic key derivation – which the attacker can brute-force just as well as the encrypted per-site key stored in the key handle.

The key insight is that a stateless authenticator is by definition globally (i.e. across secrets and sites) deterministic, and given an input-output pair, you'll be able to brute-force its internal secret. The solution is to make that internal state large enough for that to be computationally infeasible.

What are the political disagreements?

> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.

— https://wicg.github.io/webusb/

> WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting

> We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label.

— https://github.com/WebKit/standards-positions/issues/68

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

— https://mozilla.github.io/standards-positions/#webusb

The browser can already access the USB devices it needs through normal OS interfaces (the keyboard and mouse being the obvious examples). I don't see why any website should need special direct access. The only use-cases seem to be giving access to web programmers who can't be bothered to write a standalone application (not a group I trust) or to provide additional ways to track users (something I don't want).

I don't even trust Google and Mozilla enough to give them access, much less any random stranger who's setup a website.

Not everything needs to be accessible from the web. I don't know where the line is, but for me USB access is across the line.

And this also holds back things like better security from USB security keys.

You have to access the key in exactly the way that is implemented ... even if that implementation sucks or has bugs or has security failures.

Everybody hates Electron .. but then want to hamstring the browsers. Well, people still want do do the thing they want even if you don't let them. They will find a way around .. and currently that way around is Electron.

But even then, you can use this argument against it. When this type of USB access is allowed, it gives phishing attacks even more power. Now, you’ll click prompts for authentication and little did you know that malicious actors and read/write the entire USB drive!