Intent to Ship: Markup based Client Hints delegation for third-party content

[Ari Chivukula]

Contact emails

ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org

Design Doc

https://docs.google.com/document/d/1U3P9yvaT1NXG_qRmY3Lp6Me7M5kTnd3QrBb1yFUVNNk/edit

Specification

https://wicg.github.io/client-hints-infrastructure/

Intent to Prototype

https://groups.google.com/a/chromium.org/g/blink-dev/c/FTNrw03Xs9s/m/O74Mp6bmCAAJ

Summary

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.

 

Blink component

Blink>Network>ClientHints

 

Motivation

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 proposal ships 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=( 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">

TAG review

https://github.com/w3ctag/design-reviews/issues/702

Compatibility

We do not anticipate compatibility risks for this addition - Blink currently implements first party client hints via a `http-equiv` meta tag, and that functionality will not be removed or modified.

 

Interoperability

 

Gecko: Neutral

 

WebKit: Requested

 

Web developers: Positive interest from Cloudinary

Debuggability

Any improperly formatted client hint meta tags will be flagged in the Issues tab.

Is this feature fully tested by web-platform-tests?

https://github.com/web-platform-tests/wpt/pull/32142

Tracking bug

https://crbug.com/1219359

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5684289032159232

[Ari Chivukula]

Reaching out for review now that we're past the holiday season. I'm hoping to make the M99 branch cut on the 20th.

[Yoav Weiss]

I'm recusing myself on this intent, as I was involved in the design. At the same time, (and unsurprisingly), I think this is an important feature to enable Client Hints adoption for cross-origin resources, which seems critically important both for fonts as well as for image CDNs.

[Rick Byers]

LGTM1, looks pretty minor and straightforward. And I agree that we can't rely on the ability to set HTTP headers alone for wide adoption.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXTAhJDFjQp_6D%3D6KxoZRFkv_KHfJAzekNZJYTGAnP4Sw%40mail.gmail.com.

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8PWMqb_0URQfL3krHpB23h6g%2BCY9MtWNLjJxzSgQb7eg%40mail.gmail.com.

[Ari Chivukula]

Hi API owners! Wanted to bump this thread since we're getting close to the M99 branch cut (this Thursday).

This could be launched to beta only, but since there's been developer interest in this feature we would like to launch it with M99 if possible.

~ Ari Chivukula (Their/There/They're)

[chrishtr via Chromestatus]

Hi, the API owners discussed this intent today. We decided that we'd like to hear from the TAG about this feature (*), and so are not deciding on it this week. I hope a delay to M100 won't be a huge burden. (*) The TAG review was filed only a few weeks ago, so I think they need some more time.

[chrishtr via Chromestatus]

LGTM3 Looks like the TAG review is still pending. Please watch for any feedback from them that might require changes.

[Domenic Denicola]

I'd like to highlight a serious interop risk here, which is that it is not specified at all when or how many times the accept-ch meta tag is processed. Some more discussion in https://github.com/w3ctag/design-reviews/issues/702#issuecomment-1076530567 . I hope this can be addressed before shipping as it could lead to very non-interoperable implementations. (E.g. right now the only conformant implementation of the spec is to never process accept-ch meta tags at all, because there is no normative text requiring it's processing, just an unlabeled list of steps which no normative text ever runs.)

On Wed, Feb 9, 2022 at 11:35 AM chrishtr via Chromestatus <admin+c...@cr-status.appspotmail.com> wrote:

LGTM3 Looks like the TAG review is still pending. Please watch for any feedback from them that might require changes.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/000000000000a64bba05d7986b2f%40google.com.

[Ari Chivukula]

This is a good point, I'm working to fix the standard to reflect the way Chrome handles the parsing. Open to feedback if I'm missing something. https://github.com/WICG/client-hints-infrastructure/pull/103

~ Ari Chivukula (Their/There/They're)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8Toanp6p%3DdKo2rXx4n1BWAjEP5ivF%3D7%2BDf-zXH0_dgRw%40mail.gmail.com.