9 ms·

User-Agent Reduction

76 points by kkm 4y ago

forgotmypw17 4y ago
I look forward to Google-Chrome-Web (GCW) fully separating into its AOL-ish self and leaving the Good Web alone for us geeks to revel in.
computerfriend 4y ago
User agent strings are such a train wreck. I wish Chrome was braver and changed it to something like "Chromium (Blink, V8); Linux (Android)".
- somat 4y ago
  Or just "chromium 99" Every once in a while I rebel and change my user agent to "firefox 103". but in the end get sad about how much breaks when you do that, and come crawling back the the default user agent string. I think the thing that bugs me the most is not the complexity of it. but how every body is spoofing every body elses user agent string. It is just this stupid circle jerk of spoofing.
  - cj 4y ago
    How would CDNs cache both a mobile optimized and desktop optimized version of a site on the edge? I suppose this can still (kind of) be done, but on the client-side using the viewport size (combined with javascript or CSS @media) rather than on the backend.
    - jraph 4y ago
      For a simple website, the user agent should be able to decide what to download and display. It should not be a backend application. HTML is responsive by default, just don't break this, and yes, you can use media queries if needed. For images, we have srcset to tell the browser what to download depending on the screen size [1]. You should not try to optimize the bandwidth if I'm on mobile. I might be on a Wi-Fi connection with a mobile or with my tethered mobile connection on my laptop. Just optimize for everything anyway. The backend should not be involved in how the site is presented, and the CDN should be as dumb as possible, or should not be used at all. For apps, you have Javascript to do whatever you want. Mobile / desktop detection is yet another user agent detection in disguise anyway. Just detect my screen size, my dpi, my tactile screen, my mouse, possibly my bandwidth is it's really necessary (videoconferencing for instance). I could be using a mouse on a mobile device. Both the mouse and the touchscreen need to work. You might not need to do feature detection, just bind these events unconditionally. I could plug a secondary tactile screen and move my browser window on this screen. Many devices are hybrid now. A tablet with a keyboard is not that weird today. What should isMobile return? "YesAndNo"? I've not seen a really convincing use of isMobile yet. But I've seen harmful ones. They are full of assumptions that are correct most of the times, but still have exceptions. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source#attr-srcset https://developer.mozilla.org/en-US/docs/Web/HTML/Element/so...
      - fiedzia 4y ago
        > What should isMobile return? There was an joke (real story maybe) about soldiers being allowed to carry up to 25kg of gear, and therefore a device weighting 104kg supposed to be carried by 4 people was deemed not to be portable.
- Semaphor 4y ago
  On the other hand, they are amazing at catching bots. Almost all bots (obviously excluding disguised ones, but those never were an issue for us) have identifiable user agents, by blocking bots via UAs, we became better than Google Ads at blocking bots, they are probably doing some kind of complicated ML thing that works far better for edge cases, our simple solution works better for normal cases…
  - secondcoming 4y ago
    Even today? UA strings are easily fakeable (so fakeable that it surprises me that people still use them for anything). If a bot still gets caught by UA strings then it's just a poorly written bot? DoubleVerify is a Googley company that does bot detection. That uses the UA and IP address to find them.
    - Avamander 4y ago
      Easily fakeable and abusers still use bad ones. The bar is barely above the floor.
    - Semaphor 4y ago
      I’m talking about actual, legit bots. Facebook, Instagram, all those search engine crawlers. Those follow all kinds of links, including ads, and then go and annoy us and the advertisers by counting as "fake traffic". Google is/was (we wrote our own simplified adserver, only using AdManager for the agencies that require it, so I’m not sure how much things changed in the last two years) not only happy letting those through, they even send their own, it was so bad that we redirected all links through our site where we filtered all Google IP ranges (because, of course, whatever they used did not have a proper bot UA) that we could find to block them and stop sending 1000s of fake visits to the advertiser every day.
      - Multicomp 4y ago
        I wonder if these bots would respect robots.txt files for the ads?
- donatj 4y ago
  As author of a popular User Agent parser - they are indeed a train wreck but they were at least a largely solved, managed and contained train wreck. The average person could just grab a library, pass it a single string and know what browser someone was using. UA hints, SEC headers and all that stuff they’re pushing to “replace” it really just complicate the problem. Getting accurate data server side has been made a total pita.
  - kijin 4y ago
    Yeah, the problem with "just use feature detection" is that most of it only works on the frontend, or by having the frontend send additional data to the server after the initial page load. Sometimes you need to optimize things for certain browsers or bots before a single byte of JS has been sent, relying only on the first few request headers. Akamai probably needs to. Deleting the cruft but retaining the highest bits (product name and major version) like Chrome is doing seems like a reasonable compromise.
