We have sometimes been drawn to a potential privacy problem: of course, QUIC protects well against the surveillance exercised by an actor outside the communication, thanks to its systematic encryption. But what about the monitoring exerted by the server on which one connects? Let’s look at the complexity of designing Internet protocols when it comes to privacy.

Unlike the case of third-party monitoring, which is dealt with at great length in the RFCs on QUIC (see for example RFC 9000, section 9.5), the case of monitoring a user by the server to which he connects is absent. And this while the big capitalist corporations that form a highly visible part of today's web are notorious for practicing mass surveillance. But what exactly is it?

Let us first see the principle of the possible problem of follow-up of a user by the server. QUIC connections can be long, perhaps several hours or even days, and they even survive IP address changes, with QUIC allowing migration from one address to another. So the server can easily determine that the 9:00 am /machin.html request is made by the same user as the 4:00 pm /machin.html request, since it is the same QUIC connection. Undoubtedly, this user tracking problem exists. But is this specific to QUIC and is it a real problem in practice?

First, the problem is old. If the old original HTTP only sent one request per connection, this limitation was gone a long time ago. Thus, HTTP / 2 (RFC 7540) already favored long-term connections, posing the same problems. However, QUIC, with its ability to survive IP address changes, further extends the duration of these connections, which can be seen as compounding the problem (rather rare techniques, like TCP multipath, RFC 8684, also worked through IP address changes).

Importantly, in typical web usage today, there are many other methods of server tracking the user. There are obviously RFC 6265 cookies. Even if you are not logged into a service like YouTube, cookies are placed. And these cookies, unlike the long-lasting QUIC connection, allow cross-server tracking, through Google Analytics and the GAFA share buttons that so many webmasters put on their pages mindlessly. And it's not just cookies, browser fingerprinting can also identify a unique visitor, by all the information that the very chatty HTTP transmits, as the EFF test clearly shows. In short, at present, the indiscreet server who wants to track its users has many more powerful means at its disposal.

On the other hand, if we use a completely privacy-oriented system, such as the Tor Browser, which disables many web services that are too intrusive, and makes everything go through Tor, then the duration of QUIC connections could become the weak link in privacy.

For Tor, the problem is currently purely theoretical since Tor only transmits TCP and QUIC uses UDP. But it could arise in the future, the Tor project has already thought about this in the context of HTTP2 (which was called SPDY in its early days).

A QUIC customer concerned about not being tracked can therefore, once they have dealt with the much bigger problems of cookies and fingerprinting, consider solutions such as not letting QUIC connections last too long and above all, do not use migration (which allows you to maintain the connection when the IP address changes). This can be done by deliberately hanging up the connection, or simply by not providing for reserve connection IDs (RFC 9000, section 5.1.1). That said, it is easier said than done because an application is not necessarily informed quickly of a change of IP address of the machine. And, obviously, this will have a negative impact on the overall performance.

The long duration of QUIC connections is not the only mechanism by which a server could track a client. QUIC allows a client to memorize information which will allow him to reconnect to the server more quickly (what we call the “0-RTT”). This information (which works exactly like an HTTP cookie) obviously also allows the server to recognize a past client. This possibility and its sometimes harmful consequences are detailed in RFC 9001, sections 4.5 and 9.1. Note that this also exists with just TLS (what is called session resumption, RFC 8446, section 2.2) and with TCP Fast Open (RFC 7413), with the same consequences on the possibility of following a client by the server. The QUIC client who would like to protect his privacy must therefore be careful, when he starts a new connection, not to use these possibilities, which would betray him (but which reduce the latency; always the compromise).

As is often the case in security, we are therefore faced with a compromise. If we only thought about privacy, we would be using Tor all the time… for example, Web browsers clearly optimize for speed, not for privacy.