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.
It feels like we've been moving backwards in terms of privacy since HTTP/2 even as those same privacy issues have been increasingly exploited by private companies and governments. It's sad to see the situation continuously worsened instead of being improved over time. It feels like a push for performance whatever the cost, or perhaps (more pessimistically) a push to degrade privacy and security while justifying it or distracting us from it with increased performance. It's strange to see security and privacy issues inherent to these specifications acknowledged, but not addressed.
As an end user, I already get satisfactory performance with the existing protcols. What slows things down is the neverending gratuitous Javascript and automatic connections not initiated by the user for the purposes of advertising, tracking and telemetry. Even viewing these RFCs in the best light, as "improvements", it stands to reason that end users will not be the ones who benefit most (if at all) from them. It is reminiscient of personal computers in decades past that kept increasing in speed and power only to have those increases usurped by gas-like software developed on the latest, most expensive workstations by software companies aiming to license newer versions, in some cases under agreements for pre-installation with OEMS aiming to sell newer hardware. "Gas-like" because over time it seemed to expand to fill available space. The newer PCs could do more, faster, behind the scenes, but the user experience did not change; for the user, it generally still took the same amount of time to do the same routine tasks. To put it another way, these "improvements" in well-established transport protocols may mean "tech" companies will be better able to exploit end users, e.g., more data collected and more advertising served without performance degradation, perhaps leading to more commerce, but not that end users will be better able to avoid exploitation, e.g. through improved privacy and security from "tech" companies and their advertiser customers.
> Even viewing these RFCs in the best light, as "improvements", it stands to reason that end users will not be the ones who benefit most (if at all) from them.
That's kind of how I see it. A lot of internet protocols have ended up having privacy and security issues, but not so much by design. We saw the problems introduced with HTTP/2 and it appears like we're just doubling down on them instead of trying to find solutions. I guess I'm just nostalgic for the days things were made to benefit internet users rather than the people looking to make money off of them.
For what it's worth, the HTTP/2 specification contains almost identical phrasing as HTTP/3 [1]. That's not unexpected, the considerations are similar: using a single connection with connection-specific values has potential implications. However, the possibility for fingerprinting is inherent in every protocol and HTTP semantics itself paints out the ways common features might get used.
Considerations are just that. Choices in light of considerations can be traded off by client implementations - they can make their own choices about how to address these matters.
The work in the IETF to define oblivious DNS and oblivious HTTP [2] protocols is a step towards reducing such surfaces, at the trade off of functionality.
Doesn't it make more sense to separate concerns? Build the highest performance protocol possible that can operate efficiently under a wide array of conditions and then route via an overlay such as i2p whose sole job is to provide privacy if you want to do that.
Also isn't an implementation free to avoid things like connection reuse if it so chooses? For that matter some browsers support fully containerizing things per site visited.
> Doesn't it make more sense to separate concerns?
Wouldn't it be better to design a protocol that doesn't have those concerns in the first place? A good design would be easy to implement without opening up users to security and privacy issues. Designing something insecure and/or harmful and then saying that it's the implementer's job to figure out a way to fix the mess you just made feels wrong to me.
> Wouldn't it be better to design a protocol that doesn't have those concerns in the first place?
I'm referring to design concerns, not usage concerns. To minimize privacy concerns related to usage, you first have to add privacy as an additional design concern.
And privacy is a particularly difficult one because it means a lot of different things to different people. Can you reuse connections at all? What about content fingerprinting based on transfer rates - do you need to add cover traffic? Voice codecs, for example, will inadvertently reveal when the stream goes silent because they more or less stop transferring data. Instead of designing voice codecs to be less efficient, it probably makes more sense to optimize them to the maximum extent possible and then handle privacy concerns at a higher layer on an as-needed basis.
Separating design concerns to the extent reasonably possible tends to yield significantly less complex end results which has a whole host of benefits. A Swiss army knife often proves to be sub par in practice when compared to more specialized tools. Do one thing and do it well.
> A good design would be easy to implement without opening up users to security and privacy issues.
Simple designs are nearly always easier to implement. Compare the code base of OpenVPN to WireGuard for example. I think it's quite reasonable for a spec to accommodate implementations that want to make various optimizations that sacrifice user privacy. In cases where that's a concern implementations can omit such optimizations as necessary based on their specific usecase.
> To minimize privacy concerns related to usage, you first have to add privacy as an additional design concern.
I suppose I would argue that privacy and security should be a design concern. Not that it should necessarily be an issue for every protocol, but certainly for anything intended to widely replace something like HTTP or other very common internet protocols.
> I think it's quite reasonable for a spec to accommodate implementations that want to make various optimizations that sacrifice user privacy.
Sometimes it really is enough just to know that something is extremely fragile, or insecure, or easy to exploit. People can decide for themselves if they want to use it or not according to their needs. I have written a large number of programs for my own personal use where I made the intentional decision to neglect security. Because only I use them, and I know what the dangers are, and only I control the inputs it's not really an issue.
In some situations/environments there are still valid uses for older protocols like FTP even though more secure options now exist, but certainly if a new version of FTP was being designed I would expect it to try to correct the known issues with past versions.
It's not really a problem if Google designs QUIC to allow users to be tracked anywhere they go on the internet and it makes services vulnerable to DoS attacks. It's much more of a problem when those problems become part of HTTP and users who disable or refuse to accept HTTP/3 connections for their own protection are at risk of being cut off from large swaths of the www.
I assume security is a concern already. Privacy's just less well defined and a lot harder. Connection fingerprinting is hard and I don't really think it's worth trying to solve for HTTP because... they're not going to.
If you want anonymous browsing, use TOR. If you say "well TOR is too slow", welcome to the HTTP/3 party.
> Voice codecs, for example, will inadvertently reveal when the stream goes silent because they more or less stop transferring data.
Secure audio transports don't do this for what it's worth. They use Constant Bit Rate encodings. A constant number of bits are consumed every period regardless of whether there's silence. For example if you make a voice call with Signal it uses Opus CBR, an adversary suitably placed on your network path can see how long your call was, but they cannot measure silence.
With a Variable Bit Rate encoding it is possible for an adversary to not only detect silence but also estimate whether you said certain key things. For example if there's a "Project Amadeus" and you've got all the encrypted voice calls between dozens of people using a VBR codec you could write software which sifts those calls to find those which seem likely to mention "Project Amadeus" based on the data rates.
