Summary
- The 27 October revision of an individual QUIC draft adds a worked example in which a client stores a server's network observations and returns them on a later connection.
- The example binds the record to the authenticated issuing server. Existing privacy guidance recommends deleting stored statistics when the user clears cookies, putting a familiar gesture in charge of a less familiar cache.
A server can save itself some paperwork by handing the filing cabinet to the customer. In the revised QUIC congestion-data proposal, the cabinet is a client cache: a device holds network observations issued by a server, then returns the record when another connection begins. The server can recover its own history without keeping the full measurement trail for every client.
The new Appendix B makes that exchange concrete. Its recovery example tells the client to associate each record with the server's authenticated identity and endpoint. Another server advertising willingness to receive remembered data gets no claim on the first server's record. An HTTPS origin together with IP address and port is one suggested scope; the IP address alone cannot establish who issued the memory. If the association cannot be established, the client leaves the recall out.
That is a useful boundary for a device that visits many services. A matching address is cheap evidence of where a packet went. It is poorer evidence of whom the stored record belongs to. The proposal puts the selection decision in the client, before the record goes back across the wire.
It also offers three different switches. CONSUME requests statistics for present use, such as a video application's bitrate decision. CACHE signals willingness to receive and potentially return them later. CONSIDER signals that a peer will accept its earlier observations back. Their default is zero. These switches describe endpoint behaviour; a browser still needs to decide how its storage and privacy controls govern that behaviour.
The draft's security section acknowledges that returning statistics could support tracking. It compares the capability with QUIC's existing address-validation tokens, while allowing clients to inspect the readable statistics or decline values they cannot interpret. It also recommends discarding stored statistics when users clear other tracking mechanisms, including cookies. The previous revision already contained that deletion advice. October's new worked examples give the client storage role a more explicit shape.
A recommendation to clear data needs a path through the software. The button a person recognises may live in browser settings; the record lives in transport storage. The implementation has to connect the two. Present-connection telemetry can also remain present-connection telemetry: the draft's streaming example uses CONSUME without requiring a promise to retain and echo the record later.
Datatracker lists this as an individual Internet-Draft, and the 27 October announcement records its availability. It has no IETF endorsement. The source package contains no browser build with a tested cache-deletion result; such a result would show whether the familiar privacy control reaches the new drawer.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance





