Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 107538 extensions doen't load for some valid CSP schemes.
Starred by 42 users Reported by themal...@gmail.com, Dec 14 2011 Back to list
Status: Duplicate
Merged: issue 146487
Owner:
User never visited
Closed: Feb 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
Chrome Version       : 18.0.970.1
OS Version: Win7

What steps will reproduce the problem?
1. Load an unpacked extension with CSP set to
"default-src 'self' https://ssl.google-analytics.com"
2. Load an unpacked extension with CSP set to
"default-src 'self' http://ssl.google-analytics.com"

What is the expected result?

Both extensions should be loaded into Chrome.

What happens instead?

While the first one loads,
the second extension doesn't:
Invalid value for "content_security_policy"
 
Comment 1 by smus@chromium.org, Dec 14 2011
Cc: abarth@chromium.org
Comment 2 by abarth@chromium.org, Dec 14 2011
Yeah, we're no longer allowing insecure scripts in extensions.  If you load a script over HTTP, an active network attacker can inject script into your extension, which is a security vulnerability.
Comment 3 by abarth@chromium.org, Dec 14 2011
Labels: -Area-Undefined -OS-Windows Area-Internals OS-All Feature-Extensions
Owner: abarth@chromium.org
Comment 4 by abarth@chromium.org, Dec 14 2011
There's a blog post in the pipeline that explains these changes.  The blog is somewhat backed up right now because of the release announcement posts.

(Thanks for reporting this issue.)
"default-src 'unsafe-inline'" throws this error as well.

Working as intended then, re: comment #2?
Comment 6 by abarth@chromium.org, Dec 14 2011
Yes.  'unsafe-inline' and 'unsafe-eval' are blocked for script-src and object-src, as are insecure schemes like HTTP.  You can use these sources for other directives.  For example, you can include insecure images using

img-src http://example.com

Also, you can use 'unsafe-inline' for style-src.

The idea behind these restrictions is that they prevent you from opening up your extension to certain XSS attacks.
Comment 7 by themal...@gmail.com, Dec 15 2011
If I understand you correctly, a background page manifest_version>=2 must not include inline script tags? If this behaviour is intended, the example extensions should be updated.
Comment 8 by abarth@chromium.org, Dec 15 2011
Cc: -abarth@chromium.org mkwst@chromium.org
Definitely.  We're in the process of updating the examples.

By the way, we've realized (thanks in part to this thread) that forcing folks to update to manifest_version 2 before our documentation is in place is a bad idea.  I just landed a change that removes the blocking error when you try to load an older extension manifest.  Assuming you're using Canary, you should get that change pretty soon.

Thanks for reporting this bug.  It's very helpful to get constructive feedback.
Comment 9 by abarth@chromium.org, Dec 15 2011
Cc: abarth@chromium.org
Comment 10 by mkwst@chromium.org, Dec 15 2011
We're working through the samples in a separate bug:  http://crbug.com/92644   ~30 or so have been updated to use CSP, which includes moving inline script out into separate files, but we still have ~45 to go. We haven't added manifest_version to any samples yet, but we're working on it. Apologies for the confusion. :/
Are unsafe iframes blocked as well? frame-src doesn't seem to be letting me through.
Docs are up, but only on trunk:
http://code.google.com/chrome/extensions/trunk/manifest.html
unsafe iframe is working, my bad.  img-src *; frame-src *;
Comment 14 by dmtab...@gmail.com, Dec 16 2011
I just wonder whether it means all callbacks must not be inline any more.
eg. chrome.tabs.create({...}, function(tab){...});
If the callback is inline, then under the new CSP it is not allowed.
Comment 15 by mkwst@chromium.org, Dec 16 2011
Our implementation of CSP for extensions simply prevents JavaScript in general from being included inline in an HTML document. It doesn't change the general behavior of JavaScript. Callbacks can certainly be inline in the sense of being contained within the method call. 

In short, `chrome.tabs.create( ..., function (tab) { ... });` will work just fine, so long as it's included in an external JavaScript file.
This seems like an area where the manifest_version: 2 is a good upgrade path: an application that doesn't have manifest_version: 2 would not have CSP restrictions. It's a very good feature, but I worry that turning it into a requirement in M18 will make things difficult on existing extensions and authors.
Would be nice if the 'Invalid value for "content_security_policy"' error message had some hints as to what makes it invalid. But once more documentation is in place, should be fine. It's not difficult once you know what to do ;)

