And then we get thousands of posts whining about Safari being broken because it is "not like Chrome" and developers moaning that their unsafe pet API is not supported. Web developers are never going to play ball.
Some fun examples of "your browser is an OS on top of your OS":
The Screen Wake Lock API provides a way to prevent devices from dimming or locking the screen when an application needs to keep running. https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake...
The Web Serial API provides a way for websites to read from and write to serial devices. https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_...
The Window Management API allows you to get detailed information on the displays connected to your device and more easily place windows on specific screens, paving the way towards more effective multi-screen applications. https://developer.mozilla.org/en-US/docs/Web/API/Window_Mana...
The Compute Pressure API is a JavaScript API that enables you to observe the pressure of system resources such as the CPU. https://developer.mozilla.org/en-US/docs/Web/API/Compute_Pre...
(my thesis is, not all web developers want this stuff, and usually when I talk to people in the industry they agree, it's excessive)
It would be easier to sandbox if there were fewer features of course, but in practice we rarely see exploits even in complicated low-level APIs like webgpu (which must be a nightmare to make secure given how many buggy drivers and different devices it has to support). So it seems like in practice we are able to sandbox these APIs securely, and having them provides an incredible benefit to users who are able to securely and easily run applications (how else do you recommend people do this on desktop platforms?).
I can't think of an analogy that doesn't come off crass.
I posit the likelihood the morass that is webgpu not having exploitable bugs approaches 0 approximately 25 seconds after the first public release of the code, if not months prior.
Its only when one of two things occur that publishing happens, basically: intelligent frustration, and "for the lols".
Someone hits a bug and gets pissed that the authors of the libraries blame everyone but the library authors. When working around the bug discover its not just a bug. Warn devs. Sometimes responsible disclosure means a quiet fix and then disclosure, but usually it means "here's the exploit they don't care ig"
If there's not enough curious people poking things, exploitable stuff could remain hidden too long.
There's an obscure use case for this called "Watching Video"
I am not a web developer but I completely agree with you. To me, adding more complex points of failure in humongous piles of code that we absolutely need to run in a modern life is not a great risk assessment. It’s like we never learnt from the security issues with the JVM.
It’s often the ancient APIs from around 1995-2001 that are the most vulnerable ones, with information leaking across origins (like todays) needing hacky fixes to stay secure and compatible.
window.open(), target=_blank, cross site request forgery, etc.
IE6 from 2001 had a ton of these modern security issues, and Netscape before it probably had them too.
At that time there were tons of buffer overflow security holes so no on cared about side-channel attacks.
I consider it pretty great, since the alternative is installing native apps for things I'm using exactly once or very rarely.
There's a case to be made though that maybe these things should only be available to PWAs, which is what Apple is already doing for some functionality on iOS, including push notifications.
