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

Lucas Pardue <> Sun, 15 August 2021 00:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 498093A184A for <>; Sat, 14 Aug 2021 17:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o-ZU0Fl7ixf7 for <>; Sat, 14 Aug 2021 17:03:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D6C93A184C for <>; Sat, 14 Aug 2021 17:03:51 -0700 (PDT)
Received: by with SMTP id bq25so15080616ejb.11 for <>; Sat, 14 Aug 2021 17:03:51 -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=+CuSGNsHHAGSXPuEGVW+qN4xmpM5kiyB5xdBML+cs7E=; b=iALtq17H1/fMm9dqmGxVgUzHbeD/7uS4K8nJiLH/23bj0CnhOuzJOXQs2sBCwxHKFB vj5EDUH8f+AWTz2UhjiTuc/kyyDGIhTbrY/1xemldym4xstzx+t6DVdC14ouNxrXj3XA ntEDHDKWeMATJyGhtxPP8/lrSyUapiins5lSRnxozUx3LxyWUm/adrfkNx2RcNtIirC0 A5HiZ03Akv6FT4kC7+tTgZtZwclaqCn3JWaHGTfSI7RLHgeZi2BGsBrugwLVI9uH2oyH 6cYlJQf4CGRWCFGMI8pvlGb04jN6j/hkadHo9zr3ezYvOZbm2xpT4rn/ohzGidWYxbFl WTNg==
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=+CuSGNsHHAGSXPuEGVW+qN4xmpM5kiyB5xdBML+cs7E=; b=qT1WTjgAtG0gWzvdj4EyC10V7Wulh3LGnGidcNEy5tNNenjQdGZbfJfGf51aI0UP23 FCHEAXZaDV+MihZE0gYP1XMbmUkPPrUqr2UM8JuTPmLjGYAoZ/QDyVpq6E1lkA7yWHzj xQP8VVNZaPqarzcn9fLeQf/syHzlU81mAVGH8zwSPXeOAU8XYaeqMHkHXlAvd5RU2onf zFKAsu6cT4033D/jtonAfuclfwvS2U4PJsElhswVeVnshtizPw+8O1gyvBP+xTqmOoE7 3nOHnLjvUmPh/eungmvMpnksbSke0eMZl/iLds2uaZdYJsutZUspeavcGVyM/GzwLRyp TSfw==
X-Gm-Message-State: AOAM532K631YwjMRb8ydx5Vc9WIV9rmrgY19ygCKbJ5VyB4n4rbHtEz0 In4KIO+LA0eRDiGDKa5V5pnPjEG5NkmmjXMQT0U=
X-Google-Smtp-Source: ABdhPJzqNvw1ESvgOGmrMKFjt5PMBqVF72h/bl/MTpxtg+u7uLex3PClsQn8iPxzVZgcv5LAi13tTSpmLymXUXp6Rqo=
X-Received: by 2002:a17:906:1cc1:: with SMTP id i1mr9303897ejh.374.1628985827288; Sat, 14 Aug 2021 17:03:47 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Sun, 15 Aug 2021 01:03:36 +0100
Message-ID: <>
Subject: Privacy considerations of trace logging (was Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt)
To: Robin MARX <>
Cc: Kazuho Oku <>, Jana Iyengar <>, IETF QUIC WG <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000946a5005c98dd1ee"
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 00:03:57 -0000


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.


[1] -