Re: Migrating some high-entropy HTTP headers to Client Hints.

Mike West <mkwst@google.com> Fri, 30 November 2018 08:40 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 9574F129C6B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 30 Nov 2018 00:40:20 -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 avHAvcBnflWK for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 30 Nov 2018 00:40:18 -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 5E85E12008A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 30 Nov 2018 00:40:18 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1gSeJo-0008Ki-PJ for ietf-http-wg-dist@listhub.w3.org; Fri, 30 Nov 2018 08:38:36 +0000
Resent-Date: Fri, 30 Nov 2018 08:38:36 +0000
Resent-Message-Id: <E1gSeJo-0008Ki-PJ@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <mkwst@google.com>) id 1gSeJm-0008K4-FJ for ietf-http-wg@listhub.w3.org; Fri, 30 Nov 2018 08:38:34 +0000
Received: from mail-oi1-x230.google.com ([2607:f8b0:4864:20::230]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <mkwst@google.com>) id 1gSeJi-0002HN-JH for ietf-http-wg@w3.org; Fri, 30 Nov 2018 08:38:34 +0000
Received: by mail-oi1-x230.google.com with SMTP id t204so4080239oie.7 for <ietf-http-wg@w3.org>; Fri, 30 Nov 2018 00:38:10 -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=mvXjQzlDEVmuOffPEvERUt1XGQsqc3fIA+G0t0yGu9M=; b=X0K3YuZBKU6TZObjtCfe/Zh8s+YDjZtN8wUKjo4FiS6oiHIucAmKR8yx/ic38jqynS RDvXi4Ioc+9qe0VG4epmeWvt9rfmuFUm5FLEN0w+VbZjZj6rQJuq9mYe/1Zo/95o6uVd TIpcj/FnJdBxeLDXJw5rrVgVCmXbHO9xxdRe8rw6bFQ0BpaFVFZldUHzCBQ7mhRXVPVT LbXIQ9fPhNDlkAcb9fSv237p4jHgW2snsHRh3CoAyjzIE4Pa8SUvBpBSotEV+idUtgNZ EHFC5Qj4ouIEFPyTTP3gRml5O+3OrZU3miJcq7mYxnh3zC5yLt8eA88FpOTLKE3H0ixt w/hQ==
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=mvXjQzlDEVmuOffPEvERUt1XGQsqc3fIA+G0t0yGu9M=; b=dNajynKnrjdCWDvpfCiiMvXVEew2Gqdh17UmU//VBLVQjMdA/hpVkF+DAMlYpwfvno sQb4PV+1tmmQxaB6i6ybFoUevmN8AHCLPZw0Tksv0V/dPPV6Uw6nsJFpWaF7VNkV5lS2 8GJCDVmMKnzy2CJcrcsQaGiGWNlW0KRhoWToAdbxFo9Yg/2NHN3QA0HjUwUZupU/U1u9 NLqK5H22fj5436x/nEimoxSpEq1oUYqz5OFQi2Ke3FCNv5XiN0cMVoo83mRTTYppmp63 IjTjw5eTic/efXnemqaZZWbqDvgp4IqymluonBLZa6aDreZf6pwPdOTEfZ5MZyvDXx/g Piwg==
X-Gm-Message-State: AA+aEWb5K8rEP9ibmv98PtyZ8iCi1dmdxdJToYPYyQYt7JC/fSDp0D11 jHYVJDVa68PTAZFPmRU+dlYXVeIMrvFjH3mzGA+2kg==
X-Google-Smtp-Source: AFSGD/W6yexikt1xywVu2QWoIqtD1PssYNJO+zpkoGA1dpwP4HZH3oUjduYMjzE+M2hcWgLkJvB8PtSjU1g7+YsyJH8=
X-Received: by 2002:aca:33c2:: with SMTP id z185mr2948205oiz.4.1543567089403; Fri, 30 Nov 2018 00:38:09 -0800 (PST)
MIME-Version: 1.0
References: <CAKXHy=eHiMtXi8vkDYtADHdU0tnUfd3p+Wfy7vSkLgT7cA1W0w@mail.gmail.com> <CABkgnnU2P2Q+cDQ-y+798jbRZEiiQB2=5wH9QyBK_UfEf5zrkw@mail.gmail.com>
In-Reply-To: <CABkgnnU2P2Q+cDQ-y+798jbRZEiiQB2=5wH9QyBK_UfEf5zrkw@mail.gmail.com>
From: Mike West <mkwst@google.com>
Date: Fri, 30 Nov 2018 09:37:57 +0100
Message-ID: <CAKXHy=ctQxQssJCKd6-Zy+0eVq=xXoSNjZeLO7Cv4fh3h-wE7Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000000d626a057bddb8de"
X-W3C-Hub-Spam-Status: No, score=-20.7
X-W3C-Hub-Spam-Report: AWL=3.866, 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: titan.w3.org 1gSeJi-0002HN-JH cafb09a09789b0d96270823512b5650a
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/CAKXHy=ctQxQssJCKd6-Zy+0eVq=xXoSNjZeLO7Cv4fh3h-wE7Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36115
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>

On Fri, Nov 30, 2018 at 12:22 AM Martin Thomson <martin.thomson@gmail.com>
wrote:

> I think maybe I was predisposed to not like this, but I do like it.
> Not saying that I'm hugely enthusiastic about doing the CH part, but
> the bit were User-Agent becomes fixed is really appealing.
>

I am glad the concept overcame your potential predispositions! I think it's
a pretty natural extension of the CH infrastructure, and I think it's a
pretty reasonable compromise that gives us the breathing room to freeze the
UA string while not freezing out developers.

One thing we might consider, if the timing works out, is having user
> agents register their UA strings with us.  We can bake them into the
> QPACK static table so that we can save bits.  I don't want to
> privilege particular clients overly, so that only works if we have
> broad acceptance of the plan.
>

That seems pretty reasonable to me, though I'm not sure how much space we
have to work with in the static table. Chrome's current user agent string
comes in at around ~150 characters, depending on platform. Taking that as a
baseline, how many strings could we reasonably encode? Can the table expand
to an extend that would allow it to cover enough of the UA market?

-mike


> On Thu, Nov 29, 2018 at 9:26 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
>