21 ms·

Chrome phasing out support for User-Agent

672 points by oftenwrong 7y ago

zmix 7y ago
Because, there can be only one user agent...!
PaulHoule 7y ago
If they're the dominant web browser people will assume you are using Chrome anyway.
abhishekjha 7y ago
I was wondering. Isn't the page rendered on mobile and desktop based on user-agents? How would that work now?
- untog 7y ago
  Not usually, no. CSS media queries are used to format according to display size. But as a sibling here has indicated, client hints will replace the user agent here.
- deleted 7y ago
  [deleted]
- fny 7y ago
  There not phasing out User-Agent strings entirely, they're actually upgrading them: https://github.com/WICG/ua-client-hints https://github.com/WICG/ua-client-hints It looks like there's more fine grained control in the new version.
  - timw4mail 7y ago
    Javascript-only is not an upgrade.
    - snazz 7y ago
      UA strings have never been an accurate indication. If you're not using JS, then you probably have no reason to be sniffing the UA string to detect browser features, since most of those features are JS-related anyway. It's an upgrade for the people who actually need to get an indication of the supported features and APIs of the user's browser. Otherwise, you should be using media queries.
      - oefrha 7y ago
        One exception: you might want to user sniff IE and serve a completely different version due to all the CSS problems. (I know you can use IE-only comments too, but I’ve been in the situation where making a modern version simultaneously IE9-compatible was just too frigging maddening.)
        Izkata 7y ago
        A bigger, site-breaking one from further up in this thread: https://news.ycombinator.com/item?id=22685632 https://news.ycombinator.com/item?id=22685632
      - Avamander 7y ago
        Detecting dumb search crawlers, that don't support major features required for my webapp, and displaying a fallback splash has been the only reasonable way I've found.
- tenebrisalietum 7y ago
  I thought it used Javascript to detect screen size. At least it should react to resize events and if the dimensions are something that align with mobile, it should switch to mobile mode.
  - NilsIRL 7y ago
    AFAIK it's also done using CSS
  - wlesieutre 7y ago
    In a lot of cases you shouldn't even use Javascript for this, responsive layouts can be built using CSS media queries based on viewport size. More advanced webapps might occasionally need to do something fancier than that if the mobile vs desktop functionality is (for some reason) substantially different instead of just rearranged. https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queri...
- kryptiskt 7y ago
  The typical way this is done these days is by media queries in CSS, so you'd write a rule for styling based on screen width, like @media (max-width: 550 px) { body { background-color: white; } } turns the background white on small screens.
  - oefrha 7y ago
    gp is likely asking about how servers decide to redirect to the m.* version instead of the desktop version (or in some cases serve a different mobile version under the same domain), in which case, yes, it’s usually user agent sniffing.
- niea_11 7y ago
  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_Queries/Using_media_queries https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queri...
  - logfromblammo 7y ago
    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.
gregoriol 7y ago
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.
- deleted 7y ago
  [deleted]
- tenebrisalietum 7y ago
  Give an example.
- keyme 7y ago
  This last year I've been noticing things breaking on the Internet for me here and there. I'm a Firefox user. This really wasn't the case in most of the past decade. This kinda reminded me of the late 00's. It was quite common that the odd government or enterprise website was IE6 only. All hail the new IE6.
  - 3pt14159 7y ago
    I use Safari with no plugins. Even Disney World has a broken website for buying tickets for me. The web is breaking because it's gotten way too complex and the fight against trackers is leading to random failures of things that used to work.
    - DC-3 7y ago
      The web is breaking because we are reaching the point where developers are able to assume WebKit/Blink and get away with it. It is imperative that technical folk adopt Firefox to hold back the tide.
      - snazz 7y ago
        Safari is WebKit. The trouble probably isn't the engine, it's ITP messing with some analytics thing.
    - 7y ago
floatingatoll 7y ago
This was recently discussed on HN: 3 months ago: https://news.ycombinator.com/item?id=21781019 https://news.ycombinator.com/item?id=21781019 1 year ago: https://news.ycombinator.com/item?id=18564540 https://news.ycombinator.com/item?id=18564540
ravenstine 7y ago
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 browser and even the OS only encourages differences between browsers. Adding differences to your browser engine shouldn't be considered safe. Beyond that, the user agent is often a lie to trick servers into not discriminating against certain browsers or OSes. Enough variability is added to the user-agent string that a server can't reliably discriminate, but it still remains useful for some purposes in JavaScript and as a fingerprint for tracking. Which brings me to privacy. It's not as if there aren't other ways to try and fingerprint a browser, but the user agent is a big mistake for privacy. It'd be one thing if the user-agent just said "Safari" or "Firefox", but there's a lot more information in it beyond that. If the web should be the same web everywhere, then the privacy trade-off doesn't make much sense.
- ldoughty 7y ago
  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
  - _bxg1 7y ago
    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.
olsonjeffery 7y ago
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.
- jt2190 7y ago
  The proposed User Agent Client Hints API would replace this: https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/
  - anthonyrstevens 7y ago
    The User Agent Client Hints API looks like a very early draft. I could not see any proposed timeline for implementation or estimate of when this might become a supported standard. I would not personally rely on this as a substitute or replacement for User Agent by September (Google Chrome 85).
  - chrisfinazzo 7y ago
    Going way back to the original iPhone Web Apps session at WWDC in 2007, they specifically cautioned about the problem of sniffing UA strings. Of course, the reality of the web meant they had to do a bunch of compatibility hacks to get pages to display well. (Gecko appeared in the original Safari on iPhone UA, IIRC)
- anthonyrstevens 7y ago
  We are in the same boat. Certain browser/OS combinations don't handle Same-Site correctly, so we are using UA sniffing to work around their limitations by altering Same-Site cookie directives for those browsers. We will likely have to look at some other mechanism for dealing with nonconforming Same-Site behavior.
jorams 7y ago
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.
- jaywalk 7y ago
  I'm sure Google won't build in some proprietary way for them to identify Chrome. /s
  - true_religion 7y ago
    I mean they already did. The goal is to replace user agent parsing with a simple field that says exactly what browser and version this is.
    - ric2b 7y ago
      You mean like a user-agent string? Gee, I wonder how this is going to end: https://webaim.org/blog/user-agent-string-history/ https://webaim.org/blog/user-agent-string-history/
- eh78ssxv2f 7y ago
  Google is probably so big that we might as well consider Chrome and rest of the Google as separate entities.
  - blitmap 7y ago
    I hear what you're saying, but they pay people enough to follow a potential company-wide policy: Don't f-ck with user agents!
    - daveFNbuck 7y ago
