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.
taylor 
@reiddragon @leoluk > and once you know what code you're running, it won't change
you are aware that native apps can update themselves silently, yes?
@reiddragon @leoluk which, uh, everyone (+/- 30%) does, and like, it kinda is inherent. and also, you're kidding yourself, no vendor of a consumer product is releasing anything except a windows app, maybe a mac app, both of which will install startup daemons which you can't easily disable. maybe you'll get a CLI tool from some nerds, which you'll probably just download the release binary which you have no way to validate is actually the source on git because nobody wants to sit in IDA/Ghidra and pull it apart
this is definitely a more secure ecosystem than shipping a HTML file that is plain text and much more easily reversible, and only has access to the one USB device you chose and completely disappears as soon as you close the tab
@tay @leoluk > and like, it kinda is inherent
Then you don't know what the word 'inherent' means. Just because something is common, doesn't mean it's inherent. If I go to a club and see everyone smoking, would it be right to conclude humans inherently smoke?
> no vendor of a consumer product is releasing anything except a windows app, maybe a mac app, both of which will install startup daemons which you can't easily disable
And I hate those, too. Two things can be bad at once. Right now you're doing the same logical fallacy as people who say we can't criticize neoliberals anymore because if we do the nazis will come to power.
> this is definitely a more secure ecosystem than shipping a HTML file that is plain text and much more easily reversible, and only has access to the one USB device you chose and completely disappears as soon as you close the tab
html isn't code, javascript and wasm are. javascript is most often heavily obfuscated to the point you're better off looking at C code in Ghidra than trying to make sense of the obfuscation, and wasm is obfuscated by default (and wouldn't you know, quite a lot of websites depend on wasm these days)
and again, access to that one single USB device is all it needs if the program is malicious because it can use the USB device as a roundabout to the main system. Giving hardware access to code which inherently cannot be trusted (and web code inherently cannot be trusted) is just never safe, ever, no matter how much sandboxing you attempt. Running javascript and wasm isn't safe even without usb access when JITs allow them to exploit CPU bugs, and GPU access is outright unrestricted outside of the usual bounds imposed on all programs.
Then you don't know what the word 'inherent' means. Just because something is common, doesn't mean it's inherent. If I go to a club and see everyone smoking, would it be right to conclude humans inherently smoke?
> no vendor of a consumer product is releasing anything except a windows app, maybe a mac app, both of which will install startup daemons which you can't easily disable
And I hate those, too. Two things can be bad at once. Right now you're doing the same logical fallacy as people who say we can't criticize neoliberals anymore because if we do the nazis will come to power.
> this is definitely a more secure ecosystem than shipping a HTML file that is plain text and much more easily reversible, and only has access to the one USB device you chose and completely disappears as soon as you close the tab
html isn't code, javascript and wasm are. javascript is most often heavily obfuscated to the point you're better off looking at C code in Ghidra than trying to make sense of the obfuscation, and wasm is obfuscated by default (and wouldn't you know, quite a lot of websites depend on wasm these days)
and again, access to that one single USB device is all it needs if the program is malicious because it can use the USB device as a roundabout to the main system. Giving hardware access to code which inherently cannot be trusted (and web code inherently cannot be trusted) is just never safe, ever, no matter how much sandboxing you attempt. Running javascript and wasm isn't safe even without usb access when JITs allow them to exploit CPU bugs, and GPU access is outright unrestricted outside of the usual bounds imposed on all programs.
@reiddragon @tay I don't think anyone is saying that it's 100% safe (nothing is, obviously), but that it's *safer* to run applications in the browser sandbox, especially considering most real world use cases. IMO, that makes WebUSB a good thing.
Browser sandboxes are very robust. Exploits are rare and expensive (750k+ Google bug bounty, 2-3M on the black market) and using them risks burning them. It's an imperfect, but very effective security boundary.
@leoluk @tay except you were saying it's safe just earlier.
When code can inherently not be trusted, you should give it as little access as possible because even then running it is risky, but that's not at all what web browsers (especially Chrome) do; they keep punching holes in that sandbox, making the runtime more akin to the JVM or .NET CLR, all while keeping all the inherent issues of having code delivered just in time over the network from random sources which you can't trust. JITs and WebGL cause all sorts of unnecessary risks but oh look, we can run GTA in a web browser now! WebUSB, WebBluetooth, and other similar holes in the sandbox are just a continuation of that, causing endless risks just because the results are flashy
When code can inherently not be trusted, you should give it as little access as possible because even then running it is risky, but that's not at all what web browsers (especially Chrome) do; they keep punching holes in that sandbox, making the runtime more akin to the JVM or .NET CLR, all while keeping all the inherent issues of having code delivered just in time over the network from random sources which you can't trust. JITs and WebGL cause all sorts of unnecessary risks but oh look, we can run GTA in a web browser now! WebUSB, WebBluetooth, and other similar holes in the sandbox are just a continuation of that, causing endless risks just because the results are flashy
LisPi@reiddragon @leoluk @tay Caveat: It's perfectly possible to do JIT safely & properly. (Some things cannot be JIT'd in a general manner safely, of course.)
It is a design choice to do it wrong (prioritizing speed over correctness) like is current common practice.
@reiddragon @leoluk @tay Having re-read the post, I would also say that code that is inherently untrustworthy/malware simply shouldn't be allowed to run directly on the CPU, even with virtualized isolation.
Some manner of constrained memory-safe emulator should be used (so that, at worst, it can either crash the emulator or waste resources).
Some manner of constrained memory-safe emulator should be used (so that, at worst, it can either crash the emulator or waste resources).
@lispi314 @leoluk @tay personally I wouldn't trust javascript and WASM to run in anything but an interpreter so damn simple there can be no security issues in it. Would that be slow? Maybe, but then maybe websites should also stop being bloated as all hell and only use scripts for stuff that actually needs it.
@reiddragon @leoluk @tay Generally I would prefer to just have non-code payloads.
I'd prefer to exclusively run trusted Free/Libre Software and just interact with everything else through inert messages.
I can dedicate a machine to low/no trust operation, but I should not be expected to do that with every machine.
Pretty much everything else runs into Turing completeness issues & so on, which is a rabbit hole with no good ending.
I'd prefer to exclusively run trusted Free/Libre Software and just interact with everything else through inert messages.
I can dedicate a machine to low/no trust operation, but I should not be expected to do that with every machine.
Pretty much everything else runs into Turing completeness issues & so on, which is a rabbit hole with no good ending.
@lispi314 I mean, sure, but when trying to convince people that the current model of the web is broken, I'm already radical enough with "maybe website shouldn't have direct hardware access" that I got spammed yesterday with replies from people who think I'm a lunatic for that
@reiddragon I think my instance has just been blocked as collateral by too many for me to experience that often.
@lispi314 I mean, it doesn't happen *often*, all it takes is one reply that gets unexpectedly popular and everyone jumps on it
@reiddragon Yeah. I was actually pretty surprised how I only offended one LLM cultist the other day (at least enough for replies, who knows how many blocked me on sight upon reading Free Software), as I poked the adafruit thing in a popular thread.