Name suggestions

[craigfrancis]

Suggestions for Sec-Metadata header name.

Original suggestion from @arturjanc was "Sec-Site"

I'm wondering if it needs to be explicitly state "Sec-" (for Security), as this information might be useful for other purposes.... maybe performance, as you could split processing time logs between the different initiators/destinations; or log the number of requests which are same-site vs cross-site.

Oddly this reminds me of Client Hints, in that it's the client telling the server more about what the request will be used for.

[craigfrancis]

@arturjanc also suggested "Sec-Requesting-Origin", as there are concerns it might cause compatibility issues if this information was added to the Origin header (which is where the From-Origin proposal got it's name from).

Similarly we mustn't forget the Referer (Referrer) header :-)

[craigfrancis]

https://mobile.twitter.com/mikewest/status/996625224878776320

Every browser (including IE) bans XHR
from setting headers with a ‘Sec-‘ prefix

[dveditz]

I'm wondering if it needs to be explicitly state "Sec-" (for Security)

It's "Sec-" for secure, and defined as an extension point for the set of "forbidden header names" that can't be set in XHR or fetch().
https://fetch.spec.whatwg.org/#forbidden-header-name
https://xhr.spec.whatwg.org/#the-setrequestheader()-method

[mikewest]

Thanks for starting this thread, @craigfrancis!

Sec-Site / Sec-Requesting-Origin

Neither of these seem appealing to me, as they're both fairly narrow (and the latter doesn't even apply anymore, since we're no longer delivering the origin explicitly).

Oddly this reminds me of Client Hints ...

It's not that odd! The explainer even mentions that similarity explicitly: https://github.com/mikewest/sec-metadata#why-bundle-these-up-into-one-header-why-not-have-one-header-for-each-distinct-value-like-client-hints :)

It's worth evaluating, but I think I prefer the current model, where we bundle up a set of properties that I expect would be evaluated together into one header, rather than a model where we add a new request header for each bit of data.

[craigfrancis]

@mikewest ... Agreed, seeing it as a generic header, where more metadata/properties can be added later, makes me think Sec-Metadata is a pretty good name (I also prefer all of these values to be in one place, rather than using separate headers).

Now the off-topic question is... when I read the explainer document, was it your comment about Client Hints that got me thinking about it, or was I half asleep at the time and skipped that bit.

Feel free to close this issue if you're happy with the name (I am).

[Jxck]

Headers are always metadata, so Context: or Sec-Context: seems better for me.

[mikewest]

Headers are always metadata, so Context: or Sec-Context: seems better for me.

Right. "Metadata" is a dumb name. But it's what we've got at the moment... :)

Perhaps Sec-Fetch or Sec-Request or something similar, since all of these members are pulled directly from Fetch's request concept. Idunno. Once everything else is hammered out, I hope the name will just fall into place.

(We need the Sec- prefix to prevent XHR from injecting the header from JavaScript.)

[Malvoz]

@Jxck
Sec-Context conflicts with this spec name: https://w3c.github.io/webappsec-secure-contexts/. I understand HTTP header fields and the specification in which it is defined does not need to be the same. But that'd be somewhat confusing nevertheless.

@mikewest
I don't know what makes a header a policy header, but this feels like a policy header.
(Edit: Because they are intended to be applied to the document/browsing context and not per subresource?
Please do correct me if my terminology is incorrect.)

Sec-Fetch or Sec-Request is self describing but feels a bit short which I personally don't care much for, however if this categorizes as a policy header, maybe Sec-Fetch-Policy or Sec-Request-Policy ?

[Jxck]

@Malvoz

in other policy like CSP or Origin-Policy are defined by Content Author, so it's policy. but this(currently sec-metadata) spec only shows "what the contexts is this request executed" so policy does not fit I think.

if Sec-Context is too similar to secure-contexts spec, make them log as you said, means Sec-Fetch-Context or Sec-Request-Context.

[mikewest]

feels a bit short

Shorter is better, given that we'll be taking up bytes on every outgoing request with whatever we name this header.

I'm still leaning towards Sec-Fetch on those grounds, but I'm also not thinking about it too much until other vendors express a desire to implement it as well. As long as it's just Chrome, changing the name is trivial. (@dveditz, how's Mozilla feeling about this these days? :) )

[arturjanc]

Since I don't disagree with @mikewest about enough these days, I'm going to go ahead and express a personal preference for Sec-Context. The header tells the server about the circumstances which led to sending of the request (Was it created by a same-origin page? Will it end up as an <img>? Is it performed in response to a user gesture?) so I feel like context describes this situation fairly well.

[Jxck]

in the future we can extends other *-Context header which not tied to Fetch.
(for example, Feature-Policy, Content-Security-Policy etc are *-Policy family)

the *-Context is initiated by Browser which shows current browser context, like *-Policy is initiated by Server which shows current content policy.

Client <- `*-Policy` <- Server
Client -> `*-Context` -> Server

So I still on Sec-Context.

(of-course, browser need Sec prefix for avoid adding from JS)

[Malvoz]

if Sec-Context is too similar to secure-contexts spec

Well it is, and if that is a source of confusion depends on the individual to disassociate between them.

[liuyanghejerry]

I think it can be Sec-Meta. It's shorter. Since everything is "data", maybe we can strip the "data".

[mikewest]

We landed on "Fetch Metadata" and Sec-Fetch-*. Good enough!