derefr 7y ago
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 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.)
- jaywalk 7y ago
  Preventing scraping is an entirely futile effort. I've lost count of the number of times I've had to tell a project manager that if a user can see it in their browser, there is a way to scrape it. Best I've ever been able to do is implement server-side throttling to force the scrapers to slow down. But I manage some public web applications with data that is very valuable to certain other players in the industry, so they will invest the time and effort to bypass any measures I throw at them.
  - pocket_cheese 7y ago
    As a person who scrapes sites (ethically), I think it's impossible or pretty damn near impossible to prevent a motivated actor from scraping your website. However, I've avoided scraping websites because their anti scraping measures made it not worth the effort of figuring out their site. I think it's still worth for do minimal things like minify/obfuscate your client side JS and use some type of one time use request token to restrict replay-ability. The difference between knowing that I can figure it in 30 minutes vs 4 hours vs a few days is going to filter out a lot of people. Of course, sometimes obfuscating how your website works can make it needlessly more complicated, so it's a trade off.
- cirno 7y ago
  Checking the user-agent string for scrapers doesn't work anyway. In addition to using dozens of proxies in different IP address blocks, archive.is spoofs its user agents to be the latest Chrome release and updates it often.
eric_b 7y ago
This feels very ivory tower. It reminds me of the "You should never need to check user agent in JavaScript because you should just feature detect!!". Well in the real world that doesn't work every time. The same is true for server side applications of user-agent. There are plenty of non-privacy-invading reasons to need an accurate picture of what user agent is visiting. And a lot of those applications that need it are legacy. Updating them to support these 6 new headers will be a pain.
- recursive 7y ago
  Most of the time when people use user agent for a purpose they think is appropriate, it doesn't even work correctly. YMMV
- jacobr1 7y ago
  Chrome will support the legacy apps by maintaining a static-user agent. It just won't be updated when chrome updates. If you want to build NEW functionality that where you need to test support for new browsers, you do that via feature detection.
  - deleted 7y ago
    [deleted]
vxNsr 7y ago
> https://github.com/WICG/ua-client-hints https://github.com/WICG/ua-client-hints I don't really understand how this will result in any real difference in privacy or homogeneity of the web. Realistically every browser that implements this is gonna offer up all the info the server asks for because asking the user each time is terrible UX. Additionally this will allow google to further segment out any browser that doesn't implement this because they'll ask for it, get `null` back and respond with sorry we don't support your browser, only now you can't just change your UAS and keep going, now you actually need to change your browser. And if other browsers do decide to implement it, they'll just lie and claim to be chrome to make sure sites give the best exp... so we're back to where we started.
- untog 7y ago
  > I don't really understand how this will result in any real difference in privacy or homogeneity of the web. It does a little: sites don't passively receive this information all the time, instead they have to actively ask for it. And browsers can say no, much like they can with blocking third party cookies. In any case I'm not sure privacy is the ultimate goal here: it's intended to replace the awful user agent sniffing people currently have to do with a sensible system where you query for what you actually want, rather than infer it from what's available.
  - uk_programmer 7y ago
    The problem is that without User Agent sniffing in some circumstances there is no other way of working round a browser bug e.g. There are cases where browsers will report that it supports such feature using one of the feature checks but the implementation is garbage. The only way is to have a work around based on user-agent sniffing. Sure a lot of developers abuse the feature but I fear this might create another set of problems.
    - adrianN 7y ago
      The other way is not using that feature until all browsers you care about implement it correctly.
baggy_trough 7y ago
Annoying, as I just added a user agent based workaround for another Chrome compatibility problem (the increased security on same-site cookies, which can't be handled in a compatible way with all browsers).
superkuh 7y ago
User-agent is super useful to human people. But corporate people don't have a use for it. They will get that information via running arbitrary code on your insecure browser anyway. So, because mega-corps now define the web (instead of the w3c) this is life. But it doesn't have to be. We don't have to follow Google/Apple-Web standards. Anyone that makes and runs websites has a choice. And every person can simply choice not to run unethical browsers.
- zzo38computer 7y ago
  Unfortunately they are either unethical or have other problems (or most commonly, both); I have made suggestions how to make a better one. See other comment elsewhere they explain
- DevKoala 7y ago
  Not sure why you are being downvoted since your statements are correct. Few advertisers rely on user agent for ad targeting since it can be easily mocked with each HTTP request. It is used for fingerprinting, sure, but from my experience, mostly as a way to identify bot traffic. It is also true that the advertisers that fingerprint people rely on JS that executes WebGL code in order to get data from the machine. Finally, you are right that it doesn't make sense that a company like Google dictates these standards since they have a conflict of interests worth almost a trillion dollars.
- recursive 7y ago
  > User-agent is super useful to human people. For what? Honest question. You have to be like a 5th-level user agent wizard to make any sense of user agent strings, since every browser now names every other browser. How do you do anything useful with this in a way that's forward-compatible?
  - superkuh 7y ago
    I look at the logs of my websites with my eyeballs manually after a perl script to winnow them down (ie, remove hits form me, hits from tor, etc).
ErikAugust 7y ago
Larry Page no longer wants to be a “good net citizen”? https://groups.google.com/forum/m/#!msg/comp.lang.java/aSPAJO05LIU/ushhUIQQ-ogJ https://groups.google.com/forum/m/#!msg/comp.lang.java/aSPAJ...
manigandham 7y ago
I would much prefer a new version of the user-agent string. Normalize basic information (like OS and browser versions) without revealing too much (build numbers). That would let servers still get necessary info without having to run even more javascript. It can just be in querystring format to simply parsing on both client and server.
- recursive 7y ago
  Any user agent string will eventually be forced down the same path. Web sites use them to deny content. And the browsers will continue to try to match more patterns so their users see the content. As long as they exist, I can see no escaping this arms race.
intsunny 7y ago
Ah, the end of the countless references to KHTML :) As a long time KDE user I'm a little sad, but also fully aware this day would come.
- marcosdumay 7y ago
  How can we use a browser that doesn't pretend to be Netscape Navigator? This will never work :)
