#702: Markup based Client Hints delegation for third-party content

Visit on Github.

Opened Dec 20, 2021

Braw mornin' TAG!

I'm requesting a TAG review of markup based Client Hints delegation for third-party content.

This allows permission policies (for only client hints) to be set on Accept-CH meta tags which include third party origins, which is useful for web developers who may not have easy access to modify HTTP headers (e.g., developers relying on embedding third-party code snippets). For example, to specify third party requests to https://foo.bar must include sec-ch-ua-platform-version you could include:

<meta name="accept-ch" content="sec-ch-ua-platform-version=( https://foo.bar)">

You may still omit the permission policy and rely on the default allowlist as follows:

<meta name="accept-ch" content="sec-ch-ua-platform-version">

Note that this is the equivalent of the following today:

<meta http-equiv="accept-ch" content="sec-ch-ua-platform-version">

The reason we’re moving from http-equiv to name is that this new syntax isn’t supported in the HTTP header accept-ch field. The syntax to delegate client hints to third parties will be unique to the named meta tag.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the work on this specification is currently being done: WICG
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): W3C or WHATWG
  • Major unresolved issues with or opposition to this specification: N/A
  • This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Discussions

2022-02-07

Minutes

Yves: seems weird that you want to give specific settings for something that is remote -- what happens with the maintenance of those hints - what happens if the URL doesn't require those hints any more - i will look into it...

2022-02-14

Minutes

Yves: it's a way to set http headers from a server response - it's not possible in http to make claims on "this other resource".. faking server-header replies for this particular site.. it's dangerous - not clean architecturally - it may change and you have rotten content configuration... it may be conflicting with what the server may reply at some point. If people want to have an optimised way to figure out that the 3rd party server would like to have a UA platform version client hint sent in the upcoming request - it shouldn't be in the markup of another web site. It should be in something that might be cached - e.g. hsts. You could do the same here - for this particular subtree of site send us the UA platform version client hint... The server has to be configured .. the client (browser) should cache that information.

... if the intent is to say "the remote server cannot be configured properly" then you wouldn't need client hints because you wouldn't be able to handle them anyway.

Yves: leaves comment

2022-02-21

Minutes

Yves: sent something yesterday

2022-02-28

Minutes

Yves: want to answer, the crux is that their solution doesn't fix the issues with the use of CSP .. [??] and use of http-equiv for that is not really good

Dan: can we get other voices to support? mnot?

Yves: would make sense

2022-04-04

Minutes

Dan: interesting that Ari is talking about 'sent from the first party server'. What's that about? Rather than same origin. But they are being responsive to Yves' comment.

Yves: response from Dominic saying it should be properly specified. They opened an issue in their repo. If that works then I'm fine with it.

Dan: suggest closing comment

Yves: wait for plenary?

we will hopefully close at plenary