4 ms·

Stop sending User-Agent. Replace it with nothing. Not client hints. Nothing. If sites start rejecting Firefox clients because of that, then instead change it t

Stop sending User-Agent. Replace it with nothing. Not client hints. Nothing. If sites start rejecting Firefox clients because of that, then instead change it to send exactly the same User-Agent (and other software identification) that Chrome sends, and commit to exactly faking Chrome's signals in the future. The UA header never had any business existing to begin with. Servers guessing client capabilities from the software they're running, or trying to work around client bugs, is architecturally insane, concentrates power excessively, and guarantees that morons will write bugs like the one this story is about. And the other uses of the information are simply evil. If you need to signal specific capabilities, which you generally should not be doing because you shouldn't have punted all real attempts at standardization years ago, then signal specific capabilities. Or let the server try stuff and give only success or failure feedback.

metadat 4y ago
At first I was like "Yeah buddy, preach on". Then came the next thought: Then what. Site providers will still will want to know and this likely results in a browser detection excalation arms race pushed to JavaScript. I still think servers shouldn't get to know so much about browser clients, certainly not PII-level details (PII-level being the norm as it exists today).
- Hizonner 4y ago
  You can't stop fingerprinting. I wish you could, but you can't. But you CAN make it enough of a pain to cut down on the number of half-qualified Web monkeys who try to use the information in ham-handed ways. You can stop just handing the information over for free to people who might want to casually exploit you. You might even make it harder for some more sophisticated and/or committed actors to do it; for example, if I'm an ISP running a middlebox and trying to fingerprint all the traffic that runs through me, I can't use JavaScript. And you can save some bandwidth in the process.
- codetrotter 4y ago
  > Won't this likely result in browser detection to be pushed to JavaScript and create an arms escalation race? NoScript. https://noscript.net/ https://noscript.net/
  - heavyset_go 4y ago
    There are plenty of services that won't serve you data, neither web app nor data from API calls, if you aren't running a JS engine.
    - bee_rider 4y ago
      If they are important enough, add an exception.
      - heavyset_go 4y ago
        My point with my comment was addressing the GP's claim about fingerprinting being pushed to JavaScript in an arms race, which is what's happening and is something that NoScript can't really stop unless millions/billions of people start using it. NoScript is great, I use it, but isn't a solution to fingerprinting via JS if you actually want to talk to the servers that fingerprint that way.
  - IIsi50MHz 4y ago
    Can we presume a premise that having Javascript disabled is the dominant condition, and therefore does not make a browser stand out from the herd? What if having it disabled is true of only a small percentage of browsers?. If we assume that the user-agent string is set to whatever is "most common", and Javascript is disabled, are there no other identifiable bits of information? What about CSS fingerprinting? Perhaps the expected adversaries are not sufficiently motivated to try to sort somebody into a cohort based on lack of Javascript, and the remaining observable data? (But not saying NoScript has no uses.)
- MBCook 4y ago
  But that should happen. Does the user’s browser support WebDoodle2? Why try to parse a weird history of nonsense and combine that with a table of what versions of what browser supports what? Just check if document.doodle2 is defined. Done. Reliable. Easy. FF pretends to be Chrome pretends to be Safari pretends to be IE pretends to be Netscape pretends to be Mosaic pretends to be god only knows. Actually asking via JS instead of guessing is a massive improvement.
  - howinteresting 4y ago
    Problem is some versions of some browsers have bugs in some parts of doodle2, and the largest websites tend to care about things like that.
    - hsbauauvhabzb 4y ago
      Browser subversions were a problem in IE6 days, almost all modern browser usage is now on very recent browser versions.
    - MBCook 4y ago
      But you can make an API to expose the browser version. You don’t need to parse a cursed string.
- wyager 4y ago
  Good. I would rather incur costs for browser detection than make it easy.
- kevin_thibedeau 4y ago
  > results in a browser detection excalation arms race Countries should start enforcing their laws with regard to equal access for disabled users. Invoke hefty fines for denying service to people using assistive software that doesn't masquerade as a mainstream browser and the problem will disappear.