- fragmede 4y ago
  Right? the mentioned short UA string in the article is Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.0.0 Safari/537.36 but as long as we're breaking backwards compatibility anyway, it seems to me it could just say Chrome/100.0.0.0 Android
njsubedi 4y ago
If only browsers had similar behavior across the platform and devices, user-agent wouldn’t be so useful to servers. They wouldn’t need to respond with customized content for each different user agent. As a developer, I’d prefer having to deal with at most a few dozen UAs instead of hundreds of specific ones.
- rrwo 4y ago
  If you're using a version of a Chrome-based browser or Firefox from the few years, you don't need to worry about the UA. At $work, once we dropped support for Internet Explorer, site development and maintenance became much easier.
UpToTheSky 4y ago
Someone should also look into the "navigator" variable that websites can access. It provides a strangely open look into the user's machine. For example, it allows websites to know about your OS, your CPU and your memory. The "window" object also provides data that I would consider private. Like the screen size. Websites should only know the window size. Demo: https://jsfiddle.net/uvtLc784/ https://jsfiddle.net/uvtLc784/
- flutas 4y ago
  > Someone should also look into the "navigator" variable that websites can access. It provides a strangely open look into the user's machine. For example, it allows websites to know about your OS, your CPU and your memory. Looks like it's full of red herring values to me, at least Chrome 107 on a (M1) MBP. That being said, it's always good to remove anything that can be used to fingerprint a user. It reported the following... - CPU as undefined - Memory as 8GB (32GB in actuality) - Platform as MacIntel (Should be Mac-AArch64)
  - 400thecat 4y ago
    same for me. It only guessed screen resolution correctly
  - secondcoming 4y ago
    For me on various browsers: Firefox: CPU: Windows NT 10 Memory: undefinedGB Screen: 2560x1440 Brave: CPU: undefined Memory: 0.5GB Screen: 2560x1440 Edge: CPU: undefined Memory: 8GB Screen: 2560x1440 Actual values: Windows 10, 128GB, 3820x2160
    - chipsa 4y ago
      That's a crapton of RAM, but are you running on a scaled display? Specifically at 150% scaling?
      - secondcoming 4y ago
politelemon 4y ago
> The Chrome team expects the highlighted portions to be changed to: I cannot see what they have highlighted.
- rrwo 4y ago
  Neither can I, but see https://www.chromium.org/updates/ua-reduction/ https://www.chromium.org/updates/ua-reduction/ (which the article links to)
klabb3 4y ago
Eh. I guess I'm happy with any reduction of entropy in the UA string (which today almost contains your family name and dogs favorite meal in an unparseable string blob). But "client hints" seems like very little bang (device-specific cdn assets?) for the buck (an interactive, configurable and stateful protocol). And if this is for privacy reasons, but you can circumvent it by requesting client hints, then won't that end up an always-on default anyway that nobody benefits from in practice? I guess if it's fine if users and devs don't need to think about it. OTOH, this is yet another barrier to competition in the browser space, which we desperately need to curb. It seems like someone should overhaul the whole privacy mess with cookies, fingerprinting, user agents and other remnants from the 90s and take a slightly more principled approach to making a sane single standard, instead of adding hundreds of highly specific single-purpose headers and JS APIs.
- _trackno5 4y ago
  I guess it could always be on by default, but the browser can offer a privacy-focused user experience. For example, the first time a website asks for these hints the browser could prompt the user to give permission to share that information. Similar to iOS privacy information pills
- jefftk 4y ago
  > if this is for privacy reasons, but you can circumvent it by requesting client hints, then won't that end up an always-on default anyway that nobody benefits from in practice? The goal is to switch from sending high-entropy information by default to sending it only when explicitly requested by a site. This has several advantages as you try to reduce fingerprinting, but the big one is that it's visible which sites are using which information. Today any server could be using any part of the UA.
  - klabb3 4y ago
    So, if this becomes a permission, it would be another annoyance like the cookie banners. Akamai is requesting client information, allow or deny? Who would know what that even means, outside of tech? The gist is, privacy and security has to be in the defaults to be useful. The amount of stuff that can afford to have a human in the loop is in practice minor, and only be reserved for important things that people can actually understand.
