| 12:26 | <annevk> | mkwst: hey, are you around? |
| 12:26 | <annevk> | mkwst: if so, I'm wondering about CORS and navigations a bit |
| 12:27 | <annevk> | mkwst: and https://wicg.github.io/cors-rfc1918/ might do some of that I guess |
| 12:30 | <annevk> | mkwst: but I'm not entirely convinced it handles enough of the details, esp for navigations |
| 12:31 | <annevk> | mkwst: or maybe the plan at this point is to wait for Origin Policy/Manifest, which would make this simpler? |
| 13:01 | <mkwst> | Hi. I'm kinda around! |
| 13:02 | <mkwst> | I'm 100% sure that that doc doesn't handle all the details. It's old and sketchy and hasn't gotten enough review because we collectively haven't been spending time on it. |
| 13:02 | <mkwst> | What details are you interested in, in particular? |
| 13:02 | <mkwst> | ^^ annevk |
| 13:04 | <annevk> | mkwst: I'm wondering how difficult it is to patch navigation to use CORS, in a way that also makes sense for service workers, etc. |
| 13:05 | <annevk> | mkwst: and I guess a little bit about what it would mean; it'd definitely not impact WindowProxy security checks for instance, so it's mostly about whether you maybe get to be in the same process |
| 13:06 | <annevk> | mkwst: (this might be interesting for Chrome on Android I suspect) |
| 13:07 | <annevk> | mkwst: it seems you mostly tried to patch this entirely on Fetch's side, and maybe that works, I guess I should see if that does the right thing for redirects and if it does it's probably okay |
| 13:07 | <mkwst> | Hrm. I worry a bit about CORS becoming a gateway to process isolation, because I'm not actually sure it's a good thing for folks to open up cross-origin access to their resources more generally. |
| 13:08 | <mkwst> | When I last looked at this in detail (2016?), it made sense to do all the work in Fetch. |
| 13:08 | <mkwst> | But the navigation algorithm has evolved since then. Some of the work might need to move to HTML for CORS-RFC1918 in particular. |
| 13:09 | <mkwst> | That model might work for process isolation as well, as it's really concerned with passing the _preflight_, not the actual resource response. |
| 13:09 | <mkwst> | Which means that the actual response value doesn't have to be opened up cross-origin. The server just needs to grant access to ask for the thing in the way it's being asked for. |
| 13:10 | <annevk> | mkwst: yeah, it might be that a simple flag is sufficient, but then the question is whether redirects can taint such a flag or not |
| 13:11 | <annevk> | mkwst: I hope redirects properly taint sec-metadata, I haven't really looked at how that works |
| 13:12 | <mkwst> | annevk: sec-metadata recalculates the value on each pass through fetch. |
| 13:12 | <mkwst> | At least, that's what I remember writing down. |
| 13:13 | <annevk> | mkwst: so A -> A' -> B -> A means same-site, cross-site, cross-site? |
| 13:13 | <annevk> | And in particular if there's another -> A it remains cross-site? |
| 13:14 | <mkwst> | Yes. See https://mikewest.github.io/sec-metadata/#abstract-opdef-set-the-sec-metadata-header-for-a-request and https://mikewest.github.io/sec-metadata/#abstract-opdef-obtain-the-site-value. |
| 13:14 | <mkwst> | The latter walks the whole URL list, with the intent of keeping the `cross-site` taint once anything in the redirect chain is cross-site. |
| 13:15 | <annevk> | cool |
| 13:15 | <mkwst> | I haven't shipped it in Chrome yet mostly because of bugs in that redirect code that I haven't had time to fix. |
| 13:15 | <mkwst> | And because it apparently broke Switzerland. |
| 13:15 | <annevk> | Anyway, that kind of thing but for response headers is more involved and often done wrong (e.g., see Timing-Allow-Origin) |
| 13:15 | <annevk> | I guess it's involved for request headers too then, lol |
| 13:16 | <annevk> | Redirects... |
| 13:16 | <annevk> | Firefox still has bugs with Origin too around this kind of logic |
| 13:16 | <mkwst> | (We have tests (that Chrome's currently failing) at https://wpt.fyi/results/fetch/sec-metadata/redirect?label=experimental) |
| 13:17 | <mkwst> | I can imagine that kind of bug being common. It's easy to forget redirects when specifying things like TAO. |
| 13:17 | <annevk> | I did try to encourage them to carefully study CORS when doing that, but... |
| 13:19 | <annevk> | There's some brokenness in this model too though in that for <iframe> and I think <img> cross-origin -> same-origin does end up meaning same-origin, but for fetch() it doesn't (and I suspect that in particular for <img> the spec might be wrong) |
| 13:19 | <annevk> | Anyway, maybe CORS-like stuff for navigations is more doable than I thought |