W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

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

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Sun, 15 Aug 2021 01:03:36 +0100
Message-ID: <CALGR9oYLwgCEbLf_FWrOCPw0LNkFtX=4t5=d1M-j-jxQ+b0A0g@mail.gmail.com>
To: Robin MARX <robin.marx=40uhasselt.be@dmarc.ietf.org>
Cc: Kazuho Oku <kazuhooku@gmail.com>, Jana Iyengar <jri.ietf@gmail.com>, IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>

Spinning off a new thread to focus on privacy.

On Fri, Aug 13, 2021 at 5:28 PM Robin MARX <robin.marx=
40uhasselt.be@dmarc.ietf.org> 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] -
Received on Sunday, 15 August 2021 00:04:02 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 15 August 2021 00:04:04 UTC