leeoniya 7y ago
does this mean there will no longer be a way of determining if the device is primarily touch (basically all of "android", "iphone" and "ipad") or guesstimating screen size ("mobile" is typical for phones in the UA) on the server? https://developer.chrome.com/multidevice/user-agent https://developer.chrome.com/multidevice/user-agent i wonder what Amazon will do. they serve completely different sites from the same domain after UA-sniffing for mobile. is the web just going to turn into blank landing pages that require JS to detect the screen size and/or touch support and then redirect accordingly? or is every initial/landing page going to be bloated with both the mobile and desktop variants? that sounds god-awful.
- bdcravens 7y ago
  Presumably you'll grab the dimensions (could cache after first load) and then render dynamically based on that. If you're doing some sort of if statement on the server to deliver content based on screen size you're probably doing it wrong. Obviously I can't speak for every mobile user, but for myself, it's infuriating to have a completely different set of functionality on mobile.
  - leeoniya 7y ago
    > If you're doing some sort of if statement on the server to deliver content based on screen size you're probably doing it wrong. Obviously I can't speak for every mobile user, but for myself, it's infuriating to have a completely different set of functionality on mobile. there's not a "right" and a "wrong" here; it's about trade-offs. you're either stripping things down to the lowest common denominator (and leaving nothing but empty space on desktop) or you're wasting a ton of mobile bandwidth by serving both versions on initial load (the most critical first impression). you frequently cannot simply squeeze all desktop functionality from a 1920px+ screen onto a 320px screen - unless you have very little functionality to begin with. Amazon (or any e-commerce/marketplace site) is a great example where client-side responsiveness alone is far from sufficient. https://www.walmart.com/ https://www.walmart.com/ does it okay, but you can see how much their desktop site strips down to use the same codebase for desktop and mobile.
- 7y ago
fpoling 7y ago
This change does not remove the user agent. In practice it just hides OS and the version but the user may opt-in to send those to a particular site.
Roboprog 7y ago
I log this for coarse statistics about what our user base is running, but that is about it. The good news: IE use is down over the last year to only about 40%. The bad news: the growth elsewhere is all Chrome, with less than 1% Firefox or Safari. There’s a tiny sprinkling of Edge, as well, but I forget the numbers on that. Our users are state and county offices and medical facilities, rather than private individuals, so the users are somewhat captive to whatever their organization mandates. The only browser detection we do is in client side scripting to detect if the browser can directly display a PDF inline (or not, in the case of IE11)
hartator 7y ago
New proposed syntax adds even more noise: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.1.2222.33 Safari/537.36 Sec-CH-UA: "Chrome"; v="74" Sec-CH-UA-Full-Version: "74.0.3424.124" Sec-CH-UA-Platform: "macOS" Sec-CH-UA-Arch: "ARM64" Why not getting rid of the `User-Agent` completely? It's already bad infrastructure design to have the server do different renderings depending on `User-Agent` value.
- afandian 7y ago
  It's great design if you're trying to push Google products.
- magicalhippo 7y ago
  Why the hell does a regular website need to know what OS and CPU architecture I got?
  - dirtydroog 7y ago
    Visitor metrics -> audience segmentation / fingerprinting -> advertisers
  - kabacha 7y ago
    I can already see the permission pop ups for those: > for best performance this website would like to know what type of device you are using? While requesting every single "hint" and there is "ok" button and greyed out "read more or declide this request" tiny line.
  - crazygringo 7y ago
    The browser isn't for "regular" websites, it's for all websites. And believe it or not, there are crazy JavaScript bugs that are OS-dependent. I remember when I was writing a library around the audio API, and the ways it behaved on Chrome were different across Macs, Windows and Android. Detecting the OS with the user-agent string was literally the only way to build code that would work. Now I've never personally come across that for the CPU architecture, but I certainly wouldn't be surprised if there were behavioral differences between 32-bit and 64-bit processors somewhere that affects some JavaScript function or HTML5 call somewhere.
deleted 7y ago
[deleted]
varelaz 7y ago
So Google found good way to fingerprint users without user agent and found that a lot of user agents are forged and this stopped working anyway. It's time to switch to API support forging.
StillBored 7y ago
Can't happen soon enough. As a frequent user of various non-mainstream browsers i'm sick and tired of seeing "your browser isn't supported" messages with download links to chrome/etc. At least in the case of Falkon it has a built in user agent manager, and I can't remember the last time flipping the UA to firefox/whatever actually caused any problems. Although, i've also gotten annoyed at the sanctimoniousness web sites that tell me my browser is to old because the FF version I've got the UA set to isn't the latest.
- y_nk 7y ago
  if your browser isn't supported, it's not the browser's fault, rather the website you go on not to support your browser.
surround 7y ago
Good. User-agent strings are a mess. Here is an example of a user-agent string. Can you tell what browser this is? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13 How did they get so confusing? See: History of the browser user-agent string https://webaim.org/blog/user-agent-string-history/ https://webaim.org/blog/user-agent-string-history/ Also, last year, Vivaldi switched to using a user-agent string identical to Chrome’s because websites refused to work for Vivaldi, but worked fine with a spoofed user-agent string. https://vivaldi.com/blog/user-agent-changes/ https://vivaldi.com/blog/user-agent-changes/
- rplnt 7y ago
  If companies like Google wouldn't abuse the user agent string to block functionality, serve ads, force their users to specific browser then companies like Google wouldn't have to use fake UA strings and then maybe companies like Google wouldn't have to drop their support.
  - Craighead 7y ago
    You should read the link to know the history of why what you said is wrong.
- dirtydroog 7y ago
  Anything to do with HTTP is a mess!
- jsjddbbwj 7y ago
  Chrome 0.2 on Windows XP?
  - collinmanderson 7y ago
    As a web developer, I have very little trouble reading the User-Agent header. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.1.2222.33 Safari/537.36 Sec-CH-UA: "Chrome"; v="74" Sec-CH-UA-Full-Version: "74.0.3424.124" Sec-CH-UA-Platform: "macOS" Sec-CH-UA-Arch: "ARM64" Sec-CH-Mobile: ?0 Isn't moving this information to a separate Sec-CH-UA headers going to make things _more_ messy? Especially if it's in _addition_ to the frozen User-Agent header? Aren't we still going to have the issue with needing to fake even the new Sec-CH-UA header? If we're going to freeze the User-Agent header, that's fine, but don't just move the unfrozen info to a separate header. Now you have 2 problems. Aren't we just making the problem worse?
