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

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