On Fri, Jul 26, 2013 at 12:28 PM, Chris Wilson <cwilso@google.com> wrote: > On Thu, Jul 25, 2013 at 5:23 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > >> On Fri, Jul 26, 2013 at 6:29 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote: >> >>> The severity issue here I think is rather clear and non-controversial. >>> For content which is affected by this, you'll get corrupted audio playback >>> in case the AudioBuffer is modified on the main thread, or you'll get >>> corrupted audio playback and probably the ability to read memory content >>> that does not belong to you in the case where the ArrayBuffers are neutered >>> by content. Robert already wrote a very simple test case to demonstrate >>> the first issue. It would be very interesting to see how easily one could >>> write a test case for the second issue, but I think it will work by >>> basically allocating a large AudioBuffer, neuter the ArrayBuffers by >>> sending them to a worker, connect the AudioBufferSourceNode to a >>> ScriptProcessorNode and examine the contents of inputBuffer. >>> >> >> I already posted a testcase for the second issue. Chris has informally >> proposed to fix it by introducing the concept of "non-neuterable >> ArrayBuffers". I don't think that solution will get past the editors of the >> Typed Array spec (or the TAG, it looks like), but at least we agree the >> issue must be fixed one way or another. >> > > Can you point me toward that? Sorry, this thread has grown beyond > manageability (and yes, I've contributed to that) - but this is a critical > point. > http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0663.html -- Ehsan <http://ehsanakhgari.org/>
Received on Friday, 26 July 2013 19:06:53 UTC