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

2021年8月15日(日) 9:03 Lucas Pardue <lucaspardue.24.7@gmail.com>:

> Hello,
>
> 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.
>

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
improvement.

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
whatsoever.


> Cheers,
> Lucas
>
> [1] -
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-qlog-main-schema-00#section-9
>


-- 
Kazuho Oku