changelog v126 [important: read upcoming changes for FF128]
:green_square: v126
FF126 release notes FF126 for developers FF126 security advisories
NOTE
⭐ ⚠️ there is a migration of prefs coming in FF128 for sanitizing (on close and manually), including new ones,
so make sure to add any new corresponding sanitizing prefs to your overrides if required before 128
⭐ ⚠️ in FF128 I will also move arkenfox to using FPP not RFP see #1804
if you want to continue to use RFP (4501) and/or LB (4504) and/or disable webgl (4520) then you might as well add them to your overrides as well, so I don't change them on you without warning.
see this comment below for my overrides
CHANGELOG
- all changes
- ToDo: diffs
- v126 PR is at #1816
- new and active in user.js 126
- for spoof english see #1827
user_pref("browser.contentanalysis.default_allow", false); // [FF124+] [DEFAULT: false]
user_pref("browser.urlbar.yelp.featureGate", false); // [FF124+] [DEFAULT: false]
user_pref("privacy.spoof_english", 1);
- new and inactive in user.js 126
- for GPC see #1818
// user_pref("browser.link.force_default_user_context_id_for_external_opens", true);
// user_pref("browser.urlbar.quicksuggest.enabled", false); // [FF92+] [DEFAULT: false]
// user_pref("privacy.fingerprintingProtection.remoteOverrides.enabled", false); // [FF127+]
// user_pref("privacy.globalprivacycontrol.enabled", true);
- new in user.js 126, required for 128
- see #1837
clearSiteDataFF128+ =Privacy & Security>Browser Privacy>Cookies and Site Data>Clear Dataprivacy.cpdold prefs migrate toclearHistoryprivacy.clearOnShutdownmigrates toclearOnShutdown_v2- migration (the prefs are reduced) is documented at here
- I have kept the same values as before, so all you need to do is update your overrides to suit
user_pref("privacy.clearHistory.cache", true);
user_pref("privacy.clearHistory.historyFormDataAndDownloads", true);
user_pref("privacy.clearHistory.cookiesAndStorage", false);
// user_pref("privacy.clearHistory.siteSettings", false);
user_pref("privacy.clearOnShutdown_v2.cache", true); // [FF128+] [DEFAULT: true]
user_pref("privacy.clearOnShutdown_v2.historyFormDataAndDownloads", true); // [FF128+] [DEFAULT: true]
// user_pref("privacy.clearOnShutdown_v2.siteSettings", false); // [FF128+] [DEFAULT: false]
user_pref("privacy.clearOnShutdown_v2.cookiesAndStorage", true) // Cookies, Site Data, Active Logins [FF128+]
user_pref("privacy.clearSiteData.cache", true);
user_pref("privacy.clearSiteData.cookiesAndStorage", false); // keep false until it respects "allow" site exceptions
user_pref("privacy.clearSiteData.historyFormDataAndDownloads", true);
// user_pref("privacy.clearSiteData.siteSettings", false);
- made inactive in user.js 126
- they are default false
// user_pref("browser.urlbar.suggest.quicksuggest.nonsponsored", false); // [FF95+] [DEFAULT: false]
// user_pref("browser.urlbar.suggest.quicksuggest.sponsored", false); // [FF92+] [DEFAULT: false]
- moved to
9999: DEPRECATED / REMOVED
user_pref("browser.messaging-system.whatsNewPanel.enabled", false); // deprecated FF126
user_pref("browser.ping-centre.telemetry", false); // deprecated FF123
STATS
STATS v126: up to and including section 4500, minus the parrots
=========
total: 192
inactive: 50
n/a 9 (FF128+: clearHistory, clearOnShutdown_v2, clearSiteData prefs)
---
active: 133
default: 23 (at least)
n/a: 2 (of the three prefs in 0204, only one will apply)
---
flipped: 108 (at most)
all up, very boring .. only 1 new active pref (spoof english) which if anyone is already using it, it should be in their overrides.
Everything else is upcoming (FF128 sanitizing migration), or commented out since it's at default-what-we-want (or for prefsCleaner), or deprecated
Enjoy the stability of arkenfox :)
https://github.com/arkenfox/user.js/pull/1847/commits/10fddc8072b69cb7f3448fb4c5e09c8bc23b72f3
my overrides for FF128 - add em now if you want to continue with RFP in FF128+
user_pref("privacy.resistFingerprinting", true);
user_pref("privacy.resistFingerprinting.letterboxing", true); // optional
user_pref("webgl.disabled", true); // optional
user_pref("privacy.spoof_english", 2); // optional
// ^ I have en-US app lang and a non-matching en-** OS
// so my locale without spoof_english is the same as OS which is not desirable
FYI: re spoof english and en-US on english but not en-US OSes
- https://bugzilla.mozilla.org/show_bug.cgi?id=1739712#c5
-
Soo, we devised this slightly sophisticated system where if the language portion of your OS locale matches langauge portion of Firefox locale (for example "en-US" and "en-GB"), then we will use the region portfion of your OS locale in Firefox.
- edit: this happened when they ripped out the
javascript.use_us_english_localepref in FF119 1846224
When switching to FPP should privacy.window.maxInner* be disabled, too?
no, newwin (max sizes) is only used when RFP is enabled
edit: letterboxing is the one that is not tied to RFP
I'll add some info to #1804 tomorrow hopefully and unlock the topic and everyone can go have a good yarn and discuss it to death :) I of course will unsubscribe having said my bit :) e.g. why I plan to keep using RFP
About privacy.spoof_english 1, if I:
- don't use RFP;
- have set
intl.accept_languagestoen-US, en; - don't have the deprecated preferences anymore;
- am on the latest Firefox version;
- use the language EN-US for the app itself;
- and have
intl.regional_prefs.use_os_localesset totrue(regional pref. from OS is different from en-US);
am I good?
Noob question: I couldn't find browser.search.serpEventTelemetryCategorization.enabled in the new user.js, should I disable it (as suggested here) or is there a master switch somewhere already?
#1840 ?
@Tiagoquix IDK - languages is just languages - i.e request page in x,y,z ... and the app language can be different if you want
So you have en-US interface, en-US,en languages - that's all groovey (app language is used by webcontent for a lot of things, e.g. look and feel for widgets: buttons, input fields, etc - which to me is backwards but probably a legacy thing: they should eventually make all chrome use app lang, and all web content use web-request lang, but that also has issues)
Anyway, so what really matters here is the locale - all the Intl....resolvedOptions. If you have en-US language/app-lang and your os is en-US you're cool, but if your os is en-CA or en-GB then it uses that for locale. Same goes for the locales for spanish, french, german etc. But if you have en-US and your os is es-ES then it will use en-US (or so I believe, I do not have a non-english OS handy)
And that's before you start using spoof_english, which only allows spoofing for a single language, not all (because of all the places the app language leaks or is used in web content)
And resetting spoof english also has issues and I think bad design - it does not reset things which actually caused a major regression in Tor Browser where users could mix and match languages and locales - e.g. german language and english locale - relaly bad.
All I can say is test it: https://arkenfox.github.io/TZP/tzp.html#region
Thanks for the info and the testing site! Really helpful.
@Thorin-Oakenpants Out of context: could you consider releasing arkenfox v126.1 to fix the semi-colons? I think they're important fixes.
I already updated the live user.js with the active missing ; - updater will pick up on this. The other is commented out and non-breaking IMO, and is a FF127+ pref recommended not to use (but I get that this is about the syntax part)
What am I missing here? Do I really need to a 126.1 release?
edit: ok, users may not run updater unless they see a new release version, because let's face it, it's manual
edit: ok, users may not run updater unless they see a new release version, because let's face it, it's manual
exactly that!
https://github.com/arkenfox/user.js/compare/126.0...126.1
You're good people, Thorin-Oakenpants.
now at 31 spartas
last time I counted in sparta units cc: @bagder I will catch you :) edit: curl at 34.6k right now
may I ask if the cpd migration to clearHistory already happened? because there are only the latter in user.js, as opposed to the v2 prefs where we have both until 128 rolls out
because there are only the latter in user.js
they are both in the user.js - migration should not be happening until 128 AFAIK
https://github.com/arkenfox/user.js/blob/47cbf5b9740ef59ed866874346d3fee3379f8da3/user.js#L691-L710
For choosing between FPP and RFP from 128 onwards, can we summarise RFP as "If it doesn't break anything (important) for you, you should use it."?
For choosing between FPP and RFP from 128 onwards, can we summarise RFP as "If it doesn't break anything (important) for you, you should use it."?
There's a wiki page about RFP: https://github.com/arkenfox/user.js/wiki/3.3-Overrides-%5BTo-RFP-or-Not%5D
After reading, the user can decide to have it enabled or not.
RFP is on for every AF user by default. That's a privacy recommendation. The users choosing to disable it are the odd ones out, effectively saying "I don't care about what AF recommends, I'm okay with reduced privacy protection because I want XYZ to work".
From 128, RFP will be off by default, in favour of FPP. Does this mean AF is saying:
- "FPP is now recommended, don't bother with RFP.", similar to how FPI was deprecated in favour of the superior dFPI, or
- "AF is reducing privacy protection for all users by default. If you want to maintain the same level of privacy as before, keep RFP enabled."
?
All I care about is a one word answer to the question "Does AF still recommend RFP over FPP for more privacy protection, damn the breakages?". Yes or no?
#1804 doesn't provide an answer, and #1716 is far too long-winded and confusing to be able to spot one, if it is even there.
Right now, my tentative answer is yes, because "Thorin is still using it, so it must be good."
https://github.com/arkenfox/user.js/issues/1846#issuecomment-2153972165 - when I feel like it, I grew to hate writing about FPing due to incessant nature of idiots and having to repeat myself, to the point where it's a blocker
that said the answer is really simple - do what you like - if shit doesn't break (much) RFP is better and more robust. If you can't handle the breakage (or usability shit like FPS at 60 or timezone as iceland) then don't use it. Same as always. I'm just changing the DEFAULT in the TEMPLATE
without my support,. users can also use FPP (default) but kick in RFPTargets - so all RFP minus the bits that break (edit: but I'm not going to support that here, as in helping people with it, fuck that, I have enough to do)
I'm just changing the DEFAULT in the TEMPLATE
I think this is a POV problem. You're underestimating the psychological impact such changes can have on users, because you're sitting on top of a hill with all the background knowledge and expertise on the issue.
What may be a simple "Eh, I'll just add a couple slashes to the RFP prefs." to you might be a "Holy shit AF just turned off RFP entirely what does this MEAN!?" for mere users.
if shit doesn't break (much) RFP is better and more robust
THANK YOU. The fact that you're still saying this, now that the decision to move to FPP by default is already made, is what mattered here.
runs away to order buckets of ice cream in celebration
Thorin has a strong position on Arkenfox being just a template, and not a file-that-dicatates-your-usage. I like it. As long Thorin makes it very clear in the new release notes (possibly with a link to the RFP page on the wiki), I'm fine with it.
Big spoilers ahead!
have some ice cream, people!
file-that-dicatates-your-usage
Dictation is different from recommendation. There are entire sections in the user.js labelled "don't touch" or "don't bother". Of course the user is free to mess around with every single pref, but AF defaults are defaults for a reason, and deviating from them isn't done lightly.
Just want to add my two cents. @Thorin-Oakenpants it looks like you spend quite a bit of time replying to people in issues, turning the issue tracker into basically a forum. It takes a long time to understand anything, because you assume so much prior knowledge. We're not all up to date on what's going on here. I really think you need to focus on the documentation, focus on summarising and keeping things simple (while retaining references to more complicated material) such that this project can be more accessible to a wider (but still technical) audience. I recommend also adding a Discussions page. People can read the documentation and get answers from other people telling them to read the docs again because it already contains everything necessary. This is what all developers should do, really.
Discussion doesn't belong in issue trackers, and when you don't have your own dedicated page for discussion you encourage it on other platforms, which leads to people taking information out of context and doesn't aid in comprehension.
Otherwise, love what you're doing, I respect your decisions regardless.
yeah the topic and the acronyms are already hard to follow, and then the changes by mozilla year after year makes it more nebulous lol
I can help out with documentation if stuff is explained to me.
https://discuss.privacyguides.net/t/why-rfp-changes-time-zone-to-atlantic-reykjavik/19044
- anyone with a discuss account who wants to link to this, thanks
https://github.com/arkenfox/user.js/blob/6446d73cf572fcdf631534a5a51276a64eec4a2d/user.js#L799
for those wondering why
- almost no-one, if anyone, has UTC as a system/browser timezone, even if it is supported
- for this reason, browsers with UTC are associated with Tor Browser and are penalized
- since we only really care about recent (and future) date-times, we wanted to change to a real world timezone used by actual people
- 14 timezone names met the criteria that they use the same timezone (as UTC) and do not change with DST (daylight savings time) in current and future date-times
- 12 were in Africa .. and one was
Atlantic/Reykjavik- we chose Iceland - since 1912, all date-times in this timezone are effectively the same as UTC/GMT, it's just a different name
- now if a script wants to penalize Tor Browser (RFP, Mullvad Browser) based on timezone name, then they can also upset all of Iceland, and those fuckers are descended from Vikings
- https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42397
- solution instigated by some genius