Re: Migrating some high-entropy HTTP headers to Client Hints.
Ilya Grigorik <igrigorik@google.com> Fri, 30 November 2018 17:04 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 7672F12F295 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 30 Nov 2018 09:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.957
X-Spam-Level:
X-Spam-Status: No, score=-11.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 rr2gIlOkwfML for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 30 Nov 2018 09:04:20 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (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 95FAC130E19 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 30 Nov 2018 09:04:20 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1gSmAC-00063w-14 for ietf-http-wg-dist@listhub.w3.org; Fri, 30 Nov 2018 17:01:12 +0000
Resent-Date: Fri, 30 Nov 2018 17:01:12 +0000
Resent-Message-Id: <E1gSmAC-00063w-14@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <igrigorik@google.com>) id 1gSmA8-00063J-Fj for ietf-http-wg@listhub.w3.org; Fri, 30 Nov 2018 17:01:08 +0000
Received: from mail-yw1-xc2d.google.com ([2607:f8b0:4864:20::c2d]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <igrigorik@google.com>) id 1gSmA6-0003O5-VT for ietf-http-wg@w3.org; Fri, 30 Nov 2018 17:01:08 +0000
Received: by mail-yw1-xc2d.google.com with SMTP id f65so2540726ywc.8 for <ietf-http-wg@w3.org>; Fri, 30 Nov 2018 09:00:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QhDccw7SidGRdv8Mb2U9XVW5ayyPQHCXhHmkGwy10Go=; b=mxpxiBeZwYoK3aTEsa9pCpxqNnO7SAzW17nrzuVEAIbsrcQvQiS8uco8BpOq30P5UW 5JsK2pQ1gRqpvIQOWBHxkQPZUsARhlRp6nEs1EwhJk23ihC4zNP+cIwUuyocxaNQcrvf vLKiN2wS81pWMMl5MyRxHj9hFITPz8S12Qkpp1d94MFlvXYrxl3MQox6AkvsmLzyalOD UbUg+mc/73Cq96KbqEGOHLDe2JKr5dRD6qRcah3l+cnwQNbm28y/6FUGQOne0uinXBXr BQx21YKUha2EEMh02jldhW6KBh4ozyENPBO+ywdeyVTzFYgq1klq3BcaBlYZrirWpTZd o90g==
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=QhDccw7SidGRdv8Mb2U9XVW5ayyPQHCXhHmkGwy10Go=; b=uTlbfIxtdwnfZU27f3W3N+qnDAmpZYKwZXxMEQtgR+5wgYzBXYA5pHclec12YKtuRl UdnGRgkSVflPnfVT3bW/GYb+cQW9UQr6Tge9KrU/t/ZLNw7OgKbW16kQrjFzqLIfyPi/ C28qTIkBZdRzRWDcAhWU3d++Ed8P/dZthriy4oGcg2J4F/blz2JMGSXKfrAZcO6knmcU 68UhoTHTK1qH+srJk1JrfZ42U6DAdXop2yUZUc0a5JSbR62ewmyp0+C1ATJneRPXKg1L PZ6bDYwxwnzYJaud6u79OqnclnI8IQqKXqBY+s9lNdtzeZ8iZXThv3iWv80iRaR/qp2K QM7g==
X-Gm-Message-State: AA+aEWbWMRQxxhFO4wlgH5QQDRHgKh15+TI5N+tnUmkTg+hJ/JX5dINg Xo2OGEqMOYTkpiMrzYkOSF6fgERB+Ih4PttXpeLuY2taNvQ=
X-Google-Smtp-Source: AFSGD/VVqfRum/d+daWk2I15B33y86xQAuku0NbGzE9Tmf7gYPlEBt4SBfcMH42Njd0pfokcPif3d5BRYr4qLgICi8Y=
X-Received: by 2002:a0d:ce87:: with SMTP id q129mr6265990ywd.493.1543597245980; Fri, 30 Nov 2018 09:00:45 -0800 (PST)
MIME-Version: 1.0
References: <CAKXHy=eHiMtXi8vkDYtADHdU0tnUfd3p+Wfy7vSkLgT7cA1W0w@mail.gmail.com> <538F7C6E-EB14-4B49-B9B5-BED066E5838F@mnot.net> <CAKXHy=dhdrbB1i5d5=dXC-kz2kby3-GVwkwHESvP8uwqgrQAwg@mail.gmail.com> <CACj=BEhwdFCq+F3jUt49SsHFmcEj0A7uSfvU=H25-Sn2VWq1vg@mail.gmail.com>
In-Reply-To: <CACj=BEhwdFCq+F3jUt49SsHFmcEj0A7uSfvU=H25-Sn2VWq1vg@mail.gmail.com>
From: Ilya Grigorik <igrigorik@google.com>
Date: Fri, 30 Nov 2018 09:00:09 -0800
Message-ID: <CADXXVKqa48TJvAoNar9oxASiUxrC44Y7ptqYSXYHWm5_301qOA@mail.gmail.com>
To: Yoav Weiss <yoav@yoav.ws>
Cc: Mike West <mkwst@google.com>, "Mark Nottingham (Google Drive)" <mnot@mnot.net>, HTTP working group mailing list <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000867583057be4bdbe"
X-W3C-Hub-Spam-Status: No, score=-24.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1gSmA6-0003O5-VT ecf2a623a3029d7349e07ac6fd8745be
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Migrating some high-entropy HTTP headers to Client Hints.
Archived-At: <https://www.w3.org/mid/CADXXVKqa48TJvAoNar9oxASiUxrC44Y7ptqYSXYHWm5_301qOA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36120
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>
I agree with Yoav on the direction to separate the infrastructure from the features. We started by integrating the two within one spec, but overtime realized that it's hard to cleanly and crisply define many of the concepts without pulling in and having to replicate a whole lot of existing concepts and plumbing from HTML, Fetch, and other specs. This problem also only gets harder when we want to spec browser implementation. Hence the reason why we started pulling out individual hints (e.g. Downlink, RTT, ECT) into NetInfo spec, where those concepts and implementations are defined — bonus, everything is in one place for consistency — and I think it makes sense to do the same for DPR and remaining hints in current spec. +Mike West <mkwst@google.com> I like your proposal for User-Agent and Accept-Language. Most of the CH plumbing is already in place (or close to) in HTML spec, WDYT of defining those hints directly in the HTML spec? On Fri, Nov 30, 2018 at 2:10 AM Yoav Weiss <yoav@yoav.ws> wrote: > > > On Fri, Nov 30, 2018 at 9:47 AM Mike West <mkwst@google.com> wrote: > >> On Fri, Nov 30, 2018 at 1:30 AM Mark Nottingham <mnot@mnot.net> wrote: >> >>> I, for one, welcome our new Client Hint overlords. >>> >>> Personally, I'd like to see these integrated into the current CH >>> document, rather than as separate drafts. CH still needs some work, so it's >>> not like we're going to get it out the door tomorrow. >>> >> > On my list, I want to remove the specific image-related features and move > them to their own specification, with a well defined browser processing > model. > Anything else that's needed to get CH infra "out the door tomorrow"? :) > > >> >> These hints seem pretty clearly separable from the infrastructure upon >> which they're built. I'd prefer to split them out into things-in-themselves >> that we can point developers towards independently, giving ourselves the >> opportunity to explain the rationale and background more coherently than I >> think we'll be able to if we bury these in a subsection of the larger >> document. >> > > Similarly, I'd prefer clear distinctions between "CH as infrastructure" > and "Features that use the CH infrastructure". > We've had a lot of confusion and resistance to "CH the infrastructure" due > to some of the features that rely on it, and clearly separating the two > will enable implementations and user-agents to say "I support the CH > infrastructure, and certain features relying on it, but not feature X". > > From a procedural perspective, we wouldn't want every added feature to > delay "CH as infrastructure" to advance. > > >> >> I'll defer to the group as to how y'all would like to handle these, but >> I'd prefer several short and focused docs as a reader. >> >> -mike >> >> However, it seems like Ilya wants to go in a different direction, based >>> upon the notes we received for Bangkok. >>> >>> Ilya, your thoughts? >>> >>> >>> >>> > On 29 Nov 2018, at 9:22 pm, Mike West <mkwst@google.com> wrote: >>> > >>> > Hey folks, >>> > >>> > Section 9.7 of RFC7231 rightly notes that some of the content >>> negotiation headers user agents deliver in HTTP requests create substantial >>> fingerprinting surface. I think it would be beneficial if we took steps to >>> reduce their prevalence on the wire, and Client Hints looks like a >>> reasonable infrastructure on top of which to build. >>> > >>> > `User-Agent` and `Accept-Language` seem like particularly tasty and >>> low-hanging fruit, and I've sketched out two proposals as proofs of concept: >>> > >>> > * `User-Agent` could be represented as ~four distinct hints: `UA`, >>> `Model`, `Platform`, and `Arch`: >>> https://github.com/mikewest/ua-client-hints is a high-level explainer, >>> and https://tools.ietf.org/html/draft-west-ua-client-hints a sketchy ID >>> for the new headers. >>> > >>> > * `Accept-Language` could be represented as a `Lang` hint: >>> https://github.com/mikewest/lang-client-hint is a high-level explainer, >>> https://tools.ietf.org/html/draft-west-lang-client-hint an equally >>> sketchy ID for the new header. >>> > >>> > I'd appreciate y'all's feedback. Thanks! >>> > >>> > -mike >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>>
- Migrating some high-entropy HTTP headers to Clien… Mike West
- Re: Migrating some high-entropy HTTP headers to C… Thomas Peterson
- Re: Migrating some high-entropy HTTP headers to C… Mike West
- Re: Migrating some high-entropy HTTP headers to C… Stephen Farrell
- Re: Migrating some high-entropy HTTP headers to C… Martin Thomson
- Re: Migrating some high-entropy HTTP headers to C… Mark Nottingham
- Re: Migrating some high-entropy HTTP headers to C… Mike West
- Re: Migrating some high-entropy HTTP headers to C… Mike West
- Re: Migrating some high-entropy HTTP headers to C… Mike West
- Re: Migrating some high-entropy HTTP headers to C… Yoav Weiss
- Re: Migrating some high-entropy HTTP headers to C… Stephen Farrell
- Re: Migrating some high-entropy HTTP headers to C… Ilya Grigorik
- Re: Migrating some high-entropy HTTP headers to C… Mark Nottingham
- Re: Migrating some high-entropy HTTP headers to C… Mike West
- Re: Migrating some high-entropy HTTP headers to C… Daniel Stenberg
- Re: Migrating some high-entropy HTTP headers to C… Mike West
- Re: Migrating some high-entropy HTTP headers to C… Martin Thomson
- Re: Migrating some high-entropy HTTP headers to C… Ilya Grigorik
- Re: Migrating some high-entropy HTTP headers to C… Mike West
- Re: Migrating some high-entropy HTTP headers to C… Anne van Kesteren
- Re: Migrating some high-entropy HTTP headers to C… Ilya Grigorik
- Re: Migrating some high-entropy HTTP headers to C… Mark Nottingham
- Re: Migrating some high-entropy HTTP headers to C… Martin Thomson
- Re: Migrating some high-entropy HTTP headers to C… Yoav Weiss
- Re: Migrating some high-entropy HTTP headers to C… Martin J. Dürst
- Re: Migrating some high-entropy HTTP headers to C… Mike West
- Re: Migrating some high-entropy HTTP headers to C… Martin J. Dürst
- Re: Migrating some high-entropy HTTP headers to C… Ilya Grigorik
- Re: Migrating some high-entropy HTTP headers to C… Mark Nottingham
- Re: Migrating some high-entropy HTTP headers to C… Martin J. Dürst
- Re: Migrating some high-entropy HTTP headers to C… Ilya Grigorik
- Re: Migrating some high-entropy HTTP headers to C… Ronan Cremin
- Re: Migrating some high-entropy HTTP headers to C… Yoav Weiss
- Re: Migrating some high-entropy HTTP headers to C… Ronan Cremin