Cato, registered LynxⓁprobably not the first person with this idea but
Reid 
Leo@ALLES@reiddragon idk - usually, the alternative is downloading some random native app, I'd rather have a nicely sandboxed webpage with permission prompts?
@leoluk with a local program the code can't just randomly change overnight like with a website. Websites are also vulnerable to XSS. And also, how is it any semblance of sandboxed if it has direct access to USB devices?
@reiddragon If I give a random website access to a random IoT device (say, the Zigbee stick I just flashed earlier), that gives it access to just that one device. A native app has much broader access and can be vulnerable to all sorts of things.
@leoluk that USB device doesn't interact with just the website, though, and depending on what device you give it access to, it can be used to gain access to much more (ESPECIALLY when you're flashing firmware).
And webusb isn't the only thing; websites also have very direct access to the GPU by default, meaning they can very directly try to exploit bugs in the graphics driver and get access to stuff the browser never gave them access to. And webbluetooth can also be exploited in a manner very similar to webusb
And webusb isn't the only thing; websites also have very direct access to the GPU by default, meaning they can very directly try to exploit bugs in the graphics driver and get access to stuff the browser never gave them access to. And webbluetooth can also be exploited in a manner very similar to webusb
@reiddragon Right, but all of that applies to a native app as well. Having a sandboxed runtime with USB and Bluetooth access is an improvement in my mind. If it didn't exist, users wouldn't stop attaching proprietary peripherals, but they'd instead download a random native (Electron, lol) app instead, which is a much greater security risk.
@leoluk native programs can be verified, and once you know what code you're running, it won't change; websites change all the time without your knowledge - if you're running some code today, you may not be running it tomorrow; and even when the program itself isn't malicious, being in a browser also makes them vulnerable to XSS; a local program won't just randomly change its code, and can't just randomly have code injected remotely from some random site.
@reiddragon This is true for you and me, but not the average user. They don't verify or build their tools from scratch, and IMO, "opening random website with WebUSB/WebBluetooth" is a major security win over "executing random code".
I maintain a popular WebBluetooth application, which is a reverse-engineered client for a proprietary health gadget. It replaces a .exe from a random vendor website (served via HTTP...). A web app is much nicer than asking users to download and run arbitrary code.
@leoluk
> This is true for you and me, but not the average user.
So because the average user is ignorant means we should just accept major security issues?
> a major win over "executing random code"
You're still executing random code. No amount of sandboxing can prevent security issues, as we've seen time and time again whenever applications break out of "sanboxed environments"
> This is true for you and me, but not the average user.
So because the average user is ignorant means we should just accept major security issues?
> a major win over "executing random code"
You're still executing random code. No amount of sandboxing can prevent security issues, as we've seen time and time again whenever applications break out of "sanboxed environments"
@reiddragon My point is that WebUSB/WebBluetooth meaningfully improves security for the average user, so it's a net positive. It's opt-in with a permission prompt.
@leoluk oh, don't kid yourself. You already know exactly how the average user treats these prompts: They just agree to absolutely everything to get the popup out of their face and then wonder why their computer and/or phone keep getting spammed with notifications about hot singles from their area, not aware that it's because they just permitted every random website to send them notifications.
@reiddragon This kind of user would blindly download and install a random binary, or Android app, or whatever, if that's what it takes to get their gadget running (speaking from experience here...). One of these alternatives is much safer than the others.
And even for experienced users like myself, I would much rather run an open source utility in a sandbox vs outside a sandbox. I can't possibly read and verify every single line of code in it, and escaping the Chromium sandbox is expensive.
taylor 
@reiddragon @leoluk i think you think the web is way less secure than it actually is
the web is what a lot of us use to do banking, interact with government services, etc, and i haven't heard of many serious actually vulnerabilities recently, and like im talking about actual instances of exploits, don't just wave around the term "XSS" like it's some magical bullet that every website is vulnerable to
@tay @leoluk if the code running inside is well behaved and doesn't just import a fuckton of remote code for ads, trackers, and other stuff, then sure, but just go to a popular website and watch how much junk uBlockOrigin has to block.
The issue isn't for the servers, it's for the clients. Servers inherently don't trust clients to behave and that's why they're safe. Clients just inherently trust websites to not try to exploit some CPU or GPU bugs or misuse permissions they get.
The issue isn't for the servers, it's for the clients. Servers inherently don't trust clients to behave and that's why they're safe. Clients just inherently trust websites to not try to exploit some CPU or GPU bugs or misuse permissions they get.