Naming for new items in `mode`.

[mikewest]

At TPAC, @clelland suggested that we could future-proof the mode mechanism by shifting from nested-navigate to navigate-nested, which would allow developers to read navigate- as a prefix. This dovetails with the suggestion in #37 that we might want to distinguish <object> in mode.

How would you feel about this in your implementation, @arturjanc / @lweichselbaum?

@annevk, FYI.

[annevk]

Should object/embed be navigate-from-object/navigate-from-embed or no-cors-from-object/no-cors-from-embed? If I remember correctly the initial request is no-cors and subsequent would be navigate-nested.

[arturjanc]

@jerryzz0 may have thoughts based on his implementation of the logic in our applications.

At a high level, the thing that's important for security is distinguishing navigations from subresource loads, to prevent attacks on resources without breaking linking (with the idea that you can use COOP to prevent leaking information about non-renderable responses / subresources if they are navigated to directly in a top-level window).

To future-proof against changes in mode it might be useful to maintain a guarantee that navigational requests will be easily distinguishable from resource loads and any other requests, e.g. that non-navigational requests never contain "navigate" and navigational requests always contain "navigate". This seems like it could be simple enough, without putting too may requirements on future values of mode, e.g. if (hypothetically) Portals should get a new mode, it could be navigate-portal.

For object/embed I'm still not a great fan of cramming the destination into the mode, but practically it would be okay if we did something like no-cors-from-object. I feel somewhat more strongly about this being no-cors-something rather than navigate-something because:

• object/embed is currently mode=no-cors on the first request.
• If we made it navigate-something, then server-side logic for Fetch Metadata would likely have to contain a special case to block this mode while allowing other navigate-related modes.

So overall no-cors-from-X for the initial object/embed request and establishing navigate-X as the mode for navigations seems like it would work.

[jerryzz0]

I like the idea of a prefix hierarchy as:

1. The relationship with navigate is a bit clearer - particularly in a sorted list of header values.
2. It could simplify application-side implementations of "isRequestNavigational".

That being said, it's also not that big of a deal since whether this is future-proof on the application side depends on the specific server-side policy in place (e.g. navigation-blocking vs resource-blocking) i.e.

• As Artur pointed out, a resource-blocking policy would likely require a special case to block navigate-from-object by default (since this could be a data resource).
• Similarly, a navigation-blocking policy will likely also want a special case to block no-cors-from-object by default (since this could be a rendered document).

Since we anticipate resource-blocking to be a primary use case (over navigation-blocking), I would prefer to optimize for that case if we had to choose between navigate-from-object vs no-cors-from-object.

My preference is that if we decide to change nested-navigate to navigate-nested then:

1. We do so soon while these headers are still relatively new - since dealing with backwards/cross-browser compatibility can be a pain.
2. We should also change the nested-document destination (potentially exposed as part of the still debated Sec-Fetch-Dest header) to document-nested for consistency.

[annevk]

