2023-01-03
[00:05:22.0699] <nicolo-ribaudo>
I will unfortunately skip the call today, I'll be traveling at that time. See you in two weeks!

[00:54:12.0578] <Mathieu Hofman>
@annevk wrote in General:
> yulia | sick:  littledan:  I could make the Module Loading call tonight if that's helpful, please lmk
https://matrix.to/#/!wbACpffbfxANskIFZq:matrix.org/$oeD0yH7tagpCoRrR4gbgusb0fzM1ydOzWLIasu1T2ng?via=matrix.org&via=mozilla.org&via=igalia.com

[04:52:37.0102] <Luca Casonato>
> <@nicolo-ribaudo:matrix.org> I will unfortunately skip the call today, I'll be traveling at that time. See you in two weeks!

Me too!

[06:47:49.0288] <littledan>
Let's declare this time cancelled, if Yulia is also sick

[06:47:58.0400] <littledan>
also let's invite Anne tot his room

[08:19:27.0746] <Jack Works>
Do we have an agenda today 

[09:01:11.0009] <Kris Kowal>
We do not. I concur with the overall sentiment. We’ll convene in two weeks. I’ll invite Anne to this room.

[09:02:42.0966] <Jack Works>
Ok (btw I'm also on a sick holiday until Jan 16)

[09:03:03.0946] <Jack Works>
* Ok (btw I'm also on a sick leave until Jan 16)

[09:05:13.0895] <Kris Kowal>
For agenda building for N*2 weeks from now, I’d like for us to plan to meet with bakkot to improve our understanding of the feedback from the previous plenary. That may be an opportunity to prepare and dry-run a module harmony presentation-of-presentations.

[09:06:02.0440] <Kris Kowal>
I still am on the hook to refactor the compartments proposal into epic-module-harmony and proposal-module-constructor etc.

[09:19:23.0229] <Kris Kowal>
Until then, @bakkot, your feedback from plenary, if memory serves is, “no new path to eval”, and when we convene again, we are going to want to break that down and examine whether `import(new Module(new ModuleSource(text)))` qualifies as a new path to eval in the sense that you mean, and whether it’s fatal given the mitigations we have in mind. Not looking to dig in now, since we’ve got a lot of folks away, but I’d like to prime the pump for the next meeting (or a meeting thereafter).

[09:20:15.0414] <littledan>
I also nominate following up on the import assertions design discussion, as an agenda item next fortnight. And I nominate peetk and nicolo-ribaudo to lead that discussion :)

[09:20:23.0893] <Kris Kowal>
We also have a standing invitation to give @annevk the floor to discuss the next steps for import assertions.

[09:21:32.0044] <littledan>
> <@kriskowal:matrix.org> We also have a standing invitation to give @annevk the floor to discuss the next steps for import assertions.

I'd propose that we organize that like, annevk recaps his understanding of the problem we need to solve, then nicolo-ribaudo / peetk outline the possible solution we've been discussing, then annevk shares thoughts

[09:22:09.0440] <Kris Kowal>
@annevk are you available +1 fortnight?

[09:23:27.0076] <Kris Kowal>
Also, thank you littledan, I’m ecstatic to find company in which biweekly isn’t a word.

[10:26:30.0385] <bakkot>
> <@kriskowal:matrix.org> Until then, @bakkot, your feedback from plenary, if memory serves is, “no new path to eval”, and when we convene again, we are going to want to break that down and examine whether `import(new Module(new ModuleSource(text)))` qualifies as a new path to eval in the sense that you mean, and whether it’s fatal given the mitigations we have in mind. Not looking to dig in now, since we’ve got a lot of folks away, but I’d like to prime the pump for the next meeting (or a meeting thereafter).

To be precise, I'm not dead set against having a new path to `eval` - I would just want there to be a very strong reason for it, which I haven't heard yet.

[10:39:01.0634] <annevk>
Kris Kowal: yeah that should work

[10:39:33.0196] <littledan>
> <@bakkot:matrix.org> To be precise, I'm not dead set against having a new path to `eval` - I would just want there to be a very strong reason for it, which I haven't heard yet.

I think the decision about whether we expose a ModuleSource constructor which takes a string argument is extremely separable from everything else. We've heard bakkot say he doesn't want it, ljharb say he wants it, and others seem OK multiple ways. I don't think the decision here will affect any other part of the APIs we've been discussing, and I think we have a very clear shared understanding of what it would do if it does exist.

[10:42:35.0222] <littledan>
(so, I think it should be treated as a post-Stage 2, pre-Stage 3 decision, having been fully scoped out)

[10:44:41.0399] <littledan>
(still fine to hear out bakkot more, but I think he was plenty clear in plenary?)

[10:46:49.0036] <littledan>
(I think the answer to the question is: clearly yes)

[10:47:18.0543] <Kris Kowal>
> <@bakkot:matrix.org> To be precise, I'm not dead set against having a new path to `eval` - I would just want there to be a very strong reason for it, which I haven't heard yet.

Great, this is clear. We can focus on building 1. the strongest reason and 2. the work-arounds other proposals (specifically module binding static analysis) can be recovered in the absence of ModuleSource(text).

[10:50:15.0077] <Kris Kowal>
That is, being able to parse a string’s static imports and exports is currently subsumed by the ModuleSource(text) constructor but does not necessarily need to be on the path to importing the text. That can be recovered either by a parse bindings function sitting somewhere else, or by rendering module source instances constructed by ModuleSource(text) unusable (which is consistent with what a CSP would do anyway)

[10:50:46.0051] <Kris Kowal>
And the motivation for parsing bindings is bundle generation, in which case, a path to eval is not needed.

[10:51:17.0304] <Kris Kowal>
 * And the motivation for parsing bindings is bundle, web archive, or import map generation, in which case, a path to eval is not needed.

[10:53:57.0222] <Kris Kowal>
I suspect that the strongest case for a path-to-eval is a debugging environment, with hot module replacement occurring client-side, such that the runtime behavior more closely resembles a production environment than is possible to achieve with the current tooling ecosystem.

[11:02:31.0555] <bakkot>
> bundle, web archive, or import map generation

Those seem like somewhat niche use cases which would be adequately met by userland parsers, to me? Doesn't seem like support for those things would need to be built into the language.

[11:02:55.0951] <bakkot>
We already have pure-JS bundlers, after all.

[11:04:37.0477] <bakkot>
(I'm not saying they're niche things for developers to do, just that they're niche things to do _in code which is shipped to users_; when building something into the language the latter is more relevant.)

[11:05:19.0566] <Kris Kowal>
I agree that the value is bounded in this way.

[11:07:47.0218] <Kris Kowal>
And other motivating use cases I can expound upon do not involve web browsers, so I expect them to be less convincing.

[11:13:45.0698] <Kris Kowal>
For example, at Agoric, we would like to ship programs to workers as zip files containing the original sources. The workers would use the ModuleSource constructor to build out the module graph. We’re also avoiding source-to-source transforms so that audits are more transparent. The auditor can review the code and not worry about holes that would be opened by generated code. We’re currently unable to do this because our shim has to funnel module code through eval, so we necessarily have to do a module-to-program transform, and since that is prohibitively expensive, our zip files currently contain a JSON blob that contains the program and the bindings.

[11:15:02.0455] <Kris Kowal>
And notably, Agoric/Endo execution environments do not employ CSP but do harden the worker realm and confine guest programs, so the trade-offs are different. It would be fair to call our case niche, but not unimportant.

[11:15:35.0135] <Kris Kowal>
Rather, I’d call it nascent.

[11:17:53.0622] <Kris Kowal>
(For example, the very common babel facebook/regenerator runtime introduces thawn-objects in a way that would not be obvious to an auditor and would open a program to interference that would otherwise not be possible.)

[11:19:05.0665] <Kris Kowal>
A consequence of the current language limitations is that a debugger attached to a production heap snapshot can’t match stack traces with local code artifacts.

[11:34:24.0568] <bakkot>
If you could import a reified-but-not-evaluated `Module` and structuredClone it to a worker, would that eliminate your need for `eval` and therefore your need to bundle?

[11:35:04.0882] <bakkot>
(import or otherwise obtain in some manner other than constructing from a string, as would be provided some of these proposals IIUC)

[11:35:27.0449] <bakkot>
 * If you could import a reified-but-not-evaluated `Module` and `postMessag` it to a worker, would that eliminate your need for `eval` and therefore your need to bundle?

[11:35:31.0523] <bakkot>
 * If you could import a reified-but-not-evaluated `Module` and `postMessage` it to a worker, would that eliminate your need for `eval` and therefore your need to bundle?

[11:35:43.0882] <Kris Kowal>
postMessage is not available in the particular context.

[11:36:15.0530] <Kris Kowal>
Though a suitable postMessage could be implemented in terms of ModuleSource.

[11:36:48.0712] <bakkot>
Wait, so how are you getting stuff into a worker without postMessage?

[11:37:05.0909] <Kris Kowal>
I’m using the term Worker loosely. This is a Node.js or XS child process.

[11:37:32.0792] <bakkot>
Node has postMessage - though I guess not to actual child processes spawned with `exec` or whatever.

[11:38:42.0176] <Kris Kowal>
Aye, and process isolation is key. XS too. The application can resume from snapshot.

[11:43:01.0647] <bakkot>
Since you're targeting specific platforms, can you not hook into the runtime with native code and get at bindings that way? Or roll your own native `ModuleSource`-equivalent constructor, for that matter?

[11:43:33.0635] <bakkot>
I guess V8 might not expose the things you'd need, though that's in principle solvable.

[11:43:39.0069] <Kris Kowal>
XS implements ModuleSource effectively. We are working in that direction, yes.

[11:46:56.0754] <Kris Kowal>
There’s also a course to having these applications portable-to-web using XS on WASM. This is of course, not ideal, but certainly suitable for evidence of motivation :-P 

[11:55:42.0130] <Kris Kowal>
And also the course of using a Service Worker to pop the zip open. My feeling is that’s got its own trade-offs.

[11:57:43.0232] <Kris Kowal>
And of these options, having ModuleSource provided by the language is the most portable.

[11:58:20.0866] <Kris Kowal>
The alternatives require assumptions of a shared foundation that does not exist.

[13:57:01.0862] <bakkot>
Spawning a new process is fundamentally not portable to begin with, so I'm not sure why portability matters here

[14:11:53.0737] <Kris Kowal>
Spawning, the conceit that all content everything is a URL backed by an ambient fetch capability, and module loading can (and I reckoon should) be made orthogonal. The portion of the problem pertaining to spawning is expressible in a hook that differs by platform and, with `ModuleSource`, nothing else is different. Transporting module sources in an archive doesn’t require any I/O.

[14:12:07.0846] <Kris Kowal>
 * Spawning, the conceit that all content everything is a URL backed by an ambient fetch capability, and module loading can (and I reckoon should) be made orthogonal. The portion of the problem pertaining to spawning is expressible in a hook that differs by platform and, with `ModuleSource`, nothing else is different. Drawing module sources out of an archive doesn’t require any I/O.

[14:12:39.0625] <bakkot>
Well, neither does parsing the bindings out of a string, in principle

[14:12:57.0242] <Kris Kowal>
Not requiring I/O is a pretty big deal. Dynamic import currently creates an exfiltration channel.

[14:13:20.0379] <Kris Kowal>
> <@bakkot:matrix.org> Well, neither does parsing the bindings out of a string, in principle

And executing JavaScript, in principle!

[14:15:08.0868] <bakkot>
Well, right - evaluating JS is a weird and dangerous thing to do, so it's best not to expose a language-level capability for doing that, but specialist applications can (and do) do it in userland if they really need to. Seems like this use of `eval` is pretty analogous, to me.

[14:15:10.0547] <Kris Kowal>
So, one of the intertwingled concerns is that Agoric/Endo prevents that exfiltration channel. Currently, we do that by censoring the word `import`, which has a number of inconvenient false positives and artificially limits how much extant code can participate on the platform.

[14:15:40.0352] <Kris Kowal>
> <@bakkot:matrix.org> Well, right - evaluating JS is a weird and dangerous thing to do, so it's best not to expose a language-level capability for doing that, but specialist applications can (and do) do it in userland if they really need to. Seems like this use of `eval` is pretty analogous, to me.

Agreed.

[14:16:16.0616] <Kris Kowal>
And equally worthy of existence, in my opinion.

[14:17:10.0139] <bakkot>
... Which is to say, not, or do you have a different impression of the net benefit of `eval` than I do?

[14:17:11.0487] <Kris Kowal>
Except direct eval. That can die in a fire.

[14:18:10.0176] <Kris Kowal>
> <@bakkot:matrix.org> ... Which is to say, not, or do you have a different impression of the net benefit of `eval` than I do?

My impression is that we’d either be stuck with IE5 era JScript or gasp VBScript if eval hadn’t been part of the language.

[14:18:22.0773] <bakkot>
That... is not my impression.

[14:18:59.0888] <Kris Kowal>
CommonJS certainly would not have happened.

[14:19:22.0752] <Kris Kowal>
I know opinions vary on the point, but I have few regrets.

[14:21:05.0403] <Kris Kowal>
(ESM would not have happened if CJS hadn’t happened. TC39’s position in 2009 was to wait and see whether the ecosystem had an appetite for modules, which would not have been observable otherwise.)

[14:21:29.0789] <Kris Kowal>
Besides, the ecosystem didn’t really want it until they had it.

[14:22:48.0161] <bakkot>
I don't think it's really that plausible that we'd've never had a module system at all in the absence of `eval`, but in any case, we do now have such a system, so that can't be an argument for `eval` being something we would design into the language _now_.

[14:31:58.0147] <Kris Kowal>
How sympathetic are you to jsfiddle as a specialist application that would benefit from eval-but-modules?

[14:34:22.0898] <bakkot>
I don't think jsfiddle uses eval?

[14:34:27.0711] <bakkot>
So not particularly sympathetic.

[14:36:23.0867] <Kris Kowal>
At his point in the argument, would you say that the best way for Module constructor to Stage 2 would be to preserve the concept of a module source object (e.g., the source for a module block or a WebAssembly.Module) and omit the ModuleSource constructor?

[14:36:58.0727] <Kris Kowal>
I do not imagine finding better arguments for ModuleSource from text than the above.

[14:37:01.0980] <littledan>
bakkot: Do you consider this decision a Stage 2 blocker? IMO it seems OK to leave it an open question to resolve before Stage 3.

[14:37:21.0939] <littledan>
I think for Stage 2 we should sort of understand the decision space fairly well, and I think we do

[14:37:32.0169] <bakkot>
I think in general that for any proposal to advance all components of that proposal should be justified, and I am not yet convinced that the ModuleSource constructor is justified, so yes.

[14:38:12.0351] <bakkot>
As to whether it's at Stage 2 or Stage 3 concern, personally this decision feels like a fairly major one, so personally I would prefer it be made before Stage 2, but the distinction is pretty artificial given that no one is shipping before stage 3 anyway, so I don't feel strongly about that.

[14:38:22.0586] <bakkot>
 * As to whether it's a pre-Stage 2 or pre-Stage 3 concern, personally this decision feels like a fairly major one, so personally I would prefer it be made before Stage 2, but the distinction is pretty artificial given that no one is shipping before stage 3 anyway, so I don't feel strongly about that.

[14:38:51.0851] <Kris Kowal>
Do you also contend that surfacing the bindings parser is not sufficiently justified? (The performance hit for drawing in Babel into production is significant. I hope that justifies it.)

[14:39:06.0712] <bakkot>
Oh, you can do a _lot_ better than pulling Babel into production

[14:39:11.0634] <bakkot>
You don't need a full parser just to get the bindings out

[14:39:21.0800] <littledan>
Stage 2 implies all sorts of other important qualities, like "is the committee sort of committed to doing something here" and "do we have a concrete first draft"; it is really common to have disagreements about major semantic points when something goes to Stage 2

[14:39:59.0514] <bakkot>
If shipping a parser specialized to the problem of getting bindings is still not performant enough, then that's maybe something to talk about, though I'm not sure it would make sense as part of this proposal in the absence of a ModuleSource constructor

[14:40:10.0088] <Kris Kowal>
> <@bakkot:matrix.org> You don't need a full parser just to get the bindings out

I’m sure you need at least the lexer and a partial parser for sequences introduced by import and export.

[14:40:32.0227] <bakkot>
Yup, but those things are lot smaller and faster than babel's parser.

[14:40:45.0636] <bakkot>
In particular not having to construct trees saves a lot of time.

[14:41:05.0857] <Kris Kowal>
That’ll run you about 16kloc. We’ve got guybedford (Guy Bedford)’s for that.

[14:41:15.0774] <littledan>
https://github.com/guybedford/es-module-lexer

[14:41:44.0716] <littledan>
<1kloc

[14:42:47.0337] <bakkot>
> <@littledan:matrix.org> Stage 2 implies all sorts of other important qualities, like "is the committee sort of committed to doing something here" and "do we have a concrete first draft"; it is really common to have disagreements about major semantic points when something goes to Stage 2

Eh, well, depend on what you mean by "major semantic points". In theory stage 2 signifies "all _major_ semantics, syntax and API are covered", and "does this add a new eval" is IMO a major semantic point. But like I said I don't feel that strongly about this, as long as it's understood that agreeing to stage 2 doesn't signify consensus on this question either way.

[14:42:53.0798] <Kris Kowal>
That’s…much smaller than his other one. Surprising!

[14:43:36.0006] <bakkot>
our full JS parser isn't even 16k semantic LoC

[14:43:49.0027] <bakkot>
(it's like 3-5k I think)

[14:46:02.0786] <Kris Kowal>
Oh, pardon. I’m off by ten. I’m looking at Guy’s CJS lexer (which we use in prod at Agoric) and it’s 1.6K.

[14:48:01.0505] <Kris Kowal>
So, agreed, it’s consequently practical to statically analyze the bindings of a module in production without ModuleSource(text).bindings or a lower-powered Module.parse(text). So making a web page that generates bundles isn’t that much trouble.

[14:50:03.0348] <littledan>
> <@bakkot:matrix.org> Eh, well, depend on what you mean by "major semantic points". In theory stage 2 signifies "all _major_ semantics, syntax and API are covered", and "does this add a new eval" is IMO a major semantic point. But like I said I don't feel that strongly about this, as long as it's understood that agreeing to stage 2 doesn't signify consensus on this question either way.

Yeah, the draft definitely has to make a strong stab at all of those points, including this one. But committee members can still disagree with them (look at where R&T is).

[14:50:32.0690] <littledan>
anyway sorry lawyering here is beside the point

[14:51:19.0567] <littledan>
not trying to deny your right to block this proposal (which has another sort of existential question, about whether we want the importHook to be hookable at all)

[14:54:19.0506] <Kris Kowal>
There are a number of such questions. The folks at Moddable discovered that implementing Module and ModuleSource made it possible for their fuzzer to discover bugs in their module system that were previously too impractical to cover. They’ve fixed the bugs, but it highlights that it’s hard to get ESM right. There’s certainly some philosophical wiggle-room whether composing ESM with callbacks creates more bugs than it reveals.

[14:54:54.0911] <littledan>
I guess I felt like the ordering should be more like, we focus first on whether we want importHook to be a thing at all (as Shu raised), and then we'd resolve lower-order things like whether the ModuleSource constructor should exist

[14:55:40.0882] <Kris Kowal>
That is certainly the most efficient way to prune the tree.

[14:55:52.0817] <littledan>
> <@kriskowal:matrix.org> There are a number of such questions. The folks at Moddable discovered that implementing Module and ModuleSource made it possible for their fuzzer to discover bugs in their module system that were previously too impractical to cover. They’ve fixed the bugs, but it highlights that it’s hard to get ESM right. There’s certainly some philosophical wiggle-room whether composing ESM with callbacks creates more bugs than it reveals.

yes, the importHook certainly makes a bunch of things observable that previously weren't. Analogous to Proxy. Doesn't necessarily mean that the previous state was a bug.

[14:56:25.0363] <littledan>
> <@littledan:matrix.org> I guess I felt like the ordering should be more like, we focus first on whether we want importHook to be a thing at all (as Shu raised), and then we'd resolve lower-order things like whether the ModuleSource constructor should exist

so I was mapping these to Stage 2 and 3, but we could resolve them both before Stage 2 also

[15:11:51.0325] <Kris Kowal>
> <@littledan:matrix.org> https://github.com/guybedford/es-module-lexer

I assume this is sufficient to accept exactly and only grammatically valid sources. That requires block matching, but not AST generation. The other motivation for a full parse is that `eval('module {' + text + '}')` is an inevitable work-around for the lack of `ModuleSource`, which is much worse if text is not a valid source.

[15:12:22.0440] <Kris Kowal>
> <@littledan:matrix.org> https://github.com/guybedford/es-module-lexer

 * I assume this is sufficient to accept exactly and only grammatically valid sources. That requires block matching, but not AST generation. The other motivation for a full parse is that `eval('module {' + text + '}')` is an inevitable work-around for the lack of `ModuleSource`, which is much worse if text is not constrained to be a valid module source.


2023-01-09
[03:43:09.0072] <Luca Casonato>
My major open question in response to bakkot's points at plenary is how this qualifies as a new path to eval - we discussed this at the last loader meeting and came to the conclusion that a `ModuleSource` constructor was in fact **not** a new path to eval, because the "evalness" of the ModuleSource is done through dynamic import. The constructor itself **does not eval** - eval only happens at import - which is already possible.

[03:43:18.0511] <Luca Casonato>
 * My major open question in response to bakkot's points at plenary is how this qualifies as a new path to eval - we discussed this at the last loader meeting and came to the conclusion that a `ModuleSource` constructor was in fact **not** a new path to eval, because the "evalness" of the ModuleSource is done through dynamic import. The constructor itself **does not eval** - eval only happens at import - which is already possible right now.

[03:43:37.0702] <Luca Casonato>
 * My major open question in response to bakkot's points at plenary is how this qualifies as a new path to eval - we discussed this at the last loader meeting and came to the conclusion that a `ModuleSource` constructor was in fact **not** a new path to eval, because the "evalness" of the ModuleSource is done through the existing dynamic import. The constructor itself **does not eval** - eval only happens at import - which is already possible right now.

[03:44:25.0498] <Luca Casonato>
I would still like to invite bakkot to a loader meeting so we can discuss this in detail - I am likely missing something, or I am not understanding your concern correctly.

[07:30:48.0834] <littledan>
I think this is discussed more concretely as we discuss mitigations. Clearly the whole thing (ModuleSource + import()) put together was a path to eval. I guess the question was whether bakkot would accept a mitigation which was, "ModuleSource produces marked things which cannot be passed to import() but otherwise work" (but I'm not so convinced the feature is very useful, and we were discussing this above)

[08:04:32.0926] <bakkot>
Luca Casonato: as littledan says, ModuleSource + dynamic import is eval, to my view. yes, in some (but not all) hosts it possible to use `data` URIs with dynamic import already, but a.) that is not widely supported especially given CSP and so is not a reliable way to `eval` and b.) `data` URIs are very obviously a kludge, whereas a ModuleSource constructor would be a first-class part of the language, and we should be concerned about making paths to `eval` more usable, not just whether they exist at all.

also it is not at all clear to me what the use case for ModuleSource is other than `eval`; the cases discussed about were all either `eval`-like or a desire from a single library to have a built-in way of parsing out bindings. I think an affirmative case needs to be made for this feature (as with any feature), and to convince me personally that case needs to be something other than "we would like it to be easier to do `eval`" (or there needs to be an extremely strong reason to make it easier to do `eval`).

[09:39:01.0363] <littledan>
<weak-argument>well, it's eval for a module, which is otherwise more or less a missing capability</weak-argument>

[09:39:57.0301] <Kris Kowal>
I would ideally like to find a motivation for this path to eval that does not require others to buy into the SES group’s long-term motivation to make a safe path to eval, that does not rest on CSP, since I know that is contentious. But, that is personally my motivation. Making an easy path to lift text makes it easier to build a sandbox, and making that part of the language makes it easier to write portable sandboxes. One of the drawbacks of the compartment shim is that we have to censor the words `eval` and `import` from source text in order to enforce confinement. There are false positives that a native implementation wouldn’t suffer from.

[09:40:42.0741] <Kris Kowal>
Making it eaiser to make sandboxes has the emergent effect of making sandboxes safer.

[09:41:11.0697] <Kris Kowal>
And given that the design is compatible with CSP, I feel like this is a win-win.

[09:41:17.0769] <littledan>
Kris, I'm glad you're describing your actual use case, as this makes it a lot easier to follow

[09:41:21.0417] <littledan>
It's quite hard for me to follow a use case argument which centers on the censorship mechanism, since I really don't understand what sorts of restrictions you have in how you evolve that.

[09:41:45.0784] <littledan>
maybe you could give some more details there?

[09:43:00.0697] <Kris Kowal>
Yeah, in the SES shim, confinement is enforced at runtime and it’s a production performance and developer-experience requirement that not entrain rigorous static analysis or on-the-fly transformations.

[09:44:28.0620] <Kris Kowal>
The heart of the confinement mechanism points four of JavaScript’s sharpest edges at each other: We use use direct eval in sloppy mode inside a with block that puts an opaque proxy on the stack.

[09:44:48.0369] <Kris Kowal>
That’s…a summary.

[09:45:11.0882] <Kris Kowal>
In any case, there are a number of obvious ways to escape lexical containment.

[09:46:15.0920] <Kris Kowal>
Collectively “undeniable intrinsics”. So, for example, (async()=>{}) gives you access to the async function prototype. That’s pretty straightforward to confine with the hardening of shared intrinsics.

[09:47:04.0630] <Kris Kowal>
In the most basic case, {} and [] give you access to shared intrinsics in ways that can’t be denied with the lexical environment.

[09:47:59.0681] <Kris Kowal>
Likewise, `import` escapes confinement. So, we use a careful regex to identify any pattern that *might* be an invocation of import and refuse to evaluate such programs.

[09:48:33.0859] <Kris Kowal>
The Evaluators proposal would allow us to hook the behavior of `import` for confined programs.

[09:49:44.0479] <Kris Kowal>
We also ban direct `eval` similarly, but not so much because of confinement concerns, but because it is impossible to faithfully emulate the intended behavior in the shim.

[09:52:00.0850] <Kris Kowal>
In order to support modules, we have no choice but to convert modules into programs at compile time, which is a source-to-source transformation that reduces debuggability. We also eschew source maps because they can be used to confuse auditors.

[09:53:26.0520] <Kris Kowal>
So we have a module-to-program transform, which necessarily generates both the module functor source code and the bindings in a JSON envelope, and a runtime that handles these “module sources” reconstructs the linkage from the declared bindings and a sort of calling convention.

[09:55:19.0271] <Kris Kowal>
The net result is a Zip file that contains JSON enveloped sources which is not as debuggable or reviewable as we’d like. This is the artifact that must be trusted when you grant capabilities to the guest program, so this is the artifact that gets fingerprinted for integrity checks. It’s also, notably, not hosted on the web, and modules not hosted on the web are not currently possible to evaluate across all JavaScript hosts.

[09:56:01.0492] <Kris Kowal>
There are hacks, but they are hacks, and hacks and confinement are somewhat inimical.

[09:58:22.0315] <Kris Kowal>
And again, our position is not that we hope to capture all JavaScript in hardened JavaScript. Our position is that it should be possible to get to hardened JavaScript from ordinary mutable implicitly permissive one-big-sandbox JavaScript. We in fact *require* that as a starting point since anything else would preclude evolution of the host environment over time.

[10:00:13.0723] <Kris Kowal>
 * Yeah, in the SES shim, confinement is enforced at runtime and it’s a production performance and developer-experience requirement that we not entrain rigorous static analysis or on-the-fly transformations.

[10:29:48.0363] <Luca Casonato>
bakkot: so your concern is not that it is a **new** path to eval, but rather that it may make an existing path to eval more ergonomic?

As for the usecases that can justify an unconstructable `ModuleSource`:

- multiple instantiation modules (including module expressions & declarations)
- low level `script-src: no-eval` module passing between workers
- manual instantiation and module instrospection (we've seen this in WASM using `WebAssembly.Module`, for which `ModuleSource` would be the JS equivalent)

[10:34:43.0147] <bakkot>
Luca Casonato: it is a new path to eval in many contexts (e.g. anywhere with CSP, and therefore in any library), and also it makes an existing path to eval more ergonomic; both are concerns are important to me

[10:35:27.0212] <Kris Kowal>
I do not think that bakkot objects to the concept of an object that represents a module source, which has intersection semantics relevant to other proposals and does not imply a path to eval. Correct me if I’m wrong.

[10:36:09.0121] <bakkot>
right - none of my `eval` concerns apply to `ModuleSource` which does not take a string argument; I am fine with a static import syntax which gives you an object you can clone between workers and so on

[10:36:18.0979] <Kris Kowal>
Oh, bakkot our intention is _not_ to be a new path to eval with CSP. `no-unsafe-eval` would render a `ModuleSource` instance lifted from text inert.

[10:37:39.0999] <Kris Kowal>
> <@bakkot:matrix.org> right - none of my `eval` concerns apply to `ModuleSource` which does not take a string argument; I am fine with a static import syntax which gives you an object you can clone between workers and so on

This is to say we don’t need to convince bakkot of importing module sources or module blocks with sources, again correct me if I’m wrong.

[10:38:30.0498] <bakkot>
there are at least some contexts which allow `no-unsafe-eval` but do not allow `data` URIs (primarily because there are libraries with this requirement), so constructible ModuleSource + dynamic import would still constitute a new way to `eval` in such contexts

[10:38:36.0085] <bakkot>
 * there are at least some CSPs which allow `no-unsafe-eval` but do not allow `data` URIs (primarily because there are libraries with this requirement), so constructible ModuleSource + dynamic import would still constitute a new way to `eval` in such contexts

[10:38:52.0240] <Kris Kowal>
By inert I mean that `import(new Module(new ModuleSource('')))` would unconditionally return a rejected promise under a `no-unsafe-eval` CSP, and would poison any module that takes it as a transitive dependency as well.

[10:39:26.0842] <Kris Kowal>
Otherwise I would agree that would constitute a new path to eval in situations that should have none.

[10:40:51.0931] <Kris Kowal>
> <@bakkot:matrix.org> there are at least some CSPs which allow `no-unsafe-eval` but do not allow `data` URIs (primarily because there are libraries with this requirement), so constructible ModuleSource + dynamic import would still constitute a new way to `eval` in such contexts

Is there a way to better communicate an intention that constructible module sources must not create a new path to eval under any existing CSP that should disallow it?

[10:41:57.0564] <bakkot>
well, if your CSP allows `no-unsafe-eval`, then it _should_ allow `eval`, but I still don't think it is a good idea for the language to provide a new way to `eval` in that context

[10:42:21.0435] <bakkot>
and `import` is _not_ a way to `eval` in that context, which is good

[10:45:00.0404] <Kris Kowal>
I mean disallows `no-unsafe-eval`, to be clear.

[10:45:48.0133] <bakkot>
I agree that if we do end up with a constructible `ModuleSource` it must not be importable in a `no-unsafe-eval` context; I don't think there was any confusion about that

[10:45:54.0773] <Kris Kowal>
There’s a strong possibility I don’t know CSP well enough to have this conversation. I’m hoping for instruction.

[10:46:32.0698] <bakkot>
the relevant fact is that `no-unsafe-eval` does _not_ restricted use of `data:` URIs; those are controlled by the use of a `data:` scheme expression in the CSP

[10:46:36.0457] <Kris Kowal>
 * I mean a CSP that disallows use of `eval`, to be clear.

[10:46:59.0941] <bakkot>
so it is possible to have CSP in which `eval` is allowed and `data:` URIs are not, in which context `ModuleSource` + dynamic import is unambiguously a new path to eval

[10:47:39.0950] <Kris Kowal>
Is there a way we can frame it such that it would not be?

[10:47:53.0385] <bakkot>
not that I can think of?

[10:48:07.0890] <bakkot>
though all this discussion about CSP is all a little bit outside my main objection. I agree that it is _technically_ true that in at least some contexts `import` can be used for `eval` because of the existence of `data` URIs, though it is also even more technically true that this does not not apply in all contexts in which `ModuleSource` would work (if I understand correctly). however, I don't think this technical point is all that important; even granting it, it seems to me that `import` + constructible `ModuleSource` would a new first-class path to `eval` in a way that `import('data:')` is not , the latter being kludgey and not universally acceptable or available.

[10:49:28.0498] <Kris Kowal>
That is, how does one describe all CSPs in which `import(new Module(new ModuleSource(text)))` must fail?

[10:50:18.0028] <Kris Kowal>
Yeah, I’m not interested in any contexts where `import('data:')` is a workaround for eval CSP restrictions except insofar as that the proposal should not introduce loopholes in CSP.

[10:50:25.0979] <bakkot>
and while I am not dead-set against having a new _or new-ish_ first-class path to `eval` I would want it to have a strong justification, which I have not heard yet. whether this is _actually_ new or merely new-ish is not all that important to me - either way I still would want there to be a strong justification.

[10:50:40.0961] <Kris Kowal>
I am interested in environment in which there are no such workarounds, ones where import(doesNotEvenTakeURL).

[10:50:58.0081] <bakkot>
> <@kriskowal:matrix.org> That is, how does one describe all CSPs in which `import(new Module(new ModuleSource(text)))` must fail?

those which forbid `unsafe-eval`, I think is an accurate description

[10:51:37.0894] <Kris Kowal>
So it is possible that the CSP tangent was entirely us talking past each other. Thanks.

[10:52:35.0089] <Kris Kowal>
If I read correctly, we’re generally in agreement that ModuleSource(text) would not introduce a CSP loophole.

[10:52:42.0171] <bakkot>
right

[10:53:37.0603] <Kris Kowal>
> <@bakkot:matrix.org> and while I am not dead-set against having a new _or new-ish_ first-class path to `eval` I would want it to have a strong justification, which I have not heard yet. whether this is _actually_ new or merely new-ish is not all that important to me - either way I still would want there to be a strong justification.

This is my prior understanding and I suggest we focus on articulating a strong justification.

[10:54:27.0774] <Kris Kowal>
@bakkot You would not happen to have seen the bits about confining JavaScript guests without CSP above before they scrolled away?

[10:54:31.0444] <bakkot>
(the bit about CSP was just to say that `import` + `data:` URIs does not already constitute a path to `eval` in all contexts - there are CSPs which allow `eval` but do not allow importing `data:` URIs, so adding constructible `ModuleSource` would be in fact granting a path to `eval` via `import` which did not previously exist in that context. but as I say this is all kind of a technical point rather than my main objection.)

[10:57:52.0218] <bakkot>
> <@kriskowal:matrix.org> @bakkot You would not happen to have seen the bits about confining JavaScript guests without CSP above before they scrolled away?

I did read it but am lacking context to understand why your design requires the ability to `eval` modules from within a module, as opposed to having a compartment or something which would allow you to hook `import` within that context and provide a module that way

[10:58:54.0120] <Kris Kowal>
We certainly need both. The key is that the platform is backed by zipped applications (no URLs and no fetch capability)

[10:59:51.0476] <bakkot>
Why does the `import` hook on a compartment (or whatever compartments are called now) not suffice here?

[11:00:16.0296] <Kris Kowal>
The import hook returns Module instances with ModuleSources, from text dug out of Zip files.

[11:01:12.0320] <bakkot>
That's one possible design; certainly there are other designs for `import` which don't require a constructible `ModuleSource`, no?

[11:01:56.0355] <bakkot>
you could have a `defineImport(specifier: string, source: string)` capability available to the thing which created the compartment, or something, no?

[11:02:42.0397] <bakkot>
that would still be eval-like, but I am a lot less concerned about `eval` which is specifically defined in terms of compartments and which is defined from the outer compartment for use by the inner compartment, as opposed to one which is ambiently available

[11:02:48.0750] <bakkot>
(forgive me if I'm using the wrong terminology here)

[11:17:43.0583] <Kris Kowal>
That’s an interesting clarification.

[11:29:57.0592] <Luca Casonato>
> <@bakkot:matrix.org> there are at least some CSPs which allow `no-unsafe-eval` but do not allow `data` URIs (primarily because there are libraries with this requirement), so constructible ModuleSource + dynamic import would still constitute a new way to `eval` in such contexts

What CSP actually prevents `import("data:...")`? A no eval `script-src` doesn't in Chrome 👀 (example: https://dash.deno.com/playground/csptest)

[11:33:34.0859] <Luca Casonato>
also if i specify `default-src 'none'` - and same also in FF

[11:34:14.0167] <Kris Kowal>
> <@bakkot:matrix.org> that would still be eval-like, but I am a lot less concerned about `eval` which is specifically defined in terms of compartments and which is defined from the outer compartment for use by the inner compartment, as opposed to one which is ambiently available

Yeah, re terminology, by ambiently available, do you mean available by reference? An ocap interpretation of the term ambient would mean that it is registered to the parent host and available to all peers by a forgeable name.

[11:48:24.0735] <Luca Casonato>
> <@lucacasonato:matrix.org> What CSP actually prevents `import("data:...")`? A no eval `script-src` doesn't in Chrome 👀 (example: https://dash.deno.com/playground/csptest)

Oh apparently nonce'd script tags have an implicit `script-src 'strict-dynamic'' behavior for imports - TIL!

[11:48:27.0331] <bakkot>
> <@lucacasonato:matrix.org> What CSP actually prevents `import("data:...")`? A no eval `script-src` doesn't in Chrome 👀 (example: https://dash.deno.com/playground/csptest)

nonces are automatically inherited by imports, I think? try `unsafe-inline` instead of nonces in the CSP

[11:50:03.0623] <Luca Casonato>
yup, ok with that I can make a CSP that can do eval, but no `import("data:...")`: `script-src 'unsafe-inline' 'unsafe-eval'`

[11:50:41.0327] <Luca Casonato>
So your concern is that module source would allow `import()` to eval with just `unsafe-eval` specified, whereas right now you need `script-src data:` or `script-src blob:`?

[11:50:59.0708] <bakkot>
> <@kriskowal:matrix.org> Yeah, re terminology, by ambiently available, do you mean available by reference? An ocap interpretation of the term ambient would mean that it is registered to the parent host and available to all peers by a forgeable name.

I mean like any library can use this capability to `eval` in the current context, rather than only being able to do `eval` inside of a specially-constructed box

[11:52:00.0216] <bakkot>
> <@lucacasonato:matrix.org> So your concern is that module source would allow `import()` to eval with just `unsafe-eval` specified, whereas right now you need `script-src data:` or `script-src blob:`?

well, again, that is a technical point. yes, I am concerned a little bit about that, but the larger concern is that I do not regard `data:` URIs as being a first-class path to `eval` built in to the language, for this and other reasons, while `ModuleSource` would be.

[11:52:50.0787] <Luca Casonato>
i see - thank you for the clarification.

[11:56:25.0471] <Luca Casonato>
For all intents and purposes contexts with dynamic import and data URLs would have a constructable (all be it async) `ModuleSource` in the form of `(await import("data:application/javascript,abc", }{ reflect: "module" }).source` anyway, so for me the lack of an explicit `ModuleSource` constructor is not the end of the world

[11:57:10.0411] <Luca Casonato>
And in these contexts this factory would be subject to CSP - so no new path to eval here

[11:57:33.0861] <Kris Kowal>
So, Module in this proposal is providing exactly as limiting a scope as Compartments, even if Compartments are framed as a registry of source strings. If you’ll forgive a reductio absurdam, `const c = new Compartment({ importHook(specifier) { return import(specifier, {reflect: true}) } ); c.registerSource('name', text); c.import('name')` is equivalent. The key here is that `Module` is a box.

[11:57:48.0808] <Luca Casonato>
 * And in these contexts this factory would be subject to CSP - so no new path to eval here (the exact same CSP a direct `import({"data:...")` is subject to today)

[11:57:57.0651] <Luca Casonato>
 * And in these contexts this factory would be subject to CSP - so no new path to eval here (the exact same CSP a direct `import("data:...")` is subject to today)

[11:58:35.0769] <Luca Casonato>
 * For all intents and purposes contexts with dynamic import and data URLs would have a constructable (all be it async) `ModuleSource` in the form of `(await import("data:application/javascript,abc", { reflect: "module" }).source` anyway, so for me the lack of an explicit `ModuleSource` constructor is not the end of the world

[11:58:46.0725] <Kris Kowal>
My hope is that `Module` is in fact as much a box as the box you like in `Compartments`! :-)

[12:00:05.0773] <Kris Kowal>
And `Evaluators` give us another box, where we can capture the dynamic `import` behavior for non-modules. Out of these primitives, `Compartment` can be implemented in user code.

[12:00:38.0913] <Kris Kowal>
And hardened JavaScript can be faithfully implemented in user code, as it cannot with a shim.

[12:00:39.0877] <bakkot>
> <@kriskowal:matrix.org> So, Module in this proposal is providing exactly as limiting a scope as Compartments, even if Compartments are framed as a registry of source strings. If you’ll forgive a reductio absurdam, `const c = new Compartment({ importHook(specifier) { return import(specifier, {reflect: true}) } ); c.registerSource('name', text); c.import('name')` is equivalent. The key here is that `Module` is a box.

again, I'm concerned not just with _whether_ the thing is possible, but _how accessible_ it is. I agree that some designs for compartments can be bludgeoned into being a current-context `eval` but that doesn't mean all possible designs are equivalent.

[12:02:07.0915] <bakkot>
`eval` already exists, but we've largely been able to convince people not to use it. I don't want to make a new `eval` and leave it lying around in another easily accessible form.

[12:02:21.0021] <Kris Kowal>
Well, if you’re satisfied by some API impedance, that’s overall good news since we care more about what’s possible than how coherent it is.

[12:03:08.0877] <Kris Kowal>
And Compartments are not all that cumbersome.

[12:03:18.0205] <bakkot>
I am certainly _more_ comfortable with less accessible APIs but not automatically entirely comfortable with them

[12:03:26.0702] <bakkot>
 * I am certainly _more_ comfortable with less accessible new ways to `eval` but not automatically entirely comfortable with them

[12:04:54.0195] <Kris Kowal>
Would this be a sufficiently inaccessible affordance: `new Compartment({ importHook(specifier) { return { source }; } }).import('specifier')`?

[12:04:56.0170] <bakkot>
though in addition I think if Compartments the use case then a design which exposes the capability only to compartments is more palatable for that reason

[12:05:25.0588] <bakkot>
That would make me feel a lot better than `import(new Module(new ModuleSource(source)))`, certainly

[12:09:55.0849] <bakkot>
Though I would still be hesitant to add that if the only use case is your source-from-zip-files thing

[12:10:11.0711] <Kris Kowal>
So we would recover the ergonomics in user code like:
```
const loadModuleSource = async source => new Compartment({ importHook: () => ({ source }) }).import('.', { reflect: true });
```

[12:11:10.0418] <bakkot>
Why do you want to recover the ergonomics?

[12:11:18.0534] <Kris Kowal>
zip-files in this case represent a class including databases, local storage, &c, if that makes any difference in substance.

[12:11:28.0084] <bakkot>
Not really.

[12:12:17.0726] <Kris Kowal>
And in all these cases, the point is that it’s possible to draw a circle around a working set as a reviewable, confineable artifact, which would not otherwise be possible to isolate in this way.

[12:12:46.0347] <bakkot>
that is, those things are not a use case on their own - if you want to `eval` code from local storage, my question will be why do you want that

[12:13:19.0514] <bakkot>
I think I understand your particular use case, which makes cloning an opaque object to a Worker not viable, but am not convinced by that use case alone

[12:13:25.0539] <Kris Kowal>
In our case, the artifacts are smart contracts, responsible for handling money on behalf of multiple parties.

[12:14:34.0950] <bakkot>
Right, which is to say, an extremely unusual case, unlikely to generalize to something needed by other applications

[12:15:01.0005] <Kris Kowal>
Doug Crockford used to refer to the generalization of the case as mash-ups.

[12:16:34.0513] <bakkot>
Doug Crockford talked about wanting to be able to shell out to a separate process and communicate code to that process in a transparent representation?

[12:18:26.0530] <Kris Kowal>
Hardly so specifically, but Doug built AdSafe at Yahoo, which does isolate and evaluate arbitrary guest programs.

[12:20:48.0302] <bakkot>
Program isolation is mostly orthogonal from `eval` - generally one can serve the guest programs from a server, as programs, and not need to `eval` them (assuming the language has isolation abilities at all, which would need to be built out anyway, as we are doing with realms and so on)

[12:21:26.0768] <bakkot>
Your particular use case prevents this but, again, your particular use case seems to me to be extremely unusual

[12:22:53.0207] <bakkot>
So I would still want to hear other use cases before adding this feature, as I would for any feature, although they can be somewhat less compelling as long as the new path to `eval` is less accessible

[12:23:30.0821] <bakkot>
 * So I would still want to hear other use cases before adding this feature, as I would for any feature, although they can be somewhat less compelling than I would want for a new _easily-accessible_ path to `eval`


2023-01-10
[17:10:49.0600] <littledan>
Could anyone summarize the conclusions of this conversation?

[19:47:09.0449] <Kris Kowal>
Kevin might be convinced that a path from module text to evaluated behavior is permissible if 1. no new loopholes to CSP are introduced (and we agree that this is not a concern) 2. the capability is not too easy to find or use, for example made possibly only through a Compartment importHook that returns `{ source }` (but presumably not a Module importHook, and with no ModuleSource constructor. We agree that this does not limit expressible behavior.) and 2. motivation more compelling than just Agoric’s use case can be found. The use cases presented as yet are not sufficiently compelling.

[19:49:19.0406] <Kris Kowal>
To that end, I might reach out to the community at large to build a coalition. It seems we need some combination of quantity and quality of use cases that we have not yet presented. I believe these exist and we need testimonials.

[19:54:37.0783] <ljharb>
my primary use case is being able to test module-level syntax features, like TLA, without necessarily needing a filesystem to be present. That's already what I use Function for (and potentially AsyncFunction, GeneratorFunction, and AsyncGeneratorFunction as well).

[20:01:27.0250] <littledan>
ljharb, could you elaborate on what the testing is for? I take it that this is for a polyfill, rather than test262-related (where we could add extra host callbacks)

[20:02:36.0963] <littledan>
I take it that the use case has to be something that bakkot can be convinced is important enough (since he questioned that above); maybe context from ljharb could meet that requirement

[20:06:50.0373] <ljharb>
yes, polyfills or environment testing packages - like “has object spread” or “has top-level await”

[20:07:19.0317] <ljharb>
or “has Unicode named exports”, or any new syntax we add to the top level of Modules in the future

[20:07:56.0611] <ljharb>
until we ship a syntax detection mechanism (which we may never do), eval is the only viable alternative.

[20:12:00.0204] <littledan>
Could you say more about why ModuleSource helps you do something that you can't do with plain eval?

[20:17:37.0874] <Kris Kowal>
I’m also motivated by ljharb’s use case, but in the interest of demonstrating that I’ve listened to bakkot carefully, I imagine that module blocks + eval are sufficient to that end and would not require ModuleSource.

[20:18:07.0852] <ljharb>
nope, because i can’t test for the syntax in an engine that lacks module blocks

[20:18:15.0457] <ljharb>
i need a purely API-based solution

[20:18:16.0656] <Kris Kowal>
 * I’m also motivated by ljharb’s use case, but in the interest of demonstrating that I’ve listened to bakkot carefully, I imagine that module blocks + eval are sufficient to that end and would not require ModuleSource(text)

[20:18:36.0064] <bakkot>
module blocks would presumably need to contain valid-in-the-current-engine syntax anyway

[20:18:37.0049] <ljharb>
oh i see what you mean, inside Function, put a module block

[20:18:47.0132] <bakkot>
oh wait yeah

[20:19:11.0005] <bakkot>
yeah that seems adequate for this use case if I understand the use case correctly

[20:20:06.0210] <Kris Kowal>
That’s not to say I wouldn’t favor ModuleSource(x) over eval('module {' + x + '})') for that purpose, but we would only need one or the other strictly speaking.

[20:20:19.0921] <ljharb>
Function, to be clear, never eval :-)

[20:20:28.0218] <ljharb>
but yeah, same.

[20:20:31.0452] <Kris Kowal>
Yeah, fair.

[20:20:45.0286] <Kris Kowal>
Never direct-eval, anyway.

[20:22:18.0716] <ljharb>
i just avoid it like a bad word, direct or not

[20:22:47.0698] <bakkot>
ljharb: kind of a tangent, but why do you need to feature-test syntax anyway? is it just to decide which polyfill to load or is there some other case it comes up?

[20:23:03.0706] <bakkot>
("deciding which polyfill to load" is an important use case, I'm just wondering if there's others I'm missing)

[20:23:21.0243] <ljharb>
i use it constantly in test suites

[20:23:42.0484] <ljharb>
(also even if Function + a module block works for me, i still have the consistency argument that every other way of passing around code-to-be-executed has a constructor)

[20:23:48.0064] <Kris Kowal>
We do eval-based syntax testing to discover intrinsics we need to freeze, tame, and trim.

[20:23:57.0833] <Kris Kowal>
(In `ses` shim.)

[20:24:39.0168] <Kris Kowal>
I’m sympathetic to the consistency argument, but it doesn’t pass the bakkot test.

[20:25:42.0695] <Kris Kowal>
I feel very strongly that the best proposals triangulate a void implied by two other features, the way Array.from and async imply the existence of Array.fromAsync.

[20:26:06.0343] <Kris Kowal>
Or the way Array and iterators imply iterator helpers.

[20:30:20.0312] <bakkot>
if the only goal was to fill the void left by `eval` only handling the Script parse goal, the way to fill it would be `eval(source, { type: 'module' })` or something, which... I mean, I find that instinctively distasteful, but the reason I don't like it is because it's enhancing `eval`, which is also my objection to all of the other options

[20:30:36.0903] <bakkot>
it at least has the advantage that it would not be _new_ thing that we would need to tell people not to use

[20:32:30.0332] <bakkot>
honestly I kind of appreciate the honesty of it - the fundamental question before the committee, do we want to make `eval`-for-modules? if we would not add `eval(source, { type: 'module' })` then we probably should not add a constructible `ModuleSource` either

[21:33:00.0866] <Jack Works>
> <@lucacasonato:matrix.org> My major open question in response to bakkot's points at plenary is how this qualifies as a new path to eval - we discussed this at the last loader meeting and came to the conclusion that a `ModuleSource` constructor was in fact **not** a new path to eval, because the "evalness" of the ModuleSource is done through the existing dynamic import. The constructor itself **does not eval** - eval only happens at import - which is already possible right now.

Looks like the solution is to add a new directive for `script-src` CSP to limit import from dynamically constructed `ModuleSource`.

e.g. `script-src: unsafe-module-source`

[21:34:39.0638] <Jack Works>
> <@lucacasonato:matrix.org> My major open question in response to bakkot's points at plenary is how this qualifies as a new path to eval - we discussed this at the last loader meeting and came to the conclusion that a `ModuleSource` constructor was in fact **not** a new path to eval, because the "evalness" of the ModuleSource is done through the existing dynamic import. The constructor itself **does not eval** - eval only happens at import - which is already possible right now.

 * Looks like the solution is to add a new directive for `script-src` CSP to limit import from dynamically constructed `ModuleSource` from string.

e.g. `script-src: unsafe-module-source`

[21:39:16.0388] <Jack Works>
🤔 Is `ModuleSource` unforgeable? via `(module {}).constructor`

[21:42:04.0245] <Justin Ridgewell>
What do you mean by unforgeable?

[21:44:30.0533] <Justin Ridgewell>
> <@jackworks:matrix.org> Looks like the solution is to add a new directive for `script-src` CSP to limit import from dynamically constructed `ModuleSource` from string.
> 
> e.g. `script-src: unsafe-module-source`

As long as `unsafe-module-source` is a more specific variant of `unsafe-eval` (`unsafe-eval` disables both like it does for `wasm-unsafe-eval`)

[21:46:12.0305] <Jack Works>
> <@kriskowal:matrix.org> Great, this is clear. We can focus on building 1. the strongest reason and 2. the work-arounds other proposals (specifically module binding static analysis) can be recovered in the absence of ModuleSource(text).

or make `ModuleSource.fromString` a thing and make it potional?

[21:53:55.0592] <Jack Works>
> <@kriskowal:matrix.org> And the motivation for parsing bindings is bundle, web archive, or import map generation, in which case, a path to eval is not needed.

further split `ModuleSource` into `ParsedModule` and `ImportableModule`?

`ParsedModule` can be used for analyze purpose, but cannot be imported.
`ImportableModule` constructor accepts `ParsedModule` or an object that implements Virtual Module Source interface. If there is CSP, it will throw when `ParsedModule` is constructed from a string (or any other TrustedType limitations).

[22:05:06.0447] <Jack Works>
> <@littledan:matrix.org> https://github.com/guybedford/es-module-lexer

Every time I want to use es-module-lexer for some fast analyzing it always fails because
- I want to analyze TypeScript + JSX
- I want to analyze import bindings

[22:09:56.0014] <Jack Works>
> <@kriskowal:matrix.org> I assume this is sufficient to accept exactly and only grammatically valid sources. That requires block matching, but not AST generation. The other motivation for a full parse is that `eval('module {' + text + '}')` is an inevitable work-around for the lack of `ModuleSource`, which is much worse if text is not constrained to be a valid module source.

which definitely seems worse `text = '}; run any code; {'`

[06:24:11.0956] <littledan>
> <@jackworks:matrix.org> 🤔 Is `ModuleSource` unforgeable? via `(module {}).constructor`

In the current module blocks proposal, this is `Module`

[06:25:05.0394] <littledan>
> <@ljharb:matrix.org> nope, because i can’t test for the syntax in an engine that lacks module blocks

I guess this is mostly an issue if there exists any engine that ships constructable Module before module blocks.

[06:27:21.0397] <littledan>
> <@jackworks:matrix.org> Every time I want to use es-module-lexer for some fast analyzing it always fails because
> - I want to analyze TypeScript + JSX
> - I want to analyze import bindings

What do you end up doing instead?

[09:28:26.0361] <ljharb>
> <@littledan:matrix.org> I guess this is mostly an issue if there exists any engine that ships constructable Module before module blocks.

no, it's also an issue for being able to ship syntax-testing code to an engine that doesn't have either one

[09:30:33.0228] <Jack Works>
> <@littledan:matrix.org> What do you end up doing instead?

Use a full-powered parser (I am familiar with the TypeScript compiler API) which is costly. 

[10:08:55.0850] <Kris Kowal>
> <@jackworks:matrix.org> which definitely seems worse `text = '}; run any code; {'`

It is, but @bakkot makes the case that a lexer with limited parse capabilities, such that it can do the static analysis and balance braces, brackets, and parentheses, is on the order of 1KB, so it’s at least possible to avoid the code injection hazard. Node.js has such a lexer by guybedford (Guy Bedford) and the performance was okay, though only in WASM.

[10:09:54.0467] <Kris Kowal>
I do think that 1.) performance of native will be unbeatable and 2.) code injection foot-gun do count in favor of ModuleSource, but my understanding is that this is not enough to sway @bakkot.

[10:11:00.0867] <Kris Kowal>
> <@jackworks:matrix.org> or make `ModuleSource.fromString` a thing and make it potional?

I agree that this is a viable mitigation. It at least decouples `Module` from constructible `ModuleSource`.

[10:16:30.0435] <Kris Kowal>
> <@bakkot:matrix.org> honestly I kind of appreciate the honesty of it - the fundamental question before the committee, do we want to make `eval`-for-modules? if we would not add `eval(source, { type: 'module' })` then we probably should not add a constructible `ModuleSource` either

I hear you that we should slice off a portion of Module Harmony that is explicitly eval-but-modules, but I would not propose `eval(source, { type: 'module' })` as the vessel for it under any circumstances. Modules are more analogous to the `Function` constructor form of `eval` since they are reusable and defer execution, but differ because they can import and export. An `eval` form would have to answer a lot of questions about top-level await. The form would clearly be unable to export, and a completion value would stand in the way of an exports namespace. I think that the question of whether to support eval-but-modules is a better framing, but `ModuleSource` is consistent with the prevailing eval aesthetic.

[10:17:54.0081] <Kris Kowal>
That said, I don’t know whether JSDOM for example would be able to emulate `<script type="module">` faithfully using `ModuleSource`. I don’t recall whether scripts can export.

[10:20:02.0906] <Kris Kowal>
Inviting domenic (Domenic Denicola) because I had reason to wonder whether JSDOM would be a motivating use case for `ModuleSource`, such that `<script type="module">` could maybe be emulated faithfully on a language feature.

[10:20:37.0235] <Kris Kowal>
And also because domenic (Domenic Denicola) should be here anyway. 😊

[11:07:09.0854] <ljharb>
i think script type modules _can_ export, but i'm not sure if anything can access them?

[11:07:55.0725] <Kris Kowal>
Yeah, `ModuleSource` would be sufficient assuming the exports just get black-holed.

[11:08:31.0359] <ljharb>
there's only one Module parse goal so i'm not sure how you'd have a Module without allowing exports

[11:08:33.0920] <Kris Kowal>
And I don’t think we should make an eval form that reveals the completion value of a `ModuleSource`. I can’t imagine that being useful.

[11:08:57.0039] <Kris Kowal>
 * And I don’t think we should make an eval form that reveals the completion value of a module. I can’t imagine that being useful.

[11:11:47.0104] <ljharb>
i mean it could easily be the module namespace object for it, but i agree it's not super useful and best avoided


2023-01-11
[07:57:43.0368] <littledan>
> <@ljharb:matrix.org> no, it's also an issue for being able to ship syntax-testing code to an engine that doesn't have either one

I'm having trouble understanding this; doesn't `eval("module{}")` work well enough for that case?

[08:41:28.0301] <ljharb>
it might, altho ModuleSource could be polyfilled to detect TLA in an engine that doesn’t support module blocks, but polyfilling eval itself isn’t an option (or a good idea even if it were)

[09:44:23.0457] <littledan>
yeah, it still sounds to me like, for feature testing, the utility is mostly "if this feature ships before module blocks in any engine"

[11:00:24.0305] <ljharb>
mostly sure. the bigger argument for me is the consistency one

[11:00:34.0835] <ljharb>
 * mostly sure. the bigger argument for me is the consistency one, but i realize that may not interest others as much

[11:00:40.0901] <ljharb>
 * mostly, sure. the bigger argument for me is the consistency one, but i realize that may not interest others as much

[11:07:41.0064] <littledan>
Kris Kowal: Could you invite peetk ? (Or, better, give everyone permission to invite others?)

[11:08:04.0125] <littledan>
 * Kris Kowal: Could you invite scottwhittaker  ? (Or, better, give everyone permission to invite others?)

[11:09:07.0411] <littledan>
oh apparently it's publicly listed and joinable, we just don't have permission to invite people...

[11:33:25.0383] <Kris Kowal>
I think I found the button that will extend to everyone the invite folks.

[11:33:35.0459] <Kris Kowal>
 * I think I found the button that will extend to everyone the right to invite folks.

[11:33:55.0300] <scottwhittaker>
Looks like I can invite now, thanks Kris Kowal !

[11:34:06.0427] <Kris Kowal>
Greetings, scottwhittaker. Welcome aboard.

[11:34:13.0134] <scottwhittaker>
Thanks! Happy to be here :)


