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

Yoav Weiss <> Wed, 17 June 2020 09:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 845C63A085D for <>; Wed, 17 Jun 2020 02:30:39 -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 WaKwSmH4gSAl for <>; Wed, 17 Jun 2020 02:30:37 -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 5CD973A085B for <>; Wed, 17 Jun 2020 02:30:37 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jlTiI-0008FT-GE for; Wed, 17 Jun 2020 08:46:31 +0000
Resent-Date: Wed, 17 Jun 2020 08:46:30 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jlTiF-0008Ei-TG for; Wed, 17 Jun 2020 08:46:27 +0000
Received: from ([2a00:1450:4864:20::243]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jlTiD-000286-Pf for; Wed, 17 Jun 2020 08:46:27 +0000
Received: by with SMTP id i27so1814038ljb.12 for <>; Wed, 17 Jun 2020 01:46:25 -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=RZYHxKmVgY15yC/LJE1QB2VoijYqWkeKGR/GSoi/M0M=; b=qtJOFRRXGrK65vyQZiDhmlIb/Uj0d7Y4pImZ8kdrmeqjwchIKSMK9r1vP2FY4NlG4K bNCwI9mFM4FzPmB/MwKWylr01MUo9UvPuP9ORHUeRNTwxnLMiFsjpIWMBdInZaBhA+oo puN/uusU8RehwdAgScEiX4j8pJb74pKJVxxk+x0XSrUq+NDIqMtj80Vjo4kAZVNx9rbU pqYqAaVPruCbIGwgOqYZGjHBHk9phoC+Mf+TWEn7YtfzRBxOO1eQNPKYWVgLEdPs5quv ErFVgkUzVfQnQp722MOGl73AXl9RHk6ovf8nIKEEVY2QY6EOvLO4QbtazbSjdMl09xcA MPMA==
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=RZYHxKmVgY15yC/LJE1QB2VoijYqWkeKGR/GSoi/M0M=; b=GGpYvVQJ9ZikKrOgsdaSCTnXx9nsPhAdcZKTKCzQ7p+kfVroohiyw3KV6wRpG8JfT3 bAnFTostylHLwS6AE9E4SD5nUrrjPA4ERhaZSywN0KQuv7wAfhloEQolNr9j8Q0qN5eD Pgz2YTBLR68NWhSq39T73HeYtjVquttvKDgYiXVhMAAmOxbKrB8WMueaqABf2Tepmip6 esOizJZOAYY7xKZOjjmr+FNLISzkrQI1+lqeFtr6Xa6Pogg/sDtHvPzDddJndmMgrqbo Rdw1z90PouNFqdGhWhqCcF/Q5f7+ro42d5H1jmHJt9lJIt9ASO/kncoqDj3YmLrgY8Ip Ovfg==
X-Gm-Message-State: AOAM533XauvWoqSVMFVOOabAsgdjRP4qiqZPqjUl2tgW1q9sTsWYlNi5 OfazwCIbNNscQDMQV2rGF1CgcGEL5QZfk2PIttbONftW5qs=
X-Google-Smtp-Source: ABdhPJy+qudY9YVN2G4BOGHU5RZSqBAv2yb+sNm/r787FQwT6qVK9jlI1iAKSy8HLFY+FjoZmZqttpcCH04zZrPH1LQ=
X-Received: by 2002:a2e:b0f9:: with SMTP id h25mr3516569ljl.18.1592383573546; Wed, 17 Jun 2020 01:46:13 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Yoav Weiss <>
Date: Wed, 17 Jun 2020 10:45:57 +0200
Message-ID: <>
To: Roman Danyliw <>
Cc: The IESG <>,,, " Group" <>, Mark Nottingham <>
Content-Type: multipart/alternative; boundary="0000000000003f6bb405a843b12e"
Received-SPF: pass client-ip=2a00:1450:4864:20::243;;
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: 1jlTiD-000286-Pf fcf8f84871946fcfd1f542ecb34bb49e
Subject: Re: Roman Danyliw's No Objection on draft-ietf-httpbis-client-hints-14: (with COMMENT)
Archived-At: <>
X-Mailing-List: <> archive/latest/37775
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Thanks for reviewing! Apologies for the delayed reply... :/

On Tue, May 19, 2020 at 8:52 PM Roman Danyliw via Datatracker <> wrote:

> Roman Danyliw 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 4.1.  Per “Therefore, features relying on this document to
> define
> Client Hint headers MUST NOT provide new information that is otherwise not
> available to the application via other means, such as existing request
> headers,
> HTML, CSS, or JavaScript”, would this text allow for a shift in
> permissiveness
> if the references specs changed?  For example, if something was not
> permissible
> in Javascript/HTML/CSS “vX” today, but it was in “vX+1”, would that mean
> that
> additional data could be sent as hints?  I’m exploring the value of
> assigning
> version numbers to HTML, CSS and Javascript to freeze the security
> assumptions.

The underlying assumption is that data exposed in CSS/JS/HTML and Client
Hints is generally equivalent.
If we were to somehow version and  freeze security assumptions for the
former, we'd need to do the same regarding the latter.

> ** Section 4.1.  Per “User agents need to consider the value provided by a
> particular feature vs these considerations, and MAY have different policies
> regarding that tradeoff on a per-feature basis”, IMO more is needed to
> handle
> these tradeoffs.  User agent implementations SHOULD expose this policy
> creation
> process through a rich set of configuration/tuning options and with an API
> to
> enable privacy-minded, third party software to assist the user in making
> choices.

I'm not sure that this is something this document needs to try and enforce.
Different user agents have varying broad philosophies regarding the privacy
tradeoffs of varying features (beyond Client Hints related ones), the
user's ability to make an informed decision on that front, and regarding
enabling third party software to intervene in those decisions. Those
philosophies are not likely to change.

> ** Section 4.1. Per “Implementers SHOULD restrict delivery of some or all
> Client Hints header fields to the opt-in origin only, unless the opt-in
> origin
> has explicitly delegated permission to another origin to request Client
> Hints
> header fields”, how does this delegation happen?

For browsers, that happens using Feature Policy
(processing model