On 3/14/2014 11:26 PM, Boris Zbarsky wrote:

For non-core, if you control the Gecko you build against, then the answer is the same. If you have to work against a random Gecko, that's a problem we don't have a good solution for yet. Assuming you really need to expose the object to a web page. On the other hand, it's not clear to me that you want to be exposing objects to all web pages like that, in general.

Isn't this something which pagemod addons and greasemonkey already do? There's clearly lots of use-cases for polyfills or experiments provided by addons. Do we not have a safe way now to expose objects and functions to pages (all pages or some pages)?

I did discover recently that you can expose properties on the global of a Cu.Sandbox, but only the global, and you can't expose deep object hierarchies. There are also scary warnings about using return results from an .evalInSandbox on this doc page, which seem like footguns still: https://developer.mozilla.org/en-US/docs/Components.utils.evalInSandbox

For my case, I wasn't calling into the DOM, I was calling into a null-principal sandbox, but the sandbox was basically supposed to define a function:

// Filter for whether to run a telemetry experiment
function filter(context) {
if ("inspec...@mozilla.org" in context.healthReportPayload.data.last.org.mozilla.addons.addons) {
    return false;
  }
  return true;
}

And then I would call the Sandbox.filter function with a context object that has the FHR payload. But since you can't pass complex objects to a sandbox, I've had to serialize the structure using JSON and deserialize it in the sandbox. Maybe this means we should consider exposing some kind of structured-clone system for calling untrusted code, plus a safer way to call functions which may return arbitrary results?

--BDS

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to