undefined | Better HN

0 pointsRReverser4y ago0 comments

> and I think that they were only exposing features like that to trusted code (meaning apps you deliberately installed) rather than general web content

I'd actually be pretty happy if browsers chose to implement those APIs with the same restriction in mind - that is, only for explicitly installed PWAs. I said this elsewhere in the past, and I still think that's a reasonable restriction that could provide a path forward.

> or mitigating one of the two critical problems of WebUSB (that the computer trusts peripherals too much, so that one that’s hijacked can more easily become a remote code execution vulnerability)

I'm not very well-versed in the details, but I believe that's also the reason why WebUSB (or Chromium implementation of WebUSB?) doesn't allow certain classes of devices to be ever accessed via that API.

0 comments

2 comments · 1 top-level

chrismorgan4y ago· 1 in thread

Limiting it to installed apps still has the problem of users blindly agreeing to something that is fundamentally super dangerous. I don’t believe installing PWAs currently exposes any new security surface, so this would be a significant change, and worse still a persistent hazard with probably no indication of what’s going on when it’s in use. I think there’s still potential in the general concept, but it’d take work and is certainly not ready yet in any browser.

Yes, certain classes are restricted from access via WebUSB for security, https://wicg.github.io/webusb/#protected-interface-classes. But as the note says, it’s about balance: that list is necessary for security, but not sufficient.

RReverserOP4y ago

> Limiting it to installed apps still has the problem of users blindly agreeing to something that is fundamentally super dangerous.

Same can be said about native apps. Like with other hazards, in the end it's all about balance - you can't stop users from _ever_ doing stupid things.

j / k navigate · click thread line to collapse