Re: Benjamin Kaduk's No Objection on draft-ietf-httpbis-client-hints-14: (with COMMENT)
Yoav Weiss <yoav@yoav.ws> Wed, 17 June 2020 09:34 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 182CD3A086C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Jun 2020 02:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yoav-ws.20150623.gappssmtp.com
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 gbCCWNbGhdb2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Jun 2020 02:34:19 -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 0D5BC3A086A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Jun 2020 02:34:18 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jlTjr-0008QQ-9z for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Jun 2020 08:48:07 +0000
Resent-Date: Wed, 17 Jun 2020 08:48:07 +0000
Resent-Message-Id: <E1jlTjr-0008QQ-9z@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 <yoav@yoav.ws>) id 1jlTjp-0008Ld-Jx for ietf-http-wg@listhub.w3.org; Wed, 17 Jun 2020 08:48:05 +0000
Received: from mail-lj1-x241.google.com ([2a00:1450:4864:20::241]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <yoav@yoav.ws>) id 1jlTjm-000275-9G for ietf-http-wg@w3.org; Wed, 17 Jun 2020 08:48:05 +0000
Received: by mail-lj1-x241.google.com with SMTP id s1so1907850ljo.0 for <ietf-http-wg@w3.org>; Wed, 17 Jun 2020 01:48:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yoav-ws.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0NT0sBwREFCIHmIvAO+Ei3asfI3jLxKk5RID8/zdZNE=; b=0yWV3ZDIZamMjoEUj/GSehSY7TeKweMEWGmGK2RAiLxCgum4U0DiiZfBeLJuTvGV+n ScX8xT1yXNXk1QiTUmGpLNHAA8zfC+8tNbBws1eUF6IBh9JYqq6fKZwNYidj8Lnb4YSy rtn5zsmUr08FvDwLfD3RWSrPZ1f0QaBreM/PI13/59U3R97S1MfrVpIMvFpIFeUP91UH Q+soC2HJW0rYeMOUdZ/CEbVGoAo7eNTAguct4soXrpJ2ywQnERwq1qpo5OtWVs2Llh4D YL+jVIdYUlQCFDexR9Oh7H6nngoCCxoQuA3IwDyXbKtduDFD0f6tA2KjpkQt5bW61U1/ XmbA==
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=0NT0sBwREFCIHmIvAO+Ei3asfI3jLxKk5RID8/zdZNE=; b=NCosRUh5kV5HR/TLuElNF7xslo1fZV1X1oh7jC4l22+QUjJ+YNOG75tQ8QX0RZ6pTJ 3J19sVyS3e4EiWc0an5p3VqD2Zq7vxhamf3ppN3bzMHEViCwH+9En+Gjrj/AmhDMNg8s gzppU/ghOxhjCpG0X0awEYTxKtiYP+jNV92U3QngFCjYidCsts/9Hsf6XnErUmsnhr3m e0jOKtEcTOLLdMMducRX3O/epk3siDS5cYP1WGNBHMJomX+8XPRPylPgLNTdrCg7YL4F zNzRFCrsdnYjMRqwnoPuMWlAFCphTlfUJ6Lt+xujnP7a+H7iI6ulmTooSQNGUB9zQSwh bdEA==
X-Gm-Message-State: AOAM530tCDkSs0rB+kFgtqtErtkCyNXcjiZpO+p/iZfqZqK7ukEo3oGw oBb50Bjl/V8LOEZLG5iCSc4KokgLQ+hsyxGWQUZulQ==
X-Google-Smtp-Source: ABdhPJybfLqWG/fNJs7aOZadllZmzewQ1bYmmxwV+WVxYBDwbFWzHaWUxmN63/ijLmnC5OhNUwwLNfhPwn6JMK0E6Sw=
X-Received: by 2002:a2e:87c2:: with SMTP id v2mr3463038ljj.147.1592383670356; Wed, 17 Jun 2020 01:47:50 -0700 (PDT)
MIME-Version: 1.0
References: <158992178960.5956.2137971544232835817@ietfa.amsl.com>
In-Reply-To: <158992178960.5956.2137971544232835817@ietfa.amsl.com>
From: Yoav Weiss <yoav@yoav.ws>
Date: Wed, 17 Jun 2020 10:47:34 +0200
Message-ID: <CACj=BEiezqmP5AszaCC=jt5igYudGs-QQeejEr-2PFqvKDUbyw@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-client-hints@ietf.org, httpbis-chairs@ietf.org, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>
Content-Type: multipart/alternative; boundary="000000000000049fd305a843b7ea"
Received-SPF: pass client-ip=2a00:1450:4864:20::241; envelope-from=yoav@yoav.ws; helo=mail-lj1-x241.google.com
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: titan.w3.org 1jlTjm-000275-9G 87ca977f866f5b495a8a3fe2b2e327cb
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-httpbis-client-hints-14: (with COMMENT)
Archived-At: <https://www.w3.org/mid/CACj=BEiezqmP5AszaCC=jt5igYudGs-QQeejEr-2PFqvKDUbyw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37776
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>
Thanks for reviewing and apologies for the delayed reply :/ Comments addressed below and incorporated into https://github.com/httpwg/http-extensions/pull/1220 Your review would be appreciated :) On Tue, May 19, 2020 at 10:56 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk 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 > > There are thousands of different devices accessing the web, each with > different device capabilities and preference information. These > device capabilities include hardware and software characteristics, as > well as dynamic user and user agent preferences. Historically, > > nit: should "user-agent" be hyphenated? > In web specifications it typically isn't <https://infra.spec.whatwg.org/#user-agent>. RFC 7231 <https://tools.ietf.org/html/rfc7231> also doesn't seem to hyphen it. > applications that wanted to allow the server to optimize content > delivery and user experience based on such capabilities had to rely > on passive identification (e.g., by matching the User-Agent header > > nit: it feels like "allow the server" would be something that involves > granting permission or the client sending an active signal (as proposed > by this document), as opposed to just the apaplication that "wanted the > server to optimize" and had to make do with such limited signal as was > already available. > OK. Removing "allow the". > > field (Section 5.5.3 of [RFC7231]) against an established database of > user agent signatures), use HTTP cookies [RFC6265] and URL > > nit: hyphenate user-agent again, used as an adjective. > TIL: compound adjective <https://www.grammarbook.com/punctuation/hyphens.asp#:~:text=Rule%201.,is%20called%20a%20compound%20adjective.&text=When%20a%20compound%20adjective%20follows,hyphen%20is%20usually%20not%20necessary.> Done! > > o User agent detection cannot reliably identify all static > variables, cannot infer dynamic user agent preferences, requires > external device database, is not cache friendly, and is reliant on > > nit: singular/plural mismatch ("an external device database" or > "external device databases") > Done > > o Cookie-based approaches are not portable across applications and > servers, impose additional client-side latency by requiring > JavaScript execution, and are not cache friendly. > > (I think I missed a step in why a cookie-based approach inherently > requires javascript execution, though maybe it doesn't matter.) > Essentially, if you want to dynamically set your cookies based on client-side information, you need javascript to do that. > Proactive content negotiation (Section 3.4.1 of [RFC7231]) offers an > alternative approach; user agents use specified, well-defined request > headers to advertise their capabilities and characteristics, so that > > Chasing the reference, it's not clear that it supports quite this strong > of a statement: in addition to the explicit negotiation fields, it also > allows using implicit characteristics such as client IP address and > User-Agent. > Would ending that section with the following work? ", so that servers can select (or formulate) an appropriate response, based on those request headers (or on other, implicit characteristics)." > Section 2.1 > > access of third parties to those same header fields. Without such an > opt-in, user agents SHOULD NOT send high-entropy hints, but MAY send > low-entropy ones [CLIENT-HINTS-INFRASTRUCTURE]. > > It looks like the reference only defines a registry for low-entropy > hints, and we are inferring that any hints not listed in that table are > to be treated as "high-entropy". Perhaps we could reword both > directions of this directive to refer only to the registry of > low-entropy hints (e.g., "SHOULD NOT send hints that are not listed in > [registry]")? > Makes sense. > > Implementers need to be aware of the passive fingerprinting > implications when implementing support for Client Hints, and follow > the considerations outlined in the Security Considerations > (Section 4) section of this document. > > side note: in some sense the Accept-CH mechanism transforms it from a > passive to an active fingerprinting mechanism. > Good point! Removed "passive" here. > > Section 2.2 > > information in them. When doing so, and if the resource is > cacheable, the server MUST also generate a Vary response header field > (Section 7.1.4 of [RFC7231]) to indicate which hints can affect the > selected response and whether the selected response is appropriate > for a later request. > > side note: I suspect the answer I want is already present with a > detailed reading of RFC 7231, but I wonder if it's worth saying > something here about whether the Vary response header could/should > include registered client hint header field names that were not present > in the request in question. > https://tools.ietf.org/html/rfc7231#section-7.1.4 implies that Vary can be set to header names that are missing from the request. ("or lack thereof") I'm not sure we should mention that explicitly here. > Section 3.1 > > Based on the Accept-CH example above, which is received in response > to a user agent navigating to "https://example.com", and delivered > over a secure transport, a user agent will have to persist an Accept- > CH preference bound to "https://example.com". It will then use it > > What level of requirement is implied by "will have to" here? IIUC, it's > just that "if anything is persisted, it must be keyed on" but with no > obligation to do any persistence. If so, perhaps a wording like "any > persisted Accept-CH preference will be bound to" would be better? > The normative requirement in the paragraph above it is SHOULD. I'll modify the wording to your suggested one. > > for navigations to e.g. "https://example.com/foobar.html", but not to > e.g. "https://foobar.example.com/". It will similarly use the > preference for any same-origin resource requests (e.g. to > > nit: comma after "e.g." (throughout). > OK > > "https://example.com/image.jpg") initiated by the page constructed > from the navigation's response, but not to cross-origin resource > requests (e.g. "https://thirdparty.com/resource.js"). This > preference will not extend to resource requests initiated to > "https://example.com" from other origins (e.g. from navigations to > "https://other-example.com/"). > > Perhaps thirdparty.example and other.example, to stay within the BCP32 > space? > Done > > Section 3.2 > > When selecting a response based on one or more Client Hints, and if > the resource is cacheable, the server needs to generate a Vary > response header field ([RFC7234]) to indicate which hints can affect > the selected response and whether the selected response is > appropriate for a later request. > > Is BCP 14 language approprite here? > Indeed. Changed to SHOULD. > Above example indicates that the cache key needs to include the Sec- > CH-Example header field. > > nit: please add the article "the" to make this a complete sentence. > Yup > > Section 4 > > While I don't expect that I can tell the major browser vendors anything > new about the privacy considerations to client hints, I do think that we > should give some guidance to implementors of other HTTP clients, who may > not have such extensive depth of knowlege, on the general landscape in > which this mechanism is set. The subsections hereof do a great job > covering a lot of relevant details and specific factors to consider; > thank you! I think it may also be appropriate to have some more generic > lead-in text, noting that in the worst case, merely converting a passive > fingerprinting mechanism to an active fingerprinting mechanism with > server opt-in does not actually provide any privacy benefit (the worst > case being when all servers ask for all the data and clients accede)! > While we might hope that the need to jump through an extra hoop to > access fingerprinting information might dissuade some servers from > asking for it, it seems imprudent to assume that it will happen, so in > order to obtain real privacy benefit there needs to be some additional > policy controls in the client and in what hints are defined/implemented. > As I mentioned already, we already have a lot of the details for how to > apply such policy controls, and limitations to only define hints that > expose information already available in other means; what I'd like to > see is the high-level picture that ties them together. > > OK. Added something. I'd appreciate your review to see if it matches what you had in mind. > Section 4.1 > > upon it. 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 > > I think this [4] is the same as [UA-CH]. > It's pointing to a specific section of UA-CH. I'm not sure if this is critical. > > Also, use of the first person ("we") is somewhat unusual in RFC style. > Changed. > > 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. > > As written, this is a fairly weird condition. What constitutes > "available to the application via other means"? Does "put up an > interstitial until the user provides the information in question" count? > Changed to "not made available to the application by the user agent" > > o Entropy - Exposing highly granular data can be used to help > identify users across multiple requests to different origins. > Reducing the set of header field values that can be expressed, or > restricting them to an enumerated range where the advertised value > is close but is not an exact representation of the current value, > > nit: "close to" seems like it would scan better. > Yup > > Different features will be positioned in different points in the > space between low-entropy, non-sensitive and static information (e.g. > user agent information), and high-entropy, sensitive and dynamic > information (e.g. geolocation). 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. > > How about on a per-origin basis (and, e.g., domain reputation)? An > "entropy budget" where an origin that asks for too many distinct hints > won't get all of them? > Those are definitely policies that user agents can apply (e.g. one concrete proposal that looks a lot like your "entropy budget" is https://github.com/bslassey/privacy-budget) > (I also wonder if a descriptive "may wish to have" is better than the > normative "MAY", here.) > Sure. > > o 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. > > Am I reading things right that this document does not define any such > delegation mechanisms but is just admitting the possibility of such > mechanisms being defined in the future? I'd suggest clarifying up in > §2.1 with a parenthetical (akin to the "outlined below" note about the > opt-in mechanism). > Added an "(as outlined in {{CLIENT-HINTS-INFRASTRUCTURE}})" clarification to 2.1 > Implementers SHOULD support Client Hints opt-in mechanisms and MUST > clear persisted opt-in preferences when any one of site data, > browsing history, browsing cache, cookies, or similar, are cleared. > > Who is the target audience for this SHOULD? If it's just "people > implementing this document", it seems ineffectual, and if it's any > broader scope it seems unenforcable. > Removed the SHOULD here as it's already defined elsewhere that high entropy hints require an opt-in. Also changed "implementers" to "user agents". > Section 4.3 > > Research into abuse of Client Hints might look at how HTTP responses > that contain Client Hints differ from those with different values, > > nit: what are "responses that contain Client Hints"? We have discussed > Accept-CH header fields in responses, and client hints in requests, but > the only mention I recall of hints in responses was in the Vary header > field, and it's not clear that that is what was intended. > Good catch! Changed to "responses to requests that contain Client Hints". > Section 5 > > While HTTP header compression schemes reduce the cost of adding HTTP > header fields, sending Client Hints to the server incurs an increase > in request byte size. Servers SHOULD take that into account when > > nit: I wonder if this would be more clear as: > > % Sending Client Hints to the server incurs an increase in request byte > % size. Some of this increase can be mitigated by HTTP header > % compression schemes, but each new hint will still lead to some > % increased bandwidth usage. Servers SHOULD [...] > Changed. > > Section 7.1 > > I'm not sure I understand why [FETCH] is listed as a normative > reference. > Moved it to be informative. > > I find it amusing that we reference both 7231 and 7234 for Vary, though > to my untrained eye the current references both seem appropriate in > their respective locations. > > Section 7.2 > > If [CLIENT-HINTS-INFRASTRUCTURE] is to be the source of truth for > low-entropy (and, by deduction) high-entropy hints, it seems like it > should be normative. > Moved.
- Benjamin Kaduk's No Objection on draft-ietf-httpb… Benjamin Kaduk via Datatracker
- Re: Benjamin Kaduk's No Objection on draft-ietf-h… Yoav Weiss
- Re: Benjamin Kaduk's No Objection on draft-ietf-h… Benjamin Kaduk
- Re: Benjamin Kaduk's No Objection on draft-ietf-h… Yoav Weiss
- Re: Benjamin Kaduk's No Objection on draft-ietf-h… Mark Nottingham
- Re: Benjamin Kaduk's No Objection on draft-ietf-h… Benjamin Kaduk
- Re: Benjamin Kaduk's No Objection on draft-ietf-h… Yoav Weiss