2023-01-16
[02:34:56.0648] <Jack Works>
How do you think about this:

A new proposal that allows to partially download the module graph. This enables link-time tree shake for ESModule.

```js
// some-package/index.js
export { a } from './a.js'
export { b } from './b.js'

// main.js
partial import { a } from 'some-package'
```

Only `some-package/a.js` will be downloaded. To make this possible, some requirements are applied.

- If the file contains `export * from './x.js'`, to make it correctly resolved, `./x.js` will still be downloaded, which means, if you want your module can be imported partially, you'd better to write all export names instead of use `export * from` which might be annoying for library authors.
- A partially imported file might be failed to import in the future because download may fail. `import('some-package')` fails if `./b.js` is not found.

This proposal has the same design problem that @yulia's defer import faces (e.g. mixed usage of normal import and `defer`/`partial` import).

[13:18:25.0158] <ljharb>
that seems like a lot of complexity to add, compared to `import a from 'some-package/a.js'`

[13:18:57.0683] <ljharb>
iow, it seems like the need to do a partial import is solely *caused* by having created a file that re-exports (as opposed to forcing/encouraging deep importing)


2023-01-17
[18:53:13.0090] <Jack Works>
But deep importing is discouraged by the npm ecosystem by "export map", you have to explicitly expose the folder you want to (when using export map)

