Consider splitting `document` into `document` and `nested-document`.

[mikewest]

As discussed in the context of Sec-Metadata, it might be useful to clearly distinguish between top-level and nested navigation requests by splitting the document destination into document and nested-document.

@annevk notes that this might be a breaking change, as folks might be relying on the existing document destination that's exposed on Request objects. @wanderview, @jakearchibald: WDYT?

[wanderview]

Since Request.destination was only relatively recently shipped in browsers, now might be the time to make this change. Sites would need to adapt, but they could do evt.request.destination.includes('document') or something.

FWIW, this better matches what firefox uses internally:

https://searchfox.org/mozilla-central/rev/292d295d6b084b43b70de26a42e68513bb7b36a3/dom/base/nsIContentPolicy.idl#87-96

Which we then map to the exposed document destination:

https://searchfox.org/mozilla-central/rev/292d295d6b084b43b70de26a42e68513bb7b36a3/dom/fetch/InternalRequest.cpp#274-277

I was wondering if this change would interact badly with the portals proposal, but I guess the navigation request would have to complete well before any portal is promoted from 3rd party to 1st party.

[mikewest]

Thanks, @wanderview, that's helpful. Who should we loop in from WebKit/Edge to see if they'd be willing to do the same?

[wanderview]

I think @youennf can speak to the fetch API in webkit.

I'm not sure for edge. Maybe @aliams or @jungkees can help.

[youennf]

I am not totally clear about the intent of this change.
Is it to allow a simpler definition/implementation of Sec-Metadata?
Is it to allow service worker to start acting as some sort of security proxy that could decide to stop loads based on a better knowledge of the client triggering the fetch?

FWIW, WebKit has this is-top-level-navigation concept, although at a slightly lower level. The proposed change seems ok from that prospective.
The same information could be made available elsewhere in a backward compatible way: fetch event or service worker client for instance.

[mikewest]

Hey, @youennf!

Is it to allow a simpler definition/implementation of Sec-Metadata?

Right now, Sec-Metadata defines a target attribute to describe the target browsing context of a navigation request: https://mikewest.github.io/sec-metadata/#target-member. It would be ideal if we could get rid of that member by folding the top-level/nested distinction into the destination.

Is it to allow service worker to start acting as some sort of security proxy that could decide to stop loads based on a better knowledge of the client triggering the fetch?

That's also a distinction that I think might be useful, but it's not my intent. Offering that capability to developers would be a happy side-effect of this change. :)

[youennf]

That seems reasonable to me.

Given a service worker might expose the same data that servers would provide directly, it makes sense to me that a service worker should get the same level of information as the one provided to the server through Sec-Metadata, at least for navigation loads.
The cause member information does not seem to be exposed to service worker.
The same-site value might be somehow exposed although computing the public suffix might be more easily done by the browser.

[jakearchibald]

Isn't this information (and more) already available by getting the client associated with fetchEvent.targetClientId, then looking at its client.ancestorOrigins?

[wanderview]

Do you mean resultingClientId? You won't be able to look at any information about that client until after the fetch completes, right?

Also, I don't think client.ancestorOrigins has been implemented widely yet due to privacy concerns being resolved with the main thread ancestorOrigins API. I think we still have client.frameType, though, until that is resolved.

[jungkees]

The idea of exposing the header to service workers sounds interesting.

My initial thought is what'd be a downside of maintaining the target member? The values of the destination look more like what the request's resulting resource kind would be. If we split them, there seems to be quite a few places that need some clarification. E.g. "A navigation request is a request whose destination is "document" or "nested-document", etc.

Do you mean resultingClientId? You won't be able to look at any information about that client until after the fetch completes, right?

Yes.

[jakearchibald]

@wanderview wouldn't targetClientId be the right thing to look at here?

[mikewest]

There seems to be some level of agreement that splitting document might be a reasonable thing to do. If I send out a PR against Fetch, HTML, and added some tests, would other vendors implement the change? :)

[wanderview]

@wanderview wouldn't targetClientId be the right thing to look at here?

I think we answered this on IRC. Since targetClientId will be null for cross-origin targets or new top level windows it can't really be used reliably to determine the type of request.