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) On Wed, Jul 20, 2022 at 11:39 AM Alex Russell <[email protected]> wrote: > To clarify, does this also change the header name for delegation? > > On Monday, July 11, 2022 at 5:12:50 AM UTC-7 Mike West wrote: > >> LGTM3. >> >> -mike >> >> >> On Thu, Jul 7, 2022 at 9:03 PM Ari Chivukula <[email protected]> >> wrote: >> >>> 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) >>> >>> >>> On Wed, Jul 6, 2022 at 12:03 PM Daniel Bratell <[email protected]> >>> wrote: >>> >>>> LGTM2 (including removing the old syntax which is not yet used enough >>>> to be a compatibility problem) >>>> >>>> /Daniel >>>> On 2022-07-06 17:38, Chris Harrelson wrote: >>>> >>>> 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. >>>> >>>> On Wed, Jun 29, 2022 at 12:15 PM Mike Taylor <[email protected]> >>>> wrote: >>>> >>>>> 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). >>>>> >>>>> On 6/14/22 1:02 PM, Ari Chivukula wrote: >>>>> >>>>> Contact emails >>>>> >>>>> [email protected], [email protected], [email protected] >>>>> <[email protected]> >>>>> >>>>> 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 >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/R0xKm1B7qoQ>. >>>>> 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 >>>>> <https://chromestatus.com/feature/5684289032159232> and got belated >>>>> developer feedback >>>>> <https://github.com/WICG/client-hints-infrastructure/issues/108> that >>>>> it’s confusing. We reached the conclusion it’s not too late to change >>>>> course due to low adoption >>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4081> >>>>> 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 >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EClientHints> >>>>> >>>>> >>>>> >>>>> Motivation >>>>> >>>>> We’re switching from `name="accept-ch"` to `http-equiv="delegate-ch"` >>>>> on advice >>>>> <https://github.com/w3ctag/design-reviews/issues/702#issuecomment-1143680791> >>>>> that `http-equiv` should be used when the value is impacting the >>>>> processing >>>>> model. We’re switching from syntax close to HTTP Permissions-Policy >>>>> <https://w3c.github.io/webappsec-permissions-policy/#permissions-policy-http-header-field> >>>>> to use syntax closer to the iframe allow attribute >>>>> <https://html.spec.whatwg.org/dev/iframe-embed-object.html#attr-iframe-allow> >>>>> at the request of developers >>>>> <https://github.com/WICG/client-hints-infrastructure/issues/108>. >>>>> >>>>> >>>>> >>>>> Although this change is coming after a launch in M100, usage >>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4081> >>>>> 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 >>>>> <https://github.com/mozilla/standards-positions/issues/596> >>>>> >>>>> >>>>> >>>>> WebKit: No feedback on last request >>>>> <https://lists.webkit.org/pipermail/webkit-dev/2021-November/032057.html> >>>>> >>>>> >>>>> >>>>> Web developers: Positive interest from Cloudinary >>>>> <https://github.com/WICG/client-hints-infrastructure/issues/108> >>>>> >>>>> Debuggability >>>>> >>>>> Any improperly formatted client hint meta tags will be flagged in the >>>>> Issues tab >>>>> <https://docs.google.com/document/d/1lDEvj8tMeuvUs1HTTqL-44YiI-7ljeQkusM_WhUfIeE/edit> >>>>> . >>>>> >>>>> 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 >>>>> >>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> 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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4f894aa1-a903-4b9b-5e2e-bf30b8be4b9f%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> 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 [email protected]. >>>> 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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw89wr_mDkHxSHEsLrMA_NX56uJqk%2BDn76-WA4m739nE_w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- >>> 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 [email protected]. >>> >> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJ8z%2B6Zz6Z%3DpcNCwGdDi2zDioWeAyCjQ7vBZF-yHUyeFA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2BZVk6-VUS1ubyEcbq%3Ds45hAywOoC%3D31M3a%3DuE2KQWGKA%40mail.gmail.com.
