Provide hooks for Content Security Policy (CSP)

[Ms2ger]

In particular, CSP wants to do something to eval() and new Function().

http://w3c.github.io/webappsec-csp/ is a specification implemented in web browsers that provides a feature that makes eval() and new Function() no-ops. Currently it uses very hand-wavy prose for that. I believe it is better for the definition of those features to acknowledge that feature, to ensure that the expected result is well-defined.

[michaelficarra]

@Ms2ger This is not the place for these discussions. Please email es-discuss.

[domenic]

This is 100% the place for this "discussion".

[domenic]

I will work on a pull request for this today.

[annevk]

Some historical context: https://bugs.ecmascript.org/show_bug.cgi?id=2494.

[michaelficarra]

@domenic As I understand it, this repo is for concrete proposals and bug fixes. Not an open-ended discussion.

[domenic]

Yes, this is a concrete bugfix to match implementations. No discussion is needed.

[erights]

Yes, this is a concrete bugfix to match implementations. No discussion is needed.

WHAT? Such notions have not previously been part of EcmaScript. I understand why they probably should be, but this is absolutely a substantive discussion, not a bug fix.

[domenic]

This is like the other host hooks. It's already implemented everywhere, too. It has no normative consequences, only layering ones. There's no need for discussion; the proper place for discussion if you wanted to change the behavior was in the webappsec working group.

[domenic]

This was also resolved to be a trivial change in https://bugs.ecmascript.org/show_bug.cgi?id=2494 and desired for inclusion in the spec. Allen says there are enough hooks already but they aren't very explicit, if they exist. (I guess he is referring to hooking into the creation of new execution contexts.)

[erights]

https://mail.mozilla.org/pipermail/es-discuss/2016-March/045595.html
https://esdiscuss.org/topic/provide-hooks-for-content-security-policy-csp

[zenparsing]

@Ms2ger Out of respect to those readers (like me) who don't have the necessary context, please take the time to write a full description with appropriate links when creating an issue like this.

[Ms2ger]

Added some more background to the summary. I may have mistakenly assumed that a search engine of your choice would have been able to find sufficient context.

[zenparsing]

@Ms2ger Awesome, but I'm curious what's with all the terseness and snark?

[domenic]

It probably has something to do with this contributor's first welcome to the tc39 github repo being told to go away in a terse and snarky way.

[zenparsing]

Ah, that would do it. Well, chalk it up to a misunderstanding, and good to have you here, @Ms2ger !

[erights]

Yes @Ms2ger , welcome!

[allenwb]

@domenic

This was also resolved to be a trivial change in (https://bugs.ecmascript.org/show_bug.cgi?id=2494) and desired for inclusion in the spec. Allen says there are enough hooks already but they aren't very explicit, if they exist. (I guess he is referring to hooking into the creation of new execution contexts.)

The hook is step 11 of [InitializeHostDefineRealm()]](http://tc39.github.io/ecma262/#sec-initializehostdefinedrealm)

11. Create any implementation defined global object properties on globalObj.

Arguably this might be better worded as:

11. Define any implementation defined global object properties on globalObj.

to cover the cases of eval and function which have already been created prior to step 11.

In addition, the following paragraph should be added to Clause 16

An implementation may extend the behaviour of eval, the Function constructor, and %GeneratorFunction% that restricts where they may be used or the ECMAScript source code that they will accept.

All the other details should be left to the CSPspec.

[domenic]

Thanks Allen. I'd rather add specific restricted and explicit hooks as in #451 (which e.g. clarifies which steps in which algorithms, including direct eval, are affected) rather than use those kind of blanket permissions.

[allenwb]

I agree that a hook for direct eval is needed. I think the right place to put it is in PerformEval rather than at the call sites to PerformEval.

I don't think need a "hook" operation like HostEnsureCompileStrings is need. A prose line in PerformEval is more readable and can be as specific as you want to make it.

[domenic]

I think a hook operation is more precise and clearer for host environments (both implementations and specs). It certainly maps better to the existing open source engines. We can let the editor decide.

PerformEval is not sufficient since we need both the calleeRealm and the callerRealm to match web reality.