Re: Genart last call review of draft-ietf-httpbis-client-hints-13

Barry Leiba <barryleiba@computer.org> Thu, 07 May 2020 13:11 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 C7C6A3A07D5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 7 May 2020 06:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level:
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 wBlzTIrQcGai for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 7 May 2020 06:11:21 -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 65A253A07BB for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 7 May 2020 06:11:20 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jWgG0-0004al-Td for ietf-http-wg-dist@listhub.w3.org; Thu, 07 May 2020 13:08:08 +0000
Resent-Date: Thu, 07 May 2020 13:08:08 +0000
Resent-Message-Id: <E1jWgG0-0004al-Td@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 <barryleiba@gmail.com>) id 1jWgFz-0004Zz-GF for ietf-http-wg@listhub.w3.org; Thu, 07 May 2020 13:08:07 +0000
Received: from mail-il1-f171.google.com ([209.85.166.171]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <barryleiba@gmail.com>) id 1jWgFw-0004iA-SI for ietf-http-wg@w3.org; Thu, 07 May 2020 13:08:07 +0000
Received: by mail-il1-f171.google.com with SMTP id i16so2120451ils.12 for <ietf-http-wg@w3.org>; Thu, 07 May 2020 06:08:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mOHZQ0U4cXyNz4oFamhC7v42NeHYODTa+Ap60Aw565U=; b=bo3wX5djlkJyDcVMy+G4Zv9BczivwfgmFfZOKKRoA7neVyoFvdprcEvlEdUby2aljN 45TtjZdvQzxbEcIC54d/hD4aaE3Zq0SlUEMk9aXox71kBVYvGWaKlfI3BlzKue7DLzj5 sYWSM02cDvMsulw2nOklZ/Bow7zJ5YizrMEJaCijgOiJnkZCRxBFG0xTzVxOxNN7GWfU LdIgsw+G7/aYchR3r1abXNbX2fpb8xZA1li06tHbhxUu2RRbgFfuWwFEa1d36O+N2wNs +5g+0Jrb1KI7slw48sYrMvtE0nZMgENotGubJWGDJ/Vu6+scIi9R4x9nbwKj7FO7Mmpq Z5Hg==
X-Gm-Message-State: AGi0PuamUWa7Z6CN5MJ/mhEsH/aMDuZMov+RXjzv+x0ltLlww9uRbJkb V8L6kSyGnq/BA+T536Km7S234njP9SKdcoX96Qe5Tjfn
X-Google-Smtp-Source: APiQypKD1p8rEtb7cWGM6v4qlCQr2Hh5BmB/kD6PZ67IIqzYW7Q2kPlsmKl5yXK4zWY4Q1SvlJmmLt6zOJzcGLvxWhc=
X-Received: by 2002:a92:d20a:: with SMTP id y10mr8862299ily.17.1588856873653; Thu, 07 May 2020 06:07:53 -0700 (PDT)
MIME-Version: 1.0
References: <158837305177.24719.21462684096579298@ietfa.amsl.com> <CACj=BEhNqVRxQagFmJ4sbXrn=YOWAYPBqODw_rL7MZbUDjNq5w@mail.gmail.com> <A2613BDC-7577-4BED-8AB5-4799973A1586@ericsson.com> <CACj=BEivQgTBrznaHjmdgOP+1O9fRR7xtX2m_u3JMV4eGfkqFQ@mail.gmail.com> <4243CEA9-67C6-4D3D-A554-9911847CA782@ericsson.com> <CACj=BEhXjntmamP_MMw6kkiXRwOX2B-j8-Ho6EJzPtwPQGoQaQ@mail.gmail.com> <CACj=BEjhnWAQV4Odo3P3yVpmTmVZg=bCgiJrzXE87mCjCzg_YA@mail.gmail.com>
In-Reply-To: <CACj=BEjhnWAQV4Odo3P3yVpmTmVZg=bCgiJrzXE87mCjCzg_YA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Thu, 7 May 2020 09:07:42 -0400
Message-ID: <CALaySJK3RULGGBPeR0E-9-r3MGwWeQA-HmGQ9cQ3imrHkktqqw@mail.gmail.com>
To: Yoav Weiss <yoav@yoav.ws>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "draft-ietf-httpbis-client-hints.all@ietf.org" <draft-ietf-httpbis-client-hints.all@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008dce1c05a50e915d"
Received-SPF: pass client-ip=209.85.166.171; envelope-from=barryleiba@gmail.com; helo=mail-il1-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-5.4
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jWgFw-0004iA-SI bb518641ec634d19c07ca3b8391078ee
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Genart last call review of draft-ietf-httpbis-client-hints-13
Archived-At: <https://www.w3.org/mid/CALaySJK3RULGGBPeR0E-9-r3MGwWeQA-HmGQ9cQ3imrHkktqqw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37586
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>

