Considering recent chrome, firefox user agent contains id string of almost every browser in existence, this is so true:

Mozilla/5.0 (...) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

You just wait for Edge-based-on-Chromium's User-Agent :D

Per a buddy who is using said Edgium (Chromium-based Edge): https://i.imgur.com/p6ZMoJY.png

Oh ffs

Edg?

I assume real live websites are detecting "Edge/" and applying workarounds for the old rendering engine.

Like the maybe-not-actually-true reason why "Windows 9" was skipped and we got 10 instead?

It was too edgy for them.

I vote we change all user agents to just "curl".

“Apache” would be ironic.

Might as well save 3 bytes and just call use “c”.

Well, the next best thing is what webkit is doing (https://webkit.org/blog/8042/release-notes-for-safari-techno...) by freezing the user agent.

So as time goes by the user agent becomes increasingly homogenous and so, less useful for tracking.

I believe this change was rolled back, since my User Agent is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.2 Safari/605.1.15".

Rubbish. They are incredibly useful for debugging.

They would be a lot more useful if they were more straighforward and honest.

Just give me "Chrome 68" instead of "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36"

firefox has a sane user agent. mine is:

>Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

edit: sorry, accidentally submitted early

So what. Removing one of the largest sources entropy available for fingerprinting users is important. We shouldn't maintain the terrible long-term effects[1] of tracking everything just to help you have an easier time debugging.

[1] http://nymag.com/intelligencer/2019/02/shoshana-zuboff-q-and...

Does it really provide that much entropy? Maybe back in the days when browsers didn’t auto-update, but intuitively it should only provide about four bits at most (os: Android iOS macOS windows, browser: chrome safari edge ie ff) except for a few rare users who don’t stay up to date or choose a weird browser (and those folks probably are a little confused about how privacy works).

ohhhhh you betcha.

https://amiunique.org/

i ran this on my work laptop (windows 10 / firefox - mostly default settings). the "details" tab shows a full breakdown of each fingerprinting component with a "similarity ratio" (percentage of fingerprints that share the same value).

every entry is 20% or greater, most of them around 50% except for timezone (4%), canvas (1%), and user agent (0.12%).

so, yeah, user agents are still the largest source of entropy by a wide margin for fingerprinting scripts.

I suspect this is just stale data. I can’t think why the most recent version of a browser would put me at one in a thousand.

There are better solutions available than hanging functionality on unreliable vestigial bits and pieces that shouldn't be there anyway which, because others abuse the functionality, you can't trust to be correct for debugging purposes.

99% of the traffic has the correct user-agent which is useful in tracking down issues that are browser specific. The other 1% will just get ignored as noise. And it's not like we can't tell what type of browser they are using with browser specific objects that we can pull from javascript. We just can't infer the version of the browser which is critical for debugging issues.

I use a randomized user agent and every once in a while get rejected by a site that has decided my browser can't be supported. Usually when I'm on some Safari version. I doubt much effort is being done to identify fake user agents since there are better fruit to pick in the fingerprinting game.

That might be true, although you don't list the solutions, but it doesn't refute my point in any case.

Per https://webkit.org/blog/8042/release-notes-for-safari-techno... the user agent is frozen in webkit now.

You're writing your websites wrong.

I've had to debug around a short-lived bug in the Firefox rendering engine that only showed up in the FF rendering engine before. The site itself? Standards-compliant; there was flexibility in the standard (ironically, for flexboxes ;) ) about performance constraints and our site just fell down Gecko's slowness tree and hit every branch on the way.

Given the engines are allowed to vary, this experience is inevitable from time to time. The user-agent is really valuable in helping us figure out when that's what we're seeing.

If there’s a way to write them without the occasional browser-specific bug, I’d sure like to know what it is.

They help you figure out if a user agent wants a mobile view of a page without Javascript... which is pretty useful.

We don't need user agents for that. There's an easy way to tell whether a visitor wants a cleaner view of a page, without Javascript: Yes.

I said "mobile", not "cleaner". Sizes and aspect ratios are different on phones than PCs.

> I said "mobile", not "cleaner". Sizes and aspect ratios are different on phones than PCs.

User agent doesn't tell you size or aspect ratio.

Even if you know I'm running Chrome on Android on a Galaxy Note 8, you don't know the size (physical or pixel) or aspect ratio of the viewport, because: (1) I may or may not be viewing in side by side windows, (2) the screen can be in any of three resolutions, (3) the screen can be portrait or landscape, (4) the browser may or may not be set to use the full space on the long dimension of the screen.

OTOH, CSS Media Queries answer these questions.

Not necessarily. Websites should use CSS media queries to work at all aspect ratios and sizes without needing server-side code or JavaScript.

the could be accomplished just by having User-Agent: mobile, all the other data in the user-agent are useless for this purpose.

There is presumably some way, at least hypothetically, to fix the mess that User-Agent has become. (Everybody is 'Mozilla' now! And yet somehow a unique snowflake 'Mozilla' that lets you be tracked...)

But it's not quite that. It's not that a device is "mobile" instead of "stationary" that matters. It's maybe that it's a touch screen. It's maybe that it's a small screen. (With an especially uneven aspect ratio?) Maybe that it's handheld. It's maybe the combination of all of those things. But it's not really that it's "mobile" exactly. And there are, and possibly will be increasing proportions of, devices that have some but not all of these qualities we package together in our brains as 'typical mobile'

All of those small differences of mobile devices are better served by media queries I personally think. You could replace "mobile" in my example by "small-screen" if you prefer.

Agreed. Media queries need to be improved though. There are no good media queries to detect "touch screen" and/or "no keyboard or mouse/pointer, only touch screen", only JS hacks that attempt it. This can matter. But yes, improving media query (or input method query?) APIs for both CSS and JS is, I agree, the correct solution to User-Agent madness. It's just not entirely straightforward or obvious or easy, and as always getting all browsers on the same page is an issue.

Well at least we acknowledged there's some utility.

Now consider that mobile devices are different as well..

The current user agent does not give you much insight about what type of mobile device you have anyway, especially on Android.

I use Firefox for Android on ChromeOS -- it produces interesting results.

I have been having a shitty day and your comments in this article have honestly cheered me up a bit. Thank you!

<3

So instead of sending a user agent, send only the page ratio!!

This is not too helpful -- you can resize the window in such a way that the ratio changes...

Send the screen resolution

For which screens ? Why would that be helpful in any case, given the browser window is not the size of any of the screens ? I'm not sure what you would gain from getting this information.

I think CSS is probably good enough that we can live without UA sniffing for this.

We sometimes render different HTML to handle browser and device behavioural variations, including FOUT-management variations in how they load assets that therefore can't be handled in JS even if we wanted to. Historically we also redirected to a pure HTML/CSS version of our tools when IE9 or earlier was detected.

I'm pretty sure deleting User agents field will introduce another non-standard X-prefixed header.

That is not correct. They also serve to exclude users of browsers you dont know or like.