#702: Markup based Client Hints delegation for third-party content
Discussions
2022-02-07
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
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-28
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
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
OpenedDec 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 includesec-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
toname
is that this new syntax isn’t supported in the HTTP headeraccept-ch
field. The syntax to delegate client hints to third parties will be unique to thename
d meta tag.DelegateTo
).Further details:
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