Please post a revised I-D when you’re ready; thanks.

Barry

On Thu, May 7, 2020 at 6:02 AM Yoav Weiss <yoav@yoav.ws> wrote:

> Addressed the latest points in the PR. Thanks! :)
>
> On Wed, May 6, 2020 at 3:20 PM Yoav Weiss <yoav@yoav.ws> wrote:
>
>>
>>
>> On Wed, May 6, 2020 at 2:43 PM Christer Holmberg <
>> christer.holmberg@ericsson.com> wrote:
>>
>>> Hi Yoav,
>>>
>>> >> I have not received the pull request yet, so I will comment only
>>> based on your e-mail reply :)
>>> >
>>> > Apologies for the delay. PR is now up at
>>> https://protect2.fireeye.com/v1/url?k=0a42e34e-54e25920-0a42a3d5-
>>> >
>>> 869a14f4b08c-11c3f32cbd74f2f2&q=1&e=978d85da-fab3-4523-a8d9-447aa6bdf056&u=
>>> https://github.com/httpwg/http-extensions/pull/1171
>>>
>>> Thanks!
>>>
>>> I think it looks ok.
>>>
>>> BTW, are high-entropy and low-entropy defined and well-known HTTP terms?
>>>
>>
>> I'm not sure. The browser processing model defines a list of low-entropy
>> CH headers:
>> https://wicg.github.io/client-hints-infrastructure/#low-entropy-table
>> I could point at that.
>>
>>
>>> ---
>>>
>>> MaQ3:
>>>
>>> >>>> Related to MaQ2, what happens if a server receives hints that it
>>> does not
>>> >>>> understand, or does not support?
>>> >>>
>>> >>> Servers SHOULD ignore hints they do not understand or do not support.
>>> >>
>>> >> Is there are reason for not using MUST? SHOULD typically means
>>> MUST-unless-X. What would X be?
>>> >>
>>> >> Is there a way for the server to indicate to the client that it did
>>> not understand/support the hints? Whatever the answer, I think it would be
>>> good to have some text about that.
>>> >
>>> > There's no such a mechanism, similar to other request headers.
>>> > Do you have sample text in mind that may make that point clearer?
>>>
>>> Maybe just a note pointing out that there is no mechanism for a server
>>> to inform a client whether it understands and supports the hints.
>>>
>>> ---
>>>
>>> Minor issues:
>>>
>>> MiQ1:
>>>
>>> >>> Section 1 described that proactive content negotiation allows
>>> servers to
>>> >>> silently fingerprint the user agent.
>>> >>>
>>> >>> But, later in the Section it is described that Client Hints also
>>> allow a server
>>> >>> the perform fingerprinting, and the Security Considerations also say
>>> that there
>>> >>> is really no difference.
>>> >>>
>>> >>> So, does Section 1 need to talk about fingerprinting at all?
>>> >>
>>> >> Section 1 describes the fact that traditional (read: pre-Client
>>> Hints) content negotiation methods relied on sending information to all
>>> servers, which enabled passive fingerprinting,
>>> >> and how Client Hints breaks away from that paradigm, by only sending
>>> (high entropy) hints when the server needs them and opts-in to receive them.
>>> >>
>>> >> A server can request the hints even if it doesn't "need" them, but it
>>> wants to do fingerprinting. The client does not know what the server will
>>> do with the information.
>>> >>
>>> >> My point is that the reader should not get an impression that client
>>> hints somehow prevents fingerprinting. It doesn't. The only difference is
>>> that the server has to ask for the information.
>>> >
>>> > Current draft includes " Client Hints mitigate ... privacy concerns of
>>> passive fingerprinting by requiring explicit opt-in and disclosure of
>>> > required headers by the server through the use of the Accept-CH
>>> response header."
>>> > Should that be clearer?
>>>
>>> Yes, I think it is better.
>>>
>>> -------
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>