TheBrokenRail 4y ago
This. 100% this. We live in the 21st century and have proper APIs to detect features now, we should not be relying on parsing this user-agent string which is 90% legacy-garbage anyways. I mean, sites blocking compatible browsers is such a common problem that not only do user-agent switcher extensions exist, they're also some of the most popular extensions out there!
heavyset_go 4y ago
A side-effect of this will be web servers that won't allow scraping because your non-browser HTTP client won't have the same features that browsers have that also aid in profiling users for advertising. We're already at a point where scraping can be hard without a full-fledged JS engine, a move towards feature detection will mean that you're going to have to use a browser that servers can easily fingerprint for ad targeting if you want to scrape data. Chrome already deprecated UA strings 3 years ago. Google uses browser fingerprinting to detect if you're using Chrome so they can send you to working versions of their products, instead of the versions they send to other browsers that don't work as well. I can see browsers being excluded if they aren't of the 'blessed' variety that either follows Chrome's implementation, or if they don't have features that advertisers want that allow for easy user identification/tracking/fingerprinting/etc.
1vuio0pswjnm7 4y ago
By default, I do not send a UA header. Mind you I use a text-only browser so I am not concerned with "responsive design", which is arguably one legit use for the UA header. The number of sites or hosting providers^1 that actually require a UA header in order to retrieve a webpage, let alone require a specific UA string, is relatively small. IME, they will fit in a short text file.^2 From firsthand experience I know that thousands of sites, i.e., from amongst the ones submitted to HN, do not require it. I suspect the true number of sites that do not require a UA header on the www is in the hundreds of millions. IMO, this is yet another incredible "tech" company stunt that there is currently so much commercially-related reliance on what is truthfully an optional header, and one that routinely contains "fake", i.e., arbitrary, data. 1. Or "website building companies" such as Squarespace. 2. The localhost-bound forward proxy adds a UA header for those few sites automatically.
- judge2020 4y ago
  > so I am not concerned with "responsive design", which is arguably one legit use for the UA header. Responsive is specifically designed to work without client hints/detection, so you'd be good there anyways. Specific mobile-only versions of websites is what breaks, and a large part of that is (some?) Wordpress sites.
  - deleted 4y ago
    [deleted]
willnonya 4y ago
While I generally agree with you I bristtle at the "just do what chrome does" sentiment. Chrome and Google taken co trol of the standard in ways that generally aren't good for anyone.
- Xelynega 4y ago
  I don't think their suggestion was "just do what chrome does", it was "make your browser indistinguishable from chrome so that Google trying to create a seperate browser standard breaks websites for other browsers". If a website can't tell my browser apart from chrome, it can't attempt to support chrome-specitic features based on the user agent string.
deleted 4y ago
[deleted]
paranoidrobot 4y ago
I'm with you for the most part. Today, with modern browsers on almost all devices and relatively high memory, compute and bandwidth capabilities - for certain. However I can't agree with this: > The UA header never had any business existing to begin with. The early mobile web, and devices that were just too low-powered and/or low-bandwidth to support even early CSS/JS-based capabilities detection absolutely depended on server-side rendering to serve them mobile-HTML friendly sites. Yeah, it was terrible, it was painful and insane to manage - but was necessary.

metadat 4y ago

At first I was like "Yeah buddy, preach on". Then came the next thought: Then what. Site providers will still will want to know and this likely results in a browser detection excalation arms race pushed to JavaScript. I still think servers shouldn't get to know so much about browser clients, certainly not PII-level details (PII-level being the norm as it exists today).

Hizonner 4y ago
You can't stop fingerprinting. I wish you could, but you can't. But you CAN make it enough of a pain to cut down on the number of half-qualified Web monkeys who try to use the information in ham-handed ways. You can stop just handing the information over for free to people who might want to casually exploit you. You might even make it harder for some more sophisticated and/or committed actors to do it; for example, if I'm an ISP running a middlebox and trying to fingerprint all the traffic that runs through me, I can't use JavaScript. And you can save some bandwidth in the process.
codetrotter 4y ago
> Won't this likely result in browser detection to be pushed to JavaScript and create an arms escalation race? NoScript. https://noscript.net/ https://noscript.net/
- heavyset_go 4y ago
  There are plenty of services that won't serve you data, neither web app nor data from API calls, if you aren't running a JS engine.
  - bee_rider 4y ago
    If they are important enough, add an exception.
    - heavyset_go 4y ago
      My point with my comment was addressing the GP's claim about fingerprinting being pushed to JavaScript in an arms race, which is what's happening and is something that NoScript can't really stop unless millions/billions of people start using it. NoScript is great, I use it, but isn't a solution to fingerprinting via JS if you actually want to talk to the servers that fingerprint that way.
- IIsi50MHz 4y ago
  Can we presume a premise that having Javascript disabled is the dominant condition, and therefore does not make a browser stand out from the herd? What if having it disabled is true of only a small percentage of browsers?. If we assume that the user-agent string is set to whatever is "most common", and Javascript is disabled, are there no other identifiable bits of information? What about CSS fingerprinting? Perhaps the expected adversaries are not sufficiently motivated to try to sort somebody into a cohort based on lack of Javascript, and the remaining observable data? (But not saying NoScript has no uses.)
