Provide hooks for Content Security Policy (CSP)?
I'm not sure it's easy to understand what is this about, but if I read eval and Function as no-op under CSP I imagine the joy of Angular framework users since both version 1 and version 2 have various bits based on evaluation ( example: angular/angular/blob/f60fa147679cacca3a786be9851cbff7827dcb4b/modules/angular2/src/facade/lang.ts#L462 )
Can anyone explain with few words what does this change actual mean for JS ?
Best
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Andrea Giammarchi
Can anyone explain with few words what does this change actual mean for JS ?
It means that JS will now specify how it has been implemented already in every browser, in a more rigorous way that allows the CSP spec to move away from its current very imprecise blockage to something more precise. The current imprecise blockage is implemented in various different ways in different browsers:
- Different errors are thrown (so far I have seen EvalError and TypeError)
- The realm used to determine blocking differs between caller and callee realms. That is, given a CSPed window with a non-CSPed iframe, otherWindow.eval("foo"), is sometimes blocked and sometimes not. This will allow us to specify that it is always blocked (by taking into account both the caller and callee realms).
See tc39/ecma262#451 for the exact spec impact.
Are there CSP benefits for other JavaScript environments (e.g. Node.js)?
Would there be benefits in applying CSP at the module level? e.g. module A has been vetted and can do these things, whilst module B is less trusted and has strict limitations
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Ron Waldon
Are there CSP benefits for other JavaScript environments (e.g. Node.js)?
Yes; it is something that could in theory be exposed through Node's vm module (i.e. Realm creation API), which would help certain sandboxing use cases people use that for.
Would there be benefits in applying CSP at the module level? e.g. module A has been vetted and can do these things, whilst module B is less trusted and has strict limitations
I think this is a different proposal than CSP, which operates on a Realm level.
Comments inline
On Fri, Mar 4, 2016 at 11:08 PM, Domenic Denicola <d at domenic.me> wrote:
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Ron Waldon
Are there CSP benefits for other JavaScript environments (e.g. Node.js)?
Yes; it is something that could in theory be exposed through Node's vm module (i.e. Realm creation API), which would help certain sandboxing use cases people use that for.
That seems like it would be very nice for jsdom as well. Testing that
something works with and without Function/etc. headlessly.
Would there be benefits in applying CSP at the module level? e.g. module A has been vetted and can do these things, whilst module B is less trusted and has strict limitations
I think this is a different proposal than CSP, which operates on a Realm level.
es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss
Isiah Meadows me at isiahmeadows.com
At tc39/ecma262#450 we have started discussing whether a discussion is warranted. Perhaps a discussion is not warranted, in which case a thread on es-discuss is not needed, as some claim. However, since we are now discussing this very question, the question of whether we should have a discussion is moot. We have already started the meta-discussion. Let's move it here to es-discuss where it belongs.
At https://github.com/tc39/ecma262/issues/450 we have started discussing whether a discussion is warranted. Perhaps a discussion is not warranted, in which case a thread on es-discuss is not needed, as some claim. However, since we are now discussing this very question, the question of whether we should have a discussion is moot. We have already started the meta-discussion. Let's move it here to es-discuss where it belongs. -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160303/5b2dccbb/attachment.html>