User Agent Changes | Hacker News Reader

User Agent Changes

vivaldi.com

159 pointsCrazedGeek106 comments

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"

For reference, https://html.spec.whatwg.org/multipage/system-state.html#cli.... Browsers are essentially required to pretend to be Firefox from 2010, or Chrome from 2003 (!), or Safari from 2003—all while pretending to be Firefox or its predecessor in a couple of other ways. I find it very amusing.

Some context: 20030107 is Safari's first public release date.

Chrome didn't exist in 2003. The year 2003 is because Safari existed then, but Google forked WebKit later on.

this reads like an April 1st spec, "The taintEnabled() method must return false" - hur hur hur.

Interesting perspective; one could argue that the creators of non-web-standards-compliant browsers are really to blame here, forcing webdevs to branch / gate so often on the UA header. Agreed that it is really becoming dead, though.

The whole point of the article is that a number of sites (Google, Facebook, Netflix) are returning invalid sites because the browser is Vivaldi, not to make the site work with Vivaldi, but to make Vivaldi not work. It’s entirely the developer’s fault, not the browser’s.

Sure, but developers were forced down this path due to IE6 et. al. not respecting an open-standards-compliant grammar for HTML, JS, etc.

What you can't do on IE6 without user agent sniffing?

As soon as you trust the client, it's game over. Period.

There's more than one kind of trust.

You should totally trust your client to show stuff to the user. And you can generally trust your client when giving you user data, in the sense that you can trust that the data came from the user. (Unless the client is hacked by third-parties or buggy.)

Basically, you can trust your client as much as you can trust your user. Not more.

Obligatory: https://groups.google.com/forum/m/#!msg/comp.lang.java/aSPAJ...

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.

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".

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.

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.

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.

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.

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.

Oh the other thing was that we were using an https url override on Android and the custom scheme was primary iOS. And the iOS 8 or 9 added the ability for apps to handle https urls, which could be used to simplify our iOS nonsense. But not all of it.

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

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... 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.

That depends on your user base. For example [1] sees about 10-20% of Chrome and Firefox users on some notably "outdated" version. If your demographic skews towards enterprise users that seems very plausible, large companies regularly hold updates back until they are tested or use extended support releases.

1: https://www.stetic.com/market-share/browser/

For most CSS and JavaScript incompatibility issues, the way to check doesn't require UA sniffing at all. You merely check if the browser supports said feature by looking for whether the supports media query runs or if the new method is available at all.

https://developer.mozilla.org/en-US/docs/Web/CSS/@supports

@supports is often unreliable for CSS features. At least in Blink, it acts more as a "valid syntax" check then a "supported feature" check and for some reason Blink's CSS engine recognizes many new CSS features as valid syntax while not actually supporting them.

I for one would serve adapted css that is matched to the browser. Due to vendor prefixes there is unfortunately some mandatory bloat for a cross-browser stylesheet.

It would also skip polyfills when those aren't needed.

obviously what will happen with those services that need to know what browser you logged in at is they will do more vigorous capability based checking to determine your browser - sort of like how css used to have all sorts of hacks to target particular browsers.

... You're suggesting that rather than using the user agent, to identify.. the user agent, because people abused user agent strings to detect features... sites will now need to detect features and maintain a complete matrix of the features every browser and version implements, and determine the browser name, from the features it supports?

You realise how ridiculous that sounds right?

Or did you just completely misunderstand what I was talking about:

Some sites (and I've built some that do this) will show e.g. login history or account activity for users, and might say e.g. "Logged in from London using Chrome v52 on a Windows 8 PC on Tuesday at 10pm".

It's very much for human consumption.

Yes I realize how ridiculous that sounds, but on the other hand if the old way of doing it will no longer work and people need to do it they will find another way. Generally technically less nice to work with and all sorts of other attendant problems but that's the breaks. I believe this is a bad idea, but it looks like the bad idea is coming to pass.

I mean considering that if browser makers go along with this way of doing it, necessitating the hacky way of finding out what browser one is using. I think they will go along with it, but maybe also reason will prevail?

I suppose what will happen if this gets widespread is something like modernizr to detect all possible features (also those in development pipelines), and then take those features and use something like the caniuse api https://www.npmjs.com/package/caniuse-api to give you what browsers are possible for each feature, leading to some point where you can narrow it down to browser name, version.

I vote this comment of the month

And don't replace it. (Someone will replace it.)

If every browser uses the same string then it's useless/pointless; why not get rid of the UA altogether??

To prevent existing code that relies on it from breaking.

The problem there is that websites can no longer decide what content and workarounds to serve based on the user agent. Feature detection is great, but not a solution for things that need to happen server-side.

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

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

Let's take a look at Firefox!

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

Only, er, half of the version numbers are lies...

Are you on Wayland?

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.)

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.

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

