5 ms·

It's 2023. Why are we still doing user agent detection? We're supposed to do feature detection. userAgent is deprecated. https://developer.mozilla.org/en-US/d

It's 2023. Why are we still doing user agent detection? We're supposed to do feature detection. userAgent is deprecated. https://developer.mozilla.org/en-US/docs/Web/API/Navigator/userAgent https://developer.mozilla.org/en-US/docs/Web/API/Navigator/u...

madeofpalk 4y ago
How do you detect whether the user's browser has a slow implementation of an API without actually freezing the browser for 8 seconds?
- vlovich123 4y ago
  1. Pick the API that's most likely to be the fastest (based on marketshare) as the default to use. 2. Use `setInterval` to start your benchmark routine. 3. Benchmark function runs the API using a simple loop that will return quickly (i.e. within 2ms) using performance.now to evaluate. 4. When you obtain enough samples to indicate an alternate path is faster disable the benchmark function No freezing the browser. Shouldn't take too long to switch to an optimized version. That being said, this is a lot of complexity / hard to implement in a robust and fast way so I'm not saying it's a better answer.
  - madeofpalk 4y ago
    Yeah or just test the user agent.
tuwtuwtuwtuw 4y ago
Not always that simple. Where I work I need to provide a list of browsers customers can use, list those in the documentation and make sure QA test all of them and block any others. Bugs in the app can lead to big issues and telling the customers to use whatever browser suits them and "if it works it works" is not good enough. There are still large differences between browsers that feature existence is not same as feature conptivinility. Of course customers can tweak user agent and "lie" about their browser but then responsibility of issues is shifted to them.
- 3np 4y ago
  > block any others. I get all the rest but not this part. A banner should work plenty?
  - tuwtuwtuwtuw 4y ago
    I think it depends. Let's say I sell my finance application to an organization with 10k employees. They then use it to handle transactions on around 100mil per month. If there are bugs, it may result in money being transfered to the wrong company, or money being transfered without proper approval. Maybe unlikely bugs but could happen. I can show a banner telling each of the 10k users about browser requirements. I guess that around 99% of the users will ignore that banner and happily proceed with unsupported browsers. If I don't know if it will work with the browser they are using, why should I let them perform transactions using it? Sure, if it goes wrong maybe I can tell the CFO that their employee ignored the banner, but that won't make him happy. For me selling the service there are zero benefits with allowing arbitrary browsers.
capableweb 4y ago
Does using `window.navigator.userAgent` still work? Does it still return the actual user-agent? Yes, and because it does, people will use it. You (or standards) bodies can scream from the top of the mountains that it's deprecated, but it won't matter, because if it's there, it will be used.
- Szpadel 4y ago
  but Microsoft should understand why this is an issue, they had to rename their windows from 9 to 10 because applications did check based on os name string and just exit after detecting it contains "windows 9" as it suppose to match windows 95 and windows 98
  - capableweb 4y ago
    Microsoft is a huge corporation with multiple different identities inside of it, like every international super-conglomerate. The people who work on the OS are very different people who work on the web stuff.
  - ivandenysov 4y ago
    Where can I read more about this?
    - Szpadel 4y ago
      I don't think that there was any well written article about as it was very plausible rumor. but you can see eg: https://searchcode.com/?q=osname.startswith%28%22windows+9%22%29 https://searchcode.com/?q=osname.startswith%28%22windows+9%2... to see this issue present in a lot of publicly available source code.
      - MikusR 4y ago
        Quick look and most of those results are checking for macosx version or really old code where the only windows is 95 and not even xp.
  - 4y ago
TAKEMYMONEY 4y ago
My guess is that they aren't using user agent detection, for reasons you mentioned. It's unlikely they QA unstable browsers, but some in this thread are reporting the same on FF stable.
Dispatch1902 4y ago
I use the same userAgents in all of my web-scraper code, I just copy and paste my user-agent string after all these years. It is still an old FireFox user agent I got somewhere. I should test my code and see if it still works after all these years. At the time, it was the only userAgent string which didn't lead to being limited. It was almost like an invisibility cloak for my bots.
issafram 4y ago
Just look at all the big companies doing it https://faisalman.github.io/ua-parser-js/ https://faisalman.github.io/ua-parser-js/
- pentagrama 4y ago
  That tool says that I'm on Windows 10 but I'm on 11, so not 100% accurate.
