8 ms·

This is a good idea, and is something I've thought of for a while; the user agent header was a mistake from both a privacy and a UX perspective. Ideally, web b

This is a good idea, and is something I've thought of for a while; the user agent header was a mistake from both a privacy and a UX perspective. Ideally, web browsers should attempt to treat the content the same no matter what device you are on. There shouldn't be an iOS-web, and a Chrome-web, and a Firefox-web, and an Edge-web; there should just be the web. In which case, a user-agent string that contains the browser and even the OS only encourages differences between browsers. Adding differences to your browser engine shouldn't be considered safe. Beyond that, the user agent is often a lie to trick servers into not discriminating against certain browsers or OSes. Enough variability is added to the user-agent string that a server can't reliably discriminate, but it still remains useful for some purposes in JavaScript and as a fingerprint for tracking. Which brings me to privacy. It's not as if there aren't other ways to try and fingerprint a browser, but the user agent is a big mistake for privacy. It'd be one thing if the user-agent just said "Safari" or "Firefox", but there's a lot more information in it beyond that. If the web should be the same web everywhere, then the privacy trade-off doesn't make much sense.

ldoughty 7y ago
I agree, but this also is incredibly dependent on the major players (e.g. Google) not going off on their own making changes without agreement from other browsers... There are still issues today where chrome, edge, and Firefox render slightly differently. I certainly agree user agent isn't terribly necessary, but it's literally the only hook to identify when css or JavaScript needs to change... Or to support people on older browsers (e.g. Firefox ESR). How can I know when I can update my website to newer language versions without metrics confirming my users support the new ES version? I would argue simplifying the UA, product + major revision, maybe, or information relevant to rendering and JavaScript only
- _bxg1 7y ago
  Thinking cynically, it could be a power-move by Google to strengthen their hold on the ecosystem. Right now when they go out and make their own API changes without consensus (which already happens), it's possible to distinguish the "for Chrome" case and still support the standard. But if there were no User-Agent, and Google wanted to strongarm the whole group into something, and 90% of browsers are Chromium-based, devs will likely just support the Chromium version and everyone else will have no choice but to fall in line.
  - jaywalk 7y ago
    I think it's perfectly fair to lean towards cynicism whenever Google goes out on their own making changes to Chrome.
  - ldng 7y ago
    You mean, like SPDY/HTTP2 ?
    - klodolph 7y ago
      As far as I can tell, HTTP/2 is such a major improvement that no strong-arming is necessary. Speaking as a consumer of the web, as an individual who runs their own website, and at a developer working at a company with a major web presence. The web suffers a ton from the “red queen” rule in so many different ways anyway—you have to do a lot of work just to stay in the same place.
      - ldng 7y ago
        But, is it really such an improvement ? Or is it just an improvement for Cloud provider that keep pushing the Kool-Aid ? I still see a lot of contradicting benchmark and, apart from some Google Apps, personnally, I have not seen a lot of sites actually really leveraging HTTP2 (including push). But maybe you did put and leverage HTTP2 on your own website ? At your company ? Did you use push ? Do you use it with CDN ?
        klodolph 7y ago
        > But, is it really such an improvement? Yes, unequivocally. It’s amazing, even without push. The websites that use it are faster, and the development process for making apps or sites that load quickly is much more sane. You don’t have to resort to the kind of weird trickery that pervades HTTP/1 apps. > Or is it just an improvement for Cloud provider that keep pushing the Kool-Aid ? I don’t see how that makes any sense at all. Could you explain that? > But maybe you did put and leverage HTTP2 on your own website ? At your company ? Did you use push ? Do you use it with CDN ? From my parent comment, > Speaking as a consumer of the web, as an individual who runs their own website, and at a developer working at a company with a major web presence. My personal web site uses HTTP/2. It serves a combination of static pages and web apps. No push. HTTP/2 was almost zero effort to set up, and instantly improved performance. With HTTP/2, I’ve changed the way I develop web apps, for the better. My employer’s website uses every technique under the sun, including push and CDNs.
- ryandrake 7y ago
  Maybe web publishers need to let go of this idea of pixel-perfect rendering and identical JavaScript behavior across browsers, and instead just worry about publishing good content. The web is not Adobe InDesign or Photoshop. At its essence it is a system for publishing text and hyperlinks that point to other content. Get the content right and don't worry so much about whether the scrollbar is 2 pixels thick or 3.
  - KarlKemp 7y ago
    I, too, remember how this opinion was repeated as nauseam about a decade ago. It didn’t make much sense then, and even less now. Nobody today expects identical rendering: people are used to responsive websites, native widgets etc. The problem people are actually experiencing (far less now than in the past) were more serious, such as z-axis ordering differences resulting in backgrounds obscuring content. For JavaScript, I struggle with how non-“identical behavior” would express itself, except as a blank page and a small red icon in devtools.
nerdponx 7y ago
I don't know. If I'm connecting to a site with Lynx, I sure as heck don't want them to try to serve me some skeleton HTML that will be filled in with JS. Because my browser doesn't support JS, or only supports a subset of it. User Agent being a completely free form field is the real mistake IMO. Having something more structured, like Perl's "use" directive, might have been better.
- rocky1138 7y ago
  The problem with services using the user-agent to determine whether or not to allow a client access to a resource outweighs any benefit. I'm in the "it was a mistake to include this in the spec" camp.
