Subject: Re: [httpwg/http-extensions] Scope Accept-CH opt-in to same origin (#373)

From: HTTP issue updates <[email-masked]>
Date: Sat, 22 Jul 2017 15:17:09 +0000 (UTC)

arturjanc commented on this pull request.

> @@ -257,11 +257,13 @@ The Content-DPR response header field indicates to the client that the server ha
 
 # Security Considerations
 
-The request header fields defined in this specification expose information that is already available to Web applications in the browser runtime itself (e.g., using JavaScript and CSS). For example, the application can obtain viewport width, image display width, and device pixel ratio via JavaScript, or through the use of CSS media queries and unique resource URLs even if JavaScript is disabled. However, servers that gather this information through such mechanisms are typically observable (e.g., you can see that they're using JavaScript to gather it), whereas servers' use of the header fields introduced by this specification is not observable. Section 2.1 discusses potential mitigations.
+The request header fields defined in this specification, and those that extend it, expose information about the user's environment to enable proactive content negotiation. Such information may reveal new information about the user and implementers ought to provide policies and mechanisms to control how and when such hints are advertised.

I'm worried about this being a little vague. It seems that there would be a benefit to specifying the "policies and mechanisms" mentioned in this para because they might be crucial to ensuring the privacy properties of a given implementation.

-For example, sending Client Hints on all requests can make information about the user's environment available to origins that otherwise did not have access to this data, which may or may not be the desired outcome - e.g. this may enable an image optimization service to deliver a tailored asset, and it may reveal same information about the user to other origins that may not have had access to it before. Similarly, sending highly granular data, such as image and viewport width may help identify users across multiple requests. Restricting such field values to an enumerated range, where the user agent advertises a threshold value that is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting.
+The hint request headers ought not to provide new information that is otherwise not available to the application via HTML, CSS, or JavaScript. For example, this specification defines Viewport-Width, Width, and DPR header fields, all of which can be obtained via JavaScript, or through the use of CSS media queries and unique resource URLs even if JavaScript is disabled.

I would make this stronger:
1. Hints shouldn't provide information that isn't available via the usual channels.
2. Hints sent for subresource requests shouldn't carry information not available to the provider of the subresource unless the first-party opts into sending hints (note that this, combined with the same-origin restriction, would likely suggest some form of double-keying)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/373#pullrequestreview-51624553

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 28 Jul 2017 18:34:41 +0000 (UTC)

@igrigorik pushed 2 commits.

751cc62  extensible list of hints
4e0f1d6  double-keying and secure contexts

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/373/files/a80ad96304c280ed260f75730d77a1f1150b2a56..4e0f1d6f474402e488e90fce223076f9c7378ed1

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 28 Jul 2017 18:38:51 +0000 (UTC)

@arturjanc thanks for the review. Took another run, with a few large updates:

- Accept-CH and Accept-CH-Lifetime should be processed for responses originating from potentially trustworthy origins (i.e. HTTPS-only)
- Accept-CH-Lifetime preference should be double-keyed, per discussion in #372.
- Consolidated security guidance in one section + tried to rewrite that in light of above updates.

I couldn't find any good existing spec examples on double-keying, so would appreciate any guidance on how to explain it here well. 

@mnot ptal as well, as this is a substantive update.

/cc @tarunban @yoavweiss

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/373#issuecomment-318731432