I like that your comment, which is at the very top of this comment section, quotes a statement concerning Web USB, Web Bluetooth, Web NFC and Web MIDI.

The linked post is about WebSerial. The concerns about Web USB, Web Bluetooth, Web NFC and Web MIDI mostly don't apply. Most users have USB and Bluetooth devices connected, many have MIDI devices. Pretty much nobody who isn't in the specific target audience for WebSerial is going to have a serial device connected. And even if the concerns did apply, you should probably quote a statement which talks about WebSerial.

> it's not intuitive that allowing malicious-site.com to access your Bluetooth keyboard might give that site access to your stored passwords, give them the ability to hijack your DNS settings, or allow them to encrypt your hard drive and hold it ransom. And if it's not immediately obvious how those things are possible, that only serves to demonstrate how completely non-intuitive the risks are and how intractable trying to explain them in a permission prompt would be.

Which is odd because the very next thing a user will do (Which you've allowed for years) is download and execute a .exe or .dmg/.app from that same malicious-site.com which will do the same thing

I get (ab|l)users will do stupid. I appreciate the argument that WebSerial is not those other things; until it isn't and it's a victim of its own success. Now the driver maintainer at the OS level has to consider that their driver is exposed to the Internet every time an ad is served.

Maybe there should be a WebDevice which you can buy which plugs into a USB port and does all the things (for the things plugged into it) and exposes a "webdev(ice)" to the browser? There's an overengineered solution. Nonetheless in an industrial situation the things are exposed to the controller, not to the machines on the floor. [Edit: Not strictly true, they may be published as visible "tags" through various mechanisms.]

How about wifi?

There's a nasty shear layer / fault here. Don't build a house right on top of it.

I understand and previously agreed with Mozilla's hard line privacy and security stance.

Recently I've changed my mind. I've been building a thing using everything in the web platform, even if it is Chrome only and it is great. You can build apps the blend local and remote systems together in ways that make new things possible - and it is on an open-standard runtime.

But as a long time Firefox user I hate that I have to warn people at some critical features won't work.

I think from a platform point of view having features in the web platform that let it compete with other platforms is worth the trade off.

So, what you're saying is that you agree with the security concerns regarding these API, but your convenience as a developer outweighs them?

No that's a mischaracterization.

I'm saying I think it is important for free and open systems to be competitive with closed ecosystems, and to take advantage of the power of local systems.

I believe in a world where we - as developers - can build systems that have both maximum safety and maximum utility for users.

Currently there are two ways of distributing software that takes full advantage of the hardware users have:

1. AppStores, with centralized, permission based certification of developers in an attempt to make apps safe.

2. Binary downloads, relying on the operating system to make them safe for users.

I believe there should be a third way - a platform that sandboxes users from the worse things that are possible and breaks reliance on cloud platforms.

I think the web platform is the closest to achieving this. I think the security and privacy concerns are valid and well-founded, but I think the trade-offs in pushing permission-based systems are worthwhile.

Take this project as an example. The alternative to web-serial is to download a random executable binary and firmware written by who knows to your computer, with full read/write permissions. I think that is a riskier outcome for users than enabling this API.

The web is not a software distribution platform, it's a platform for distributing thin clients to propriatory walled gardens that will break your use cases or just ban you at will. Users have absolutely no control over the web, so no I don't see it as a superior alternative

I completely disagree.

I've been using the web since 1994, and it's always distributed applications. I mean what were WAIS and Veronica except attempts to build applications - and they were (vastly inferior) predecessors to the web.

The web is the most ugly, horrible, messy, fantastic and beautiful Commons in human history and I love it.

Yes, people will block it and Balkenize it and make it ugly and make terrible apps that run horribly.

But it is better than anything else we've built, so there is that.

I think you're both right. What I dislike about it, is how we went from walled gardens to ads, tracking, and guilt tripping adblock users (while IMO whatever you see or don't want to see is up to the client). It is a huge cat and mouse game.

(That guilt tripping is what worries me in relation to WebUSB and webserial.)

In a TUI, it is still completely unacceptable that the client would spam the user with ads. And if it would, due to FOSS nature it is easy to circumvent.

If web devs are clever they produce an API instead of pure HTML + JS + the whole bloated crap around them. It'd save them costs, and heavy API users could subscribe.

I think it is uncharitable to say "your convenience". It's more like "your vision as a creator". We're talking about developer intent that isn't possible otherwise. You can say "good, it shouldn't be", but don't characterize it as convenience.

Now with Webxxx, the user needs to make sure that it is the right URL, not a fake teanns instead of teams, so he is unsure every time he has to use it. Some random download, once it works, can be reused and you have more trust that it works after the trial was positive.

And if it is open source, you can review the code before compiling. I can't review the code of some random server, as my browser only receives a random wasm binary for example.

But the alternative is binary flashing software AND a binary blob to flash.

This doesn't preclude it being open source in anyway. Infact with a WASM toolchain you could even compile in the browser.

Yep, web serial okay but not bluetooth? "We can't make it secure". Yes you can.

No web bluetooth from inside an iframe, always require consent to select a device and connect to it.

Sure, I suppose it could enable more scams by tricking people into connecting to x device but if we were truly worried about stopping scams we'd turn the internet off and then shotgun our entire species.

The worry is real: there has historically not been a meaningful security barrier between a USB device and software running on the machine it's connected to. Firmware hasn't been developed with the assumption that the machine is malicious, there's probably lots of firmware which you can get RCE on by sending a weirdly formatted USB packet. Lots of devices have pretty unrestricted firmware update via USB functionality. And security is often fairly lax the other direction too; at least Linux implicitly assumes that hardware you connect is trusted, and there are lots of old, insecure drivers for USB devices out there.

Do users understand that by clicking "allow" on a website, an attacker can re-flash their mouse with firmware which causes the mouse to present itself as some obscure USB device which activates a vulnerable driver? That by clicking "allow" on a pop-up from a website, the website can abuse their keyboard to install a key logger or botnet? Should a user be expected to understand this?

I don't know how valid this fear is in practice. Has anyone done a study?

But that isn't how it works, it's not a prompt like asking permission to use the camera allow/deny. The user gets presented with list of compatible devices and they have to select one themselves.

An attacker could try to convince users to select something specific but that depends on the actual devices that are present and the "default" option to a confused non-technical person is to just cancel out of the list.

I know it works like that, the part about "clicking allow'" was a slight oversimplification which doesn't change the point. Do users understand the security implications of giving access to a device in the pop-up? I don't think so.