It might make sense that for hierarchical values we use a different separator as the hyphen is already used for another purpose. E.g., no-cors/from-object or navigate/nested. This would be somewhat novel for enumeration values though (https://w3ctag.github.io/design-principles/#casing-rules doesn't mention it at least). But for writing simple parsers for them it seems really rather good. E.g., "navigate".split("/") yields a single value, "navigate/nested".split("/") yields two.

cc @domenic

[mikewest]

Hrm. If we're going to be .split()ing the value, then it seems like we might really be talking about two things: the mode on the one hand (navigate, no-cors, etc.), and the way the response will be used on the other (nested, top-level, etc.). I think it makes more sense to do that disjunction explicitly, as Sec-Fetch-Dest aimed to do.

Would it be reasonable to drop nested-navigate, and instead introduce something like Chromium's FrameOwnerElementType enum as a distinct header? (e.g. Sec-Fetch-Mode: nested-navigate would instead be represented by Sec-Fetch-Mode: navigate; Sec-Fetch-X-Bikeshed-Browsing-Context-Container-Type: iframe, or something similar). I think I'd prefer to do that, rather than risk falling into the weird naming hole that we ended up with in referrer policy.

[annevk]

That's fair and maybe that's an argument against that syntax. I worry that by using separate headers we make it easier to create faulty policies that forget about embed and object. (Or indeed forget about nesting.)

[mikewest]

I also worry that folks will forget about things they ought to check (I wanted everything in one big header, as you'll recall... ;) ). But given that we just shipped this a minute ago, and the folks who are using it at scale a. haven't really started yet, and b. are pretty much all on this thread, I'm pretty confident that we can both change things up and document them in such a way that developers will understand what they need to do. Checking three headers isn't significantly more complicated than checking two (where the second really splits along two axes). I think that's still my preference.

If y'all disagree, I can certainly be convinced that ever-more-complicated mode entries are reasonable, but it seems like we're jamming things in there just because it already exists.

[annevk]

I guess I'd love to see what it would look like concretely. My worry is that with -Dest it's not really clear how it relates to -Mode or that a mode of no-cors can turn into a navigation.

[mikewest]

I guess I'd love to see what it would look like concretely.

Strawproposal:

• Top-level navigation:

  Sec-Fetch-Site: cross-site
  Sec-Fetch-Mode: navigation
  [Sec-Fetch-Whatever omitted for top-level navigation]
  

• <script> load:

  Sec-Fetch-Site: cross-site
  Sec-Fetch-Mode: no-cors
  [Sec-Fetch-Whatever omitted for pure subresource requests]
  

• <iframe> navigation

  Sec-Fetch-Site: cross-site
  Sec-Fetch-Mode: navigation
  Sec-Fetch-Whatever: iframe
  

• <object> plugin or navigation:

  Sec-Fetch-Site: cross-site
  Sec-Fetch-Mode: no-cors
  Sec-Fetch-Whatever: object
  

mode of no-cors can turn into a navigation.

Indeed. This is confusing, and it may be better to explicitly label this as navigation-possibly-depending-on-how-you-respond-dearest-server, as it does feel like it might be a distinct kind of request with different behavior than "navigation".

I'm less convinced that nested navigations (or portaled navigations?) are distinct in the same way. It seems like we might want to advertise the latter to give sites choices about what code to send (no reason to check for portalHost, etc. if you know you're not being portaled), but the higher-order choice of whether or not you'd like to be framed seems possible by checking Sec-Fetch-Whatever's value (or lack thereof). That feels like good contextual information, but not a distinct mode...

[annevk]

Okay, so the -Whatever header is only for being framed or the possibility of getting framed and only has four values (the four HTML framing element local names). -Frame seems reasonable in that case.

[mikewest]

Okay, so the -Whatever header is only for being framed or the possibility of getting framed and only has four values (the four HTML framing element local names).

Right. Something like an enum of frame, iframe, object, embed, portal, and whatever we collectively invent tomorrow. I think we'd define it in terms of the request's reserved client's target browsing context's container's tag name? Something like that...

-Frame seems reasonable in that case.

Sec-Fetch-Frame-Owner might be more descriptive? Especially if we add more "frame" attributes as #43 hints at...

[mikewest]

@arturjanc, @jerryzz0, could y'all live with this bisection of Sec-Fetch-Mode? Is it a terrible idea?

[jerryzz0]

If I understand correctly, the proposal is to:

1. Keep Sec-Fetch-Mode largely the same but collapse the current navigate and nested-navigate into a single navigate value.

2. Keep Sec-Fetch-Site unchanged.

3. Introduce Sec-Fetch-Frame-Owner (or something equivalent) to distinguish between the various framing scenarios.

I think this works. In particular:

• A naive resource-blocking policy looking only at Sec-Fetch-Site and Sec-Fetch-Mode would still work and ambiguous cases like embed/object which has a Mode of no-cors would be blocked by default.

• Policies that actually need to account for e.g. embed/object (as described in Handling iframing via <embed> / <object> #37) can do so by looking at Sec-Fetch-Frame-Owner.

In other words, in practice it'd function as a (similar but not identical) substitute to Sec-Fetch-Dest which does not seem like a terrible idea.

it may be better to explicitly label this as navigation-possibly-depending-on-how-you-respond-dearest-server

Hmm that could be nice and might make things easier to understand on the application side; but then Sec-Fetch-Mode wouldn't be a simple reflection of the Request Mode anymore - at which point the question arises as to whether Sec-Fetch-Mode makes more sense than a (as a hypothetical strawman) Sec-Fetch-Is-Navigational with values of yes/no/maybe.

[annevk]

@jerryzz0 Sec-Fetch-Site is unchanged and Sec-Fetch-Mode would largely be the same. I think you interchanged them initially. Note that if we changed the -Mode enumeration values I would expect us to also change request's mode concept. It's not exposed in many places so likely changes can still be made there.