+++ This bug was initially created as a clone of Bug #1353468 +++ (Quote from Philipp Kewisch [:Fallen] from bug 1353468 comment 28) > Does the userScripts API also cover the case where the developer wants to > run code fetched from a background script, that is not specific to a web > page? If not, is this something we will be able to support? I've come across > this in the one or other add-on. (Quote from Luca Greco [:rpl] from bug 1353468 comment #29) > The userScripts API does not cover the use case of "running third party js > code in a sandboxed environment" from a background script (or any other > extension page), mostly because the userScripts API has been designed to > take into account the oop architecture (the userScript will be registered > from the extension process, but then it is going to run in the content > process) and the particular "life cycle" of a "content script"/"userScript" > (that is tied to the webpage that the userScript is hooked to). > > I would not exclude that covering the "running third party js code in a > sandboxed environment" use case may also be useful to some extension, we may > need to detail the use cases that it should cover in a bit more detail, so > that we can draft a "API design proposal" to discuss/evaluate. --- Some possible use cases: * An add-on that retrieves code from a remote third party host that generates a key of sorts, which it then can use in its own API requests. Given the code can change, the developer doesn't want to rely on updating the add-on every time, but would instead want to execute code in the sandbox, then retrieve the key result from that file. * An add-on that wants to provide a viewer for htz or maff files, which are web archives. These files include scripts that need to be executed including eval() and other unsafe things, and we should provide a possibility to do so in a safe way. Supposedly an iframe sandbox is not sufficient here and the add-on author requires allow-scripts and allow-same-origin, which will make it unsafe again. This may be covered with the user scripts api though, will have to double check. --- Possible things that speak against this would be that it would open a route to execute remote code. The remote code could just as well be a coin mining script, and while executed safely, it would still be against policy. As a reviewer, it would be impossible to catch this. I think this could be immensely useful to some developers, but it also has some risks. I'm filing this to discuss the merits and to reach a decision that works for everyone.

It would really be useful for one of my projects, if directly allowing unsafe evals in sandboxed iframes is a problem, firefox could try the same thing as chrome did, add a sandbox property in the manifest: https://developer.chrome.com/extensions/sandboxingEval

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958