[blink-dev] Intent to Prototype: Markup based Client Hints delegation for third-party content

171 views
Skip to first unread message

Ari Chivukula

unread,
Sep 8, 2021, 12:58:36 PM9/8/21
to blink-dev

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

Privacy>Fingerprinting

 

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

https://crbug.com/1219359


Link to entry on the Chrome Platform Status

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


Domenic Denicola

unread,
Sep 8, 2021, 1:02:11 PM9/8/21
to Ari Chivukula, blink-dev
On Wed, Sep 8, 2021 at 12:58 PM Ari Chivukula <ari...@chromium.org> wrote:

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

Privacy>Fingerprinting

 

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


I feel like a TAG review would be especially helpful here, as there are several architectural implications of exposing a so-far-HTTP-only feature through HTML. And, as noted below, there's an important question about name="" (usually used for metadata) vs. http-equiv="" (usually used for changing behavior). Wider design input would be valuable for that sort of thing.
 

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

https://crbug.com/1219359


Link to entry on the Chrome Platform Status

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


--
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.
Reply all
Reply to author
Forward
0 new messages