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.
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.