With becoming the default in soon, everyone's talking about the efficiency improvements, however to me the privacy tradeoffs aren't worth the gains i.e. (Wikipedia):

"QUIC includes a connection identifier which uniquely identifies the connection to the server regardless of source. This allows the connection to be re-established simply by sending a packet, which always contains this ID, as the original connection ID will still be valid even if the user's IP address changes."

@MatejLach Sounds a bit like one of those things where computer users are assumed to be both uninterested and fundamentally incapable of understanding anything about the technology they are using.

In my opinion it's a bad development, we should instead work towards more understanding of technology, empowering people to decide which tech they use and how.

If we assume people are stupid (I don't think that), then things like #freesoftware become meaningless as people can't tell the difference.

@meena @MatejLach no. It's fundamental to the protocol. It's also ephemeral, short lived, and equivalent to the TCP 4-tuple

@meena @MatejLach there's probably an about:config option, but why?

The claimed connection ID issue is just spurious. Each connection you make gets a new ID; it just makes behaviour when you switch IPs (eg on mobile phones) better

@erincandescent @MatejLach

but why

my fundamental disdain for everything that comes out of Google

@meena @MatejLach the ID is there so that when you roam between WiFi and mobile your connection doesn't break

It's ephemeral (Lasts only as long as the connection, and those last only a few minutes and smart) and small

@meena @MatejLach IETF QUIC doesn't reassemble Google QUIC that much any more TBH

@meena @erincandescent

'network.http.http3.enabled' in about:config (not on by default yet btw, just soon)

@MatejLach this is the equivalent of a source/destination ip/port 4-tuple when using http/2 (http with connection multiplexing). Assuming browsers treat that in the same way (don't share connection between normal and "private browsing" tabs for instance), it should change pretty much nothing to the current tradeoff. It is not supposed to be a persistent id resisting a browser restart, or any sort of super-cookie

@a000d4f7a91939d0e71df1646d7a48 What about VPNs? With HTTP/2 did the connection not get dropped when the IP and interface changed?

@MatejLach with HTTP/2, your connection would get dropped when going on or off of the VPN, with HTTP/3 it won't, with this id. Note however that with HTTP/2 (as for 1 and 1.1), this connection loss will make the browser reissue the same requests, including cookies (and possibly other identifying headers), so both sessions can be linked fairly easily by remote server. If using a VPN to hide your ip from a server, you should not go on and off your VPN, as it defeat the whole purpose.

@MatejLach I would recommend having a separate browser for VPN and non-VPN access to internet if you really want to do both

@MatejLach QUIC is non-standard. Firefox does not ship non-standard stuff. Firefox will be shipping http3, not quic. This code is ephemeral and only used for session resumption. It's not a tracker since it is strict to one site, it is not corelated cross site.

@andreipetcu How is QUIC non standard?

QUIC is essentially HTTP/3's underlying UDP-based transport protocol.

As for not being a tracker since it's per domain only and not cross site, my concern was not cross site tracking, but rather a site knowing who you are even if you say switch to a VPN or a tunnel.

Granted, you should not be keeping your old browser connections alive when you do that, but it is an extra thing to be mindful of that was previously not there.

Sign in to participate in the conversation
Matej Lach's mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!