Having both incumbentNavigationOrigin and the source browsing context's active document's origin seems bad #6514
Description
Spinning off from #1130 and #2591, my concern is that even if we applied tricks similar to #6497 and #6512, we might end up in a bad place, because we have two notions of "initiator origin" for a navigation.
The spec uses:
- incumbentNavigationOrigin, computed in step 9 of navigate, for determining the origin of the response, which, for example, feeds into
Sec-Fetch-Site - The source browsing context's active document's origin for:
- "should" guidance about what to display when prompting the user about external software
- Determining the COOP enforcement result (step 7 of process a navigate fetch)
- The same-origin check for javascript: URLs (step 2)
When will these two concepts differ? Well, assuming we fix source browsing context's active document's origin to be computed synchronously instead of lazily, then the differences arise mainly when cross-global scripting is involved. For example, consider:
https://a.example.com/which embedshttps://b.example.com/which embedshttps://c.example.com/.- All three of them use
document.domainso that they can synchronously script each other. (You knew it was coming!!) - In the outermost frame I navigate the innermost frame by doing
frames[0].contentDocument.querySelector("iframe").src = "https://whatever.example/"
Then, the incumbentNavigationOrigin is the outermost https://a.example.com/ where the script is running, whereas the source browsing context's active document's origin is https://b.example.com/. (The same thing happens for the initial navigation if we changed this example to insert the innermost iframe, instead of modify it, BTW.)
You can construct similar terrible situations with window.open(), where the source browsing context is derived from the entry global, which differs from incumbent in fun ways. (On the other hand, location.href and other setters always sets the source browsing context to the incumbent, so it cannot diverge there.) Other scenarios I haven't dug into are inserting <meta http-equiv="refresh"> or performing a non-bfcache history.back() navigation.
Anyway, this difference seems bad. Security checks for javascript: URLs and COOP should probably use the same security checks as Sec-Fetch-Site.
So, which origin do we care about? I guess this is testable in browsers, so probably I should write some tests and report back...