| 19:46 | <Francisco Tolmasky> | I put this in TC39 delegates, but I think it might be more appropriate here: is the expectation that ShadowRealms should not share module graphs. That is to say, import { x } from "y", that x should have nothing in common from the same x imported from y in a parent realm -- but is the module resolution/caching/etc. also "reset" (or is that piece host dependent -- or does that potentially introduce a "side channel" for the ShadowRealm to determine if a module has been imported in the parent if it loads quickly)? |
| 20:05 | <ljharb> | if the cache is shared, then it wouldn't tell them about the parent, because it could have been loaded in a different shadowrealm |
| 20:22 | <nicolo-ribaudo> | They are two separate modules, similarly to what would happen if you load "y" in two different workers |
| 20:22 | <nicolo-ribaudo> | I'm not 100% sure that the proposal mandates that, but the HTML side of the modules algorithms does |
| 20:23 | <nicolo-ribaudo> | Specifically, the "module key" in ECMA-262 is (importer, specifier), and those two "y"s have different importers |
| 20:23 | <nicolo-ribaudo> | Oh actually, re-reading: yes, that introduces a timing side channel |
| 20:24 | <nicolo-ribaudo> | The JS value is separate, but the module source might have been pre-cached |
| 20:24 | <nicolo-ribaudo> | To make shadowrealms safe however, you have to disable timers regardless of this |
| 20:25 | <Francisco Tolmasky> | is "importer" synonymous with "loader", or is an importer different than a loader (by loader I mean (https://whatwg.github.io/loader/), or JSModuleLoader in JavaScriptCore |
| 20:25 | <nicolo-ribaudo> | It's the module that contains the import |
| 20:26 | <Francisco Tolmasky> | wait, but in that case moduleKey is different even in the same realm if two modules import the same thing, right? |
| 20:26 | <Francisco Tolmasky> | moduleKey is only ever the same if you literally import from the same module twice in the same file? |
| 20:28 | <nicolo-ribaudo> | Yes exactly, but hosts might use a normalised cache key for the web request |
| 20:28 | <nicolo-ribaudo> | For example, HTML uses the resolved URL |
| 20:28 | <Francisco Tolmasky> | I see |
| 20:29 | <nicolo-ribaudo> | We can only require that the cache key is at least as granular as (importer, specifier), but not that it's less granular |
| 20:30 | <Francisco Tolmasky> | I see, its just to gaurantee that splitting up your imports in a file doesn't have weird worse fetching side effects |
| 20:31 | <Francisco Tolmasky> | OK, so separately, the idea of @@translate in the whatwg loader spec, that is not at all surfaced from the importHook stuff, right? importHook is orthogonal to the fetch/resolve/translate steps defined there... Or like, only overlaps with resolve and fetch? |
| 22:04 | <Francisco Tolmasky> | Is there an official import.now proposal anywhere? I see references to it everywhere, but can't seem to find an actual place it's pinned down |