[blink-dev] Intent to Prototype: 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/
Summary
To support variable fonts, color vector fonts, responsive images, and other third-party content which requires client information lost by the user agent reduction implementation we need a way to extend client hints. 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
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 prototypes a metadata 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">
TAG review
Not needed
Risks
This extension makes it easier for web developers to expose client hints to third-party content, but does not increase the surface area from what was already allowed via HTTP response headers. Blink currently implements first party client hints via a `http-equiv` meta tag. This extension will have to co-exist with (as a `name` meta tag) or replace/remove that iteration upon final implementation.
Interoperability and Compatibility
Gecko: No official position on implementation (Client Hints considered non-harmful; User Agent Client Hints considered harmful)
WebKit: No official position on implementation
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?
No, but it will be as part of prototyping.
Tracking bug
Link to entry on the Chrome Platform Status
Domenic Denicola
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/
Summary
To support variable fonts, color vector fonts, responsive images, and other third-party content which requires client information lost by the user agent reduction implementation we need a way to extend client hints. 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
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 prototypes a metadata 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">
TAG review
Not needed
Risks
This extension makes it easier for web developers to expose client hints to third-party content, but does not increase the surface area from what was already allowed via HTTP response headers. Blink currently implements first party client hints via a `http-equiv` meta tag. This extension will have to co-exist with (as a `name` meta tag) or replace/remove that iteration upon final implementation.
Interoperability and Compatibility
Gecko: No official position on implementation (Client Hints considered non-harmful; User Agent Client Hints considered harmful)
WebKit: No official position on implementation
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?
No, but it will be as part of prototyping.
Tracking bug
Link to entry on the Chrome Platform Status
--
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/CAGpy5D%2BDQCwmfg-efW11Ms7DQgjy2tUOd3AELg1He6ovqbFWLQ%40mail.gmail.com.