stirner 7y ago
Meanwhile, you can still use youtube.com/tv to control playback on your PC from your phone—but only if you spoof your User-Agent to that of the Nintendo Switch [1]. Sounds like they are more interested in phasing out user control than ignoring the header entirely. [1] https://support.google.com/youtube/thread/16442768?hl=en&msgid=16717689 https://support.google.com/youtube/thread/16442768?hl=en&msg...
- ahmedalsudani 7y ago
  Oh wow. I used that in the past and it worked great. I didn’t realize Google broke it only to force us to use their app. What a bunch of turds. Thank you for the Nintendo Switch pro-tip.
  - nofunsir 7y ago
    Yes. I firmly believe this is an attack on user control. For example, I believe they REALLY want us to use the youtube app: - Viewing youtube.com on a new iPad pro, Goolag lies and says "your browser doesn't support 1080p." - Ok, change to desktop version in app. Goolag once again lies and says "your browser doesn't support full screen." They also lie and say they've redirected you to the "desktop version", and nag you with a persistent banner that you should return to the safety of the mobile website. - Ok, change to "request desktop version" via user agent. Full functionality. Full screen is DEFINITELY possible with a javascript bookmark. 1080p+ is DEFINITELY possible. Ads blocked in browser. If I were to use the app, they would have FULL CONTROL.
    - true_religion 7y ago
      Are you deliberately misspelling Google as Goolag to make it sound like gulag?
DevKoala 7y ago
From the git repo: > Blocking known bots and crawlers Currently, the User-Agent string is often used as a brute-force way to block known bots and crawlers. There's a concern that moving "normal" traffic to expose less entropy by default will also make it easier for bots to hide in the crowd. While there's some truth to that, that's not enough reason for making the crowd be more personally identifiable. This means that consumers of the Google Ad stream have one less tool to identify bots, and will pay Google for more synthetic traffic, impressions and clicks; this could be a huge revenue boost for Google. A considerable amount of their traffic is synthetic. I doubt this was overlooked.
smashah 7y ago
Stupidity. user-agent spoofing is a fact of life for many projects. Whatever feature they're going to come out with to replace UA will be spoofable too soon enough.
gumby 7y ago
This is OK...I guess? I mean it's great to get rid of that overloaded carbuncle of user-agent, but that will just lead to a new round of interpreting "hints". shrug Google is a serial abuser of user-agent already so this is somewhat ironic.
mcs_ 7y ago
sorry, anyone knows the link of the original source of this?
bunchOfCucks 7y ago
Geeks on a power trip. Never was a good idea seen
yu_chen 7y ago
ahhh
CKN23-ARIN 7y ago
> While removing the User-Agent completely was deemed problematic, as many sites still rely on them, Chrome will no longer update the browser version and will only include a unified version of the OS data. So, nearly all of the information that makes User-Agent strings problematic will remain. They're just phasing out precise version information.
Humphrey 7y ago
Interesting. We don't use UA to track customers, but it has been invaluable information for trying specific bugs. Eg, twice in the past 2 months, I've had to fix weird bugs that didn't make sense. The only way I was able to solve them was to look for patterns in which browsers and versions those who reported the bugs were using. Both turned out to be to do different iOS Safari cookie related bugs that only occurred in specific versions. Without logging the UA there would have been no way I would have been able to discover those bugs and create workarounds for those iphone users. I'm all for preventing tracking, but I can't imagine a time where all browsers behavior so similarly that we won't have to write workarounds for browser bugs and differences. As a developer I can't imagine caring about Edgium vs Chrome, but it's important to know what the underlying engines are.
dheera 7y ago
No! I loved User-Agent because I could fake other user agents, e.g. - being the google crawler to get past paywalls - being a Mac user agent to get free internet access at some hotels
badrabbit 7y ago
This is insane. You know, no HN post to a google blogspot site works for me because these jerks are the only ones that discrinate on UA? Google engoneering is Sooooooo disconnected from the rest of the world, I think we need legal regulation to stop them from doing stuipd things like this. Do they have any idea how many things need it? HNers with a position of power at work, I plead with you: please advocate banning of Chrome at work and replacing it with any one of the webkit based alternatives or firefox. These people are insane. Every month I hear of some ridiculous thing. They took out navbar url parameters, add links to in page words, now this! For those who think this is good for privacy...it is not! This is the same old sneaky ass evil thing they do. UA can be used to finger print you but it's very easy to set a generic user agent. Actually, if you look at user agents most of them have the latest string for Chrome, IE or firefox so it isn't useful without a whole lot of other details correlated with it. You know what the exception is? Android and iPhone browsers that incluse your device make and model in the UA and apps that includes whole lot more like facebook's apps. Do you know what a "flexible" api like the one they're talking about allows? More fingerprintable data points! The fact that you even use that api is a privacy issue. Let's sat clienthints allows for 10 different variations of responses from clients,your specific client details might have just 3 things different from the mean and bam, now they can track your specific device. With UA,all versions of a client have the same exact detail and most people need an extension to change it, so it makes it much less easy to finger print. This is the same ol sneaky bait and switch Google pulls. The content of your UA is not the privacy concern (although it contains too much at times) , it is the fact that it can be correlated with timing info,IP (especially v6),and if they already know your UA they will also use client default http header options to identify and track you without consent.
nofunsir 7y ago
I view this as an attack on the web as it stands. Google wants to create a walled-garden net. Goog-net. All ads, shopping, videos, documents, email, locations, articles flowing through THEIR protocols and THEIR servers and THEIR fiber. No possibility of blocking ads they don't want blocked. No URLs. No Agent strings. No user control. Only user consumption. If they have to allow some small chump players to have a piece of this cake (a la: "Oh trust us, AMP is an 'open' protocol and anyone can host it. it's not just for our own benefit in the end. Trust us.") in order for the entire population to accept their changes bit by bit, so be it in their eyes. They know we would reject an outright takeover.
KingOfCoders 7y ago
Any idea on how to identify devices then? We currently check the user agent to to send a new code when an user logs in from a new device. How would you do this without user agent?
- SifJar 7y ago
  Use a cookie?
2400 7y ago
if you want to go to the source of that story: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/-2JIRNMWJ7s/yHe4tQNLCgAJ https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...
jakeogh 7y ago
Fantastic. Thank you Chrome team! Especially for those who dont execute arb JS, this is a huge +. Personally, I would like to drop the line completely and not send the key at all, but it's a start.
- maverick74 7y ago
  totally agree!!!
guyn 7y ago
The first time one of my articles appear in HN, I'm kinda excited
classified 7y ago
So basically, Google shat their own bed and is just now beginning to realize that it stinks. Attempts to invent the universal internet user toll booth are back on track.
maverick74 7y ago
Finally someone step up to stop the UA madness!!! Now, all we'll need is a way to not send anything at all!!!
y_nk 7y ago
isn't it concerning that Google decides to follow and implement even though the conversation on github concluded by "it should be rejected by W3C"?
justlexi93 7y ago
More specifically, Google thinks they're the central authority as to what Chrome will do.

