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

Alissa Cooper via Datatracker <> Thu, 21 May 2020 13:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E472B3A0CD6 for <>; Thu, 21 May 2020 06:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q55IWBwdLHXi for <>; Thu, 21 May 2020 06:48:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 868433A0CD4 for <>; Thu, 21 May 2020 06:48:32 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jblVl-0006Cb-Dc for; Thu, 21 May 2020 13:45:25 +0000
Resent-Date: Thu, 21 May 2020 13:45:25 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jblVj-0006Bl-J2 for; Thu, 21 May 2020 13:45:23 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jblVg-00028s-VU for; Thu, 21 May 2020 13:45:23 +0000
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 07D743A0C6B; Thu, 21 May 2020 06:45:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper via Datatracker <>
To: "The IESG" <>
Cc:,,, Mark Nottingham <>,
X-Test-IDTracker: no
X-IETF-IDTracker: 7.0.0
Auto-Submitted: auto-generated
Reply-To: Alissa Cooper <>
Message-ID: <>
Date: Thu, 21 May 2020 06:45:09 -0700
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jblVg-00028s-VU 8f8b44c925bd22a4b45534de118f1288
Subject: Alissa Cooper's No Objection on draft-ietf-httpbis-client-hints-14: (with COMMENT)
Archived-At: <>
X-Mailing-List: <> archive/latest/37704
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


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

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.