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.

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.

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

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.

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