I had _heaps_ of inline scripts in my extension, and I didn't know anything about CSP prior to this error, but after a lot of trial-and-error (comment #6 was very helpful!) and looking at the W3 specs, my final CSP looks like this:

"content_security_policy": "default-src 'self';   script-src 'self' https://platform.twitter.com;   style-src 'self' 'unsafe-inline';   img-src 'self' data: chrome: filesystem:;   connect-src 'self' http: https: chrome-extension:;   frame-src http: https:"

and managed to move all my inline scripts into files. (hopefully my CSP can act as an example for other extension developers in the meantime)

> I worry that turning it into a requirement in M18 will make things difficult on existing extensions and authors.

Yes.  We're going to hold off on making it a requirement until later.

> hopefully my CSP can act as an example for other extension developers in the meantime

If you find yourself whitelisting broad schemes like http and https, you might consider just using * instead.  Once you've whitelisted all of http, there isn't much to be gained by not whitelisting *.
Comment 19 by srous...@gmail.com, Dec 18 2011
> Yes.  'unsafe-inline' and 'unsafe-eval' are blocked for script-src

This sucks. Lots of JS libraries compile templates into JS functions using eval and "new Function" for speed. If you are going to block all these, then that blog post ought to point out all the JS libraries that will be blocked as a result. I have a largish extension using ExtJS for example, and the whole thing just crumbled.
Comment 20 by srous...@gmail.com, Dec 18 2011
Also, is the Content-Security-Policy getting applied correct to the devtools page of an extension? Doesn't look like it to me.
Hi sroussey,

Thanks for the feedback.  Is this the JS library you're using: http://www.sencha.com/products/extjs  ?  Would you be willing to share the id of your extension?

If a bunch of people run into this issue, we might be able to let extensions enabled 'unsafe-eval'.  I'd like to understand your situation better first though.

Thanks again.
> Also, is the Content-Security-Policy getting applied correct to the devtools page of an extension?

Good question.  I haven't tested that yet.
Comment 23 by dmtab...@gmail.com, Dec 19 2011
> Also, is the Content-Security-Policy getting applied correct to the devtools page of an extension?

JavaScript code can still be executed directly from the devtools page. However, eval is not allowed.
Comment 24 by srous...@gmail.com, Dec 19 2011
Yes, Sencha's ExtJS. It is not just the templating stuff, but data access too (though I think that could be refactored).

As for the devtools_page, which is where I am loading the JS files in question, I can't seem to turn on unsafe-eval.

Really, having CSP for content scripts, vs background scripts, vs devtools page, vs page action popup would be better than a one-size-fits-all that you have today.

