| 16:17 | <Jack Works> | https://github.com/codehag/pattern-matching-epic cc Kris Kowal this repo introduce a new proposal process called Epic, it looks very like what you did in #71 |
| 16:57 | <Kris Kowal> | Convergent evolution in the wild. |
| 17:00 | <Kris Kowal> | yulia: as Jack Works points out, we have jinxed each other. I have a PR open that breaks Compartments into layers https://github.com/tc39/proposal-compartments/blob/fc3e8e0a6c1af7ffb09f111d9ddd9328aed09cf0/README.md |
| 17:01 | <Kris Kowal> | Which is to say, I support this potential new evolution in proposal design. |
| 22:55 | <Kris Kowal> | littledan, nicolo-ribaudo Had a conversation with Mark Miller and Peter Hoddie in which I managed fall back to my earlier position that Module needs to take a referrer and that the arguments of importHook need to be (specifier, referrer), but now with a compelling argument: It should not be possible for the referrer to vary between calls to the importHook, and that’s best guaranteed if we capture the referrer given to the Module constructor in an internal slot that the module instance feeds back to importHook. |
| 22:57 | <Kris Kowal> | I may or may not successfully edit my way to that state before I present, and obviously, my goal is to reach a consistent snapshot before plenary, not to have a final answer to the design question. |
| 22:57 | <littledan> | Wait, I had a conversation with guybedford where he managed to convince me that a ModuleSource should have a referrer |
| 22:57 | <littledan> | This is all consistent though |
| 22:58 | <Kris Kowal> | Yeah, we’re likely to have conversations like that until we either get tired or separate all three layers. |
| 22:59 | <Kris Kowal> | That being: {text, bindings}, {{text, bindings}, referrer}, {{{text, bindings}, referrer}, memo, meta, state, &c} |
| 22:59 | <littledan> | The thing is, Module (and maybe also ModuleSource) also may need to close over the import map |
| 23:00 | <littledan> | Ah yes Nicolo and I have been talking about where memoization happens… also confusing |
| 23:00 | <Kris Kowal> | I think there are coherent stances on module blocks where Module instances have [[HostData]] that leads back to the host’s module map, as would be necessary to mitigate certain configuration errors, but also coherent stances where it does not. |
| 23:01 | <Kris Kowal> | But, ModuleSource should just close over source. I’m open to adding layers and moving state around, but it would be not good to have state with the source. |
| 23:01 | <littledan> | My intuition is that module blocks and module reflection probably give you the same thing. They both need a referrer, and module reflection needs multiple instantiation (which is optional for module blocks IMO) |
| 23:02 | <Kris Kowal> | Interesting. |
| 23:02 | <littledan> | But, |
| 23:02 | <Kris Kowal> | WebAssembly.Module definitely maps to ModuleSource. Those do not have referrers. |
| 23:03 | <littledan> | Guy’s proposal definitely returns something with a referrer for Wasm |
| 23:03 | <littledan> | Otherwise csp doesn’t work |
| 23:03 | <Kris Kowal> | But I agree there might be an intermediate, or that Module in its initial state can serve as the intermediate. |
| 23:03 | <Kris Kowal> | Guy’s position is consistent with annotating module sources with origin information in their host data. |
| 23:04 | <littledan> | I think we could say, WebAssembly.Module has a new internal slot, which might be empty, which is the referrer |
| 23:04 | <littledan> | And we can apply this to ModuleSource generally, or make it a separate class if needed |
| 23:04 | <littledan> | Doe’s ModuleSource have host data? |
| 23:05 | <Kris Kowal> | I would like to think of CSP origin as orthogonal to referrer. |
| 23:06 | <Kris Kowal> | My mental model at the moment is that ModuleSource instances have an internal slot [[ModuleSource]] for an abstract Module Source. |
| 23:06 | <Kris Kowal> | More than a mental model, I should say, that made it into my current PR. |
| 23:07 | <littledan> | In general, I think it would be nice if import module gave you something you could do import() on. This requires a referrer. Otoh a core goal of Guy’s proposal is that import module gives you something which can be multiply instantiated |
| 23:07 | <Kris Kowal> | 262 needs to mention referrer, but does not need to couple it to CSP. |
| 23:07 | <littledan> | So this means, a class which has a referrer but is not an instance, if we want to meet those goals |
| 23:08 | <littledan> | Referrer is sufficient for csp, and necessary for other reasons |
| 23:08 | <littledan> | I don’t mind thinking of that as coincidental |
| 23:08 | <Kris Kowal> | Referrer on Module is sufficient, and referrer on ModuleSource is not necessary. |
| 23:08 | <littledan> | I explained a separate reason why it is necessary above |
| 23:08 | <Kris Kowal> | Though origin on ModuleSource is necessary for CSP. |
| 23:09 | <Kris Kowal> | I would like to think of these as different even if coincidental. |
| 23:09 | <littledan> | Sure |
| 23:09 | <Kris Kowal> | Going back to your conversation with Guy… |
| 23:10 | <Kris Kowal> | I think all motivating cases are handled if Module captures a referrer and if there’s a way to obtain a Module in an uninitialized state. That’s the deferred execution proposal. |
| 23:11 | <Kris Kowal> | And I’m open to deferred execution subsuming import reflection to that end. |
| 23:11 | <littledan> | It would be pretty cool if these could be unified somehow |
| 23:11 | <littledan> | And I think giving it an instance which has a referrer but no instance would do it |
| 23:11 | <Kris Kowal> | If import module x from 'x.wasm' came up as a Module: |
| 23:13 | <Kris Kowal> |
|
| 23:14 | <Kris Kowal> | Notably, in the multiple instantiation case, referrer can and must be differentiated from source.[[HostData]].[[Origin]]. Spoofing origin is no-go. |
| 23:15 | <Kris Kowal> | That’s me convincing myself that referrer and origin may coincidentally be the same value, but must be orthogonal. |
| 23:16 | <Kris Kowal> | Similarly, new ModuleSource(text) from a trusted type can also produce a Module Source Record with an associated [[Origin]]. |
| 23:43 | <Kris Kowal> | Would someone here kindly verify that they can open this slide deck link? https://drive.google.com/file/d/1NJWRBZJBP25uoyLXYDQVU5uG7YVZD4M9/view?usp=sharing |
| 23:55 | <littledan> | Yes I can open it |
| 23:55 | <Kris Kowal> | I’ll get them added to the agenda. |
| 23:55 | <littledan> | I am fine with considering csp layered to be orthogonal to referrer but it really is two copies of the same information. Csp can be more specific about paths than just origin |
| 23:56 | <Kris Kowal> | I think they’re not necessarily the same since referrer can be virtualized but origin cannot. |
| 23:56 | <littledan> | And the idea of TT is because it is too hard to apply that specific of a csp policy |
| 23:56 | <littledan> | Oh! Ok |
| 23:56 | <littledan> | When is referrer virtualized? |
| 23:56 | <littledan> | I guess import maps? |
| 23:57 | <Kris Kowal> | Whenever you construct a Module, you may choose any referrer. |
| 23:57 | <Kris Kowal> | Up to an including { importMeta: { url: "💩" } } |
| 23:58 | <Kris Kowal> | Or rather, assuming a new referrer argument, new Module(originalSource, "🤥", { etc }). |
| 23:59 | <Kris Kowal> | In which case the originalSource would have an associated origin by which CSP would be enforced, but a referrer that need only be useful to the extent that you can use it to resolve an importSpecifier in an importHook. |