[HN Gopher] I-cant-believe-its-not-webusb: Hacking around lack o...
___________________________________________________________________
I-cant-believe-its-not-webusb: Hacking around lack of WebUSB
support in Firefox
Author : todsacerdoti
Score : 280 points
Date : 2025-03-14 08:36 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mevv wrote:
| pretty sweet
| agluszak wrote:
| > WebUSB and its associated political disagreements
|
| What are the political disagreements?
| nicman23 wrote:
| probably that your browser can access the hardware. which i
| also do not want.
| tux3 wrote:
| The politics of exposing users to security issues VS giving the
| web more capabilities.
|
| A fight which is usually won by people who just want features
| now. Security flaws tend to look hypothetical until people
| actually exploit them in the wild.
| usrnm wrote:
| If history teaches us anything, it's the fact that we will
| come full circle, the browser will become the os at some
| point. People with money want it to happen and they have
| resources to make us think that we want it too. Might as well
| enjoy the ride
| gostsamo wrote:
| should a browser have api-s allowing websites to access
| directly the file system and usb devices which might be
| insecure and help in fingerprinting or it should not. a.k.a
| chrome against all the ants.
| jeroenhd wrote:
| In this case, Safari also doesn't implement the API, and
| that's far from an ant. Plenty of cases where something is
| effectively everywhere but in Firefox, but this time Apple
| also decided against it.
| gostsamo wrote:
| Safari is an ant standing on the shoulders of a giant
| apple.
| pests wrote:
| It already does though. It's the type=upload box we've had
| for decades. Think of it as how smartphones let you give
| access to only a specific file or see a subset of files. The
| "UI" is just using a system control. You can also drag and
| drop files into the browser too. This is all available to
| javascript.
| Kbelicius wrote:
| > It already does though.
|
| It doesn't. Websites don't have access to your file system.
|
| > It's the type=upload box we've had for decades.
|
| It isn't. That isn't giving the access to your file system
| to a website. That is simply providing a file to a website.
| The website doesn't even get the real path to the file but
| a C:\fakepath\filename.
|
| > You can also drag and drop files into the browser too.
| This is all available to javascript.
|
| Again, that is not giving access to your filesystem to a
| website. That is giving a file to a website.
| pests wrote:
| I do agree partially but I don't see a difference in
| practice Using your definition every app on Android and
| Apple doesn't have access to your filesystem either.
|
| Just like you have to select which image from your camera
| roll that Facebook is allowed to see / access. It gets
| that one image, and only that image, on purpose. It
| doesn't get to have a free for all through your files.
| tannhaeuser wrote:
| Fingerprinting, basically, and whether browsers should gain any
| more capabilities at this point which just deepens the
| dependency on Chrome further and further.
| nicce wrote:
| About fingerprinting - was the WebUSB made poorly? I believe
| the device information can be strictly restricted and given
| only on user consent. E.g. by default browser sees only
| plugged-in status of certain device categories.
| vbezhenar wrote:
| You don't see anything without user consent.
| nicce wrote:
| It works like that or you think it should work like that?
|
| If browser gets zero information, it drastically reduces
| UX. It even does not know to suggest permission popups
| without being misleading in the end.
| swiftcoder wrote:
| While fingerprinting is a concern with many web extensions,
| the bigger problem here is the security risks inherent in
| exposing on the open internet a bunch of USB devices that
| were not designed with adversarial inputs in mind...
| tannhaeuser wrote:
| I think you're right. Weren't there even remote DMA/CPU-
| level attacks over OHCI/USB?
| rs186 wrote:
| I think that ship sailed many years ago.
|
| As I user who cares deeply about privacy and has almost
| everything enabled -- "strict" anti tracking protection on
| the browser, uBlock origin, DNS level filtering etc -- I
| discovered that any the fingerprint for my Firefox is pretty
| much unique on the entire Internet.
|
| One thing that astonished me was that the number of hardware
| cores of my CPU is easily accessible from JavaScript. I have
| an AMD machine with 8 cores and 16 threads. Somehow it is on
| the high end of machines that access the Internet, and only a
| small fraction of users have a 8 core CPU. Combined with just
| a few other parameters, especially IP address, it is easy to
| uniquely identify this computer.
|
| Just one additional channel of information from WebUSB barely
| matters at all.
| JimDabell wrote:
| WebUSB is not a web standard. It's a Blink-only API cooked up
| by Google and rejected by both Mozilla and Apple on privacy and
| security grounds. It cannot become a web standard without two
| independent implementations, and Google have failed to convince
| anybody outside of Google to implement it. Nevertheless, it
| pops up on various websites as things Firefox and Safari are
| "failing" to support.
|
| > 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
| jlarocco wrote:
| I don't know the general political disagreements, but I
| personally don't want WebUSB and think it's a garbage idea.
|
| 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.
| bsder wrote:
| > I don't see why any website should need special direct
| access.
|
| 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.
| consteval wrote:
| I believe USB security keys are covered under a different
| API.
|
| 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!
| tetris11 wrote:
| If you have a keyboard with QMK/Via firmware, customising it with
| WebUSB is a nightmare.
|
| 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.
| mschuster91 wrote:
| > Still, I wish there was a less creepy way.
|
| 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.
| unwind wrote:
| I think the third is scroll lock [1].
|
| 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
| jeroenhd wrote:
| I love scroll lock still existing on keyboards. Some
| operating systems still use it to control text scroll for
| some reason (useful when you don't have `screen` installed
| maybe?), but I mostly use it for toggles in video games. It
| shows the toggle state on a physical interface, like one of
| those fancy programmable macro keyboards, but on commodity
| hardware!
| Tijdreiziger wrote:
| I believe there are still a number of applications where
| Scroll Lock is useful, most notably Microsoft Excel.
| tetris11 wrote:
| how so?
| Tijdreiziger wrote:
| With ScrLk off, the arrow keys move the cursor (active
| cell). With it on, the arrow keys scroll the window
| contents instead.
|
| (I believe this is actually the original purpose of
| ScrLk, but most applications these days don't use it.)
| ahoka wrote:
| I can't just set any key to output the unicode character I
| want. I know there are some Linux only hacks, but it would be
| nice to do in a standard way.
| meindnoch wrote:
| You can't manipulate capslock state from JS.
| Amekedl wrote:
| what are you talking about? I have to approve the website
| before it can access my devices via WebUSB. What's the actual
| issue / path for keylogging etc. there, care to explain instead
| of fearmongering?
| tuananh wrote:
| i'm just guessing here but maybe only chrome is asking that.
| if the malware is another program, no confirmation is
| required?
| tuananh wrote:
| taking this from vial website
|
| ``` 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.
| tetris11 wrote:
| Yeah I have this udev rule, it fails to trigger properly
| and I think it might be because of what it thinks the user
| group and the web browser group is. I haven't fully
| debugged it, but I can tell you that this does not work for
| me
| terinjokes wrote:
| If you're on reasonably updated distribution, setting the
| GROUP in the udev rule might be causing issues. The
| [uaccess way][0] is to just set the TAG.
| SUBSYSTEMS=="usb", ATTRS{idVendor}=="vendor_id",
| ATTRS{idProduct}=="product_id", MODE="0660",
| TAG+="uaccess"
|
| The Arch Wiki also has this note:
|
| > 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_regul
| ar_users...
| tetris11 wrote:
| Oh thanks for this
| vbezhenar wrote:
| Windows and macOS allow access to USB devices for user
| programs. Linux by default does not allow access to USB
| devices, you need to chmod corresponding pseudo-file in /dev
| (or write udev rule to make it happen automatically). So when
| one uses WebUSB (or any other usb software) without root, it
| won't work immediately.
| junon wrote:
| Missing the point entirely. You must still enable USB
| support from the site before it can see or interact with
| anything.
| vbezhenar wrote:
| It has nothing to do with sites. You are missing the
| point. To access USB device with Linux, any software,
| including browser, should have permission to access
| certain files in /dev.
| junon wrote:
| You visit a page. It asks for device access. You get a
| dialog box choosing the device that matches the filter
| the site wants. You can either choose a device or
| decline. Site does not see anything other than what you
| approve.
|
| What is difficult about understanding that?
| kuschku wrote:
| You're the one missing the forest for the trees. The
| security risk is not caused by websites, but by the fact
| that the browser can access your USB devices in the first
| place.
|
| 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.
| _flux wrote:
| You could have an elevated service that has separate
| configuration for which devices the user wants to grant
| access to, and it could even work as a proxy to disallow
| "bad" usage patterns. The interface to USB devices
| doesn't need to be directly with the kernel.
|
| 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.
| lxgr wrote:
| > The security risk is not caused by websites, but by the
| fact that the browser can access your USB devices in the
| first place.
|
| 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.
| danieldk wrote:
| Modern Linux systems are more complex than that. E.g. if I
| plug in a USB drive and one of its partitions has
| permissions brw-rw---- 1 root disk 8, 2
| Mar 14 11:51 /dev/sda2
|
| I can still mount it even though I am not _root_ or in the
| _disk_ group. Why? Because many Linux desktops /apps can
| use polkit to get elevated access if a set of policy rules
| allow them to do so. E.g. there is typically a policy for
| udisks that allows clients in active sessions to mount
| filesystems.
|
| 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.
| tetris11 wrote:
| What group does the browser run in. Surely it's the same
| group as the user, and has the same wheel privileges, no?
| danieldk wrote:
| Being in the wheel group is not enough to write to the
| relevant device nodes. At any rate, my point was that
| device permissions and UID/GIDs alone do not determine
| whether a user or application can write to the device.
| Higher privileges can be mediated through polkit.
| kuschku wrote:
| The browser itself shouldn't have access to raw devices, as
| that means giving all programs running under your user the
| ability to flash your keyboard firmware.
|
| 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.
| jeroenhd wrote:
| > download the resulting json and then flash the firmware to
| your keyboard via sudo-level flashing tool
|
| 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.
| cosmic_cheese wrote:
| You could add a little hardware button or toggle switch to
| the board to enable/disable flash drive emulation if you
| really wanted to be secure. Write your config, unmount, flip
| toggle switch.
| Springtime wrote:
| _> and offline customization tools are all Electron based so
| there 's not much advantage._
|
| 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).
| tucnak wrote:
| I own Keychron devices with QMK firmware, and Brave (Chromium)
| is really explicitly communicating whenever the keyboard is
| being configured. I have also installed GrapheneOS using it, &
| honestly I cannot imagine getting tricked into launching a
| keylogger that way. I already trust Keychron and GrapheneOS to
| some extent so the point is moot, I think.
| evanjrowley wrote:
| If you're looking for a QMK alternative to Via, I recommend you
| try using QMK Configurator and QMK Toolbox. The combination is
| not as ergonomic as Via, but at least you get a graphical
| keymap editor that compiles firmware and is far less bloated.
| The experience has been good with my Keeb.io boards.
| tetris11 wrote:
| Yep, this is my current workflow -- not the easiest, but the
| one I trust the most
| ajross wrote:
| This is a little confused. The idea behind the permissions
| model is that the browser suite is responsible for mediating
| access to the hardware. Obviously, yes, you need to give it
| access to the hardware in the first place for it to do that. If
| you don't trust the browser as a manager of a hardware
| abstraction layer, that's fine. But that's the model that Via
| expects. I don't see how it's any more "creepy" than letting
| your browser read your camera or microphone or storage.
|
| 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.
| tetris11 wrote:
| Because the browser interacts with my camera/mic through
| specific media APIs that don't allow it to flash the
| firmware.
| ajross wrote:
| Uh... you can't "flash firmware" via USB HID. WebUSB in
| fact does not allow raw access to arbitrary devices, it
| works with specific defined protocols.
| MortyWaves wrote:
| Maybe it's a good thing USB ports are not available to browser
| based code.
| saint_yossarian wrote:
| As a Linux user I love WebMIDI, because it means I don't have
| to open a Windows VM anymore to run firmware updates / utility
| tools for audio gear manufacturers that embrace it (e.g.
| Novation).
|
| WebUSB should enable the same for more types of devices, but of
| course there should be appropriate permission mechanisms.
| rasjani wrote:
| Webmidi is godsent for Akai LPD8 controllers. It came with
| software that's used to reprogramming midi banks. Software
| never got updates and doesnt work anymore in any modern mac.
| Thank $deity for webmidi and some reverse engineering, i can
| reprogram it to a degree that its at least functional and
| dont need to throw it away.
| MortyWaves wrote:
| Why does that require a browser and not software you run
| natively?
| JimDabell wrote:
| WebMIDI has been used by porn sites to track users:
|
| https://news.ycombinator.com/item?id=23679063
| _flux wrote:
| As I understand it, it was because WebMIDI was accepted by
| Chrome without prompting the user.
|
| To me it seems should be impossible use it for tracking
| after they added the prompt.
| saint_yossarian wrote:
| That is/was a Chrome problem, Firefox only allows WebMIDI
| after granting permission. Unfortunately its implementation
| is also incomplete/buggy so I still often end up using
| Chrome for those use cases anyway.
| cship2 wrote:
| Whenever the committe crams another desktop features into
| the browser you can be sure it is mainly convenience and
| surveillance!
| mvdtnz wrote:
| No, it's not.
| dz0ny wrote:
| 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://mozilla.github.io/standards-positions/
| vbezhenar wrote:
| It should be easy to fix that with browser extension and small
| native program. Nobody wrote this yet?
| pjc50 wrote:
| Wait, under what circumstances are browser extensions allowed
| to communicate with anything outside the browser?
| vbezhenar wrote:
| 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 wrote:
| 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).
| Macha wrote:
| 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 wrote:
| Oh wow, this is cool. Yep this would make USB Serial work
| on Firefox with a simple extension.
| Macha wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| - 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 wrote:
| why bother with electron madness when you have 20 minute
| job for pyqt.
| mardifoufs wrote:
| 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 wrote:
| 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).
| kristofferR wrote:
| Yeah. People don't remember how painful it was to download
| a separate flasher and driver for every single board you
| tried to flash.
| linker3000 wrote:
| I fire up Brave for WebUSB for flashing ESP32 devices. It's
| Chrome, but less Googly.
| Diti wrote:
| I believe Chromium might be safer to use than Brave. http
| s://old.reddit.com/r/browsers/comments/1j1pq7b/list_of_b.
| ..
| bangaladore wrote:
| 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.
| hot_gril wrote:
| "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."
| bangaladore wrote:
| 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.
| dns_snek wrote:
| 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.
| ajross wrote:
| > Can websites gather any data without user consent?
|
| 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.
| whytevuhuni wrote:
| "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.
| hot_gril wrote:
| Even a lot of reasonably tech-savvy people might not know
| the difference between the WebUSB consent popup and the
| security key popup.
| dns_snek wrote:
| That was my very first concern when I thought about
| WebUSB too, but Chromium has a block list of Vendor IDs
| which includes various security keys.
|
| https://chromium.googlesource.com/chromium/src/+/967d1121
| 2c9...
| ajross wrote:
| 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.
| danieldk wrote:
| 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.)
| smrq wrote:
| 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.
| xp84 wrote:
| 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.
| 0x457 wrote:
| > 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?
| cstrahan wrote:
| 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.
| BobaFloutist wrote:
| I sure hope you're aware that you're not the typical
| browser user.
| shantara wrote:
| 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
| inetknght wrote:
| > _Flashing every day isn't too uncommon if you're often
| changing the key map, macros, and other configuration_
|
| That sounds like a failure in design of the keyboard
| and/or your own personal use case instead of the
| designed-for use case.
| mixmastamyk wrote:
| Is LVFS not available for these devices? Sounds like it
| would be a better fit. https://fwupd.org/
| crote wrote:
| 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.
|
| [0]: https://www.zsa.io/voyager , for example
| mixmastamyk wrote:
| Hmm, that's a poor design. Firmware should be separate
| from its configuration.
| crote wrote:
| 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.
| xp84 wrote:
| > 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.
| thayne wrote:
| 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.
| jwr wrote:
| > 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).
| shermantanktop wrote:
| Isn't that what printer drivers are for?
| dymk wrote:
| Why install and run some arbitrary blob that has full
| access to your computer, when you can open a web page and
| grant access to a single device?
| tiagod wrote:
| Yes, and they run with kernel level permissions.
| tehbeard wrote:
| 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.
| lxgr wrote:
| 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".
| BiteCode_dev wrote:
| Plus webusb is a 0 day waiting to happen. Browsers should not
| become os, they are exposed to the entire web.
| baq wrote:
| Browsers have been OSes for the past decade.
| throwaway48476 wrote:
| An OS designed by no one and implemented piecemeal
| through a thousand disconnected RFCs.
| baq wrote:
| And targeted by tens of millions of developers for
| billions of users.
| mardifoufs wrote:
| 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.
| lxgr wrote:
| 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.
| BiteCode_dev wrote:
| 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.
|
| 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.
| lxgr wrote:
| 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.
|
| The same goes for Web Bluetooth.
| moron4hire wrote:
| 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.
| lxgr wrote:
| 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.
| wpm wrote:
| >don't need to download an electron app to interact with
| physical hardware.
|
| 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?
| hot_gril wrote:
| In a cross-platform way, kinda yeah. Especially on the Mac
| side where OS updates always break everything.
| lxgr wrote:
| 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.
| fragmede wrote:
| 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).
| xp84 wrote:
| 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.
| troupo wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| That sounds the same to me, just a bit nicer articulated.
| troupo wrote:
| 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...)"
| izacus wrote:
| Are those people in the room with us and can you point at
| any that hold both opinions at once?
| consteval wrote:
| 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.
| LegionMammal978 wrote:
| > Why do people in these discussions pretend that it is
| only WebUSB that needs a permission and consent?
|
| 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.
| troupo wrote:
| > but it is only USB/serial access where Mozilla has
| decided that a permission prompt is inadequate.
|
| No, it's not.
| LegionMammal978 wrote:
| 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.
| troupo wrote:
| 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?"
|
| I have the answer here:
| https://news.ycombinator.com/item?id=43363010
| cosmic_cheese wrote:
| 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.
| Wingy wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Many of the WebUSB flashing tools work fine offline, so one
| can just save the web page locally and use it that way.
| JimDabell wrote:
| > 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
|
| And here is the WebKit discussion:
| https://github.com/WebKit/standards-positions/issues/199
| bangaladore wrote:
| 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 wrote:
| 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 wrote:
| 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
| simoncion wrote:
| > 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.
|
| Relatedly; apparently even Google has locked down WebUSB
| because it substantially weakened client security:
| <https://news.ycombinator.com/item?id=43362586>.
| hot_gril wrote:
| 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.
| lxgr wrote:
| Can I really, in Firefox? This seems like something
| that's impossible to provide via the Web Extension API.
| hot_gril wrote:
| It's supposedly doable:
| https://news.ycombinator.com/item?id=43361159
|
| 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.
| lxgr wrote:
| > 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.
| hot_gril wrote:
| 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.
| dymk wrote:
| What are you basing that on? What makes granting access
| to a device so much more difficult to explain than any
| other permission?
| fabrice_d wrote:
| 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.
| dymk wrote:
| These seem like the same level of "thing" to ask of a
| user, I have no clue what you think the fundamental
| distinction is
| lxgr wrote:
| > Google cannot make this into a web standard unilaterally
|
| At their market share, what's the downside to them of
| something remaining Chrome proprietary forever?
| Boogie_Man wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| _> 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-... [2]
| https://github.com/WICG/webusb/blob/main/blocklist.txt
| cosmic_cheese wrote:
| > 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 wrote:
| 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.
| hot_gril wrote:
| What's the front door, WebUSB or something else like TLS
| 1.2?
| hot_gril wrote:
| Google should've asked me first, cause just seeing the name
| WebUSB, I said "wtf why is this even a thing, absolutely no."
| hard_times wrote:
| Wait until you find out about WebBluetooth
| hot_gril wrote:
| At least I'm a little relieved that Firefox and Safari
| don't support that either.
| MrQuincle wrote:
| Wait until you find out about WebWifi
| SAI_Peregrinus wrote:
| I'm just waiting for someone to compile Chromium to WASM,
| giving us WebWeb.
| gsich wrote:
| Imagine if those devices used proper USB descriptors/classes
| instead of generic HID device.
| IshKebab wrote:
| I thought WebUSB required you to explicitly select a USB
| device from a list to allow the web page to connect to it?
| LeifCarrotson wrote:
| 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.
| hot_gril wrote:
| localhost-only access is a reasonable compromise
| xp84 wrote:
| 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?
| michaelt wrote:
| Take a look at this browser popup box, asking the user to
| select which device to use for webauthn: https://filestor
| e.community.support.microsoft.com/api/images...
|
| 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.
| michaelt wrote:
| Right. The attack is:
|
| 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.
| bestouff wrote:
| > I don't get why people want to poke so many holes in the
| sandbox.
|
| Because what's a sandbox to you is an universal API layer to
| some.
| jancsika wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| lxgr wrote:
| 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.
| babypuncher wrote:
| > 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.
| Devasta wrote:
| Maybe I'm just in the minority, I just don't see what purpose
| this serves.
|
| Besides my mouse, I just don't have anything that uses USB. My
| phone generally isn't connected, I've not needed a USB drive in
| years and I struggle to think of a situation where I have a
| product that uses USB that I need to use my laptop for but also
| don't want the software controlling it installed on that laptop.
| pests wrote:
| Google unlocking the Stadia controllers via a website was nice.
| rightbyte wrote:
| Seems like an artificial problem though.
| ryukoposting wrote:
| This is a good point that tends to get drowned out by the
| severe privacy and security concerns. WebUSB provides zero
| value to the overwhelming majority of end users, and minimal
| value to the handful of us who have ever used it at all.
| kristofferR wrote:
| That's not true at all, flashing ESP32 devices has been made
| WAAAAAY easier with WebUSB than before. Many keyboards have
| stopped requiring installing third-party software/drivers to
| customize them after WebUSB became a thing. The benefits are
| huge.
| swiftcoder wrote:
| > The benefits are huge
|
| To a relatively small group of enthusiasts, sure. I'd love
| to see numbers on the percentage of browser-users who own
| keyboards which require regular firmware updates..,
| kristofferR wrote:
| Who cares about what the plebs do? By that logic
| extension support should be removed from browsers
| outright, since extensions are just used by a small group
| of enthusiasts.
| ryukoposting wrote:
| > Who cares about what the plebs do?
|
| Blink, WebKit, and Gecko devs probably.
| dspillett wrote:
| This is effectively part of Google's official argument
| for making ad blocking more difficult (the unofficial
| argument being that they actively don't care if ad
| blocking is more difficult, for obvious reasons).
|
| The use cases for extensions cover a much larger segment
| of browser users than programmable keyboards and
| microcontrollers though: there is a lot more mass appeal
| for things like languagetool/grammarly, ad-blockers and
| other page tidiers, tools that are useful for devs1, and
| so forth.
|
| --------
|
| [1] I'd put money on even the vast majority of front-end
| devs not touching microcontrollers or having programmable
| keyboards.
| swiftcoder wrote:
| > Who cares about what the plebs do?
|
| Pretty much everyone involved in the security and
| usability of the internet.
|
| Enthusiasts will find ways to accomplish what they want
| to regardless of whether there's an easy browser-based
| path.
| dspillett wrote:
| While that shows a good use case for a minority, it doesn't
| refute at all "zero benefit to the overwhelming majority of
| end users". Most end users don't have configurable
| keyboards, and even less program microcontrollers.
|
| This is why it is contentious: On the one hand you have a
| great QoL benefits for a minority of users who are more
| than willing to accept the potential fingerprinting risk
| and consider other dangers to be overblown hypotheticals,
| or are technical enough to mitigate those issues. On the
| other you have the vast majority who have no need of the
| feature at all, and are probably unaware of any risk and
| will be until it becomes apparent in a can't-be-undone
| manner. Google sides with the former, Firefox and Apple err
| the other way. At what point a small potential risk for
| everybody is worth QoL benefits for a relative few, is the
| main point of contention (the second largest probably being
| a mix of "is the risk really a risk anyway?" or "but you'll
| be fingerprinted to buggery & back anyway so what
| difference does this bit-or-few of data really make?").
|
| A side issue is the concern about the browser becoming a
| bloated almost-but-not-quite full OS, and a huge mess that
| needs much effort to maintain to keep its growing attack
| surface defended.
| Orygin wrote:
| I fail to see what is gained to flash ESP32 from the
| browser vs from a small software gui you can run on your
| computer (and offline as well). Saving the 1 minute setup
| time needed to install the software ? The rest is basically
| the same procedure.
| mvdtnz wrote:
| I have so much shitty desktop software that could easily be a
| web app. The steelseries software that manages my usb headset,
| the crappy Garmin app that connects to my watch, my Corsair
| keyboard software, that awful Logitech management software,
| etc.
| mqus wrote:
| Great, they are now websites. What happens if they decide to
| no longer host them in two years?
| wpm wrote:
| Odds are those shitty apps _are_ web apps.
|
| This entire thread is a symptom of the lack of interest and
| stagnation of desktop software APIs. Does the Logitech mouse
| software need to consume 1GB of RAM so I can map a button? Of
| course not, but Logitech chose that approach because I dunno,
| trying to write a simple Cocoa app for Mac was too hard, made
| their brains hurt, so the complex job of "sending predefined
| configuration parameters in hex over Bluetooth" turns into
| "ship a small web browser because web devs are cheap as chips
| and wRiTe OnCE RuN eVeRyWhErE"
| zamadatix wrote:
| GP is lamenting the apps ship an entire self-contained,
| often outdated, browser one must run and update separately
| for each app because they are desktop apps. Web apps just
| run as a page in your browser like any other site. Not
| everyone who has an issue with a former has an issue with
| the latter.
| bsder wrote:
| So, I suppose you would prefer to not use your Logitech
| mouse on macOS?
|
| If you don't make cross-platform feasible, you will wind up
| with Windows support only.
| aosaigh wrote:
| When developers create Electon apps, HN complains about it.
| When developers then use web serial to avoid having to install
| Electron apps, HN complains about it.
|
| And before anyone says "just write a native app", let me know
| how many small businesses you run where you can afford to
| employ developers to create and manage multiple apps across
| platforms?
| kalaksi wrote:
| Don't be daft. There are plenty of comments for and against.
| HN consists of multiple people.
| mvdtnz wrote:
| Maybe you struggle to imagine uses for USB because you "just
| don't have anything that uses USB". You could just as easily
| argue that USB itself shouldn't exist using that logic. And
| you'd be just as wrong.
| moffkalast wrote:
| A while back I was setting up some LD2410 radar sensors. Of
| course the shitty Chinese level of support is a shady exe that
| only runs on Windows.
|
| Then I found this:
| https://github.com/albertnis/ld2410-configurator which did the
| job by just doing the whole process in a browser. I was really
| amazed that this was even a thing at the time, and it's
| certainly a great way to do multiplatform serial interfaces.
| jy14898 wrote:
| Another way (I think) is to emulate a USB headset and play/listen
| to data encoded in audio
| tanepiper wrote:
| A few years back I wrote a WebSerial/WebUSB app for fun -
| https://web-serial-app.netlify.app/
|
| It still throws a 'Blue screen of Death' for Firefox
| akimbostrawman wrote:
| While I can understand the drama and criticism surrounding the
| "standard", using it to flash GrapehenOS on Pixel phones has been
| one of the most pleasant, easy and fast OS installations
| experiences i ever had on any device. Literally plug, click and
| play.
| swiftcoder wrote:
| > encrypts the private key with the "master" key, and returns the
| encrypted private key as the key handle
|
| 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?
| slater wrote:
| [NSA with their multiple quantum computers has entered chat] /s
| lxgr wrote:
| Good thing AES is quantum-safe, so quantum computers are
| completely irrelevant when it comes to symmetric key
| wrapping.
| lxgr wrote:
| It's exactly as risky as any other possible stateless
| authenticator implementation, if you think about it.
|
| 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.
| lxe wrote:
| This is the reason I don't use firefox and opt for Edge instead.
| Mozilla's ridiculous stance on WebUSB, WebSerial and other web-
| forward tech is bizarre. It shuts out a huge hobbyist community
| and diminishes web as a platform.
| miohtama wrote:
| Meanwhile, the other half of Hacker News community complains
| web browsers have too many features and want go back to Web
| 1.0.
| schmidtleonard wrote:
| The classic balancing act between minimizing attack surface
| vs "if it can't be used, it can't be abused."
| izacus wrote:
| Or a classic selfish "I don't use it so noone else should
| have it".
| 85392_school wrote:
| Web Bluetooth and the File System API are among other APIs not
| supported by Firefox.
| lxe wrote:
| Exactly... making Photopea's UX worse.
| inetknght wrote:
| "I want to make cool things without thinking about how doing so
| will make users dangerously unsafe"
|
| Go make cool things. But you need to remember that thing you
| think is cool isn't safe for everyone to play with. Don't shove
| your trash onto others.
| tekchip wrote:
| The benefit to folks who flash devices frequently is obvious.
| However, joe user, the other 3 billion or so users couldn't care
| less. Poking holes in the sandbox for those folks is negligent at
| best.
|
| 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.
| lxgr wrote:
| Wow, U2F already encapsulates its protocol messages in USB HID
| messages for compatibility, as far as I understand - so now we
| can encapsulate arbitrary protocols in U2F messages?
|
| Beautiful. I hate it. But I also love it.
| Aurornis wrote:
| This comment section is a fascinating mix of people who use
| WebUSB talking about how great it is and people who don't use
| WebUSB being confused about why anyone would want it.
|
| 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.
| wazoox wrote:
| Yeah, except that someday the site that provide that useful app
| may be gone once and for all, while the app would remain just
| fine until you uninstall it. So it's a double-edged sword.
| diggernet wrote:
| > may be gone once and for all
|
| ...and the domain taken over by a scammer who puts up a fake
| app that does unspeakable things to your USB device.
| SunlitCat wrote:
| > does unspeakable things to your USB device
|
| Taken out of context (and meaning), this sounds kinda
| naughty! :D
| anon7000 wrote:
| The app they make would probably be Internet enabled with
| electron so... prolly also won't work
| croes wrote:
| I'm more concerned about security by giving a webbrowser too
| much access to local resources.
|
| Convenience and security don't fit together
| moffkalast wrote:
| Almost as if we've got some kind of notification that asks
| you if you want to give a browser access to a certain device
| huh?
| croes wrote:
| Because browser never have bugs.
| kccqzy wrote:
| Yeah but if I need to talk to a local device, I trust
| browser's security far more than a random vendor's native
| app. I recently bought a keyboard that allows remapping keys;
| the vendor has both a native app and a web app to do it: I
| trusted the web app far more.
| croes wrote:
| So you don't trust the vendor. Maybe using their hardware
| isn't a good idea in the first place.
|
| 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.
| paulddraper wrote:
| Example: Purchasing shipping labels, and using a scale to weigh
| the physical items. (Technically that's HID not USB, but
| similar idea.)
| hackernudes wrote:
| Quick summary.
|
| 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.
| sedatk wrote:
| Yes, this isn't for accessing arbitrary devices. It can be used
| to build custom devices that can be used by webpages without
| any consent prompts though.
| nine_k wrote:
| But possibly this MCU's firmware can be expanded to serve a
| WebUSB lookalike of sorts?
| owebmaster wrote:
| so if I understood it right, Firefox is vulnerable to the
| problem they wanted to avoid but without giving us WebUSB?
| kevincox wrote:
| No, because the device they are accessing needs to be
| specifically built for this use case. So you would need to
| give the user a malicious device then use a malicious
| webpage. The attack scenario isn't impossible, but is far
| less then those that are possible with WebUSB.
| contravariant wrote:
| While not impossible, I just can't think of a good reason
| why you'd need them to access a malicious webpage when
| you've already gotten them to install a malicious device.
| fhars wrote:
| No, USB is vulnerable to malicious devices.
| mortalkastor wrote:
| This is nothing new.
|
| Up until ~5 years ago, hacking U2F to make it pass (smuggle?)
| arbitrary data was exactly how hardware wallet like those from
| Ledger and Trezor were communicating with websites and web
| extensions (like Metamask), for the lack of a better alternative.
| This is how hardware secured "web3" came to be.
| beezle wrote:
| Isn't this similar to why most people turn off UPnP on their
| routers and other similar devices, for security reasons?
| stockhorn wrote:
| Couldnt we add some "usb descriptor flag" which says whether
| WebUSB should be allowed or not? Then firefox/chrome would not
| need to maintain a blocklist.
| franga2000 wrote:
| A bit OT, but most of this thread seems to be generally about
| WebUSB, not the OP (although it is a pretty cool hack!)
|
| 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.
___________________________________________________________________
(page generated 2025-03-14 23:00 UTC)