Havoc 4y ago
I can see reduced granularity but that seems a touch extreme? I’d rather google work on all the other info that leaks
iicc 4y ago
I've been blocked from an Akamai fenced website because I used Firefox for Android. Not great when you have a plane ticket you need to change.
- iam-TJ 4y ago
  Your experience made me wonder how that blocking stands up against accessibility legal requirements in various countries.
Briggs958 4y ago
[dead]
jraph 4y ago
When I got started with the web 15 years ago, it was advised everywhere not to rely on user agent strings and rely on feature detection instead, and that using the user agent string should be a last resort solution. Today, we are still seeing issues "solved" by switching one's user agents. And here we are reading Akamai whining about user agents getting unreliable. And we are talking unreliable at the minor version and specific platform version level. It's not like we weren't warned ahead of time. I'm sure problems will be sorted by proper http headers, data in handshakes or other things. And they should. Nobody should have to read user agent strings to optimize things, because things should also be optimized for a new, unknown user agent that would support these optimizations.
- krono 4y ago
  The level of detail that will be available to servers will not be reduced at all, but rather repackaged and split up into separate headers that the server can individually request. The information contained in these headers will likely be more accurate because it's claimed to be safer this way. Whereas today your browser sends the messy but relatively detailed user agent string automatically with each request, after this change it will still send the messy user agent string with each request but with a tiny bit less detail. Google's writers are pretty good at polishing turds, got to give them that!
- masklinn 4y ago
  > and that using the user agent string should be a last resort solution. In fairness, “last resort solution” means sometimes it is your only solution, when a specific browser fucks up on specific content and you need to work around that specifically.
  - jraph 4y ago
    Sure, that belongs to the very few valid use cases. I got an iPad 2 from a relative, I do detect its user agent on my private Invidious instance to send it transpiled/polyfilled JS instead of the original one. Of course it would not be the correct solution if Apple did not forbid other browsers on its hardware, the correct solution would then be to install a recent Firefox version on it. It would also allow a shitload of other stuff to work, like subtitles on fullscreen videos and autoplay on the next video, playback of videos protected by HTTP basic auth, as well as Let's Encrypt SSL certificates. The device's browser should send a "X-I-m-dumb-and-my-manufacturer-likes-to-piss-everybody-off: true" HTTP header to avoid relying on its user-agent though.
daveoc64 4y ago
While I am personally in favour of feature sniffing, rather than user agent sniffing, I think it's worth remembering the debacle about how the SameSite attribute on cookies was handled by the browsers a few years ago. Several browsers shipped with an old implementation of the spec that is incompatible with the most recent, current version of the spec. Setting the SameSite attribute to a specific value can result in the site working in newer browsers, but not in older browsers (or vice versa). The only way to handle this is to sniff for a specific set of old browsers by user agent string, and to alter how cookies are set for those: https://www.chromium.org/updates/same-site/incompatible-clients/ https://www.chromium.org/updates/same-site/incompatible-clie... Due to the prevalence of old iOS devices that can't be updated with a more modern browser (especially iPads), the company I work for has to keep this user agent sniffing in our codebases going forward. If the user agent string is going to be deprecated or significantly weakened, there needs to be effort among browser vendors to avoid something like this ever happening again.
- jefftk 4y ago
  All the UA reduction proposals still include sending the browser major version, which is what you need to handle this kind of incompatibility.
donatj 4y ago
Similarly related, no longer being able to tell iPad OS and macOS apart server side was a major blow for us. We have essentially “continue this in the app” buttons whose existence and how they passed state (iOS vs Android) was determined server side. We rewrote that all to happen client side because you can check “is it a Mac?” && “does it have multi-touch support?” And know it’s an iPad - at least until they build a touchscreen Mac.
- geraldwhen 4y ago
  Open in app banners are butt, so good riddance. If I wanted an app, I would be using an app.
  - donatj 4y ago
    It's not a banner. It's a little button to take the current state into the app so you can go offline.
deleted 4y ago
[deleted]
charonn0 4y ago
Seems like a relevant time to bring up this old chestnut: https://webaim.org/blog/user-agent-string-history/ https://webaim.org/blog/user-agent-string-history/
bullen 4y ago
This would sort itself out if browser implementations followed the standard and allowed us to set the user-agent ourselves. Personally I would then set it to 1, 2 or 3 and have my server handle those cases. Right now then ONLY user-agent code I have running is this: navigator.userAgent.indexOf('Android') == -1 && navigator.userAgent.indexOf('Other') == -1 && navigator.userAgent.indexOf('SamsungBrowser') == -1 Good job Samsung/Google!