[20:07:56.0144] <ljharb>
how is that discouraging it?

[20:08:12.0266] <ljharb>
it certainly means your "exports" needs to enumerate all your entry points, sure

[20:08:36.0786] <ljharb>
but it means users have much smaller bundle sizes and/or memory footprints, way smaller than "treeshaking" can achieve

[20:53:08.0221] <Kris Kowal>
It would be fair to say that export maps tilt the field slightly away from accidental deep exports in a way that gives package authors an important degree of control over the expression of their forward compatibility commitments, but I would not say it discourages deep exports.

[22:33:42.0173] <ljharb>
you have to explicitly add a `.` also, and explicitly make your barrel/manifest file, so it seems the same to me as far as maintainer effort

[08:48:44.0196] <annevk>
littledan: are we meeting today? Not a lot of people confirmed for today.

[08:57:02.0776] <nicolo-ribaudo>
I will join

[08:57:29.0249] <guybedford>
annevk: these meetings have been fairly regular so I'm sure a few of us will turn up

[08:57:47.0711] <guybedford>
as long as we have someone with the permissions that is...

[08:57:55.0464] <Kris Kowal>
All set to welcome folks into the meet.

[09:04:00.0369] <Kris Kowal>
littledan we have anne today. Any chance you’re on your way?

[10:49:29.0727] <annevk>
My follow-up from the meeting: https://github.com/whatwg/html/issues/7233#issuecomment-1385852355 I will have more Jan 26 as part of the group meets then