My extension uses experimental apis so it is not available for download. It is a rewrite of Illuminations that will be available for Chrome (see http://www.illuminations-for-developers.com/about/ for info on the Firefox/Firebug version).
Blocking 'unsafe-eval' for script is a big disappoinment for me.

In my [work-in-progress] extension I'm using CoffeeScript compiler, which is allows to include scripts written in CoffeeScript, like this:

  <script src="/resources/javascript/coffee-script-compiler.min.js"></script>
  <script type="text/coffeescript">
    // Random CoffeeScript code.
    class App extends Batman.App
    App.run()
  </script>

And it doesn't works without "script-src 'unsafe-eval'".

(While precompiling to JavaScript is an obvious solution, it's simply so more distracting, that I'm voting for enabling 'unsafe-eval' for scripts.)
Status: Assigned
Comment 27 by srous...@gmail.com, Dec 29 2011
>> Also, is the Content-Security-Policy getting applied correctly to the devtools page of an extension?
>
>Good question.  I haven't tested that yet.

Should that be a separate bug report? 
> Should that be a separate bug report?

Yes, please.
Comment 29 by pa...@casaschi.net, Jan 11 2012
@6
are you definitely planning to forbid inline scripts from any HTML pages, even from the pages within the extension itself?
I have HTML pages as part of the extension that would require a MAJOR redesing if this is true, for example my options.html page where I use inline scripts to validate and apply values. Moving all the javascript code to separate js files is NOT obvious, especially if the <input type="button" onclick="do_something();"> statements are also forbidden.

Would it be possible to allow 'unsafe-inline' for chrome-extension://myOwnExtensionId/*.html pages?
The majority of the XSS bugs in extensions are in HTML pages of the sort you describe.  If you use 'unsafe-inline', then you open your extension up to XSS, which means an attacker can abuse all of your extensions privileges.

We're planning to make this change gradually so that you'll have a chance to update your extension on your own schedule.  There's a blog post in the works that explains more about what we're planning and why we think this change is important.

For the specific case you mentioned, the general approach is to give the button an ID:

<input type="button" id="somethingbutton">

and then use addEventListener in an external script:

document.getElementById("somethingbutton").addEventListener("click", function() { do_something(); }, false);

We understand that there's work involved in updating your extension to remove inline script, but we think the security benefits are worth the costs.  Here's a blog post some researchers at Berkeley wrote that explains the problem we're trying to address: <http://www.adrienneporterfelt.com/blog/?p=226>.
Status: WontFix
This behavior is working as intended.  In manifest_version 2, we're not allowing insecure (e.g., http) scripts to be loaded into extension.

The question of whether to allow unsafe-eval is a tougher call.  The general consensus seems to be that we should continue to block unsafe-eval because it's really easy to shoot yourself in the foot with eval.  We understand that this is going to cause problems for some developers who use libraries what use eval internally, but many popular libraries (e.g., jQuery) have removed their uses of eval internally for just this reason.

There is a workaround to gain access to eval, which is reasonably secure.  The workaround is to create a sandboxed iframe (using the HTML5 sandbox attribute on iframes) with a data URL:

<iframe sandbox="allow-scripts" src="data:text/html,<script>...</script>"></iframe>

You can then use postMessage to communicate with the frame and the frame can use eval.  The frame runs in a sandboxed, so an attacker who tries to corrupt your extension via eval will have difficulty escaping from the sandbox.

I'm sorry if this isn't the decision that you were hoping for, but I hope you understand that our goal here is to improve the security of the extension system.  I'm happy to discuss this topic further if you'd find that helpful.
I'd like an unsafe URL directive; "trampoline_url", which only has no more access than a content script.
Another idea; make <iframe sandbox> work nicely with chrome-extension uris. They ought have no more access to the extension than a content script would. And they're in their own DOM, so they are basically a content script. They carry their own CSP as inherited by the sandbox value.

The trampoline concept I've seen/used twice now. It's used sometimes as a target for OAuth2 redirects, and I've had to use it for content script to background page postMessage semantics. So that's why I proposed it, only because I've seen it a few times. It'd make a lot of sense to have <iframe sandbox> + trampoline, as an extra precaution in the manifest.
<iframe sandbox> should already work nicely with Chrome extensions.  Is there something you think it should do that it's not already doing?
> The question of whether to allow unsafe-eval is a tougher call. 
> The general consensus seems to be that we should continue to block 
> unsafe-eval because it's really easy to shoot yourself in the foot with eval.

I haven't seen many examples of this in practice, not to say it doesn't happen. Sadly, the CSP spec is kinda stupid in regards to this problem, as it equates "new Function" to scripts inserted via innerHTML.

> but many popular libraries (e.g., jQuery) have removed their uses of 
> eval internally for just this reason.

Um, jQuery doesn't do templating, so I wouldn't even expect it to have eval at all. I hope jQuery is not used as a proxy for all JS libs and frameworks.

In fact, I am hard pressed to find a JS framework or library that satisfies your requirements. I chose some random libs and all of them use eval and/or new Function, so you might as well black list these on your Chrome Extension page so developers know:

Sencha ExtJS
Dojo Toolkit
qooxdoo
SproutCore
mustache.js
jrender.js
ejs.js
haml.js
jade.js
jQuery Template
jquery-jtemplates.js
jquery.jqote2.js
jquery.views.js
baba.js
underscore.js
midori.js
processing.js
jsrender.js
...
..
.

> Sadly, the CSP spec is kinda stupid in regards to this problem, as it equates "new Function" to scripts inserted via innerHTML.

That's not accurate.  The former is controlled by 'unsafe-eval' and the latter is controlled by 'unsafe-inline'.
OK, then the spec is good. ;)

