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

Yoav Weiss <> Wed, 17 June 2020 08:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5166B3A07C0 for <>; Wed, 17 Jun 2020 01:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2cQICNVIxg32 for <>; Wed, 17 Jun 2020 01:52:27 -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 84D343A07BF for <>; Wed, 17 Jun 2020 01:52:27 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jlTno-0001w4-Pc for; Wed, 17 Jun 2020 08:52:12 +0000
Resent-Date: Wed, 17 Jun 2020 08:52:12 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jlTnn-0001vJ-EA for; Wed, 17 Jun 2020 08:52:11 +0000
Received: from ([2a00:1450:4864:20::141]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jlTnl-0002FY-7D for; Wed, 17 Jun 2020 08:52:10 +0000
Received: by with SMTP id c21so809241lfb.3 for <>; Wed, 17 Jun 2020 01:52:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UNSRwvR2Lnz74SIdcVNxSxDRnxsla+kmBJgafbytSkA=; b=mUOPxk15unmGomTv7iPAgcVB2PBGt3f0bRgYPLhES82EwaS6pYOolRNOR8NJzG2tW9 +7ZA6daSruqebnuBQyRM166MFbGc7Nr8VlXCjE9MFFNLuMdqF/xNfwy2zxe4xPV5Sb9c UEDyk0NJVeaVlYR7thsNd9YxD+IaEqlDIBY5zO9pZtragpBLeKeKIvtd1GtRZd2mil4Z 8OjVzuC8KoP6HUdhUJOGI29xEZsRFvTxWMU+XEbnQ6GAwr4+PV+v7Yo0B2zGdn9YLyOw hKHZ9P44flUyfswJ/19Nw2A9nI3OUy/3MdB+4DiZuRV5P2tnX67MviwhCxhzMbKK5Tku +Bcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UNSRwvR2Lnz74SIdcVNxSxDRnxsla+kmBJgafbytSkA=; b=enfEkmxEkv11vAAQTIHEnII1grm+wMgpZTIqoz9JPL7nwBr7GRz2cibUXM0cyx1yxt MitZybEqjToKUbhNZsHpIu7+Y2G9+HgTL2bmQDK/RWtG1WzoPOXjoaeejYXDO/zVWojw f1dhYj+lw6xvOsd3CHb7G0aO0Gol9zMFnCsl76twoZ9pBojxpU6ut7N2U/oBPZivKtBI J+lOOWis9FJJcmbA0Y6eTZeB2lBtSEL9EfYkF+ygorRylub/rpdFaEXx/JaO7VnXV/jW tZwGeCG1XW///9M9qSAqvS7TbOcJVypWqy20w7ZRkzj4mwR4dL23/G0YnuLxLfPMbDHG GVSg==
X-Gm-Message-State: AOAM532lPX5w7Ilx8DzQemd6V0zIIZnWLPGCSwTQVPI8P0Hn5E4n965r sgsPRhE+OD5mGmgN3nPBzdvBuZLeNiSLxLxfZtFR+g==
X-Google-Smtp-Source: ABdhPJx9BIX2uTXZLV6kHA/XG5xwGKSGcDroAglzakN52Y/uUyzJtQbZw9pZxRAJkjMQxpF3Rvuw0xZpjI068F7bq2U=
X-Received: by 2002:ac2:5f07:: with SMTP id 7mr4080742lfq.132.1592383917292; Wed, 17 Jun 2020 01:51:57 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Yoav Weiss <>
Date: Wed, 17 Jun 2020 10:51:41 +0200
Message-ID: <>
To: Alissa Cooper <>
Cc: The IESG <>,,, " Group" <>, Mark Nottingham <>
Content-Type: multipart/alternative; boundary="000000000000bc965905a843c560"
Received-SPF: pass client-ip=2a00:1450:4864:20::141;;
X-W3C-Hub-Spam-Status: No, score=-8.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jlTnl-0002FY-7D c62b811290e50bcd72adbd3a5cf5d33c
Subject: Re: Alissa Cooper's No Objection on draft-ietf-httpbis-client-hints-14: (with COMMENT)
Archived-At: <>
X-Mailing-List: <> archive/latest/37780
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Thanks for reviewing, apologies for the delay responding... :/

Comments addressed in

Your review will be appreciated :)

On Thu, May 21, 2020 at 3:45 PM Alissa Cooper via Datatracker <> wrote:

> 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?

Active fingerprinting can be monitored and controlled by the user agent or
security researchers, so in that sense, it's not "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.

Added "turning passive fingerprinting vectors into active ones".

> 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.

I adopted Benjamin's proposal.

> 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?

Theoretically, user agents can have permission prompts for sites that try
to access high-levels of entropy (either through a single high-entropy
vector, or through many lower entropy ones).
The sentence is trying to explain that doing so would be difficult, as
users are not likely to understand and take into consideration the
trade-offs involved.
I'd appreciate proposals to make that sentence clearer :)

> 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.

Added "User agents supporting Client Hints features which send certain
information to opted-in servers SHOULD avoid sending the equivalent
information passively."