Re: A question about user tracking with QUIC

["Roy T. Fielding" <[e-mail]>]

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