4 ms·

> There is no reason whatsoever to allow remote access to USB devices Sorta but that's not what this standard is proposing. It's proposing a way of accessing a

> There is no reason whatsoever to allow remote access to USB devices Sorta but that's not what this standard is proposing. It's proposing a way of accessing a USB device from a web browser. There isn't any remote access happening here (at least not directly though with this standard you could theoretically do that). This is simply so web apps can get closer to native apps in functionality.

creshal 11y ago
Web apps, and malware injected into adverts. Oh joy.
pdkl95 11y ago
> It's proposing a way of accessing a USB device from a web browser. > There isn't any remote access If you don't see the contradiction between these two statements, I don't know how to help you. 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 is simply so web apps can get closer to native apps in functionality. That's a terrible idea. Blurring the lines between a webpage and a native app simply teaches people to treat webpages as if they were a local app, when the should be learning to treat anything form the network as potentially hostile. If you don't have a clean separation between the remote UI and the local UI, you're creating the perfect situation for phishing attacks.
- derefr 11y ago
  > If you don't have a clean separation between the remote UI and the local UI, you're creating the perfect situation for phishing attacks. I don't know what you're imagining my computer works like, but I don't have a separation between local and remote UI. I have a separation between OS and application UI (e.g. the Windows Ctrl+Alt+Del dialogue) but everything else is untrustworthy, local or no. A local app can be executing untrusted logic "sourced from" the internet just as well as a remote app can. To say otherwise is to presume that all updates to all apps on your PC go through a third-party that verifies that they never add any remotely-accessible "extension points" that weren't there in previous updates. Obviously, this is not the case, even for the strictest corporate device-management release-engineering program.
- ybx 11y ago
  > If you don't see the contradiction between these two statements, I don't know how to help you. Just because it's in a browser doesn't mean it's remote access. Javascript APIs can be accessed locally.
- BinaryIdiot 11y ago
  > 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.
- yoklov 11y ago
  It might be a terrible idea, but keep in mind that practically every development platform aside from the web is becoming more and more locked down as time passes (app stores, etc). Which sucks, obviously, but it's not surprising that there's an attempt to bring the web closer to parity with native, since it seems to be a more tractable problem than stoping what's happening to native platforms.

creshal 11y ago

Web apps, and malware injected into adverts. Oh joy.

pdkl95 11y ago

> It's proposing a way of accessing a USB device from a web browser. > There isn't any remote access If you don't see the contradiction between these two statements, I don't know how to help you. 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 is simply so web apps can get closer to native apps in functionality. That's a terrible idea. Blurring the lines between a webpage and a native app simply teaches people to treat webpages as if they were a local app, when the should be learning to treat anything form the network as potentially hostile. If you don't have a clean separation between the remote UI and the local UI, you're creating the perfect situation for phishing attacks.

derefr 11y ago
> If you don't have a clean separation between the remote UI and the local UI, you're creating the perfect situation for phishing attacks. I don't know what you're imagining my computer works like, but I don't have a separation between local and remote UI. I have a separation between OS and application UI (e.g. the Windows Ctrl+Alt+Del dialogue) but everything else is untrustworthy, local or no. A local app can be executing untrusted logic "sourced from" the internet just as well as a remote app can. To say otherwise is to presume that all updates to all apps on your PC go through a third-party that verifies that they never add any remotely-accessible "extension points" that weren't there in previous updates. Obviously, this is not the case, even for the strictest corporate device-management release-engineering program.
ybx 11y ago
> If you don't see the contradiction between these two statements, I don't know how to help you. Just because it's in a browser doesn't mean it's remote access. Javascript APIs can be accessed locally.
BinaryIdiot 11y ago
> 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.
yoklov 11y ago
It might be a terrible idea, but keep in mind that practically every development platform aside from the web is becoming more and more locked down as time passes (app stores, etc). Which sucks, obviously, but it's not surprising that there's an attempt to bring the web closer to parity with native, since it seems to be a more tractable problem than stoping what's happening to native platforms.