When Adam Klein presented this proposal at the November 2017 TC39 meeting, one of the committee's questions was, how should this proposal interact with eval? In one possibility, literals encountered within an eval would be treated as verified literals. Note that eval is not the only way that new code is executed; e.g., in the Web Platform, you can insert a new <script> tag, and in Node.js, the vm interface provides other ways to execute code.
Whenever code can be executed from user strings, if it is validated as a literal, this feature is made ineffective. On the other hand, if those things are treated as "not a literal", this might interact poorly with various kinds of code loading systems, which may be trusted.
Potential solutions discussed in the committee:
Define this problem to be out of scope: The feature could be said to be intended to work in environments where new code cannot be introduced, such as where HostEnsureCanCompileStrings will throw an exception for the target programs (e.g., with the default CSP mode).
Define some sort of token that has to do with what various instances of code execution are. Then, when verifying that a string or template is "literal enough", its code execution token would be compared against the set of tokens that are deemed acceptable. (It's possible I misunderstood this idea; I don't understand how the details would work out here.)
When Adam Klein presented this proposal at the November 2017 TC39 meeting, one of the committee's questions was, how should this proposal interact with
eval
? In one possibility, literals encountered within aneval
would be treated as verified literals. Note thateval
is not the only way that new code is executed; e.g., in the Web Platform, you can insert a new<script>
tag, and in Node.js, the vm interface provides other ways to execute code.Whenever code can be executed from user strings, if it is validated as a literal, this feature is made ineffective. On the other hand, if those things are treated as "not a literal", this might interact poorly with various kinds of code loading systems, which may be trusted.
Potential solutions discussed in the committee: