It causes confusion as to which pref has priority (are SSUAOs overridden by this pref?)
This should be done with finer granularity on a per-request basis, which can easily be done with a targeted extension manipulating request headers.
These things will have to be mitigated application-side.
Pref needs to be reworked to distance UXP from fallacies in mozilla-central development and the resulting unmaintained Firefox extensions, to neuter them.
Several reasons:
- This is a terrible Web Compat footgun
- It causes confusion as to which pref has priority (are SSUAOs overridden by this pref?)
- This _should_ be done with finer granularity on a per-request basis, which can easily be done with a targeted extension manipulating request headers.
These things will have to be mitigated application-side.
Pref needs to be reworked to distance UXP from fallacies in mozilla-central development and the resulting unmaintained Firefox extensions, to neuter them.
Let me repeat my forum post. 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.
Let me repeat my forum post. 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.
Let me repeat my reply, since you clearly can’t wait 5 minutes for an answer.
Actually, for web compatibility reasons, it is about request headers. The blanket override is a terrible footgun.
Off-topic for this issue:
Also, I don’t actually see why we need overrides for buildID and oscpu outside of a testing/debugging environment - seems they were added by Mozilla for just that, too. 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 (because there are more unique values to be found there than what OS and what browser build you are using).
Either way, that would be something for a different issue.
Let me repeat my reply, since you clearly can't wait 5 minutes for an answer.
Actually, for web compatibility reasons, it *is* about request headers. The blanket override is a terrible footgun.
Off-topic for this issue:
Also, I don't actually see why we need overrides for `buildID` and `oscpu` outside of a testing/debugging environment - seems they were added by Mozilla for just that, too. 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 (because there are more unique values to be found there than what OS and what browser build you are using).
Either way, that would be something for a different issue.
If you want to provide reasons aside from “my old firefox extensions” or “I want it” to keep/restore this preference, then by all means weigh in on the issue on the forum where this is being discussed. Reasons for removing it have been given in comment 0 https://forum.palemoon.org/viewtopic.php?f=3&t=25624&start=20#p203598
If you want to provide reasons aside from "my old firefox extensions" or "I want it" to keep/restore this preference, then by all means weigh in on the issue on the forum where this is being discussed. Reasons for removing it have been given in comment 0
https://forum.palemoon.org/viewtopic.php?f=3&t=25624&start=20#p203598
Several reasons:
These things will have to be mitigated application-side.
Pref needs to be reworked to distance UXP from fallacies in mozilla-central development and the resulting unmaintained Firefox extensions, to neuter them.
Let me repeat my forum post. 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.
Let me repeat my reply, since you clearly can’t wait 5 minutes for an answer.
Actually, for web compatibility reasons, it is about request headers. The blanket override is a terrible footgun.
Off-topic for this issue:
Also, I don’t actually see why we need overrides for
buildIDandoscpuoutside of a testing/debugging environment - seems they were added by Mozilla for just that, too. 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 (because there are more unique values to be found there than what OS and what browser build you are using).Either way, that would be something for a different issue.
If you want to provide reasons aside from “my old firefox extensions” or “I want it” to keep/restore this preference, then by all means weigh in on the issue on the forum where this is being discussed. Reasons for removing it have been given in comment 0
https://forum.palemoon.org/viewtopic.php?f=3&t=25624&start=20#p203598
Backed out for devtools breakage.
Following the discussion on the forum this issue will be repurposed.
Remove blanket general.useragent.override prefto Rework blanket general.useragent.override pref 11 hours ago