Normative: Allow CodeLike object evaluation

[lukewarlow]

This change introduces a new HostGetCodeForEval host hook, this is used to allow evaluating certain objects.

This change also provides the compilation type and the original arguments, to the host hook HostEnsureCanCompileStrings.

This PR upstreams a reduced version of the https://github.com/tc39/proposal-dynamic-code-brand-checks proposal

Closes #1498, #938

[caridy]

probably a little premature to do this at stage 1 :-)

@ljharb I think the reasoning behind this PR is that it doesn't really change any functionality, it is just layering. The original proposal from @mikesamuel was a lot bigger, this is just a small piece of that and we were hoping to just ask for consensus rather than pushing this thru the staging process. @cc @nicolo-ribaudo

[ljharb]

@caridy if it's normative, it's not just layering - but sure, if the goal is to try to turn it into a needs consensus PR, then this is fine, but my recollection is that that approach was rejected in favor of a proposal, I'm not sure how it'll turn out.

[lukewarlow]

@ljharb my understanding was that this would just be layering in the same way #3222 was.

[ljharb]

You might be right :-) would this PR obviate the entire linked proposal?

[lukewarlow]

Yeah with this PR the use case for that proposal, trusted types protection of eval and Function would be entirely addressed. That proposal would subsequently be withdrawn. The changes have been reduced over time and that linked PR addressed some of the required changes anyway.

[michaelficarra]

FYI @lukewarlow @nicolo-ribaudo this wouldn't be appropriate for stage 3 before testing and integration work has been completed. Maybe you should change the agenda item asking for stage 3 to stage 2.7?

[michaelficarra]

I don't really like the design here. Instead of adding a Boolean slot, could we add a String slot? The thing I don't like about having a Boolean slot and calling ToString on it is that there's no guarantee that it produces the same String each time. There's also no guarantee that ToString completes normally. If the String can't be precomputed and guaranteed constant, we could also use the slot to memoise it: ~not-computed~ or a String.

If it doesn't limit what you're trying to do with this proposal, I would much prefer a design like that.

[nicolo-ribaudo]

@michaelficarra This is currently tested in WPT. I asked to @ptomato how to test this in test262 but, given that the only observable change is that there might be objects that are not returned as-is by eval() but we don't actually say which objects they are (or we don't request that they exist), he suggested that this isn't really testable in test262 and that it's better to have it in WPT.

The test that shows that "there exist an object that is not returned as-is by eval" is at https://github.com/web-platform-tests/wpt/blob/23894a7e427bc088cfd4b3aa6ba8a8927b904713/trusted-types/eval-csp-no-tt.html#L13-L15. We could try somehow moving it to test262 if you prefer, maybe by requesting runners to provide an optional $262.getObjectForEval(toStringResult).

