Reconsider http-equiv support

[yoavweiss]

Having to support <meta http-equiv> significantly complicates implementation in browsers (as it forces header parsing to happen in the renderer, resulting in browsers having to trust their renderers).

But:

• First party CH processing requires the first party to inspect headers, so likely means they can set them as well.
• Third party CH processing requires the first party to set Feature Policy opt-in headers, so they might as well also opt-in to CH using headers.

Given the above, it doesn't seem that adding a header requirement on the first party will impact deployment complexity (beyond taking legacy content, already opting in through <meta>, into consideration)

/cc @colinbendell & @eeeps for opinions

[eeeps]

Third party CH processing requires the first party to set Feature Policy opt-in headers, so they might as well also opt-in to CH using headers.

Using http-equiv to set Feature Policies seems dead in the water, both because of pushback from spec editors and for what I think (?) is a related security problem as the one you're highlighting for Accept-CH.

However, the problem of developers not being willing or able to set HTTP headers is real. I'll point again to our data on this, showing that virtually all users of Cloudinary's client hints features opted-in via http-equiv, rather than using headers.

Rather than stating that this is an unsolvable problem, so 🤷‍♂️, I think we should be working to solve it. I'm rooting for a future where:

1. Browsers start checking /.well-known/origin-policy pro-actively, without being prompted to do so by an Origin-Policy header
2. Setting a Feature-Policy that allows certain origins to receive hints also does the opting-into actually getting them sent. See Using Feature Policy to opt-in, and not just allow #23.
3. Authors who can't or would rather not configure headers, can drop a file into /.well-known/origin-policy that looks like this, and opt-in origin wide.

What is the cost of waiting to depreciate http-equiv until that, or some other path that does not require headers, is paved?

[yoavweiss]

Going back to this, maybe just the persistency part of http-equiv needs to be reconsidered. That way http-equiv will impact the current document, but not persisted on the origin. This will keep things as they are for the subresource case, but will enable simpler information flow architectures.

/cc @morlovich

[morlovich]

What's the story for 3P permissions and 1P child iframes with that?

Flow-wise http-equiv and 3P permissions does seem tricky, though, since info may need to propagate from renderer to browser to different renderer, which seems extremely difficult to make not racey.

[yoavweiss]

What's the story for 3P permissions and 1P child iframes with that?

Apologies for the delayed reply. I think the simplest path of "http-equiv is only applied to current document" may be best. The "victim" use case here would be hints on navigation requests to 1P child iframes. I think that's acceptable and simpler to explain: "If you need persistency, you need to use the headers".

[yoavweiss]

@eeeps @colinbendell - thoughts on #21 (comment)?

I think it will solve your use-cases while not adding significant complexity to browser architectures.

[colinbendell]

On the surface, I think that is a fine compromise. Each document request would have to implement the markup to signal the use of the accept-ch. This is typically the way we have seen this implemented anyway since the http-equiv is added to the base templates on the CMS and the like.

Are there any places that the definition of a document request would be ambiguous (other than SPA designs)?

[yoavweiss]

Are there any places that the definition of a document request would be ambiguous (other than SPA designs)?

Not really. The client hints set is defined on the environment settings object, which is a pretty solid concept.

[eeeps]

What's the story for 3P permissions

Good question! Authors would still need to attach a Feature Policy header to the document response, to get hints on 3P subresource requests, yeah?

If so, this change would only solve half of my problem.

[yoavweiss]

Good question! Authors would still need to attach a Feature Policy header to the document response, to get hints on 3P subresource requests, yeah?

Indeed!

If so, this change would only solve half of my problem.

I agree.