More descriptive header names for destination and user-activated

[arturjanc]

Some of the shortened header names seem fairly cryptic. Would it make sense to rename them to make their purpose more obvious? For example:

Sec-Fetch-Dest -> Sec-Fetch-Destination
Sec-Fetch-User -> Sec-Fetch-User-Activated or Sec-Fetch-Gesture?

FWIW if the user-activated flag is the odd one out, I wouldn't be super sad to not have it in v1 -- it seems the least likely to be useful for developers in the short term.

[mikewest]

I don't have strong feelings about the name. Something longer might be fine. That said, the header name isn't affected by HPACK, so extra bytes are something to consider. @mnot suggested Desc explicitly in https://www.mnot.net/blog/2018/11/27/header_compression#header-names as being the right side of the balance between obtuse and overinflated.

I can see the argument that User is on the wrong side of that balance. User-Activated is longer. Gesture doesn't match the HTML concept's name. UsrAct doesn't seem right.

FWIW if the user-activated flag is the odd one out, I wouldn't be super sad to not have it in v1 -- it seems the least likely to be useful for developers in the short term.

That surprises me. From earlier conversations, it sounded like this was an important mitigation for XS Search? Did I misunderstand that?

[arturjanc]

Re: header names, if there don't seem to be any significantly more appealing alternatives to what's currently in the spec, let's just stick to what we have -- there's probably not much benefit to bikeshedding this more :)

FWIW if the user-activated flag is the odd one out, I wouldn't be super sad to not have it in v1 -- it seems the least likely to be useful for developers in the short term.

That surprises me. From earlier conversations, it sounded like this was an important mitigation for XS Search? Did I misunderstand that?

I obviously favor more security-relevant metadata to less, so I wouldn't argue for removing it; but it somehow seemed easier to justify it as one of many fields in Sec-Metadata whereas now most of the other fields are Fetch-oriented (and exposed as separate hreaders) so it stands out a bit.

It has security value for preventing XS-Search or tabnabbing, but these might also be tackled with Cross-Origin-Opener-Policy, so there seem to be some alternatives that can help with these problems.

[mikewest]

I plan to leave the naming as-is. It's a compromise to be sure, but it feels like a reasonable one (and given the conversation in #16, it doesn't seem like this will block an initial pass at this feature anyway).