Re: A question about user tracking with QUIC

[Mikkel Fahnøe Jørgensen <[e-mail]>]

> 
> This is why that I suggested (but it may be a bad idea, may be I
> didn't think of everything) that a privacy-conscious client may be
> better by not using connection migration, and resetting to an entirely
> new connection when the IP address changes.

You cannot do that for non-trivial protocols such as HTTP because you need application state that cannot be interrupted during migration. Even if you create a new connection, the server would still need to know how to connect the new connection to the existing state. You might for example be in the middle of transferring a picture over an HTTP stream when migrating. You would have to drop the picture and restart transfer at the new connection. And it wouldn’t be hard for the server to fingerprint.

You could imagine other more privacy conscious protocols, also over QUIC, but you would have to define your own application protocol, and explicitly disallow connection migration and possibly also 0-RTT. For example, you could create a public FTP like service in this way and restart file download if connection is broken due to user migration. QUIC has a 0 connection ID that disallows migration, so you can do this if you want.

QUIC discussions has mostly focused on the HTTP use case, and general TCP replacement, for version 1, although I and others have also pushed for other use cases such as symmetric server to server communication.

If you really want privacy you can do more than QUIC does, such as onion routing, but that might depend on middleware and require trust to be placed elsewhere. This presumably comes at a cost of latency and complexity which is outside the design scope of QUIC.

You might also want to look into QUIC tunnelling, but I have not studied this in detail.