3 ms·

> If you don't see the contradiction between these two statements, I don't know how to help you. Alternatively you could be more constructive and try to explai

> If you don't see the contradiction between these two statements, I don't know how to help you. Alternatively you could be more constructive and try to explain what your position here is because, as I'm reading this standard, I'm not seeing any remote access (it's all client-side). Granted, like I already mentioned, once access is granted you could use something like web sockets to make it accessible remotely but that's a very explicit thing a developer or malicious app has to do. Which, granted, is possible but the user also has to give it access to do such a thing which is no different than allowing camera access which already exists in a similar way. If you want to argue that anything that can be coded to be accessed remotely is outright remote access then...well just about everything is remote access and it kinda loses its meaning. > Stop thinking of what this is supposed to do; it's the failure cases that are the problem. Good security design involves concepts like compartmentalization and defense-in-depth. Finding a browser exploit shouldn't also grant low level access to the USB buss. This shows me you didn't even read the standard. The standard OUTRIGHT says the same thing as you and outlines how their standard WOULD NOT grant low level access to the USB bus. So why even bother commenting if you're not even going to read what's in the standard and comment, incorrectly, about it? This isn't really typical on Hacker News.

ssalazar 11y ago
> I'm not seeing any remote access (it's all client-side) Anything that can be accessed client-side can be easily uploaded via XmlHttpRequest or whatever people use for that now. This is not a new concept. > Granted, like I already mentioned, once access is granted you could use something like web sockets to make it accessible remotely but that's a very explicit thing a developer or malicious app has to do. Hardly- user data is incredibly valuable and you can be sure that for many sites, if a page has access to USB info they will upload and track it. Presumably any foreign JS code imported (e.g. Google Analytics) can also access this data and include it in the information it tracks.
- BinaryIdiot 11y ago
  > Anything that can be accessed client-side can be easily uploaded via XmlHttpRequest or whatever people use for that now. This is not a new concept. Correct but this standard is absolutely not "remote access to USB devices" as the parent suggested. If we're going to abstract the meaning of "remote" to anything that can be uploaded by something that can access it then it loses its meaning entirely. The standard proposes nothing remote from the web to the browser; it's entirely between USB devices and the browser. Saying "allow remote access to USB devices" is entirely misleading hence my original comment. > Hardly- user data is incredibly valuable and you can be sure that for many sites, if a page has access to USB info they will upload and track it. Presumably any foreign JS code imported (e.g. Google Analytics) can also access this data and include it in the information it tracks. What's the "hardly" for? You and I don't seem to be disagreeing here.
  - kscz 11y ago
    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 11y ago
      > 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.

ssalazar 11y ago

> I'm not seeing any remote access (it's all client-side) Anything that can be accessed client-side can be easily uploaded via XmlHttpRequest or whatever people use for that now. This is not a new concept. > Granted, like I already mentioned, once access is granted you could use something like web sockets to make it accessible remotely but that's a very explicit thing a developer or malicious app has to do. Hardly- user data is incredibly valuable and you can be sure that for many sites, if a page has access to USB info they will upload and track it. Presumably any foreign JS code imported (e.g. Google Analytics) can also access this data and include it in the information it tracks.

BinaryIdiot 11y ago
> Anything that can be accessed client-side can be easily uploaded via XmlHttpRequest or whatever people use for that now. This is not a new concept. Correct but this standard is absolutely not "remote access to USB devices" as the parent suggested. If we're going to abstract the meaning of "remote" to anything that can be uploaded by something that can access it then it loses its meaning entirely. The standard proposes nothing remote from the web to the browser; it's entirely between USB devices and the browser. Saying "allow remote access to USB devices" is entirely misleading hence my original comment. > Hardly- user data is incredibly valuable and you can be sure that for many sites, if a page has access to USB info they will upload and track it. Presumably any foreign JS code imported (e.g. Google Analytics) can also access this data and include it in the information it tracks. What's the "hardly" for? You and I don't seem to be disagreeing here.
- kscz 11y ago
  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 11y ago
    > 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.