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.

[Chris Thompson]

Thanks Camille.

I would be a bit surprised if we allow a renderer-initiated navigation to a local scheme, since we as a rule don't allow normal pages to link or access URLs with local schemes. It does allow cross-origin navigations, though -- would the CSP concerns apply there as well?

Based on our reading of the specs as currently written, this navigation should use the WindowClient Document's policy container, so making this change would be a bug fix aligning us with the broader Service Worker / HTML / Fetch specs. crbug.com/454162508#comment30 has our latest reasoning on that (although the bug is currently restricted -- I've cc'd you on it if you are interested in the details).

[Camille Lamy]

Thanks for pointing me to the bug and the ServiceWorker spec.

First, I think it is relatively clear that the spec says this navigation is supposed to have an initiator, which is the frame controlled by the ServiceWorker which is being navigated. We're not doing that, and that's a bug.

Now if I read the SW spec correctly, I think we're more or less guaranteed that we're going to navigate to a non-local scheme since step 3 of the navigate algorithm has us return an error in case of an about:blank URL before we start the navigation. In that case, we're considering a navigation from a document to a regular HTTP URL. Adding the proper initiator should only impact LNA and the setting of the referrer URL, as other members of the PolicyContainer will be recomputed when we receive the response and do not impact the navigation. I don't think adding a referrer URL when we used not to is an issue for websites, if anything it's probably more of a positive. So to me, the only potentially problematic web visible impact is the application of LNA.