
User Agent Changes - CrazedGeek
https://vivaldi.com/blog/user-agent-changes/
======
pornel
Congratulations Google, you did it! You killed the User-Agent header.

The HTML spec already requires all browsers to report themselves as Netscape
in the Netscape-era `navigator` object:

    
    
            appCodeName - Must return the string "Mozilla".
            appName - Must return the string "Netscape".
            product - Must return the string "Gecko".
    

So a few more "oopses" from Google products and the next spec will end up
saying:

    
    
           User-Agent - Must be equal to the string "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.79"

~~~
stickfigure
_the next spec will end up saying...Must be equal to the string..._

This is exactly the right way to solve the problem. The UA header isn't going
away because of Legacy. Pin it to an arbitrary generally accepted value and be
done with it. The best part about this is that any client-side developer can
implement this solution unilaterally... and Vivaldi now has.

~~~
stephenr
Assuming that the problem here is people doing UA sniffing, the problem, like
with people doing glue sniffing, is to stop people sniffing the UA (or glue) -
not to make the UA (or glue) unusable for it's intended purpose.

Have you ever used a service that shows things like your active sessions,
login attempts etc? Notice how they basically all show you what kind of device
and usually what browser the session/login is from, with a date time and
usually location?

If everyone pretends to be Chrome what's the fucking point any more? "You
logged in from Chrome on Tuesday the 3rd at 8am". "Well no I fucking didn't, I
guess I better go reset my damn passwords again".

~~~
denormalfloat
There are wrong reasons to sniff the UA string, and less wrong reasons. If a
Browser has a bug that gets fixed in later versions, sites have to sniff the
UA string to do the right thing. For example, a browser bug may cause people
to see an error, and the they are using an old version of the browser. The
right thing to do is to upgrade, but how to tell? When you are subject to the
bugs of some other code, and which are skewed across different versions of the
software, the most reasonable way to work around it is by UA sniffing.

~~~
zeta0134
I would have bought this argument a decade ago, but at this stage the number
of site users not doing some form of automatic updates on their browser should
be in the minority. The problems user agents were designed to solve back in
the Netscape Navigator days have since been standardized using much better
signals, and the odd standards compliance bug here and there isn't really
justification for something as weak and unreliable as a user agent string.

I say kill it. Fix it to some static value and require new sites moving
forward to do proper feature detection if they really care to work around
standards bugs or use experimental new features.

~~~
dgoldstein0
The core web features don't have such bugs anymore for all practical purposes,
but newer apis do. Content security policy in particular has a lot of bugs
especially around features in v2 and v3 of the spec, when they were first
implemented in chrome / Firefox often took a few major versions to get right.
I think I've seen similar hacks around use of newer crypto apis. The
alternative is to wait 2-3 years between the release of a new api by all major
browsers and actually using it.

~~~
Zarel
Sadly, feature detection is still impossible for many features.

For instance, the only way to detect `contentEditable` support is through
user-agent sniffing. Many versions of Android Chrome and iOS Safari will
happily report that they support `contentEditable` and then refuse to make the
content editable.

I'm actually struggling with a similar issue right now: there's no way to
detect an on-screen keyboard, so there's no way to focus a textbox only if it
wouldn't cover up the screen with an on-screen keyboard (which is pretty
important for chat apps). The best you can do involves a lot of hacks,
including UA sniffing.

~~~
dgoldstein0
Ouch. Wasn't aware of those. But still not surprised there are edge cases out
there.

If I look hard enough, I can always find places where different browser
behaviors differ. For instance, I once discovered that the maximum top value I
could put a position absolute div within a position relative div was around 20
million px in chrome but only 1.53 million in IE (if my memory serves). This
was at least fixable by stacking multiple divs for every 1.5 million pixels I
wanted to lay out.

But for every quirk like this that's possible to work around by coding to the
lowest common denominator, there's another somewhere that you just can't. I
recall doing another project which involved trying to pop open a mobile app to
view content; and it was supposed to switch to the store to prompt you to
install if you didn't have the app. At the time this involved different hacks
for iOS Safari and Android chrome. Behaviors that differed included what
happened when you navigate to a scheme with no handler (in chrome, the
previous page kept running), and whether the scheme could trigger the app from
an iframe (which was blocked in chrome but not Safari iirc). And handing off
state to the app during the install flow was simple on Android, but on iOS
required another pile of hacks. Whole thing ended up an overcomplicated mess,
but we ended up pretty good ux for the intended flows. This was 2014 so the
situation is probably better today - I think iOS Safari added some meta tags
that are targeted to very similar use cases.

