It's not just you. Browsers are systems-within-systems. They're gigantic, illustrated by the fact that the number of implementations that are well maintained can be counted on one hand. A lot of people take issue with that.

The Web platform is now so gigantic and complex that even Microsoft has decided it's impossible to write a browser!

Or Microsoft did a back of the napkin calculation and realised that the potential increase in user base for Microsoft products wasn’t worth the money.

Their users are already on Windows and Microsoft already has telemetry on them. And we’re talking about the browser guts and not the surface, which is where most of UX lives. But none of this means that Microsoft is browser incompetent.

MacOS’s media framework uses sandboxes so even if media gets exploited it wouldn’t be able to write to disk or launch processes like in this example.

There’s really no excuses in this case for WebAudio, of all things, to be able to write to disk. And it’s dubious that Chrome should be able to launch any processes outside of the few specific child jobs it needs for process isolation.

We need something like `pledge` from BSD available across all platforms. Would mitigate quite a few of these exploits. Though, shipping good SELinux policy could solve the problem as well, maybe even better.

wasm is only a new phenomenon and those APIs were designed without wasm in mind. Note that wasm is also slower and thus more resource (battery) consuming than a native C++ implementation. Also, Chrome is already adding audioworklets to WebAudio so it will become customizeable. Last but not least, browsers are at least a central place that can be patched. Compare this to a possible future where vulnerable wasm libraries are being used in web apps, allowing third parties to run cross site wasm based exploits. Websites can't even switch off sms based 2fA, would you expect them to keep their wasm libraries up to date?

> Note that wasm is also slower and thus more resource (battery) consuming than a native C++ implementation.

My tests for codecs is now around 20% slower than native code, for the naive implementation. And SIMD.wasm helps a lot.

Long story short, WASM must be removed from browsers before it reaches wider adoption. And along with other completely unneeded APIs.

Parties opposing that must be expelled from standard bodies.

P.S. Just look at completely outrageous effort to push payment APIs into the browser and stuff they want to bundle along https://www.w3.org/2019/09/15-wpwg-minutes.html

Those are two genuinely useful things, without the hardware API issues of the others.

No.

I disagree. By having the browser implement these features we gain security. Chrome's sandbox is extremely powerful, and they can isolate and restrict all of those features you're describing very deliberately, in a way that a more generalized OS provided tool may not be able to.

> I disagree. By having the browser implement these features we gain security.

This is the opposite: this FFT and convolution code is in C++, and therefore OUTSIDE of the JS sandbox.

My point is that there should be a minimum in C++ and MORE inside the JS sandbox.

Browsers sandbox more than just the javascript VM/ renderer.

Obviously not the webaudio part, seeing this exploit.

There was likely a sandbox escape.

I completely disagree. I think we've already seen with the JS-framework-of-the-day culture, flash, java applets and whatnot what happens when a browser doesn't provide the right level of abstraction for the developers. The developer tools are still years behind what developers need and if the browser doesn't provide them, a million npm dependencies will.

Where did you see the reference to webaudio? Link to any other relevant details about the vulnerability, specifically?

If you follow the link, you'll see it is in the webaudio convolver.

The issue is that a lot of the use cases for the processes you mention have soft real time requirements where GC pauses are unacceptable, and the underlying OS's have differing world views when it comes to dealing with audio (even on the same OS, there may be different driver APIs with fundamentally different approaches to audio I/O!).

So having a simple audio API + ability to do pro-audio like things in JS is not really possible in a browser. They have to expose a complex framework with a nuanced API to the underlying engine to make some of this stuff even possible in a web browser.

> So having a simple audio API + ability to do pro-audio like things in JS is not really possible in a browser.

Absolutely not: wasm does not have GC pauses.

You'd be right about Firefox or IE, but that's not the case with Chrome, because Chromium OS is a thing. Google is building an OS, not just a browser.

You are completely missing the point: they should do less in C/C++ and more in JS/TS/Wasm.

I wholly agree with you. Somebody must push back on companies trying to push useless APIs