76 points by kkm 4y ago

I look forward to Google-Chrome-Web (GCW) fully separating into its AOL-ish self and leaving the Good Web alone for us geeks to revel in.

computerfriend 4y ago

User agent strings are such a train wreck. I wish Chrome was braver and changed it to something like "Chromium (Blink, V8); Linux (Android)".

somat 4y ago
Or just "chromium 99" Every once in a while I rebel and change my user agent to "firefox 103". but in the end get sad about how much breaks when you do that, and come crawling back the the default user agent string. I think the thing that bugs me the most is not the complexity of it. but how every body is spoofing every body elses user agent string. It is just this stupid circle jerk of spoofing.
- cj 4y ago
  How would CDNs cache both a mobile optimized and desktop optimized version of a site on the edge? I suppose this can still (kind of) be done, but on the client-side using the viewport size (combined with javascript or CSS @media) rather than on the backend.
  - jraph 4y ago
    For a simple website, the user agent should be able to decide what to download and display. It should not be a backend application. HTML is responsive by default, just don't break this, and yes, you can use media queries if needed. For images, we have srcset to tell the browser what to download depending on the screen size [1]. You should not try to optimize the bandwidth if I'm on mobile. I might be on a Wi-Fi connection with a mobile or with my tethered mobile connection on my laptop. Just optimize for everything anyway. The backend should not be involved in how the site is presented, and the CDN should be as dumb as possible, or should not be used at all. For apps, you have Javascript to do whatever you want. Mobile / desktop detection is yet another user agent detection in disguise anyway. Just detect my screen size, my dpi, my tactile screen, my mouse, possibly my bandwidth is it's really necessary (videoconferencing for instance). I could be using a mouse on a mobile device. Both the mouse and the touchscreen need to work. You might not need to do feature detection, just bind these events unconditionally. I could plug a secondary tactile screen and move my browser window on this screen. Many devices are hybrid now. A tablet with a keyboard is not that weird today. What should isMobile return? "YesAndNo"? I've not seen a really convincing use of isMobile yet. But I've seen harmful ones. They are full of assumptions that are correct most of the times, but still have exceptions. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source#attr-srcset https://developer.mozilla.org/en-US/docs/Web/HTML/Element/so...
    - fiedzia 4y ago
      > What should isMobile return? There was an joke (real story maybe) about soldiers being allowed to carry up to 25kg of gear, and therefore a device weighting 104kg supposed to be carried by 4 people was deemed not to be portable.
Semaphor 4y ago
On the other hand, they are amazing at catching bots. Almost all bots (obviously excluding disguised ones, but those never were an issue for us) have identifiable user agents, by blocking bots via UAs, we became better than Google Ads at blocking bots, they are probably doing some kind of complicated ML thing that works far better for edge cases, our simple solution works better for normal cases…
- secondcoming 4y ago
  Even today? UA strings are easily fakeable (so fakeable that it surprises me that people still use them for anything). If a bot still gets caught by UA strings then it's just a poorly written bot? DoubleVerify is a Googley company that does bot detection. That uses the UA and IP address to find them.
  - Avamander 4y ago
    Easily fakeable and abusers still use bad ones. The bar is barely above the floor.
  - Semaphor 4y ago
    I’m talking about actual, legit bots. Facebook, Instagram, all those search engine crawlers. Those follow all kinds of links, including ads, and then go and annoy us and the advertisers by counting as "fake traffic". Google is/was (we wrote our own simplified adserver, only using AdManager for the agencies that require it, so I’m not sure how much things changed in the last two years) not only happy letting those through, they even send their own, it was so bad that we redirected all links through our site where we filtered all Google IP ranges (because, of course, whatever they used did not have a proper bot UA) that we could find to block them and stop sending 1000s of fake visits to the advertiser every day.
    - Multicomp 4y ago
      I wonder if these bots would respect robots.txt files for the ads?
donatj 4y ago
As author of a popular User Agent parser - they are indeed a train wreck but they were at least a largely solved, managed and contained train wreck. The average person could just grab a library, pass it a single string and know what browser someone was using. UA hints, SEC headers and all that stuff they’re pushing to “replace” it really just complicate the problem. Getting accurate data server side has been made a total pita.
- kijin 4y ago
  Yeah, the problem with "just use feature detection" is that most of it only works on the frontend, or by having the frontend send additional data to the server after the initial page load. Sometimes you need to optimize things for certain browsers or bots before a single byte of JS has been sent, relying only on the first few request headers. Akamai probably needs to. Deleting the cruft but retaining the highest bits (product name and major version) like Chrome is doing seems like a reasonable compromise.