There is also a test about how it interacts with new Function (at https://github.com/web-platform-tests/wpt/blob/master/trusted-types/eval-function-constructor.html), but given that whether a call to new Function is allowed or not is entirely host-defined I don't think it can be moved to test262 in any way.

---

Regarding the host integration, it's specified at https://w3c.github.io/trusted-types/dist/spec/#host-ensure-can-compile-strings and https://w3c.github.io/trusted-types/dist/spec/#csp-eval.

[nicolo-ribaudo]

I don't really like the design here. Instead of adding a Boolean slot, could we add a String slot? The thing I don't like about having a Boolean slot and calling ToString on it is that there's no guarantee that it produces the same String each time. There's also no guarantee that ToString completes normally. If the String can't be precomputed and guaranteed constant, we could also use the slot to memoise it: ~not-computed~ or a String.

If it doesn't limit what you're trying to do with this proposal, I would much prefer a design like that.

I recommended using toString() to convert objects to string in eval() because new Function already uses toString() to convert objects to strings. When doing new Function(someObject) twice, there is already no guarantee that it will generate two functions with the same code.

When it comes to Trusted Types, the host is checking not only that the new Function/eval is being called with an object that has the capability of being converted into code, but also that the object gives the permission to convert the specific string obtained through ecma262 into code (step 2.4.1 of https://w3c.github.io/trusted-types/dist/spec/#csp-eval)

[nicolo-ribaudo]

@syg I was reading tc39/proposal-source-phase-imports#59 — should we replace the internal slot on the host-provided object with a HostEvalShouldStringifyObject hook for the same reason?

[nicolo-ribaudo]

@bakkot I was re-reading the new Function spec -- you mentioned that the sourceText created in CreateDynamicFunction is not exposed. However, my reading is that step 4 of OrdinaryFunctionCreate stores it in F.[[SourceText]], and then Function.prototype.toString will return it.

[bakkot]

I don't remember saying such a thing, but either way, yes, that's correct.

[michaelficarra]

@nicolo-ribaudo You may be referring to what I said, and I think I may have confused dynamic functions with built-in functions. While the exact whitespace/comments/etc in the String returned by Function.prototype.toString for built-ins is intentionally underspecified, the String returned for dynamic functions is indeed fully specified. If you want, it seems okay to pass that to the host AO. Sorry for the mistake.

[syg]

@syg I was reading tc39/proposal-source-phase-imports#59 — should we replace the internal slot on the host-provided object with a HostEvalShouldStringifyObject hook for the same reason?

Is this a comment referencing an earlier version of the PR? I don't see an internal slot currently.

[lukewarlow]

@syg yes there was previously a slot but we've changed it to a host hook (which itself may or may not check a slot)

[lukewarlow]

If you want, it seems okay to pass that to the host AO. Sorry for the mistake.

@michaelficarra is that something we can do without needing to represent that change? Passing the built code string through would indeed be the best course from our side (CSP is in fact already specced that way).

[michaelficarra]

@lukewarlow Any normative change at stage 2.7 or later should be presented to the committee, but I don't think this one should require consensus. It can be just a quick update.

[nicolo-ribaudo]

Removing the [needs test262 tests] label per the April 2024 discussion (https://github.com/tc39/notes/blob/main/meetings/2024-04/april-10.md#evalnew-function-changes-for-trusted-types-as-normative-pr-or-stage-3) (the change is not easily testable in test262 since it's just about how much info is exposed to hosts, and it's covered by WPT)

---

Regarding the esmeta failure, it seems like it's checking updated call sites to HostEnsureCanCompileStrings using the old signature of the host hook, rather than the new one from this PR?

[nicolo-ribaudo]

This PR introduces _sourceStr_ and _codeString_ variables: we'll want to use wither String or Str consistently, but we need to wait for #3837 to decide which one.

--

For other reviewers:

• the implementation of HostEnsureCanCompileStrings is at https://w3c.github.io/webappsec-csp/#can-compile-strings
• the implementation of HostGetCodeForEval is at https://html.spec.whatwg.org/#hostgetcodeforeval(argument)

[nicolo-ribaudo]

Suggested change

	<dd>It allows host environments to return a String of code from _argument_ to be used by eval, rather than eval returning _argument_.</dd>
	<dd>It allows host environments to return a String representing _argument_ to be used as code by eval, rather than eval returning _argument_ as-is.</dd>

[nicolo-ribaudo]

I would remove this, it's repeating what the <dl> description says.

[nicolo-ribaudo]

This list is missing _compilationType_.

Also, it's has so many entries now that maybe it should be a <ol> list, even though that's slightly unusual. @tc39/ecma262-editors thoughts?

[nicolo-ribaudo]

@jhnaldo This PR will need a corresponding update in https://github.com/es-meta/esmeta/blob/main/src/main/resources/manuals/funcs/HostEnsureCanCompileStrings.ir.

Should we add this to esmeta-ignore.json for now, so that ESMeta can be updated after that this PR is merged, or is it possible somehow for ESMeta to typecheck both this PR and what's currently on main?