> No. But I wouldn't grant a "random" website hardware access either.

We’ve trained people unskilled in IT that’s apps are dangerous and websites are safer. They’ve finally gotten it.

So let’s make websites unsafe, only one click away (which we know users will click)! What a great idea!

Sounds like your only objection is over how scary-looking the prompt is?

Running a downloaded executable is already "one click away", and connecting a website to a Bluetooth device isn't nearly as dangerous as running an executable. The difference in levels of access and size of the exposed attack surface is huge.

It’s all baby steps.

WebDRM: subvert control of the machine from the user.

WebUSB: allow browser-based attacks on physically connected hardware.

WebBLE: allow browser-based attacks on wirelessly connected gadgets too!

What’s next? WebDMA? WebFdisk?

Sorry, but an industry that constrains progress to keep up with its slowest users isn't what I signed up for.

The case for a reputable website is even stronger given that you can literally inspect the source code as it runs. While a native program might require disassembly and de-obfuscation, a website can only deliver JavaScript that can just be copy-pasted into a text editor.

The one exception I can think of might be WebAssembly, but to date most native features (like location, filesystem access, even manipulating the DOM) require interop with JS to be used by wasm.

Plenty of websites minify their javascript, which is on the train to obfuscation. Javascript is definitely obfuscatable if desired.