[11:16:11.0986] <littledan>
ah sorry for missing the meeting, but I'm glad to hear that Anne got to meet everyone


2023-01-18
[23:45:25.0915] <annevk>
yulia: will Fx hold off from shipping Import Assertions?

[01:16:01.0720] <yulia>
annevk: we can wait on it, yes

[10:21:12.0285] <annevk>
Although I'll be on vacation the week of the next TC39 meeting (assuming https://github.com/tc39/agendas/blob/main/2023/01.md is correct), I'm willing to make the time to attend a morning session about this topic if that would help.

[10:22:18.0348] <Kris Kowal>
Are there champions among us who intend to present at plenary?

[10:22:55.0292] <Kris Kowal>
I for one expect to not be able to attend, depending on how the baby-wave-function collapses, so I’m not making any such plans.

[10:24:05.0584] <littledan>
We're working on a presentation in Bloomberg+Igalia for next meeting, and will have something on the agenda today

[10:24:37.0198] <littledan>
I'm a champion of the initial proposal and will put my stamp on it but might not actually be the presenter. I'm totally open to being a co-presenter if needed though.

[10:24:57.0159] <littledan>
> <@annevk:matrix.org> Although I'll be on vacation the week of the next TC39 meeting (assuming https://github.com/tc39/agendas/blob/main/2023/01.md is correct), I'm willing to make the time to attend a morning session about this topic if that would help.

