4 ms·

Assuming that the problem here is people doing UA sniffing, the problem, like with people doing glue sniffing, is to stop people sniffing the UA (or glue) - not

Assuming that the problem here is people doing UA sniffing, the problem, like with people doing glue sniffing, is to stop people sniffing the UA (or glue) - not to make the UA (or glue) unusable for it's intended purpose. Have you ever used a service that shows things like your active sessions, login attempts etc? Notice how they basically all show you what kind of device and usually what browser the session/login is from, with a date time and usually location? If everyone pretends to be Chrome what's the fucking point any more? "You logged in from Chrome on Tuesday the 3rd at 8am". "Well no I fucking didn't, I guess I better go reset my damn passwords again".

denormalfloat 7y ago
There are wrong reasons to sniff the UA string, and less wrong reasons. If a Browser has a bug that gets fixed in later versions, sites have to sniff the UA string to do the right thing. For example, a browser bug may cause people to see an error, and the they are using an old version of the browser. The right thing to do is to upgrade, but how to tell? When you are subject to the bugs of some other code, and which are skewed across different versions of the software, the most reasonable way to work around it is by UA sniffing.
- zeta0134 7y ago
  I would have bought this argument a decade ago, but at this stage the number of site users not doing some form of automatic updates on their browser should be in the minority. The problems user agents were designed to solve back in the Netscape Navigator days have since been standardized using much better signals, and the odd standards compliance bug here and there isn't really justification for something as weak and unreliable as a user agent string. I say kill it. Fix it to some static value and require new sites moving forward to do proper feature detection if they really care to work around standards bugs or use experimental new features.
  - dgoldstein0 7y ago
    The core web features don't have such bugs anymore for all practical purposes, but newer apis do. Content security policy in particular has a lot of bugs especially around features in v2 and v3 of the spec, when they were first implemented in chrome / Firefox often took a few major versions to get right. I think I've seen similar hacks around use of newer crypto apis. The alternative is to wait 2-3 years between the release of a new api by all major browsers and actually using it.
    - Zarel 7y ago
      Sadly, feature detection is still impossible for many features. For instance, the only way to detect `contentEditable` support is through user-agent sniffing. Many versions of Android Chrome and iOS Safari will happily report that they support `contentEditable` and then refuse to make the content editable. I'm actually struggling with a similar issue right now: there's no way to detect an on-screen keyboard, so there's no way to focus a textbox only if it wouldn't cover up the screen with an on-screen keyboard (which is pretty important for chat apps). The best you can do involves a lot of hacks, including UA sniffing.
      - dgoldstein0 7y ago
        Ouch. Wasn't aware of those. But still not surprised there are edge cases out there. If I look hard enough, I can always find places where different browser behaviors differ. For instance, I once discovered that the maximum top value I could put a position absolute div within a position relative div was around 20 million px in chrome but only 1.53 million in IE (if my memory serves). This was at least fixable by stacking multiple divs for every 1.5 million pixels I wanted to lay out. But for every quirk like this that's possible to work around by coding to the lowest common denominator, there's another somewhere that you just can't. I recall doing another project which involved trying to pop open a mobile app to view content; and it was supposed to switch to the store to prompt you to install if you didn't have the app. At the time this involved different hacks for iOS Safari and Android chrome. Behaviors that differed included what happened when you navigate to a scheme with no handler (in chrome, the previous page kept running), and whether the scheme could trigger the app from an iframe (which was blocked in chrome but not Safari iirc). And handing off state to the app during the install flow was simple on Android, but on iOS required another pile of hacks. Whole thing ended up an overcomplicated mess, but we ended up pretty good ux for the intended flows. This was 2014 so the situation is probably better today - I think iOS Safari added some meta tags that are targeted to very similar use cases.
  - wongarsu 7y ago
    That depends on your user base. For example [1] sees about 10-20% of Chrome and Firefox users on some notably "outdated" version. If your demographic skews towards enterprise users that seems very plausible, large companies regularly hold updates back until they are tested or use extended support releases. 1: https://www.stetic.com/market-share/browser/ https://www.stetic.com/market-share/browser/
