[csmpltn]

> "These are opt-in, so they are only sent if requested."

Are google.com, youtube.com, netflix.com, facebook.com, amazon.com and reddit.com going to ask for User Agent Client Hints? If they're going to (which is more than likely, let's not kid ourselves) - I don't see how your point holds?

> "Why/how does this waste bandwidth?"

Based on the current proposal - non-mobile browsers or browsers that simply do not wish to expose the specific model are somehow required to return the following header in response:

    Sec-CH-UA-Model: ""

Those are 19 absolutely useless bytes. Wouldn't it make more sense to simply omit the header from the response altogether? It would convey the exact same information to the server ("my Sec-CH-UA-Model is empty"), without the overhead of sending additional data.

[joshuamorton]

> Are google.com, youtube.com, netflix.com, facebook.com, amazon.com and reddit.com going to ask for User Agent Client Hints?

Possibly, but they only need them on initial request I think.

> It would convey the exact same information to the server ("my Sec-CH-UA-Model is empty"), without the overhead of sending additional data.

It doesn't commit the exact same info though. This says "the client is aware of this scheme and doesn't reply, vs the client is unaware of the rfc. It's the true/false/none issue.

In a sane world, there would be auch shorter way to encode that, but http is a bad protocol so you can't nest/namespace things or whatever.

[csmpltn]

> "Possibly, but they only need them on initial request I think."

I don't see how this is going work.

If this is data the backend needs the client is either going to have to send it out on every request (like it does today with the User-Agent header) - or the client will only send it out once, and the response would be cached by the backend somehow. The requirement to cache this data on the backend is non-trivial to implement and is a huge paradigm shift. That's actually another pitfall with the RFC in a sense.

> It doesn't commit the exact same info though. This says "the client is aware of this scheme and doesn't reply, vs the client is unaware of the rfc. It's the true/false/none issue."

This doesn't make any sense to me whatsoever.

The "scheme" is what we make it out to be. If the scheme would allow for omitting headers (as it should have) - then the client would be in compliance with the scheme, wouldn't it?

By designing an RFC which allows for omitting headers we actually resolve the ambiguity between "false" and "none": the data is either explicitly there, or it's not.

I'm simply claiming that the scheme as currently proposed is nonsensical and negligent. At Chrome's scale - I expect each proposal to introduce more headers and data to every request to be very carefully weighed against impact on global bandwidth consumption and resource utilization (and energy use). I don't feel like any of that is reflected in this RFC, which is an absolute shame and a big part of the problem: we keep piling up more crap thinking "it doesn't really make a difference". I think it reflects poorly on the people involved with designing and building this.

Perhaps we should mandate providing these numbers explicitly with every RFC so that we can know how much the implementation actually "costs" in terms of bandwidth, memory, etc at the web's scale. This should help identify RFCs like this one which are seriously off on the engineering side of things.

[joshuamorton]

> By designing an RFC which allows for omitting headers we actually resolve the ambiguity between "false" and "none": the data is either explicitly there, or it's not.

The point is that a server may care about the difference between "I am explicitly opting out of giving you this information" and "What are you talking about".

Also keep in mind that Chrome, when communicating with Amazon, Google, or Netflix probably uses HTTP/2 or HTTP/3, which would compress the headers, making much of your complaint moot. I'd expect `Sec-CH-UA-{foo}: ""` to compress very well.