Still, I think the blacklist on the developer page for Chrome extensions is a good idea. Some of us are coding for months on stuff only to find out that the framework we based things on won't work someday.

Also: What is the answer for these type of scenarios? I worked on the js port of json-template, but I can tell you that interpreting code in JS is slower than compiling to JS and letting the browser run it, by 10-100x.
There's certainly a trade-off here, and we understand that there's a cost to making these changes.

Are you running to actual trouble or are you just worried that you'll run into trouble in the future?  I'm also curious if you've had trouble or success with the <iframe sandbox> workaround.

In Comment #21 I asked if you'd be willing to share the ID of your extension.  I'm happy to take a look at it and see how we can make it work with these new restrictions.
When I set the manifest_version = 2 my UI does not show. ExtJS uses eval/new Function in a few places: data retrieval for models (dumb idea, and easy to fix), and XTemplate which the entire UI lib is based on. 

If you look at the code for most of these template libs, you see that they put some template code together and then later call with a couple of objects that act scope/context. So postMessage isn't going to work, since the scope/context objects won't transfer correctly, and certainly wouldn't be fast. (Correct me if I'm wrong on that, but I assume they essentially go through a json encode/decode).

You won't find my extension anywhere since it is only on my machine, so having an ID won't help. I think it would be a glorious piece of technology to showcase at Google I/O this year though. ;)

However, if you want I can make a sample. It will be kinda dumb since normally you would not use such a big JS lib like ExtJS inside a Chrome extension to do a popup, for example. But I can make you one if you want.

As for what I'm doing: I'm adding iframes into the Web Inspector, with a complexity of a similar scale as WI itself. (Note that this is a real pain: my code has to shuttle data from the user JS content space to my extension content space to the extension background page to the devtools background page to the UI iframe.) If I could have different rules for my iframe inside the devtools, at least my issue would be solved. I tried proposing the idea to allow a different CSP for a different part of the extension, but that got shot down.

At the moment, I can just avoid using manifest_version = 2. It just may not last for long. 
Where do secure scripts fall in this? If our scripts are loaded via HTTPS, will they still be blocked?
> Where do secure scripts fall in this? If our scripts are loaded via HTTPS, will they still be blocked?

You can whitelist HTTPS sites.
Beg my pardon for my English.

New CSP will block lots of VERY popular libs and make them useless. Making templates quite hard to implement. Are you really ready to deal with this refusion?

I am developing extension using Ember.js (and it is using Handlebar.js) and I am pretty sad that my work will be deprecated in the near future.

And, what is also important, developing without these libs will increase developing period tangibly.

My last question:  are you all REALLY sure to make the CSP so strict?..
Comment 43 by Deleted ...@, May 5 2012
Google's very own "AngularJS" framework breaks because of this change.  Would love for them to talk internally and figure out a way to fix that.  Breaks with "Error: Code generation from strings disallowed for this context"
dotjosh, you might be interested in this blog post: https://mikewest.org/2012/05/content-security-policy-feature-detection
Comment 45 by pande...@gmail.com, May 14 2012
Isn't it a little severe to eliminate eval() entirely from developers' toolkits? I wanted to create a simple extension for testing out a compile-to-JavaScript language, so I am stuck either not using a manifest_version or implementing a solution with iframes that unnecessarily complects my otherwise simple application. I hope someone has the good sense to reconsider this "protect developers from themselves" attitude.
Well this is quite hampering, not to mention that its going to be excluding most of the available JS application frameworks.  I think it's really in everyone's best interest to bring back the relaxed policy.  Otherwise we're not left with really much to work with.

