11 ms·

I wish people would stop trying to force inject cynicism into this because this is actually pretty amazing of an idea imo. If you look at browsers like Falkon o

by jchw 7y ago

I wish people would stop trying to force inject cynicism into this because this is actually pretty amazing of an idea imo. If you look at browsers like Falkon or QuteBrowser they are perfectly serviceable browsers but actually using them can be annoying due to UA sniffing, even by Google. In theory this is the solution to that problem. Freezing and unifying the UA will prevent everyone, including Google, from using it to gate features. I am a bit worried, though, about how we will continue to count marketshare. If the intent were to remove the UA it would be worse, but it does seem like browser marketshare analytics based on user agents may be coming to an end. (Disclosure: I work for Google on unrelated projects.)

shadowgovt 7y ago
Does this change allow for the server to refrain from having to do RPCs to the browser to get additional feature information to figure out what quirks the vended page / JS needs to be compatible with? I'm all for more privacy, but IIUC the main reason big sites like Google still do any UA sniffing at all is to minimize the latency / byte cost for the client in vending a web site that is expected to work.
- jchw 7y ago
  IMO: Old browsers will still send UAs, since obviously they’re not going to update for this change. New browsers should support enough of the web platform to obsolete this practice going forward.
  - Zarel 7y ago
    New browsers still don't support everything. One of my biggest questions: "Does this device have a keyboard?" (relevant for "should I show hints for keyboard shortcuts?") is still straight-up unanswerable, and all I can do is guess from the UA. Other questions include "should I tell the user to drag-and-drop?" "should I tell the user to tap?" etc.
    - jchw 7y ago
      Ideally, imo, most sites should use the web platform as intended and their sites will work fine regardless of input device. If you are using UA sniffing to determine if the device has a keyboard it will be wrong a lot of the time; you can’t tell if a Microsoft Surface has the keyboard attached or an iPad doesn't. you’d probably be no worse off trying to detect it by screen width, which is already a defacto way to detect mobile devices anyways, for better or worse. (The right solution is probably a new kind of API or media query.)
      - Zarel 7y ago
        I know, that's why I said "unanswerable" and "all I can do is guess". The specific feature this came up recently is whether or not a chat app should autofocus the input box. Ideally, the answer is "yes" if you have a keyboard (lets you start sending messages faster) and "no" if you don't (the on-screen keyboard would cover up the conversation and be distracting). There's, of course, no way to detect an iPad keyboard, so currently iPads miss out on autofocus. Discord, incidentally, uses an alternate solution: "don't autofocus the textbox, but instead detect keypresses outside the textbox and manually insert the corresponding letters in the box". This, of course, completely fails for various non-Latin keyboards, such as Japanese: if you type "chi", it will insert 「cひ」 instead of 「ち」.
    - phkahler 7y ago
      >> Other questions include "should I tell the user to drag-and-drop?" "should I tell the user to tap?" etc Why are you doing all that? Just offer the desktop version or Mobil version and be done with it. You dont need to figure out dev_caps in such detail.
      - Zarel 7y ago
        Because I still believe in the ideals of responsive web design. If a desktop user wants to use my site in a tiny window (maybe to tile it next to another window), they should still be able to use keyboard shortcuts. And if a user with a large screen wants to use touch interaction (maybe they have a Surface Studio), they should be able to. There's no reason to make multiple sites each with their own flaws, when you can just make one site that can do anything.
jackjeff 7y ago
I have been on receiving end of browser bugs, developing cutting edge JavaScript applications. It's VERY useful to be able to use the UA string to do something like: if (Chrome version X) then { do this crazy workaround because Chrome is broken } No. People don't even necessarily update to the latest version. The "Samsung Browser" was notorious for seemingly always be some old fork of Chrome or Chromium that would never update.
- pornel 7y ago
  That approach is fragile, because it won't stop applying the crazy workaround after Chrome version Y fixes the problem. You can't know which version it's going to be, and there's a chance you won't be maintaining that code anymore then.
  - wvenable 7y ago
    But if you can't sniff the browser version, you might still have to apply the crazy work around forever because you have no way of knowing when to stop. It works both ways.
    - dessant 7y ago
      The correct approach is to use feature detection. There are libraries available for it, such as Modernizr [1]. [1] https://modernizr.com/docs/#what-is-feature-detection https://modernizr.com/docs/#what-is-feature-detection
      - wvenable 7y ago
        You can't always feature detect bugs. I'm not sure why this entire thread is filled "use feature detection" when it's been historically clear that it isn't sufficient.
        shakna 7y ago
        Part of the proposed deprecation of the useragent is a JS API to expose the information.
