Subject: Re: [httpwg/http-extensions] Requiring Accept-CH (#284)

From: HTTP issue updates <[email-masked]>
Date: Thu, 09 Feb 2017 02:58:08 -0800

Please note that such a requirement will significantly reduce the capability of servers to adapt the main HTML document to viewport dimensions, network conditions, etc. So while I understand the need to reduce passive fingerprinting, I think the decision should be on a per-hint basis and based on the info that the hints actually expose.

For example, I'd argue in the case of viewport dimensions and screen density, that info is already exposed in the UA string (along with other, more specific data on the user's device and browser), and the hints only make it easier to adapt content without a device DB, while not necessarily increasing fingerprinting capabilities.

As for network conditions, while exposing them may add data to the fingerprinter's toolbox, they can vary wildly between sessions (and even during a session), so I'd argue they don't necessarily increase fingerprinting capabilities.

-- 
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/284#issuecomment-278610132

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 11 Feb 2017 01:47:00 -0800

CH is not just for browsers. There are other types of clients: native apps that talk to own backends, internal HTTP clients that talk to image servers, and so on. As such, I don't think we're in a position to make sweeping formal (MUST) requirements for how/when support for these hints should be advertised or when they can be sent. 

Existing section for Accept-CH starts with "servers can advertise support".. which, I think, is the right approach. The other relevant section is...

https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-03#section-2.1

> 2.1.  Sending Client Hints
> 
>   Clients control which Client Hint headers and their respective header
>   fields are communicated, based on their default settings, user
>   configuration and/or preferences.  The user can be given the choice
>   to enable, disable, or override specific hints.
>
>   The client and server, or an intermediate proxy, can use an opt-in
>   mechanism to negotiate which fields should be reported to allow for
>   efficient content adaption.

I believe the above already covers all the cases we brought up here and on the list?

-- 
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/284#issuecomment-279133287

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 11 Feb 2017 03:37:15 -0800

If hints are capable of uniquely identifying a user's device then the data communicated is personal data. If it concerns a European resident then before it is processed, meaning collected or used, the user must give their consent. This is a legal requirement in Europe, which will be strongly enforced after the GDPR and the new ePrivacy Regulation come into force next year.
This inevitably means that sending an Accept-CH requires opt-in consent. If the browser does not require it then all the sites (in Europe or elsewhere if directed at European residents) will have to.

-- 
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/284#issuecomment-279138444

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 11 Feb 2017 04:43:42 -0800

That may be true for hints that are capable of uniquely identifying a user, but irrelevant for hints that are not. Therefore, we shouldn't impose a rule requiring an opt in for all hints.

-- 
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/284#issuecomment-279141602

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 11 Feb 2017 05:29:03 -0800

The more hints the more entropy. If an origin can place Accept-CH they can use that to single-out the user without their knowledge, unless opt-in is required. 
How could entropy be reduced? Can it be quantified?

-- 
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/284#issuecomment-279143807

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 11 Feb 2017 07:20:07 -0800

@michael-oneill I think we may be talking past each other here. Everything you describe is already possible within the provided text in the draft - e.g. if you're building a browser you can provide necessary opt-in's and all the rest; if you're building an app you can prompt the user to accept terms of service on install, and so on. How the various implementations chose to surface this is up to them; we're not in a position to enforce anything 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/284#issuecomment-279151499

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 12 Feb 2017 17:15:22 -0800

