Support for eval() in Workers


I tried submitting this on githib/atom thinking it was an enhancement request, but was redirected here.

I’m attempting to port some code which works in browsers to create a package for Atom. When eval() is used inside Worker code, it generates the standard EvalError due to the Content Security Policy script-src: ‘self’, i.e., no ‘unsafe-eval’.

If the code was on the main thread, it could use the common ‘loophole’ based on the ‘vm’ module. But Node cannot be used inside Worker’s and this is unlikely to change due to thread safety issues (electron Issue #797).

Two possible ways around this problem:

  1. Provide a mechanism by which Workers can use the standard loophole, e.g., pre-install ‘vm’ or equivalent into WorkerGlobalSpace.

  2. Provide a mechanism to redefine the security policy within a package.

But I’m open to other suggestions, including use of some Atom feature that I haven’t found yet. I’m not looking for an alternative to Workers; I’d like to reuse the code that already works in browsers.


Does this help at all?


Unfortunately, this doesn’t help because require isn’t supported inside a Worker, so ‘loophole’ can’t be loaded. This workaround is only available code running on the main thread.


Since there has been little discussion on this topic, let me take it a step further.

With respect to eval(), the current Atom content security policy is over-restrictive. Javascript code which is downloaded over the internet and works in pretty much any browser, does not work in a user installed package in the Atom text editor. This is compounded by the fact that the content security policy is hard coded in the Atom application (static.html) and requires a re-build to change it; it cannot be easily changed by the user or overridden by a package.

Without getting into the ‘eval is evil’ debate, Atom/Node has accepted that there is value in eval() in providing an alternative when running on the main thread, namely the ‘vm’ or ‘loophole’ module. Arguably, using eval() on a Worker thread is even more secure given the limited access to the global environment, e.g., no DOM access. Using a worker has even been the basis for more than one sandbox proposal (JavaScript sandbox… and Building Widget Sandboxes…).

So I would propose that the Atom content security policy be relaxed for ‘script-src’ to allow ‘unsafe-eval’. The current policy offers minimal security benefits and best case forces developers to use a non-standard, platform dependent workaround. Worst case (Worker threads), it just breaks working code.


Holy, I am suffering this problem for two days. I may need to break one more CSP in Worker, that is importScripts(url).
"Runtime.js:139 Refused to load the script ‘http://xxx/x/xxx.js’ because it violates the following Content Security Policy directive: “script-src ‘self’”.
I can use XMLHttpRequest to load resource myself. But I really need to eval the string to make the project work. I have tried to use ‘vm’ but failed. My heart is even more tired to see your conclusion… Yeah, the CSP is over-restrictive !!
Does someone can propose a workable solution? I really appreciate it !