nforgerit 4y ago
I get the best practice and why relying on the User Agent is helplessly flawed, but I've never come across a better way to get a sneak peek into the (first) Initial Page Request of a customer to your web app. E.g. if you'd wanted to improve the page performance and weight of your app, you'll want to keep unused js/css to near zero. If you'd rely on feature detection, your critical path for "showing the initial screen of the app" is bound to "download feature detect, parse it, execute it, fetch correct variants of your js/css packages, parse them, execute them, show screen". That's not cool, imho.
- judge2020 4y ago
  Changing the UA only changes the behavior of the web server, so unless that's some block of untouchable code owned by some other team made to 'optimize' page loads for different clients, you're not doing yourself any favors by changing it in your browser; you should be loading up the client itself since you can't simulate the actual engine loading your web app differently. > If you'd rely on feature detection, your critical path for "showing the initial screen of the app" is bound to "download feature detect, parse it, execute it, fetch correct variants of your js/css packages, parse them, execute them, show screen". That's not cool, imho. Even for barebones web apps, your initial html response should have either empty data (but otherwise a visible UI) or a SSR'd version of the page shown while the JS downloads and executes.
  - nforgerit 4y ago
    1) If clients spoof their UA, they just get what they asked for. Couldn't care less. 2) With SSR you're actually making a case for sniffing the UA for the client's device class. Web apps might need to ship vastly different but overlapping code across different device classes. I'm not even talking about things that can be lazily loaded subsequently, I'm talking about the initial screen for given URL. 3) I'm _not_ going to show the customer any loading spinner or just show a white page for 2s. We had that with Java Applets, remember? All in all, I'm not saying we should getting back into optimizing web apps for certain os/browsers/versions. What I'm saying is there might be good reasons where the mess of classifying the device on the (first) Initial Page Request is acceptable, given the alternatives.
deleted 4y ago
[deleted]
Jasper_ 4y ago
There are genuine differences in browsers that need to be handled correctly and aren't easily observable or runtime-detectable. Multimedia (needed for camera/mic handling) and WebRTC still remain a giant landmine that requires UA testing 10 years later. Web advocates can scream from the rooftops as much as they want that nobody should do UA testing, and then have basically no response when we encounter genuine browser bugs that can't be worked around.
dogma1138 4y ago
Because you’ll be surprised how many developers aren’t familiar with these things and how many of them think that they are more clever than the herd and do not validate their assumptions. It wouldn’t surprise me if some junior dev picked it up and then went to ask a senior dev how can they detect the browser version and they got a half assed reply hmm check the user agent and went on with that. 95% of the major bugs and security issues I see on a daily basis are due to this.
- nforgerit 4y ago
  I'm genuinely interested: How does UA sniffing for, e.g. a device class, introduce security issues that wouldn't exist w/o it?
  - dogma1138 4y ago
    UA isn’t the cause of security issues the same thought process or lack there off that led to UA being used as a proxy for compatibility in this cause is. But in a more general view reliance on an unreliable and user controlled data for decision making is a pretty common pitfall in the security world.
yeko 4y ago
Sometimes it is not possible due to bugs in browsers. For example, how do you know if calling a API will crash the browser? https://bugs.chromium.org/p/chromium/issues/detail?id=1183362 https://bugs.chromium.org/p/chromium/issues/detail?id=118336...
- account42 4y ago
  In that case you use that API whenever you can so that browser gets fixed ASAP.
  - oblio 4y ago
    Yeah, and that browser update is controlled by IT and they manage the CEOs laptop and you'll be fired if the site doesn't work on their laptop.

madeofpalk 4y ago

How do you detect whether the user's browser has a slow implementation of an API without actually freezing the browser for 8 seconds?

vlovich123 4y ago
1. Pick the API that's most likely to be the fastest (based on marketshare) as the default to use. 2. Use `setInterval` to start your benchmark routine. 3. Benchmark function runs the API using a simple loop that will return quickly (i.e. within 2ms) using performance.now to evaluate. 4. When you obtain enough samples to indicate an alternate path is faster disable the benchmark function No freezing the browser. Shouldn't take too long to switch to an optimized version. That being said, this is a lot of complexity / hard to implement in a robust and fast way so I'm not saying it's a better answer.
- madeofpalk 4y ago
  Yeah or just test the user agent.

tuwtuwtuwtuw 4y ago

Not always that simple. Where I work I need to provide a list of browsers customers can use, list those in the documentation and make sure QA test all of them and block any others. Bugs in the app can lead to big issues and telling the customers to use whatever browser suits them and "if it works it works" is not good enough. There are still large differences between browsers that feature existence is not same as feature conptivinility. Of course customers can tweak user agent and "lie" about their browser but then responsibility of issues is shifted to them.

3np 4y ago
> block any others. I get all the rest but not this part. A banner should work plenty?
- tuwtuwtuwtuw 4y ago
  I think it depends. Let's say I sell my finance application to an organization with 10k employees. They then use it to handle transactions on around 100mil per month. If there are bugs, it may result in money being transfered to the wrong company, or money being transfered without proper approval. Maybe unlikely bugs but could happen. I can show a banner telling each of the 10k users about browser requirements. I guess that around 99% of the users will ignore that banner and happily proceed with unsupported browsers. If I don't know if it will work with the browser they are using, why should I let them perform transactions using it? Sure, if it goes wrong maybe I can tell the CFO that their employee ignored the banner, but that won't make him happy. For me selling the service there are zero benefits with allowing arbitrary browsers.

capableweb 4y ago

Does using `window.navigator.userAgent` still work? Does it still return the actual user-agent? Yes, and because it does, people will use it. You (or standards) bodies can scream from the top of the mountains that it's deprecated, but it won't matter, because if it's there, it will be used.

