Firefox 53: new preferences and Ghacks-user.js changes
The following article provides you with information on new Firefox 53 preferences, deprecated or removed preferences, and changes to the Ghacks-user.js file for the Firefox web browser.
Mozilla released Firefox 53 on April 19, 2017 to the public. The new stable version of the web browser shipped with quite a few important changes. For one, Mozilla dropped support for Windows XP and Vista, 32-bit Mac OS X, and Linux distributions running on older processors. The second big change was the removal of the Aurora development branch.
Firefox 53 shipped with several new features, including two new compact themes known from the browser's Developer Edition, and the first Project Quantum bits.
You can download the most recent version of the user.js file from the project's Github website. Thanks goes out to Earthling for creating the changelog for Firefox 53, and to all other maintainers of the list on GitHub.
Firefox 53.0: new preferences
The following preferences are new additions to the browser which Mozilla added after the Firefox 52.0 release:
- user_pref("browser.storageManager.enabled", false); // enables Site Data in Preferences in conjunction with "dom.storageManager.enabled", true.
- user_pref("browser.urlbar.decodeURLsOnCopy", true); // !! default value in FF53 is false !!
- user_pref("dom.IntersectionObserver.enabled", false);
- // user_pref("extensions.webextensions.remote", true); // default is false in FF53 so maybe not quite ready yet to enable
/** we already had the following prefs in the user.js but we now commented them out **/
- // user_pref("browser.tabs.remote.separateFileUriProcess", true); // default is false in FF53 so maybe not quite ready yet to enable. This runs file:// locations in a separate content process.
- // user_pref("svg.disabled", true); // it breaks YouTube player controls
Firefox 53.0: deprecated or removed preferences
The following preferences have been removed or are deprecated. Please note that some may still be used in Firefox ESR editions.
- dom.beforeAfterKeyboardEvent.enabled
- media.getusermedia.screensharing.allow_on_old_platforms
- plugin.scan.Acrobat // Scans locations for installed Acrobat plugins
- plugin.scan.Quicktime // Scans locations for installed Quicktime plugins
- plugin.scan.WindowsMediaPlayer // Scans locations for installed Windows Media Player plugins
- security.tls.unrestricted_rc4_fallback
Firefox 53.0 Ghacks-user.js changes
The following changes are new additions to the Ghacks-user.js file since the last release.
- user_pref("browser.crashReports.unsubmittedCheck.autoSubmit", false);
- user_pref("browser.crashReports.unsubmittedCheck.enabled", false);
- user_pref("webextensions.storage.sync.enabled", false); // !! default value in FF53 is true !!
- user_pref("webextensions.storage.sync.serverURL", "");
/** 4 new prefs in a new subsection for Favicons **/
- user_pref("browser.shell.shortcutFavicons", false);
- // user_pref("alerts.showFavicons", false);
- // user_pref("browser.chrome.favicons", false);
- // user_pref("browser.chrome.site_icons", false);
/** for completeness' and transparency's sake these are mentioned here too,
but they contain deliberate data mismatches and syntax errors **/
/* 1110: set sandbox level. DO NOT MEDDLE WITH THESE.
* They are included to inform you NOT to play with them. ... ***/
- // user_pref("security.sandbox.content.level", "donotuse")
- // user_pref("dom.ipc.plugins.sandbox-level.default", "donotuse");
- // user_pref("dom.ipc.plugins.sandbox-level.flash, "donotuse");
Moved item 2025
enable/disable various media types to the personal section,
commented them all out and set all values to false, so you can easily un-comment the media formats you want to disable. Previously they were all active and enforcing either true or false. #67
- // user_pref("media.flac.enabled", false); // prev: true
- // user_pref("media.mp4.enabled", false); // prev: true
- // user_pref("media.ogg.enabled", false);
- // user_pref("media.ogg.flac.enabled", false);
- // user_pref("media.opus.enabled", false);
- // user_pref("media.raw.enabled", false);
- // user_pref("media.wave.enabled", false);
- // user_pref("media.webm.enabled", false); // prev: true
Activated previously commented-out prefs
- user_pref("browser.sessionstore.interval", 30000);
Changed values :
- user_pref("privacy.clearOnShutdown.sessions", true); // 52alpha: false
- user_pref("privacy.cpd.sessions", true); // 52alpha: false
- user_pref("security.dialog_enable_delay", 700); // 52alpha: 1000
- user_pref("security.mixed_content.use_hsts", true); // 52alpha: false
- user_pref("ui.submenuDelay", 150); // 52alpha: 75
Commented out
- user_pref("browser.urlbar.maxRichResults", 0);
- user_pref("dom.event.contextmenu.enabled", false);
- user_pref("reader.parse-on-load.enabled", false); // also moved to section 3000 (PERSONAL SETTINGS)
Thank you earthlng. I didn’t use it because I thought anything whitelisted in the Firefox TP would undo anything blocked elsewhere. I thought I read that in the past when it came to using different add ons where one would whitelist something that would otherwise get blocked by another and applied it to the TP.
I linked to the “shavar-staging-lists” above but probably the one used is this:
//github.com/mozilla-services/shavar-prod-lists/blob/master/disconnect-entitylist.json
from here: //github.com/mozilla-services/shavar-prod-lists
“Is there an easy way to see all whitelisted items in the basic and strict TP lists?”
//raw.githubusercontent.com/mozilla-services/shavar-staging-lists/master/disconnect-entitylist.json
… is the “whitelist” or entitylist as mozilla calls it, and how it works is that all the domains in the “properties” groups can load anything they want from the respective “resources” group. For example the 7 domains in Twitter’s “resources” are whitelisted on the 8 domains in Twitter’s “properties”
@fmarier confirmed that that’s essentially how it works here:
//github.com/ghacksuserjs/ghacks-user.js/issues/102#issuecomment-298702871
The whitelist is the same for both basic or strict, but some of it will be ignored in the “basic” protection because it never blocks the additional content from “strict” and therefore doesn’t need to whitelist anything either.
“What happens when something is whitelisted in one but blocked in another?”
It will be blocked by whichever one has the block in it.
“Which takes precedence?”
uBO (and I assume ABP too) comes first. If the requests are not already blocked by an addon then TP kicks in.
You can test it yourself – see RoxKilly’s comment here: //github.com/ghacksuserjs/ghacks-user.js/issues/103#issuecomment-300744231
What happens when something is whitelisted in one but blocked in another? Which takes precedence?
Is there an easy way to see all whitelisted items in the basic and strict TP lists?
Thank you Pants but that is above my understanding level.
I was hoping for something along the lines of https://www.fanboy.co.nz/r/fanboy-ultimate.txt
I want to make sure using the built in tracking protection does not do more harm than good by introducing multiple different filters that unknowingly have one whitelisting something that the Ultimate filter list above is trying to block.
Quoting Pants, ”
Options>Privacy>Use Tracking Protection and you will see three choices: “Always”, “Only in private windows”, “Never”
”
If you don’s see these 3 buttons it is because by default Firefox doesn’t display them all … in which case, from about:config search for privacy.trackingprotection.ui.enabled and set it to true :
// enable more Tracking Protection choices under Options>Privacy>Use Tracking Protection
user_pref(“privacy.trackingprotection.ui.enabled”, true); // Default=false
Tracking Protection (TP), by default, is only used in Private Windows, so if you start firefox normally, then it is not used except for when you go New>Private Window. The default list used is the “basic” one, which is configured for less/zero website breakage. The list isn’t massive, as you can see from the file sizes, but do allow for third parties to work where needed. Bu it’s not the best you can do – eg: AFAIK, TP allows google analytics on say youtube (and maybe elsewhere).
go to about:config change this `privacy.trackingprotection.ui.enabled` to true. THEN open Options>Privacy>Use Tracking Protection and you will see three choices: “Always”, “Only in private windows”, “Never”
These three choices are controlled by the following two prefs
user_pref(“privacy.trackingprotection.pbmode.enabled”, true);
user_pref(“privacy.trackingprotection.enabled”, true); // all windows: normal and private
If both are false then TP is off. If both are true then TP is all windows both normal and private. And if pbmode = true and the other is false, then it’s just Private windows.
Here are the two values for which TP list to use (if you do it manually you need to restart FF)
* [SETTING] Options>Privacy>Use Tracking Protection>Change Block List ***/
// user_pref(“urlclassifier.trackingTable”, “test-track-simple,base-track-digest256”); // basic
// user_pref(“urlclassifier.trackingTable”, “test-track-simple,base-track-digest256,content-track-digest256”); // strict
There are NO clashes per se with using TP and uBlock Origin. If a domain is blocked in both, TP I believe kicks in first – but regardless, it is blocked. If a domain is only blocked in one (TP or uBo), it is still blocked. If it is not blocked in either, then it is allowed. There is no issues using both.
Two tracking protections questions.
Is there a way to see the basic and strict filters lists used to see what is in them?
Does the tracking protection filter lists include whitelisted items also so that it might cause a conflict or overrule a filter list used in ABP or UBO?
https://wiki.mozilla.org/Security/Tracking_protection#Lists
Basic mode: mozstd-track* + mozpub-track*
Strict mode: mozfull-track*
https://github.com/fmarier/sbdbdump/blob/master/dump.py – script to dump sbstore contents
@earthling
That was it. Wonder why a multiple year old state.json was just now setting that toolkit.telemetry.cachedClientID? That preference had been default blank all that time but just recently begun setting itself.
Am I supposed to delete those datareporting and healthreport folders? Only thing in them is that old state.json file.
Thanks.
“it is apparently still connecting to something to check and set the toolkit.telemetry.cachedClientID”
afaik it’s not connecting to anywhere to set a cachedClientID, it’s created internally. If telemetry is fully disabled it’s not really necessary to clear the ID.
If you always get same ID then maybe you have some old stuff in your profile (state.json?)
//dxr.mozilla.org/mozilla-central/source/toolkit/modules/ClientID.jsm#106
I never included toolkit.telemetry.cachedClientID in the user.js file because the default was always empty. Even though all the other telemetry preferences have been disabled, Firefox is now setting that toolkit.telemetry.cachedClientID so I had to add it.
Each time I would reset and it would be default empty. Then set it to user set empty. But Firefox would then set it back to the same ID number after a day or so. Any idea what Firefox setting it is using to set a toolkit.telemetry.cachedClientID even though all the telemetry settings are disabled? Thought it would stop checking telemetry when disabled but it is apparently still connecting to something to check and set the toolkit.telemetry.cachedClientID.
Where does it store that unique ID it gives it? Setting it to default or user set lists it as blank but it always comes back with the same ID number.
Not an issue since I added it to the user.js. Just curious.
FYI, if “browser.storageManager.enabled” is set to true, the Advanced panel menu doesn’t display on FF53. Don’t know why. Not much documentation on this new preference.
Did a little more digging and found this mention from https://blog.mozilla.org/l10n/2017/03/07/firefox-l10n-report-aurora-54/ under the Browser heading:
“In the last couple of cycles, some strings landed in pref for managing Site Data. To see this section in Preferences (at the bottom of Advanced -> Network), you need to enable (set to “trueâ€) both these keys in about:config
browser.storageManager.enabled
dom.storageManager.enabled
Functionality is still hard to test, since there are no websites using this feature available for testing.”
Found the above URL from note [3] in section 2706 of the GitHub user.js file.
By the way, thanks to all involved for the time and effort spent on this project, and my compliments to you, Martin, on a most useful and excellent website.
Thanks for the tip Pants. Unfortunately, it wasn’t that one though.
The site rateyourmusic.com blocks access after browsing the site for a bit. They state it is due to malware or blocking javascript but it doesn’t appear to be related to that.
Anyone happen to know how to figure out the cause? I figure it is a changed setting in the user.js but figuring out which ones to experiment with is above my comfort level.
Maybe it could be SSL Session ticketing ids? 1203 `security.ssl.disable_session_identifiers` – maybe they are sick of you negotiating handshakes for every item. Worth a test.
While I was looking for what some pref does I came across this website:
https://cat-in-136.github.io/
It shows you new/changed prefs for each version.
Yes, that’s a great reference link! Across several years, he’s done an excellent job in diff’ing changes across versions and reporting them.
Going forward, earthlng’s repo is excellent. We’ve talked about adding ESR (in the future maybe, especially when 57 lands) and Linux (looks unlikely – but here is something – https://github.com/ghacksuserjs/ghacks-user.js/issues/101 ).
That’s what I had been using with glee, but Earthlng’s https://github.com/earthlng/FFprefs-diffs appears to be an improvement.
Notice how the cat-in-136 site leaves small version gaps in its differentials. Some preferences slip through the cracks.
There has been changes with the referrer prefs recently and I’m confused.
Removed pref:
network.http.sendSecureXSiteReferrer
Recently created prefs:
network.http.enablePerElementReferrer
network.http.referer.userControlPolicy
Previously, I would tweak the following prefs, and as a result no referrer was sent, ever.
network.http.sendRefererHeader = 0
network.http.sendSecureXSiteReferrer = false
How can I reproduce this behaviour with the new prefs ? What I did, although I don’t know if it works, is set to 0:
network.http.enablePerElementReferrer
network.http.referer.userControlPolicy
And keep as default (true):
network.http.enablePerElementReferrer
Does anyone know if it works ? No referrer sent ever, regardless of per element referrer thingies or secure X-site shenanigans ?
quote: “Recently created prefs: network.http.enablePerElementReferrer”
Not so. That is nowhere in the user.js or the changelog. We do not use this pref at all, never have. See below why.
==
For an in depth discussion on referrers (which were changed in FF52-53, one was deprecated, two new ones added), including advise and some real insight from a Mozilla engineer who actually works in this section, Francois Marier (fmarier on github), read our discussion here : https://github.com/ghacksuserjs/ghacks-user.js/issues/5
===
As for `network.http.enablePerElementReferrer`
“That’s a partial feature flag that’s likely to be removed later. There’s no harm in setting it to its default value, but it’s not a particularly useful user control. It allows sites to trim the referrer on links and images for example, on an individual basis.”
and from here: https://github.com/ghacksuserjs/ghacks-user.js/issues/59
“However, the user controls like http.referer.XOriginPolicy take precedence over this, so it’s actually unnecessary from a user point of view. I suspect we will remove that pref at some point (given the feature is no longer experimental).”
`network.http.referer.userControlPolicy` is only a default, it can be overridden by a site-controlled Referrer Policy. This is not what you think it is
===
If you want to never ever send any referers then (“network.http.sendRefererHeader”, 0) = never send referers on links or images should be enough. Not that I have ever bothered trying it, as it breaks way too much of the internet to be useful – but could be used in a really hardened profile.
I’m pretty sure `network.http.referer.userControlPolicy` is internal only and used as fallback when a site has no policy, but I’d have to ask fmarier to be sure. I’ll ask him, just watch https://github.com/ghacksuserjs/ghacks-user.js/issues/5 for his response.
Thanks a lot for the very useful reply and links :)
Don’t waste your time digging this but just in case you have the answer already in memory, do you know if a website can read what the default policy is for referrers ? (network.http.referer.userControlPolicy)
Like, is it sent as an HTTP header ? If not, perhaps it is readable when JavaScript is enabled ?
I’m basically wondering if the default can only be overwritten blindly, or if it can be read and fingerprinted.
As for completely blocking referrers, I used to encounter very rarely a situation where I had to switch it on, but not in two years I think.
Thanks again!
Thank you T J for focusing on the bigger picture (i.e praising us! heh).
First of all, I apologize, the WEBEXTENSIONS syncing preference should have a [SETUP] tag (if you follow the github project you will know what this means).
But have any of you actually read what this user.js is (go read the readme here -> https://github.com/ghacksuserjs/ghacks-user.js/blob/master/README.md )
– 1. It’s a template, nothing to stop you commenting out what you don’t like (as Tau says above), and earthlng goes to a lot of trouble to create these friendly changelogs to make it easier for everyone.
– 2. the user.js is focused on PRIVACY among other things. If you read the user.js, you will see we have provided reference links. We don’t make decisions willy nilly.
– 3. the pref in question is for WebExtensions only and they are few at the moment (early days), I doubt if much is using it yet. It landed in 52 IIRC and was only flipped on in 53
– 4. It can always be revisited and changed
– 5. We work on next release changes well in advance. In fact we already have an issue open for FF54 and have already added 3 preferences, and noted dozens of others – so be proactive, and help out. The more the merrier
Now back to the “we don’t make decisions willy nilly” bit. Considering earthlng and myself have been looking at firefox issues and web technologies almost daily for 2 years + (earthlng probably longer since he’s a developer), it’s not like we just make shit up (but yes we can be wrong, and github is allowing more voices to have more input for better results, so take part damnit!). As per the reference link ( https://wiki.mozilla.org/WebExtensions/chrome.storage.sync ), an add-on developer can sync extensions preferences (this is the main case scenario), but they could in fact sync anything (including private/personal info). So there are two issues to this. One is your data in the cloud (which should be secure and private, I trust Mozilla on that – but is it encrypted, I suspect not, chrome isn’t AFAIK), and the other is developers tracking you across devices.
The only thing I am not sure is if this is required for the WE to have local storage access in able to store it’s settings. The pref name suggests it’s only for SYNCING – so Ray above, ” if you’re using a WebExtension that needs to save settings” should be “needs to SYNC settings” AFAIK.
As a “NEW FEATURE” with privacy/tracking implications, it is OFF in our user.js which, again, is a template, one that is in a constant state of change/review
==
@Harushi .. I trust Mozilla. Syncing add-on data is not about mozilla, it’s about having some un-encrypted data in the cloud that could be accessed (eg third party/law enforcement), and also increases the “attack surface” for tracking/privacy (developers can sync more than extension settings).
“sync anything (including private/personal info). So there are two issues to this. One is your data in the cloud (which should be secure and private, I trust Mozilla on that – but is it encrypted, I suspect not, chrome isn’t AFAIK)”
blog.mozilla.org/services/2014/04/30/firefox-syncs-new-security-model/
“firefox sync v2” introduced in 2014, does employ encryption.
I don’t recall reading that comms performed by WebExtensions must be (can only be) HTTPS. Even if they must (as in, inbuilt browser policy raises an exception if plain http or plain ftp is attempted), we dare not presume and cannot verify whether the backend server for each developer’s WebExtension is employing encrypted storage.
ps:
The server software for “Firefox Sync” is opensource ~~ we’re free to setup our own private (individual, or for group use) sync servers… but the software stack is monstrously huge, and, convoluted. I’m hoping to see the day where it would become a “snapin” available for OwnCloud, NextCloud, et al.
Thanks for that info :)
I meant encrypted storage, not the transmission. I should have been clearer.
@Ray
‘you’ll want to set “webextensions.storage.sync.enabled” to true if you’re using a WebExtension that needs to save settings.’
That’s not true. The settings are also stored locally just not synced across devices or backed up on mozilla servers for which there’s no guarantee that the data will be retained there.
What does browser.urlbar.decodeURLsOnCopy do?
It’s in the user.js
/* 3027: decode URLs on copy from the urlbar (FF53+)
* [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1320061 ***/
user_pref(“browser.urlbar.decodeURLsOnCopy”, true);
To save you the time, basically it means when you copy an url from the urlbar such as
– http://путин.президент.рф/биографиÑ
you won’t get this instead
http://путин.президент.рф/%D0%B1%D0%B8%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%8F
capisce?
Like Soren said, you’ll want to set “webextensions.storage.sync.enabled” to true if you’re using a WebExtension that needs to save settings.
It doesn’t make sense to disable this.
“you’ll want to set “webextensions.storage.sync.enabled” to true if you’re using a WebExtension that needs to SYNC settings.”
fixed that for you. web extensions can still save their settings, this is a syncing pref
If an extension has only implemented saving preferences with storage.sync, then the WebExtension will fail.
If an extension is using storage.local, then you’re correct, saving will still work.
But you shouldn’t make assumptions that extensions will just use storage.local. How do I know? I wrote a WebExtension myself and I’m only utilizing storage.sync.
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/storage#Properties
Who the heck has the time to follow all these ongoing changes, not only in FF ? And if we fix some changes we don’t agree with then the next ones have already popped up. The technology companies imho have three goals: 1. To get (steal) complete personal informations about us. 2. To force on us their policies, and only their policies. 3. To make as much money as possible without any concerns about the user and without any regards about privacy. And this imho applies to all of them, call them FF or M$, Apple or Google or IsnitchYourData.
The ball is rolling and will be extremely hard to stop. The people we pay (government) don’t give a poop since they are a major part of this dirty game. And with this orange hairdo clown
it won’t get any better.
It’s not about trusting mozilla or not, at all. Some people just don’t like to have their data stored in the cloud.
We only have 2 items with 3 prefs for Sync at them moment. The 1st is theoretically deprecated/removed but there’s still some code that uses it, and the other ones are the new additions mentioned in the changelog.
We rely on people to give us their opinions so that we can ship a default that’s more in line with what users want.
We may revisit the decision to include prefs to disable Sync. I agree, it doesn’t make much sense to include them because you need to have a Sync account and be logged in to use it. We’ll deal with it once the remaining code for “services.sync.enabled” gets cleaned up and removed, or maybe earlier if someone opens a new Issue on the github page asking us to revisit. Thanks
“We rely on people to give us their opinions so that we can ship a default that’s more in line with what users want.”
I’ve never seen such a public remonstration as when the Australis interface came out. If you actually think Mozilla listens to users, then you must be new to the Mozilla team.
PS. I *still* detest the Australis interface.
>Some people just don’t like to have their data stored in the cloud.
Absolutely this. If you use and need Sync it’s just a tweak to do as of now, after all.
During the squabbles / disagreements about Sync, something was forgotten !
Thank you VERY MUCH to Pants, earthling, Martin and all the Github stargazers. You have all put in a lot of work on user.js and the updates.
Come on posters ! Say “thank you” before you start fighting about “Sync or not to sync”. None of you did !
Yes THANK YOU all for this. I have spent countless hours trying to do what you have done.
I agree with Sören Hentzschel. Addon data sync is a very useful feature and it make no sense to disable it. If you don’t trust Firefox, I think Firefox isn’t your choice.
Since Fossamail is dead, it would be great if someone can adapt this Ghacks-user.js to Thunderbird, please.
@Martin, thanks for writing these promotional articles for the ghacks user.js. The stargazers on the github page increased quite a lot since the last article about the move to github.
@Sören, thanks for the infos. We are aware that some things may not quite be ready yet. But since the prefs landed in stable, we assume that mozilla thinks that those features are at least sufficiently working and ready for testing.
If someone wants to enable some of those and test it, it may also help mozilla when users notice problems and hopefully report them. We aim to inform users about available options and new prefs, but let them decide what they want to use.
As for webextensions.storage.sync.enabled let me quote from the mozilla wiki (that we linked to in the items description block):
Running a storage server imposes a long term financial and people burden on Mozilla. We intend to regularly review the storage server and see if it should be maintained. If it is shouldn’t, an appropriate deprecation period and plan will be made.
We don’t provide:
any guarantees about uptime
any guarantees about performance
any guarantees about data retention
—-
We also added a warning behind the pref in the changelog that the default value is true.
The ghacks user.js is a template that we expect users to adapt to their own needs and liking. And as you can see from Yuliya’s reply – not everyone is a fan of Sync. It’s impossible for us to provide a user.js that will satisfy everyone.
– The full changelog is here: https://github.com/ghacksuserjs/ghacks-user.js/issues/96, and comes with nicely color coded js bits, as well as links to various issues raised if relevant, where you can see any discussion held about any changes/decisions.
– Changelogs are all the changes between “alpha” releases (which are about a week after stable lands), so this also includes any fixes/changes/revamps/everything and is not solely FF53 specific changes.
– The changelog is a much friendlier user version than trawling thru atomic level commits.
– If you have a github login, feel free to question or ask about any of our decisions – either comment on an existing issue (open or closed), or ask in the changelog (issue #96), or start a new issue.
As earthlng says:
“Any and all help, suggestions, recommendations, links, tips and tricks, questions, thank you’s or whathaveyou – signup/login and start typing – thanks”
hey man, the cia is after you. burn everything and run dude. it is the government man. i don’t trust them.
it is a conspiracy man! they are setting you up. it is the government man. hide your stash dude. that area 51 thing man… we are doomed. unless we encrypt everything. like everything man, even toilet papers.
You do realize I work for the CIA, right?
What theme are you using for Firefox?
It used to be called “devedition theme dark”, but if you use FireFox 53 or newer you can go to Tools > Add-ons > Appearance and find it there under the name “Compact Dark”. At least in Windows builds it’s there.
If you use older stable versions, such as 52ESR you’ll need an add-on called “Developer Edition theme enabler”, otherwise it’s hidden. Open developer tools to change it’s colour.
Looks like compact dark to me
Hi Martin,
> default is false in FF53 so maybe not quite ready yet to enable
You can remove the “maybe”, there are reasons for the default settings. ;)
The target for browser.tabs.remote.separateFileUriProcess;true is Firefox 56. There are still known bugs. Also extensions.webextensions.remote is definitively not ready in Firefox 53. I don’t know the target, but it won’t be enabled before Firefox 55.
> user_pref(“webextensions.storage.sync.enabled”, false); // !! default value in FF53 is true !!
Why did you disable the ability for add-ons to sync the user’s settings between devices? It makes no sense. If you’re a sync user you WANT to sync data. Otherwise you wouldn’t use Sync and enable the sync of add-ons and preferences. You should respect the user choice, even is the defaults of a custom user.js file, and the login for Firefox Sync is a clear user choice, isn’t?
Sync is malware, just like Pocket and Loop. It’s another word for “give us your data”. You can always do it locally by copying the %appdata%\Mozilla folder to all your machines if you want to have the same profile across all of them. And since they can talk to each other through (W)LAN it all resorts to a simple drag and drop operation. You can even automate this through task scheduler to have it done once every x days. There’s no need to send your data to some random american server.
Rick A.,
I’m a spammer? Okay, whatever. So you trust a company with your data, a company which sells data aggregated through their “Focus” product? Do note that when a company states it collects “anonymised data” they’re just bullsh*tting you. There is no anonymised data collection, it is all tied and traceable back to the device it is tied to.
Regardless, I stand by my initial statement: the malware known as Sync. And it’s valid for any company trying to pull this unneeded crap on the end user as it is quite an unused feature, and I’d be surprised to see if at least 5% (five) of FireFox’s userbase is actually using it.
@Yuliya – You’re literally a spammer. “Sync is malware” – What a joke.
@Sören: Your comment has nothing to do with mine yadda yadda yadda… Why am I not surprised, former Mozilla Representative Hentzschel? There is reason not to blindly trust neither Mozilla nor Pocket. Especially Pocket.
Please google the term “malware”. Sync is the reason for a lot of users (not only in Firefox, also for a lot of Chrome users and users of other browsers) do use or to not use a browser. And by the way, in Firefox you can use your own server, you don’t have to use the Mozilla servers.
But more important: your comment is completely off-topic and has nothing to do with my comment. I said that if a user decided to use sync he *wants* to sync the data, otherwise the user wouldn’t use Sync. I don’t see a way to disagree in this point. Why should a user use Sync if the user don’t want to sync the data? It makes no sense. And your comment is definitively no response to my comment, it’s a completely different topic. The only common thing is the term “sync” in both comments.