1465555 - Allow background scripts to evaluate unsafe code in a sandbox

Status: NEW

(WebExtensions :: General, enhancement, P3)

Description

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

+++ 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.

Comment 1

[Banou26]

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

Comment 2

[Firefox Bug Husbandry Bot]

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