| 02:51 | <sefeng> | Noam Rosenthal: I am fixing https://github.com/web-platform-tests/wpt/blob/cff0ff1898/resource-timing/SO-XO-SO-redirect-chain-tao.https.html#L56-L61 for Firefox. I wonder which redirect should cause the TAO check to fail? |
| 02:53 | <sefeng> | is it because the last redirect from cross-origin to same-origin? |
| 02:53 | <sefeng> | I am asking because in Firefox, the TAO check is done by always againsting the origin that started the load |
| 02:55 | <sefeng> | which is probably wrong I guess. I am still not familiar with the FETCH spec, is it supposed to be done by against the current origin? |
| 02:58 | <EveryOS> | Does emitting the token happen regardless of the previous if-otherwise? |
| 04:20 | <Noam Rosenthal> | sefeng: It's because the request's origin becomes redirect-tainted (https://fetch.spec.whatwg.org/#concept-request-tainted-origin), and the TAO check accesses that origin which is serialized to null (https://fetch.spec.whatwg.org/#ref-for-serializing-a-request-origin%E2%91%A0). This part is a bit hard to follow in the fetch spec IMO. |
| 06:56 | <annevk> | Andrew Williams: that's a very good question, I think it's closely related to https://github.com/whatwg/html/issues/5254 |
| 06:57 | <annevk> | Andrew Williams: my inclination would be yes, as the entire chain is HTTPS |
| 07:01 | <annevk> | It's somewhat unfortunate the entire world went with application/json rather than text/json. |
| 07:19 | <Ms2ger 💉💉> | Does emitting the token happen regardless of the previous if-otherwise? |
| 13:00 | <EveryOS> | Ok. Thank you! |
| 15:36 | <sefeng> | Noam Rosenthal: thanks. So say have a A->B->A redirect chains, when should the tainted origin returns true? |
| 15:36 | <sefeng> | the spec says If url’s origin is not same origin with lastURL’s origin and request’s origin is not same origin with lastURL’s origin, then return true |
| 15:38 | <sefeng> | I'd assume we want it to return true when doing thelast redirect, but doesn't last redirect which is A have the same origin as the lastURL's origin? |
| 15:38 | <sefeng> | at this point, url is B, lastURL is A, and request's origin is 'A' |
| 15:38 | <sefeng> | what do I miss? |
| 15:46 | <sefeng> | oh perhaps the URL list contains the last redirect already before doing the TAO check of the last redirect, so I can continue the loop to make lastURI=B, url=A and request=A? |
| 15:56 | <Noam Rosenthal> | sefeng: I don't remember exactly, but I think you can't make TAO succeed for redirect-tainted origins, even A->B->A, just like CORS can't. annevk / Yoav Weiss perhaps have more context about this |
| 16:01 | <annevk> | sefeng: in A -> B -> A, when this check happens request's URL list will contain [A, B, A] because otherwise it can't request the final A |
| 16:02 | <annevk> | The underlying security problem is https://en.wikipedia.org/wiki/Confused_deputy_problem |
| 16:03 | <annevk> | (I also have to re-read this algorithm each time to see if it works, if someone would be willing to add some examples underneath that'd be much appreciated!) |
| 18:06 | <Noam Rosenthal> | annevk: ok, so IIUC, for CORS it protects from CSRF amongst other things, where e.g. a POST to another site would redirect you to a different authenticated POST in the original site. And we added that limitation to TAO to align with CORS. The attack vector on TAO is a bit less clearer to me in this case but the alignment makes some sense. |
| 18:06 | <Noam Rosenthal> | sefeng: ^^ |
| 19:29 | <Eric Portis (he/him)> | A question someone has surely asked before... if I, a subresource host, have already granted cross-origin read access with Access-Control-Allow-Origin: *, why would I ever not want to grant embed access via Cross-Origin-Resource-Policy: cross-origin? |
| 19:31 | <Eric Portis (he/him)> | Which is to say, why do I have to set both? Why doesn't ACAO:* imply CORP:cross-origin? I get that it doesn't right now because ACAO is for CORS, and CORP is for cross-origin isolation, and those are different... but like, read permission is ≥ embed permission, I think? |
| 19:48 | <Eric Portis (he/him)> | If you squint, both headers say, "this resource doesn't contain any private data" |
| 20:13 | <Andrew Williams> | ah interesting, thanks for the link and feedback annevk |