Host callout should provide enough information to determine flavour.

[mikesamuel]

@erights

Sole blocker for stage 2 is that HostBeforeCompile does not have enough information to distinguish

• indirect eval from direct eval
• direct eval in strict mode from direct eval in sloppy mode

It currrently has enough info to distinguish

• eval from *Function invocation
• different *Function constructors from one another

That should remain true.

[koto]

@erights Please see the updated text, where I've changed the host callout. I would like to understand more why the host callout needs to distinguish new Function from direct eval from indirect eval. The current hooks don't have that support - why should the host hooks have it now? The web platform APIs don't have any plans to be using that information, so it's not clear to me what advantage does it bring.

[ljharb]

It would be nice if CSP could differentiate; Function is safe in a way eval is not.

[koto]

I agree there are differences between those two, but the the CSP guards are set up on compilation, not evaluation and there are no plans to change that in the web platform.

We might actually make use of a distinguisher between new Function and eval in Trusted Types, but @erights request is about adding more data to the callout (direct vs indirect eval, strict vs sloppy). Adding those is relatively easy, but I would like to understand how and if these would be used. Web platform doesn't plan to use these additional distinguishers, which hosts are and how?

[erights]

Hi @koto sorry for the delayed responses. I have in mind non-browser hosts with no interest in CSP. These different cases are in fact semantically very different and have different safety properties.

The EcmaScript spec makes a horrible error in how it folds together direct and indirect eval into the internal performEval function. Direct eval is a special form in the code containing the direct eval expression. Aside from the test to determine if this is evaluation is a direct-eval evaluation, the only relevant realm is the realm containing the direct eval expression code. An indirect eval by contrast is just a function call in which only the realm of the called function is relevant. The realm of the caller should have no more influence than on any other function call. I understand that browsers and CSP have legacy constraints. They must do what they've always done no matter how nonsensical. However, on other hosts not trying for browser or CSP compat, any realm-based censorship decisions should align only with the relevant realm as explained above.

Likewise, strict vs sloppy are very different. And Function vs eval are very different, as @ljharb states.

[koto]

Thanks for the explanation. Which non-web hosts are planning to use this new distinction and how can we make sure that this distinction is both required and sufficient? Dynamic code guards (instead of outright banning like before) can be done in many ways, so understanding what is sufficient is also important.

It's a trivial change and I understand and agree that it might be useful, but I'm not yet convinced that it would be used, hence my reservation. After all, the old callout was there for years unchanged, presumably "good enough" for the hosts.

Knowing concrete hosts use cases helps. For example, should we distinguish different flavours of *Function? Before rewrite we did that, now I pass the assembled function body to the host, but all of them come annotated as "Function". That's sufficient for web, but I'm clueless whether other hosts would make use of this.

[koto]

Closing this, since no use case has been provided. I understand that in general the mechanics of eval might be improved in many ways, and some of the Realm work is more challenging because of that. Future use cases, as they get a more concrete shape, could certainly be championed as separate proposals, but don't I see enough advantage or overlap of bundling it with this one.