672 points by oftenwrong 7y ago

zmix 7y ago

Because, there can be only one user agent...!

PaulHoule 7y ago

If they're the dominant web browser people will assume you are using Chrome anyway.

abhishekjha 7y ago

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

untog 7y ago
Not usually, no. CSS media queries are used to format according to display size. But as a sibling here has indicated, client hints will replace the user agent here.
deleted 7y ago
[deleted]
fny 7y ago
There not phasing out User-Agent strings entirely, they're actually upgrading them: https://github.com/WICG/ua-client-hints https://github.com/WICG/ua-client-hints It looks like there's more fine grained control in the new version.
- timw4mail 7y ago
  Javascript-only is not an upgrade.
  - snazz 7y ago
    UA strings have never been an accurate indication. If you're not using JS, then you probably have no reason to be sniffing the UA string to detect browser features, since most of those features are JS-related anyway. It's an upgrade for the people who actually need to get an indication of the supported features and APIs of the user's browser. Otherwise, you should be using media queries.
    - oefrha 7y ago
      One exception: you might want to user sniff IE and serve a completely different version due to all the CSS problems. (I know you can use IE-only comments too, but I’ve been in the situation where making a modern version simultaneously IE9-compatible was just too frigging maddening.)
      - Izkata 7y ago
        A bigger, site-breaking one from further up in this thread: https://news.ycombinator.com/item?id=22685632 https://news.ycombinator.com/item?id=22685632
    - Avamander 7y ago
      Detecting dumb search crawlers, that don't support major features required for my webapp, and displaying a fallback splash has been the only reasonable way I've found.
tenebrisalietum 7y ago
I thought it used Javascript to detect screen size. At least it should react to resize events and if the dimensions are something that align with mobile, it should switch to mobile mode.
- NilsIRL 7y ago
  AFAIK it's also done using CSS
- wlesieutre 7y ago
  In a lot of cases you shouldn't even use Javascript for this, responsive layouts can be built using CSS media queries based on viewport size. More advanced webapps might occasionally need to do something fancier than that if the mobile vs desktop functionality is (for some reason) substantially different instead of just rearranged. https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queri...
kryptiskt 7y ago
The typical way this is done these days is by media queries in CSS, so you'd write a rule for styling based on screen width, like @media (max-width: 550 px) { body { background-color: white; } } turns the background white on small screens.
- oefrha 7y ago
  gp is likely asking about how servers decide to redirect to the m.* version instead of the desktop version (or in some cases serve a different mobile version under the same domain), in which case, yes, it’s usually user agent sniffing.
niea_11 7y ago
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_Queries/Using_media_queries https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queri...
- logfromblammo 7y ago
  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.

gregoriol 7y ago

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.

deleted 7y ago
[deleted]
tenebrisalietum 7y ago
Give an example.
keyme 7y ago
This last year I've been noticing things breaking on the Internet for me here and there. I'm a Firefox user. This really wasn't the case in most of the past decade. This kinda reminded me of the late 00's. It was quite common that the odd government or enterprise website was IE6 only. All hail the new IE6.
- 3pt14159 7y ago
  I use Safari with no plugins. Even Disney World has a broken website for buying tickets for me. The web is breaking because it's gotten way too complex and the fight against trackers is leading to random failures of things that used to work.
  - DC-3 7y ago
    The web is breaking because we are reaching the point where developers are able to assume WebKit/Blink and get away with it. It is imperative that technical folk adopt Firefox to hold back the tide.
    - snazz 7y ago
      Safari is WebKit. The trouble probably isn't the engine, it's ITP messing with some analytics thing.
  - 7y ago

floatingatoll 7y ago

This was recently discussed on HN: 3 months ago: https://news.ycombinator.com/item?id=21781019 https://news.ycombinator.com/item?id=21781019 1 year ago: https://news.ycombinator.com/item?id=18564540 https://news.ycombinator.com/item?id=18564540

ravenstine 7y ago

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 browser and even the OS only encourages differences between browsers. Adding differences to your browser engine shouldn't be considered safe. Beyond that, the user agent is often a lie to trick servers into not discriminating against certain browsers or OSes. Enough variability is added to the user-agent string that a server can't reliably discriminate, but it still remains useful for some purposes in JavaScript and as a fingerprint for tracking. Which brings me to privacy. It's not as if there aren't other ways to try and fingerprint a browser, but the user agent is a big mistake for privacy. It'd be one thing if the user-agent just said "Safari" or "Firefox", but there's a lot more information in it beyond that. If the web should be the same web everywhere, then the privacy trade-off doesn't make much sense.

ldoughty 7y ago
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
- _bxg1 7y ago
  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.

olsonjeffery 7y ago

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.

jt2190 7y ago
The proposed User Agent Client Hints API would replace this: https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/
- anthonyrstevens 7y ago
  The User Agent Client Hints API looks like a very early draft. I could not see any proposed timeline for implementation or estimate of when this might become a supported standard. I would not personally rely on this as a substitute or replacement for User Agent by September (Google Chrome 85).
- chrisfinazzo 7y ago
  Going way back to the original iPhone Web Apps session at WWDC in 2007, they specifically cautioned about the problem of sniffing UA strings. Of course, the reality of the web meant they had to do a bunch of compatibility hacks to get pages to display well. (Gecko appeared in the original Safari on iPhone UA, IIRC)
anthonyrstevens 7y ago
We are in the same boat. Certain browser/OS combinations don't handle Same-Site correctly, so we are using UA sniffing to work around their limitations by altering Same-Site cookie directives for those browsers. We will likely have to look at some other mechanism for dealing with nonconforming Same-Site behavior.

jorams 7y ago

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.

jaywalk 7y ago
I'm sure Google won't build in some proprietary way for them to identify Chrome. /s
- true_religion 7y ago
  I mean they already did. The goal is to replace user agent parsing with a simple field that says exactly what browser and version this is.
  - ric2b 7y ago
    You mean like a user-agent string? Gee, I wonder how this is going to end: https://webaim.org/blog/user-agent-string-history/ https://webaim.org/blog/user-agent-string-history/
eh78ssxv2f 7y ago
Google is probably so big that we might as well consider Chrome and rest of the Google as separate entities.
- blitmap 7y ago
  I hear what you're saying, but they pay people enough to follow a potential company-wide policy: Don't f-ck with user agents!
  - daveFNbuck 7y ago