Lx1oG-AWb6h_ZG0 7y ago
Meanwhile, Google is forcing this massive change across the web right now by defaulting cookies to SameSite=Lax, something that breaks a lot of login scenarios. The only way to fix it is to start emitting SameSite=None. BUT WAIT, a lot of fairly recent browsers (e.g., iOS < 13, Chrome 51-66) don't support it, so you actually need to do this crazy user agent sniffing to not break things: https://www.chromium.org/updates/same-site/incompatible-clients https://www.chromium.org/updates/same-site/incompatible-clie.... I find it ridiculous that one part of Chrome is forcing me to add user agent sniffing while another part is trying to deprecate it. They need to get their act together: their decisions have massive consequences across the ecosystem and they need to be more responsible.
- StavrosK 7y ago
  I've seen this complaint a lot, and to me it amounts to saying "this default is wildly insecure but is used by a tiny fraction of sites, so I'd rather keep the insecure default rather than ask those sites to add a single header". Perhaps you can correct me on why that's not so.
  - jes5199 7y ago
    because adding that single header breaks the behavior on old browsers
  - thayne 7y ago
    The problem isn't that they need to add a header. The problem is that they need to add the header _or not_ depending on which browser is making the request. Which means you have to sniff the user agent, even though pretty much everyone agrees browser agent sniffing causes problems, and the same browser that is pushing this change is also trying to get rid of the only way to know if that header should be set or not. And I think the chrome team could have come up with a solution that didn't involve browser sniffing, such as sending a header in the request identifying that SameSite=Lax is the defualt, or that SameSite=None is accepted. But instead they recommended sniffing the user-agent string.
    - 7y ago
pilif 7y ago
> In theory this is the solution to that problem How so? There is still an API to ask for more details, so you can continue to do exactly the same thing as before at the cost of a few additional API calls What am I not seeing? To me this feels like just adding more complexity to still end up at the same spot we are now.
owenmarshall 7y ago
It's a great technical decision that may hopefully drive sites towards web standards, but technical decisions don't exist in a vacuum and can't be analyzed in them. The world's biggest advertisement provider's browser arm isn't going to turn off a source of fingerprinting data unless they simply don't need it anymore. It's far more likely that Google is pulling the ladder up behind them: they can identify users without that fingerprinting data, so it's beneficial to deny it to their competitors. This can be simultaneously a great technical decision and a decision that entrenches Google.
kerkeslager 7y ago
> I am a bit worried, though, about how we will continue to count marketshare. If the intent were to remove the UA it would be worse, but it does seem like browser marketshare analytics based on user agents may be coming to an end. I think there's an implicit assumption a lot of people (not you) are making: that there's no cost in collecting data. There is: often you change things by observing them, and that's not always a good thing. There are big costs to UA strings.
cpeterso 7y ago
Google can start by phasing out UA sniffing on their own websites, such Google Stadia blocking Microsoft's Chromium Edge users: https://winbuzzer.com/2020/01/03/google-stadia-is-currently-blocked-on-microsofts-chromium-edge-browser-xcxwbn/ https://winbuzzer.com/2020/01/03/google-stadia-is-currently-...
bryanrasmussen 7y ago
as I observed in the previous thread on this subject you will still be able to gate features, just you won't use the UA to do it. It might also be that being able to detect exactly what browser someone is using will become a much harder undertaking, requiring significant investment of developer hours, that only some companies will have the resources to invest.
Supermancho 7y ago
> if the intent were to remove the UA it would be worse That is hopefully the end goal. It's not worse, it's an ideal that goes hand in hand with reducing cookie usage, removing flash, mandating SSL, etc. The UA was an attempt to see if the ecosystem could cooperate to make apps more actively intelligent. This is a failed experiment. Security teaches us to reduce attack surface and we should not be using half-measures like a header-string to trigger naive/implicit client behavior. Behaviors should be explicit for safety.

