Mozilla team, if you're reading, please reject implementing or at least enabling such APIs with extremely high-risk to the user by default in your browser - "sandbox" or not.
As "everything" is supposed to live inside a browser window, there "naturally" needs to be rich APIs for accessing whatever the user may decide to plug into ports or their wireless equivalents.
We are going full circle here, with the web "browser" becoming the new leased line terminal. Keep in mind that at the end of the mainframe era, some "terminals" had local hardware that could rival a micro-computer.
This is why the X protocol included support for printing, as the printer would be hooked up to the X "terminal" and not the mainframe (DEC had their own wire protocols for talking either to terminals or printers for doing bitmap and vector graphics).
Everything old is new again, and i wonder if i will live long enough to witness some rainbowhaired dev blog (or whatever it will be called at the time) about how they are gleefully ripping out all this cruft from the "soon" to be retired web protocol.
The issue is that 99.99% of USB devices aren't designed with the possibility of hostile payloads coming from the host, so the security rests entirely on the webusb permission dialog. Which should be presented as "grant this website administrative access to your computer" but isn't.
The other NaCl https://developer.chrome.com/native-client
This is something most companies can't do. Small co., can pull it out that for some times, but as companies grow, the temptation to "simply make money" overwhelms even most principled person.
Also, maybe bluetooth and USB devices don't need to be on the net.
Only if you believe minified JS is significantly easier to audit, which seems rather unlikely.
In both cases, the thing which works is securing the capability rather than the code. Having generic USB support is risky but e.g. having mediated access to cameras and microphones has been fine.
I find it highly unlikely we are going to be able to trust "mediated" access.
How can you build applications on the web that use
Bluetooth or USB devices without these APIs?
The whole benefit of web apps is they demand less trust because they're better sandboxed. Poking holes in the sandbox (like WebUSB) makes web apps worse, not better.
a) Don't do it and pivot your company to doing something else.
b) Implement your own solution with companion native apps that build this missing bridge. Out of public scrutiny and with many times less resources, but hey: the browser is secure! ;)
You simply don't
Really? Web applications can essentially change at the whim of the owner or server(s) hosting them, every time you refresh the page. You have far more control and "transparency" over when a native application changes.
Is it even using tls for network requests? So many things we can’t see in a native app.
You're just not looking hard enough. ;-)
As all the vulnerabilities discovered and exploited in closed-source software shows, along with those in open-source which have been there for many years without being discovered, whether the source is open or closed is nearly irrelevant.
To quote the mentality of those who see beyond that debate, "Source code? We don't need no stinkin' source code!"
Unfortunately, the only viable alternative right now is to install a companion native application. That companion app launches an (https/ws) server that talks to the device and exposes some api for your site to use through javascript.
It is a disgusting can of worms, but if you squash them all you get a working system at the end.