| 18:54 | <guybedford> | I've posted up a draft HTML PR for ESM Phase Imports in https://github.com/whatwg/html/pull/11152 |
| 18:54 | <guybedford> | feedback very welcome! |
| 22:19 | <bakkot> | guybedford: I haven't been following closely; can you give an example of how one would obtain an unrooted module in the current world? |
| 22:19 | <bakkot> | (i.e. in the world without module {} syntax) |
| 22:20 | <bakkot> | I guess just the ModuleSource constructor? |
| 22:21 | <bakkot> | I forget if we were exposing that or not |
| 22:23 | <bakkot> | oh and WebAssembly.compile I guess |
| 22:34 | <bakkot> | unrelated, has there been any discussion of Trusted Types integration? |
| 22:35 | <bakkot> | right now there's TrustedScript; presumably there would need to be TrustedModuleSource or something? Kinda of annoying but not terrible I guess |
| 23:07 | <guybedford> | yes just via new WebAssembly.Module(bytes) today and in future perhaps either new ModuleSource('source') or eval('module { }'). |
| 23:08 | <guybedford> | For the most part I think rooted modules are trusted in the sense that they are known to originate from their URL and origin with CSP / integrity checks as appropriate |
| 23:08 | <guybedford> | I'm hopeful that security model might be possible to develop further |
| 23:08 | <guybedford> | (all rooted sources as trusted sources) |
| 23:12 | <bakkot> | Trusted Types is specifically a mechanism for getting from untrusted values to values which can be used in contexts which require trust (that is, which pass CSP) |
| 23:13 | <bakkot> | so the relevant thing here would be a way to take an unrooted source and get something usable in a CSP context |
| 23:13 | <guybedford> | Right, but Trust Types are sink protections for user sources. But module sources are trusted sources, therefore do not require sink protection. |
| 23:13 | <bakkot> | for rooted module sources, yes |
| 23:13 | <nicolo-ribaudo> | I'm thinking that you would need a TrustedScript as an argument to a potential ModuleSource constructor |
| 23:13 | <nicolo-ribaudo> | Similarly to how you need to pass a TrustedScript to Function |
| 23:14 | <nicolo-ribaudo> | And gate creation of Module sources, rather than their usage |
| 23:18 | <bakkot> | I was trying to figure out how this works for WASM but it's apparently unspecified, fun fun |
| 23:19 | <bakkot> | anyway empirically CSP blocks compilation to Module objects |
| 23:19 | <bakkot> | so probably it makes more sense for the trust gate to be on creation of Module objects, not on their use |
| 23:19 | <bakkot> | as nicolo-ribaudo suggests but not as currently specified, at least based on my reading of the description in the PR; correct me if I'm wrong |
| 23:20 | <bakkot> | https://github.com/WebAssembly/spec/issues/1393 is the wasm+csp issue incidentally |
| 23:20 | <bakkot> | man CSP is just the single worst web spec |
| 23:20 | <bakkot> | CSP and everything it touches |
| 23:20 | <guybedford> | Yes, that might well be the approach. Note also that module declarations nested arbitrarily deep in sources that bottom out as rooted sources are still also themselves rooted sources. Yes Wasm might even benefit from its own trusted types support for WebAssembly compile. Note that source phase integration for Wasm already unified Wasm CSP on script-src policy. |
| 23:21 | <bakkot> |
Did it? Where's that specified? |
| 23:21 | <guybedford> | In the HTML integration PR - https://github.com/whatwg/html/pull/10380 were a bunch of discussions in WhatWG about that |
| 23:24 | <bakkot> | I don't see any discussions of CSP in that thread or anything in the PR which touches CSP |
| 23:24 | <bakkot> | did you mean to link a different one? |
| 23:29 | <guybedford> | I believe there was a WhatNOT meeting to discuss it, we also discussed it considerably in the modules group and various threads. I don't know if there's an easy canonical resource to find on that. It comes down to using destination script for Wasm I believe. |
| 23:29 | <bakkot> | bleh |
| 23:31 | <bakkot> | I believe you that these discussions happened but it is a bad state of affairs when to know what a correct implementation is you have to have been at a specific meeting, rather being able to look at a specification |
| 23:34 | <guybedford> | I should actually just land https://github.com/WebAssembly/esm-integration/pull/78, it was previously blocked by Anne, but he later rescinded this and I never landed it. |
| 23:34 | <bakkot> | ah, nice! |
| 23:38 | <guybedford> | Merged, thanks for the ping |
| 23:39 | <bakkot> | I assume the intention is that worker modules are governed by worker-src? |
| 23:42 | <guybedford> | yes, exactly, since new Worker(mod) sets the worker URL from the module URL. Then there's some questions around transfer, similarly to the ones for WA.Module. Still not clear how postMessage works with CSP to me. |
| 23:44 | <shu> | the html integration PR for supporting new Worker(mod) isn't merged yet, is it? |
| 23:44 | <guybedford> | no, it's just a draft as I just posted up in https://matrix.to/#/!RkpmGMjJtqLKXzByOT:matrix.org/$vkBt_r3WpPEc-S4JjDQRQFswYCMmKKqSzNRZxH-Hw7k?via=matrix.org&via=igalia.com&via=mozilla.org |
| 23:45 | <shu> | okay, i'm just trying to take down AIs |
| 23:46 | <shu> | the CSP integration is unobservable until the HTML PR merges, yeah? |
| 23:46 | <shu> | or is it unrelated? |
| 23:46 | <guybedford> | for workers yes, for Wasm source phase already landed it's already integrated |
| 23:47 | <shu> | is there change needed to CSP implementations today for import source foo from "foo.wasm"? |
| 23:48 | <shu> | well, i guess "yes" to the extent that it needs to check script-src just like JS modules? |
| 23:51 | <shu> | yeah i have no idea what's actually needed here to ship. would appreciate a pointer to a spec draft / PR against CSP, though i hear CSP spec itself is a dumpster fire |
| 23:51 | <guybedford> | Yes, although it's a minor implementation detail in the fetch implementation - that the network request is the same that requests for JS or Wasm under script destination, then handling Wasm based on the content-type. |