From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org Mon Jan 30 14:12:44 2023 Return-Path: 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 BFF67C151709 for ; Mon, 30 Jan 2023 14:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Irnpu1kixoik for ; Mon, 30 Jan 2023 14:12:40 -0800 (PST) Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BED2C14CF17 for ; Mon, 30 Jan 2023 14:12:40 -0800 (PST) Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1pMcO3-005dwo-La for ietf-http-wg-dist@listhub.w3.org; Mon, 30 Jan 2023 22:12:27 +0000 Resent-Date: Mon, 30 Jan 2023 22:12:27 +0000 Resent-Message-Id: Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pMcO1-005dvW-Tq for ietf-http-wg@listhub.w3.org; Mon, 30 Jan 2023 22:12:25 +0000 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pMcNy-007dr5-7h for ietf-http-wg@w3.org; Mon, 30 Jan 2023 22:12:25 +0000 Received: by mail-wr1-x42e.google.com with SMTP id bk16so12535138wrb.11 for ; Mon, 30 Jan 2023 14:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=coD25F+dUrT1Oj3Mpwh9pg8QA/vDLWdGCiQXIZQABLQ=; b=ZdHSaGj13RVR+PVAS52atfEE1lV2rXjDbd2RnlsaKrd7szApmkFBGhQpO2AHOxdPIg qn/wq6o6oa8gK3I9bDZbsWNFZS1lHIKITNwltclgQqOhSjd899gDsurJ5mGP99xSlybH lwXeIk/gA0wWzasv+O/QBoJv5oXjbtxo/P9KcraGrxL0wzVmqy3b7Ts7melNxiRsjUmh 41iU3hzJc1Z/jDAcnn3neuce6qthhHVrOfHnA7FizibtrYCZCRCS1WYfrOfxxpMlJ01E 272VOpJUqNiOZWT+1fLIi7HnPV5I1YVR0ytR/xwXELOhZGp9OsoEeaNTShvSZ+8V6CuT T9pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=coD25F+dUrT1Oj3Mpwh9pg8QA/vDLWdGCiQXIZQABLQ=; b=A9CDM+JP0dIy5n2MxOH7ytmNnkixKL4sV9CbSM1howPlbqf5YeZERxCFHmsYSjQUaO xZygw9xP3ygJ77eJoBKjoWd5l0mmTKl09AV90/EtaZPADby2y0osFJdnh1fgG8c1u77+ A5eJmGKUheq32BkfN3dNmxhHMmqYNk+fRQzl7XBg3RrI92ZxJvIrwwoCz+7dDYxdkrma SEfD+7NWqhvovmD+6E4X0uX01HvD23w4Q7reU6iGhsXxmXKJ4I4FeBQLJ7UpNCigNk5s cHSCpcWGSSUpj/6HJGgX9AHUSkAVGhmjReBKpDo3IaLwbW6PePoIfQ8hJvBW5E2+IHq4 RbVg== X-Gm-Message-State: AO0yUKV3LA2pHNqMQe1B6CrutsB9p6vLC2VhprN3xp4xTUTND0UNTGQX kd63TK9KKGnXMezSnXsDK5pWviEKPovzt0Myp1CKSGl2Ii7yy9cXUW52wg== X-Google-Smtp-Source: AK7set8wuDOgbIFkUzgzMyfQi/AI5ec5CIGxw+lsKXAii7ftAWbnqGstlQixiDY0FlFu+w6quAUqx63cPx3b5Uew1Cs= X-Received: by 2002:a5d:4e41:0:b0:2bf:b7ce:8c8c with SMTP id r1-20020a5d4e41000000b002bfb7ce8c8cmr974958wrt.195.1675116731548; Mon, 30 Jan 2023 14:12:11 -0800 (PST) MIME-Version: 1.0 References: <16133a2f-5fbe-0f7f-c2ea-e83d20fdb3cc@gmail.com> <20230130084455.6ede70c9@fabiankeil.de> <5d420b68-e4b2-34b8-1a56-a9fddf9872a0@gmail.com> In-Reply-To: From: Jeffrey Yasskin Date: Mon, 30 Jan 2023 14:11:59 -0800 Message-ID: To: "Soni L." Cc: ietf-http-wg@w3.org Content-Type: multipart/alternative; boundary="000000000000be8f9d05f3828159" Received-SPF: pass client-ip=2a00:1450:4864:20::42e; envelope-from=jyasskin@google.com; helo=mail-wr1-x42e.google.com X-W3C-Hub-DKIM-Status: validation passed: (address=jyasskin@google.com domain=google.com), signature is good X-W3C-Hub-Spam-Status: No, score=-24.6 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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_HELO_NONE=0.001, 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 1pMcNy-007dr5-7h 5713601f9555bd22e7e3e5a56cca5066 X-Original-To: ietf-http-wg@w3.org Subject: Re: Slower HTTP for privacy Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/40724 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --000000000000be8f9d05f3828159 Content-Type: text/plain; charset="UTF-8" The negative choices are up to individual clients. For example, Chrome's User-Agent reduction depends on certain client hints being available, but it's a separate change. Jeffrey On Mon, Jan 30, 2023 at 1:42 PM Soni L. wrote: > > > On 1/30/23 18:27, Nick Harper wrote: > > It sounds like what you want is Client Hints ( > https://developer.mozilla.org/en-US/docs/Web/HTTP/Client_hints). > > > Roughly, but it still doesn't eliminate the existing headers altogether. > > Client Hints seems to be *positive* hints only, i.e. "send these, please". > > What about *negative* hints, i.e. "don't even bother sending these"? How > do you prevent useless data from being sent? > > > On Mon, Jan 30, 2023 at 10:48 AM Soni L. wrote: > >> >> >> On 1/30/23 04:44, Fabian Keil wrote: >> > "Soni L." wrote on 2023-01-29 at 11:45:53: >> > >> > > It would be appreciated if there were a slower HTTP, with more round >> > > trips, explicitly designed with privacy negotiation in mind. >> > > >> > > Importantly, you can't leak data which you do not have. The best way >> to >> > > not have that data is to not receive it. >> > > >> > > Why does a server need to accept user agents and a bunch of other >> > > unnecessary stuff if it isn't gonna use it? Doesn't it just make the >> > > server more liable for no good reason? Make it possible to turn it >> off! >> > > Most of it can just be turned off. >> > > >> > > In fact, the simplest servers (static hosting) only really need the >> URL >> > > and the Host. Everything else is unnecessary liability. >> > >> > It's not exactly what you ask for, but Privoxy [0] has a >> > delay-response{} response action [1] that is somewhat related. >> > >> > Fabian >> > >> > [0] >> > [1] < >> https://www.privoxy.org/user-manual/actions-file.html#DELAY-RESPONSE> >> It's not at all what we ask for! Uh, we mean like, why does the HTTP >> server have to parse and discard the User-Agent header and another 10 or >> so headers which it has no use for, instead of just... not receiving >> those headers in the first place? >> >> Why can't the client send URL and Host, then wait for the server to send >> a Headers Required message, then send the required headers (which may be >> none)? Yes, it takes longer (more RTTs), but the best way to improve >> privacy is to not have the data in the first place. >> >> > --000000000000be8f9d05f3828159 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The negative choices are up to individual clients. Fo= r example, Chrom= e's User-Agent reduction depends on certain client hints being available= , but it's a separate change.

Jeffrey
On Mon, J= an 30, 2023 at 1:42 PM Soni L. <fakedme+http@gmail.com> wrote:
=20 =20 =20


On 1/30/23 18:27, Nick Harper wrote:
=20

Roughly, but it still doesn't eliminate the existing headers altogether.

Client Hints seems to be *positive* hints only, i.e. "send these, please".

What about *negative* hints, i.e. "don't even bother sending t= hese"? How do you prevent useless data from being sent?


On Mon, Jan 30, 2023 at 10:48 AM Soni L. <fakedme+http@gmail.com> wrote:


On 1/30/23 04:44, Fabian Keil wrote:
> "Soni L." <fakedme+http@gmail.com> wrote on 2023-01-29 at 11:45:53:
>
> > It would be appreciated if there were a slower HTTP, with more round
> > trips, explicitly designed with privacy negotiation in mind.
> >
> > Importantly, you can't leak data which you do not have. The best way to
> > not have that data is to not receive it.
> >
> > Why does a server need to accept user agents and a bunch of other
> > unnecessary stuff if it isn't gonna use it? Doesn&#= 39;t it just make the
> > server more liable for no good reason? Make it possible to turn it off!
> > Most of it can just be turned off.
> >
> > In fact, the simplest servers (static hosting) only really need the URL
> > and the Host. Everything else is unnecessary liability.
>
> It's not exactly what you ask for, but Privoxy [0] has a=
> delay-response{} response action [1] that is somewhat related.
>
> Fabian
>
> [0] <https://www.privoxy.org/>
> [1] <https://w= ww.privoxy.org/user-manual/actions-file.html#DELAY-RESPONSE>
It's not at all what we ask for! Uh, we mean like, why does the HTTP
server have to parse and discard the User-Agent header and another 10 or
so headers which it has no use for, instead of just... not receiving
those headers in the first place?

Why can't the client send URL and Host, then wait for the server to send
a Headers Required message, then send the required headers (which may be
none)? Yes, it takes longer (more RTTs), but the best way to improve
privacy is to not have the data in the first place.


--000000000000be8f9d05f3828159--