9 ms·

I know this is a bit a pet peeve of mine, (and not a very popular opinion) but I think the browsers are doing too much, and WebAudio is a very good example of t

by jbk 7y ago

I know this is a bit a pet peeve of mine, (and not a very popular opinion) but I think the browsers are doing too much, and WebAudio is a very good example of that. Instead of standardizing something low-level to input/output audio and query the hardware, like an OS; it standardizes soooo many things and filters, including downmixers, panners, quadfilters and Convolution (for reverbs); which is where the issue is in this exploit. The resulting complexity is huge, almost impossible to implement correctly in a cross-browser way, and a lot more code in C/C++ is written. I do advocate simpler APIs for audio, low-level, and let JS or Wasm do the filtering, using the JS sandboxing model. And, of course, this does not apply only to WebAudio, but I think WebAudio is a good symptom.

coleifer 7y ago
Where did you see the reference to webaudio? Link to any other relevant details about the vulnerability, specifically?
- jbk 7y ago
  If you follow the link, you'll see it is in the webaudio convolver.
dmos62 7y ago
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.
- csande17 7y ago
  The Web platform is now so gigantic and complex that even Microsoft has decided it's impossible to write a browser!
  - threatofrain 7y ago
    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.
CoolGuySteve 7y ago
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.
- Avamander 7y ago
  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.
baybal2 7y ago
I wholly agree with you. Somebody must push back on companies trying to push useless APIs
est31 7y ago
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?
- baybal2 7y ago
  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 https://www.w3.org/2019/09/15-wpwg-minutes.html
  - saagarjha 7y ago
    No.
  - pjc50 7y ago
    Those are two genuinely useful things, without the hardware API issues of the others.
- jbk 7y ago
  > 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.
tziki 7y ago
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.
unlinked_dll 7y ago
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.
- jbk 7y ago
  > 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.
staticassertion 7y ago
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.
- jbk 7y ago
  > 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.
  - staticassertion 7y ago
    Browsers sandbox more than just the javascript VM/ renderer.
    - jbk 7y ago
      Obviously not the webaudio part, seeing this exploit.
      - staticassertion 7y ago
        There was likely a sandbox escape.
bufferoverflow 7y ago
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.
- jbk 7y ago
  You are completely missing the point: they should do less in C/C++ and more in JS/TS/Wasm.

by jbk 7y ago

coleifer 7y ago

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

jbk 7y ago
If you follow the link, you'll see it is in the webaudio convolver.

dmos62 7y ago

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.

csande17 7y ago
The Web platform is now so gigantic and complex that even Microsoft has decided it's impossible to write a browser!
- threatofrain 7y ago
  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.

CoolGuySteve 7y ago

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.

Avamander 7y ago
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.

baybal2 7y ago

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

est31 7y ago

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?

baybal2 7y ago
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 https://www.w3.org/2019/09/15-wpwg-minutes.html
- saagarjha 7y ago
  No.
- pjc50 7y ago
  Those are two genuinely useful things, without the hardware API issues of the others.
jbk 7y ago
> 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.

tziki 7y ago

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.

unlinked_dll 7y ago

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.

jbk 7y ago
> 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.

staticassertion 7y ago

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.

jbk 7y ago
> 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.
- staticassertion 7y ago
  Browsers sandbox more than just the javascript VM/ renderer.
  - jbk 7y ago
    Obviously not the webaudio part, seeing this exploit.
    - staticassertion 7y ago
      There was likely a sandbox escape.

bufferoverflow 7y ago

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.

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