Skip to content

Define policy-controlled features #696

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
eeeps wants to merge 1 commit into from
Closed

Define policy-controlled features #696

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions draft-ietf-httpbis-client-hints.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -255,6 +255,27 @@ Implementers ought to consider both user and server controlled mechanisms and po

Implementers SHOULD support Client Hints opt-in mechanisms and MUST clear persisted opt-in preferences when site data, browsing history, browsing cache, or similar, are cleared.

## Opt-in via Feature Policy
Copy link
Member

@igrigorik igrigorik Sep 29, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eeeps this entire section should live in Feature Policy spec, not here. Could you move it over to your FP PR?

Copy link
Contributor Author

@eeeps eeeps Dec 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure it belongs in the Feature Policy spec. The Feature Policy spec only defines a generic set of mechanisms, and is not in the business of defining (or even, to date, enumerating) specific policy-controlled features like this.

Can you explain why you don't think these feature policy definitions belong in the Client Hints spec?

Perhaps there's somewhere in the HTML or Fetch specs that'd be a better home?

cc: @yoavweiss

Copy link
Contributor

@yoavweiss yoavweiss Dec 14, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're both right! :)

Cross-origin fetches is a web concept, so it has no place here. At the same time, FP does indeed just define the mechanisms, not the features.

HTML and Fetch are probably the right places for this, where the features are defined in HTML and initialize an object keeping track of the Document's CH delegation to certain third-parties, which is later used in Fetch to actually make a decision on sending the hints themselves using it.

Copy link
Contributor Author

@eeeps eeeps Dec 14, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yoavweiss do you think this policy-controlled feature definition belongs in (or is blocked by?) whatwg/html#3774, or should I create a new PR on the HTML spec?

Copy link
Member

@mnot mnot Dec 17, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're going to make the CH spec generic (which still needs to be properly explained/discussed, btw :), I'd think that the CH spec should have a mention of FP and some general guidance, whereas the specific feature definitions / guidance should go wherever those particular hints are defined. YMMV, of course.

Copy link
Member

@igrigorik igrigorik Dec 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. We could mention FP as an example of how delegation can happen for a browser use case. For other environments.. they may or may not use a similar pattern.

@mnot does that sound reasonable to you?

Copy link
Contributor

@martinthomson martinthomson Dec 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If feature policy were a done deal, that might be OK, but it's still very unstable.

Copy link
Member

@mnot mnot Dec 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, that sounds like an argument for more generic language.


Implementers that implement [Fetch](http://fetch.spec.whatwg.org) SHOULD provide authors the ability to opt-into sending specific Client Hints to specific origins using [Feature Policy](https://wicg.github.io/feature-policy/).

This document defines [policy-controlled features](https://wicg.github.io/feature-policy/#features) for the following Client Hints header fields:

| Client Hints header field | policy-controlled feature | [default allowlist](https://wicg.github.io/feature-policy/#default-allowlists) |
|--|--|--|
| `DPR` | `ch-dpr` | `'self'` |
| `Width` | `ch-width` | `'self'` |
| `Viewport-Width` | `ch-viewport-width` | `'self'` |

These feature policies are set on the [client](https://fetch.spec.whatwg.org/#concept-request-client), and enforced on requests made by that client.

For example, after receiving a document with the following [policy directives](https://wicg.github.io/feature-policy/#policy-directives)

~~~ example
Feature-Policy: ch-dpr image-cdn.com 'self'; ch-width image-cdn.com 'self'; ch-viewport-width: 'none';
~~~

the client may send `DPR` and `Width` headers on requests to both `image-cdn.com` and its own origin, but must not send `Viewport-Width` hints on any request.

# IANA Considerations

Expand Down