[crote]

The knife cuts both ways, though: webusb / webhid / webmidi allow raw access to physical devices which weren't designed for it, and therefore don't have any protections for it. You're just one nag screen away from having your devices be permanently hacked by some random website.

It's quite worrying seeing the Chrome team have such blatant disrespect for basic security. Rather than using an allowlist for known-good devices or using some kind of handshake to validate the device is okay with a certain website talking to it, they use a blocklist to prevent a website from messing with things like keyboards/mice/u2f keys. It's a massive footgun waiting to go off.

Firefox refuses to implement those APIs due to security concerns, and until they do a serious design overhaul it'd probably be better if Chrome hid it behind a default-off feature switch too.

[exe34]

I'm pretty sure I did have to give permission for this to work, and my default instinct for such requests is to say no or close the page immediately, unless it's something I actively want, like in this case. I take your point though, I'd prefer that there were a whole other page I had to go to and enable something like this.

On the other hand, I've always hated how even something I've written for myself can be hobbled at the alter of security out of religious zeal. At one point you really couldn't access local files, although the orthodoxy has now shifted. I just wish it were easy to just point to a directory and say that's all you're getting, but do whatever you want in there.

[egberts1]

Not to mention how data can be leaked back to the hoster via steady stream of URLs.