content_security_policy and manifest version 2

284 views
Skip to first unread message

Japhy Bartlett

unread,
Aug 2, 2012, 6:25:25 PM8/2/12
to Chromium Apps
Our extension relies pretty heavily on eval()..  the extension that gets installed is basically just a bit of chrome-specific glue that downloads/stores a blob of javascript from S3, and runs eval() on it.

This is incredibly convenient because we publish a toolbar for all the major browsers (chrome/safari/ie/firefox);  ie, we have four minimal extensions that download and eval() a blob of cross-browser compatible javascript on pageloads.  We can push updates that are themed to holidays, independent of all the browser-specific updating frameworks, we don't need to wait for a user to click "update", our designers can work with a single repository, etc.


It's great, it's awesome, it makes everyone's life easier, and of course it's now completely broken with manifest version 2 :(


is there any hope of making this architecture work now?  I have been tinkering with something like:

"content_security_policy": "script-src 'self' https://toolbar.ourdomain.com.s3.amazonaws.com; object-src 'self'"

Without any luck.  Will this work if I somehow refactor the eval() to be a <script> tag with a src pointing to the whitelisted s3 bucket?  Or does anyone see another way to preserve this architecture?


Thanks for any advice.

- Japhy

Michael Hart / Awesome New Tab Page

unread,
Aug 2, 2012, 6:51:02 PM8/2/12
to chromi...@chromium.org
If you include it as an external script, it should work. You simply can't use eval outside of the sandbox. You can still run javascript from other websites (like Google+/Twitter/FB buttons, Google Analytics, etc.).

However, you might consider using CSS for theme purposes as it'd likely be far more efficient and a lot easier to maintain.

Suraj

unread,
Aug 7, 2012, 12:28:08 AM8/7/12
to chromi...@chromium.org

Dont use inline scripts and inline events like onclick etc.. 

Nate Thelen

unread,
Aug 13, 2012, 3:19:25 PM8/13/12
to chromi...@chromium.org
We do this too for exactly the same reason.  Hopefully we can figure out a way around it.  Have you had any luck?

Joshua Woodward

unread,
Aug 13, 2012, 3:29:15 PM8/13/12
to Nate Thelen, chromi...@chromium.org
var s=document.createElement('script');

document.getElementsByTagName('head')[0].appendChild(s);

this doesn't work?


--
You received this message because you are subscribed to the Google Groups "Chromium Apps" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msg/chromium-apps/-/DvJUJQhvlxMJ.
To post to this group, send email to chromi...@chromium.org.
To unsubscribe from this group, send email to chromium-app...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-apps/?hl=en.



--



Twitter - @howtohtml5

Japhy Bartlett

unread,
Aug 13, 2012, 3:50:45 PM8/13/12
to Chromium Apps, Nate Thelen
I quickly tried a port that used a <script> tag, but I ran into something else that I didn't see a solution to.  Sadly, our extension is a pretty low priority at our company (it's more of an extension of our website than a full-fledged product) and it was faster to build a crippled version for google that used their update infrastructure.  

We did pretty much the same thing to get past the Mozilla code reviews because they had no mercy for any line of cross-browser code.

So now that chrome extensions can't be hosted on our own servers, it would seem "easiest" to host everything through their respective app markets.  Except, the IE and Safari markets seem to be total black holes that we can't get into.  So it's just a mess all around.

- Japhy
Reply all
Reply to author
Forward
0 new messages