Help us out here. The platform is great and has promise, but not if I can't use the framework that I already know to build on it.  That's the whole point of the web.
Comment 47 by 4bra...@gmail.com, May 24 2012
For those of you looking for a JS templating library that doesn't use `new Function` Mustachejs at or before 0.4.2 works. https://github.com/janl/mustache.js/tree/0.4.2
Comment 48 by saroy...@gmail.com, May 27 2012
Hi Guys,
I really agree that the eval restriction is not a good idea, for example I've developed the extension that allows  people create automation and now I'm going to make update on it also for manifest version, in new updated version I want to allow users to inject scripts into the extensions background page and  just imagine how useful that extension could be without eval restriction, users could use chrome api for example to clean the cookies and I can allow them just call my function using eval and for my point of view it could became very powerful testing suit. Just to give users simple interface, ready functions and the extension can beat a lot of similar plugins in on other platforms.
Here is the link for not updated extension:
https://chrome.google.com/webstore/detail/jmbmjnojfkcohdpkpjmeeijckfbebbon?utm_source=chrome-ntp-icon

I will only ask google team just give as more freedom for developers as possible and in case of developers will not use CSP just write somewhere in web store that this extension don't use CSP.
Comment 49 by dmtab...@gmail.com, May 27 2012
#48 I agree with you. I also have an extension, which is merely used to test extension APIs. Without CSP, I was able to execute JavaScript from an extension page to test chrome.* APIs but now I have to open the developer tools and type code in the Console. In addition, sometimes even code typed in the Console is prohibited to execute, which complicates debugging. Anyway, code execution in the Console from the Developer Tools should always be allowed, I think.

Comment 50 by mka...@gmail.com, May 28 2012
> There is a workaround to gain access to eval, which is reasonably secure.  The workaround is to create a sandboxed iframe (using the HTML5 sandbox attribute on iframes) with a data URL:

That's not a workaround at all because you end up with eval being async.

The whole point of eval is that if give you sync evaluation of JavaScript.

So what I don't understand is, can you enable unsafe-eval? What's the syntax?

http://code.google.com/chrome/extensions/trunk/contentSecurityPolicy.html says:

"There is no mechanism for relaxing the restriction against executing inline JavaScript. In particular, setting a script policy that includes unsafe-inline will have no effect. This is intentional."

But there is not a single reference to unsafe-eval on this page.
Please, enable the use of eval and/or new Function. It's a very powerful tool when used wisely. Add a lot of warnings regarding use of eval if you want, but please let us use it. 

In the case of unsafe-inline there's an easy workaround, but what can we do about usafe-eval?

Please, please please keep the use of eval and/or new Function optional.  My extensions use ejs and mustache and I'd have to rewrite all of them just because of that limitation.

 
Other than the outdated version of Mustache.js, does anyone know of a up-to-date and maintained JS templating library I could use with my Chrome extension that plays well with the new CSP settings?
I have spent months building a large open source chrome extension that will now be depreciated by this change because it relies heavily on underscore.js templates... 
@matthewrobertson03:

One thing you might try is using the "sandbox" manifest attribute to sandbox the pages that use underscore.js:

http://code.google.com/chrome/extensions/trunk/manifest.html#sandbox

That will let them use eval but will prevent them from calling extension APIs directly.  Instead, they'll need to postMessage to your background page to call extension APIs.
Unability to use strings in timeouts and intervals is a real bugger.

In my extension I used it to evaluate my own code, so I am able to fire a function of a class I'm in, knowing it's intance's name. Now, I can't do that at all, because using strings is permitted and using window[this.name] will result in "window" being the object of a timeout/interval henceforth, not the object I'm in. And the only way to work around this is to create a handler inside a function (or globally, outside the object), which creates a pile of unneeded code.

That's not an issue in my particular case, because there's a single instance and I give it a name, so I can rely on it. But even so I was using it for convenience reason.
Comment 57 Deleted
Maybe we shouldn't allow any code at all, as it could possibly be used to exploit vulnerabilities. What a silly, counterproductive, frustrating change for extension developers!
Comment 59 by mock...@gmail.com, Jul 11 2012
For those of you looking for a JS templating library that doesn't use `new Function` there is Distal templates
Comment 60 by jan.g...@gmail.com, Jul 11 2012
Regarding mainfest v. 2 and CSP, what is the plan for GWT-based-extensions and when is the right time to try to run my GWT stuff at ver. 2? Last time, the best advice I got was: "for now switch to manifest ver. 1".
I would also like to request for enabling 'unsafe-eval'. I desperately need eval for complex mathematical expression evaluations, which nothing else seem to do efficiently. Without this, my extension will be dead.
@sks.ideas: Have you tried using a sandboxed iframe to evaluate the mathematical expressions?