@igrigorik I recognize that Client Hints could be used by HTTP implementations that aren't a browser being used by a user. It seems like in most (or all?) of those suggested cases, a developer controls the server and the client and sending `Accept-CH` wouldn't be a challenge. (That said, it might be that this could be a SHOULD, or a requirement that explicitly describes the situations where it doesn't need to be followed.)

While the current language provides flexibility to the client implementation, I think there are interoperability reasons to specify conditions that support user privacy here. Providing the expectation in the spec that the server receives Client Hints only if it has asked for them means that developers won't have to check UA implementations individually to try to figure out how to receive hints and UA implementers will have a common required condition which will benefit all users' privacy in providing for more detectability.

-- 
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/284#issuecomment-279272786

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 12 Feb 2017 17:23:33 -0800

@yoavweiss that User-Agent strings have, in some recent mobile implementations, increased their entropy and revealed more about the specific hardware isn't necessarily a good thing or something we should accept and duplicate in actual standards. The browser on the laptop I'm using right now doesn't reveal the specific model of MacBook that I'm using, or the size or density of its screen in the `User-Agent` or other HTTP headers. 

I agree that looking up info in device databases based on browser sniffing is not the ideal case; I don't think that means we should increase the presence of explicit device info in all HTTP requests. `Accept-CH` would be a data minimization method more similar to existing JavaScript implementations; sites that need the information can ask for it and ask for it in a way that's visible.

-- 
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/284#issuecomment-279273517

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 24 Feb 2017 09:38:19 -0800

PTAL https://github.com/httpwg/http-extensions/pull/305. 

-- 
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/284#issuecomment-282354086

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 24 Feb 2017 12:18:28 -0800

What is the purpose of sending Client Hints to embedded third-parties anyway? 
How does the user know  a response to an embedded subresource contains Accept-CH? There should at least be a user agent setting so third-parties do not receive hints, preferably the default similar to the way third-party cookies are now blocked (somewhat) in Safari. A drive-by Accept-CH will be even more of a privacy risk especially if the user is never informed.

-- 
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/284#issuecomment-282393991

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 24 Feb 2017 16:21:37 -0800

It is common for sites to host resources on a CDN whose origin != document origin -- e.g. I host my images on a third-party image service and I want said CDN to optimize the resources based on advertised CH hints. Note that there is (already) nothing preventing the document from exporting the same data.. most commonly by appending it into the URL of the subresource.

Which is to say, and to reiterate once more, CH **does not** expose anything that was not previously available to the document via JavaScript and/or CSS.

-- 
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/284#issuecomment-282440965

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 25 Feb 2017 01:33:26 -0800

It exposes it to any resource immediately, without needing to return script in html which then has to return information in another request. It makes fingerprinting, already recognised as a privacy risk, much easier, and less detectable. 
User agents should have default settings that block Client Hints. This could be qualified on a per origin basis by DNT or a new Permission that puts the user in control.

-- 
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/284#issuecomment-282472678

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 25 Feb 2017 01:36:33 -0800

or alternatively invent a mechanism for limiting the entropy

-- 
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/284#issuecomment-282472828

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 25 Feb 2017 04:33:09 -0800

probably we can have an option for whitelisting / blacklisting the domains client hints should be sent to as a meta tag as well (CSP-style)

-- 
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/284#issuecomment-282481180

---

From: HTTP issue updates <[email-masked]>
Date: Sat, 25 Feb 2017 09:03:10 -0800

> User agents should have default settings that block Client Hints. This could be qualified on a per origin basis by DNT or a new Permission that puts the user in control.

As I said earlier—see https://github.com/httpwg/http-extensions/issues/284#issuecomment-279151499—our guidance in the spec allows for this and we do recommend that they use Accept-CH as an opt-in. I'm not against DNT or additional permissions, but we're not in a position to make these policy decisions here; those decisions need to be made by the implementers. I don't think we're going to get much further in this discussion in this forum.

-- 
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/284#issuecomment-282496922

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 26 Feb 2017 21:13:24 -0800

And to be clear, this spec is for the protocol aspects of CH. We need to note the privacy and security considerations, but how it's actually used is application-specific, and the place that's being done for Web browsers is the Fetch spec. 

-- 
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/284#issuecomment-282629843

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 26 Feb 2017 21:48:59 -0800

Closed #284.

-- 
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/284#event-977810451

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 26 Feb 2017 21:48:58 -0800

Resolved via https://github.com/httpwg/http-extensions/pull/305.

-- 
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/284#issuecomment-282633883