derefr 7y ago

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 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.)

jaywalk 7y ago
Preventing scraping is an entirely futile effort. I've lost count of the number of times I've had to tell a project manager that if a user can see it in their browser, there is a way to scrape it. Best I've ever been able to do is implement server-side throttling to force the scrapers to slow down. But I manage some public web applications with data that is very valuable to certain other players in the industry, so they will invest the time and effort to bypass any measures I throw at them.
- pocket_cheese 7y ago
  As a person who scrapes sites (ethically), I think it's impossible or pretty damn near impossible to prevent a motivated actor from scraping your website. However, I've avoided scraping websites because their anti scraping measures made it not worth the effort of figuring out their site. I think it's still worth for do minimal things like minify/obfuscate your client side JS and use some type of one time use request token to restrict replay-ability. The difference between knowing that I can figure it in 30 minutes vs 4 hours vs a few days is going to filter out a lot of people. Of course, sometimes obfuscating how your website works can make it needlessly more complicated, so it's a trade off.
cirno 7y ago
Checking the user-agent string for scrapers doesn't work anyway. In addition to using dozens of proxies in different IP address blocks, archive.is spoofs its user agents to be the latest Chrome release and updates it often.

eric_b 7y ago

This feels very ivory tower. It reminds me of the "You should never need to check user agent in JavaScript because you should just feature detect!!". Well in the real world that doesn't work every time. The same is true for server side applications of user-agent. There are plenty of non-privacy-invading reasons to need an accurate picture of what user agent is visiting. And a lot of those applications that need it are legacy. Updating them to support these 6 new headers will be a pain.

recursive 7y ago
Most of the time when people use user agent for a purpose they think is appropriate, it doesn't even work correctly. YMMV
jacobr1 7y ago
Chrome will support the legacy apps by maintaining a static-user agent. It just won't be updated when chrome updates. If you want to build NEW functionality that where you need to test support for new browsers, you do that via feature detection.
- deleted 7y ago
  [deleted]

vxNsr 7y ago

> https://github.com/WICG/ua-client-hints https://github.com/WICG/ua-client-hints I don't really understand how this will result in any real difference in privacy or homogeneity of the web. Realistically every browser that implements this is gonna offer up all the info the server asks for because asking the user each time is terrible UX. Additionally this will allow google to further segment out any browser that doesn't implement this because they'll ask for it, get `null` back and respond with sorry we don't support your browser, only now you can't just change your UAS and keep going, now you actually need to change your browser. And if other browsers do decide to implement it, they'll just lie and claim to be chrome to make sure sites give the best exp... so we're back to where we started.

untog 7y ago
> I don't really understand how this will result in any real difference in privacy or homogeneity of the web. It does a little: sites don't passively receive this information all the time, instead they have to actively ask for it. And browsers can say no, much like they can with blocking third party cookies. In any case I'm not sure privacy is the ultimate goal here: it's intended to replace the awful user agent sniffing people currently have to do with a sensible system where you query for what you actually want, rather than infer it from what's available.
- uk_programmer 7y ago
  The problem is that without User Agent sniffing in some circumstances there is no other way of working round a browser bug e.g. There are cases where browsers will report that it supports such feature using one of the feature checks but the implementation is garbage. The only way is to have a work around based on user-agent sniffing. Sure a lot of developers abuse the feature but I fear this might create another set of problems.
  - adrianN 7y ago
    The other way is not using that feature until all browsers you care about implement it correctly.

baggy_trough 7y ago

Annoying, as I just added a user agent based workaround for another Chrome compatibility problem (the increased security on same-site cookies, which can't be handled in a compatible way with all browsers).

superkuh 7y ago

User-agent is super useful to human people. But corporate people don't have a use for it. They will get that information via running arbitrary code on your insecure browser anyway. So, because mega-corps now define the web (instead of the w3c) this is life. But it doesn't have to be. We don't have to follow Google/Apple-Web standards. Anyone that makes and runs websites has a choice. And every person can simply choice not to run unethical browsers.

zzo38computer 7y ago
Unfortunately they are either unethical or have other problems (or most commonly, both); I have made suggestions how to make a better one. See other comment elsewhere they explain
DevKoala 7y ago
Not sure why you are being downvoted since your statements are correct. Few advertisers rely on user agent for ad targeting since it can be easily mocked with each HTTP request. It is used for fingerprinting, sure, but from my experience, mostly as a way to identify bot traffic. It is also true that the advertisers that fingerprint people rely on JS that executes WebGL code in order to get data from the machine. Finally, you are right that it doesn't make sense that a company like Google dictates these standards since they have a conflict of interests worth almost a trillion dollars.
recursive 7y ago
> User-agent is super useful to human people. For what? Honest question. You have to be like a 5th-level user agent wizard to make any sense of user agent strings, since every browser now names every other browser. How do you do anything useful with this in a way that's forward-compatible?
- superkuh 7y ago
  I look at the logs of my websites with my eyeballs manually after a perl script to winnow them down (ie, remove hits form me, hits from tor, etc).

ErikAugust 7y ago

Larry Page no longer wants to be a “good net citizen”? https://groups.google.com/forum/m/#!msg/comp.lang.java/aSPAJO05LIU/ushhUIQQ-ogJ https://groups.google.com/forum/m/#!msg/comp.lang.java/aSPAJ...

manigandham 7y ago

I would much prefer a new version of the user-agent string. Normalize basic information (like OS and browser versions) without revealing too much (build numbers). That would let servers still get necessary info without having to run even more javascript. It can just be in querystring format to simply parsing on both client and server.

recursive 7y ago
Any user agent string will eventually be forced down the same path. Web sites use them to deny content. And the browsers will continue to try to match more patterns so their users see the content. As long as they exist, I can see no escaping this arms race.

intsunny 7y ago

Ah, the end of the countless references to KHTML :) As a long time KDE user I'm a little sad, but also fully aware this day would come.

marcosdumay 7y ago
How can we use a browser that doesn't pretend to be Netscape Navigator? This will never work :)

leeoniya 7y ago

does this mean there will no longer be a way of determining if the device is primarily touch (basically all of "android", "iphone" and "ipad") or guesstimating screen size ("mobile" is typical for phones in the UA) on the server? https://developer.chrome.com/multidevice/user-agent https://developer.chrome.com/multidevice/user-agent i wonder what Amazon will do. they serve completely different sites from the same domain after UA-sniffing for mobile. is the web just going to turn into blank landing pages that require JS to detect the screen size and/or touch support and then redirect accordingly? or is every initial/landing page going to be bloated with both the mobile and desktop variants? that sounds god-awful.