fragmede 4y ago
Right? the mentioned short UA string in the article is Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.0.0 Safari/537.36 but as long as we're breaking backwards compatibility anyway, it seems to me it could just say Chrome/100.0.0.0 Android

njsubedi 4y ago

If only browsers had similar behavior across the platform and devices, user-agent wouldn’t be so useful to servers. They wouldn’t need to respond with customized content for each different user agent. As a developer, I’d prefer having to deal with at most a few dozen UAs instead of hundreds of specific ones.

rrwo 4y ago
If you're using a version of a Chrome-based browser or Firefox from the few years, you don't need to worry about the UA. At $work, once we dropped support for Internet Explorer, site development and maintenance became much easier.

UpToTheSky 4y ago

Someone should also look into the "navigator" variable that websites can access. It provides a strangely open look into the user's machine. For example, it allows websites to know about your OS, your CPU and your memory. The "window" object also provides data that I would consider private. Like the screen size. Websites should only know the window size. Demo: https://jsfiddle.net/uvtLc784/ https://jsfiddle.net/uvtLc784/

flutas 4y ago
> Someone should also look into the "navigator" variable that websites can access. It provides a strangely open look into the user's machine. For example, it allows websites to know about your OS, your CPU and your memory. Looks like it's full of red herring values to me, at least Chrome 107 on a (M1) MBP. That being said, it's always good to remove anything that can be used to fingerprint a user. It reported the following... - CPU as undefined - Memory as 8GB (32GB in actuality) - Platform as MacIntel (Should be Mac-AArch64)
- 400thecat 4y ago
  same for me. It only guessed screen resolution correctly
- secondcoming 4y ago
  For me on various browsers: Firefox: CPU: Windows NT 10 Memory: undefinedGB Screen: 2560x1440 Brave: CPU: undefined Memory: 0.5GB Screen: 2560x1440 Edge: CPU: undefined Memory: 8GB Screen: 2560x1440 Actual values: Windows 10, 128GB, 3820x2160
  - chipsa 4y ago
    That's a crapton of RAM, but are you running on a scaled display? Specifically at 150% scaling?
    - secondcoming 4y ago

politelemon 4y ago

> The Chrome team expects the highlighted portions to be changed to: I cannot see what they have highlighted.

rrwo 4y ago
Neither can I, but see https://www.chromium.org/updates/ua-reduction/ https://www.chromium.org/updates/ua-reduction/ (which the article links to)

klabb3 4y ago

Eh. I guess I'm happy with any reduction of entropy in the UA string (which today almost contains your family name and dogs favorite meal in an unparseable string blob). But "client hints" seems like very little bang (device-specific cdn assets?) for the buck (an interactive, configurable and stateful protocol). And if this is for privacy reasons, but you can circumvent it by requesting client hints, then won't that end up an always-on default anyway that nobody benefits from in practice? I guess if it's fine if users and devs don't need to think about it. OTOH, this is yet another barrier to competition in the browser space, which we desperately need to curb. It seems like someone should overhaul the whole privacy mess with cookies, fingerprinting, user agents and other remnants from the 90s and take a slightly more principled approach to making a sane single standard, instead of adding hundreds of highly specific single-purpose headers and JS APIs.

_trackno5 4y ago
I guess it could always be on by default, but the browser can offer a privacy-focused user experience. For example, the first time a website asks for these hints the browser could prompt the user to give permission to share that information. Similar to iOS privacy information pills
jefftk 4y ago
> if this is for privacy reasons, but you can circumvent it by requesting client hints, then won't that end up an always-on default anyway that nobody benefits from in practice? The goal is to switch from sending high-entropy information by default to sending it only when explicitly requested by a site. This has several advantages as you try to reduce fingerprinting, but the big one is that it's visible which sites are using which information. Today any server could be using any part of the UA.
- klabb3 4y ago
  So, if this becomes a permission, it would be another annoyance like the cookie banners. Akamai is requesting client information, allow or deny? Who would know what that even means, outside of tech? The gist is, privacy and security has to be in the defaults to be useful. The amount of stuff that can afford to have a human in the loop is in practice minor, and only be reserved for important things that people can actually understand.

Havoc 4y ago

I can see reduced granularity but that seems a touch extreme? I’d rather google work on all the other info that leaks

