Subject: Alissa Cooper's No Objection on draft-ietf-httpbis-client-hints-14: (with COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Thu, 21 May 2020 06:45:09 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-httpbis-client-hints-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-hints/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1: "passively providing such information allows servers to silently
fingerprint the user" --> isn't pretty much all fingerprinting silent?

Moreover, I think it would be good to explain in Section 1 that Client Hints
provides a way for servers to actively fingerprint clients rather than doing it
passively.

Section 2.1: "Without such an opt-in, user agents SHOULD NOT send high-entropy
hints, but MAY send low-entropy ones [CLIENT-HINTS-INFRASTRUCTURE]." --> Given
the use of normative language here, I think either this doc or the referenced
doc needs to define what high-entropy hints are. Are all hints not defined as
low-entropy considered to be high-entropy? If so, then I think a change along
the lines of what Benjamin proposed is warranted. If not (as the text in
Section 4.1 sort of indicates), then this doc needs to specify what
high-entropy hints are.

Section 4.1: "user choice mechanisms that allow users to balance privacy
concerns against bandwidth limitations" --> This is vague enough that I don't
understand what it is talking about. What is an example of such a mechanism?

Section 4.1:

   "The header-based opt-in means that we can remove passive
   fingerprinting vectors, such as the User-Agent string (enabling
   active access to that information through User-Agent Client Hints
   [4]), or otherwise expose information already available through
   script (e.g. the Save-Data Client Hint [5]), without increasing the
   passive fingerprinting surface."

How about changing that "we can" into a recommendation to do so? In other
words, could this document recommend that if User-Agents are sending certain
information in Client Hints that they stop sending it or similar information
via other headers? Maybe this is too obvious, but given the breadth of HTTP
clients in the wild, it may help to state the obvious.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 May 2020 09:25:52 -0700

> https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-hints/

I actually don't think this characterization is correct. Specifically:

- When something that clients unilaterally send now is replaced by a client
hint (e.g., User-Agent) then this changes fingerprinting from passive to
active
- When something that you currently have to call a JS API to get is
replaced by a client hint, then this makes it *more* passive because the
server only has to take one action to get the hint indefinitely.

-Ekr