Re: Privacy considerations of trace logging (was Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt)

Kazuho Oku <> Sun, 15 August 2021 09:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA5EF3A0140 for <>; Sun, 15 Aug 2021 02:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4QmmLkvtRDMC for <>; Sun, 15 Aug 2021 02:01:46 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 953963A0128 for <>; Sun, 15 Aug 2021 02:01:46 -0700 (PDT)
Received: by with SMTP id cn28so9937107edb.6 for <>; Sun, 15 Aug 2021 02:01:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=skH+YaXh01OWDdae9ki3MORvAr9Nez49FK1t2swhQG4=; b=j0x8kz5Kl4ouGTd7mQ6VIJqda8FIXEIR359BTpB0J5HZksze21hfSZtp/ZESMWz+iV lSok2FhCgpOMekW3xsxW0/MNnCtRMefzlS+8ySHLbluJJljmVLQTrfThY6Jx6X0IwfpT 4mahmX1w76gaTfaVuphvkWe6CzCCY4Qu4UT5m3JfC0f366+uUk73EsXN4wZBa6Crrg9N Vrf6eKFvI8YnxL+v2zK60WCeFUxx8wSNbHbOrafjNCMhDdqteh3ARYJ38rcMCIXH77p7 JiY38m4llXJcQ4Lj9jqhLuWilsKLeAHDkjFhr8XxixIKDNymc5Qpy5TNXwTyz62FGH0k ghag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=skH+YaXh01OWDdae9ki3MORvAr9Nez49FK1t2swhQG4=; b=nxXnAPrKeM3HPv2gAIkTFYgOeaOl77tjMKMcBQwR/Dvaot+oK1pWgoHfZPnZyZCJ5S iXdyBOVXYPSwcp8JSwyhBawql/zd2V1UosgkEgDSSKjZv2GrlEX3mtDQQsvPIEZLCw9l bV//7WJjTpCKgY9vWILWMuYEQ8GlZ68/hxBMD1zLwsGNOasgE6AkVMW3Kb+oYE5/I9VY T5oAXV4tNteXuH0c16LlO8mG4GBqJZ543S203c45P2dW2R34xV3D3sMbAMNX4YNbHY0x GWXtsQDPG7NTtDi7cH/MmgEXIPWvQjReN+XBUmOyWkt8+kY/CioK7CCFN+hSdjNE55jk O6rw==
X-Gm-Message-State: AOAM530hl9jofWU9vWIS1Bwa40F8KzDtZetb93bXeYAWDfyFfUe0eBou qf+yuHqv6UUM/LsSMU3ac0Oisb9daLduTN74a7Y=
X-Google-Smtp-Source: ABdhPJzgIuIJoKr13Ea3ovCD9Ea7TfRf+eqaMjzlh53wgFhx9mhR71mNKFcjal8kUliPkOEGfP9AFU9mBs4KrVCjRtI=
X-Received: by 2002:aa7:d5d3:: with SMTP id d19mr13108235eds.201.1629018104158; Sun, 15 Aug 2021 02:01:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Kazuho Oku <>
Date: Sun, 15 Aug 2021 18:01:30 +0900
Message-ID: <>
Subject: Re: Privacy considerations of trace logging (was Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt)
To: Lucas Pardue <>
Cc: Robin MARX <>, Jana Iyengar <>, IETF QUIC WG <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="0000000000006e5e3505c995551f"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 15 Aug 2021 09:01:52 -0000

2021年8月15日(日) 9:03 Lucas Pardue <>:

> Hello,
> Spinning off a new thread to focus on privacy.
> On Fri, Aug 13, 2021 at 5:28 PM Robin MARX <robin.marx=
>> wrote:
>> 5) I wonder if this should be a completely separate document, a separate
>> document part of the qlog effort, or part of the qlog documents.
>>     As said in 4), I don't feel this necessarily should be limited to
>> qlog, but a lot of the privacy issues+mitigations inherent to exposing logs
>> will be discussed for qlog and should probably be referenced for this
>> approach as well.
>>     Currently, you seem to skirt some of this by saying it doesn't matter
>> because the client is the one requesting the logs, but I don't quite agree
>> that's enough.
>>     This could be used to ask end-users to capture a trace of a
>> problematic connection and upload it for analysis. If the end-user isn't
>> very technical, they might not know which info they're exposing. Even if
>> they are, they probably don't want to go through the trouble of sanitizing
>> the logs themselves.
>>     Put differently: this should probably either be restricted to expose
>> no privacy-sensitive info at all (or at least discuss the issues) or allow
>> explicit selection of a "privacy level" (the approach we'll probably take
>> with qlog is to define multiple levels of obfuscation/omission for
>> different use cases).
> I'm not so fussed on what text goes where. But I have a nagging concern
> that we (collectively) aren't great at defining this type of thing, and we
> should do better. The collect all and scrub model leaves me itchy.
> Different applications that already have the ability to logs lots of detail
> (e.g. Chrome netlog), seem to have different views on what "private data"
> is. Where do they define that and is it consistent? Are there regulatory
> considerations we should also be thinking about?
> More specifically, and this is by no means a criticism of the editors,
> qlog's security and privacy section is 3 paragraphs of TODOs [1]. I think
> it would be great to find some people that could channel their knowledge or
> expertise to start populating it with direct contributions, references, or
> in contribution to some broader companion doc.

I agree that it would be reasonable to write down the risks of logging
information, especially the application data being sent in cleartext.

At the same time, I would point out that servers can log whatever they
want, regardless of what qlog or any specification says. So if we are to
provide some guidelines (or even just warnings), that is going to be an

The same argument applies to requiring a client's action (to upload the
trace). It cannot be worse than servers retaining traces and using them

> Cheers,
> Lucas
> [1] -

Kazuho Oku