http://developer.chrome.com/trunk/apps/app_external.html#sandboxing

Here's a sample app that shows the technique:

https://github.com/GoogleChrome/chrome-app-samples/tree/master/eval-in-iframe
I just spent a few weeks working on an extension rewrite using Handlebars templates, just loaded it up as an unpackaged extension, and ran into the same problem. Introducing a restriction that breaks all the most popular templating engines is a really bad idea, IMHO.
@wmbenedetto: This blog post seems to imply that Handlebars supports precompilation, which should make it work without eval:

http://matthewrobertson.org/blog/2012/07/10/javascript-templates-and-chromes-content-security-policy/
#62 @abarth: Didn't know that sandboxing was available for extensions. Will give it a try. Thank you!
We have a new doc (thanks mike!) about using templating libraries inside the extensions sandbox to use eval safely
http://code.google.com/chrome/extensions/trunk/sandboxingEval.html
Comment 67 by lag...@gmail.com, Aug 27 2012
The workaround page links to a bunch of 404 pages. 
Also by using this workaround for creating templates, which is my use case, will there be a perf hit?  
Comment 68 by lag...@gmail.com, Aug 27 2012
Also, i am not sure this workaround would work well on a case where a template is created on the fly. 
jsViews data linking seems to do that.
Comment 69 by mkwst@chromium.org, Sep 10 2012
Cc: aa@chromium.org
Labels: Mstone-23
Mergedinto: 146487
Status: Duplicate
Thanks for all the feedback. While we're still convinced that dropping `eval()` is the right thing to do long-term, it's causing causing more pain in the short term than we expected.  http://crbug.com/146487  has loosened the CSP requirements for extensions to allow you to whitelist 'unsafe-eval' if you need it. I'll mark this bug closed as a duplicate of that one.

A few things to note:

1. This change only effects extensions and legacy packaged apps. `eval()` is still blocked for the new-style Chrome applications demoed at I/O (details at http://developer.chrome.com/apps/app_csp.html)

2. `eval()` is blocked by default. You'll need to add a `content_security_policy` attribute to your manifest that whitelists `'unsafe-eval'` for `script-src`. That might look like: 

    {
        ...
        "content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'"
        ...
    }

3. This change is in Canary now, and is targeting Chrome 23 for stable release.

If you've got any questions at all, https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-extensions/Wyer5m3Y4tQ is the right thread for discussion.

Thanks!

-mike
I'm a researcher who has done a fair amount of work on security weaknesses of JavaScript.

I'd like to strongly encourage the Chrome developers to stand firm on the goal of blocking unrestricted 'eval' in extensions for the medium term. If the input to eval can be influenced in any way by an attacker, it is extremely difficult to do correct escaping that will eliminate all injection attacks. I would be astonished if all of the libraries mentioned were doing it right -- there *will* be exploitable security bugs in them. In web content, the damage from this is limited to XSS of the particular site using the library, but in an extension, it's can easily lead to a full compromise of the browser. (Extensions having excess authority is a problem in itself, as I'm sure you're aware, but one that is going to take longer to solve.)

There's significant overuse of eval in some of the popular libraries, and their developers should definitely be encouraged to strip that out. For the remaining legitimate uses, it would be possible to allow a more limited eval in an object-capability subset, as supported by Caja and Secure ECMAScript, or in an HTML5 sandbox as already mentioned (the former is preferable I think, and more expressive).
Comment 71 by Deleted ...@, Sep 25 2012
Basically our applications are not going to work, i am stuck here with a calculator app that will break if i dont find a fix for eval.
Mergedinto: 146487
@Aidan: Please see Comment #69.  You can now enable eval.
Hi,

we happily used eval() in a web worker created by our extension. Since Chrome 23, we get "Code generation from strings disallowed for this context".

Web worker is sandbox by its nature and we spent last two months rewriting our extension to use web worker as a sandbox. However, Chrome 23 started to ignore that.

Now we AFAIK can only:
  1) Rewrite the whole extension again to create sandboxed html page in manifest.
  2) Use MUCH WORSE 'unsafe-eval' for the whole extension.

