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

閲覧: 531 回
最初の未読メッセージにスキップ

Ari Chivukula

未読、
2021/12/20 17:02:042021/12/20
To: blink-dev、Jade Kessler、Mike Taylor、Yoav Weiss

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

未読、
2022/01/10 15:58:302022/01/10
To: blink-dev、Jade Kessler、Mike Taylor、Yoav Weiss
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

未読、
2022/01/11 5:09:502022/01/11
To: Ari Chivukula、blink-dev、Jade Kessler、Mike Taylor
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

未読、
2022/01/11 14:51:522022/01/11
To: Yoav Weiss、Ari Chivukula、blink-dev、Jade Kessler、Mike Taylor
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

未読、
2022/01/11 15:41:592022/01/11
To: Rick Byers、Yoav Weiss、Ari Chivukula、blink-dev、Jade Kessler、Mike Taylor

Ari Chivukula

未読、
2022/01/18 10:18:552022/01/18
To: Daniel Bratell、Rick Byers、Yoav Weiss、blink-dev、Jade Kessler、Mike Taylor
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

未読、
2022/01/19 12:04:112022/01/19
To: blin...@chromium.org
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

未読、
2022/02/09 11:35:302022/02/09
To: blin...@chromium.org
LGTM3 Looks like the TAG review is still pending. Please watch for any feedback from them that might require changes.

Domenic Denicola

未読、
2022/03/23 12:24:522022/03/23
To: chrishtr via Chromestatus、blin...@chromium.org
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.

Ari Chivukula

未読、
2022/03/24 15:42:342022/03/24
To: Domenic Denicola、chrishtr via Chromestatus、blin...@chromium.org
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)

全員に返信
投稿者に返信
転送
新着メール 0 件