iicc 4y ago

I've been blocked from an Akamai fenced website because I used Firefox for Android. Not great when you have a plane ticket you need to change.

iam-TJ 4y ago
Your experience made me wonder how that blocking stands up against accessibility legal requirements in various countries.

Briggs958 4y ago

[dead]

jraph 4y ago

When I got started with the web 15 years ago, it was advised everywhere not to rely on user agent strings and rely on feature detection instead, and that using the user agent string should be a last resort solution. Today, we are still seeing issues "solved" by switching one's user agents. And here we are reading Akamai whining about user agents getting unreliable. And we are talking unreliable at the minor version and specific platform version level. It's not like we weren't warned ahead of time. I'm sure problems will be sorted by proper http headers, data in handshakes or other things. And they should. Nobody should have to read user agent strings to optimize things, because things should also be optimized for a new, unknown user agent that would support these optimizations.

krono 4y ago
The level of detail that will be available to servers will not be reduced at all, but rather repackaged and split up into separate headers that the server can individually request. The information contained in these headers will likely be more accurate because it's claimed to be safer this way. Whereas today your browser sends the messy but relatively detailed user agent string automatically with each request, after this change it will still send the messy user agent string with each request but with a tiny bit less detail. Google's writers are pretty good at polishing turds, got to give them that!
masklinn 4y ago
> and that using the user agent string should be a last resort solution. In fairness, “last resort solution” means sometimes it is your only solution, when a specific browser fucks up on specific content and you need to work around that specifically.
- jraph 4y ago
  Sure, that belongs to the very few valid use cases. I got an iPad 2 from a relative, I do detect its user agent on my private Invidious instance to send it transpiled/polyfilled JS instead of the original one. Of course it would not be the correct solution if Apple did not forbid other browsers on its hardware, the correct solution would then be to install a recent Firefox version on it. It would also allow a shitload of other stuff to work, like subtitles on fullscreen videos and autoplay on the next video, playback of videos protected by HTTP basic auth, as well as Let's Encrypt SSL certificates. The device's browser should send a "X-I-m-dumb-and-my-manufacturer-likes-to-piss-everybody-off: true" HTTP header to avoid relying on its user-agent though.

daveoc64 4y ago

While I am personally in favour of feature sniffing, rather than user agent sniffing, I think it's worth remembering the debacle about how the SameSite attribute on cookies was handled by the browsers a few years ago. Several browsers shipped with an old implementation of the spec that is incompatible with the most recent, current version of the spec. Setting the SameSite attribute to a specific value can result in the site working in newer browsers, but not in older browsers (or vice versa). The only way to handle this is to sniff for a specific set of old browsers by user agent string, and to alter how cookies are set for those: https://www.chromium.org/updates/same-site/incompatible-clients/ https://www.chromium.org/updates/same-site/incompatible-clie... Due to the prevalence of old iOS devices that can't be updated with a more modern browser (especially iPads), the company I work for has to keep this user agent sniffing in our codebases going forward. If the user agent string is going to be deprecated or significantly weakened, there needs to be effort among browser vendors to avoid something like this ever happening again.

jefftk 4y ago
All the UA reduction proposals still include sending the browser major version, which is what you need to handle this kind of incompatibility.

donatj 4y ago

Similarly related, no longer being able to tell iPad OS and macOS apart server side was a major blow for us. We have essentially “continue this in the app” buttons whose existence and how they passed state (iOS vs Android) was determined server side. We rewrote that all to happen client side because you can check “is it a Mac?” && “does it have multi-touch support?” And know it’s an iPad - at least until they build a touchscreen Mac.

geraldwhen 4y ago
Open in app banners are butt, so good riddance. If I wanted an app, I would be using an app.
- donatj 4y ago
  It's not a banner. It's a little button to take the current state into the app so you can go offline.

deleted 4y ago

[deleted]

charonn0 4y ago

Seems like a relevant time to bring up this old chestnut: https://webaim.org/blog/user-agent-string-history/ https://webaim.org/blog/user-agent-string-history/

bullen 4y ago

This would sort itself out if browser implementations followed the standard and allowed us to set the user-agent ourselves. Personally I would then set it to 1, 2 or 3 and have my server handle those cases. Right now then ONLY user-agent code I have running is this: navigator.userAgent.indexOf('Android') == -1 && navigator.userAgent.indexOf('Other') == -1 && navigator.userAgent.indexOf('SamsungBrowser') == -1 Good job Samsung/Google!