1398662 - Sandbox support for web extensions

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, enhancement, P5)

Description

[apic.apps]

Attachment: eval blocked by firefox extension

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622

Steps to reproduce:

I have a extension (available in chrome - https://chrome.google.com/webstore/detail/apic-complete-api-solutio/ggnhohnkfcpcanfekomdkjffnfcjnjam) where I need to execute some user provided javascript code using eval. The best approach is to use a iframe in sandboxed mode. But firefox doesnt allow execution of eval without unsafe-eval CSP directive.


Actual results:

If I use unsafe-eval CSP directive the extension is not accepted by firefox and without unsafe-eval CSP directive the extension does not work


Expected results:

Chrome has the support of running something in a sandboxed mode. The files that will run in sandboxed mode can be defined in the manifest file. Here is the link to chrome docs for sandbox mode https://developer.chrome.com/apps/manifest/sandbox

Comment 2

[Rob Wu [:robwu]]

The linked bug 1353468 is primarily about running scripts in a sandbox with a shared DOM (content scripts).

The requested feature here is to allow pages in an extension to have a custom Content Security Policy that allows unsafe-eval (which is currently not allowed by add-on reviewers).

https://developer.chrome.com/extensions/manifest/sandbox

The main motivation for this bug is a way of safely executing arbitrary JS code in an extension.
The ability to create pages with the null principal already be of much help.

Yang, are you sure that this should be a duplicate of bug 1353468?

Comment 3

[apic.apps]

I completely second with Rob's question. The feature I am requesting with this ticket is to provide a means of executing some page in the extension by providing a custom CSP that will run in a sandboxed mode and can use unsafe-eval.

Comment 4

[Caitlin Neiman [:caitmuenster]]

Hi apic.apps, this has been added to the agenda for the WebExtensions APIs triage meeting on November 14. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/Add-ons/Contribute/Triage
* Meeting agenda: https://docs.google.com/document/d/1g3RMfKZ3671NcusMqkoOiKwfPekRe-VI7Rzqxo6F_Ao/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

We discussed about this request during the last WebExtensions APIs triage meeting, and we didn't reach an agreement about how much needed this feature would be (the "sandbox" manifest property doesn't seem to be very common even between the existent Chrome extensions), and so the design-decision-denied. 

(nevertheless, if at some point more detailed and compelling use cases are highlighted, I wouldn't totally exclude that this decision could be re-evaluated in the future).

Comment 6

[Kris Maglione [:kmag]]

Closing all open bugs with the [design-decision-denied] whiteboard flag.