21 ms·

Blink-Dev – Intent to Deprecate and Freeze: The User-Agent string

381 points by jasonvorhe 7y ago

ChrisSD 7y ago
> On top of those privacy issues, User-Agent sniffing is an abundant source of compatibility issues, in particular for minority browsers, resulting in browsers lying about themselves (generally or to specific sites), and sites (including Google properties) being broken in some browsers for no good reason. > The above abuse makes it desirable to freeze the UA string and replace it with a better mechanism. UA sniffing should have died out a long time ago. It's frustrating that it's 2020 and I'm still having my browsing experience broken for no other reason than the site doesn't like my UA.
- DJBunnies 7y ago
  I have some news for you about what year it is.
  - ChrisSD 7y ago
    Thanks, I've edited.
    - cmsd2 7y ago
      i predict this comment will age badly.
- gsich 7y ago
  Don't use $current_year argumentation.
  - interfixus 7y ago
    Don't don't.
  - wruza 7y ago
    It is a subjective version of “too long not fixed”. Like gp remembers this exact problem in 1980/1990/2000 and still there it is. A specific year has nothing to do with it. So come on, it’s 2020 and we still have to explain idioms to each other :)
- sebazzz 7y ago
  User agent sniffing is still sometimes required. Take the SameSite bugs that Safari had. On the server you needed to act on that based on User Agent sniffing.
  - Macha 7y ago
    I also remember a CSS bug Safari 4 or 5 had with tables and touch scrollbars that we had to resort to UA detection for - it's not always possible to feature detect bugs.
  - vdnkh 7y ago
    Agreed. For media streaming UA sniffing is required because of quirks each browser has in decoding media. Safari has a few quirks about the MP4 packaging it likes via MediaSourceExtensions. Firefox's network stack includes a delay not related to the actual request because of its implementation[0] which makes timing of small downloads very inaccurate. None of these differences are discernible except by UA. [1] I believe FF includes in the download length the time a request spends sitting in the request queue, but I can't exactly remember.
    - anoncake 7y ago
      Browsers have those quirks because web designers work around and hide them.
  - xfalcox 7y ago
    > SameSite bugs that Safari had Safari has SameSite bugs and it's infuriating that after years they don't even update the bug reports, let alone fix those. https://bugs.webkit.org/show_bug.cgi?id=200345 https://bugs.webkit.org/show_bug.cgi?id=200345
  - jerf 7y ago
    I think it's distinctly possible that the current status quo may cause an overreaction. Feature detection is good. But we may also need the ability to do specific version checking sometimes. What I think would be best is two things: A feature advertising string (preferably with some versioning in itself), and a new User Agent string that is just that: The user agent. As in, "This is Firefox 72.2.813". Maybe the OS in there too. I think a non-trivial part of the problem with the UA today is "Hey... I'm Firefox. Also, I'm Mozilla. Also, I'm edge 3, and Internet Explorer 6, and today I think I'm also Chrome. Also, I may be a monkey with a banana plugged in to an ethernet cable." Part of the problem is that people abuse the user agent, but part of the problem is that the user agent string is also a pack of outright, outrageous, self-contradictory lies. A truthful field may still have significant utility. One of the things I've learned over the years in software engineering is that you should do you best to make sure that your system doesn't contain lies, or, failing that, treat them like any other issues that you should contain at the edges rather than letting it run riot through your system. For instance, if you decide to let customers have 10GB of bandwidth free before you start charging them, you should never accomplish that goal by tweaking the bandwidth counting system to report 7.5GB of usage as 0GB. That is a lie. Tell the truth about the usage and let the billing system apply the discount, which is itself a truth as well. You always pay for lies in the system in the long run. It is a very common pattern in coding as well where some function author figures out how to assemble the correct lie to some other function to make it do what the author things they want, but in the long run you're better off telling the truth and fixing the code to work with the truth. Otherwise, well, you really do end up with a tangled web of code. Which is... exactly what we've gotten with UA-detection-based code. We won't necessarily get the same mess if there's a new UA that isn't a lie. I'm not claiming this will lead to utopia. Minority forks of popular browsers will fail to pick up the necessary ad-hoc bug fixes this way, for instance. My claim is more like in the long run, the best thing for everybody is just to have a user agent that tells the truth, even if on occasion in the short term you experience occasional problems. (One way to at least partially achieve this is to standardize the new truthful agent string to something like (\w+) ((\d+.)+\d) (\w+), and specify it as "non-conforming true user agent strings MUST be entirely rejected and treated as being absent", so anyone who tries to be Firefox and Chrome and also a monkey ends up being nobody in particular.)
- dTal 7y ago
  Of course, when the User Agent sniffing messes up, you're perfectly free to change it, and see what else you can get the server to send you. Can you still do that with whatever crazy "feature detection" replaces it?
LyndsySimon 7y ago
For context, as it’s not immediately obvious at the link: Blink is Chrome/Chromium’s rendering engine.
- ShinTakuya 7y ago
  Thanks, I assumed so but it's useful to have this confirmation before I looked it up. Honestly this is a little surprising to me. Sites pulling shit like matching UA usually works out in Chrome's favour so it's nice to see them throwing the minor web browsers an olive branch.
  - close04 7y ago
    Developers will still mostly target the most popular browser(s), particularly Chrome. It would be great if browsers like Firefox managed to implement a "feature detection spoof" that you can enable to still present yourself as Chrome (or other browsers) regardless of the actual features requested. More or less like changing the UA does now.
    - GoblinSlayer 7y ago
      That's Go Faster addon.
      - close04 7y ago
        This looks like it's intended to fix specific issues, not for fingerprint blocking. I was thinking more like being able to present yourself as generic Chrome on Windows 10 or Firefox on Android if you chose to, even with the risk of breaking the site.
        GoblinSlayer 7y ago
        Firefox resists fingerprinting by default, and go faster addon provides mitigations for sites that break in this mode, like providing a specific UA string.
qwerty456127 7y ago
> And finally, starting fresh will enable us to drop a lot of the legacy baggage that the UA string carries (“Mozilla/5.0”, “like Gecko”, “like KHTML”, etc) going forward. Why not drop just that and leave nothing but the exact HTML and JavaScript engine names and versions like "Blink a.b, V8 x.y"? And what about robots? Will the Googlebot give the UA up as well?
- richthegeek 7y ago
  There are plenty of unmaintained sites out there that do stupid things in reaction to UA strings, and one of the stupid things is using a regex that expects specific strings to exist. Using a completely new string format in the same field (or removing it entirely) breaks a lot of sites that'll never be fixed. Freezing it prevents this. And if we're freezing and creating a new system then why not go for something queryable without all the baggage?
  - qwerty456127 7y ago
    How is something without all the baggage expected to help with the sites doing the stupid things?
    - ajsnigrutin 7y ago
      Users still want to see those pages. If browser X removes the UA string, that site brakes for them, and they change to browser Y that still has the old useragent.
      - qwerty456127 7y ago
        But won't removing just the baggage parts of the UA ("like Gecko", "KHTML" etc) break those sites anyway?
        richthegeek 7y ago
        The old UA will exist as it always has done - frozen, unchanged. Nothing will be removed from the literaly `user-agent` header value.
LeonM 7y ago
Good. The only legitimate use case I can think of is exception tracking, it is valuable to know which browser caused the exception. Beyond that, a website should never, ever rely on the UA for anything.
- qwerty456127 7y ago
  IMHO you're right but underestimate the value of what you have mentioned. It is VERY valuable to know which browser caused the exception.
  - jmcs 7y ago
    Maybe after people stop using the user agent for stupid reasons it can be made useful again. User agents should be stuff like "Firefox 71.0" or "Chrome 79.0.3945", not "Mozilla but really AppleWebKit disguised as KHTML, but no really I'm Chrome but maybe I'm Safari"
    - HorstG 7y ago
      Yes, but unfortunately using the user agent for only non-stupid reasons is a postcondition for the hell freezing over.
  - GoblinSlayer 7y ago
    Hopefully people will think twice before doing stuff that depend on browser.
- Tade0 7y ago
  Last time the UA string was useful to me was to show my SO's uncle that iOS Edge is just a "repackaged and watered down version of Safari".
  - saagarjha 7y ago
    My user agent is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15". Clearly I'm running a repackaged Firefox browser?
