| 01:07 | <sideshowbarker> |
Wonder what behavior the spec requires here |
| 01:09 | <sideshowbarker> | and https://stackoverflow.com/questions/57974176/safari-does-not-persist-the-authorization-header-on-redirect is another 2-year-old question about the same thing |
| 05:12 | <Noam Rosenthal> | Yoav Weiss: Noam Rosenthal : what is the cross-origin redirects case for unload timing protecting against? It's basically saying if you go x.com -> y.com --redirects to-> x.com/bar, x.com/bar does not get unload timing for x.com. Why? No information about y.com leaked. https://wpt.fyi/results/navigation-timing/unload-event-same-origin-check.html?label=experimental&label=master&aligned |
| 05:13 | <Noam Rosenthal> | to me it seems like an unnecessary security measure or I don't understand it. Yoav Weiss ? |
| 05:35 | <Yoav Weiss> | It's possible that this is overly strict. It used to be TAO protected and have the same rules as TAO, but at some point we realized that it's not really protecting anything (it's not the origin which information was exposed that was opting in), so moved to a same origin check. The same=>cross=>same scenario was one that we protected against in TAO, so maybe that logic sticked around through the move to same origin checks. |
| 05:37 | <Yoav Weiss> | Maybe annevk has reasons as to why we should keep it, but I tend to agree with y'all that if the previous origin is the same as the destination origin, we could expose the data |
| 07:48 | <annevk> | I think Referer and Sec-Fetch-Site are impacted so I think this ought to be impacted as well. What might leak is if y.com does a further redirect based on a cookie. Now x.com could conspire with subsequent x.com, but given that Referer and Sec-Fetch-Site are impacted it might not entirely be clear whether it's the result of a redirect or a subsequent visit. Especially with more navigation tracking mitigation down the line. |
| 07:48 | <annevk> | Noam Rosenthal: Yoav Weiss: Domenic: ^^ |
| 07:50 | <Noam Rosenthal> | I think Referer and Sec-Fetch-Site are impacted so I think this ought to be impacted as well. What might leak is if y.com does a further redirect based on a cookie. Now x.com could conspire with subsequent x.com, but given that Referer and Sec-Fetch-Site are impacted it might not entirely be clear whether it's the result of a redirect or a subsequent visit. Especially with more navigation tracking mitigation down the line. |
| 07:56 | <annevk> | Noam Rosenthal: yeah, though I'd argue that case is worse. |
| 07:57 | <annevk> | sideshowbarker: left a reply. Not sure if Safari has an open bug for this, maybe you want to file one? |
| 07:58 | <sideshowbarker> | sideshowbarker: left a reply. Not sure if Safari has an open bug for this, maybe you want to file one? |
| 15:28 | <devsnek> | any webkit/gecko people feeling inspired? https://github.com/whatwg/websockets/issues/20 |
| 15:29 | <devsnek> | annevk: you seemed to not hate this, in the past at least. do you think mozilla would accept contribution for this? |
| 15:31 | <annevk> | devsnek: yeah probably, but will need spec + tests |