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

From: HTTP issue updates <[email-masked]>
Date: Wed, 02 Aug 2017 22:23:50 -0700

mnot commented on this pull request.

A few things I saw. Overall I think this approach looks good. Still need to see the whole spec after changes before doing a final review; need to see it in situ (and I suspect others will too).

> @@ -101,9 +102,9 @@ A Client Hint request header field is a HTTP header field that is used by HTTP c
 
 ## Sending Client Hints
 
-Clients control which Client Hints are sent in requests, based on their default settings, user configuration and/or preferences. Implementers might provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. Implementations specific to certain use cases or threat models might avoid transmitting these header fields altogether, or limit them to secure contexts or authenticated sessions. Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging.
+Clients control which Client Hints are sent in requests, based on their default settings, user configuration and/or preferences. The client and server, or an intermediate proxy, can use an opt-in mechanism outlined below to negotiate which fields should be sent to allow for efficient content adaption.

Is the intent of including 'intermediary proxy' to include CDNs, or to also include forward proxies? If it's just CDN/reverse proxies, I'd remove it; it's widely understood that they're acting as a server. 'intermediary proxy' means "forward proxy" and I don't think you want that.

> @@ -127,28 +128,28 @@ For example:
   Accept-CH: DPR, Width, Viewport-Width
 ~~~
 
-When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the origin ({{RFC6454}}) is interested in receiving specified request header fields that match the advertised field-values; same-origin resource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field-values.
+When a client receives Accept-CH from a potentially trustworthy origin ({{SECURE-CONTEXTS}}), or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the origin ({{RFC6454}}) is interested in receiving specified request header fields that match the advertised field-values; same-origin resource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field-values.

This reads as if you can either have a secure origin OR include the HTML meta tag to get Accept-CH processed; is that the intent?

 ~~~ abnf7230
   Accept-CH-Lifetime = #delta-seconds
 ~~~
 
-The field-value indicates that the Accept-CH preference SHOULD be considered stale after its age is greater than the specified number of seconds.
+When a client receives Accept-CH-Lifetime from a potentially trustworthy origin ("opt-in origin"), the field-value indicates that the Accept-CH preference SHOULD be considered stale after its age is greater than the specified number of seconds, and if applicable, persisted as a double-keyed preference that combines the values of the opt-in origin and the potentially trustworthy origin of the resource that initiated the request that received the opt-in preference.

Age in relation to what?

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

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 03 Aug 2017 07:28:50 +0000 (UTC)

martinthomson commented on this pull request.

-When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the application is interested in receiving specified request header fields that match the advertised field-values; subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field-values.
+When a client receives Accept-CH from a potentially trustworthy origin ({{SECURE-CONTEXTS}}), or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the origin ({{RFC6454}}) is interested in receiving specified request header fields that match the advertised field-values; same-origin resource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field-values.

The addition of the reference to SECURE-CONTEXTS is new here, and unnecessary.  The requirement here is not that the context is secure (that's a notion that belongs to the web, not HTTP generally), but that the `Accept-CH` is both authentic and integrity protected.  You should limit the use of `Accept-CH` to HTTPS.

 ~~~ abnf7230

"double-keyed" is a new concept for the protocol here, and one that (again) really only makes sense on the web.  The property that you are looking for is that the persisted state is bound to the origin.  You should allow it to be more narrowly bound, but the point is to constrain its maximum scope.  Choosing a narrower scope is a discretionary thing that might be done by web browsers.

Also, I find the phrasing of this last bit cumbersome and hard to follow.  The point is that permission to persist might be scope (see above).

-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.
+Transmitted Client Hints header fields should not provide new information that is otherwise not available to the application via HTML, CSS, or JavaScript.  Further, 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 advertised value is close but is not an exact representation of the current value, can help mitigate the risk of such fingerprinting as well as reduce possibility of unnecessary cache fragmentation.

The term you are looking for here is "linkability" or "linkable".  The more information that a request contains, the more likely an adversary is to be able to correctly identify two requests as belonging to the same user agent (i.e., link the two).

The claim here (reducing the accuracy of field values) isn't generically true.  I believe that it is true for the hints defined in this document, but the structure of this document is such that it might be taken as a universal truth.  For something like the proposed Geolocation header field, which is a continuous-valued field, this claim would be false (read [Section 13.5 of RFC 6772](https://tools.ietf.org/html/rfc6772#section-13.5) for background).

-Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on.
+Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:
+
+  - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging.
+  - Implementers should support double-keyed Client Hints opt-in requested by potentially trustworthy origins via Accept-CH and Accept-CH-Lifetime header fields, and clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared.

should is not sufficient here: information that is persisted for an origin MUST be reset when any action that is designed to break linkability is executed (clearing cookies is one such action)

-Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on.
+Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:
+
+  - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging.
+  - Implementers should support double-keyed Client Hints opt-in requested by potentially trustworthy origins via Accept-CH and Accept-CH-Lifetime header fields, and clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared.
+  - Implementations specific to certain use cases or threat models may avoid transmitting Client Hints header fields altogether or limit them to authenticated sessions only that already carry identifying information, such as cookies or referer data.

MAY is extremely weak and "may" is even weaker.  It seems like these are generally fixed values, akin to User-Agent, but others thus far proposed (see again Geolocation) aren't.  It seems like the advice here is intended to be generic, so what are the criteria an implementation might use to decide to send or suppress these fields if cookies are not being sent?

-Implementers ought to provide mechanisms and policies to control how and when such hints are advertised. For example, they could require origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on.
+Implementers should consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:
+
+  - Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. However, implementers should also be aware that explaining the privacy implications of passive fingerprinting or network information disclosure to users may be challenging.
+  - Implementers should support double-keyed Client Hints opt-in requested by potentially trustworthy origins via Accept-CH and Accept-CH-Lifetime header fields, and clear remembered opt-in when site data, browsing history, browsing cache, or similar, are cleared.
+  - Implementations specific to certain use cases or threat models may avoid transmitting Client Hints header fields altogether or limit them to authenticated sessions only that already carry identifying information, such as cookies or referer data.
+
+Following the above recommendations should significantly reduce the risks of linkability and passive fingerprinting.

You don't want to make this claim.  It's fairly easy to show it as false.  If your claim is that the incremental increase in linkability (over not sending hints) is reduced significantly, that might be true, but I doubt that also.  This is making a trade-off - if the information is basically already available via User-Agent or script, then this isn't a big increase, but in other cases it could be a big change.

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