bdcravens 7y ago
Presumably you'll grab the dimensions (could cache after first load) and then render dynamically based on that. If you're doing some sort of if statement on the server to deliver content based on screen size you're probably doing it wrong. Obviously I can't speak for every mobile user, but for myself, it's infuriating to have a completely different set of functionality on mobile.
- leeoniya 7y ago
  > If you're doing some sort of if statement on the server to deliver content based on screen size you're probably doing it wrong. Obviously I can't speak for every mobile user, but for myself, it's infuriating to have a completely different set of functionality on mobile. there's not a "right" and a "wrong" here; it's about trade-offs. you're either stripping things down to the lowest common denominator (and leaving nothing but empty space on desktop) or you're wasting a ton of mobile bandwidth by serving both versions on initial load (the most critical first impression). you frequently cannot simply squeeze all desktop functionality from a 1920px+ screen onto a 320px screen - unless you have very little functionality to begin with. Amazon (or any e-commerce/marketplace site) is a great example where client-side responsiveness alone is far from sufficient. https://www.walmart.com/ https://www.walmart.com/ does it okay, but you can see how much their desktop site strips down to use the same codebase for desktop and mobile.
7y ago

fpoling 7y ago

This change does not remove the user agent. In practice it just hides OS and the version but the user may opt-in to send those to a particular site.

Roboprog 7y ago

I log this for coarse statistics about what our user base is running, but that is about it. The good news: IE use is down over the last year to only about 40%. The bad news: the growth elsewhere is all Chrome, with less than 1% Firefox or Safari. There’s a tiny sprinkling of Edge, as well, but I forget the numbers on that. Our users are state and county offices and medical facilities, rather than private individuals, so the users are somewhat captive to whatever their organization mandates. The only browser detection we do is in client side scripting to detect if the browser can directly display a PDF inline (or not, in the case of IE11)

hartator 7y ago

New proposed syntax adds even more noise: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.1.2222.33 Safari/537.36 Sec-CH-UA: "Chrome"; v="74" Sec-CH-UA-Full-Version: "74.0.3424.124" Sec-CH-UA-Platform: "macOS" Sec-CH-UA-Arch: "ARM64" Why not getting rid of the `User-Agent` completely? It's already bad infrastructure design to have the server do different renderings depending on `User-Agent` value.

afandian 7y ago
It's great design if you're trying to push Google products.
magicalhippo 7y ago
Why the hell does a regular website need to know what OS and CPU architecture I got?
- dirtydroog 7y ago
  Visitor metrics -> audience segmentation / fingerprinting -> advertisers
- kabacha 7y ago
  I can already see the permission pop ups for those: > for best performance this website would like to know what type of device you are using? While requesting every single "hint" and there is "ok" button and greyed out "read more or declide this request" tiny line.
- crazygringo 7y ago
  The browser isn't for "regular" websites, it's for all websites. And believe it or not, there are crazy JavaScript bugs that are OS-dependent. I remember when I was writing a library around the audio API, and the ways it behaved on Chrome were different across Macs, Windows and Android. Detecting the OS with the user-agent string was literally the only way to build code that would work. Now I've never personally come across that for the CPU architecture, but I certainly wouldn't be surprised if there were behavioral differences between 32-bit and 64-bit processors somewhere that affects some JavaScript function or HTML5 call somewhere.

deleted 7y ago

[deleted]

varelaz 7y ago

So Google found good way to fingerprint users without user agent and found that a lot of user agents are forged and this stopped working anyway. It's time to switch to API support forging.

StillBored 7y ago

Can't happen soon enough. As a frequent user of various non-mainstream browsers i'm sick and tired of seeing "your browser isn't supported" messages with download links to chrome/etc. At least in the case of Falkon it has a built in user agent manager, and I can't remember the last time flipping the UA to firefox/whatever actually caused any problems. Although, i've also gotten annoyed at the sanctimoniousness web sites that tell me my browser is to old because the FF version I've got the UA set to isn't the latest.

y_nk 7y ago
if your browser isn't supported, it's not the browser's fault, rather the website you go on not to support your browser.

surround 7y ago

Good. User-agent strings are a mess. Here is an example of a user-agent string. Can you tell what browser this is? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13 How did they get so confusing? See: History of the browser user-agent string https://webaim.org/blog/user-agent-string-history/ https://webaim.org/blog/user-agent-string-history/ Also, last year, Vivaldi switched to using a user-agent string identical to Chrome’s because websites refused to work for Vivaldi, but worked fine with a spoofed user-agent string. https://vivaldi.com/blog/user-agent-changes/ https://vivaldi.com/blog/user-agent-changes/

rplnt 7y ago
If companies like Google wouldn't abuse the user agent string to block functionality, serve ads, force their users to specific browser then companies like Google wouldn't have to use fake UA strings and then maybe companies like Google wouldn't have to drop their support.
- Craighead 7y ago
  You should read the link to know the history of why what you said is wrong.
dirtydroog 7y ago
Anything to do with HTTP is a mess!
jsjddbbwj 7y ago
Chrome 0.2 on Windows XP?
- collinmanderson 7y ago
  As a web developer, I have very little trouble reading the User-Agent header. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.1.2222.33 Safari/537.36 Sec-CH-UA: "Chrome"; v="74" Sec-CH-UA-Full-Version: "74.0.3424.124" Sec-CH-UA-Platform: "macOS" Sec-CH-UA-Arch: "ARM64" Sec-CH-Mobile: ?0 Isn't moving this information to a separate Sec-CH-UA headers going to make things _more_ messy? Especially if it's in _addition_ to the frozen User-Agent header? Aren't we still going to have the issue with needing to fake even the new Sec-CH-UA header? If we're going to freeze the User-Agent header, that's fine, but don't just move the unfrozen info to a separate header. Now you have 2 problems. Aren't we just making the problem worse?

stirner 7y ago

Meanwhile, you can still use youtube.com/tv to control playback on your PC from your phone—but only if you spoof your User-Agent to that of the Nintendo Switch [1]. Sounds like they are more interested in phasing out user control than ignoring the header entirely. [1] https://support.google.com/youtube/thread/16442768?hl=en&msgid=16717689 https://support.google.com/youtube/thread/16442768?hl=en&msg...