~~~
NieDzejkob
If you don't mind me asking, why are you dealing with million-pixel distances?
What problems do they solve?

~~~
chrismorgan
Probably the most common use case for such things is progressively-
rendered/-loaded lists, where you know the number of items and the height of
each item in the list, so that you can reserve all the space and provide a
meaningful scrollbar, and have a limited number of children absolutely
positioned on screen at any given time.

This gives a _far_ better experience than infinite scrolling (which has no
meaningful scrollbar, so you can’t jump to the end or an arbitrary point in
the middle) or pagination (which is just generally painful once you want
something not at the start).

We do this in Fastmail’s webmail, and have put in workarounds for overly-tall
elements breaking browsers.
[https://github.com/fastmail/overture/blob/41cdf36f3e7c8f0dd1...](https://github.com/fastmail/overture/blob/41cdf36f3e7c8f0dd1ba37eecf4a475250ce4b15/source/views/collections/ListView.js#L120-L138)
lists them, including some values at which things break. (Actually, IE doesn’t
allow containers anywhere near that tall, capping effective values much
earlier, with the consequence that you can’t access things near the end of the
list. But the problem was that once you get much larger still, it starts
ignoring the values you specify altogether, which would break the entire
technique.)

For us, the most common height of each email’s entry in the list is 51px; at
that, 400,000 emails is enough to get to 20,400,000px high, which is enough to
break both IE and Firefox (not sure about Chrome or Safari, I’ve never
actually tested it; their failure mode may well just be different, limiting
numbers instead of ignoring them).

400,000 emails in a mailbox isn’t all that common, but it does happen.

------
cowmoo728
Can we take a moment to appreciate how obtuse UA strings are? I mean really,
the user agent

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/78.0.3904.99 Safari/537.36 Vivaldi/2.9.1705.41

is almost laughable for a strange collection of historical reasons. The
history of UA strings has come up before here:

[https://news.ycombinator.com/item?id=16525559](https://news.ycombinator.com/item?id=16525559)

When is a browser going to just ditch the cruft and present something
sensible?

~~~
JoshTriplett
I wonder if it'd be too late for http/3 to say "user-agent is deprecated,
user-agents should not send it, any server accepting http/3 may assume the
following compatibility value for the header without it being sent".

Was anything like that considered during the http/3 design process?

(I saw the linked "client hints" proposal in the article, but that doesn't
mention the idea of completely dropping the header from client requests and
assuming a certain baseline value for http/3.)

~~~
toast0
User-Agent for browsers is pretty much useless now, but it's still a pretty
useful name for a header if you want to put real information in it. Ex, if
you're calling an api, it's nice to have a version number and a name/contact
so broken things can be fixed.

I don't remember if HTTP/2 (and presumably /3) has a initial dictionary for
header compression, they could have a suggested value in there, so if you want
to look like a browser, you can use that at a low byte cost.

~~~
edoceo
I make an API, for narrow use case. All calls have to be from a registered UA,
among other things forms the HMAC sig.

~~~
neikos
This sounds like authentication with extra steps? Why not just send a bearer
token?

~~~
edoceo
We do. Header is for message signing. And UA has to be registered, part of the
spec provided by client.

------
chrisweekly
No mention of the UA string would be complete without this 2008 gem, one of my
all-time favorite bits of geek lore / culture:

[https://webaim.org/blog/user-agent-string-
history/](https://webaim.org/blog/user-agent-string-history/)

------
chrismmay
I have seen a few cases where users complain that our mobile app (which runs
in a webview inside a native app) doesn't work for them. When we look in the
server logs, we find a user agent string that indicates a user is running iOS
11.4.1. My theory is that the older version indicates that the client's mobile
device has run out of storage space. The device can't download the update to
iOS 13.x since there is insufficient storage available on the device.

Even if the user frees-up some space on their device, not enough to upgrade to
iOS 13.x, but enough to run our app theoretically, our app still fails to run
for them. Uninstalling and reinstalling the native app that contains the
webview that runs our web app doesn't solve the problem either. My theory is
that there are truncated versions of some of our javascript files left over
from when the device ran out of storage that don't get re-downloaded even when
storage is later made available....

I've been telling people to free-up space on their device and upgrade it to
iOS 13 to fix the problem. I sure hope that works...

If all user agents become a fixed string, how on god's green earth will we
troubleshoot problems reported by users? I sure hope we get another header
that will tell us the real client platform information so we can eventually
repeat this exercise after another few years...

This scenario is complicated, but my point is really that of course we need a
User Agent to accurately tell what platform the client is running for entirely
legitimate reasons and mega corporations should not do patently evil things to
make the lives of developers and support people even more frustrating than
they already are. There should be laws against things like this. It really is
fraud to change something like the User Agent string to a constant value that
is incorrect, and it WILL lead to damaging events in real people's lives if it
happens. People could be fired for being led down the wrong investigative path
when troubleshooting problems. From the article, it sounds like significant
damage has already been done.

~~~
skrebbel
I don't understand, why don't you "just" try to support ios 11?

~~~
jsnell
You've totally misunderstood the OP's story.

Their app does not have any kind of dependency on iOS 13 and should work on
iOS 11. It's just that there's a correlation between an iOS 11 UA and the app
not working. The hypothesis is that there is something wrong with some devices
that both a) caused them to not be upgraded, b) causes their app to fail.

This kind of misreading is a prime example of just how toxic any discussions
about version number detection are. Rather than give the OP any benefit of the
doubt and maybe re-read what they wrote, you've just decided they must be
incompetent or lazy and castigate them over it.

~~~
skrebbel
Oh come on.

I even began my sentence stating that I didn't understand. What more do you
want? I was genuinely interested, there's no need to snark. The only thing
that's toxic in this thread is your comment.

If we're going to begin by assuming that things like "I don't understand" are
meaningless hollow phrases that trolls tack on comments just to snark more
effectively, then the end is that we simply can't communicate online anymore.
Please don't push in that direction, it's not the solution.

> you've just decided they must be incompetent or lazy and castigate them over
> it.

I did no such thing and I'm genuinely angry at you for suggesting it.

------
boring_twenties
I'm surprised Slack isn't on the list, it refuses to work with Waterfox at
least (which only appends its name to the Firefox user agent it's based on),
and presents a stupid and condescending lecture about why it's for your own
good, to boot.

------
Scoundreller
Heh, I remember my university wouldn’t let you login to wifi without having
their site-licensed anti-malware software.

So I changed my UA to a Mac and got online without it.

------
fouc
Does anyone think that User Agent should be killed off?

If we had no way of detecting between browsers that would lead to a much more
consistent cross-browser experience in the long run and not allow one
browser's dominance to affect the internet experience for the rest.

~~~
thayne
It also removes some legitimate use cases including:

\- identifying active sessions

\- working around bugs in specific versions of a browser/os

\- changing UI to match the native experience of a user

\- seeing percentage of users using different browsers (which is important to
know if you can use new features in web apis)

\- etc.

~~~
forgotmypwd123
Web pages should not work around browser bugs, its like a linux distro working
around kernel bugs. Just fucking fix it.

~~~
namibj
Yeah, it's called polyfills. It's bloat when not needed.

------
Tepix
I think they went exactly in the wrong direction. Given that they have a very
small market share it is understandable.

However, what if the latest Firefox or Chrome would just have a user string
"Chrome/80.0 (Windows 10; Win64; x64)"?

And if you run into a problem you get a button that reverts to the old
horrible piece of junk.

Now that robots.txt is established and security.txt is almost there, the next
thing we need is a contact.txt that browsers can use to offer a button that
will allow sending bug reports to webmasters without having to search the site
for the contact address.

~~~
onreact
Nah, just prevent dominant corporations like Google to use anti-competitive
blocking or redirecting measures.

Vivaldi has to mimic Chrome because otherwise Google throws errors.

It's not that Google is unaware that there are browsers or that Vivaldi is not
Chrome.

------
bambax
> _Every other site will get a User Agent that appears to be identical to
> Chrome. There is a downside for us in doing this since Vivaldi will
> effectively disappear from third party rankings of browser popularity (we
> will be indistinguishable from Chrome) but that is a price we will happily
> pay to provide the best website compatibility for our users._

Why not choose a FF UA string then? At least they would be doing the world a
favor!!

~~~
tsukurimashou
Well they didn't say it clearly but they chose chrome because a lot of people
use google products, and their browser will work best if they pretend to be
chrome, it is that simple. Firefox has the same issues they describe in the
article, google throttle perfs and break things on purpose for Firefox (gmail
features, youtube features, maps, etc...).

------
ravenstine
The user-agent header was a huge mistake.

~~~
stephenr
Not at all.

Being able to vaguely confirm the type of device someone uses can help in
basic troubleshooting (particularly related to e.g. noticing unauthorised
account access).

Using the user agent string to identify web technology compatibility was and
is a huge mistake.

------
3xblah
Comments here on User-Agent fail to mention how browsers can be distinguished
by the headers they send and the ordering of those headers. For example, the
User-Agent header might be the 9th header in a Chrome browser while in a
Firefox browser it might be the 2nd header. By default, neither Chrome nor
Firefox may send exactly the same number of headers.

------
bullen
User-Agent should be able to be set by the page following the spec. there is a
chromium bug since 2015 that covers it but Google doesn't care:

[https://bugs.chromium.org/p/chromium/issues/detail?id=571722](https://bugs.chromium.org/p/chromium/issues/detail?id=571722)

which is blocked by

[https://bugs.chromium.org/p/chromium/issues/detail?id=595993](https://bugs.chromium.org/p/chromium/issues/detail?id=595993)

which is blocked by

[https://bugs.chromium.org/p/chromium/issues/detail?id=963260](https://bugs.chromium.org/p/chromium/issues/detail?id=963260)

~~~
Thorrez
Fixing that won't help any of the problems listed in the post.

Also it wouldn't set the User-Agent on top level page loads, just on
XHRs/fetches.

~~~
bullen
True, but it's more important since XHR/Fetch can be used for real-time data!

~~~
Thorrez
I don't understand why real-time data is more important than the initial page
load.

XHR/Fetch can only read data from the same origin (unless there are CORS
headers allowing cross-origin). AIUI, since it's generally the same origin,
there generally shouldn't be any User-Agent problems, because the team making
the calls is the same team controlling the server-side code. So spoofing a
different User-Agent for compatibility shouldn't be necessary.

~~~
bullen
Because if you use HTTP for real-time stuff and you make say 10 requests per
second and you can't remove the User-Agent header which is like 100+ bytes
long that makes for a lot of bytes per month (if you have 1000 users):

"Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/74.0.3729.169 Safari/537.36"

114x10x60x60x24x30x1000 = 3TB/month

Edit: but now that I checked ingress data is free on all cloud operators!
What?

------
Aloha
This is more of an asking the assembled a question.. why should I use vivaldi?

~~~
recursivecaveat
I've been a Vivaldi user for over a year now. Mostly I just prefer the UI. You
have a lot of options, especially compared to Chrome's almost zero. In
particular I like to have the tabs stacked vertically along the side, so
they're more manageable in quantity. Otherwise, its just Chromium, so my only
complaint is the tendency for sites to nag/scare you about using an 'outdated'
browser. Occasionally Youtube will temporarily break their UI in some minor,
Vivaldi-only way, but otherwise I've never been blocked or had a functional
problem with a site.

~~~
alwillis
I love the UI/UX of Vivaldi.

I use Brave a lot when I'm using a Chromium-based browser; perhaps when the
SDK comes out, Vivaldi will integrate BAT [1]. It would also be nice if
Vivaldi got Brave's features like built-in Tor and IPFS.

[1]: [https://www.cnet.com/news/braves-privacy-focused-ads-to-
spre...](https://www.cnet.com/news/braves-privacy-focused-ads-to-spread-
beyond-startups-own-browser/)

------
Dolores12
That is so bad idea. Why choose Chrome? Let it be Firefox? Web analytics will
show even higher numbers for Chrome, hence developers would not bother to test
anywhere but in Chrome.

~~~
fantyoon
Pretty sure Google is already attacking Firefox in the same way. I remember
having to change my User-Agent to Chrome on Firefox mobil because a bunch of
Google sites where broken otherwise (but worked perfectly fine when thinking
that I was using Chrome).

If your only goal is compatibility and thats the only thing you care about,
using Chrome is the choice.

------
dredmorbius
Everybody lies:

[https://noti.st/nielsleenheer/73y43P/slides](https://noti.st/nielsleenheer/73y43P/slides)

------
thrower123
This is indicative of the kind of world where we had to jump from Window 8 to
Windows 10 because of shitty user-agent parsing .

------
agluszak
Oh, these sweet monopolistic practices...

------
dethos
Good move. Other browsers should follow.

------
tyingq
I wonder if they debated whether to imitate Safari or Mozilla or Edge instead.

~~~
zlsa
Vivaldi is based on Chromium, so it's best to imitate the same engine.

* Yes, I know that Edge is now based on Chromium. But given the two, it's better to pretend to be your parent browser, rather than a sibling.

------
dependenttypes
The question is, why ever use a unique user agent?

