| 05:00 | <yhirano> | annevk: In that case this problem is not specific to cross-origin, not specific to navigation and not specific to "manual" redirect mode. |
| 05:03 | <yhirano> | annevk: const res = fetch(url, {mode: 'same-origin', redirect: 'follow'}) |
| 05:03 | <annevk> | yhirano: I'm not sure I follow, but yeah, maybe, really depends on how redirects work which may well vary across engines |
| 05:05 | <yhirano> | annevk: if the fetch is initiated on a COEP enabled environment and experienced redirects, having the redirect information in the dom process would be problematic from your POV, right? |
| 05:07 | <annevk> | yhirano: in general I'd consider it problematic, but yes |
| 05:37 | <yhirano> | annevk: thanks, I commented at the bug. |
| 07:03 | <annevk> | yhirano: somewhat surprised you handle redirects in that process |
| 07:04 | <annevk> | yhirano: we might have something similar atm though due to extensions and maybe CSP |
| 07:04 | <yhirano> | annevk: for subresources we do that (and that was why we could implement CORS in the renderer processes) |
| 07:05 | <annevk> | yhirano: you mean out of? |
| 07:09 | <yhirano> | annevk: redirect is partially handled in the network process, but the network process ask the renderer process if it would follow the redirect. The legacy CORS implementation lives in the renderer process and cancels the redirect if the CORS check fails. The new CORS implementation is implemented in the network process. Is that clear? |
| 07:16 | <annevk> | yhirano: yeah, thanks; I think that does mean that long term it's not that infeasible for redirects to be handled completely in the networking process |
| 07:17 | <annevk> | yhirano: and maybe that also means there's nothing much to do for COEP |
| 08:43 | <smaug____> | What is uncustomized in https://html.spec.whatwg.org/#upgrades about? |
| 08:43 | <smaug____> | I can't see that elsewhere in the spec |
| 09:45 | <MikeSmith> | smaug____: looks like Domenic added that a few weeks ago in https://github.com/whatwg/html/commit/2793ee4a461c6c39896395f1a45c269ea820c47e |
| 09:45 | <MikeSmith> | and background is at https://github.com/whatwg/html/pull/5126 and at https://github.com/whatwg/html/issues/5118 |
| 10:05 | <mkwst> | annevk yhirano: Chromium currently does more checks in the renderer process than I think we want to do. It hasn't yet been worth the trouble to move, for example, CSP and MIX redirect checks out of the renderer and into the browser process. Ideally, we'd be verifying all of that the way that it's specified (e.g. the innards of Fetch => browser process). |
| 10:06 | <mkwst> | At the moment, we have been focusing on the bigger problems (e.g. CORS), but I imagine we will get to the rest of the checks over time. |
| 10:06 | <mkwst> | As annevk notes, I don't think the COEP spec would need to change for us to do that. |
| 11:22 | <annevk> | mkwst: the main impact on COEP is whether people should be able to hold an opaque-redirect response |
| 11:22 | <annevk> | mkwst: for opaque responses we've made some adjustments to the cache API and such, but these don't directly apply to opaque-redirect responses as those can be same-origin as well |
| 11:22 | <annevk> | (I guess they do apply to cross-origin redirects at least, but that doesn't address all vectors) |
| 11:23 | <mkwst> | annevk: Do opaque-redirect responses come up anywhere other than navigation? |
| 11:24 | <annevk> | mkwst: you can get one via fetch() |
| 11:24 | <annevk> | mkwst: iirc |
| 11:24 | <annevk> | mkwst: and definitely with fetch() in a service worker |
| 11:24 | <mkwst> | annevk: Hrm. Maybe we could not do that instead of doing it? |
| 11:25 | <mkwst> | I thought that was just an internal bit of the navigation algorithm. It surprises me a little that we expose it via `fetch()`. |
| 11:25 | <annevk> | mkwst: well, we need to support navigation from service workers |
| 11:25 | <annevk> | mkwst: including their redirect handling |
| 11:26 | <annevk> | mkwst: I'm less clear on the remainder |
| 11:28 | <mkwst> | annevk: Yes. It makes sense that it could be visible to SW, I just didn't think about it that way. In my head we gave the SW a crack at the initial request, and somehow magically jumped back to the HTML algorithm for the rest. |
| 11:29 | <yhirano> | annevk: I'm still not sure what part of the problem is navigation specific (or, opaque-redirect specific). |
| 11:29 | <mkwst> | yhirano, annevk: Yeah, it doesn't initially seem to me that there's much difference between an opaque-redirect response and an opaque response more generally. |
| 11:49 | <annevk> | mkwst: yhirano: an opaque response is always cross-origin from you |
| 11:49 | <annevk> | mkwst: yhirano: an opaque-redirect response is not and therefore might not have CORP |
| 11:49 | <annevk> | mkwst: yhirano: does that help? |
| 11:51 | <yhirano> | annevk: mkwst: how about followed same-origin redirect? |
| 12:28 | <annevk> | yhirano: what do you mean? |
| 12:30 | <yhirano> | annevk: https://github.com/whatwg/html/issues/5223#issuecomment-579087618 |
| 12:32 | <MikeSmith> | about the CSS Shepherd tool, does anybody know what the set of specs is that the indexes? |
| 12:33 | <annevk> | yhirano: that doesn't yield an opaque-redirect response though |
| 12:33 | <annevk> | yhirano: if it's followed it doesn't really matter as it doesn't have to be observable (assuming a better architecture will eventually be in place as per earlier comments) |
| 12:50 | <yhirano> | annevk: hmm... with that assumption forbidding redirect: 'manual' for non-navigation requests may help future implementers. |
| 12:56 | <annevk> | yhirano: yeah, or only inside COEP as a start (though it seems hard to restrict in that way) |
| 15:07 | <Domenic> | smaug____: https://dom.spec.whatwg.org/#concept-element-custom-element-state |
| 15:07 | <smaug____> | ah, DOM |
| 15:07 | <smaug____> | thanks |