Subject: Re: [httpwg/http-extensions] Accept-CH-Lifetime privacy concerns (#372)

From: HTTP issue updates <[email-masked]>
Date: Fri, 19 Jan 2018 09:43:46 -0800

@arturjanc thanks, I think we're converging on a good solution here.

a) Opened a feature request against FP: https://github.com/WICG/feature-policy/issues/129
b) Assuming we all agree on the above, I'd propose the following update in CH...

```diff
diff --git a/draft-ietf-httpbis-client-hints.md b/draft-ietf-httpbis-client-hints.md
index 91ebc81..4455ff0 100644
--- a/draft-ietf-httpbis-client-hints.md
+++ b/draft-ietf-httpbis-client-hints.md
@@ -100,7 +100,7 @@ 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. The client and server can use an opt-in mechanism outlined below to negotiate which fields should be sent to allow for efficient content adaption.
+Clients control which Client Hints are sent in requests, based on their default settings, user configuration, and server preferences. The client and server can use an opt-in mechanism outlined below to negotiate which fields should be sent to allow for efficient content adaption, and optinally use additional mechanisms to negotiate delegation policies that control access of third parties to same fields.

 Implementers should be aware of the passive fingerprinting and network information disclosure implications when implementing support for Client Hints, and follow the considerations outlined in "Security Considerations" section of this document.

@@ -263,6 +263,7 @@ Transmitted Client Hints header fields SHOULD NOT provide new information that i

 Implementers ought to consider both user and server controlled mechanisms and policies to control which Client Hints header fields are advertised:

+  - Implementers SHOULD restrict delivery of some or all Client Hints header fields to the opt-in origin only, unless the opt-in origin has explicitly delegated permission to another origin to request Client Hints header fields.
   - 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.
   - Implementations specific to certain use cases or threat models MAY avoid transmitting some or all of Client Hints header fields. For example, avoid transmission of header fields that can carry higher risks of linkability.
```

To recap, this would leave us with:
- CH is HTTPS only
- Delivery of hints is bound to origin and requires explicit origin opt-in
- FP controls 3P delegation for UAs, with custom default policies for each hint:
  - By default most hints are scoped with FP policy of `self`, which means that 1P has to explicitly allow 3P's to request access to the hint. 
  - One exception today is Save-Data, which we believe (and as currently implemented in Chrome) should have a default FP policy of `*`.

Does that land us in a good place to resolve this thread? :-)

-- 
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/issues/372#issuecomment-359038699

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 22 Jan 2018 04:47:04 -0800

Looks good to me -- thanks for all the work on this, Ilya!

-- 
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/issues/372#issuecomment-359413549

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 22 Jan 2018 11:42:25 -0800

LGTM2! :)

-- 
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/issues/372#issuecomment-359541356

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 25 Jan 2018 07:49:41 +0000 (UTC)

Closed #372.

-- 
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/issues/372#event-1441091713

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 24 Jan 2018 23:49:41 -0800

Excellent, looks like we've landed in a good place! I've updated the CH spec and resolving this issue. Let's continue the FP discussion in WICG/feature-policy#129. 

Thanks all for your patience and help here!

-- 
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/issues/372#issuecomment-360387378