You have created a perverse-sounding design.

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

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

This would not work, too many websites (perhaps wrongly) depend on this string.

I'm specifically suggesting that http/3 could have an implied value for this header if not supplied, so that omitting it was semantically equivalent (and a server could synthesize it).

That's not how HTTP works. HTTP is a transfer protocol, and is not so opinionated on the semantic meaning of the Data it moves. HTTP, HTTP/2, and HTTP/3 were designed to be backwards compatible. It would break that compatibility if there were a semantic change in the absence of the UA string. Specifically, H/3 requests couldn't be downgraded to HTTP/1.1 requests by proxies. There are a lot of proxies.

> It would break that compatibility if there were a semantic change in the absence of the UA string. Specifically, H/3 requests couldn't be downgraded to HTTP/1.1 requests by proxies.

It would not reduce the semantic meaning of HTTP to say "in http/3, the default value of the user-agent header is XYZ (a non-specific modern browser), and if you want an empty header, you must specify the header with an empty value. Proxies and other software translating requests between http/3 and older versions of http should map an omitted header in http/3 to this value, and should map an empty string to a missing header."

It would certainly require change, and it isn't a change likely to happen at this point, but it wouldn't have been impossible, nor would it have reduced the fidelity of http. It simply would have changed the default assumption from "something too ancient to identify itself" to "something modern that doesn't want to identify itself".

From the article, there is this recent proposal for "UA-hints": https://github.com/WICG/ua-client-hints

Every browser has to act together, or the ones that don't will win due to better compatibility.

The obvious way to make that happen is a law. Just prohibit the user agent string from being sent, starting with browsers that are distributed after a certain date.

Perhaps a bit of voluntary cooperation is possible. It worked for webassembly.

That's insane to propose the government should regulate http headers. What happened to freedom of speech?

>What happened to freedom of speech?

Deceptive speech is regularly curtailed by the government (eg. fraud, deceptive advertising)

>> What happened to freedom of speech?

> Deceptive speech is regularly curtailed by the government (eg. fraud, deceptive advertising)

Is spoofing a User-Agent string really deceptive speech? It's just asking a server to return a web-page in the same format as a specific browser... somewhat like asking a salesperson to give you the same price they give everyone else.

Only a small subset of deceptive speech; it’s perfectly legal to lie about who you voted for, or that you like someone’s haircut. Plausible deniability (my browser is Chrome, I swear) is potentially a means for individual autonomy and counteracting the misuse of power.

While I agree with your first sentence, freedom of speech doesn't have anything to do with HTTP headers.

Say for instance, all clients claimed to be Chrome. This would skew analytics towards Chrome, and would clearly benefit Google. If this activity did not benefit Google, Google would fight this activity, presumably on the grounds that other companies are producing a product that claims to be their product when it is not. Since it benefits Google, Google is not compelled to fight this misrepresentation. I argue that Google is evil for allowing this to happen, and that the US government (FTC) should intervene in this area where possible, on anti-trust grounds.

If there's nothing to analyze, analytics would lose meaning (it's already a cargo cult though).

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

Better still, ditch the UA string entirely. The only thing that will force website developers to write cross-browser compatible progressively enhanced websites and apps is being forced to detect features and test in all browsers instead of just whitelisting Chrome based on the User Agent.

User Agent strings are bad for the web.

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/

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.

I am surprised clearing the cache doesn’t remove these lingering files, given their remnants would be a privacy problem.

This is a webview embedded in a native app that we don't control, not a web browser. No, clearing the cache in Safari doesn't help. This stackoverflow https://stackoverflow.com/questions/5468553/clearing-uiwebvi... says you can write some native code to clear the cache, but we don't control the native app, we control the web app that runs in the webview. We will report the problem to the native app developer, but hopefully the user can just free-up space and upgrade their iOS in the meantime.

Aren't you at the mercy of that app? https://developer.apple.com/documentation/webkit/wkwebview/1...

We are... but they report the UserAgent properly (sort of). Here's an example:

Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148

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

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.

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.

