[kscz]

I think perhaps the point that the others in this thread are making should be rephrased: you execute untrusted code in the browser, and giving that untrusted code effectively direct access to the USB peripherals is frightening. If you trust some website with "webUSB permissions", and that website has a cross-site scripting vulnerability, you've given a remote actor the ability to manipulate some USB device(s).

That being said, I'm a little confused about your definition of "remote" access. If I have a jetty server with a remotely exploitable hole in it, someone who exploits that hole is depending on me running a local client, but I would still consider it a "remote" exploit. In the same vein, someone running a browser that I can compromise with purely code on external websites is still being "remotely exploited." The attack vector requires the client to visit a specific page or click a specific link, but I didn't have to walk up to their computer and insert a USB stick. That's what makes the attack a "remote" attack for me.

[BinaryIdiot]

> you execute untrusted code in the browser, and giving that untrusted code effectively direct access to the USB peripherals is frightening.

But if you read the linked specification you're not doing that. You're giving them access to an abstraction that is quite limited in what it can do. If you had direct access you could reflash firmware.

> If I have a jetty server with a remotely exploitable hole in it, someone who exploits that hole is depending on me running a local client, but I would still consider it a "remote" exploit.

Yes of course that's "remote". It requires network connections to access.

> In the same vein, someone running a browser that I can compromise with purely code on external websites is still being "remotely exploited." The attack vector requires the client to visit a specific page or click a specific link, but I didn't have to walk up to their computer and insert a USB stick. That's what makes the attack a "remote" attack for me.

That's not remote at all. That's entirely client based. The client just happens to load some sort of exploit on its own. If it was really remote you could push a script to the client using its network address.

The client functions the same with or without internet connectivity. The jetty server example does not.

[kscz]

Well, I think we'll have to agree to disagree here on terminology!

When a browser gets a malicious advertisement or a user gets a malicious cross-site scripting attack, I consider that remote exploit. Yes, it required the client to do something (i.e. visit a malicious page), but there are plenty of things which you can do to create that state without much user interaction. If I might ask, what do you call attacks like these?

I agree though that my Jetty example wasn't a good one, I was just making the point that the exploit was still in client code (i.e. something running on the victim's machine).