ahmedalsudani 7y ago
Oh wow. I used that in the past and it worked great. I didn’t realize Google broke it only to force us to use their app. What a bunch of turds. Thank you for the Nintendo Switch pro-tip.
- nofunsir 7y ago
  Yes. I firmly believe this is an attack on user control. For example, I believe they REALLY want us to use the youtube app: - Viewing youtube.com on a new iPad pro, Goolag lies and says "your browser doesn't support 1080p." - Ok, change to desktop version in app. Goolag once again lies and says "your browser doesn't support full screen." They also lie and say they've redirected you to the "desktop version", and nag you with a persistent banner that you should return to the safety of the mobile website. - Ok, change to "request desktop version" via user agent. Full functionality. Full screen is DEFINITELY possible with a javascript bookmark. 1080p+ is DEFINITELY possible. Ads blocked in browser. If I were to use the app, they would have FULL CONTROL.
  - true_religion 7y ago
    Are you deliberately misspelling Google as Goolag to make it sound like gulag?

DevKoala 7y ago

From the git repo: > Blocking known bots and crawlers Currently, the User-Agent string is often used as a brute-force way to block known bots and crawlers. There's a concern that moving "normal" traffic to expose less entropy by default will also make it easier for bots to hide in the crowd. While there's some truth to that, that's not enough reason for making the crowd be more personally identifiable. This means that consumers of the Google Ad stream have one less tool to identify bots, and will pay Google for more synthetic traffic, impressions and clicks; this could be a huge revenue boost for Google. A considerable amount of their traffic is synthetic. I doubt this was overlooked.

smashah 7y ago

Stupidity. user-agent spoofing is a fact of life for many projects. Whatever feature they're going to come out with to replace UA will be spoofable too soon enough.

gumby 7y ago

This is OK...I guess? I mean it's great to get rid of that overloaded carbuncle of user-agent, but that will just lead to a new round of interpreting "hints". shrug Google is a serial abuser of user-agent already so this is somewhat ironic.

mcs_ 7y ago

sorry, anyone knows the link of the original source of this?

bunchOfCucks 7y ago

Geeks on a power trip. Never was a good idea seen

yu_chen 7y ago

ahhh

CKN23-ARIN 7y ago

> While removing the User-Agent completely was deemed problematic, as many sites still rely on them, Chrome will no longer update the browser version and will only include a unified version of the OS data. So, nearly all of the information that makes User-Agent strings problematic will remain. They're just phasing out precise version information.

Humphrey 7y ago

Interesting. We don't use UA to track customers, but it has been invaluable information for trying specific bugs. Eg, twice in the past 2 months, I've had to fix weird bugs that didn't make sense. The only way I was able to solve them was to look for patterns in which browsers and versions those who reported the bugs were using. Both turned out to be to do different iOS Safari cookie related bugs that only occurred in specific versions. Without logging the UA there would have been no way I would have been able to discover those bugs and create workarounds for those iphone users. I'm all for preventing tracking, but I can't imagine a time where all browsers behavior so similarly that we won't have to write workarounds for browser bugs and differences. As a developer I can't imagine caring about Edgium vs Chrome, but it's important to know what the underlying engines are.

dheera 7y ago

No! I loved User-Agent because I could fake other user agents, e.g. - being the google crawler to get past paywalls - being a Mac user agent to get free internet access at some hotels

badrabbit 7y ago

This is insane. You know, no HN post to a google blogspot site works for me because these jerks are the only ones that discrinate on UA? Google engoneering is Sooooooo disconnected from the rest of the world, I think we need legal regulation to stop them from doing stuipd things like this. Do they have any idea how many things need it? HNers with a position of power at work, I plead with you: please advocate banning of Chrome at work and replacing it with any one of the webkit based alternatives or firefox. These people are insane. Every month I hear of some ridiculous thing. They took out navbar url parameters, add links to in page words, now this! For those who think this is good for privacy...it is not! This is the same old sneaky ass evil thing they do. UA can be used to finger print you but it's very easy to set a generic user agent. Actually, if you look at user agents most of them have the latest string for Chrome, IE or firefox so it isn't useful without a whole lot of other details correlated with it. You know what the exception is? Android and iPhone browsers that incluse your device make and model in the UA and apps that includes whole lot more like facebook's apps. Do you know what a "flexible" api like the one they're talking about allows? More fingerprintable data points! The fact that you even use that api is a privacy issue. Let's sat clienthints allows for 10 different variations of responses from clients,your specific client details might have just 3 things different from the mean and bam, now they can track your specific device. With UA,all versions of a client have the same exact detail and most people need an extension to change it, so it makes it much less easy to finger print. This is the same ol sneaky bait and switch Google pulls. The content of your UA is not the privacy concern (although it contains too much at times) , it is the fact that it can be correlated with timing info,IP (especially v6),and if they already know your UA they will also use client default http header options to identify and track you without consent.

nofunsir 7y ago

I view this as an attack on the web as it stands. Google wants to create a walled-garden net. Goog-net. All ads, shopping, videos, documents, email, locations, articles flowing through THEIR protocols and THEIR servers and THEIR fiber. No possibility of blocking ads they don't want blocked. No URLs. No Agent strings. No user control. Only user consumption. If they have to allow some small chump players to have a piece of this cake (a la: "Oh trust us, AMP is an 'open' protocol and anyone can host it. it's not just for our own benefit in the end. Trust us.") in order for the entire population to accept their changes bit by bit, so be it in their eyes. They know we would reject an outright takeover.

KingOfCoders 7y ago

Any idea on how to identify devices then? We currently check the user agent to to send a new code when an user logs in from a new device. How would you do this without user agent?

SifJar 7y ago
Use a cookie?

2400 7y ago

if you want to go to the source of that story: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/-2JIRNMWJ7s/yHe4tQNLCgAJ https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...

jakeogh 7y ago

Fantastic. Thank you Chrome team! Especially for those who dont execute arb JS, this is a huge +. Personally, I would like to drop the line completely and not send the key at all, but it's a start.

maverick74 7y ago
totally agree!!!

guyn 7y ago

The first time one of my articles appear in HN, I'm kinda excited

classified 7y ago

So basically, Google shat their own bed and is just now beginning to realize that it stinks. Attempts to invent the universal internet user toll booth are back on track.

maverick74 7y ago

Finally someone step up to stop the UA madness!!! Now, all we'll need is a way to not send anything at all!!!

y_nk 7y ago

isn't it concerning that Google decides to follow and implement even though the conversation on github concluded by "it should be rejected by W3C"?

justlexi93 7y ago

More specifically, Google thinks they're the central authority as to what Chrome will do.