[Amekedl]

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?

[kuschku]

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.

[vbezhenar]

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.

[microtonal]

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.

[junon]

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

[tuananh]

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]

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

[tuananh]

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