8 ms·

UA reduction has officially started with Chrome 101: The UA string is not sending the minor version anymore, only 0.0.0. This is the beginning of the end for

UA reduction has officially started with Chrome 101: The UA string is not sending the minor version anymore, only 0.0.0. This is the beginning of the end for the UA string. As more and more UA reductions are deployed, the UA hints will become more useful and eventually depreciate the UA string entirely. https://www.chromium.org/updates/ua-reduction/ https://www.chromium.org/updates/ua-reduction/ https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/

mminer237 4y ago
About time. Statistics are mostly dead in favor of privacy anyway. At least this should help stop Google's blatantly anti-competitive practice of neutering search results if you're not using Chrome.
- kbelder 4y ago
  You think Google is reducing info Chrome sends in its user agent string in order to limit the ability of Google to favor Chrome? I can't imagine Google would be doing this without some sort of back-channel method of tracking this exact info. They're likely just removing this info from visibility to other websites, giving themselves a competitive advantage. Man, that sounds a little paranoid, but...
  - jedimastert 4y ago
    the brand and major version hints are sent with every request regardless of preferences, so no "back channel" needed.
grishka 4y ago
The one important use of the UA string is being able to tell whether it's a computer or a mobile device, to use different templates to render your pages. The new "client hints" botched that because while yes, there is "CH-UA-Mobile" that gives you a straight yes/no answer with no guesswork involved, you have to ask for it first — you can't get it on the first request, which very much defeats its purpose. And don't suggest me to use the same markup for both desktop and mobile with adaptive styles. More often than not this ends up being equally terrible on both kinds of devices.
- themacguffinman 4y ago
  Not sure what's the issue here, according to the spec you should be able to get it on the first request: > Sites that wish to serve mobile-specific sites using UA-CH can do that using the Sec-CH-UA-Mobile headers that are sent by default on every request. What am I missing?
  - grishka 4y ago
    Hm? Did they change it since the last time I saw the spec? Then yes, it's sensible indeed.
- eyelidlessness 4y ago
  > And don't suggest me to use the same markup for both desktop and mobile with adaptive styles. More often than not this ends up being equally terrible on both kinds of devices. My experience is generally (though not always) the exact opposite. It’s usually the case that when designers and implementers took the care to ship a properly responsive design, they’ve produced a design that adapts well to many factors. Designs which treat different device classes differently tend to be rigid, and fail to anticipate subtle differences or factors within those device classes. I hesitate to link to the snotty site most commonly used to point this out (though I will if anyone asks), but HTML is responsive by default. Knowing this, and building upon it, is a great way to start learning how to build responsive pages that work really well.
  - grishka 4y ago
    The problem is that you can't really use the same markup for both touchscreens and mice. Touchscreens call for oversized everything so it's easy to hit things with your finger. Mice are much more precise, enabling you to pack everything more tightly, and capable of hovering, enabling you to add new interactions like revealing things on hover. Moreover, phones are mostly vertical and computer screens are mostly horizontal. While you can no problem add a fixed header on mobile, it will be an annoyance on desktop because it eats into the scarcer vertical area. But you can replace the fixed header with a sidebar because there's often more horizontal space than you know what to do with. And so on, and so forth. There's much difference between the two interaction paradigms if you want to provide a fitting UX for both. Most people these days, however, don't. Here's an example from my own project: same post, different layouts. https://imgur.com/a/7uOy7II https://imgur.com/a/7uOy7II

mminer237 4y ago

About time. Statistics are mostly dead in favor of privacy anyway. At least this should help stop Google's blatantly anti-competitive practice of neutering search results if you're not using Chrome.

kbelder 4y ago
You think Google is reducing info Chrome sends in its user agent string in order to limit the ability of Google to favor Chrome? I can't imagine Google would be doing this without some sort of back-channel method of tracking this exact info. They're likely just removing this info from visibility to other websites, giving themselves a competitive advantage. Man, that sounds a little paranoid, but...
- jedimastert 4y ago
  the brand and major version hints are sent with every request regardless of preferences, so no "back channel" needed.

grishka 4y ago

The one important use of the UA string is being able to tell whether it's a computer or a mobile device, to use different templates to render your pages. The new "client hints" botched that because while yes, there is "CH-UA-Mobile" that gives you a straight yes/no answer with no guesswork involved, you have to ask for it first — you can't get it on the first request, which very much defeats its purpose. And don't suggest me to use the same markup for both desktop and mobile with adaptive styles. More often than not this ends up being equally terrible on both kinds of devices.

themacguffinman 4y ago
Not sure what's the issue here, according to the spec you should be able to get it on the first request: > Sites that wish to serve mobile-specific sites using UA-CH can do that using the Sec-CH-UA-Mobile headers that are sent by default on every request. What am I missing?
- grishka 4y ago
  Hm? Did they change it since the last time I saw the spec? Then yes, it's sensible indeed.
eyelidlessness 4y ago
> And don't suggest me to use the same markup for both desktop and mobile with adaptive styles. More often than not this ends up being equally terrible on both kinds of devices. My experience is generally (though not always) the exact opposite. It’s usually the case that when designers and implementers took the care to ship a properly responsive design, they’ve produced a design that adapts well to many factors. Designs which treat different device classes differently tend to be rigid, and fail to anticipate subtle differences or factors within those device classes. I hesitate to link to the snotty site most commonly used to point this out (though I will if anyone asks), but HTML is responsive by default. Knowing this, and building upon it, is a great way to start learning how to build responsive pages that work really well.
- grishka 4y ago
  The problem is that you can't really use the same markup for both touchscreens and mice. Touchscreens call for oversized everything so it's easy to hit things with your finger. Mice are much more precise, enabling you to pack everything more tightly, and capable of hovering, enabling you to add new interactions like revealing things on hover. Moreover, phones are mostly vertical and computer screens are mostly horizontal. While you can no problem add a fixed header on mobile, it will be an annoyance on desktop because it eats into the scarcer vertical area. But you can replace the fixed header with a sidebar because there's often more horizontal space than you know what to do with. And so on, and so forth. There's much difference between the two interaction paradigms if you want to provide a fitting UX for both. Most people these days, however, don't. Here's an example from my own project: same post, different layouts. https://imgur.com/a/7uOy7II https://imgur.com/a/7uOy7II