User Agent Changes
-
I welcome this eventually making its way into public builds.
-
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.
This doesn't matter. Vivaldi's userbase was so small they never actually appeared on such sites, and was mostly just lumped into the "other" category anyway.
P.S. On the bright side there is a recent proposal to fix the problems with User Agents. We will certainly keep our eye on it and revisit the situation in the future.
That won't fix the main problem. It will make user agent a bit cleaner and remove the need for all the fluff.
But it won't stop people blocking browsers arbitrarily.
And any old servers that did bad UA sniffing will just stop serving pages altogether if the UA was removed entirely.
-
@pesala: Not everyone understands the user agent or even knows it exists / is the cause, so a blanket change is necessary in order to fix it for everyone.
-
@Pesala That would certainly be useful for users who understand how UAs work.
But for the vast majority of browser users, they won't know what it means or how to use it without additional instruction.
And to make sites work right "first time" (without needing extra clicks, clearing cookies, logging out and back in...), changing the default UA makes most sense.
-
… (sorry, it had to be trimmed to not take one
PgDn
)Now I'm thinking of switching to another browser, though I don't want to and never thought I would.
-
Will you do that on mobile too ?
-
@potmeklecbohdan: What? why?
-
@LonM But there are many users (like me) that want Vivaldi to use its own UA and are already used to some extra clicks (uMatrix &c).
Wait, why do we have the UA changing extensions?
-
@Aronand Cause I want Vivaldi to be itself… Well, hard to explain. Give me a few minutes/hours and I'll be OK again (w/ User Agent Switcher for Chrome always active w/ the old Vivaldi's UA )
-
@cqoicebordel: That is the plan
-
@potmeklecbohdan: It is itself. The UA was already just a string of different browser names at this point anyway, “Mozilla, AppleWebKit, KHTML, Gecko, Chrome, Safari…”
The UA does not define the browser. Most users never see it. It is only displayed to the websites you connect to
-
@ruario I know, but it's like… ehm, maybe reverse the following… like being on Windows, using terminal & i3 and managing SW from Octopi (&c).
-
Good decision, problems with websites made me reluctant to recommend Vivaldi to less tech savvy people.
-
Nice, another extension I can remove
-
That sounds like a reasonable change or better yet - workaround. And to be honest, for the exact same reason, I always change the user-agent of my web browsers to a generic Chromium one, so that I don't run into any problems. But seeing this change being being baked directly into Vivaldi is a good thing. Kudos to you!
-
This is also great for reducing fingerprinting!
-
I'm sure this is a good move to avoid users running into all kinds of issues with sites not working. It's definitely something causing a lot of grief (right after various extension issues).
It's funny (and sad) though that after so many years of the web, sites still do this. Developers repeat the same mistakes over and over. Browser-sniffing was one of the most common causes of trouble back in the Opera days - over 15 years ago!
Personally I'm proud to use a Vivaldi, and would rather display a proud "Vivaldi Snapshot Baby!" UA string. Any site that breaks with it is not worth it to use anyway
-
@Pathduck Also this move would avoid the usual dumb sites saying that Vivaldi 2.10 is older than 2.9
-
Heh... maybe it's time for a "Bork Vivaldi" version. Unfortunately, that would probably do more harm than good...
-
Elimination I had thought of (and I'd been running that way recently to avoid problems), but reversal I hadn't. It's brilliant, as long as the sites that do work don't change on you abruptly. Keeping the list very contained will guard against that.
BTW, I just looked: Brave doesn't use a custom string, and it seems to be doing very well. So I wouldn't worry about that part. Unsure if it IDs as itself to any of the sites you mention.