> That user won't see any benefit that day, that week, and maybe never; I will benefit from this even though I don't use Chrome (or other Google product/servic

> That user won't see any benefit that day, that week, and maybe never; I will benefit from this even though I don't use Chrome (or other Google product/services). Reducing traffic manipulation by middleboxes and eliminating passive traffic snooping are important goals, and preserving forward compatibility should increase interoperability with future versions. I benefit from the internet moving back towards the end-to-end principle (smart hosts connected to a dumb network that only routes packets). The additional bandwidth cost is trivial and by definition will not affect anything that follows the spec. > imagine the extreme case ... Again, that's extreme and not going to happen. Speculating about hypothetical problems you admit are not going to happen is a distraction and waste of time. It's possible to make up extreme hypothetical problems afflicting any plan. > imagine Microsoft had Windows 10 insert something in network traffic to compel compatibility I spent a lot of time in the late-90s/early-00s fighting against Microsoft (and others) trying to embrace, extend, and extinguish[1] open standards. That strategy relies on extending an existing protocol with features that are not supported by existing implementations. The goal is to create the wall around a public garden by creating interoperability problems. The only people that might be affected are middleboxes that want to manipulate traffic (good; that was the goal) and incompetent implementations of the spec. The latter probably needs to be fixed (or replaced) anyway because not following the spec that is important for security is a sign that the software probably has other serious bugs and vulnerabilities. I have spent decades fighting for Free Software and against proprietary control of data formats, which are usually a form of rent seeking. Encouraging implementations to follow the spec and ignore unknown elements is unrelated to those concerns. > different products used GREASE to compete for different outcomes. How, precisely, is that supposed to work when (according to the RFC[2]), "Servers MUST correctly ignore unknown values in a ClientHello and attempt to negotiate with one of the remaining parameters." > It's also intentionally bad engineering This is very good engineering. The software industry has been negligent in learning good engineering practices like the importance of designing in tolerance[3] and failing safely. [1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... [2] https://tools.ietf.org/html/draft-ietf-tls-grease-01#section-3.2 https://tools.ietf.org/html/draft-ietf-tls-grease-01#section... [3] https://www.youtube.com/watch?v=9AYuXNz_0Fc https://www.youtube.com/watch?v=9AYuXNz_0Fc