- CM30 7y ago
  For most CSS and JavaScript incompatibility issues, the way to check doesn't require UA sniffing at all. You merely check if the browser supports said feature by looking for whether the supports media query runs or if the new method is available at all. https://developer.mozilla.org/en-US/docs/Web/CSS/@supports https://developer.mozilla.org/en-US/docs/Web/CSS/@supports
  - silverwind 7y ago
    @supports is often unreliable for CSS features. At least in Blink, it acts more as a "valid syntax" check then a "supported feature" check and for some reason Blink's CSS engine recognizes many new CSS features as valid syntax while not actually supporting them.
- namibj 7y ago
  I for one would serve adapted css that is matched to the browser. Due to vendor prefixes there is unfortunately some mandatory bloat for a cross-browser stylesheet. It would also skip polyfills when those aren't needed.
bryanrasmussen 7y ago
obviously what will happen with those services that need to know what browser you logged in at is they will do more vigorous capability based checking to determine your browser - sort of like how css used to have all sorts of hacks to target particular browsers.
- stephenr 7y ago
  ... You're suggesting that rather than using the user agent, to identify.. the user agent, because people abused user agent strings to detect features... sites will now need to detect features and maintain a complete matrix of the features every browser and version implements, and determine the browser name, from the features it supports? You realise how ridiculous that sounds right? Or did you just completely misunderstand what I was talking about: Some sites (and I've built some that do this) will show e.g. login history or account activity for users, and might say e.g. "Logged in from London using Chrome v52 on a Windows 8 PC on Tuesday at 10pm". It's very much for human consumption.
  - bryanrasmussen 7y ago
    Yes I realize how ridiculous that sounds, but on the other hand if the old way of doing it will no longer work and people need to do it they will find another way. Generally technically less nice to work with and all sorts of other attendant problems but that's the breaks. I believe this is a bad idea, but it looks like the bad idea is coming to pass. I mean considering that if browser makers go along with this way of doing it, necessitating the hacky way of finding out what browser one is using. I think they will go along with it, but maybe also reason will prevail? I suppose what will happen if this gets widespread is something like modernizr to detect all possible features (also those in development pipelines), and then take those features and use something like the caniuse api https://www.npmjs.com/package/caniuse-api https://www.npmjs.com/package/caniuse-api to give you what browsers are possible for each feature, leading to some point where you can narrow it down to browser name, version.
basicplus2 7y ago
I vote this comment of the month

denormalfloat 7y ago

There are wrong reasons to sniff the UA string, and less wrong reasons. If a Browser has a bug that gets fixed in later versions, sites have to sniff the UA string to do the right thing. For example, a browser bug may cause people to see an error, and the they are using an old version of the browser. The right thing to do is to upgrade, but how to tell? When you are subject to the bugs of some other code, and which are skewed across different versions of the software, the most reasonable way to work around it is by UA sniffing.

