- From: Joseph Berkovitz <joe@noteflight.com>
- Date: Tue, 23 Jul 2013 16:09:22 -0400
- To: Ehsan Akhgari <ehsan.akhgari@gmail.com>
- Cc: "Robert O'Callahan" <robert@ocallahan.org>, "public-audio@w3.org" <public-audio@w3.org>
- Message-Id: <8FB7D5F5-5E5C-4114-8E35-F5CCBC2063EF@noteflight.com>
Not only should we subject this to CORS rules, I think we *must* subject it to CORS rules. Audio assets are commonly delivered from CDNs and these are typically located at an origin foreign to the containing page. I note that AudioBuffer.decodeAudioData obeys CORS as a fact on the ground in both the FF implementation and Webkit/Blink. . . . . . ...Joe Joe Berkovitz President Noteflight LLC Boston, Mass. phone: +1 978 314 6271 www.noteflight.com "Your music, everywhere" On Jul 23, 2013, at 10:52 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote: > On Tue, Jul 23, 2013 at 12:30 AM, Robert O'Callahan <robert@ocallahan.org> wrote: > HTML media elements can play media resources from any origin. When an element plays a media resource from an origin different from the page's origin, we must prevent page script from being able to read the contents of the media (e.g. extract video frames or audio samples). In particular we should prevent ScriptProcessorNodes from getting access to the media's audio samples. We should also information about samples leaking in other ways (e.g. timing channel attacks). Currently the Web Audio spec says nothing about this. > > Anyone know how Webkit/Blink solves this? > > I think we should solve this by preventing any non-same-origin data from entering Web Audio. That will minimize the attack surface and the impact on Web Audio. > > My proposal is to make MediaElementAudioSourceNode convert data coming from a non-same origin stream to silence. > > I like this idea. > > Should we also subject this to CORS rules to make it possible for Web Audio to access media elements coming from other origins? > > -- > Ehsan > <http://ehsanakhgari.org/> >
Received on Tuesday, 23 July 2013 20:09:38 UTC