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

Alissa Cooper via Datatracker <noreply@ietf.org> Thu, 21 May 2020 13:48 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E472B3A0CD6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 21 May 2020 06:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q55IWBwdLHXi for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 21 May 2020 06:48:32 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868433A0CD4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 21 May 2020 06:48:32 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jblVl-0006Cb-Dc for ietf-http-wg-dist@listhub.w3.org; Thu, 21 May 2020 13:45:25 +0000
Resent-Date: Thu, 21 May 2020 13:45:25 +0000
Resent-Message-Id: <E1jblVl-0006Cb-Dc@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <noreply@ietf.org>) id 1jblVj-0006Bl-J2 for ietf-http-wg@listhub.w3.org; Thu, 21 May 2020 13:45:23 +0000
Received: from mail.ietf.org ([4.31.198.44]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <noreply@ietf.org>) id 1jblVg-00028s-VU for ietf-http-wg@w3.org; Thu, 21 May 2020 13:45:23 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (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 <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-httpbis-client-hints@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, Mark Nottingham <mnot@mnot.net>, mnot@mnot.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.0.0
Auto-Submitted: auto-generated
Reply-To: Alissa Cooper <alissa@cooperw.in>
Message-ID: <159006870863.12702.17567729594777906050@ietfa.amsl.com>
Date: Thu, 21 May 2020 06:45:09 -0700
Received-SPF: pass client-ip=4.31.198.44; envelope-from=noreply@ietf.org; helo=mail.ietf.org
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: titan.w3.org 1jblVg-00028s-VU 8f8b44c925bd22a4b45534de118f1288
X-Original-To: ietf-http-wg@w3.org
Subject: Alissa Cooper's No Objection on draft-ietf-httpbis-client-hints-14: (with COMMENT)
Archived-At: <https://www.w3.org/mid/159006870863.12702.17567729594777906050@ietfa.amsl.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37704
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=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 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.