Kowalski Dragon
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.
@reiddragon I also use the ESPHome web UI to flash stuff (built from source in a sandbox, served from my local server). Personally, I much prefer this, both in terms of security and convenience, over having to run a native app on my local device.
Even if I build it myself, I can't actually read all of the ESPHome source code and its dependencies before building and executing it.
@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.
@leoluk the sandbox doesn't mean shit when it's poked full of holes, though, and web browsers are just that: swiss cheese
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.
LisPi@reiddragon @leoluk One shouldn't be executing random code.
There should, at the very least, be a distribution package manager available with packages that have been vetted by vaguely-trusted parties (you're trusting them with maintaining the OS, if they're not trusted you're kind of screwed) and where you could get appropriate software.
There should, at the very least, be a distribution package manager available with packages that have been vetted by vaguely-trusted parties (you're trusting them with maintaining the OS, if they're not trusted you're kind of screwed) and where you could get appropriate software.
@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
@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
Colin 🐈🌱@reiddragon @cato
I installed /e/os on my phone over webusb. The only reason why I have chromium installed :3
I installed /e/os on my phone over webusb. The only reason why I have chromium installed :3
Dan 🌻@reiddragon @cato @Colin why? The android bootloader shows you the signature of the OS before it boots. You can compare that to the published hash on the website (assuming it's anything like graphene) and at that point it's no different from having used a native app. Apart from the fact that it was way easier for users to use and devs to maintain :)
Rexo the Trans Bus 🏳️🌈🏳️⚧️🚌@cato @[email protected] if you want an actual argument then yes I do actually trust a specific scoped permission more than a native app with full access. I suppose you could have everything in Flatpaks with scoped perms but realistically I'm not sure if 1. companies would bother and 2. people would accept that
@cato @[email protected] also that would restrict people to Linux. better than forcing Windows, but ultimately WebUSB is cross platform
@rexo @cato this is the hundredth time I'm saying this just in this thread, but that permissions system doesn't mean jack shit. It's been compromised many times, can be completely bypassed by someone who knows what they're doing, and even if it worked as intended, it doesn't even cover everything, allowing websites to just get direct access to the GPU driver, letting them exploit it willy nilly, with absolutely no permissions in sight
The. Web. Cannot. Be. Trusted. The whole model was made for serving static documents, not applications. But now they shoved applications in the bloody thing and we're supposed to just pretend the whole thing isn't a giant security nightmare
The. Web. Cannot. Be. Trusted. The whole model was made for serving static documents, not applications. But now they shoved applications in the bloody thing and we're supposed to just pretend the whole thing isn't a giant security nightmare
WooShell
Ceres
DarkRat
Momo@cato
Also: WebMIDI...
(Yes Novation, I look at you with your Components management tool for your synths!)
embix@momo @cato Hab ich bisher nie erfolgreich benutzen können. Brauche ich allerdings nicht zum flashen, sondern nur Noten in Websynths kippen o.ä. Thomanns stompen-dings funktioniert bei mir auch nicht.
Das einzige, was (leider auch nur) in chromiumbased Browsern zuverlässig funktioniert, sind ZSA's Tastaturflashtool und deren 10-Fingertrainingsseite. Für ersteres gibt's auch ein offline-Tool (und prinzipiell ja QMK), für zweiteres monkeytype.
@brezelradar
Ich habs nur mit Chromium zum Laufen gebracht im Zusammenspiel mit Novation Components (und meiner Novation Circuit Tracks) und Behringer SynthTribes (und meinem Behringer Td3). Für Novation muss man unter Linux noch in den modulparametern von snd_seq_midi (/sys/module/snd_seq_midi/parameters/) die Input- und Output-Buffersize auf 131072 hochsetzen (ist per default 4096), sonst schlägt der packupload fehl.
@cato
Ich habs nur mit Chromium zum Laufen gebracht im Zusammenspiel mit Novation Components (und meiner Novation Circuit Tracks) und Behringer SynthTribes (und meinem Behringer Td3). Für Novation muss man unter Linux noch in den modulparametern von snd_seq_midi (/sys/module/snd_seq_midi/parameters/) die Input- und Output-Buffersize auf 131072 hochsetzen (ist per default 4096), sonst schlägt der packupload fehl.
@cato
Owl Eyes
arrie
Harald Hannelius 
@cato web Bluetooth
Rachel
kira for scale
kNeo gHau
machete_Badger
Bastian@cato https://github.com/mozilla/standards-positions/issues/100
Mozilla claims they have privacy concerns
Mozilla claims they have privacy concerns
the sophari™ is currently away@cato
- whats my purpose
= android webview debugging
- oh my god
- whats my purpose
= android webview debugging
- oh my god
Stephen Johnson@cato seems so niche but it’s so completely me/true
Rib 