| 00:02 | <annevk> | smaug____: not sure to what extent, but it has a number of features everyone wants |
| 00:04 | <annevk> | littledan: how does importing Wasm work again? |
| 01:29 | <smaug____> | annevk: sure, but only one implementation. Perhaps the features should be exposed as lower level primitives. |
| 01:29 | <smaug____> | Just a random thought |
| 03:57 | <annevk> | Yeah, true |
| 05:02 | <Domenic> | I've advocated for removing it but Apple has supported keeping it for some time so we're at multi-implementer support... But that second support does not appear to be of the sort "we plan to implement this soon"... so I'm unsure. |
| 06:35 | <littledan> | annevk: It's based on the MIME type, just like JSON |
| 07:07 | <annevk> | littledan: I meant more in terms of capabilities. Does the Wasm just run or do you have to invoke something for it to run? |
| 07:08 | <littledan> | annevk: It just runs, like JavaScript. It invokes a "start function" |
| 07:09 | <littledan> | It can only import things from other modules, but those modules may give it access to globals |
| 07:10 | <littledan> | I was hoping that the get-originals proposal would give it access to everything, but I don't understand the landscape of who likes those kinds of proposals at the moment |
| 07:11 | <annevk> | If it can import a JS module the threat model seems equivalent |
| 07:11 | <annevk> | To JS modules |
| 15:45 | <littledan> | annevk: Someone might assume it's less powerful, if they hear about the Wasm sandbox and don't understand that module integration gives the power to import JS modules (unlike the JS API). I'm not sure if this makes it at all like JSON. |
| 22:41 | <annevk> | littledan: I don’t think it does. Going from data to code execution is bad as it’s not expected, but Wasm starts with code execution that’s equally capable |
| 23:04 | <littledan> | annevk: OK, seems reasonable to me, but I wonder what we will do to note module types explicitly. I don't remember when in TC39 we rejected adding syntax for this sort of thing. I am not sure we considered it. Maybe Domenic has more details. I would like to figure out how to enable JSON modules. |
| 23:05 | <littledan> | I just remember talking about things like SRI, but I think we can agree that this does not make as much sense inline, because of tree cache invalidation. |
| 23:20 | <annevk> | littledan: agreed, though not having a solution for SRI at all is bad and arguably a step backward |
| 23:21 | <annevk> | littledan: might also lead to non-adoption depending on your threat model |
| 23:23 | <littledan> | Yeah, I think if we make a clear proposal to TC39 for this, it could work. I only remember a TC39 presentation encouraging us not to do this (IIRC for SRI) and some committee members agreed. We don't tend to resolve "we will never do this". So I think it's worth re-examining. |
| 23:24 | <littledan> | Annevk: Was there any concrete suggestion for the right way to include this data, either for SRI or JSON? |
| 23:25 | <littledan> | Do people want this to be inline in the JS? |
| 23:29 | <littledan> | I am not sure if there is some other proposal that would provide SRI that this would overlap with (signed exchange? It's been made clear that import maps would not have SRI information) |
| 23:33 | <annevk> | Import maps still seems like the most viable place |
| 23:51 | <annevk> | The downside is that you have to use import URLs for non-script resources, but that seems okayish |
| 23:53 | <annevk> | Or perhaps with some other opt-in we just route all URLs through this map |