users who modify settings this way should know about backups instead complaining about regular precedures in software which resets critical settings for purpose. omg
This really isn't new... I've noticed preferences reset to default values whenever I updated FF; some resets in Tools - Options, while most are in about:config. As @Brummelchen said, backups are key here, especially useful when used with programs that can compare two files simultaneously to identify which about:config entries were modified (such as WinMerge), and comparing notes from sites such as this one, and some threads on this forum.
I would advise you to find out why this is so like you're talking about. If it is absolutely sure that Firefox upgrades, re-installation, etc., does not change in any way these settings. If you have doubt, backup the prefs.js file in your personal profile directory. Into this file are always stored Your latter preferences. Of course You can use also user.js file, but some antivirus and anti malware programs may remove it without asking Your opinion.
Prefs... both default values (which don't appear in prefs.js) and non-default values (which do appear in prefs.js and may be user-adjusted values)... can be (and have been) changed during updates. Silently, no less. As in without any prompt or alert which serves to inform the user that a (possibly very important) pref is changing. Furthermore, you could be diligent and read the Release Notes plus Developer Notes plus Security Advisories before an update and still not become aware of some such changes. You could even read through the "Complete list of changes for this release" (a link that was moved from a more obvious location near the top of the Release Notes page to the bottom right) and miss some. You could click through to every bug in that long list of bugs in an attempt to catch discussion of pref changes not surfaced elsewhere. However, pref changes can be tied to code changes. In order to understand some of the pref changes you must also understand the related code changes.
Exactly, hence my disgust. Further, I'm coming from the angle of the average user. That makes it all the more troublesome.
Well things may become even more troublesome for some users. Specifically, those that utilize extensions to help monitor and/or manage prefs. Due to the WebExtensions only plan. I think the comments I've seen were: WebExtensions will be allowed no access to the pref system. WebExtensions will be allowed a very limited (TBD, requests wanted) set of higher level APIs that can accomplish some of what can now be done through pref access. WebExtensions will be able to indirectly flip (bools only?) a limited number of (TBD) abstracted settings via a module that handles the underlying details. So I'm thinking there may be a substantial reduction in what can be done via extension (which might also affect some autoconfig accessible APIs). The insistence on limited, abstracted-only access might be also be telegraphing significant future reductions in what user-adjustable settings are supported in general.
I wonder if this will cause a ripple effect to apps such as AdGuard for Windows (not addon version), where one can disable Browser APIs such as WebRTC, Push, Location, plus other misc things under the Stealth Mode tab.
@marzametal: That is an interesting question, and I'd ask the appropriate dev. As you probably know, a proxy/MITM acts by tampering with traffic. In the base case, such a component doesn't really disable Browser APIs. It tries to achieve the same effect through other techniques such as blocking traffic a browser API would trigger, blocking/altering scripts that invoke the API, injecting counter scripts of its own, modifying/injecting CSP directives, stripping/adjusting other headers, etc. However, such a component might [also] try to control browser settings/API/behavior by: Altering a browser-configuration-controlling file/component that the browser retrieves from a remote server. Assumes the browser actually retrieves something like that and that feature is enabled and the retrieval mechanism isn't protected against such tampering. Mere reliance upon HTTPS wouldn't do if the tool is already MITMing things at that level. Now I'm wondering how well protected Firefox is on this front. Altering browser configuration through a helper extension Altering browser configuration by leveraging one of the mechanisms that is available to the user (such as user.js, autoconfig, or the like)
Let me please add my two cents to this discussion. It happens so, that I am also an addons reviewer for AMO (not very active though, I review several addons monthly). So, there was an active discussion in amo editors mailing list about XUL deprecation, webextensions and such. There was a lot of hate towards Mozilla due to the WE transition (I wish I could share downthemall! author's email with you, it was hateful and really hilarious at the same time). I don't really understand myself what's the reason for such a haste. Also some add-ons simply cannot be transitioned to WE (like NoScript and DownThemAll for instance). Either they'll get a special treatment from Mozilla (if they are popular enough) or will be abandoned. Even though, my personal opinion is that WE transition is a right decision. Timing might be wrong indeed, they'd better wait until WE becomes more functional than Chromium. But anyway, all these different add-ons APIs zoo is holding FF back, it is very hard to support everything. Why do you think e10s transition took THAT much time? Let me please share the relevant presentation about WebExtensions platform with you: https://docs.google.com/presentatio...ioaw9DzYxue-RXU/edit#slide=id.g19b3cc96fc_0_3 Here are some key points: 1. WebExtensions have become the most common type of extension submitted to AMO (65% of new add-on submissions in November) 2. Mozilla aren't planning to just become a heavier Chromium. They are planning to extend WebExtensions platform, coming next 6 months: Sidebars and other persistent UI, Improving request handling, File system access, New theme support 3. Despite of the point 2, I doubt WE will ever be on par with XPCOM/XUL. edit: oh, I should read better before posting. Reading @TheWindBringeth post I've decided the thread is about WE transition Anyway, I hope my post may be useful.
Absolutely true. There is no cross-browser way to really disable browser api (for some browsers there's no way at all), so what we do is using counter scripts, CSP, and sometimes block it on protocol level (for instance WebRTC can be detected&blocked).
idd Mozilla have some hand for it in the shorter past^^ nevertheless no worry here - my firefox is handmade screwed but working proper. i also have really problems to realise why people have so much trouble when they use addons. same user using chromium releases beside firefox always moan about firefox but in direct comparison chromium releases had much more changes. most reason for using older firefox is the australis design, lot of users got stuck at version 29, or 42 - minor at 3.5. but the most forget that all trouble is self-made - by using addons. i dont know examples for the real world but software is complete different. if possible and i could spend time on webextensions i would try to use those i already have installed in opera - to minimize the work for it. i know some who has installed ~240 extension, half of it active. each update in the closer past made him issues. guess why - the simplest solution is not - he doubt. one major point for less users - "paternalism" - "the evil mozilla dont let us do our way". ok, for few users it seems so, not for the most - like the most of software creators mozilla take some responsibility. better this way then modify instead modify to get security. i had similar with linux - it wont let me do things which i can do easy with windows - i had to learn. or i have opera parallel working - stupid opera first sight, but now similar to firefox. it took some time. every day usage need to learn about. i wrote about backup, my daily bread for my computer, more or less. concerning firefox - i create new profiles for each new version from the old one. i had made some (bad) experience with going back/forward with the same profile. some changes dont work on older versions. exchanging extensions, last was secure login OUT and LogMeIn IN - LogMeIn is e10s compatible, the other not. HTH