Yes, it'd definitely help if you attended and gave your point of view

[10:25:26.0380] <Kris Kowal>
A presentation regarding import assertions?

[10:26:11.0769] <nicolo-ribaudo>
Yes, based on the discussion we had on Tuesday 

[10:28:38.0377] <nicolo-ribaudo>
> <@annevk:matrix.org> Although I'll be on vacation the week of the next TC39 meeting (assuming https://github.com/tc39/agendas/blob/main/2023/01.md is correct), I'm willing to make the time to attend a morning session about this topic if that would help.

I'll add the discussion to the agenda, should I put as a schedule constraint for you that it should be in the first hours of the day? (10:00-12:00 EST)

[10:29:18.0304] <annevk>
Yeah, that would be great, thanks!


2023-01-19
[12:59:48.0316] <peetk>
hello everyone, here is a draft of what we intend to present next week regarding import attributes, following up on recent conversations: https://gist.github.com/peetklecha/a55532165dbd4905aa91bbe59e8b1001

[13:00:00.0333] <peetk>
we would really appreciate input before sharing this more widely

[13:14:59.0775] <littledan>
I missed the last few module calls; is this a good summary of what people were thinking there?

[14:25:05.0684] <ljharb>
a conclusion in March, or in January?

[14:25:50.0670] <littledan>
We're going to work on a PR to the repo, but I don't think we have enough time to get consensus on it this meeting (the PR should be up already to achieve that)

