Request for position: Markup based Client Hints delegation for third-party content

[arichiv]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Markup based Client Hints delegation for third-party content
• Specification or proposal URL: https://groups.google.com/a/chromium.org/g/blink-dev/c/FTNrw03Xs9s/m/O74Mp6bmCAAJ, https://docs.google.com/document/d/1U3P9yvaT1NXG_qRmY3Lp6Me7M5kTnd3QrBb1yFUVNNk/edit, https://wicg.github.io/client-hints-infrastructure/#accept-ch-state-algo
• Caniuse.com URL (optional): N/A
• Bugzilla URL (optional): N/A
• Mozillians who can provide input (optional): @martinthomson @annevk @hsivonen

Other information

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

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 proposes 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=('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">

[annevk]

I'm not persuaded we should address "cannot modify HTTP headers" scenarios in this manner. As I outlined in https://github.com/w3c/webappsec-permissions-policy/issues/55 this results in mutable policies, race conditions, and other problems.

Instead, we should figure out how to address the more fundamental problem of HTTP headers being hard to configure. (One way this can be done is by not providing solutions such as these, eventually resulting in CDNs that do offer flexibility here getting more customers.)

This is aside from client hints, which as noted at https://mozilla.github.io/standards-positions/#http-client-hints we're not exactly favorable on and as noted at WICG/client-hints-infrastructure#100 has unresolved same-origin policy issues.

[eeeps]

@annevk HTTP headers are hard HTML authors to configure and maintain. Why?

1. There are many possible stacks
2. Each stack probably has multiple places where HTTP headers could be set
3. All of those places are often out-of-view or even out-of-bounds for the people who write HTML
4. There are no easy answers; how headers are best configured depends on many variables. Many of those variables are technical, but just as many are organizational.

A concrete example: let's say I'm working with a Cloudinary customer to set the Permissions-Policy header needed for us to receive responsive image client hints. The customer is authoring a custom theme for WordPress, on Apache, fronted by Cloudflare. There are at least four places where they could set HTTP headers: with a WP plugin, using .htaccess, via PHP, or using Cloudflare config.

Depending on the person I'm working with's role and expertise, they may have the ability to set headers using some or none of these. Other people in the organization might need to be brought in. But if they're writing an <img> component, they almost certainly have editing permissions over and visibility into the HTML.

The problem isn't CDN providers with inadequate feature sets. Most offer ways for people to set headers. The problem is that those people often aren't the same people who are writing markup.

So, we get results like these, where markup authors overwhelmingly use markup to solve a problem, rather than HTTP: https://almanac.httparchive.org/en/2021/resource-hints#fig-1

I get that there are many potential layering problems that fall out of using HTML to alter HTTP. We should continue to seek solutions like the original vision of Origin-Policy which provide a standard, more-accessible way front-end authors to do arbitrary HTTP things.

In the meantime, (and here's where I think we disagree) we shouldn't hold use cases that don't suffer from layering problems back. If authors overwhelmingly want to use HTML to accomplish an important task, and (if and only if) there are no end-user-facing problems that arise from that, why not pave the cowpath until a more general solution arises?