zeta0134 7y ago
I would have bought this argument a decade ago, but at this stage the number of site users not doing some form of automatic updates on their browser should be in the minority. The problems user agents were designed to solve back in the Netscape Navigator days have since been standardized using much better signals, and the odd standards compliance bug here and there isn't really justification for something as weak and unreliable as a user agent string. I say kill it. Fix it to some static value and require new sites moving forward to do proper feature detection if they really care to work around standards bugs or use experimental new features.
- dgoldstein0 7y ago
  The core web features don't have such bugs anymore for all practical purposes, but newer apis do. Content security policy in particular has a lot of bugs especially around features in v2 and v3 of the spec, when they were first implemented in chrome / Firefox often took a few major versions to get right. I think I've seen similar hacks around use of newer crypto apis. The alternative is to wait 2-3 years between the release of a new api by all major browsers and actually using it.
  - Zarel 7y ago
    Sadly, feature detection is still impossible for many features. For instance, the only way to detect `contentEditable` support is through user-agent sniffing. Many versions of Android Chrome and iOS Safari will happily report that they support `contentEditable` and then refuse to make the content editable. I'm actually struggling with a similar issue right now: there's no way to detect an on-screen keyboard, so there's no way to focus a textbox only if it wouldn't cover up the screen with an on-screen keyboard (which is pretty important for chat apps). The best you can do involves a lot of hacks, including UA sniffing.
    - dgoldstein0 7y ago
      Ouch. Wasn't aware of those. But still not surprised there are edge cases out there. If I look hard enough, I can always find places where different browser behaviors differ. For instance, I once discovered that the maximum top value I could put a position absolute div within a position relative div was around 20 million px in chrome but only 1.53 million in IE (if my memory serves). This was at least fixable by stacking multiple divs for every 1.5 million pixels I wanted to lay out. But for every quirk like this that's possible to work around by coding to the lowest common denominator, there's another somewhere that you just can't. I recall doing another project which involved trying to pop open a mobile app to view content; and it was supposed to switch to the store to prompt you to install if you didn't have the app. At the time this involved different hacks for iOS Safari and Android chrome. Behaviors that differed included what happened when you navigate to a scheme with no handler (in chrome, the previous page kept running), and whether the scheme could trigger the app from an iframe (which was blocked in chrome but not Safari iirc). And handing off state to the app during the install flow was simple on Android, but on iOS required another pile of hacks. Whole thing ended up an overcomplicated mess, but we ended up pretty good ux for the intended flows. This was 2014 so the situation is probably better today - I think iOS Safari added some meta tags that are targeted to very similar use cases.
- wongarsu 7y ago
  That depends on your user base. For example [1] sees about 10-20% of Chrome and Firefox users on some notably "outdated" version. If your demographic skews towards enterprise users that seems very plausible, large companies regularly hold updates back until they are tested or use extended support releases. 1: https://www.stetic.com/market-share/browser/ https://www.stetic.com/market-share/browser/
CM30 7y ago
For most CSS and JavaScript incompatibility issues, the way to check doesn't require UA sniffing at all. You merely check if the browser supports said feature by looking for whether the supports media query runs or if the new method is available at all. https://developer.mozilla.org/en-US/docs/Web/CSS/@supports https://developer.mozilla.org/en-US/docs/Web/CSS/@supports
- silverwind 7y ago
  @supports is often unreliable for CSS features. At least in Blink, it acts more as a "valid syntax" check then a "supported feature" check and for some reason Blink's CSS engine recognizes many new CSS features as valid syntax while not actually supporting them.
namibj 7y ago
I for one would serve adapted css that is matched to the browser. Due to vendor prefixes there is unfortunately some mandatory bloat for a cross-browser stylesheet. It would also skip polyfills when those aren't needed.

bryanrasmussen 7y ago

obviously what will happen with those services that need to know what browser you logged in at is they will do more vigorous capability based checking to determine your browser - sort of like how css used to have all sorts of hacks to target particular browsers.

stephenr 7y ago
... You're suggesting that rather than using the user agent, to identify.. the user agent, because people abused user agent strings to detect features... sites will now need to detect features and maintain a complete matrix of the features every browser and version implements, and determine the browser name, from the features it supports? You realise how ridiculous that sounds right? Or did you just completely misunderstand what I was talking about: Some sites (and I've built some that do this) will show e.g. login history or account activity for users, and might say e.g. "Logged in from London using Chrome v52 on a Windows 8 PC on Tuesday at 10pm". It's very much for human consumption.
- bryanrasmussen 7y ago
  Yes I realize how ridiculous that sounds, but on the other hand if the old way of doing it will no longer work and people need to do it they will find another way. Generally technically less nice to work with and all sorts of other attendant problems but that's the breaks. I believe this is a bad idea, but it looks like the bad idea is coming to pass. I mean considering that if browser makers go along with this way of doing it, necessitating the hacky way of finding out what browser one is using. I think they will go along with it, but maybe also reason will prevail? I suppose what will happen if this gets widespread is something like modernizr to detect all possible features (also those in development pipelines), and then take those features and use something like the caniuse api https://www.npmjs.com/package/caniuse-api https://www.npmjs.com/package/caniuse-api to give you what browsers are possible for each feature, leading to some point where you can narrow it down to browser name, version.

basicplus2 7y ago

I vote this comment of the month