| 04:59 | <yhirano> | annevk: Do you have any opinions on the last comment of https://github.com/whatwg/fetch/issues/966? |
| 08:17 | <annevk> | yhirano: it seems fine to me, I wonder if we really need 2, but I guess theoretically it could be an attack vector so maybe that's good; I kinda prefer requiring h2 over that, but can live with provided there's solid test coverage |
| 08:22 | <yhirano> | annevk: Thanks. I'm not fully sure about the need for the new header too, but I think the new header is less confusing than requiring h2. |
| 08:26 | <annevk> | yhirano: who suggested the new header? Security team? |
| 08:27 | <annevk> | yhirano: are we effectively looking at two new headers or do we only want the preflight response to advertize it, similar to Access-Contor-Allow-Credentials? |
| 08:27 | <annevk> | yhirano: Access-Control-Allow-Streams: true? |
| 08:28 | <yhirano> | annevk: none. I thought some participants wanted to restrict the feature for H2, which seemed unfortunate to me. |
| 08:29 | <yhirano> | annevk: If everyone agrees that the secure context restriction is enough, I'm happy to retract the new header. |
| 08:31 | <yhirano> | annevk: I'm fine with both (having one header on response, or having headers on both req and res). Maybe only on response is enough? |
| 08:35 | <annevk> | yhirano: so the main reason to restrict to h2 is to avoid imposing new impl requirements on browsers with regards to chunked encoding |
| 08:35 | <annevk> | yhirano: might be sunk cost for Chrome, but not sure that's the case for all involved, I thought it wasn't for Firefox |
| 08:36 | <annevk> | yhirano: I hadn't considered that sending chunked encoding itself to a different origin is in effect a new attack vector, but given the required CORS preflight I'm kinda okay with not requiring an additional opt-in for that, especially as it's a normal HTTP request in pretty much all respects, except for not listing Content-Length |
| 08:39 | <yhirano> | annevk: Does @ddragana know Firefox's status for chunked encoding? |
| 08:44 | <annevk> | yhirano: she would know for sure, yes, I can ask again |
| 09:06 | <yhirano> | annevk: Thank you. I'll add a comment on the thread. |
| 09:06 | <annevk> | yhirano: so |
| 09:07 | <annevk> | yhirano: we don't have it, but adding it is doable |
| 09:07 | <annevk> | yhirano: secure contexts is a must though |
| 09:07 | <yhirano> | annevk: My understanding is: |
| 09:07 | <yhirano> | annevk: secure context is a must-have |
| 09:08 | <yhirano> | annevk: requiring h2 may be good for some user agents from implementation cost PoV, but at least one web dev expressed a concern from usability PoV |
| 09:08 | <yhirano> | annevk: adding a new header may be good from security PoV |
| 09:09 | annevk | nods |
| 09:09 | <annevk> | Though, I'm okay with saying that the existing CORS preflight is sufficient here |
| 11:55 | <annevk> | littledan: heya, who would be best to ask questions about WebAssembly.Module? |
| 11:55 | <littledan> | annevk: I can answer some, also Ms2ger and Luke |
| 11:56 | <annevk> | littledan: I don't really understand how it's similar to SharedArrayBuffer, since it always copies the input bytes |
| 11:57 | <annevk> | littledan: and it doesn't even accept SharedArrayBuffer as an argument currently |
| 11:57 | <littledan> | yeah... I wasn't around when they made that decision. I believe it was so that it can be processed asynchronously, but I don't know why they didn't detach it instead |
| 11:57 | <littledan> | I don't see why it couldn't accept a SAB, but I also don't understand the use case. I thought we were adding SAB support on a case-by-case basis when we were confident? |
| 11:58 | <littledan> | the copy is created eagerly and then the compilation may happen in the background |
| 11:58 | <littledan> | annevk: Are there any issues with the wording of the copy? |
| 11:58 | <annevk> | littledan: maybe since they don't actually want to recompile? |
| 11:58 | <littledan> | well, yeah, if it were a live, changing thing and expected to reflect that, that'd be pretty unworkable... |
| 11:59 | <annevk> | littledan: the specification is clear, I'm trying to understand the space in light of the changes we're making around SharedArrayBuffer serialization |
| 11:59 | <littledan> | do you have a reference for that? |
| 12:00 | <annevk> | littledan: no, in a discussion with lth that came up, that maybe folks don't want to compile again and therefore don't want to allow messaging these things out of a process |
| 12:00 | <littledan> | oh, there was a separate thing about serializing modules |
| 12:01 | <littledan> | but some folks were saying they *would* want to recompile |
| 12:01 | <annevk> | okay |
| 12:01 | <annevk> | (Your understanding about allowing SharedArrayBuffer is correct btw, we'll gradually sprinkle [AllowShared] all over the place.) |
| 12:02 | <littledan> | serializing modules is supported, see https://webassembly.github.io/spec/web-api/index.html#serialization |
| 12:02 | <littledan> | not to storage, though (although that was originally planned) |
| 12:02 | <littledan> | modules are much nicer than SAB here since the code can't mutate. Also, they've already had an async compile step |
| 12:03 | <annevk> | I guess the real question is, should serializing these modules only work when serializing SAB works? |
| 12:03 | <littledan> | I'm not sure what implementations do, whether they actually recompile or not. My memory was that, in the beginning, more folks than I expected were actually just serializing the Wasm bytecode |
| 12:04 | <annevk> | I'll email you and Luke as a start if that's okay. |
| 12:04 | <littledan> | hmm, I can imagine the reason for this restriction, yes |
| 12:04 | <littledan> | if one origin's process is totally hosed, then you might not trust it to compile things |
| 12:04 | <littledan> | OTOH, the browser could just decide to fall back to sharing the bytecode when going across sites |
| 12:05 | <littledan> | this would make it more of a performance cliff than a security hole |
| 12:05 | <littledan> | (Ms2ger would be a good person to cc in any email) |
| 12:05 | <annevk> | Going across processes will always be a cliff of sorts I suspect (unless we make everything slower) |
| 12:05 | <annevk> | Okay |
| 12:06 | <annevk> | I'll copy Ms2ger on all my emails from now |
| 12:06 | <annevk> | on |
| 12:06 | <littledan> | yeah, this makes sense. I suspect there's no restriction needed here |
| 12:06 | <Ms2ger> | \o/ |
| 12:11 | <annevk> | littledan: Ms2ger: ah, I think a thing I was missing is https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#javascript-api-changes |
| 12:12 | <annevk> | littledan: Ms2ger: that would certainly be a type of WebAssembly.Module type that needs similar restrictions |
| 12:13 | <littledan> | isn't this implicit in WebIDL? |
| 12:13 | <littledan> | err sorry I misread |
| 12:14 | <littledan> | I don't see why we need this sort of option for WebAssembly.Module |
| 12:14 | <littledan> | it's a bit backwards: Memory actually *creates* a SAB. Whereas Module's constructor consumes one |
| 12:15 | <annevk> | Oh wait, that's WebAssembly.Memory |
| 12:15 | <littledan> | I think we can just rely on WebIDL to check that no SAB is passed in, and then the result is always copied and sharable |
| 12:15 | <annevk> | Can WebAssembly.Memory be serialized? |
| 12:15 | <littledan> | (and this is the current specified semantics IIRC) |
| 12:15 | <annevk> | Well currently it's restricted to be shared within an agent cluster |
| 12:15 | <annevk> | And cannot be serialized to disk despite mostly being bytes |
| 12:17 | <littledan> | right, we had a whole debate about serializing WebAssembly.Module to storage. IMO it only makes sense if people will actually store the compilation output, but this has all sorts of cases where it gets invalidated. Better to just store the bytecode and have good caching |
| 12:17 | <littledan> | (it's a high-level, unreliable API, but IndexedDB support would've been as well, given all the cases where it would disappear) |
| 12:17 | <littledan> | also it seemed like some engines were just going to store the bytecode anyway, when you serialize WebAssembly.Module, which defeats the whole purpose |
| 12:19 | <littledan> | Here's the spec for serializing WebAssembly.Memory. It does what you'd probably expect https://github.com/WebAssembly/threads/blob/master/document/web-api/index.bs#L146 |
| 12:20 | <littledan> | (looks like I wrote that) |
| 12:22 | <annevk> | littledan: I see, so, you can create Memory from any kind of BufferSource, but you can only serialize if that BufferSource was SAB |
| 12:22 | <annevk> | littledan: and then when you serialize, all SAB serialization restrictions automatically apply |
| 12:23 | <littledan> | you can create a Module from any BufferSource, but the Memory constructor allocates the underlying ArrayBuffer |
| 12:25 | <littledan> | when you use the "shared" option for Memory, it creates an SAB internally (which you can easily access), and that is subject to those serialization restrictions |
| 12:25 | <littledan> | thanks for this review, btw |
| 12:25 | <annevk> | littledan: okay, so you create Memory and based on options it either creates AB or SAB (I might not call the internal slot BufferSource in that case) |
| 12:26 | <annevk> | I guess what WebAssembly.Module does doesn't matter so much then, indeed |
| 12:27 | <annevk> | As by itself it's not an attack vector and the process isolation seems to be driven by non-security reasons |
| 13:18 | <littledan> | annevk: Yeah, that's how I see it |
| 13:20 | <annevk> | Cool, I'm glad this is layered even better than I expected and I think I mostly misunderstood WebAssembly.Module since I didn't know about the plans around WebAssembly.Memory |
| 15:59 | <annevk> | nox: I'm looking at what's remaining of your script insertion work |
| 15:59 | <nox> | annevk: Remaining? |
| 15:59 | <nox> | Parts landed? :O |
| 16:00 | <annevk> | nox: I think I have a slightly better handle on what I want out of it so maybe I can try to drive it to a conclusion |
| 16:00 | <annevk> | nox: and also get Apple to weigh in |
| 16:00 | <nox> | annevk: Nice. Sorry for dropping the ball. |
| 16:00 | <annevk> | nox: I really appreciate all the work you put into it thus far, looking over it again it seems we were extremely close |
| 16:01 | <annevk> | or are, really |
| 16:01 | <nox> | Thanks! |
| 16:44 | <annevk> | nox: so yeah, now I'm at what kind of mutation records should normalize() generate |
| 16:44 | <annevk> | nox: meh |
| 16:45 | <annevk> | but, progress |
| 16:49 | <annevk> | Maybe it's not quite that bad |
| 16:54 | <nox> | annevk: Famous last words. :P |
| 16:58 | <nox> | annevk: Took a day off to go protest against pension system reform today, so I'll look at your PR tomorrow. :) |
| 16:59 | <annevk> | nox: 👍🏻 |
| 17:30 | <jugglinmike> | annevk / Domenic: by my reading, the `crossorigin` attribute for `<script>` only affects classic scripts, not modules. Does that sound right to you? |
| 17:31 | <annevk> | jugglinmike: hmm, doesn't crossorigin=use-credentials have an effect? |
| 17:32 | <Domenic> | ^ that |
| 17:33 | <jugglinmike> | oh, let's see |
| 17:33 | <jugglinmike> | I |
| 17:35 | <annevk> | also, not sure empty string counts as a state |
| 17:35 | <jugglinmike> | ah, I see it now: https://html.spec.whatwg.org/#set-up-the-module-script-request |
| 17:36 | <jugglinmike> | sorry, I was thrown off by 'mode is "cors"' in https://html.spec.whatwg.org/#fetch-a-single-module-script |
| 17:38 | <jugglinmike> | oh, no. "credentials mode" is not "mode" |
| 17:40 | <annevk> | Correct, they're distinct |
| 17:43 | <jugglinmike> | Okay, so `crossorigin` affects the "mode" of the request for a classic script and the "credentials mode" of the request for module scripts |
| 17:43 | <annevk> | It affects both for classic scripts |
| 17:44 | <annevk> | It doesn't affect mode for module scripts |
| 17:45 | <jugglinmike> | via https://html.spec.whatwg.org/#set-up-the-classic-script-request |
| 17:45 | <jugglinmike> | I think I get it, now. Thanks for the help :) |
| 17:45 | <annevk> | 👍🏻 |