varelaz 7y ago
That just makes things harder for those who wants this information. Still you can fingerprint browser by features and API support, but it requires javascript now and up to date library with recent features support check. I mean that it doesn't prevent obtaining this information, it's still available for big players who has big data
tempestn 7y ago
One problem with this is that browsers don't behave the same. For example, iOS Safari prevents multiple pop-up windows to be opened by a single user interaction. Each one requires clicking back to the original page and allowing the popup. Now you might say, "Why would you ever want to do that?" But there are always going to be edge cases—in this case it's an integral part of one of the features of autotempest.com. But that's just one example. And the only way we can detect whether that behaviour is going to be blocked is by checking the UA. I can understand why this is a good thing for privacy. Like many things to do with security on the web though, it's just a shame that bad actors have to ruin so many things for legitimate uses. (The recent story on Safari local storage being another example of that...)

ldoughty 7y ago

I agree, but this also is incredibly dependent on the major players (e.g. Google) not going off on their own making changes without agreement from other browsers... There are still issues today where chrome, edge, and Firefox render slightly differently. I certainly agree user agent isn't terribly necessary, but it's literally the only hook to identify when css or JavaScript needs to change... Or to support people on older browsers (e.g. Firefox ESR). How can I know when I can update my website to newer language versions without metrics confirming my users support the new ES version? I would argue simplifying the UA, product + major revision, maybe, or information relevant to rendering and JavaScript only

_bxg1 7y ago
Thinking cynically, it could be a power-move by Google to strengthen their hold on the ecosystem. Right now when they go out and make their own API changes without consensus (which already happens), it's possible to distinguish the "for Chrome" case and still support the standard. But if there were no User-Agent, and Google wanted to strongarm the whole group into something, and 90% of browsers are Chromium-based, devs will likely just support the Chromium version and everyone else will have no choice but to fall in line.
- jaywalk 7y ago
  I think it's perfectly fair to lean towards cynicism whenever Google goes out on their own making changes to Chrome.
- ldng 7y ago
  You mean, like SPDY/HTTP2 ?
  - klodolph 7y ago
    As far as I can tell, HTTP/2 is such a major improvement that no strong-arming is necessary. Speaking as a consumer of the web, as an individual who runs their own website, and at a developer working at a company with a major web presence. The web suffers a ton from the “red queen” rule in so many different ways anyway—you have to do a lot of work just to stay in the same place.
    - ldng 7y ago
      But, is it really such an improvement ? Or is it just an improvement for Cloud provider that keep pushing the Kool-Aid ? I still see a lot of contradicting benchmark and, apart from some Google Apps, personnally, I have not seen a lot of sites actually really leveraging HTTP2 (including push). But maybe you did put and leverage HTTP2 on your own website ? At your company ? Did you use push ? Do you use it with CDN ?
      - klodolph 7y ago
        > But, is it really such an improvement? Yes, unequivocally. It’s amazing, even without push. The websites that use it are faster, and the development process for making apps or sites that load quickly is much more sane. You don’t have to resort to the kind of weird trickery that pervades HTTP/1 apps. > Or is it just an improvement for Cloud provider that keep pushing the Kool-Aid ? I don’t see how that makes any sense at all. Could you explain that? > But maybe you did put and leverage HTTP2 on your own website ? At your company ? Did you use push ? Do you use it with CDN ? From my parent comment, > Speaking as a consumer of the web, as an individual who runs their own website, and at a developer working at a company with a major web presence. My personal web site uses HTTP/2. It serves a combination of static pages and web apps. No push. HTTP/2 was almost zero effort to set up, and instantly improved performance. With HTTP/2, I’ve changed the way I develop web apps, for the better. My employer’s website uses every technique under the sun, including push and CDNs.
ryandrake 7y ago
Maybe web publishers need to let go of this idea of pixel-perfect rendering and identical JavaScript behavior across browsers, and instead just worry about publishing good content. The web is not Adobe InDesign or Photoshop. At its essence it is a system for publishing text and hyperlinks that point to other content. Get the content right and don't worry so much about whether the scrollbar is 2 pixels thick or 3.
- KarlKemp 7y ago
  I, too, remember how this opinion was repeated as nauseam about a decade ago. It didn’t make much sense then, and even less now. Nobody today expects identical rendering: people are used to responsive websites, native widgets etc. The problem people are actually experiencing (far less now than in the past) were more serious, such as z-axis ordering differences resulting in backgrounds obscuring content. For JavaScript, I struggle with how non-“identical behavior” would express itself, except as a blank page and a small red icon in devtools.

nerdponx 7y ago

I don't know. If I'm connecting to a site with Lynx, I sure as heck don't want them to try to serve me some skeleton HTML that will be filled in with JS. Because my browser doesn't support JS, or only supports a subset of it. User Agent being a completely free form field is the real mistake IMO. Having something more structured, like Perl's "use" directive, might have been better.

rocky1138 7y ago
The problem with services using the user-agent to determine whether or not to allow a client access to a resource outweighs any benefit. I'm in the "it was a mistake to include this in the spec" camp.

varelaz 7y ago

That just makes things harder for those who wants this information. Still you can fingerprint browser by features and API support, but it requires javascript now and up to date library with recent features support check. I mean that it doesn't prevent obtaining this information, it's still available for big players who has big data

tempestn 7y ago

One problem with this is that browsers don't behave the same. For example, iOS Safari prevents multiple pop-up windows to be opened by a single user interaction. Each one requires clicking back to the original page and allowing the popup. Now you might say, "Why would you ever want to do that?" But there are always going to be edge cases—in this case it's an integral part of one of the features of autotempest.com. But that's just one example. And the only way we can detect whether that behaviour is going to be blocked is by checking the UA. I can understand why this is a good thing for privacy. Like many things to do with security on the web though, it's just a shame that bad actors have to ruin so many things for legitimate uses. (The recent story on Safari local storage being another example of that...)