It's not "purely hypothetical." It's reckless and irresponsible of you to spread misinformation like that based on wishful thinking.
WebUSB made it possible to work around Yubikey phishing protection [1]. WebMIDI allows websites to overwrite device firmware, which is a dangerous capability that could result in a sandbox escape [2]. Granting a website WebNFC permissions makes it possible to read TOTP tokens stored on Yubikeys at any point later on [3], which is worrying because ordinary users can't possibly deduce that from permission prompts. Battery Status API was heavily abused for fingerprinting by the time it was removed from Firefox [4]. I'm amazed that you dismissed that as a "hypothetical" concern, because if anything, it's the legitimate uses of the API that was hypothetical [5]. Uber used it to "inflate Uber prices for desperate users with low batteries." [5] [6].
But one don't even need theses examples to see how bad theses APIs are. Hardware are mostly designed to work with local applications. To expose them to websites is a fundamentally flawed idea. Google justifies them by adding permission prompts each time a problem emerges, but users can't possibly be expected to be fully aware of the consequences of allowing raw hardware access to websites with mere dialogs that they blindly click through.
And oh I wish there were only 3 bad APIs like you hinted. There are more than that. WebMIDI, WebNFC, WebSerial, WebHID, Generic Sensor API, File System Access, Low-level Sockets API, Network Information API, and the list goes on.
These aren't isolated examples. It's part of a broader pattern where Google ships an anti-feature, asks for "feedback" which means nothing because "devs already depend on it," and "standardizes" it despite opposition from the remaining browser vendors [7] [8].
I’ll judge browser security based on a broad set of examples rather than a cherry-picked one every time.
If a particular feature is controlled by a permissions prompt, saying that 'users can't be expected to be fully aware of' the consequences of a particular permission edit has, once again, nothing to do with security as everybody in the world besides yourself understands that term. Criticise their UI team, perhaps, but such a problem has nothing to do with security - indeed the 'feature' might be working exactly as intended, notwithstanding the (in your view) unclear wording obscuring it.
At this point I can only assume that your conflating of security and privacy is pathological, and I very much doubt that we can have a fruitful discussion about this.
Take WebMIDI, for example. A website using it would show the following permission prompt in Chrome:
example.com wants to
Control and reprogram your MIDI devices (SysEx)
[Block] [Allow]
According to you, everyone should understand that term to mean example.com can access their device to overwrite the firmware of a MIDI device, turn it into a keyboard, and take full control of the computer. It's feature working as intended and no security issues are involved.
I am so glad both Apple and Mozilla doesn't subscribe to you or Google's definition of "security." These gaping security holes can cause so much damage, and to see these as "features working as intended" shows how disconnected you are with actual users. Even the infamous ActiveX would not have security issues if we redefined security under your terms. A browser should never ever include capabilities for full system compromise as one of its features. No permission prompt should ever let that happen.
You also need to consider the inherent danger of exposing hardware to websites when considering whether permission prompts are adequate. Again, hardware aren't designed with the expectation that they'll be exposed to websites. Browser vendors can't possibly be aware of the security implications of doing so for every device out there either. That was one of the core arguments of my previous reply and I wish you hadn't omitted that. Unfortunately, my point about the permission prompt was taken out of context and spun into a "pathological" view that "everybody in the world besides myself" would laugh at.
Lastly, you might want to actually look at the examples I posted. Some of them don't or didn't involve permission prompts and enabled attack by third parties. Which I believe to be a security issue even under your terms.
WebUSB made it possible to work around Yubikey phishing protection [1]. WebMIDI allows websites to overwrite device firmware, which is a dangerous capability that could result in a sandbox escape [2]. Granting a website WebNFC permissions makes it possible to read TOTP tokens stored on Yubikeys at any point later on [3], which is worrying because ordinary users can't possibly deduce that from permission prompts. Battery Status API was heavily abused for fingerprinting by the time it was removed from Firefox [4]. I'm amazed that you dismissed that as a "hypothetical" concern, because if anything, it's the legitimate uses of the API that was hypothetical [5]. Uber used it to "inflate Uber prices for desperate users with low batteries." [5] [6].
But one don't even need theses examples to see how bad theses APIs are. Hardware are mostly designed to work with local applications. To expose them to websites is a fundamentally flawed idea. Google justifies them by adding permission prompts each time a problem emerges, but users can't possibly be expected to be fully aware of the consequences of allowing raw hardware access to websites with mere dialogs that they blindly click through.
And oh I wish there were only 3 bad APIs like you hinted. There are more than that. WebMIDI, WebNFC, WebSerial, WebHID, Generic Sensor API, File System Access, Low-level Sockets API, Network Information API, and the list goes on.
These aren't isolated examples. It's part of a broader pattern where Google ships an anti-feature, asks for "feedback" which means nothing because "devs already depend on it," and "standardizes" it despite opposition from the remaining browser vendors [7] [8].
I’ll judge browser security based on a broad set of examples rather than a cherry-picked one every time.
[1]: https://www.wired.com/story/chrome-yubikey-phishing-webusb/
[2]: https://github.com/mozilla/standards-positions/issues/58
[3]: https://github.com/mozilla/standards-positions/issues/238
[4]: https://www.cs.princeton.edu/~arvindn/publications/battery-s...
[5]: https://groups.google.com/g/mozilla.dev.platform/c/5U8NHoUY-...
[6]: http://www.forbes.com/sites/amitchowdhry/2016/05/25/uber-low...
[7]: https://github.com/mozilla/standards-positions/issues/459
[8]: https://twitter.com/rich_harris/status/1220412711768666114