by jchw 7y ago

shadowgovt 7y ago

Does this change allow for the server to refrain from having to do RPCs to the browser to get additional feature information to figure out what quirks the vended page / JS needs to be compatible with? I'm all for more privacy, but IIUC the main reason big sites like Google still do any UA sniffing at all is to minimize the latency / byte cost for the client in vending a web site that is expected to work.

jchw 7y ago
IMO: Old browsers will still send UAs, since obviously they’re not going to update for this change. New browsers should support enough of the web platform to obsolete this practice going forward.
- Zarel 7y ago
  New browsers still don't support everything. One of my biggest questions: "Does this device have a keyboard?" (relevant for "should I show hints for keyboard shortcuts?") is still straight-up unanswerable, and all I can do is guess from the UA. Other questions include "should I tell the user to drag-and-drop?" "should I tell the user to tap?" etc.
  - jchw 7y ago
    Ideally, imo, most sites should use the web platform as intended and their sites will work fine regardless of input device. If you are using UA sniffing to determine if the device has a keyboard it will be wrong a lot of the time; you can’t tell if a Microsoft Surface has the keyboard attached or an iPad doesn't. you’d probably be no worse off trying to detect it by screen width, which is already a defacto way to detect mobile devices anyways, for better or worse. (The right solution is probably a new kind of API or media query.)
    - Zarel 7y ago
      I know, that's why I said "unanswerable" and "all I can do is guess". The specific feature this came up recently is whether or not a chat app should autofocus the input box. Ideally, the answer is "yes" if you have a keyboard (lets you start sending messages faster) and "no" if you don't (the on-screen keyboard would cover up the conversation and be distracting). There's, of course, no way to detect an iPad keyboard, so currently iPads miss out on autofocus. Discord, incidentally, uses an alternate solution: "don't autofocus the textbox, but instead detect keypresses outside the textbox and manually insert the corresponding letters in the box". This, of course, completely fails for various non-Latin keyboards, such as Japanese: if you type "chi", it will insert 「cひ」 instead of 「ち」.
  - phkahler 7y ago
    >> Other questions include "should I tell the user to drag-and-drop?" "should I tell the user to tap?" etc Why are you doing all that? Just offer the desktop version or Mobil version and be done with it. You dont need to figure out dev_caps in such detail.
    - Zarel 7y ago
      Because I still believe in the ideals of responsive web design. If a desktop user wants to use my site in a tiny window (maybe to tile it next to another window), they should still be able to use keyboard shortcuts. And if a user with a large screen wants to use touch interaction (maybe they have a Surface Studio), they should be able to. There's no reason to make multiple sites each with their own flaws, when you can just make one site that can do anything.

jackjeff 7y ago

I have been on receiving end of browser bugs, developing cutting edge JavaScript applications. It's VERY useful to be able to use the UA string to do something like: if (Chrome version X) then { do this crazy workaround because Chrome is broken } No. People don't even necessarily update to the latest version. The "Samsung Browser" was notorious for seemingly always be some old fork of Chrome or Chromium that would never update.

pornel 7y ago
That approach is fragile, because it won't stop applying the crazy workaround after Chrome version Y fixes the problem. You can't know which version it's going to be, and there's a chance you won't be maintaining that code anymore then.
- wvenable 7y ago
  But if you can't sniff the browser version, you might still have to apply the crazy work around forever because you have no way of knowing when to stop. It works both ways.
  - dessant 7y ago
    The correct approach is to use feature detection. There are libraries available for it, such as Modernizr [1]. [1] https://modernizr.com/docs/#what-is-feature-detection https://modernizr.com/docs/#what-is-feature-detection
    - wvenable 7y ago
      You can't always feature detect bugs. I'm not sure why this entire thread is filled "use feature detection" when it's been historically clear that it isn't sufficient.
      - shakna 7y ago
        Part of the proposed deprecation of the useragent is a JS API to expose the information.

