Why Aren't Safari or Firefox Able to Process Audio Data from Mediaelementsource

Why aren't Safari or Firefox able to process audio data from MediaElementSource?

This answer is quoted almost exactly from my answer to a related question: Firefox 25 and AudioContext createJavaScriptNote not a function

Firefox does support MediaElementSource if the media adheres to the Same-Origin Policy, however there is no error produced by Firefox when attempting to use media from a remote origin.

The specification is not really specific about it ^{(pun intended)}, but I've been told that this is an intended behavior, and the issue is actually with Chrome… It's the Blink implementations (Chrome, Opera) that need to be updated to require CORS.

MediaElementSource Node and Cross-Origin Media Resources:

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 23 Jul 2013 16:30:00 +1200
To: "public-audio@w3.org" <public-audio@w3.org>

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.

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.

If this proposal makes it into spec it will be nearly impossible for a developer to even realize why his MediaElementSource is not working. As it stands right now, calling createMediaElementSource() on an <audio> element in Firefox 26 actually stops the <audio> controls from working at all and throws no errors.

What dangerous things can you do with the audio/video data from a remote origin? The general idea is that without applying the Same-Origin Policy to a MediaElementSource node, some malicious javascript could access media that only the user should have access to (session, vpn, local server, network drives) and send its contents—or some representation of it—to an attacker.

The HTML5 media elements don't have these restrictions by default. You can include remote media across all browsers by using the <audio>, <img>, or <video> elements. It's only when you want to manipulate or extract the data from these remote resources that the Same-Origin Policy comes into play.

[It's] for the same reason that you cannot dump image data cross-origin via <canvas>: media may contain sensitive information and therefore allowing rogue sites to dump and re-route content is a security issue. - @nmaier

Web Audio API createMediaElementSource breaks the audio tag

You didn't say, but I suspect you're using Firefox or possibly Safari. It actually worked for me when I downloaded your page and loaded it locally in Chrome. But I think this is a bug in Chrome.

Unfortunately, local media files (i.e. file:// URLs) are always treated as being in a different domain from the web page that contains them, even if the web page is also a local file. And that means you run into this problem:

Why aren't Safari or Firefox able to process audio data from MediaElementSource?

It basically means you have to load the page from a web server, not from a file. You can set up a local web server on your own machine to serve local files.

Firefox 25 and AudioContext createJavaScriptNote not a function

You can try using createScriptProcessor instead. Firefox is still not getting correct values, but at least that error is no longer present.

Demo - http://jsbin.com/olugOri/4/edit

Edit: ^{(more visibility for the important discussion in the comments)}

---

Firefox does support MediaElementSource if the media adheres to the Same-Origin Policy, however there is no error produced by Firefox when attempting to use media from a remote origin.

The specification is not really specific about it ^{(pun intended)}, but I've been told that this is an intended behavior, and the issue is actually with Chrome… It's the Blink implementations (Chrome, Opera) that need to be updated to require CORS.

MediaElementSource Node and Cross-Origin Media Resources:

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 23 Jul 2013 16:30:00 +1200
To: "public-audio@w3.org" <public-audio@w3.org>

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.

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.

If this proposal makes it into spec it will be nearly impossible for a developer to even realize why his MediaElementSource is not working. As it stands right now, calling createMediaElementSource() on an <audio> element in Firefox 26 actually stops the <audio> controls from working at all and throws no errors.

What dangerous things can you do with the audio/video data from a remote origin? The general idea is that without applying the Same-Origin Policy to a MediaElementSource node, some malicious javascript could access media that only the user should have access to (session, vpn, local server, network drives) and send its contents—or some representation of it—to an attacker.

The HTML5 media elements don't have these restrictions by default. You can include remote media across all browsers by using the <audio>, <img>, or <video> elements. It's only when you want to manipulate or extract the data from these remote resources that the Same-Origin Policy comes into play.

[It's] for the same reason that you cannot dump image data cross-origin via <canvas>: media may contain sensitive information and therefore allowing rogue sites to dump and re-route content is a security issue. - @nmaier

Javascript Web Audio API AnalyserNode Not Working

You should setup an event listener for the audio's canplay event and only setup the MediaElementSource and connect it after that event fires.

It also won't work in Safari due to a bug in their implementation. AFAIK Chrome is the only browser that properly supports the Web Audio API.

Media Element Audio Source Node How to Play

Figured it out finally, but don't know exactly what the issue was...

rather then using

audio = new Audio();
audio.src = self.file;

and connecting this,
I instead used

audio = document.querySelector('audio');

to select an element I had previously put into the page. I am not sure if this works simply because it gave it more time to load, or if there is something intrinsic to the API

Web Audio API and audio tag

Chrome follows the Same Origin Policy too, unless you have CORS enabled on your server.

Soundcloud CORS

Unfortunately, at the moment, the CORS headers aren't enabled on the mp3 files that are delivered from the CDN (ec-media subdomain). You'd need to use a proxy if you need to request these files via XHR.

CORS headers are enabled on the JSON data returned from the API, but not the mp3s.

If you are trying to use Web Audio API you could use mediaElementSource and load the mp3 via setting src property of the audio to be used as “media source” as described here.

---

Related Topics