[14:26:18.0023] <littledan>
so the proposal is to sort of have this two month period to continue working it out, hoping to get consensus on some kind of change to import assertions by March

[14:26:30.0796] <littledan>
and the "conclusion" from this meeting would be "please hold on, implementers"

[14:26:45.0695] <littledan>
 * We're going to work on a PR to the import assertions repo, but I don't think we have enough time to get consensus on it this meeting (the PR should be up already to achieve that)

[14:33:05.0309] <ljharb>
makes sense, that's a really good thing to establish asap, to remove the time pressure on figuring things out

[14:36:26.0117] <littledan>
well, I think we have significant time pressure either way; if we don't deliver on a solution soon, a fairly likely outcome is that we'll have incoherent things shipping more widely. So I hope we can come to consensus on a way through by March.

[14:36:39.0782] <ljharb>
true enough

[14:36:52.0653] <Justin Ridgewell>
> with the understanding that web browsers may violate the semantic requirements of the JavaScript specification, that import assertions behave as assertions
I think that's incorrect from TC39's side. We should remove the restriction if we decide to keep using `assert`

[14:36:53.0129] <Justin Ridgewell>
 * > with the understanding that web browsers may violate the semantic requirements of the JavaScript specification, that import assertions behave as assertions

I think that's incorrect from TC39's side. We should remove the restriction if we decide to keep using `assert`