We do support iOS 11. The client being on iOS 11 is an indication that the device has run our of storage space. Because it was out of storage, the files for our app were truncated because there was insufficient storage. A truncated file is there but it's corrupt. iOS doesn't detect this corruption, and the app is broken. Forever, and it can't be fixed without a factory reset, complete reinstall of the OS or somehow jailbreaking the device as far as I know. The customer reporting "stuck on a blank screen" and the User Agent being stuck on iOS 11, even when most people have automatic updates enabled are the primary indications that leads to this conclusion.

Ah right! Thanks, now I get it. Wow that's nasty.

At the same time, it's my computer and if I want to change the User-Agent string, I will. I don't have to tell you what platform I'm using if I don't want to.

You are absolutely right, but don't expect apps to work, and if you report a problem to an app maker, you can expect the response "Sorry we cannot reproduce your problem. Everything works fine for us with browser XXX", or possibly "Sorry we cannot find logs for your device XXX" because you are falsely reporting your device in the UA, but telling them in your communication about the problem something different.

Sure, I'm not disagreeing with any of that. But saying it's "fraud" and there there should be "laws against" it is going way too far.

Of course, if I choose to call you for support I probably would not continue to hide what platform I'm using, that'd be silly. I wouldn't report an issue with false information.

I agree, making laws about it shouldn't be necessary. The context of this discussion is that applications should not flatly refuse to service UA clients who are not the biggest 3 or 4 players. A better solution would be to require servers to service all clients, but if an unknown or unexpected client is detected, the server's response should include a compatibility warning. Server-side software makers are simply trying to limit the amount of testing they need to do to provide a reliable system. Client-side software makers, by lying about who they are, are trying to do the exact same thing. The problem is that these two actions result in an outcome that achieves neither server nor client's goals, and there's the rub.

You are arguing that it should be ok for your software to lie about who/what it is. If we go down that road, we end up with chaos. Software misreporting who/what it is so a server that will think it is a compatible system and agree respond, when it might otherwise refuse.

fraud n. A deception practiced in order to induce another to give up possession of property or surrender a right. n. A piece of trickery; a trick.

Personally, despite the obviously good intention to provide a reliably working software system, I think building a software system that systematically lies when reporting who/what it is is worse than a one-off lie to a customer support person on a phone call.

Surely there is a solution that does not involve deception.

I approach this as an end user. I'm using a tool, my browser in this case, to make a request for resources from a server. I can choose to make any request I like, formed in any way I choose. The server can choose to respond in any way it likes, compatibility warnings and all.

However if a server refuses to serve me a response if I use one client over another, but is still willing to serve me the user, I do believe it is well within my right to disguise myself as another client. I'm not accessing anything I don't have a right to; after all, the server would happily respond if I use a different client.

> You are arguing that it should be ok for your software to lie about who/what it is.

I suppose, yes, I am. Not "who" though, we're not talking about authentication. Only what software, I the end user, am using to make the request.

I'll concede it's "fraud" if you define it as "trick." Guilty as charged: trickery.

You have me there on the "who" bit. I admit I have also been guilty on occasion of doing whatever is necessary as a client to get a server to respond.

My point is that if we are going to try to fix it, we should address the problem, not mask it or throw up our hands and just set the UA to some silly constant. The information is helpful in troubleshooting issues and avoids people having to ask the inevitable "what browser/device are you using?" and also helps to allocate resources when testing. I honestly don't know what we would do as software developers and testers without somewhat accurate UA information.

Maybe where we are right now is the best we can do. You can pretend to be Chrome and most of the major devices/clients will report their UA accurately, but if everyone did what you are claiming is your right to do, we would not have a viable ecosystem.

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.

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.

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.

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.

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

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

Yup, it should be killed off.

First step would be for all browsers to send the same UA. Once it becomes completely meaningless, nobody will read it any more and we can drop it permanently.

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.

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.

> 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!!

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...).

Probably because Vivaldi is based on Chromium.

The user-agent header was a huge mistake.

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.

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.

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

which is blocked by

https://bugs.chromium.org/p/chromium/issues/detail?id=595993

which is blocked by

https://bugs.chromium.org/p/chromium/issues/detail?id=963260

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.

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

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.

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?

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

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.

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...

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.

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.

Everybody lies:

https://noti.st/nielsleenheer/73y43P/slides

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 .

Oh, these sweet monopolistic practices...

Good move. Other browsers should follow.

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

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.

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

Reply on news.ycombinator.com