Did I miss any option? Did you just forget that using eval() in web worker is safe? Or can I somehow specify that I really meant that web worker's javascript files to be sandboxed? It would be a pity to remove this sandboxing-attribute from web workers.

From everything I learned there, I wouldn't hesitate to call this a non-intentional bug. "eval() is not working in web workers."

Thanks a lot.

Mergedinto: 146487
> Web worker is sandbox by its nature

Web workers are not sandboxed.

> Rewrite the whole extension again to create sandboxed html page in manifest.

That's what the documentation recommends.
There are also situations where the eval problem is not something a library can control. 

PouchDB has to run MapReduce functions that come down from a CouchDB as a string. These strings are evaled into functions and then called. This is an open security hole... but the only way to query a local offline database if you follow the CouchDB way of doing things. Just thought I'd mention it here:
https://github.com/daleharvey/pouchdb/issues/96
 

We were currently looking to switch from Backbone to a new framework. Since our app has to run in a chrome extension I forked all the  popular frameworks in the ToDoMVC project (which provides sample apps in  each framework, using best practices for the framework) to test which frameworks play nicely with chrome extensions. This fork might be useful to others who are planning on using a framework in a chrome extension:
https://github.com/cesine/todomvc-for-chrome-extensions/issues/milestones?state=closed

3 Frameworks work out of the box
* Agility.js
* Vanilla JS example
* Batman.js

8 additional Frameworks work if you allow unsafe-eval 

4 Frameworks can get around unsafe-eval if you precompile your templates
* Backbone.js
* Ember.js
* Knockback.js
* Spine.js
* JQuery example

4 Frameworks seem to depend on eval
* Dojo - no plan to remove evals
* KnockoutJS (MVVM) - no plan to remove evals
* AngularJS - library uses eval
* Closure - example uses eval, but might not be necessary

1 Framework seems to depend on in-line scripts
* GWT - inline-script : example creates a script tag on the fly

1 Framework seems to depend on non https script-src
* YUI - huge library, most examples seem to download from an http server



If you include the new unsafe-eval in your Content Security Policy, 12 frameworks out of 14 work. 

Sample Content Security Policy in context:
{
  "name": "ToDoMVC - In Chrome Extensions",
  "version": "1.1",
  "description": "Helping you select an MV* framework for Chrome Extensions - Todo apps for Backbone.js, Ember.js, AngularJS, Spine and many more",

  "app": {
    "launch": {
      "local_path": "index.html"
    }
  },
  "offline_enabled": true,
  "permissions": [
    "unlimitedStorage"
  ],
   "icons": { 
  },
   "manifest_version" : 2,
  "content_security_policy" : "default-src 'self'; img-src 'self' http://gravatar.com; script-src 'unsafe-eval';  object-src 'unsafe-eval';"
}
@abarth, re #74: Sorry to bother again. As you (and documentation) suggested, we tried to rewrite our extension and use sandboxed page.

However, we found that in sandboxed page we cannot use web workers at all. Currently, as far as we discovered, Chromium is able to use web workers outside sandbox (created from both remote url and file packed with extension), but when used in sandboxed page, we get "SECURITY_ERR: DOM Exception 18" all the time. 

What we liked about web workers is their onerror callback as well as their terminate() method. Generally I see no reason why should be web workers in sandbox forbidden.

So what can we do?

Thanks in advance!

Comment 77 by Deleted ...@, Nov 5 2012
Hello,

I also receive "SECURITY_ERR: DOM Exception 18" error. Could you give us any information, how to deal with this problem?

Thank you
Mergedinto: 146487
Unfortunately, we do not currently support creating workers from sandboxed documents.
Project Member Comment 79 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Feature-Extensions -Mstone-23 Cr-Platform-Extensions Cr-Internals M-23
Comment 80 by Deleted ...@, Apr 12 2014
if your chrome does not show video iframe. Then there is two methods to solve this problem. These two methods are described in this post.
http://www.bestrightway.com/2014/04/chrome-iframe-not-displaying-problem.html

Sign in to add a comment