[blink-dev] Intent to Prototype & Ship: Syntax changes to markup based Client Hints delegation

[Ari Chivukula]

Contact emails

ari...@chromium.org, mike...@chromium.org, yoav...@chromium.org

Prior Intent

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

Specification

https://github.com/WICG/client-hints-infrastructure/pull/109

Summary

There is existing HTML syntax to delegate client hints to third-party content which requires client information lost by user agent reduction. Example:

<meta name="accept-ch" value="sec-ch-dpr=(https://foo.bar  https://baz.qux), sec-ch-width=(https://foo.bar)">

 

We shipped this syntax in M100 and got belated developer feedback that it’s confusing. We reached the conclusion it’s not too late to change course due to low adoption so far.

 

This intent proposes a replacement syntax with the same feature set. Example:

<meta http-equiv="delegate-ch" value="sec-ch-dpr https://foo.bar https://baz.qux; sec-ch-width https://foo.bar">

 

Blink component

Blink>Network>ClientHints

 

Motivation

We’re switching from `name="accept-ch"` to `http-equiv="delegate-ch"` on advice that `http-equiv` should be used when the value is impacting the processing model. We’re switching from syntax close to HTTP Permissions-Policy to use syntax closer to the iframe allow attribute at the request of developers.

 

Although this change is coming after a launch in M100, usage of the prior syntax is low (currently 0.000016%) and it seems worth taking the opportunity to reduce developer confusion and increase standards compliance.

TAG review

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

Compatibility

We will not be removing either prior syntax, so there is no compatibility risk.

 

Interoperability

Other engines haven’t shipped the previous delegation syntax, so are unlikely to object to this specific change.

 

Gecko: Neutral

 

WebKit: No feedback on last request

 

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/34416

Tracking bug

https://crbug.com/1334152

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6308751530262528

[Anne van Kesteren]

On Tue, Jun 14, 2022 at 7:02 PM Ari Chivukula <ari...@chromium.org> wrote:
> Gecko: Neutral

I don't think I should claim to speak for Gecko anymore, but that
comment of mine was not neutral. We keep adding mutable policies (and
I include one-off no policy -> policy transitions in this) on the
basis that it makes sense to those pushing for those policies and the
people they happen to talk to, but it doesn't make sense from a
slightly broader perspective. It builds on brittle infrastructure and
fundamentally can result in hard to diagnose bugs.

Yes, declaring policies via HTTP might hurt adoption short term, but
overcoming that hurdle is what we should focus on. Instead, we keep
having this debate for each new policy as nobody is willing to own the
actual problem. (There's a very similar problem with getting features
to be restricted to secure contexts. Each feature advocate is always
convinced their feature shouldn't be and will then go on to enumerate
the problems requiring secure contexts might cause them...)

[Mike Taylor]

To add some clarity to the proposed changes and the rationale (as this came up in the API OWNERS meeting today):

In M100 we shipped the following syntax, thinking it was a good idea to get as close to Permissions-Policy syntax as possible:

<meta name="accept-ch" value="sec-ch-dpr=(https://foo.bar  https://baz.qux), sec-ch-width=(https://foo.bar)">

But it’s not quite a valid Permissions Policy, as Cloudinary pointed out.

One difference is the lack of quotes around origins  (which are required for sf-strings). But without changing HTML meta parsing entirely (no thanks), we would have to force devs to use a single quote for value=, so they could use double quotes inside. Or the inverse, but sf-strings don’t allow for beginning with single quotes.

Another difference is the fact that client hints tokens begin with the `sec-` prefix, but the policy-controlled feature names do not.

So the delta is far enough away from a Permissions-Policy header to declare that our attempt failed. :(

Instead, this intent proposes adding new syntax (old syntax to be deprecated/removed if this is approved in a followup intent) that looks like so:

<meta http-equiv="delegate-ch" value="sec-ch-dpr https://foo.bar https://baz.qux; sec-ch-width https://foo.bar">

This format tracks more closely with iframe’s “allow” serialization (and other familiar meta http-equiv pragmas, like CSP).

[Chris Harrelson]

LGTM1 to ship this *and* remove the old syntax at the same time. We/I think it'd be better to do it all at once without having both syntaxes in the while for a period.

--
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/4f894aa1-a903-4b9b-5e2e-bf30b8be4b9f%40chromium.org.

[Daniel Bratell]

LGTM2 (including removing the old syntax which is not yet used enough to be a compatibility problem)

/Daniel

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

[Ari Chivukula]

Combining the addition of the new syntax and the removal of the old one works. I'll update the language on the chrome status feature page. There won't be an issue getting the code in for M105 assuming we get the third LGTM within a week.

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

[Mike West]

LGTM3.

-mike

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

[Alex Russell]

To clarify, does this also change the header name for delegation?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4f894aa1-a903-4b9b-5e2e-bf30b8be4b9f%40chromium.org.

--
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+unsubscribe@chromium.org.

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

--
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+unsubscribe@chromium.org.

[Ari Chivukula]

Accept-CH is still the name of the HTTP header to request client hints and Permissions-Policy is still the name of the HTTP header to delegate client hints.

This only changes the HTML meta tag name/syntax.

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

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/4f894aa1-a903-4b9b-5e2e-bf30b8be4b9f%40chromium.org.

--
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/CAOMQ%2Bw89wr_mDkHxSHEsLrMA_NX56uJqk%2BDn76-WA4m739nE_w%40mail.gmail.com.

--
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.

[slightlyoff via Chromestatus]

LGTM; thanks for clarifying.