general.useragent.override - how to set?

[suseuser04]

Hello:

I am puzzled by general.useragent.override and general.useragent.override.domain.name settings.

Which one has preference over the other?

In my experience setting general.useragent.override has preference over all
general.useragent.override.domain.name settings.

Can you enlighten me how I supposed to set these if I want eg set specific overrides for specific domains
(eg youtube.com) and a general one for all the domains which are not set specifically?

Thanks,

suseuser

[Pentium4User]

Code: Select all

general.useragent.override.addons.mozilla.org

for addons.mozilla.org for example.
You can open about:config and then you see the default overrides.

Same happens for youtube.com

[vannilla]

Use Sasuga: https://addons.palemoon.org/addon/sasuga/
It was created exactly with the purpose of helping out those people that don't know how to (or don't want to) work with the raw settings.

[jars_]

Add-ons - PermissionsPlus | Pale Moon

[suseuser04]

Thank for your answers.

Unfortunately the subject title is misleading, and I only realized it when I read the answers.

I do know how to go to about:config and how to set key/value pairs.

What I don't understand how general.useragent.override and
general.useragent.override.domain.name (eg general.useragent.override.youtube.com)
are related. In what order are they applied? I would expect that it goes from the more
specific to the less specific, that is if a domain name rule is found it is applied first,
and if a domain name is not found, then general.useragent.override applies. But in
my experience if I set general.useragent.override it overrides all
general.useragent.override.domain.name rule. For example if I set
general.useragent.override.youtube.com to a value that works with youtube, and
general.useragent.override to a value that doesn't work with youtube, youtube site will not work.

The question is how I can set a basic override rule which applies only if there is no override rule for a specific domain.

Thanks,

suseuser

[vannilla]

What you should do is reset the "general.useragent.override" preference, restart, then use only domain-specific overrides.
If you saw in practice that the generic override takes precedence over the domain-specific ones, then that's how it works.
You can't have a general override because there's no need to: domain-specific overrides are necessary only when a site does a terrible UA sniffing, for everything else you don't need it but rather keep the Pale Moon/Basilisk name so that webmasters will discover the existance if this browser.

[suseuser04]

Thanks.

> rather keep the Pale Moon/Basilisk name so that webmasters will discover the existance if this browser.

That's what I don't want to do. I don't want websites to know my exact browser/operating system.
And I cannot set a site specific override to every site I visit.

suseuser

[Moonchild]

I don't want websites to know my exact browser/operating system.

For better or for worse, a lot of sites have to know your browser by user agent because they don't do feature-detection and are still stuck in the 90s doing ua sniffing (needed back then because of MSIE and because better ways of detecting features didn't exist yet -- no excuse now). If you don't want that, then you are going to have to lie about your browser one way or another, and as a result websites will break by serving you content specifically catered to the browser you are pretending to be. You'll have to consider what you find more important: them knowing your browser by ua or websites not breaking.

[suseuser04]

Thanks.

I do know all of that. Still I would like to know how the general.userage.override rules supposed to
work, which one has precedence. If site settings does not have precedence over general.userage.override
setting, then what is the role of general.userage.override at all? I would like to understand it.
None of the previous answers explained it. If you cannot answer that, please point me somewhere I
can find the answer.

Thanks,

suseuser

[vannilla]

It has been explained:

If you saw in practice that the generic override takes precedence over the domain-specific ones, then that's how it works.

What we are trying to tell you is that you either tell everyone you are using Pale Moon and lie only to a selected list of broken website, or you tell everyone you are not using Pale Moon and avoid visiting those broken website, assuming you can do it in the first place. For example you can't use YouTube since it will be broken.

[suseuser04]

OK, I guess now I see.


quote:

> If you saw in practice that the generic override takes precedence over the domain-specific ones, then that's how it works.

According to this it is not possible to spoof a general useragent which is overwritten for specific sites. I expected that it should
work like that.

Thanks.

suseuser

[Moonchild]

According to this it is not possible to spoof a general useragent which is overwritten for specific sites. I expected that it should
work like that.

Actually expected this return

The thing is, if you want to override what you present yourself as, you'd expect that to happen everywhere, not selectively -- otherwise it's not performing its intended purpose of faking your presence as something else. Thus, a blanket general.useragent.override will override site-specific defaults the browser comes with, to make your fake UA not leak anything else to websites.

[New Tobin Paradigm]

general.useragent.override, the global pref, needs to be exterminated.

[Moonchild]

I'm fine with that. Alternative extensions should handle changing request headers directly, instead.

[New Tobin Paradigm]

If someone has the skillz, that could be one kickass extension actually. Handle site-specific and do granular fix ups on a per-request basis.

[Moonchild]

I'm sure people have the skillz for that

[New Tobin Paradigm]

*feedback* Paging moonbat or vanilla, upgrade needed in extensions, upgrade need in extensions. *chhhk*

[JustOff]

The point is, it's not only about request headers, but also about the navigator object. And being able to control general.buildID.override, general.oscpu.override, and general.useragent.override is pretty important for setting up a privacy-enhanced environment. Please don't cut it out of the browser core.

[moonbat]

*feedback* Paging moonbat or vanilla, upgrade needed in extensions, upgrade need in extensions. *chhhk*

Roger.

[Moonchild]

The point is, it's not only about request headers, but also about the navigator object. And being able to control general.buildID.override, general.oscpu.override, and general.useragent.override is pretty important for setting up a privacy-enhanced environment.

Actually, for web compatibility reasons, it is about request headers. The blanket override is a terrible footgun.
Also, I don't actually see why we need overrides for buildID and oscpu outside of a testing/debugging environment. If you want to toss it up for privacy, then you may as well demand we add pref overrides for all the other properties of the Navigator object.