Hacker News Reader

Comment by tetris11 | Hacker News Reader

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.

View on HN

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

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.

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

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

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!

I believe there are still a number of applications where Scroll Lock is useful, most notably Microsoft Excel.

how so?

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

That functionality would actually be useful in all sorts of games, but that's probably a lost cause at this point. We've settled on other paradigms.

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.

You can't manipulate capslock state from JS.

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.

Because the browser interacts with my camera/mic through specific media APIs that don't allow it to flash the firmware.

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.

Sorry, you're right. I guess it allows you to just change settings. Still, its unclear what those settings constitute, and how easily a keylogger could be embedded there.

QMK is open source keyboard firmware. Obviously yes, you can install a keylogger. You can't download one via a web app.

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

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.

Yep, this is my current workflow -- not the easiest, but the one I trust the most

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.

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?

i'm just guessing here but maybe only chrome is asking that. if the malware is another program, no confirmation is required?

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.

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

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

Oh thanks for this

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.

Missing the point entirely. You must still enable USB support from the site before it can see or interact with anything.

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.

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?

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.

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.

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

On security focused distros, it obviously works in neither browser right now, because it's a fucking stupid idea.

Except the browser can't even see the device if it's even a vaguely secure operating system.

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.

What group does the browser run in. Surely it's the same group as the user, and has the same wheel privileges, no?

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.

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.

Reply on news.ycombinator.com