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 <[email protected]> wrote: > On Jun 7, 2021, at 12:00 PM, Stephane Bortzmeyer <[email protected]> > 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 > >