Lx1oG-AWb6h_ZG0 7y ago

Meanwhile, Google is forcing this massive change across the web right now by defaulting cookies to SameSite=Lax, something that breaks a lot of login scenarios. The only way to fix it is to start emitting SameSite=None. BUT WAIT, a lot of fairly recent browsers (e.g., iOS < 13, Chrome 51-66) don't support it, so you actually need to do this crazy user agent sniffing to not break things: https://www.chromium.org/updates/same-site/incompatible-clients https://www.chromium.org/updates/same-site/incompatible-clie.... I find it ridiculous that one part of Chrome is forcing me to add user agent sniffing while another part is trying to deprecate it. They need to get their act together: their decisions have massive consequences across the ecosystem and they need to be more responsible.

StavrosK 7y ago
I've seen this complaint a lot, and to me it amounts to saying "this default is wildly insecure but is used by a tiny fraction of sites, so I'd rather keep the insecure default rather than ask those sites to add a single header". Perhaps you can correct me on why that's not so.
- jes5199 7y ago
  because adding that single header breaks the behavior on old browsers
- thayne 7y ago
  The problem isn't that they need to add a header. The problem is that they need to add the header _or not_ depending on which browser is making the request. Which means you have to sniff the user agent, even though pretty much everyone agrees browser agent sniffing causes problems, and the same browser that is pushing this change is also trying to get rid of the only way to know if that header should be set or not. And I think the chrome team could have come up with a solution that didn't involve browser sniffing, such as sending a header in the request identifying that SameSite=Lax is the defualt, or that SameSite=None is accepted. But instead they recommended sniffing the user-agent string.
  - 7y ago

pilif 7y ago

> In theory this is the solution to that problem How so? There is still an API to ask for more details, so you can continue to do exactly the same thing as before at the cost of a few additional API calls What am I not seeing? To me this feels like just adding more complexity to still end up at the same spot we are now.

owenmarshall 7y ago

It's a great technical decision that may hopefully drive sites towards web standards, but technical decisions don't exist in a vacuum and can't be analyzed in them. The world's biggest advertisement provider's browser arm isn't going to turn off a source of fingerprinting data unless they simply don't need it anymore. It's far more likely that Google is pulling the ladder up behind them: they can identify users without that fingerprinting data, so it's beneficial to deny it to their competitors. This can be simultaneously a great technical decision and a decision that entrenches Google.

kerkeslager 7y ago

> I am a bit worried, though, about how we will continue to count marketshare. If the intent were to remove the UA it would be worse, but it does seem like browser marketshare analytics based on user agents may be coming to an end. I think there's an implicit assumption a lot of people (not you) are making: that there's no cost in collecting data. There is: often you change things by observing them, and that's not always a good thing. There are big costs to UA strings.

cpeterso 7y ago

Google can start by phasing out UA sniffing on their own websites, such Google Stadia blocking Microsoft's Chromium Edge users: https://winbuzzer.com/2020/01/03/google-stadia-is-currently-blocked-on-microsofts-chromium-edge-browser-xcxwbn/ https://winbuzzer.com/2020/01/03/google-stadia-is-currently-...

bryanrasmussen 7y ago

as I observed in the previous thread on this subject you will still be able to gate features, just you won't use the UA to do it. It might also be that being able to detect exactly what browser someone is using will become a much harder undertaking, requiring significant investment of developer hours, that only some companies will have the resources to invest.

Supermancho 7y ago

> if the intent were to remove the UA it would be worse That is hopefully the end goal. It's not worse, it's an ideal that goes hand in hand with reducing cookie usage, removing flash, mandating SSL, etc. The UA was an attempt to see if the ecosystem could cooperate to make apps more actively intelligent. This is a failed experiment. Security teaches us to reduce attack surface and we should not be using half-measures like a header-string to trigger naive/implicit client behavior. Behaviors should be explicit for safety.