On Fri, May 24, 2013 at 11:49 AM, Cristiano Belloni < [email protected]> wrote:
> On Friday, May 24, 2013 5:11:25 PM UTC+1, Kevin Reid wrote: > >> Caja does not include a taming of the Web Audio API. >> >> There's no reason not to (except that we would have to give the host page >> a way to control audio input/output access), but it hasn't previously come >> up on our list of APIs people want. >> > > Where's that list? I would gladly add that request :) > https://code.google.com/p/google-caja/issues/list > (the final goal is to load throught Caja unsafe plugins in this project of > mine: http://kievii.net/k2h.html). I agree that the host page would have > a way to control audio source and audioDestination. > Sounds like a great application for Caja. In particular, since you're sandboxing an audio processing plugin, all you should need to do is *not* grant the .destination property of the audio context, and similarly not grant any way to get the microphone; since the Web Audio API is graph-based and doesn't have any operations like "get nodes connected to this node", that's sufficient to arrange for the needed security! You could try simply using the available taming membrane controls to allow >> a context to be passed into the guest — you would have to explicitly mark >> as safe every part of the API you use. I don't offhand see any reason why >> that wouldn't work. >> > > How would I do that in practice? Taming the Web Audio api functions inside > the context object? > Essentially, yes. I don't offhand know where to find good documentation of how to configure the taming membrane for this kind of use — Ihab? -- --- You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
