Re: Re: Provide hooks for Content Security Policy (CSP)?

[Isiah Meadows]

Comments inline

On Fri, Mar 4, 2016 at 11:08 PM, Domenic Denicola  wrote:
> From: es-discuss [mailto:es-discuss-boun...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Isiah Meadows
m...@isiahmeadows.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Re: Provide hooks for Content Security Policy (CSP)?

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@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.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Provide hooks for Content Security Policy (CSP)?

[Ron Waldon]

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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Provide hooks for Content Security Policy (CSP)?

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-boun...@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][1] 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 https://github.com/tc39/ecma262/pull/451 for the exact spec impact.

[1]: https://w3c.github.io/webappsec-csp/#directive-script-src
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Provide hooks for Content Security Policy (CSP)?

[Andrea Giammarchi]

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:
https://github.com/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 Regards

On Thu, Mar 3, 2016 at 3:36 PM, Mark S. Miller  wrote:

> 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
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss