4 ms·

Is there any legitimate use for UA string sniffing vs feature detection? And what could a search engine possibly do that's so bleeding edge it doesn't work in

by rendaw 3y ago

Is there any legitimate use for UA string sniffing vs feature detection? And what could a search engine possibly do that's so bleeding edge it doesn't work in all browsers?

throwaway167 3y ago
Track you in new and exciting ways.
PlutoIsAPlanet 3y ago
Google provides a more basic webpage for older browsers.
- klabb3 3y ago
  Introducing ‘about: blank’ by Google. A new way to experience the web.
  - djbusby 3y ago
    Will be shuttered in less than 5 years.
    - sumtechguy 3y ago
      such optimism!
- Aissen 3y ago
  And they often do that wrongly. Try typing "weather" in Firefox for Android vs Chrome for Android; a vastly inferior version is shown on Firefox. Changing the UA or using desktop mode makes the page work flawlessly.
  - Miner49er 3y ago
    Wow, that's very anticompetitive.
1oooqooq 3y ago
No. But you might be misguided if you are incompetent to do it right, with incremental enhancement based on available features/resources. But then you will also be incompetent to do it right with UA sniffing, which is even harder and require more maintenance to keep the list up-to-date. That's the obtuse thought process on how you get the garbage google just showed us.
- acdha 3y ago
  This level of condescension isn’t helpful, especially as you’re wrong to make such an absolute assertion rather than describing the right or wrong reasons to use a tool. UA sniffing should be a last resort but there have been times where browsers have claimed to support something but had hard to detect bugs and the cleanest way to handle it was to pretend the feature detection failed on those older browsers. This is increasingly rare – the last time I had to do it was for Internet Explorer – but I would not take a bet that nobody will ever have a need for it again. As an example, I recently had to deal with an exception to a TLS 1.2 requirement because while almost all of our traffic is from modern user agents, there was a group of blind users with braille displays using Android KitKat which defaults to only supporting a maximum of TLS 1.1 and “go buy an expensive new device” isn’t an appropriate response even though you might be entirely comfortable saying that random internet crawlers getting an error is okay.
  - 1oooqooq 3y ago
    You proved my (overly condescending) point. You either support older TLS or you don't. Do not try to fine tune it to one known audience. You just locked everyone that is not in the sample you just whitelisted(!) out of your service. But you don't know about them, so no harm? If you think one use case for tls1.1 is OK for one use case, just accept you support it. Same for every thing else. Every time you use UA sniff, you are doing it wrong. not matter how smart you think you are. You are not. It's just a momentary feel good because you are oblivious to everything else. Just like you felt good when you blocked tls1.1 before knowing of those blind users. Now you felt good allowing those blind users because you still don't know about another group that you might learn tomorrow or never, because you are blocking them :)
xcdzvyn 3y ago
Detecting the user's OS to provide the right binary download link?
- suprfsat 3y ago
  Google Earth still asks me to choose "64 bit .deb (For Debian/Ubuntu)" or "64 bit .rpm (For Fedora/openSUSE)", but I guess user agent sniffing wouldn't help that.
RulerOf 3y ago
There've been a few, but the first one that impacted me was Chrome's switch to requiring the SameSite=None flag on Set-Cookie headers[1] in a third party context. > Warning: A number of older versions of browsers including Chrome, Safari, and UC browser are incompatible with the new None attribute and may ignore or restrict the cookie. This caveat meant that UA sniffing was the only reliable means of setting cookies that were guaranteed to work properly. 1: https://web.dev/articles/samesite-cookies-explained https://web.dev/articles/samesite-cookies-explained
scott_w 3y ago
We’ve seen browsers behave differently in subtle ways. To mitigate impact while we figured out the correct fix, we’ve served different content to them so those users still get a working experience while we figure out and fix the underlying issue. This had nothing to do with feature detection, so the usual suggestions simply won’t work.
dathinab 3y ago
yesn't basically you can send slightly less data by only sending the relevant layout/js code etc. with the first request instead of sending some variation which then the browser selects/branches one most likely a terrible optimization for most sides maybe not google search due to how much it's called but then Google is (as far as I remember) also the company which has tried to push the removal of UA strings (by fixating all UA strings to the same string, or at least a small set of strings)... so quite ironic
rstuart4133 3y ago
One notable thing about the Google search homepage is how fast it is. It's gob smackingly quick. It responds to the initial key press under in under 200ms with 10 suggestions that include text and pictures, and keeps doing it. My round trip time to www.google.com is around 20ms, so at least 100ms of that time is swallowed by the internet. You don't get that sort of speed without heavy optimisation. In fact I'd be amazed if www.google.com isn't the most heavily optimised page on the internet. So it's not at all surprising to me that they optimise based on what browser is asking.
- ndriscoll 3y ago
  Wouldn't a 20 ms RTT mean 20 ms is swallowed by the Internet? As long as your 10 suggestions fit within the TCP receive window, you already have an active connection from the initial page load, so it's 1 RTT to get the data (you could put the images into data URIs so everything could be gathered in 1 fetch, right?). I'd expect the UI update to set a list of 10 items should also take way less time than a single frame. The 200 ms search seems impressive without me knowing much about what it needs to do, but the UI portion seems trivial?

by rendaw 3y ago

Is there any legitimate use for UA string sniffing vs feature detection? And what could a search engine possibly do that's so bleeding edge it doesn't work in all browsers?

throwaway167 3y ago

Track you in new and exciting ways.

PlutoIsAPlanet 3y ago

Google provides a more basic webpage for older browsers.

klabb3 3y ago
Introducing ‘about: blank’ by Google. A new way to experience the web.
- djbusby 3y ago
  Will be shuttered in less than 5 years.
  - sumtechguy 3y ago
    such optimism!
Aissen 3y ago
And they often do that wrongly. Try typing "weather" in Firefox for Android vs Chrome for Android; a vastly inferior version is shown on Firefox. Changing the UA or using desktop mode makes the page work flawlessly.
- Miner49er 3y ago
  Wow, that's very anticompetitive.

1oooqooq 3y ago

No. But you might be misguided if you are incompetent to do it right, with incremental enhancement based on available features/resources. But then you will also be incompetent to do it right with UA sniffing, which is even harder and require more maintenance to keep the list up-to-date. That's the obtuse thought process on how you get the garbage google just showed us.

acdha 3y ago
This level of condescension isn’t helpful, especially as you’re wrong to make such an absolute assertion rather than describing the right or wrong reasons to use a tool. UA sniffing should be a last resort but there have been times where browsers have claimed to support something but had hard to detect bugs and the cleanest way to handle it was to pretend the feature detection failed on those older browsers. This is increasingly rare – the last time I had to do it was for Internet Explorer – but I would not take a bet that nobody will ever have a need for it again. As an example, I recently had to deal with an exception to a TLS 1.2 requirement because while almost all of our traffic is from modern user agents, there was a group of blind users with braille displays using Android KitKat which defaults to only supporting a maximum of TLS 1.1 and “go buy an expensive new device” isn’t an appropriate response even though you might be entirely comfortable saying that random internet crawlers getting an error is okay.
- 1oooqooq 3y ago
  You proved my (overly condescending) point. You either support older TLS or you don't. Do not try to fine tune it to one known audience. You just locked everyone that is not in the sample you just whitelisted(!) out of your service. But you don't know about them, so no harm? If you think one use case for tls1.1 is OK for one use case, just accept you support it. Same for every thing else. Every time you use UA sniff, you are doing it wrong. not matter how smart you think you are. You are not. It's just a momentary feel good because you are oblivious to everything else. Just like you felt good when you blocked tls1.1 before knowing of those blind users. Now you felt good allowing those blind users because you still don't know about another group that you might learn tomorrow or never, because you are blocking them :)

xcdzvyn 3y ago

Detecting the user's OS to provide the right binary download link?

suprfsat 3y ago
Google Earth still asks me to choose "64 bit .deb (For Debian/Ubuntu)" or "64 bit .rpm (For Fedora/openSUSE)", but I guess user agent sniffing wouldn't help that.

RulerOf 3y ago

There've been a few, but the first one that impacted me was Chrome's switch to requiring the SameSite=None flag on Set-Cookie headers[1] in a third party context. > Warning: A number of older versions of browsers including Chrome, Safari, and UC browser are incompatible with the new None attribute and may ignore or restrict the cookie. This caveat meant that UA sniffing was the only reliable means of setting cookies that were guaranteed to work properly. 1: https://web.dev/articles/samesite-cookies-explained https://web.dev/articles/samesite-cookies-explained

scott_w 3y ago

We’ve seen browsers behave differently in subtle ways. To mitigate impact while we figured out the correct fix, we’ve served different content to them so those users still get a working experience while we figure out and fix the underlying issue. This had nothing to do with feature detection, so the usual suggestions simply won’t work.

dathinab 3y ago

yesn't basically you can send slightly less data by only sending the relevant layout/js code etc. with the first request instead of sending some variation which then the browser selects/branches one most likely a terrible optimization for most sides maybe not google search due to how much it's called but then Google is (as far as I remember) also the company which has tried to push the removal of UA strings (by fixating all UA strings to the same string, or at least a small set of strings)... so quite ironic

rstuart4133 3y ago

One notable thing about the Google search homepage is how fast it is. It's gob smackingly quick. It responds to the initial key press under in under 200ms with 10 suggestions that include text and pictures, and keeps doing it. My round trip time to www.google.com is around 20ms, so at least 100ms of that time is swallowed by the internet. You don't get that sort of speed without heavy optimisation. In fact I'd be amazed if www.google.com isn't the most heavily optimised page on the internet. So it's not at all surprising to me that they optimise based on what browser is asking.

ndriscoll 3y ago
Wouldn't a 20 ms RTT mean 20 ms is swallowed by the Internet? As long as your 10 suggestions fit within the TCP receive window, you already have an active connection from the initial page load, so it's 1 RTT to get the data (you could put the images into data URIs so everything could be gathered in 1 fetch, right?). I'd expect the UI update to set a list of 10 items should also take way less time than a single frame. The 200 ms search seems impressive without me knowing much about what it needs to do, but the UI portion seems trivial?