Chrome 0-day exploit used in Operation WizardOpium

Post by jbk » Sun, Nov 03, 2019, 10:26 AM UTC

unlinked_dll wrote: post #129

jbk wrote: post #70

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…

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 re…

Post by jbk » Sun, Nov 03, 2019, 10:28 AM UTC

coleifer wrote: post #71

jbk wrote: post #70

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…

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

Post by jbk » Sun, Nov 03, 2019, 10:30 AM UTC

est31 wrote: post #98

jbk wrote: post #70

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…

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 librari…

Post by jbk » Sun, Nov 03, 2019, 11:02 PM UTC

staticassertion wrote: post #156

jbk wrote: post #154

Earlier quoted context omitted.

> 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.

Post by piiwebtech » Wed, Nov 13, 2019, 5:24 AM UTC