Firefox 25 says to bring Web Audio but an important functions seems to be missing - createJavaScriptNode.
I'm trying to build a analyser but I get the error in console that createJavaScriptNode is not a function.
Asked
Active
Viewed 2,341 times
1 Answers
9
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
-
2`createJavaScriptNode` is a deprecated method (replaced by `createScriptProcessor`), much in the same fashion of `noteOn` being replaced by `start`. The values produced by this should be the same as webkit implementations, if not, be sure to file a bug! – jsantell Oct 31 '13 at 21:16
-
@jsantell neither [Firefox 27 or Safari 7 are able to process audio data from `MediaElementSource`](http://stackoverflow.com/questions/13958158/why-arent-safari-or-firefox-able-to-process-audio-data-from-mediaelementsource). Chrome (Blink) is the only browser that fully supports the Web Audio API right now. – idbehold Oct 31 '13 at 21:50
-
ahhh, that was an issue over a year ago with Safari :[ https://github.com/jsantell/web-audio-api-bugs/tree/master/safari/MediaElement-to-JSNode I'll make the appropriate bug for Firefox -- thanks! – jsantell Oct 31 '13 at 22:53
-
actually, the above test case works for me in FF25 and FF28 (and replacing the deprecated APIs, webkit prefix, etc), looks like they uplifted the changes! – jsantell Oct 31 '13 at 23:02
-
3@jsantell Firefox does seem to support `MediaElementSource`, but only if the audio resource is from the same origin. It should also work if the server hosting the audio sets the correct CORS headers. I'm not sure I understand why they decided to do this. What dangerous things can you do with the audio data from a remote origin? And if that is per-spec, why does Chrome allow it? – idbehold Nov 01 '13 at 00:09
-
@idbehold I'd assume you have to obey same-origin/CORS for the same reason that you cannot dump image data cross-origin via ` – nmaier Nov 01 '13 at 13:16
-
@nmaier I'd really like to see a proof-of-concept as to how a remote `MediaElementSource` could be abused. And it should be easy to test since both Chrome and Opera currently allow it. – idbehold Nov 01 '13 at 15:21
-
@idbehold Breaking audio-captchas by abusing visitors computing power? Dumping data of private video conferencing recordings that the attacker has no access to, but the visitor does (has a session, vpn, whatever) – nmaier Nov 01 '13 at 15:22
-
@nmaier that's still all dependent on the ` – idbehold Nov 01 '13 at 15:29
-
According to the w3 list, Blink implementations need to update to require CORS: http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0219.html https://twitter.com/jsantell/status/396753990412562432 – jsantell Nov 02 '13 at 22:08
-
@jsantell Firefox doesn't throw any errors, and according to that w3 thread the proposal is to "convert data coming from a non-same origin stream to silence". That doesn't seem helpful to the developer. At the very least it should throw an error in the same way that an XHR to a remote origin throws an error in the console. – idbehold Nov 03 '13 at 17:07