initiator change for Service Worker WindowClient.navigate

[Hubert Chao]

Hi navigation-dev@

I'm looking into adding an initiator to the Service Worker WindowClient.navigate() function (see https://groups.google.com/a/chromium.org/g/blink-dev/c/8AK8V4fSZFU), as a way of fixing a bug around Local Network Access (LNA) restrictions that aren't currently enforced on these navigations.

The question came up of what else might change if we add an initiator to these navigations; specifically in 2 areas:

a) What other security restrictions would end up applying to these navigations that aren't currently applied, both if the navigation from the WindowClient is a main frame navigation, or a subframe navigation?

b) Are there any current use cases (other than LNA checks) in which adding the initiator would break? (e.g. navigation currently succeeds but would fail)?

The only change I can think of here is that referrer header information might now be sent with the navigation, wondering if there's anything else I might have missed.

thanks,

/hubert

[Camille Lamy]

One thing that comes to mind is that we may inherit a bunch of security policies from the initiator when navigating to a local scheme. I don't know if WindowClient.navigate can navigate to a local scheme, though from what I recall when reading the code I don't see why it wouldn't. While that would not generally break the navigation, it may break the local page navigated to (e.g. if you now inherit CSP and you get CSP violations that you used not to have).

Overall, conceptually I think it makes sense to have an initiator for this kind of navigations. When a navigation is initiated by the content as opposed to the browser UX we do want to keep track of the security properties of the content that initiated the navigation, for example for cases like these.