MBCook 4y ago
But that should happen. Does the user’s browser support WebDoodle2? Why try to parse a weird history of nonsense and combine that with a table of what versions of what browser supports what? Just check if document.doodle2 is defined. Done. Reliable. Easy. FF pretends to be Chrome pretends to be Safari pretends to be IE pretends to be Netscape pretends to be Mosaic pretends to be god only knows. Actually asking via JS instead of guessing is a massive improvement.
- howinteresting 4y ago
  Problem is some versions of some browsers have bugs in some parts of doodle2, and the largest websites tend to care about things like that.
  - hsbauauvhabzb 4y ago
    Browser subversions were a problem in IE6 days, almost all modern browser usage is now on very recent browser versions.
  - MBCook 4y ago
    But you can make an API to expose the browser version. You don’t need to parse a cursed string.
wyager 4y ago
Good. I would rather incur costs for browser detection than make it easy.
kevin_thibedeau 4y ago
> results in a browser detection excalation arms race Countries should start enforcing their laws with regard to equal access for disabled users. Invoke hefty fines for denying service to people using assistive software that doesn't masquerade as a mainstream browser and the problem will disappear.

TheBrokenRail 4y ago

This. 100% this. We live in the 21st century and have proper APIs to detect features now, we should not be relying on parsing this user-agent string which is 90% legacy-garbage anyways. I mean, sites blocking compatible browsers is such a common problem that not only do user-agent switcher extensions exist, they're also some of the most popular extensions out there!

heavyset_go 4y ago

A side-effect of this will be web servers that won't allow scraping because your non-browser HTTP client won't have the same features that browsers have that also aid in profiling users for advertising. We're already at a point where scraping can be hard without a full-fledged JS engine, a move towards feature detection will mean that you're going to have to use a browser that servers can easily fingerprint for ad targeting if you want to scrape data. Chrome already deprecated UA strings 3 years ago. Google uses browser fingerprinting to detect if you're using Chrome so they can send you to working versions of their products, instead of the versions they send to other browsers that don't work as well. I can see browsers being excluded if they aren't of the 'blessed' variety that either follows Chrome's implementation, or if they don't have features that advertisers want that allow for easy user identification/tracking/fingerprinting/etc.

1vuio0pswjnm7 4y ago

By default, I do not send a UA header. Mind you I use a text-only browser so I am not concerned with "responsive design", which is arguably one legit use for the UA header. The number of sites or hosting providers^1 that actually require a UA header in order to retrieve a webpage, let alone require a specific UA string, is relatively small. IME, they will fit in a short text file.^2 From firsthand experience I know that thousands of sites, i.e., from amongst the ones submitted to HN, do not require it. I suspect the true number of sites that do not require a UA header on the www is in the hundreds of millions. IMO, this is yet another incredible "tech" company stunt that there is currently so much commercially-related reliance on what is truthfully an optional header, and one that routinely contains "fake", i.e., arbitrary, data. 1. Or "website building companies" such as Squarespace. 2. The localhost-bound forward proxy adds a UA header for those few sites automatically.

judge2020 4y ago
> so I am not concerned with "responsive design", which is arguably one legit use for the UA header. Responsive is specifically designed to work without client hints/detection, so you'd be good there anyways. Specific mobile-only versions of websites is what breaks, and a large part of that is (some?) Wordpress sites.
- deleted 4y ago
  [deleted]

willnonya 4y ago

While I generally agree with you I bristtle at the "just do what chrome does" sentiment. Chrome and Google taken co trol of the standard in ways that generally aren't good for anyone.

Xelynega 4y ago
I don't think their suggestion was "just do what chrome does", it was "make your browser indistinguishable from chrome so that Google trying to create a seperate browser standard breaks websites for other browsers". If a website can't tell my browser apart from chrome, it can't attempt to support chrome-specitic features based on the user agent string.

deleted 4y ago

[deleted]

paranoidrobot 4y ago

I'm with you for the most part. Today, with modern browsers on almost all devices and relatively high memory, compute and bandwidth capabilities - for certain. However I can't agree with this: > The UA header never had any business existing to begin with. The early mobile web, and devices that were just too low-powered and/or low-bandwidth to support even early CSS/JS-based capabilities detection absolutely depended on server-side rendering to serve them mobile-HTML friendly sites. Yeah, it was terrible, it was painful and insane to manage - but was necessary.