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.
> 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.
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.
Just because it's in a browser doesn't mean it's remote access. Javascript APIs can be accessed locally.
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.
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.
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.
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.
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.
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).
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.