| 01:19 | <Justin Martin> | Is there any mechanism to enforce subresource integrity upon a document, such that one can know that a document-like entity (e.g. an iframe or Document object) was initialized from a resource with a given content hash? |
| 05:16 | <annevk> | Justin Martin: no and no plans for that either at this point that I know of |
| 15:37 | <annevk> | Domenic: to be clear, I agree that ideally <link rel=preload> does not do type-specific fetching, but how is it not a layering violation for fetch() to act on Link headers? At that point it would no longer be the lowest-level primitive we could offer. Definitely seems counter to its design goals. |
| 15:38 | <Domenic> | fetch() is already not the lowest-level primitive; it builds on top of HTTP which has a bunch of header-triggered behaviors (including further fetches), like Location, CORS, etc. |
| 15:39 | <Domenic> | Link being another one of those seems reasonable to me; there's a bit of an IETF/WHATWG mess where IETF doesn't have the toolbox to specify Link caches in proper detail but that's fine, we can do it. |
| 15:39 | <Domenic> | (We already have to specify things like Location redirect limits) |
| 15:40 | <annevk> | The Link header is not part of HTTP proper though, Location is. |
| 15:40 | <Domenic> | I think that's just a SDO split and does not reflect any interesting architecture |
| 15:41 | <annevk> | It's the same SDO and that SDO has pulled in headers that are part of the core HTTP architecture into HTTP, so I'm not really sure you understand the setup... |
| 15:41 | <Domenic> | I think I understand the IETF's desired setup. I don't think it matches how the web actually works in browsers. |
| 15:41 | <Domenic> | Or how it is experienced by web developers |
| 15:42 | <Domenic> | I don't think any web developer thinks of Link and Location and X-Content-Type-Options and Access-Control-Allow-Origin as on different layers of the stack. |
| 15:42 | <Domenic> | And I don't think they should have to |
| 15:42 | <Domenic> | And I don't think that reflects any implementation split (in web browsers at least) |
| 15:43 | <annevk> | Web browsers actually have that kind of split quite a bit (and match Fetch far less than would be ideal) |
| 15:44 | <Domenic> | That is not my understanding of the Chromium and Gecko codebases. |
| 15:44 | <annevk> | I agree that web developers might perceive things differently |
| 15:44 | <Domenic> | The main split there is renderer vs. browser/network processes |
| 15:44 | <Domenic> | And that largely has to do with whether stuff should or needs to be accessible to the main thread |
| 15:45 | <Domenic> | E.g. ACAO (Fetch-level, not HTTP-level) stays in the network stack, and this helps against Spectre defenses. |
| 15:45 | <annevk> | Both Chrome and Gecko wrap network code with a bunch of Fetch thingies |
| 15:46 | <Domenic> | Yep, but their headers are implemented all over the place, e.g. a lot of stuff supposedly in Fetch is in the network code. |
| 15:46 | <Domenic> | The layering is not based on specs, it's based on security mostly. |
| 15:46 | <annevk> | And some of it has shifted over time, that's fair, but I don't think browsers necessarily represent an ideal architecture either 🙂 |
| 15:47 | <Domenic> | For sure, I don't think there is a single ideal architecture, it depends on your goals. Security vs. aligning with web developer expectations vs. writing well-factored specs across SDO boundaries are all different goals. |
| 15:47 | <annevk> | It'd be interesting to know if web developers expect Link headers to take effect when you use fetch() |
| 15:48 | <Domenic> | +1 |
| 15:48 | <annevk> | I suspect they wouldn't expect that when using it in Deno or Node.js and I kinda doubt they expect it from browsers, but who knows |
| 15:48 | <Luca Casonato> | +1 |
| 15:48 | <Domenic> | Deno has some similar stuff for import(), but yeah I dunno about fetch(). |
| 15:49 | <Domenic> | (It'll auto-fetch types based on certain headers.) |
| 15:49 | <Luca Casonato> | What would Link headers in fetch even do? |
| 15:49 | <Domenic> | preload and preconnect |
| 15:49 | <Luca Casonato> | ah |
| 15:49 | <Domenic> | and modulepreload |
| 15:50 | <Luca Casonato> | (It'll auto-fetch types based on certain headers.) Location which redirects the current chain of fetches) |
| 15:51 | <Luca Casonato> | I think most devs expect fetch et al (low level network primitives) to be relatively stateless. Ie they don't go and trigger something to happen out of bounds that you can't really observe |
| 15:53 | <annevk> | (I also don't think that the layering in browsers is necessarily based on security. A lot of it is just "happened to be easy to do this way". There's some higher-level layering that's for security reasons, but a lot of the decisions within a single security "zone" are rather arbitrary. And sometimes confusing, with both the networking and application code parsing the same header.) |
| 15:55 | <Domenic> | I'll say that on Chromium parts the layering is extremely security-motivated; we have multiple year+ projects to move things between processes and parts of the codebase for security. |
| 15:55 | <Luca Casonato> | FWIW, i don't think fetch should respect preload or preconnect. it makes for very confusing debugging if a server can trigger an additional background fetch by just setting a header on the response imo |
| 15:55 | <Domenic> | Maybe that's just us though |
| 15:56 | <annevk> | Domenic: that's the higher-level layering |
| 15:57 | <Domenic> | I'm not sure how many "levels of layering" you have in mind, but I think we don't conceptualize the Chromium codebase that way at least :) |
| 15:58 | <annevk> | Domenic: a great many |
| 16:01 | <Luca Casonato> | No, we also maintain this split between privileged and unprivileged sides in Deno. But it's a really tricky thing for this networking stuff, because there are so many interconnected pieces that all operate on slightly different layers of the system. Any time any of these layers can have side effects, it makes for much much more complex implementation because then we may need to jump from deep inside of trusted code, back into untrusted code. |
| 16:49 | <annevk> | Luca Casonato: for the multipart issue, Domenic was playing with multipart/x-mixed-replace; from your response it seems you are not? |
| 16:50 | <annevk> | (Context: https://github.com/whatwg/fetch/issues/1021.) |
| 16:51 | <Domenic> | Yeah, multipart/form-data is extremely different from multipart/x-mixed-replace |
| 16:52 | <Domenic> | Also I don't see why we would close the issue? We didn't satisfy the feature request of adding a native TransformStream for multipart responses... |
| 17:19 | <TabAtkins> | I don't think any web developer thinks of Link and Location and X-Content-Type-Options and Access-Control-Allow-Origin as on different layers of the stack. |
| 17:20 | <legostarwars_saga> | hello |
| 17:52 | <Luca Casonato> | Domenic annevk my bad. I only skimmed over the issue. Disregard my comment. |
| 18:03 | <TabAtkins> | What is the purpose of the "type name" thing in WebIDL? Afaict it's not used anywhere in the spec; the only references to it are things defining what their type names are. Is this just some weird legacy thing dating back to when WebIDL pretended it was useful for Java, and we've kept it going out of inertia? |
| 18:12 | <annevk> | TabAtkins: blame points to https://github.com/whatwg/webidl/commit/8e66595d495b40d05c9926fbd01b0fa0be5ecb6a, but I wasn't able to figure it out based on that (perhaps there's some corresponding email or some such) |
| 18:14 | <TabAtkins> | thanks for tracking it down, I agree that the commit doesn't provide enough context. I'll ping @heycam, thanks! |
| 18:16 | <TabAtkins> | Oohhhhhhh, it was used for the old T[] syntax that produced Array subclasses; it would name the subclass accordingly. |
| 18:17 | <TabAtkins> | Its' the final mention of the term "type name" in that commit. |
| 18:17 | <TabAtkins> | okay, opening a bug to discuss removing it |