Skip to content
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.

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

Define policy-controlled features #696

Closed
wants to merge 1 commit into from

Conversation

eeeps
Copy link
Contributor

@eeeps eeeps commented Sep 24, 2018

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. Those are defined in this PR.
  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 Hints’ policy-controlled feature before appending the Client Hint header.

@@ -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

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

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

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

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

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

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

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

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.

@mnot mnot changed the title Client Hints: define policy-controlled features Define policy-controlled features Nov 30, 2018
@eeeps
Copy link
Contributor Author

eeeps commented Mar 26, 2019

@yoavweiss is adding these definitions to the HTML spec here: whatwg/html@335f566

@mnot @igrigorik Maybe spin up a separate issue to discuss the level which delegation mechanisms should be explained/exampled in the CH spec?

@eeeps eeeps closed this Mar 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

5 participants