How do you imagine other protocols handle switching physical connections? With HTTP 1, you send your session ID as a cookie after wasting time creating a new TCP connection
Yes, obviously, but we already know how that is used. This is a more complex protocol that might enable attack vectors that were not possible before and we do not think about when accessing websites:
But see the notes taken from the HTTP/3 RFC itself, written by the authors:
10.11. Privacy Considerations
Several characteristics of HTTP/3 provide an observer an opportunity
to correlate actions of a single client or server over time. These
include the value of settings, the timing of reactions to stimulus,
and the handling of any features that are controlled by settings.
As far as these create observable differences in behavior, they could
be used as a basis for fingerprinting a specific client.
HTTP/3's preference for using a single QUIC connection allows
correlation of a user's activity on a site. Reusing connections for
different origins allows for correlation of activity across those
origins.
Several features of QUIC solicit immediate responses and can be used
by an endpoint to measure latency to their peer; this might have
privacy implications in certain scenarios.
Tracking sessions across different physical connections has some non-trivial privacy implications:
https://http3-explained.haxx.se/en/quic/quic-connections#con...
How do you imagine other protocols handle switching physical connections? With HTTP 1, you send your session ID as a cookie after wasting time creating a new TCP connection
Yes, obviously, but we already know how that is used. This is a more complex protocol that might enable attack vectors that were not possible before and we do not think about when accessing websites:
But see the notes taken from the HTTP/3 RFC itself, written by the authors:
10.11. Privacy Considerations