Szpadel 4y ago
but Microsoft should understand why this is an issue, they had to rename their windows from 9 to 10 because applications did check based on os name string and just exit after detecting it contains "windows 9" as it suppose to match windows 95 and windows 98
- capableweb 4y ago
  Microsoft is a huge corporation with multiple different identities inside of it, like every international super-conglomerate. The people who work on the OS are very different people who work on the web stuff.
- ivandenysov 4y ago
  Where can I read more about this?
  - Szpadel 4y ago
    I don't think that there was any well written article about as it was very plausible rumor. but you can see eg: https://searchcode.com/?q=osname.startswith%28%22windows+9%22%29 https://searchcode.com/?q=osname.startswith%28%22windows+9%2... to see this issue present in a lot of publicly available source code.
    - MikusR 4y ago
      Quick look and most of those results are checking for macosx version or really old code where the only windows is 95 and not even xp.
- 4y ago

TAKEMYMONEY 4y ago

My guess is that they aren't using user agent detection, for reasons you mentioned. It's unlikely they QA unstable browsers, but some in this thread are reporting the same on FF stable.

Dispatch1902 4y ago

I use the same userAgents in all of my web-scraper code, I just copy and paste my user-agent string after all these years. It is still an old FireFox user agent I got somewhere. I should test my code and see if it still works after all these years. At the time, it was the only userAgent string which didn't lead to being limited. It was almost like an invisibility cloak for my bots.

issafram 4y ago

Just look at all the big companies doing it https://faisalman.github.io/ua-parser-js/ https://faisalman.github.io/ua-parser-js/

pentagrama 4y ago
That tool says that I'm on Windows 10 but I'm on 11, so not 100% accurate.

nforgerit 4y ago

I get the best practice and why relying on the User Agent is helplessly flawed, but I've never come across a better way to get a sneak peek into the (first) Initial Page Request of a customer to your web app. E.g. if you'd wanted to improve the page performance and weight of your app, you'll want to keep unused js/css to near zero. If you'd rely on feature detection, your critical path for "showing the initial screen of the app" is bound to "download feature detect, parse it, execute it, fetch correct variants of your js/css packages, parse them, execute them, show screen". That's not cool, imho.

judge2020 4y ago
Changing the UA only changes the behavior of the web server, so unless that's some block of untouchable code owned by some other team made to 'optimize' page loads for different clients, you're not doing yourself any favors by changing it in your browser; you should be loading up the client itself since you can't simulate the actual engine loading your web app differently. > If you'd rely on feature detection, your critical path for "showing the initial screen of the app" is bound to "download feature detect, parse it, execute it, fetch correct variants of your js/css packages, parse them, execute them, show screen". That's not cool, imho. Even for barebones web apps, your initial html response should have either empty data (but otherwise a visible UI) or a SSR'd version of the page shown while the JS downloads and executes.
- nforgerit 4y ago
  1) If clients spoof their UA, they just get what they asked for. Couldn't care less. 2) With SSR you're actually making a case for sniffing the UA for the client's device class. Web apps might need to ship vastly different but overlapping code across different device classes. I'm not even talking about things that can be lazily loaded subsequently, I'm talking about the initial screen for given URL. 3) I'm _not_ going to show the customer any loading spinner or just show a white page for 2s. We had that with Java Applets, remember? All in all, I'm not saying we should getting back into optimizing web apps for certain os/browsers/versions. What I'm saying is there might be good reasons where the mess of classifying the device on the (first) Initial Page Request is acceptable, given the alternatives.

deleted 4y ago

[deleted]

Jasper_ 4y ago

There are genuine differences in browsers that need to be handled correctly and aren't easily observable or runtime-detectable. Multimedia (needed for camera/mic handling) and WebRTC still remain a giant landmine that requires UA testing 10 years later. Web advocates can scream from the rooftops as much as they want that nobody should do UA testing, and then have basically no response when we encounter genuine browser bugs that can't be worked around.

dogma1138 4y ago

Because you’ll be surprised how many developers aren’t familiar with these things and how many of them think that they are more clever than the herd and do not validate their assumptions. It wouldn’t surprise me if some junior dev picked it up and then went to ask a senior dev how can they detect the browser version and they got a half assed reply hmm check the user agent and went on with that. 95% of the major bugs and security issues I see on a daily basis are due to this.

nforgerit 4y ago
I'm genuinely interested: How does UA sniffing for, e.g. a device class, introduce security issues that wouldn't exist w/o it?
- dogma1138 4y ago
  UA isn’t the cause of security issues the same thought process or lack there off that led to UA being used as a proxy for compatibility in this cause is. But in a more general view reliance on an unreliable and user controlled data for decision making is a pretty common pitfall in the security world.

yeko 4y ago

Sometimes it is not possible due to bugs in browsers. For example, how do you know if calling a API will crash the browser? https://bugs.chromium.org/p/chromium/issues/detail?id=1183362 https://bugs.chromium.org/p/chromium/issues/detail?id=118336...

account42 4y ago
In that case you use that API whenever you can so that browser gets fixed ASAP.
- oblio 4y ago
  Yeah, and that browser update is controlled by IT and they manage the CEOs laptop and you'll be fired if the site doesn't work on their laptop.