anilshanbhag 7y ago
The trigger for this was most likely the Brave/Vivaldi browsers. Brave used to 'Brave/X.y' at the end of user agent. Whatsapp didn't work with that useragent. Now Brave uses Google Chrome's useragent. In my app Dictanote (https://dictanote.co https://dictanote.co) - which uses Chrome's speech-to-text API, I have no way to distinguish Brave/Vivaldi and user doesn't understand why its not working :/
- RKearney 7y ago
  Using user agents to detect features is the wrong way to do it because you’ll have these exact problems. To determine if a browser has the text to speech API just check if the webkitSpeechRecognition object exists (if that’s the one you’re using). It will exist in Chrome and will not exist in other browsers that lack the feature.
  - scarejunba 7y ago
    > * It will exist in Chrome and will not exist in other browsers that lack the feature.* An incorrect assumption stated as fact with such great confidence. Good job. Even on the face of it, any engineer would know this can't be true.
- DarkCrusader2 7y ago
  Shouldn't you be using feature detection[1] here anyway? Making browsers unsupported in a blanket fashion via user-agent is the exact thing people should stop doing. [1] https://developers.google.com/web/updates/2014/01/Web-apps-that-talk-Introduction-to-the-Speech-Synthesis-API#feature_detection https://developers.google.com/web/updates/2014/01/Web-apps-t...
  - anilshanbhag 7y ago
    The webkitSpeechRecognition object shows up on both browsers. When you start recognition, it acts like you are not connected to the network. Not connected to the network is a common error , so you cannot fingerprint it to Brave. This specific API only works in Google Chrome unfortunately. So we need to stop people from trying in another browser and getting frustrated as to why its not working.
dbetteridge 7y ago
While the intent is good, didn't we recently see from the roll-out of secure/strict same-site cookies that feature detection isn't mature enough? Or does that not apply here. Getting rid of user agent strings is great, as long as we get a better way to determine browser capabilities that doesn't require some kind of special feature checking library...
- rowan_m 7y ago
  For older browsers, the UA string remains - so that's still viable for compatibility issues. https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/ will provide the cleaner, opt-in approach in the future.
  - dbetteridge 7y ago
    The hints do seem like a good approach, though scary from a fingerprinting side as they're much more fine-grained.
    - rowan_m 7y ago
      It changes the passive fingerprinting vector to an active one: https://github.com/bslassey/privacy-budget#passive-surfaces https://github.com/bslassey/privacy-budget#passive-surfaces So, while UA hints could potentially supply more information than the current UA string - each item needs to be explicitly requested by the site meaning the browser can make a choice on what to return. This may depend on user's preferences, level of trust in a site, the amount of identifying information already provided to the site, etc.
      - ori_b 7y ago
        > It changes the passive fingerprinting vector to an active one You say this as though the ad industry cares. > So, while UA hints could potentially supply more information than the current UA string - each item needs to be explicitly requested by the site meaning the browser can make a choice on what to return. Let me introduce you to useragent switchers. The replacement is strictly worse. Simply freezing the user agent solves things well.
chrisweekly 7y ago
Must-read bit of webdev lore: https://webaim.org/blog/user-agent-string-history/ https://webaim.org/blog/user-agent-string-history/
dijit 7y ago
Google recently introduced a new “secure” login page which forces my chromium based browser (qutebrowser) to fake a Mozilla firefox user agent in order to work. As such, I think if detection comes in some other form, it might be harder to trick some sites into working properly.
- zzzcpan 7y ago
  Despite all the PR about "privacy", they don't seem to intend to prevent detection at all and are introducing even more surface for detection with client hints. Basically the opposite of what the title implies.
  - rowan_m 7y ago
    Client Hints (https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/) move a passive fingerprinting vector to an active one, i.e. information must be explicitly requested by the site and then the browser can choose how to respond. The default level of information exposed drops to just the browser name and major version, which is only sent to sites on HTTPS and with JavaScript enabled. Additional hints are only sent on subsequent requests by the browser if the site sends the matching header in its initial response and the browser chooses to send a value. The current set of proposed hints define the same amount of information exposed Chrome's User-Agent string.
    - zzzcpan 7y ago
      That's not an active fingerprinting vector, especially within the context of https, still passive one with a minor protocol detail.
    - HorstG 7y ago
      Yes, but the fear remains that all sites will just always request everything from ua-client-hints. It is also totally unclear how browsers will handle this. I think making this permissioned will just add to the PrivacyNagOverload. Also, browsers will continue to lie in the hints because sites will always make broken assumptions or even try to do mischief with the info. I think the only winning move is not to play: Freeze the User-Agent and do not provide a replacement. Or at the very least, make the replacement based on actual feature bits, not version numbers and device models.
devit 7y ago
How about doing this but also NOT providing the client hints API and NOT providing any way for JavaScript to explicitly ask for OS and browser product name and version? While browser and JavaScript engines are likely to continue being detectable due to behavior and performance for the foreseeable future, it's probably possible to make the OS, browser frontend and exact engine version undetectable.
- pteraspidomorph 7y ago
  Seems to be the Firefox plan according to the text.
- marcusarmstrong 7y ago
  Browser vendor/version is hugely important information for triaging issues and implementing progressive enhancement approaches on large scale websites.
  - tyingq 7y ago
    Perhaps, but it invalidates most of their stated reasons for doing this. Which makes the post a confusing read.
    - marcusarmstrong 7y ago
      IMO it’s explained better in the Client Hints specification.
      - HorstG 7y ago
        Client hints are not any more useful than traditional UA for privacy or progressive enhancement. Its the same content, just split up. Any browser not sending everything will have atrocious permission UX, nagging websites or just get the broken IE5 version. UA hints solve nothing, even after reading the spec
    - magicalist 7y ago
      > it invalidates most of their stated reasons The "main advantages" section for client hints all seem to apply there.
close04 7y ago
> It provides the required information only when the server requests it In the interest of fingerprinting a server would request this every time. > It provides the information in small increments, so servers are only exposed to the information they need and request Then the server would need and request the most comprehensive list possible in order to fingerprint someone with better granularity than a UA string could. I'm not against this as I appreciate the value of this kind on information for the developers. It would be done one way or another. But why is this billed as mainly a privacy move? Nothing suggests it intrinsically offers better privacy when facing a website configured to fingerprint you. It actually looks like it gives even more granular info over which the user has less control than they used to with the UA.
jamescun 7y ago
Feature detection isn't the only use case User Agent strings service, two I've seen frequently are: * Exception Tracking - The User Agent string is usually attached to exceptions to aid in reproduction. * Outdated Client Detection - Primarily in internal dashboards in BYOD environments, I've seen the server display an error when a known outdated/insecure browser connects.
- kalleboo 7y ago
  When Safari froze their UA, another big one that came up was browser bugs. Specific versions of browsers on specific platforms have bugs, and you need to be able to tell your user to upgrade.
  - clarry 7y ago
    Please use the latest supported browser. There, I just told you to upgrade without sniffing UA.
    - HorstG 7y ago
      Also, "please upgrade, then call back" is always the first point on any support call checklist.
      - kalleboo 7y ago
        On the web you've lost 95% of users before they contact support
    - kalleboo 7y ago
      No user is going to see that sentence. They're going to read right past it, click some button, it doesn't work, "this site sucks" and go somewhere else.
      - clarry 7y ago
        I'll take that over a feature that just gets abused for all kinds of things and will create breakage which makes users just go elsewhere because it's broken. It is ridiculous for every website to be babysitting their users software, when we already have operating systems that keep software up to date, package managers that keep software up to date, and software that keeps itself up to date. If I need to make a really important website that can't lose users like that, I just need to make damn sure it works with any relevant browser without any UA sniffing hacks that will bite back down the line. If I'm making some bleeding edge crap that really needs a bleeding edge browser, I'm sure I can find a place for that sentence where most users will find it, and if I lose a few users, it probably isn't that big of a deal. Chances are I'd lose more users anyway due to many not wanting or being able to update for any number of reasons.
tsegratis 7y ago
I'd still like a way to feature detect, rather than make a round-trip to the browser. This would let me embed webasm rather than js+branch to begin a second download if feature found... etc I suggest UA string be a bitmask of features. Then feature detection should stop being broken Extra bits could be used for js-on/js-off, and is-bot/is-human -- Ah I see they're kind of doing the bitmask, but keeping a round-trip, and making things complicated (though I realize latest http standards can probably remove those round-trips in the average case) I'd still suggest the bitmask for non-sensitive information, and have everything else simply js-tested as it currently is Maybe is-user-blind might be a nice bit too, since canvas based websites could switch to the dom, or whatever
- tsegratis 7y ago
  Please could we also have a couple more privacy setting bits for i-accept-your-cookies and i-want-to-be-told-about-cookies-on-every-single-website-because-i-forget-what-they-are-and-really-want-to-click-through-to-your-privacy-settings If we have those bits, then the user can make a set of choices once, for every site, and we get rid of cookie pop-ups -- Websites could still ask if they want/need to do something that violates those choices
  - zeven7 7y ago
    Or we can just assume like reasonable adults that websites are going to put cookies in your browser and promote privacy-oriented tech to users rather than trying to pretend that having every website ask for permission in order to enable basic functionality solves anything.
    - pjc50 7y ago
      > promote privacy-oriented tech to users Like what? > every website ask for permission in order to enable basic functionality I don't believe that purely functional cookies require GDPR permission - that's covered by "provide services to the user". It's the ones which are functionality to third parties not the user which are the problem.
dochtman 7y ago
Quite happy that the market leader is taking this step! Hopefully this will decrease the problems with lacking feature detection. I was surprised that the post doesn't contain any example user agent strings for a sample of how they are expected to look starting from the different milestones.
saagarjha 7y ago
Safari tried to do this but had to walk back some of their changes: https://bugs.webkit.org/show_bug.cgi?id=180365 https://bugs.webkit.org/show_bug.cgi?id=180365. Currently, it reports the marketing OS and version of Safari truthfully, while lying about the bundled version of WebKit. For example, my user agent is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15", but I am running Safari 13.1, WebKit 15609.1.13.4 on macOS Catalina 10.15.3.
- dangerface 7y ago
  Safari is a broken mess, I have to detect and fix it more than any other browser, makes sense they would make it even more broken.
  - realusername 7y ago
    I agree with that, I don't know if it's a lack of manpower on Safari and Safari mobile or what but it's severely far behind the other browsers.
    - londons_explore 7y ago
      Being a monopoly on iPhones means the rest of the community has to work around their bugs. Why would they put any effort into fixing those bugs - web devs are working around them just fine? Safari could say "Sorry - <div> tags aren't working in the current release", and all big websites would switch to other html tags in a matter of weeks.
    - AgloeDreams 7y ago
      Well, Chrome was based on Webkit for a while and then they forked it and as a result stopped contributing to it. For Google, Chrome is a major product (as it forces their Search engine and products). For Apple, Safari is pretty minor. Apple simply doesn't have a reason to throw so much manpower at it.
      - 7y ago
dangerface 7y ago
This is a backwards step, I get the user agent is revealing things it has no right to like os, but not all browsers are made equal I need to know what its capable of.
- AgloeDreams 7y ago
  They are adding a property for this. A browser will expose a bunch of 'I Support this' flags and client hints rather than a browser version.
deleted 7y ago
[deleted]
tjelen 7y ago
And at the same time they recommend using UAs to detect agents incompatible with SameSite=None cookies (see https://www.chromium.org/updates/same-site/incompatible-clients https://www.chromium.org/updates/same-site/incompatible-clie...), including certain Chrome versions.
josteink 7y ago
Ok. So how do we do OS detection then? How do I know which (binary) download to offer my users? Edit: How do I provide reasonable defaults when the user’s OS actually matters?
- zzzcpan 7y ago
  Don't. That's an anti-pattern in UX. People download binaries for different OSes all the time, so list links for all OSes you support.
  - josteink 7y ago
    Giving people a reasonable default is bad UX? That’s a load of horseshit if I’ve ever heard it.
    - zzzcpan 7y ago
      What reasonable default? You don't know where people want to install your binaries and you do want people to know what other OSes you support. In UX if the number of choices is very small, like those couple of OSes you support, it is always best to present them all.
      - josteink 7y ago
        Every major player provides the reasonable default when downloading binaries. Every single one. There’s a reason for that. Regular users are not technical and if you ask them to make a choice based on technical matters (Windows, MAC, Linux, Apple AppStore, Android AppStore, Chrone WebStore, whatever), where you instead could have had -1 clear choice- already presented by default in a big nice button, you will lose conversions or increase tech-support costs. The evidence for this is so overwhelming that knowingly trying to ignore that makes it look like you have an agenda or horse to grind.
        zzzcpan 7y ago
        No, these are not UX metrics, these are commercial metrics. There is a reason conversions and tech-support costs and almost all a/b tests and all that are not even remotely good UX metrics, as they do not exist to measure anything users care about in the product, only what companies care about.
Ayesh 7y ago
This can have a huge impact. - Server log analytics will not be able to provide OS/Browser stats. - Default download pages (Detect OS automatically and redirect to the platform-specific download pages) would not work. - "m." Sites: there are still some sites that sniff the UA string and redirect users to mobile site. It's looking for patterns like "/mobile/" in UA, and don't require a lot of updates as the post argues.
- onion2k 7y ago
  I think you'll still be able to tell what OS and browser it is, just not the specific major or minor version because they'll be 85.0.0 (if that's the version when this happens) forever. All of the examples you've put there will still be achievable with the out-of-date UA string.
CodeWriter23 7y ago
> It provides the information in small increments, so servers are only exposed to the information they need and request, rather than being exposed to the full gamut of the UA string even if they are just trying to figure out one detail about the browser. So, an extra RT if your app needs to sense which UA it’s talking to.
sheerun 7y ago
Client Hints won't work with SSR because they are available only on second request... I hope they fix it before deprecating.
smashah 7y ago
Is this going to make spoofing UA harder/redundant? If so it's bad news for a lot of projects.
leeoniya 7y ago
https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/ the proposed implementation leaves me questioning how useful the CH headers are for initial impressions of a web property if only the browser and version are sent by default, and more info is only provided on follow-up requests, assuming the user agrees to some permission popup they don't understand. it'll be the "this site uses cookies" nonsense / nuisance all over again. it'll finally push end users to install the native reddit app without those constant annoyances. i have quite a few ux enhancements that need to know or guestimate the screen size, if the device is touch capable and OS (especially for form input styling). i dont see how it is possible without an additional delay, fetch request and some annoying permission popup to deliver a good experience in the brave new CH world.
- HorstG 7y ago
  There is CSS media query for exactly your use-case. No need for sniffing, round-trips or any server-side activity at all.
  - leeoniya 7y ago
    a media query will not tell me what OS it is so i can infer the metrics of native fonts and form controls. i would have to use JS and create sentinel elements to make the measurements, which would still be a form of slower, shittier sniffing. also, a media query or any other client side method prevents me from delivering exactly the final content that's necessary and not have to do additional reflow-inducing js to get the end result.
danShumway 7y ago
Requires some complicated conversations about how client hints should work in a privacy-respecting way, but this is still unquestionably the right move. The arguments we're seeing are around what the replacement should be (or if there should be a replacement at all). But either of those scenarios are still better than keeping user agents as they are.
at_a_remove 7y ago
I have mixed feelings on this. On the other hand, I knew some people above me who are still stuck on useragent sniffing as the "way to go." On the other hand, I did use it in combination with other techniques to provide some real information. At one point I had a hard-to-even-track kind of problem, with difficulty even looking for common trends. I created a help form for the user. Please fill out when this occurred, where you were (this mattered), what OS were you running, what browser, and so forth. What I found using the UA (and backed by other tricks) was that many users, young users who were enrolled in college, were not only unaware of their browser or operating system version but the OS itself. Its utility began its decline when the browser makers began copying one another wholesale. It's kind of a shame. Capability-testing is better but for some troubleshooting applications, having something particular to pin your problems to is handy.
- miohtama 7y ago
  Please see UA Client Hints linked in the proposal https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/ You should still get this information, but more privacy oriented manner.
  - earthboundkid 7y ago
    I know no one RTFAs (I usually don't even RTFA), but in this case, it's really egregious. The whole discussion is going back and forth about UA sniffing with no one mentioning that the damn proposal is entirely based on adding UA Client Hints as a replacement. It makes this whole multi-hundred comment discussion pretty much valueless. Please, other commenters: read this link before discussing whether you're caremad about "like Gecko" in the UA string!
    - mkl 7y ago
      In this case, it seems like you didn't read the discussion either. Many people have been talking about UA Client Hints here, before you commented.
shortercode 7y ago
This seems particularly unhelpful for bug reporting systems. Being able to see a specific bug is only happening on Chromium 78 for Linux can save a lot of time and frustration. In theory the user can fill in the details on a bug report themselves, but it's hard enough to persuade them to copy paste the crash message we generate for them at the moment.
- penagwin 7y ago
  There should be better ways to identify the browser than the user agent. The user agent is a legacy artifact, have you seen how many "compatibility" parts are in there? Like why does the chrome user agent say "Mozilla" in iy?
  - samastur 7y ago
    Yes, but do you know any? UA is the only thing I get in server logs to discover how much attention I should pay to support particular browsers.
    - miohtama 7y ago
      User agent strings will be deprecated in favour of UA Client Hints, as mentioned in the proposal https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/
    - penagwin 7y ago
      There's not really a good server side way to do it unfortunately. All the current alternatives to my knowledge require js. It depends on your application but the only real alternative is to use a js analytics library to collect the statistics. The good news is that they're more accurate, can give you more information, and there's plenty of self hosted options like Matomo. But it is yet another thing the client as to load, and adblockers will likely skew your metrics.
ronancremin 7y ago
The irony of Google purporting to protect users' privacy while at the same time: - Chrome is still shipping with 3rd party cookies turned on by default (Safari and Firefox have them off, by default) - Chrome usage stats are sent to Google including button clicks. This is admitted in the Chrome privacy policy. - Chrome on mobile automatically shares your location with your default search engine i.e. Google - Chrome sort of forces a login …which shares browser and user details history with Google - Google redirects logins through the youtube.com domain to enable them to set a cookie for YouTube as well as Gmail or whatever, every time you login. Naughty stuff. So the stated reason for the change doesn't appear to make sense, suggesting that something else is going on. It amazes me that more people aren't calling Google out on this.
- deleted 7y ago
  [deleted]
- dawnerd 7y ago
  I don’t know if google redirecting their logins through YouTube and gmail are as bad as you make it out to be.
- czardoz 7y ago
  > So the stated reason for the change doesn't appear to make sense, suggesting that something else is going on. That's unsubstantiated and dilutes the discussion IMO. If you read the post, the proposal outlines a bunch of good reasons to stop supporting UA strings (feature detection, etc)
- glogla 7y ago
  Google is not protecting its users privacy, it is protecting their own business. They want everyone's ads to be worse than Google's, so you use Google. Hiding private data from everyone but themselves is part of the plan.
  - HorstG 7y ago
    Exactly. That is also why "logging in to Chrome" or rather Google is such an insidious misfeature. Soon they will be the only ones with cross-site tracking and third-party-cookie equvalents in the leading browser. That would be check mate for all other advertisers. I'm just not sure whether it's good or bad that antitrust regulators won't notice before it's too late.
tracker1 7y ago
I'm not sure I get the point of specifically requesting it... also, should have a DOM API to get this information spelled out, not sure where that is... Let alone requiring a round trip for the server to even see the information... does that mean a 302 to itself for initial data? What about a POST? The first render is where this kind of crap is most useful for server-side rendering. The fact is, in general, it would be nice to get the actual browser/version and os/version, and maybe have an engines list for cross-compatibility detection as a fallback. When you come across a bug that only effects a specific browser/version (or other browsers using that engine as a base), it's a pain to deal with... cleaning it up when fixed is another issue, or worse, when you target a specific version, then the next release doesn't fix the issue and you're scrambling to update your range for the fix. It isn't nearly as bad as the late 90's, but it's still pretty bad.
zerotolerance 7y ago
I think the proposal is well-intentioned and shortsighted. Nobody ever plans for a junk drawer feature, but certain features are destined to be fragile fuzzy contracts regardless. Unless this proposal seeks to eliminate the differences between different user agents, it is proposing moving to a different but equivalent junk drawer. The change would create real pain for service providers and consumers alike and provide little benefit. From the implementation side, I would have preferred to see an OPTIONS request style solution similar to CORS to allow complying UAs to detect what if any UA information will be required.
- Izkata 7y ago
  > I think the proposal is well-intentioned and shortsighted. Could also be evil and long-term: user agents won't matter anymore once everything is auto-updated Chrome, right?
arendtio 7y ago
As a KDE User, I am so happy every time I see 'KHTML' in one of those User-Agent strings, it would be horrible if Konquerors legacy would be removed one day ;-) So it is good they don't want to remove it, but just freeze it :D
ksec 7y ago
Google's Good Intention were to support privacy, and >the web should be is an abundant source of compatibility issues. in particular for minority browsers, resulting in browsers lying about themselves (generally or to specific sites), and sites (including Google properties) being broken in some browsers for no good reason. Doesn't that mean every Web feature would be Google's way or the high way. Google, using Blink and Chrome would be dictating the web standards. And if it is incompatible, it would now officially be the browser vendors's fault and not the designer.
- trilliumbaker 7y ago
  > Google's Good Intention were to support privacy I find this intent for be very difficult to believe. Chrome's privacy policy[0] already lists a ton of information that Chrome sends to Google. I am cynical and simply do not trust Google. I see this as a move for control rather than privacy. 0. https://www.google.com/chrome/privacy/ https://www.google.com/chrome/privacy/
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
buu700 7y ago
There are many, many cases where UA sniffing is correct and required. Browsers are buggy, complicated pieces of software that don't always behave 100% as specified or expected. Feature detection is well and good, and should be the first line of attack; but sometimes you need to account for things like certain versions of Safari having WebRTC "support" that's actually completely broken, certain versions of Chrome crashing when certain WebAssembly features are used, and Firefox-specific CSS bugs. (All real examples I've run into.) It may not be the worst thing in the world if UA sniffing is broken for all existing web properties though, since anything not well maintained enough to migrate to a new API is probably either working off of outdated information or abusing UA sniffing where feature detection would have been more appropriate anyway. That being said, requiring a server to use User Agent Client Hints is stupid. What are client-side libraries like webrtc-adapter (https://github.com/webrtcHacks/adapter/issues/1017 https://github.com/webrtcHacks/adapter/issues/1017) supposed to do? I don't see any goals listed that wouldn't be addressed equally well while providing an equivalent JS API.
- crazygringo 7y ago
  > There are many, many cases where UA sniffing is correct and required. This times a million. Browsers have tons of bugs/inconsistencies where knowing the browser+version is the only way to work around them. Even when browsers fix them, you need to keep the workarounds for people still on the older versions. When I wrote a library that used the audio API, I couldn't believe the number of browser+version-specific workarounds I had to code for. And it's not just "bugs" but things where the spec is unclear. I don't remember the exact specifics, but it was a lot of stuff like "if I send a pause command, will a stop event fire afterwards or a pause event or no event at all?" There were a lot of situations where there was zero overlap between browsers. Literally no choice but to use user agent sniffing.
- xtracto 7y ago
  Just a couple of weeks ago we had a customer complain that their customers were having problems using our technology in IE11 because it was too slow... We had to recur to identifying IE11 to write workarounds so that it works there...
JohnFen 7y ago
Removing the user agent string is something that I've wished for for decades. While we're at it, the browser should not be revealing anything else about it or our machines at all unless we consent to it.
darrinm 7y ago
How will this affect caniuse.com? I use it every day.
toast0 7y ago
I may be cynical, but the Accept-CH proposal seems to me like something proposed for appearances only, not with any intent to actually implement. It just doesn't make sense from the perspective of HTTP. The only existing flow where an HTTP server passes context to the client and the client makes a new request based on that is HTTP authentication; but that's not intended to be optional --- generally servers don't provide good enough content with HTTP 401 and expect clients to display it in case they don't feel like authenticating. In this proposed flow, the server would need to, at least, start sending the content on the original request, and then send it again in case the client actually sends a new request. If this is an HTTPS only feature, the server to client request could be moved up into the TLS handshake; the client could include an empty Accept-CH extension, and if present, the server could include an Accept-CH extension with the fields it wants in HTTP requests. Then the client would send the fields, or not, according to user preference. Zero added round trips. Otherwise, it might be better if the server were able to indicate to clients what its matching rules were. If the initial response returns best case data, and a list of exception rules, the client could send a second request only if the rules matched. Then you could say if it's a specific build of Chrome where important feature is present but broken[1], or Chrome version before X, or Chrome on mobile if ARMv5 or whatever, please disregard the content and refetch with more details provided to the server, so it could provide an appropriate page. [1] Let's say that particular version crashes when the feature is attempted to be used; it's plausible, and not really detectable from Javascript.
jonarnes 7y ago
> The opt-in based mechanism of Client Hints currently suffers from the fact that on the very-first view, the browser have not yet received the opt-in. That means that requiring specific UA information (e.g. device model, platform) on the very-first navigation request may incur a delay. We are exploring options to enable the opt-in to happen further down the stack to avoid that delay. I'm surprised Google goes ahead with this without having a concrete plan to handle the first request to a page. I fear that will become an ugly mess of redirects, js hacks and broken pages. Think Google is under estimating how widespread device detection user User-Agent on the server side is...
EGreg 7y ago
This is a terrible idea unless the better mechanism includes a way to determine at least basic things like whether this is a mobile browser! Determined web developers will still be able to detect the browser using Javascript and send the info to the server. And meanwhile, we won’t be able to send resources optimized for eg mobile browsers vs desktop ones. Now we have to ship lots of crap from the server and hope JS is enabled to load the minimum. The whole deprecation movement has to stop breaking the web for activist reasons.
- zzo38computer 7y ago
  The resource optimization is mostly needed only due to making stuff too complicated already. Simplify the document and then it should just as well either way.
kerkeslager 7y ago
One problem with User-Agent strings is that they actually don't work for their intended use case. Nothing is stopping user agents from lying about who they are to the server, and many user agents actively do this. I've been on teams a few times that tried to use UA strings to try to serve up features per-browser. Trying to do this directly falls apart quickly. There are some libraries that handle the most common problems, but that really only delays the inevitable: eventually some critical user is using a browser that you are detecting wrong, and you end up lost in endless hard-coded edge cases. Using UA strings to determine functionality isn't an effective strategy.
sergeykish 7y ago
How much of the web depends on User Agent header? Maybe it can be removed altogether with small whitelist of exceptions. Firefox about:config general.useragent.override, String, leave empty Looks fine so far
deleted 7y ago
[deleted]
peterwwillis 7y ago
It's going to be fun to watch all the product teams for all the web products stop all their active development so they can push through emergency fixes when this breaks their products. Just like Chrome 80's breaking of an established cookie use pattern is doing.
superkuh 7y ago
I can see why the commercial web interests would want to get rid of user-agent strings. But to non-corporate persons, at least to techies, they're very useful and fun things. It's just text too so it's easy to deal with. Adopting some complex standard in javascript to replace it is no replacement.
jmurda 7y ago
There is a live demo of client hints https://browserleaks.com/client-hints https://browserleaks.com/client-hints I don't see how this should reduce fingerprinting if all sites start sending accept-ch headers by default
TheGoddessInari 7y ago
This is rich coming from Google, which this week started blocking access to Gmail based on a client's user agent!

381 points by jasonvorhe 7y ago

> On top of those privacy issues, User-Agent sniffing is an abundant source of compatibility issues, in particular for minority browsers, resulting in browsers lying about themselves (generally or to specific sites), and sites (including Google properties) being broken in some browsers for no good reason. > The above abuse makes it desirable to freeze the UA string and replace it with a better mechanism. UA sniffing should have died out a long time ago. It's frustrating that it's 2020 and I'm still having my browsing experience broken for no other reason than the site doesn't like my UA.

DJBunnies 7y ago
I have some news for you about what year it is.
- ChrisSD 7y ago
  Thanks, I've edited.
  - cmsd2 7y ago
    i predict this comment will age badly.
gsich 7y ago
Don't use $current_year argumentation.
- interfixus 7y ago
  Don't don't.
- wruza 7y ago
  It is a subjective version of “too long not fixed”. Like gp remembers this exact problem in 1980/1990/2000 and still there it is. A specific year has nothing to do with it. So come on, it’s 2020 and we still have to explain idioms to each other :)
sebazzz 7y ago
User agent sniffing is still sometimes required. Take the SameSite bugs that Safari had. On the server you needed to act on that based on User Agent sniffing.
- Macha 7y ago
  I also remember a CSS bug Safari 4 or 5 had with tables and touch scrollbars that we had to resort to UA detection for - it's not always possible to feature detect bugs.
- vdnkh 7y ago
  Agreed. For media streaming UA sniffing is required because of quirks each browser has in decoding media. Safari has a few quirks about the MP4 packaging it likes via MediaSourceExtensions. Firefox's network stack includes a delay not related to the actual request because of its implementation[0] which makes timing of small downloads very inaccurate. None of these differences are discernible except by UA. [1] I believe FF includes in the download length the time a request spends sitting in the request queue, but I can't exactly remember.
  - anoncake 7y ago
    Browsers have those quirks because web designers work around and hide them.
- xfalcox 7y ago
  > SameSite bugs that Safari had Safari has SameSite bugs and it's infuriating that after years they don't even update the bug reports, let alone fix those. https://bugs.webkit.org/show_bug.cgi?id=200345 https://bugs.webkit.org/show_bug.cgi?id=200345
- jerf 7y ago
  I think it's distinctly possible that the current status quo may cause an overreaction. Feature detection is good. But we may also need the ability to do specific version checking sometimes. What I think would be best is two things: A feature advertising string (preferably with some versioning in itself), and a new User Agent string that is just that: The user agent. As in, "This is Firefox 72.2.813". Maybe the OS in there too. I think a non-trivial part of the problem with the UA today is "Hey... I'm Firefox. Also, I'm Mozilla. Also, I'm edge 3, and Internet Explorer 6, and today I think I'm also Chrome. Also, I may be a monkey with a banana plugged in to an ethernet cable." Part of the problem is that people abuse the user agent, but part of the problem is that the user agent string is also a pack of outright, outrageous, self-contradictory lies. A truthful field may still have significant utility. One of the things I've learned over the years in software engineering is that you should do you best to make sure that your system doesn't contain lies, or, failing that, treat them like any other issues that you should contain at the edges rather than letting it run riot through your system. For instance, if you decide to let customers have 10GB of bandwidth free before you start charging them, you should never accomplish that goal by tweaking the bandwidth counting system to report 7.5GB of usage as 0GB. That is a lie. Tell the truth about the usage and let the billing system apply the discount, which is itself a truth as well. You always pay for lies in the system in the long run. It is a very common pattern in coding as well where some function author figures out how to assemble the correct lie to some other function to make it do what the author things they want, but in the long run you're better off telling the truth and fixing the code to work with the truth. Otherwise, well, you really do end up with a tangled web of code. Which is... exactly what we've gotten with UA-detection-based code. We won't necessarily get the same mess if there's a new UA that isn't a lie. I'm not claiming this will lead to utopia. Minority forks of popular browsers will fail to pick up the necessary ad-hoc bug fixes this way, for instance. My claim is more like in the long run, the best thing for everybody is just to have a user agent that tells the truth, even if on occasion in the short term you experience occasional problems. (One way to at least partially achieve this is to standardize the new truthful agent string to something like (\w+) ((\d+.)+\d) (\w+), and specify it as "non-conforming true user agent strings MUST be entirely rejected and treated as being absent", so anyone who tries to be Firefox and Chrome and also a monkey ends up being nobody in particular.)
dTal 7y ago
Of course, when the User Agent sniffing messes up, you're perfectly free to change it, and see what else you can get the server to send you. Can you still do that with whatever crazy "feature detection" replaces it?

LyndsySimon 7y ago

For context, as it’s not immediately obvious at the link: Blink is Chrome/Chromium’s rendering engine.

ShinTakuya 7y ago
Thanks, I assumed so but it's useful to have this confirmation before I looked it up. Honestly this is a little surprising to me. Sites pulling shit like matching UA usually works out in Chrome's favour so it's nice to see them throwing the minor web browsers an olive branch.
- close04 7y ago
  Developers will still mostly target the most popular browser(s), particularly Chrome. It would be great if browsers like Firefox managed to implement a "feature detection spoof" that you can enable to still present yourself as Chrome (or other browsers) regardless of the actual features requested. More or less like changing the UA does now.
  - GoblinSlayer 7y ago
    That's Go Faster addon.
    - close04 7y ago
      This looks like it's intended to fix specific issues, not for fingerprint blocking. I was thinking more like being able to present yourself as generic Chrome on Windows 10 or Firefox on Android if you chose to, even with the risk of breaking the site.
      - GoblinSlayer 7y ago
        Firefox resists fingerprinting by default, and go faster addon provides mitigations for sites that break in this mode, like providing a specific UA string.

qwerty456127 7y ago

> And finally, starting fresh will enable us to drop a lot of the legacy baggage that the UA string carries (“Mozilla/5.0”, “like Gecko”, “like KHTML”, etc) going forward. Why not drop just that and leave nothing but the exact HTML and JavaScript engine names and versions like "Blink a.b, V8 x.y"? And what about robots? Will the Googlebot give the UA up as well?

richthegeek 7y ago
There are plenty of unmaintained sites out there that do stupid things in reaction to UA strings, and one of the stupid things is using a regex that expects specific strings to exist. Using a completely new string format in the same field (or removing it entirely) breaks a lot of sites that'll never be fixed. Freezing it prevents this. And if we're freezing and creating a new system then why not go for something queryable without all the baggage?
- qwerty456127 7y ago
  How is something without all the baggage expected to help with the sites doing the stupid things?
  - ajsnigrutin 7y ago
    Users still want to see those pages. If browser X removes the UA string, that site brakes for them, and they change to browser Y that still has the old useragent.
    - qwerty456127 7y ago
      But won't removing just the baggage parts of the UA ("like Gecko", "KHTML" etc) break those sites anyway?
      - richthegeek 7y ago
        The old UA will exist as it always has done - frozen, unchanged. Nothing will be removed from the literaly `user-agent` header value.

LeonM 7y ago

Good. The only legitimate use case I can think of is exception tracking, it is valuable to know which browser caused the exception. Beyond that, a website should never, ever rely on the UA for anything.

qwerty456127 7y ago
IMHO you're right but underestimate the value of what you have mentioned. It is VERY valuable to know which browser caused the exception.
- jmcs 7y ago
  Maybe after people stop using the user agent for stupid reasons it can be made useful again. User agents should be stuff like "Firefox 71.0" or "Chrome 79.0.3945", not "Mozilla but really AppleWebKit disguised as KHTML, but no really I'm Chrome but maybe I'm Safari"
  - HorstG 7y ago
    Yes, but unfortunately using the user agent for only non-stupid reasons is a postcondition for the hell freezing over.
- GoblinSlayer 7y ago
  Hopefully people will think twice before doing stuff that depend on browser.
Tade0 7y ago
Last time the UA string was useful to me was to show my SO's uncle that iOS Edge is just a "repackaged and watered down version of Safari".
- saagarjha 7y ago
  My user agent is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15". Clearly I'm running a repackaged Firefox browser?

anilshanbhag 7y ago

The trigger for this was most likely the Brave/Vivaldi browsers. Brave used to 'Brave/X.y' at the end of user agent. Whatsapp didn't work with that useragent. Now Brave uses Google Chrome's useragent. In my app Dictanote (https://dictanote.co https://dictanote.co) - which uses Chrome's speech-to-text API, I have no way to distinguish Brave/Vivaldi and user doesn't understand why its not working :/

RKearney 7y ago
Using user agents to detect features is the wrong way to do it because you’ll have these exact problems. To determine if a browser has the text to speech API just check if the webkitSpeechRecognition object exists (if that’s the one you’re using). It will exist in Chrome and will not exist in other browsers that lack the feature.
- scarejunba 7y ago
  > * It will exist in Chrome and will not exist in other browsers that lack the feature.* An incorrect assumption stated as fact with such great confidence. Good job. Even on the face of it, any engineer would know this can't be true.
DarkCrusader2 7y ago
Shouldn't you be using feature detection[1] here anyway? Making browsers unsupported in a blanket fashion via user-agent is the exact thing people should stop doing. [1] https://developers.google.com/web/updates/2014/01/Web-apps-that-talk-Introduction-to-the-Speech-Synthesis-API#feature_detection https://developers.google.com/web/updates/2014/01/Web-apps-t...
- anilshanbhag 7y ago
  The webkitSpeechRecognition object shows up on both browsers. When you start recognition, it acts like you are not connected to the network. Not connected to the network is a common error , so you cannot fingerprint it to Brave. This specific API only works in Google Chrome unfortunately. So we need to stop people from trying in another browser and getting frustrated as to why its not working.

dbetteridge 7y ago

While the intent is good, didn't we recently see from the roll-out of secure/strict same-site cookies that feature detection isn't mature enough? Or does that not apply here. Getting rid of user agent strings is great, as long as we get a better way to determine browser capabilities that doesn't require some kind of special feature checking library...

rowan_m 7y ago
For older browsers, the UA string remains - so that's still viable for compatibility issues. https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/ will provide the cleaner, opt-in approach in the future.
- dbetteridge 7y ago
  The hints do seem like a good approach, though scary from a fingerprinting side as they're much more fine-grained.
  - rowan_m 7y ago
    It changes the passive fingerprinting vector to an active one: https://github.com/bslassey/privacy-budget#passive-surfaces https://github.com/bslassey/privacy-budget#passive-surfaces So, while UA hints could potentially supply more information than the current UA string - each item needs to be explicitly requested by the site meaning the browser can make a choice on what to return. This may depend on user's preferences, level of trust in a site, the amount of identifying information already provided to the site, etc.
    - ori_b 7y ago
      > It changes the passive fingerprinting vector to an active one You say this as though the ad industry cares. > So, while UA hints could potentially supply more information than the current UA string - each item needs to be explicitly requested by the site meaning the browser can make a choice on what to return. Let me introduce you to useragent switchers. The replacement is strictly worse. Simply freezing the user agent solves things well.

chrisweekly 7y ago

Must-read bit of webdev lore: https://webaim.org/blog/user-agent-string-history/ https://webaim.org/blog/user-agent-string-history/

dijit 7y ago

Google recently introduced a new “secure” login page which forces my chromium based browser (qutebrowser) to fake a Mozilla firefox user agent in order to work. As such, I think if detection comes in some other form, it might be harder to trick some sites into working properly.

zzzcpan 7y ago
Despite all the PR about "privacy", they don't seem to intend to prevent detection at all and are introducing even more surface for detection with client hints. Basically the opposite of what the title implies.
- rowan_m 7y ago
  Client Hints (https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/) move a passive fingerprinting vector to an active one, i.e. information must be explicitly requested by the site and then the browser can choose how to respond. The default level of information exposed drops to just the browser name and major version, which is only sent to sites on HTTPS and with JavaScript enabled. Additional hints are only sent on subsequent requests by the browser if the site sends the matching header in its initial response and the browser chooses to send a value. The current set of proposed hints define the same amount of information exposed Chrome's User-Agent string.
  - zzzcpan 7y ago
    That's not an active fingerprinting vector, especially within the context of https, still passive one with a minor protocol detail.
  - HorstG 7y ago
    Yes, but the fear remains that all sites will just always request everything from ua-client-hints. It is also totally unclear how browsers will handle this. I think making this permissioned will just add to the PrivacyNagOverload. Also, browsers will continue to lie in the hints because sites will always make broken assumptions or even try to do mischief with the info. I think the only winning move is not to play: Freeze the User-Agent and do not provide a replacement. Or at the very least, make the replacement based on actual feature bits, not version numbers and device models.

devit 7y ago

How about doing this but also NOT providing the client hints API and NOT providing any way for JavaScript to explicitly ask for OS and browser product name and version? While browser and JavaScript engines are likely to continue being detectable due to behavior and performance for the foreseeable future, it's probably possible to make the OS, browser frontend and exact engine version undetectable.

pteraspidomorph 7y ago
Seems to be the Firefox plan according to the text.
marcusarmstrong 7y ago
Browser vendor/version is hugely important information for triaging issues and implementing progressive enhancement approaches on large scale websites.
- tyingq 7y ago
  Perhaps, but it invalidates most of their stated reasons for doing this. Which makes the post a confusing read.
  - marcusarmstrong 7y ago
    IMO it’s explained better in the Client Hints specification.
    - HorstG 7y ago
      Client hints are not any more useful than traditional UA for privacy or progressive enhancement. Its the same content, just split up. Any browser not sending everything will have atrocious permission UX, nagging websites or just get the broken IE5 version. UA hints solve nothing, even after reading the spec
  - magicalist 7y ago
    > it invalidates most of their stated reasons The "main advantages" section for client hints all seem to apply there.

close04 7y ago

> It provides the required information only when the server requests it In the interest of fingerprinting a server would request this every time. > It provides the information in small increments, so servers are only exposed to the information they need and request Then the server would need and request the most comprehensive list possible in order to fingerprint someone with better granularity than a UA string could. I'm not against this as I appreciate the value of this kind on information for the developers. It would be done one way or another. But why is this billed as mainly a privacy move? Nothing suggests it intrinsically offers better privacy when facing a website configured to fingerprint you. It actually looks like it gives even more granular info over which the user has less control than they used to with the UA.

jamescun 7y ago

Feature detection isn't the only use case User Agent strings service, two I've seen frequently are: * Exception Tracking - The User Agent string is usually attached to exceptions to aid in reproduction. * Outdated Client Detection - Primarily in internal dashboards in BYOD environments, I've seen the server display an error when a known outdated/insecure browser connects.

kalleboo 7y ago
When Safari froze their UA, another big one that came up was browser bugs. Specific versions of browsers on specific platforms have bugs, and you need to be able to tell your user to upgrade.
- clarry 7y ago
  Please use the latest supported browser. There, I just told you to upgrade without sniffing UA.
  - HorstG 7y ago
    Also, "please upgrade, then call back" is always the first point on any support call checklist.
    - kalleboo 7y ago
      On the web you've lost 95% of users before they contact support
  - kalleboo 7y ago
    No user is going to see that sentence. They're going to read right past it, click some button, it doesn't work, "this site sucks" and go somewhere else.
    - clarry 7y ago
      I'll take that over a feature that just gets abused for all kinds of things and will create breakage which makes users just go elsewhere because it's broken. It is ridiculous for every website to be babysitting their users software, when we already have operating systems that keep software up to date, package managers that keep software up to date, and software that keeps itself up to date. If I need to make a really important website that can't lose users like that, I just need to make damn sure it works with any relevant browser without any UA sniffing hacks that will bite back down the line. If I'm making some bleeding edge crap that really needs a bleeding edge browser, I'm sure I can find a place for that sentence where most users will find it, and if I lose a few users, it probably isn't that big of a deal. Chances are I'd lose more users anyway due to many not wanting or being able to update for any number of reasons.

tsegratis 7y ago

I'd still like a way to feature detect, rather than make a round-trip to the browser. This would let me embed webasm rather than js+branch to begin a second download if feature found... etc I suggest UA string be a bitmask of features. Then feature detection should stop being broken Extra bits could be used for js-on/js-off, and is-bot/is-human -- Ah I see they're kind of doing the bitmask, but keeping a round-trip, and making things complicated (though I realize latest http standards can probably remove those round-trips in the average case) I'd still suggest the bitmask for non-sensitive information, and have everything else simply js-tested as it currently is Maybe is-user-blind might be a nice bit too, since canvas based websites could switch to the dom, or whatever

tsegratis 7y ago
Please could we also have a couple more privacy setting bits for i-accept-your-cookies and i-want-to-be-told-about-cookies-on-every-single-website-because-i-forget-what-they-are-and-really-want-to-click-through-to-your-privacy-settings If we have those bits, then the user can make a set of choices once, for every site, and we get rid of cookie pop-ups -- Websites could still ask if they want/need to do something that violates those choices
- zeven7 7y ago
  Or we can just assume like reasonable adults that websites are going to put cookies in your browser and promote privacy-oriented tech to users rather than trying to pretend that having every website ask for permission in order to enable basic functionality solves anything.
  - pjc50 7y ago
    > promote privacy-oriented tech to users Like what? > every website ask for permission in order to enable basic functionality I don't believe that purely functional cookies require GDPR permission - that's covered by "provide services to the user". It's the ones which are functionality to third parties not the user which are the problem.

dochtman 7y ago

Quite happy that the market leader is taking this step! Hopefully this will decrease the problems with lacking feature detection. I was surprised that the post doesn't contain any example user agent strings for a sample of how they are expected to look starting from the different milestones.

saagarjha 7y ago

Safari tried to do this but had to walk back some of their changes: https://bugs.webkit.org/show_bug.cgi?id=180365 https://bugs.webkit.org/show_bug.cgi?id=180365. Currently, it reports the marketing OS and version of Safari truthfully, while lying about the bundled version of WebKit. For example, my user agent is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15", but I am running Safari 13.1, WebKit 15609.1.13.4 on macOS Catalina 10.15.3.

dangerface 7y ago
Safari is a broken mess, I have to detect and fix it more than any other browser, makes sense they would make it even more broken.
- realusername 7y ago
  I agree with that, I don't know if it's a lack of manpower on Safari and Safari mobile or what but it's severely far behind the other browsers.
  - londons_explore 7y ago
    Being a monopoly on iPhones means the rest of the community has to work around their bugs. Why would they put any effort into fixing those bugs - web devs are working around them just fine? Safari could say "Sorry - <div> tags aren't working in the current release", and all big websites would switch to other html tags in a matter of weeks.
  - AgloeDreams 7y ago
    Well, Chrome was based on Webkit for a while and then they forked it and as a result stopped contributing to it. For Google, Chrome is a major product (as it forces their Search engine and products). For Apple, Safari is pretty minor. Apple simply doesn't have a reason to throw so much manpower at it.
    - 7y ago

dangerface 7y ago

This is a backwards step, I get the user agent is revealing things it has no right to like os, but not all browsers are made equal I need to know what its capable of.

AgloeDreams 7y ago
They are adding a property for this. A browser will expose a bunch of 'I Support this' flags and client hints rather than a browser version.

deleted 7y ago

[deleted]

tjelen 7y ago

And at the same time they recommend using UAs to detect agents incompatible with SameSite=None cookies (see https://www.chromium.org/updates/same-site/incompatible-clients https://www.chromium.org/updates/same-site/incompatible-clie...), including certain Chrome versions.

josteink 7y ago

Ok. So how do we do OS detection then? How do I know which (binary) download to offer my users? Edit: How do I provide reasonable defaults when the user’s OS actually matters?

zzzcpan 7y ago
Don't. That's an anti-pattern in UX. People download binaries for different OSes all the time, so list links for all OSes you support.
- josteink 7y ago
  Giving people a reasonable default is bad UX? That’s a load of horseshit if I’ve ever heard it.
  - zzzcpan 7y ago
    What reasonable default? You don't know where people want to install your binaries and you do want people to know what other OSes you support. In UX if the number of choices is very small, like those couple of OSes you support, it is always best to present them all.
    - josteink 7y ago
      Every major player provides the reasonable default when downloading binaries. Every single one. There’s a reason for that. Regular users are not technical and if you ask them to make a choice based on technical matters (Windows, MAC, Linux, Apple AppStore, Android AppStore, Chrone WebStore, whatever), where you instead could have had -1 clear choice- already presented by default in a big nice button, you will lose conversions or increase tech-support costs. The evidence for this is so overwhelming that knowingly trying to ignore that makes it look like you have an agenda or horse to grind.
      - zzzcpan 7y ago
        No, these are not UX metrics, these are commercial metrics. There is a reason conversions and tech-support costs and almost all a/b tests and all that are not even remotely good UX metrics, as they do not exist to measure anything users care about in the product, only what companies care about.

Ayesh 7y ago

This can have a huge impact. - Server log analytics will not be able to provide OS/Browser stats. - Default download pages (Detect OS automatically and redirect to the platform-specific download pages) would not work. - "m." Sites: there are still some sites that sniff the UA string and redirect users to mobile site. It's looking for patterns like "/mobile/" in UA, and don't require a lot of updates as the post argues.

onion2k 7y ago
I think you'll still be able to tell what OS and browser it is, just not the specific major or minor version because they'll be 85.0.0 (if that's the version when this happens) forever. All of the examples you've put there will still be achievable with the out-of-date UA string.

CodeWriter23 7y ago

> It provides the information in small increments, so servers are only exposed to the information they need and request, rather than being exposed to the full gamut of the UA string even if they are just trying to figure out one detail about the browser. So, an extra RT if your app needs to sense which UA it’s talking to.

sheerun 7y ago

Client Hints won't work with SSR because they are available only on second request... I hope they fix it before deprecating.

smashah 7y ago

Is this going to make spoofing UA harder/redundant? If so it's bad news for a lot of projects.

leeoniya 7y ago

https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/ the proposed implementation leaves me questioning how useful the CH headers are for initial impressions of a web property if only the browser and version are sent by default, and more info is only provided on follow-up requests, assuming the user agrees to some permission popup they don't understand. it'll be the "this site uses cookies" nonsense / nuisance all over again. it'll finally push end users to install the native reddit app without those constant annoyances. i have quite a few ux enhancements that need to know or guestimate the screen size, if the device is touch capable and OS (especially for form input styling). i dont see how it is possible without an additional delay, fetch request and some annoying permission popup to deliver a good experience in the brave new CH world.

HorstG 7y ago
There is CSS media query for exactly your use-case. No need for sniffing, round-trips or any server-side activity at all.
- leeoniya 7y ago
  a media query will not tell me what OS it is so i can infer the metrics of native fonts and form controls. i would have to use JS and create sentinel elements to make the measurements, which would still be a form of slower, shittier sniffing. also, a media query or any other client side method prevents me from delivering exactly the final content that's necessary and not have to do additional reflow-inducing js to get the end result.

danShumway 7y ago

Requires some complicated conversations about how client hints should work in a privacy-respecting way, but this is still unquestionably the right move. The arguments we're seeing are around what the replacement should be (or if there should be a replacement at all). But either of those scenarios are still better than keeping user agents as they are.

at_a_remove 7y ago

I have mixed feelings on this. On the other hand, I knew some people above me who are still stuck on useragent sniffing as the "way to go." On the other hand, I did use it in combination with other techniques to provide some real information. At one point I had a hard-to-even-track kind of problem, with difficulty even looking for common trends. I created a help form for the user. Please fill out when this occurred, where you were (this mattered), what OS were you running, what browser, and so forth. What I found using the UA (and backed by other tricks) was that many users, young users who were enrolled in college, were not only unaware of their browser or operating system version but the OS itself. Its utility began its decline when the browser makers began copying one another wholesale. It's kind of a shame. Capability-testing is better but for some troubleshooting applications, having something particular to pin your problems to is handy.

miohtama 7y ago
Please see UA Client Hints linked in the proposal https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/ You should still get this information, but more privacy oriented manner.
- earthboundkid 7y ago
  I know no one RTFAs (I usually don't even RTFA), but in this case, it's really egregious. The whole discussion is going back and forth about UA sniffing with no one mentioning that the damn proposal is entirely based on adding UA Client Hints as a replacement. It makes this whole multi-hundred comment discussion pretty much valueless. Please, other commenters: read this link before discussing whether you're caremad about "like Gecko" in the UA string!
  - mkl 7y ago
    In this case, it seems like you didn't read the discussion either. Many people have been talking about UA Client Hints here, before you commented.

shortercode 7y ago

This seems particularly unhelpful for bug reporting systems. Being able to see a specific bug is only happening on Chromium 78 for Linux can save a lot of time and frustration. In theory the user can fill in the details on a bug report themselves, but it's hard enough to persuade them to copy paste the crash message we generate for them at the moment.

penagwin 7y ago
There should be better ways to identify the browser than the user agent. The user agent is a legacy artifact, have you seen how many "compatibility" parts are in there? Like why does the chrome user agent say "Mozilla" in iy?
- samastur 7y ago
  Yes, but do you know any? UA is the only thing I get in server logs to discover how much attention I should pay to support particular browsers.
  - miohtama 7y ago
    User agent strings will be deprecated in favour of UA Client Hints, as mentioned in the proposal https://wicg.github.io/ua-client-hints/ https://wicg.github.io/ua-client-hints/
  - penagwin 7y ago
    There's not really a good server side way to do it unfortunately. All the current alternatives to my knowledge require js. It depends on your application but the only real alternative is to use a js analytics library to collect the statistics. The good news is that they're more accurate, can give you more information, and there's plenty of self hosted options like Matomo. But it is yet another thing the client as to load, and adblockers will likely skew your metrics.

ronancremin 7y ago

The irony of Google purporting to protect users' privacy while at the same time: - Chrome is still shipping with 3rd party cookies turned on by default (Safari and Firefox have them off, by default) - Chrome usage stats are sent to Google including button clicks. This is admitted in the Chrome privacy policy. - Chrome on mobile automatically shares your location with your default search engine i.e. Google - Chrome sort of forces a login …which shares browser and user details history with Google - Google redirects logins through the youtube.com domain to enable them to set a cookie for YouTube as well as Gmail or whatever, every time you login. Naughty stuff. So the stated reason for the change doesn't appear to make sense, suggesting that something else is going on. It amazes me that more people aren't calling Google out on this.

deleted 7y ago
[deleted]
dawnerd 7y ago
I don’t know if google redirecting their logins through YouTube and gmail are as bad as you make it out to be.
czardoz 7y ago
> So the stated reason for the change doesn't appear to make sense, suggesting that something else is going on. That's unsubstantiated and dilutes the discussion IMO. If you read the post, the proposal outlines a bunch of good reasons to stop supporting UA strings (feature detection, etc)
glogla 7y ago
Google is not protecting its users privacy, it is protecting their own business. They want everyone's ads to be worse than Google's, so you use Google. Hiding private data from everyone but themselves is part of the plan.
- HorstG 7y ago
  Exactly. That is also why "logging in to Chrome" or rather Google is such an insidious misfeature. Soon they will be the only ones with cross-site tracking and third-party-cookie equvalents in the leading browser. That would be check mate for all other advertisers. I'm just not sure whether it's good or bad that antitrust regulators won't notice before it's too late.

tracker1 7y ago

I'm not sure I get the point of specifically requesting it... also, should have a DOM API to get this information spelled out, not sure where that is... Let alone requiring a round trip for the server to even see the information... does that mean a 302 to itself for initial data? What about a POST? The first render is where this kind of crap is most useful for server-side rendering. The fact is, in general, it would be nice to get the actual browser/version and os/version, and maybe have an engines list for cross-compatibility detection as a fallback. When you come across a bug that only effects a specific browser/version (or other browsers using that engine as a base), it's a pain to deal with... cleaning it up when fixed is another issue, or worse, when you target a specific version, then the next release doesn't fix the issue and you're scrambling to update your range for the fix. It isn't nearly as bad as the late 90's, but it's still pretty bad.

zerotolerance 7y ago

I think the proposal is well-intentioned and shortsighted. Nobody ever plans for a junk drawer feature, but certain features are destined to be fragile fuzzy contracts regardless. Unless this proposal seeks to eliminate the differences between different user agents, it is proposing moving to a different but equivalent junk drawer. The change would create real pain for service providers and consumers alike and provide little benefit. From the implementation side, I would have preferred to see an OPTIONS request style solution similar to CORS to allow complying UAs to detect what if any UA information will be required.

Izkata 7y ago
> I think the proposal is well-intentioned and shortsighted. Could also be evil and long-term: user agents won't matter anymore once everything is auto-updated Chrome, right?

arendtio 7y ago

As a KDE User, I am so happy every time I see 'KHTML' in one of those User-Agent strings, it would be horrible if Konquerors legacy would be removed one day ;-) So it is good they don't want to remove it, but just freeze it :D

ksec 7y ago

Google's Good Intention were to support privacy, and >the web should be is an abundant source of compatibility issues. in particular for minority browsers, resulting in browsers lying about themselves (generally or to specific sites), and sites (including Google properties) being broken in some browsers for no good reason. Doesn't that mean every Web feature would be Google's way or the high way. Google, using Blink and Chrome would be dictating the web standards. And if it is incompatible, it would now officially be the browser vendors's fault and not the designer.

trilliumbaker 7y ago
> Google's Good Intention were to support privacy I find this intent for be very difficult to believe. Chrome's privacy policy[0] already lists a ton of information that Chrome sends to Google. I am cynical and simply do not trust Google. I see this as a move for control rather than privacy. 0. https://www.google.com/chrome/privacy/ https://www.google.com/chrome/privacy/

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

buu700 7y ago

There are many, many cases where UA sniffing is correct and required. Browsers are buggy, complicated pieces of software that don't always behave 100% as specified or expected. Feature detection is well and good, and should be the first line of attack; but sometimes you need to account for things like certain versions of Safari having WebRTC "support" that's actually completely broken, certain versions of Chrome crashing when certain WebAssembly features are used, and Firefox-specific CSS bugs. (All real examples I've run into.) It may not be the worst thing in the world if UA sniffing is broken for all existing web properties though, since anything not well maintained enough to migrate to a new API is probably either working off of outdated information or abusing UA sniffing where feature detection would have been more appropriate anyway. That being said, requiring a server to use User Agent Client Hints is stupid. What are client-side libraries like webrtc-adapter (https://github.com/webrtcHacks/adapter/issues/1017 https://github.com/webrtcHacks/adapter/issues/1017) supposed to do? I don't see any goals listed that wouldn't be addressed equally well while providing an equivalent JS API.

crazygringo 7y ago
> There are many, many cases where UA sniffing is correct and required. This times a million. Browsers have tons of bugs/inconsistencies where knowing the browser+version is the only way to work around them. Even when browsers fix them, you need to keep the workarounds for people still on the older versions. When I wrote a library that used the audio API, I couldn't believe the number of browser+version-specific workarounds I had to code for. And it's not just "bugs" but things where the spec is unclear. I don't remember the exact specifics, but it was a lot of stuff like "if I send a pause command, will a stop event fire afterwards or a pause event or no event at all?" There were a lot of situations where there was zero overlap between browsers. Literally no choice but to use user agent sniffing.
xtracto 7y ago
Just a couple of weeks ago we had a customer complain that their customers were having problems using our technology in IE11 because it was too slow... We had to recur to identifying IE11 to write workarounds so that it works there...

JohnFen 7y ago

Removing the user agent string is something that I've wished for for decades. While we're at it, the browser should not be revealing anything else about it or our machines at all unless we consent to it.

darrinm 7y ago

How will this affect caniuse.com? I use it every day.

toast0 7y ago

I may be cynical, but the Accept-CH proposal seems to me like something proposed for appearances only, not with any intent to actually implement. It just doesn't make sense from the perspective of HTTP. The only existing flow where an HTTP server passes context to the client and the client makes a new request based on that is HTTP authentication; but that's not intended to be optional --- generally servers don't provide good enough content with HTTP 401 and expect clients to display it in case they don't feel like authenticating. In this proposed flow, the server would need to, at least, start sending the content on the original request, and then send it again in case the client actually sends a new request. If this is an HTTPS only feature, the server to client request could be moved up into the TLS handshake; the client could include an empty Accept-CH extension, and if present, the server could include an Accept-CH extension with the fields it wants in HTTP requests. Then the client would send the fields, or not, according to user preference. Zero added round trips. Otherwise, it might be better if the server were able to indicate to clients what its matching rules were. If the initial response returns best case data, and a list of exception rules, the client could send a second request only if the rules matched. Then you could say if it's a specific build of Chrome where important feature is present but broken[1], or Chrome version before X, or Chrome on mobile if ARMv5 or whatever, please disregard the content and refetch with more details provided to the server, so it could provide an appropriate page. [1] Let's say that particular version crashes when the feature is attempted to be used; it's plausible, and not really detectable from Javascript.

jonarnes 7y ago

> The opt-in based mechanism of Client Hints currently suffers from the fact that on the very-first view, the browser have not yet received the opt-in. That means that requiring specific UA information (e.g. device model, platform) on the very-first navigation request may incur a delay. We are exploring options to enable the opt-in to happen further down the stack to avoid that delay. I'm surprised Google goes ahead with this without having a concrete plan to handle the first request to a page. I fear that will become an ugly mess of redirects, js hacks and broken pages. Think Google is under estimating how widespread device detection user User-Agent on the server side is...

EGreg 7y ago

This is a terrible idea unless the better mechanism includes a way to determine at least basic things like whether this is a mobile browser! Determined web developers will still be able to detect the browser using Javascript and send the info to the server. And meanwhile, we won’t be able to send resources optimized for eg mobile browsers vs desktop ones. Now we have to ship lots of crap from the server and hope JS is enabled to load the minimum. The whole deprecation movement has to stop breaking the web for activist reasons.

zzo38computer 7y ago
The resource optimization is mostly needed only due to making stuff too complicated already. Simplify the document and then it should just as well either way.

kerkeslager 7y ago

One problem with User-Agent strings is that they actually don't work for their intended use case. Nothing is stopping user agents from lying about who they are to the server, and many user agents actively do this. I've been on teams a few times that tried to use UA strings to try to serve up features per-browser. Trying to do this directly falls apart quickly. There are some libraries that handle the most common problems, but that really only delays the inevitable: eventually some critical user is using a browser that you are detecting wrong, and you end up lost in endless hard-coded edge cases. Using UA strings to determine functionality isn't an effective strategy.

sergeykish 7y ago

How much of the web depends on User Agent header? Maybe it can be removed altogether with small whitelist of exceptions. Firefox about:config general.useragent.override, String, leave empty Looks fine so far

deleted 7y ago

[deleted]

peterwwillis 7y ago

It's going to be fun to watch all the product teams for all the web products stop all their active development so they can push through emergency fixes when this breaks their products. Just like Chrome 80's breaking of an established cookie use pattern is doing.

superkuh 7y ago

I can see why the commercial web interests would want to get rid of user-agent strings. But to non-corporate persons, at least to techies, they're very useful and fun things. It's just text too so it's easy to deal with. Adopting some complex standard in javascript to replace it is no replacement.

jmurda 7y ago

There is a live demo of client hints https://browserleaks.com/client-hints https://browserleaks.com/client-hints I don't see how this should reduce fingerprinting if all sites start sending accept-ch headers by default

TheGoddessInari 7y ago

This is rich coming from Google, which this week started blocking access to Gmail based on a client's user agent!