[14:37:27.0344] <littledan>
> <@jridgewell:matrix.org> > with the understanding that web browsers may violate the semantic requirements of the JavaScript specification, that import assertions behave as assertions
> 
> I think that's incorrect from TC39's side. We should remove the restriction if we decide to keep using `assert`

The proposal here is to change the keyword as well as the semantics

[14:37:40.0578] <Justin Ridgewell>
> An alternative, which we disprefer, is to continue using the assert syntax

[14:37:56.0402] <Justin Ridgewell>
It's a stated alternative, which I think badly states the alternative

[14:38:06.0180] <littledan>
sure, in this alternative then we have two sub-alternatives, but they're both bad

[14:38:25.0710] <littledan>
the sub-alternatives being, relax the invariant or not

[14:38:33.0706] <littledan>
(and if relaxed, then how)

[14:38:47.0332] <littledan>
this document proposes changing the syntax instead

[14:39:01.0867] <littledan>
there's always lots of alternatives which can be considered!

[14:40:46.0330] <Justin Ridgewell>
> Further possible benefits of import attributes

We can also unnest the dynamic import syntax: `import x from "y" with type: "json", reflect: "module";` -> `import("y", { type: "json", reflect: "module" })` (instead of `import("y", { assert: { type: "json" }, reflect: "module" })`)

