Markup based Client Hints delegation for third-party content

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Markup based Client Hints delegation for third-party content
• Specification or proposal URL: https://groups.google.com/a/chromium.org/g/blink-dev/c/FTNrw03Xs9s/m/O74Mp6bmCAAJ, https://docs.google.com/document/d/1U3P9yvaT1NXG_qRmY3Lp6Me7M5kTnd3QrBb1yFUVNNk/edit, https://wicg.github.io/client-hints-infrastructure/#accept-ch-state-algo
• Caniuse.com URL (optional): N/A
• Bugzilla URL (optional): N/A
• Mozillians who can provide input (optional): @martinthomson @annevk @hsivonen

Other information

This is to support content negotiation use cases such as differential serving of variable fonts, color vector fonts, responsive images, and other third-party content which requires client information lost by user agent reduction. For example: variable fonts allow significantly less font information to be transferred without loss of functionality, but only works on specific operating systems.

It’s already possible to set a Permissions Policy in the HTTP response header, but for sites without the ability to modify HTTP headers a HTML solution would be ideal. This proposes a meta tag which allows delegation of client hints to third-party origins. These tags could be included in code-snippets for embedded third-party content for ease of use.

For example, to specify third party requests to https://foo.bar must include sec-ch-width you could include:
<meta name="accept-ch" content="sec-ch-width=('self' '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-width">

Note that this is the equivalent of the following today:
<meta http-equiv="accept-ch" content="sec-ch-width">

Start by reading the linked Blink proposal, WICG Client Hints infrastructure specification, and the issue's examples of meta-based delegation. Compare the proposed markup behavior with the existing http-equiv="accept-ch" behavior described in the issue. Done means documenting a well-supported Mozilla position on the proposal.