Check Feature Policy before attaching Client Hints

[eeeps]

This PR is part of an attempt to address w3c/webappsec-permissions-policy#129 – using Feature Policy to let authors opt-into sending specific Client Hints to specific origins.

The overall, basic idea is:

1. A new set of policy-controlled features – one for each Client Hint header field – is defined in the Client Hints spec.
2. A new algorithm which determines whether a request is able to use a policy-controlled feature is defined in the Feature Policy spec.
3. The step in Fetch that appends Client Hint headers calls the new algorithm, checking if a request is allowed to use a Client Hint’s policy-controlled feature before appending the Client Hint header. That change is contained in this PR.

---

Preview | Diff

[igrigorik]

Some existing plumbing that we need to refactor:

• https://fetch.spec.whatwg.org/#client-hints-list
• Fetching steps 6+7: https://fetch.spec.whatwg.org/#fetching

I think the behavior we want here is..

1. We need to define the Accept-CH opt-in processing in HTML spec
2. For nav request, update Fetch to reference (1) instead of current "client hints tokens" ref to IETF spec
3. For subresources, execute algorithm defined in FP, checking for delegation

@eeeps @annevk WDYT, does that make sense?

[yoavweiss]

(1) and (2) are implemented (but not yet landed) in whatwg/html#3774 and #773

@eeeps & @tarunban - maybe we should merge all the different CH related PRs, to make it easier to discuss them in a holistic manner. Thoughts?

[annevk]

Yeah, I'd much prefer we don't add feature policy until the architecture is more correctly described.

[ghost]

I agree that it's best to merge related PRs. However, I really do not have a pending PR. So, I am not sure if I can help much here.

[eeeps]

Closing, as I've moved this PR at over to yoavweiss#1 in order to consolidate CH/Fetch work.