[14:43:50.0394] <littledan>
maybe! That's a useful kind of bikeshedding which I'd encourage to happen outside of plenary. In plenary, I'd like to focus on getting a shared understanding of the problem space and vague sympathy with the idea that we'd move back from assertions to something else with different syntax and semantics, maybe more like a previous iteration of the proposal (but with some mitigations to address the issues previously raised about unrestricted import attributes)

[14:44:33.0741] <littledan>
I think we can bikeshed at more length on the details in our loader calls. What's harder is getting that agreement in principle in the change in direction.

[14:50:28.0948] <littledan>
What do people here think about that change in direction?

[15:00:39.0391] <Kris Kowal>
Supportive.

[15:03:49.0377] <Kris Kowal>
Something mildly tragic that is probably impossible to avoid is that the 'css' type will come to generally mean the kind of CSS we have today, which can’t fully participate in the module graph because it imports by URL, not module specifier (and implied 'css' type). It would be nice if we some day had proper CSS modules that would benefit from specifier resolution for their imports.

[15:07:29.0623] <littledan>
I thought CSS modules weren't allowed to import at all, and that was their way around it

[15:07:47.0104] <Kris Kowal>
That’s a cool stopgap.

[15:07:55.0746] <Kris Kowal>
I didn’t know that was the case.

[15:08:11.0718] <littledan>
we should figure this out... I could be remembering wrong

[15:08:42.0467] <Kris Kowal>
So, in the future, CSS imports could participate in the module graph with an implicit type: 'css'.

[15:09:05.0787] <littledan>
what do you mean, implicit?

[15:10:26.0121] <littledan>
oh, right, an @import within css would have that type by default


2023-01-20
[00:00:44.0388] <annevk>
As far as syntax bikeshedding outside of the formal meeting goes, probably don't wanna forget it impacts `import()` too?

[00:02:06.0403] <annevk>
And interesting point on CSS, I didn't realize those would forbid further imports. Not sure if that's enough as they also take URLs, but maybe. (It would have been so nice if import specifiers were just URLs. We could have made `js:specifier` work. Oh well.)

[04:41:32.0316] <littledan>
> <@annevk:matrix.org> As far as syntax bikeshedding outside of the formal meeting goes, probably don't wanna forget it impacts `import()` too?

Yes, we would need to make the decision of whether this puts all attributes at the top level, or whether they stay in a `with` property

[04:42:40.0650] <littledan>
> <@annevk:matrix.org> And interesting point on CSS, I didn't realize those would forbid further imports. Not sure if that's enough as they also take URLs, but maybe. (It would have been so nice if import specifiers were just URLs. We could have made `js:specifier` work. Oh well.)

I think it is a straightforward solution to say, within CSS there is a default type (and they would need to add some syntax if they wanted to import JS, whatever that means)

[07:01:22.0412] <Kris Kowal>
Yeah, I will not stop until all URLs are module specifiers and not the other way around ;-)


2023-01-22
[09:37:35.0714] <nicolo-ribaudo>
> <@peetk:matrix.org> hello everyone, here is a draft of what we intend to present next week regarding import attributes, following up on recent conversations: https://gist.github.com/peetklecha/a55532165dbd4905aa91bbe59e8b1001

Hello people, I prepared some slides based on peetk's gist: https://docs.google.com/presentation/d/1HbWhyo4tSnpv4vMZqCa2YQvi_mKdpDi4JWWBtSUQqQY

I went with the "change keyword" + "limit hosts to only use the `type` attribute to affect how the module is fetched and interpreted" path — the main difference between the slides and the gist is that I kept the current syntax (just swapping `assert` with `with`) because that felt like an orthogonal discussion


2023-01-23
[06:51:42.0295] <littledan>
Hey Sven! svensauleau was one of the original co-champions of import assertions with me (actually we developed the idea while in an Igalia Web Engines Hackfest)

[06:52:22.0673] <littledan>
now we have all original champions of that proposal engaged--Myles and Dan Clark got back to me saying they don't have the bandwidth to be involved at the moment, but Dan finds the idea of a change along the lines of the gist reasonable


2023-01-24
[00:21:32.0711] <annevk>
I was looking at https://docs.google.com/presentation/d/1HbWhyo4tSnpv4vMZqCa2YQvi_mKdpDi4JWWBtSUQqQY/edit#slide=id.g1f8a07b0c2b_0_53. I hope we do actually enforce CORS for module style sheets. It doesn't really affect the slides though. The overall point stands.

[00:28:01.0977] <annevk>
Looks good overall. Thanks for making these!

[00:28:26.0033] <annevk>
It's too bad https://chromestatus.com/metrics/feature/popularity doesn't have any metrics for this feature.

[00:29:20.0036] <annevk>
domenic (Domenic Denicola): do you know if there are internal metrics for Import Assertions that you can share?

[00:37:55.0099] <littledan>
> <@annevk:matrix.org> I was looking at https://docs.google.com/presentation/d/1HbWhyo4tSnpv4vMZqCa2YQvi_mKdpDi4JWWBtSUQqQY/edit#slide=id.g1f8a07b0c2b_0_53. I hope we do actually enforce CORS for module style sheets. It doesn't really affect the slides though. The overall point stands.

Well, we do currently set cors, just as we do currently use the script destination. I guess that probably wasn’t the best example for the slides. Maybe Accept: would be?

[00:47:38.0245] <annevk>
littledan: yeah that could work, or only have destination and CSP


2023-01-26
[07:39:19.0972] <Mathieu Hofman>
> <@kriskowal:matrix.org> And `Evaluators` give us another box, where we can capture the dynamic `import` behavior for non-modules. Out of these primitives, `Compartment` can be implemented in user code.

I have been out of this conversation for a while, but thinking about this, I'm wondering if an `evaluator.createModuleSource(moduleSourceString): ModuleSource` would make sense. It would clearly be tied to making new evaluators, in a way that can be denied independently from `ModuleSource` existence. However while I believe an evaluator holds its own module graph, I don't think ModuleSource participate in that graph since they're just unevaluated source representation.

[07:54:08.0119] <Kris Kowal>
Indeed. There would be no entanglement between the `evaluator` and the resulting `ModuleSource`. There _is_ entanglement between the evaluators and module instance in `const evaluators = new Evaluators(); new evaluators.Module(...)`

[08:00:07.0047] <Kris Kowal>
That entanglement is evident in a number of ways, including the global object visible to the module, the differentiation between direct and indirect `eval` (the `eval` in scope must match the `eval` of the evaluators instance), the evaluators bequeathed to the module block and module blocks under direct eval, and I believe some other cases. If the evaluators are endowed onto their own globalThis, then the `Function`, indirect `eval`, _and_ `Module` are also entangled, such that `(0, eval)('import("x")')` invokes the `importHook` of the evaluators directly and the same story applies to constructed functions.


2023-01-27
[12:44:11.0793] <Justin Ridgewell>
In case you're not following all the GH issues: V8/Chromium just posted https://github.com/whatwg/html/issues/7233#issuecomment-1407049226

[15:39:17.0257] <littledan>
Interesting, I guess that is what you were pushing for, Justin

[15:41:37.0413] <shu>
happy to add more nuance next week

[15:42:50.0846] <littledan>
Thanks for taking the time to think this through!