Re: A question about user tracking with QUIC

[Lucas Pardue <[e-mail]>]

Hi,

Speaking as an individual.

Through the lens of server-side observation and linking of clients, I think
Christian makes astute observations on some common concerns and
QUIC-specific ones. Roy too makes some great additional observations about
the context of discussion.

It seems to me this topic might well do with some time to draw out the
considerations for documentation. However, the applicability draft is
already through a second round of WGLC, and that timeline seems too tight
for inclusion of such considerations. I would seem to me that the PEARG
(Privacy Enhancements and Assessments Research Group) [1] is ideally suited
towards housing effort on deeper/broader analysis of privacy aspects of
protocol evolution (I might even stick a note in for multipath TCP as
something that moves the needle on privacy of "legacy" application
protcols).

Cheers,
Lucas

[1] - https://datatracker.ietf.org/rg/pearg/about/

On Mon, Jun 7, 2021 at 8:43 PM Roy T. Fielding <[e-mail]> wrote:

> On Jun 7, 2021, at 12:00 PM, Stephane Bortzmeyer <[e-mail]>
> wrote:
> >
> > Any specific reference to such a discussion about privacy "against"
> > the server? I did not find any.
>
> There have been many discussions about session establishment and
> reestablishment.  Too many to note. However, "user tracking" is not the
> term used when the same server remembers interactions with a single user.
> That's more typically referred to as analytics or sessions, not tracking.
>
> There is a relevant concern about multisite tracking on servers that
> present a certificate for multiple origins, but that applies to both H2
> and H3
> and only if the browser chooses to reuse the same session layer across
> multiple sites. Regardless, this is nothing compared to a browser's
> inherent
> tracking features that any origin server is capable of directing for the
> sake of tracking at the HTML/JS layer.
>
> There was a conscious decision, early on, that QUIC would not attempt to
> provide the same features as Tor (or any other sort of privacy broker).
> It is simply impossible for a protocol to do a better job at that without
> centralizing everything by default, which would then be a far greater
> danger
> to users than individual origin sessions. Using QUIC to communicate with
> a user-selected, private intermediary (like Tor) would be much better, I
> think,
> than trying to do the same with H1/TLS or H2/TLS. Or at least it will be
> once
> there is a large number of users using the same protocols.
>
> > (And having important discussions on a Microsoft platform not
> > controlled by the IETF is a bad idea, anyway, but I digress.)
>
> The IETF does not have the resources to provide a comparable issue tracking
> system, let alone one that manages PRs and version control for authors,
> while
> providing extensive search capabilities at the same time. It's a tool.
>
> ....Roy
>
>