4 ms·

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

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.

deleted 4y ago
[deleted]
simmervigor 4y ago
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. [1] https://www.rfc-editor.org/rfc/rfc9113.html#section-10.8 https://www.rfc-editor.org/rfc/rfc9113.html#section-10.8 [2] https://datatracker.ietf.org/wg/ohai/about/ https://datatracker.ietf.org/wg/ohai/about/
d110af5ccf 4y ago
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.
- autoexec 4y ago
  > 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.
  - d110af5ccf 4y ago
    > 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.
1vuio0pswjnm7 4y ago
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.
- autoexec 4y ago
  > 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.

deleted 4y ago

[deleted]

simmervigor 4y ago

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. [1] https://www.rfc-editor.org/rfc/rfc9113.html#section-10.8 https://www.rfc-editor.org/rfc/rfc9113.html#section-10.8 [2] https://datatracker.ietf.org/wg/ohai/about/ https://datatracker.ietf.org/wg/ohai/about/

d110af5ccf 4y ago

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.

autoexec 4y ago
> 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.
- d110af5ccf 4y ago
  > 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.

1vuio0pswjnm7 4y ago

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.

autoexec 4y ago
> 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.