Chrome phasing out support for User-Agent • Hacker News Board

Re: Chrome phasing out support for User-Agent

#31

Post by ldoughty » Wed, Mar 25, 2020, 3:38 PM UTC

ravenstine wrote: post #27

This is a good idea, and is something I've thought of for a while; the user agent header was a mistake from both a privacy and a UX perspective. Ideally, web browsers should attempt to treat the content the same no matter what device you are on. There shouldn't be an iOS-web, and a Chrome-web, and a Firefox-web, and an Edge-web; there should just be the web. In which case, a user-agent string that contains the browse…

I agree, but this also is incredibly dependent on the major players (e.g. Google) not going off on their own making changes without agreement from other browsers...

There are still issues today where chrome, edge, and Firefox render slightly differently. I certainly agree user agent isn't terribly necessary, but it's literally the only hook to identify when css or JavaScript needs to change... Or to support people on older browsers (e.g. Firefox ESR). How can I know when I can update my website to newer language versions without metrics confirming my users support the new ES version?

I would argue simplifying the UA, product + major revision, maybe, or information relevant to rendering and JavaScript only

Re: Chrome phasing out support for User-Agent

#32

Post by onion2k » Wed, Mar 25, 2020, 3:41 PM UTC

gregoriol wrote: post #4

As usual, this will fuck up the users, and not the techy nerds making such decisions, but the average joe because things on the internet will be broken for them.

this will fuck up the users

That's a downside if it happens, but the upsides (privacy, forcing devs to use feature detection instead, etc) still means it's worthwhile.

Re: Chrome phasing out support for User-Agent

#33

Post by olsonjeffery » Wed, Mar 25, 2020, 3:43 PM UTC

At my employer we are using UserAgent to detect the browser so that we can drive SameSite cookie policy for our various sites (e.g. IE11 and Edge, which we still support, doesn't support SameSite: None).

There are a variety of scenarios where this comes up (e.g. we ship a site that is rendered, by another vendor, within an iframe; so we have to set SameSite: None on our application's session cookie so that it's valid within the iframe, thus allowing AJAX calls originating from within the iframe to work based on our current auth scheme.. BUT only within Chrome 70+, Firefox but NOT IE, Safari, etc).

Just providing this as an example of backend applications needing to deal with browser-specific behavior, since most of the examples cited in other comments are about rendering/css/javascript features on the client and how UserAgent drives that.

Re: Chrome phasing out support for User-Agent

#34

Post by _bxg1 » Wed, Mar 25, 2020, 3:48 PM UTC

ldoughty wrote: post #31

ravenstine wrote: post #27

This is a good idea, and is something I've thought of for a while; the user agent header was a mistake from both a privacy and a UX perspective. Ideally, web browsers should attempt to treat the content the same no matter what device you are on. There shouldn't be an iOS-web, and a Chrome-web, and a Firefox-web, and an Edge-web; there should just be the web. In which case, a user-agent string that contains the browse…

I agree, but this also is incredibly dependent on the major players (e.g. Google) not going off on their own making changes without agreement from other browsers... There are still issues today where chrome, edge, and Firefox render slightly differently. I certainly agree user agent isn't terribly necessary, but it's literally the only hook to identify when css or JavaScript needs to change... Or to support people on…

Thinking cynically, it could be a power-move by Google to strengthen their hold on the ecosystem.

Right now when they go out and make their own API changes without consensus (which already happens), it's possible to distinguish the "for Chrome" case and still support the standard. But if there were no User-Agent, and Google wanted to strongarm the whole group into something, and 90% of browsers are Chromium-based, devs will likely just support the Chromium version and everyone else will have no choice but to fall in line.

Re: Chrome phasing out support for User-Agent

#35

Post by logfromblammo » Wed, Mar 25, 2020, 3:49 PM UTC

niea_11 wrote: post #22

abhishekjha wrote: post #3

I was wondering. Isn't the page rendered on mobile and desktop based on user-agents? How would that work now?

If you want to just change the styling and layout of the page depending on the user's device, then you can use css's media queries[0]. But if you want to serve two totally different pages (one for mobile and another for desktop), then I don't see how it can be done without JS or reading the user agent. [0] : https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queri...

If you want to serve two totally different pages, you use two totally different URLs, and don't try to second-guess what the user asked for.

Re: Chrome phasing out support for User-Agent

#36

Post by jorams » Wed, Mar 25, 2020, 3:49 PM UTC

The weird thing about this is that the only company I've seen doing problematic user-agent handling in recent years is Google themselves. They have released several products as Chrome-only, which then turned out to work fine in every other browser if they just pretended to be Chrome through the user agent. Same with their search pages, which on mobile were very bad in every non-Chrome browser purely based on user agent sniffing.

Re: Chrome phasing out support for User-Agent

#37

Post by jaywalk » Wed, Mar 25, 2020, 3:54 PM UTC

jorams wrote: post #36

The weird thing about this is that the only company I've seen doing problematic user-agent handling in recent years is Google themselves. They have released several products as Chrome-only, which then turned out to work fine in every other browser if they just pretended to be Chrome through the user agent. Same with their search pages, which on mobile were very bad in every non-Chrome browser purely based on user age…

I'm sure Google won't build in some proprietary way for them to identify Chrome.

/s

Re: Chrome phasing out support for User-Agent

#38

Post by jt2190 » Wed, Mar 25, 2020, 3:54 PM UTC

olsonjeffery wrote: post #33

At my employer we are using UserAgent to detect the browser so that we can drive SameSite cookie policy for our various sites (e.g. IE11 and Edge, which we still support, doesn't support SameSite: None). There are a variety of scenarios where this comes up (e.g. we ship a site that is rendered, by another vendor, within an iframe; so we have to set SameSite: None on our application's session cookie so that it's valid…

The proposed User Agent Client Hints API would replace this: https://wicg.github.io/ua-client-hints/

Re: Chrome phasing out support for User-Agent

#39

Post by eh78ssxv2f » Wed, Mar 25, 2020, 3:55 PM UTC

jorams wrote: post #36

The weird thing about this is that the only company I've seen doing problematic user-agent handling in recent years is Google themselves. They have released several products as Chrome-only, which then turned out to work fine in every other browser if they just pretended to be Chrome through the user agent. Same with their search pages, which on mobile were very bad in every non-Chrome browser purely based on user age…

Google is probably so big that we might as well consider Chrome and rest of the Google as separate entities.

Re: Chrome phasing out support for User-Agent

#40

Post by derefr » Wed, Mar 25, 2020, 3:57 PM UTC

These days, it feels like the sole use of User-Agent is as a weak defence against web scraping. I've written a couple of scrapers (legitimate ones, for site owners that requested machine-readable versions of their own data!) where the site would reject me if I did a plain `curl`, but as soon as I hit it with -H "User-Agent: [my chrome browser's UA string]", it'd work fine. Kind of silly, when it's such a small deterrent to actually-malicious actors.

(Also kind of silly in that even real browser-fingerprinting setups can be defeated by a sufficiently-motivated attacker using e.g. https://www.npmjs.com/package/puppeteer-extra-plugin-stealth, but I guess sometimes a corporate mandate to block scraping comes down, and you just can't convince them that it's untenable.)