10 ms·

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

by dz0ny 2y ago

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. https://developer.mozilla.org/en-US/docs/Web/API/Serial https://developer.mozilla.org/en-US/docs/Web/API/Serial https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/

vbezhenar 2y ago
It should be easy to fix that with browser extension and small native program. Nobody wrote this yet?
- pjc50 2y ago
  Wait, under what circumstances are browser extensions allowed to communicate with anything outside the browser?
  - vbezhenar 2y ago
    https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... 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).
    - lxgr 2y ago
      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).
      - vbezhenar 2y ago
        When random websites connect to your application, you can (and should) inspect Referer header and filter out unwanted ones.
  - Macha 2y ago
    https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... 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
    - dz0ny 2y ago
      Oh wow, this is cool. Yep this would make USB Serial work on Firefox with a simple extension.
      - Macha 2y ago
        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.
      - AshamedCaptain 2y ago
        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.
jeroenhd 2y ago
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.
- Macha 2y ago
  - Firefox addon to add WebUSB capabilities 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.
  - hexo 2y ago
    why bother with electron madness when you have 20 minute job for pyqt.
    - mardifoufs 2y ago
      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.
- baq 2y ago
  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).
troupo 2y ago
> 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".
- LegionMammal978 2y ago
  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.
  - troupo 2y ago
    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?
    - lukan 2y ago
      That sounds the same to me, just a bit nicer articulated.
      - troupo 2y ago
        No, it's not the same. 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...)"
Wingy 2y ago
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!
- idle_zealot 2y ago
  It's not an either-or thing. Every case of WebUSB flashing I've seen also offers an open source CLI tool you can pull down and use instead.
  - smrq 2y ago
    Perhaps because WebUSB is not well supported? Just a hypothesis, but pushing it as a standard might encourage it to become an either-or thing.
  - wayvey 2y ago
    Many of the WebUSB flashing tools work fine offline, so one can just save the web page locally and use it that way.
JimDabell 2y ago
> 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. Here is the Mozilla discussion: https://github.com/mozilla/standards-positions/issues/336 https://github.com/mozilla/standards-positions/issues/336 And here is the WebKit discussion: https://github.com/WebKit/standards-positions/issues/199 https://github.com/WebKit/standards-positions/issues/199
- bangaladore 2y ago
  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.
  - fabrice_d 2y ago
    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.
    - bangaladore 2y ago
      But this is obviously not a solvable problem. 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
      - 2y ago
Boogie_Man 2y ago
Could've learned to use DD in the time it took to make this post. Web browsers need to remain incapable of... formatting my disks
TexanFeller 2y ago
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.
- lxgr 2y ago
  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.
michaelt 2y ago
> 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. [1] https://www.yubico.com/support/security-advisories/ysa-2018-02/ https://www.yubico.com/support/security-advisories/ysa-2018-... [2] https://github.com/WICG/webusb/blob/main/blocklist.txt https://github.com/WICG/webusb/blob/main/blocklist.txt
- cosmic_cheese 2y ago
  > 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.
  - schmidtleonard 2y ago
    If you weld my front door shut, I'm going to be upset with you. "But welding your front door shut doesn't bother me at all." Yeah, that's the problem right there.
    - 2y ago
jancsika 2y ago
> 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.
- observationist 2y ago
  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.
- TheRealPomax 2y ago
  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".
  - justinrubek 2y ago
    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
  - Dylan16807 2y ago
    > 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.
babypuncher 2y ago
> 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.

by dz0ny 2y ago

vbezhenar 2y ago

It should be easy to fix that with browser extension and small native program. Nobody wrote this yet?

pjc50 2y ago
Wait, under what circumstances are browser extensions allowed to communicate with anything outside the browser?
- vbezhenar 2y ago
  https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... 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).
  - lxgr 2y ago
    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).
    - vbezhenar 2y ago
      When random websites connect to your application, you can (and should) inspect Referer header and filter out unwanted ones.
- Macha 2y ago
  https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... 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
  - dz0ny 2y ago
    Oh wow, this is cool. Yep this would make USB Serial work on Firefox with a simple extension.
    - Macha 2y ago
      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.
    - AshamedCaptain 2y ago
      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.

jeroenhd 2y ago

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.

Macha 2y ago
- Firefox addon to add WebUSB capabilities 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.
- hexo 2y ago
  why bother with electron madness when you have 20 minute job for pyqt.
  - mardifoufs 2y ago
    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.
baq 2y ago
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).

troupo 2y ago

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

LegionMammal978 2y ago
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.
- troupo 2y ago
  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?
  - lukan 2y ago
    That sounds the same to me, just a bit nicer articulated.
    - troupo 2y ago
      No, it's not the same. 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...)"

Wingy 2y ago

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!

idle_zealot 2y ago
It's not an either-or thing. Every case of WebUSB flashing I've seen also offers an open source CLI tool you can pull down and use instead.
- smrq 2y ago
  Perhaps because WebUSB is not well supported? Just a hypothesis, but pushing it as a standard might encourage it to become an either-or thing.
- wayvey 2y ago
  Many of the WebUSB flashing tools work fine offline, so one can just save the web page locally and use it that way.

JimDabell 2y ago

> 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. Here is the Mozilla discussion: https://github.com/mozilla/standards-positions/issues/336 https://github.com/mozilla/standards-positions/issues/336 And here is the WebKit discussion: https://github.com/WebKit/standards-positions/issues/199 https://github.com/WebKit/standards-positions/issues/199

bangaladore 2y ago
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.
- fabrice_d 2y ago
  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.
  - bangaladore 2y ago
    But this is obviously not a solvable problem. 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
    - 2y ago

Boogie_Man 2y ago

Could've learned to use DD in the time it took to make this post. Web browsers need to remain incapable of... formatting my disks

TexanFeller 2y ago

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.

lxgr 2y ago
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.

michaelt 2y ago

> 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. [1] https://www.yubico.com/support/security-advisories/ysa-2018-02/ https://www.yubico.com/support/security-advisories/ysa-2018-... [2] https://github.com/WICG/webusb/blob/main/blocklist.txt https://github.com/WICG/webusb/blob/main/blocklist.txt

cosmic_cheese 2y ago
> 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.
- schmidtleonard 2y ago
  If you weld my front door shut, I'm going to be upset with you. "But welding your front door shut doesn't bother me at all." Yeah, that's the problem right there.
  - 2y ago

jancsika 2y ago

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

observationist 2y ago
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.
TheRealPomax 2y ago
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".
- justinrubek 2y ago
  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
- Dylan16807 2y ago
  > 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.

babypuncher 2y ago

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