Thanks, this seems to be a never ending story as new ones popup all the time. As a fresh Firefox user since a few months back, I wonder if I manually backup the profile folder e.g xxxxxx.default (by following the mozilla support article) will all these about:config changes move along so I don't need to do all this again incase I need to make a fresh Firefox installation so I can just replace the profile folder that is created at install with my backup ? Or is there something more that I need to backup apart from the profile folder ? Cheers.
you only need the "pref.js" file from the profile folder... thats where every setting is stored... well afaik that is... xD
@SweX: I've done the backup/restore of profile folder contents many times, and I used to "sync" Mozilla apps (Firefox, Thunderbird, ...) on different machines by transferring the profile folder contents. To reduce the chances of a problem, I only transferred the profile between identical application versions and the same OS (Firefox x.y.z profile on Win7 <-> Firefox x.y.z profile on Win7). It worked out well. However, there were some occasions when I spotted stale data in a profile. Whether that was due to a program update that didn't properly deal with the existing profile from an earlier version, the transferring of profiles, or something else, I don't know. I simply decided that it would be best to periodically do a full clean install of the Mozilla apps and extensions. That forced me to find a better way to save/apply pref changes. Prefs.js contains pref changes that you make PLUS pref changes made by extensions PLUS pref changes made by the program itself (it stores some variables in there). The file is meant to be application maintained, and I'm hesitant to think it is always safe to plop an old prefs.js into an otherwise fresh profile. User.js is a file that is meant to be user maintained, and I tried that for awhile. Eventually I discovered autoconfig and chose that route. The autoconfig file lives in the same directory as the application program and can apply things to multiple profiles. It can set prefs, set permissions, and do other things that help with clean installs. I'd suggest you go ahead and setup a system to backup/restore your profile folder. The profile holds not only prefs but permissions, bookmarks, cookies, passwords, certs, extensions, etc. So you'll want a backup of it anyway, and being able to backup/restore everything at once is very convenient. At some point though, you might want to think about ways to put your own changes in their own (commented) files.
Actually Mozilla based browsers also store prefs inside the omni.ja files. You would have to extract them to see all the contents. Also mentioned before is to use lockPref which can lock your about: config prefs settings from being changed.
I'm in the process of switching over to 37.0.1 and noticed a few things... 1) That connections.json file mentioned media.gmp-gmpopenh264.autoupdate, but not media.gmp-eme-adobe.autoupdate. The Adobe DRM support gets enabled in FF 38 I think. The not yet released GMPUtils.jsm presents related prefs in an organized fashion. See this.GMPPrefs = line: https://mxr.mozilla.org/mozilla-central/source/toolkit/modules/GMPUtils.jsm#73. Note that {0} gets replaced by GMP IDs (such as "gmp-gmpopenh264", "gmp-eme-adobe") in order to form full preferences. 2) I haven't played with a stock build in some time, so this round I took a quick look at some things and allowed the test install some access to the Internet (while running Wireshark and the HttpFox extension). I saw background (non-user-driven) HTTPS communication with search.yahoo.com in Wireshark which did not show up in HttpFox. Which is curious, since HttpFox shows other background traffic. This makes me suspect that there *might* be a bypass of normal capture (and possibly blocking) APIs when carrying out certain communication with search.yahoo.com. More info needed. Edit: Captured some via Firefox logging, looks like unused speculative connections to me. Which would seem to explain why no actual requests were logged. I forgot all about the speculative stuff as a result of always disabling it. 3) I saw a number of requests to self-repair.mozilla.org... WTF is that... search... http://www.ghacks.net/2015/03/11/firefox-to-get-self-heal-feature/ ... https://bugzilla.mozilla.org/show_bug.cgi?id=1031506... etc. For anyone else in the dark, the sales pitch in short: Mandatory Mozilla extension signing combined with revocation will assure Mozilla can block those extensions which it considers harmful, but it had/has no way to undo the changes made by such extensions. This self-repair mechanism will be used to make changes to the user's browser. Edit2: Currently, browser.selfsupport.enabled & browser.selfsupport.url. The latter is in that json list.
New user and just noticed this post. For a while I've been using a firefox build off sourceforge built for portability. Last build I checked was probably 36. Even after creating a huge 'user.js' file filled with all kinds of options to quiet down firefox, I still noticed it wanted to 'phone home' so to speak. Seems like every new build throws in some new privacy erosion feature? As it stands my user.js file has grown probably 5 times the size when I first started with the newer firefox base. I was wondering if all this advice and/or suggestions here in this thread or elsewhere could not be put into a singular file(s) like a 'user.js' so that any user could be assured of at least getting newer firefox incarnates to keep its mouth shut from the get go. Sort of a drop-in file anyone could get. Just wondering...
Welcome to Wilders, I like your idea, considering it's rather time consuming to find this by searching the Net and you end up in articles and forum threads that can be both old and new and may not be relevant today, so your idea would probably save time for others that are looking for this kind of info as well. Yes, the latest "feature" they released was Hello, and luckily it's quite easy for anyone that wants to disable it via about:config.
@TheWindBringeth Thank you, yes bookmarks was another thing that I would have to be included in the backup. Yeah I noticed a month or so back that if the profile name doesn't "match" Firefox will not startup at all and will show an error message, I was going to transfer something but I apparently did it wrong, and that was before I knew about that the profile name xxx.default had to match, otherwise firefox wouldn't startup at all, and that came as a surprise since I didn't know it was that sensitive it's just a browser.... About this, if I update Firefox and something essential needs to be changed in the prefs during the update (as it is application maintained) would lockPref prevent that from happening and it may not end well ? I really have to read up on how to make use of a User.js as I am very "green" on this if I go for that. Is Autoconfig and the User.js connected or is it two totally different ways of doing this ? Everything I have in my userChrome.css file has been found on the Internet and I have simply used copy&paste because I can't code css, and that works fine as I can just delete what I just added if I don't like how it turned out. Does copy&paste work for the Autoconfig and/or User.js too or is it more complex ? Sorry for all the questions, but the answers I have found on the Net wasn't that easy to understand for a new Firefox user.
Good question. No, it shouldn't be a problem. Basically, lockPref just prevents "user changes" (those made via GUI, read via prefs.js, read via user.js, or treated as such by the application or extension). The application and extensions can change a pref set with lockPref if/when they need to. Why use it then? Example: An admin uses lockPref in an autoconfig file which is stored in application bin dir. Thereby restricting what a non-admin user can do. The non-admin user doesn't have write access to the bin dir to change the autoconfig file. There may also be some benefits in scenarios involving purely well behaved extensions. It also helps to avoid an issue mentioned down below. Two different javascript files, with the autoconfig one being allowed more control over the application. The autoconfig file can be named whatever you want so you have to create/edit another file to instruct Firefox to use it. They aren't mutually exclusive BTW. You can use both at the same time, in which case processing order/priority comes into play. Yes, you can copy autoconfig examples you find into your autoconfig file and/or copy user.js examples you fine into your user.js file. When it comes to undoing such changes, sometimes you can just delete the lines you added to those files... sometimes you must do that *and* take an additional step to update the prefs.js file. More specifically, if you manipulate user values... pref() call in autoconfig or user_pref() call in user.js... Firefox will update prefs.js as necessary to reflect your changes. No problem so far. However, if you remove such lines in autoconfig or user.js, Firefox may not update prefs.js to reflect their removal. In which case you'll have a user_pref() call lingering in the prefs.js file and still having an effect. You'll have to remember to also take a step to remove that prefs.js entry. For example, by resetting the pref in about:config or carefully editing the prefs.js file when the browser is closed. Edit: I rephrased/simplified this section. Anyway, if/when you want to go the autoconfig or user.js route... look for some intro/tutorial material and read through it. Create a test profile to experiment with. Start with manipulating preferences that aren't used, such as TestPref1, TestPref2. Watch what happens, get a feel for things. Then try applying some simple and conservative changes to actual preferences. Graduated steps towards the goal. Move your changes over to your live profile after you have confidence in them (test important sites). Regardless of which approach you use, try to learn/understand what it is that the preferences do. You were smart enough to wonder if a user-applied something called lockPref could interfere with an update. You have the potential
Thank you very much for all the answers, it surely sounds useful and not too difficult to use once you fully understand all of it, but that may take a while. That copy&paste works fine for this is great to hear. Yes tutorials and guides are always a good first step, if I go this route I will be sure to check some of them out. And remember to set up a new profile that can be used for testing stuff out. Cheers!
Excellent thread... just went nuts and applied all the rules in a sandboxed x64 Pale Moon... Will upgrading to a new version of Pale Moon (over the current installed version) wipe about:config settings?
FWIW, I can't recall seeing any Mozilla application or derivative doing that. Only very limited use of PaleMoon though. Doing that would be a (major, in some cases) problem for those who upgrade that way (and many people do). However, that is a moment when a newer version of software must deal with potentially outdated preferences and other things. In general, I wouldn't totally rule out the possibility of some adjustments. It would be wise to backup your profile before (any type of update) and also review settings/prefs after (any type of update). As mentioned earlier in the thread, I personally like to compare prefs as they stand in the previous application version to prefs as they stand in the new application version. Looking for additions, subtractions, changes. Well, not like as in enjoy... like as in think it is best and do it
I'm leaving this here, it's a GitHub project to hardening the settings in Firefox. Here are also several interesting links if it comes to the security topic in Firefox: https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/ http://kb.mozillazine.org/Category:Security_and_privacy-related_preferences https://wiki.mozilla.org/CA:IncludedCAs http://forums.mozillazine.org/viewtopic.php?f=8&t=2627297 http://kb.mozillazine.org/Connections_established_on_startup_-_Firefox http://kb.mozillazine.org/About:config_entries Well, the stuff I love on Firefox is that most (if not all) stuff is very well documented and it's very easy to find and if needed to change. I wouldn't say that there is any hidden spying or something like that, so in my eyes there is no needed for any Firefox mod(s) since all can be controlled via prefs.js / user.js from the first start.
Each pref would need to be documented, so that anyone adopting use of the file can make an informed decision which to keep, which to outcomment... ...and, if user disagrees with a given pref value, should he change =1 to =0 or does it need to be =2 or (begs extensive docs) Across versions does prefname= 1 consistently continue to mean "1"? No. I recall multiple prefs for which the acceptable values have changed across versions (e.g. "true/false" became "0/1/2") Current firefox release contains over TWO THOUSAND preferences. Your "well documented" claim is unfounded ~~ "official" documentation pages across all mozilla websites (dev,wiki) do not cumulatively "explain" even half of those prefs. Nothing hidden?!? How about "HealthReporting will be OPT IN", then in next version release... they pulled a switcheroo (changed prefs so that release channel users were "opted in" by default). How about "oops, too many users have discovered network.experiments.enabled and set its value to false. Lets ignore that pref, and introduce 5 more experiments -related prefs and..." How about: "maintenanceService", which performs an end-run, bypassing windows UAC.... Buddy, here's a hidden gem for ya: During each startup, firefox sniffs your WINDOWS (or linux) USER ACCOUNT, and attempts to glean your firstname+lastname+email+loginPassword. We cannot disable this behavior via prefs, and my firm stance is that a "web browser" has no damned business retrieving such personally identifying info. (BTW, check it ~~ almost a year after a torproject bug report pointed this out, TorBrowser has not pared this from their codebase) (also, last I checked, same exists in PaleMoon's codebase) "at startup, browser gleans user FULL NAME (real name, given name) from O/S" https://trac.torproject.org/projects/tor/ticket/13398 You can view the relevant sourcecode online: mozilla / toolkit / components / startup / nsUserInfoWin.cpp http://lxr.mozilla.org/mozilla-release/source/toolkit/components/startup/nsUserInfoWin.cpp (nsUserInfoWin.cpp is only one of several {another for linux, another for mac} relevant sourcefiles) ================================== Now, sit up straight, pay attention: Regardless what you attempt to do, today, to mitigate the "ill behavior" of the current version "web browser"... THE NOOSE IS TIGHTENING. We are collectively being herded into a scenario in which the communication performed between the "web browser" and remote servers is NOT http traffic. SPDY and websockets ~~ by design, these represent indefinitely-long, continuous connections through which blackbox non-http traffic is conveyed. Not only have the mozilla devs oh-so-inconveniently not created APIs to observe these streams... ...even the remaining http/s traffic is (again, by design) continually gaining protection / immunity to user or extension intervention. To wit, here's one of the latest greatest "features" coming down the mozilla pike: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Basic_concepts (service worker objects can establish 'guards', enforcing that the headers born by requests they generate are 'immutable') We're being subjected to a paradigm shift. Privacy be damned. USER-AGENT --} WEB CLIENT The former placed requests on behalf of (and at the request of) the user, interpreted the response, and generated human-friendly output. The latter... establishes a connection between PC (or other device) and remote servers, turning the device into "eyes and ears, plus whatever additional i/o... and localstorage", thereby providing "The Web" a "remote presence" on the device.
I could be wrong and I am just speculating but I have to say I was suspicious about the tails devs decision to replace iceweasel with firefox. I have been wondering how many of the devs we trust have been coerced into sacrificing our privacy by claims that pedophiles etc are using their software to remain anonymous. I have similar concerns about the secret messenger service devs dropping it because of claims cyber bullies use it. We know multi billion dollar agencies are going all out to attack privacy and anonymity and social engineering can be just as powerful a tool as legislation to put a stop to something, if not more so.
Just prior to the australis release, I compared ("diff"ed) iceweasel vs firefox sourcecode. I found ZERO remarkable functional differences. Iceweasel ships with a few prefs set to different default values, and that's about it. Have code differences emerged within the past year? I doubt it, considering the iceweasel "staff" is nearly nil, like: 2 dudes and a poodle. So, if the Tails distro is now shipping firefox (vs iceweasel), as "insecure browser", in addition to TorBrowser... does it even matter? In any case, that change may have been due to necessity rather than choice. TorBrowser tracks (develops against) firefox ESR versions and when they moved to ff 31ESR for the TorBrowser v4.xx builds, iceweasel at that time may have still been (idunno, I didn't "fact check" here) shipping earlier, pre-australis, firefox code. Without the changeover, user confusion would have ensued: "hey, my addons work in the 'insecure browser'... but same are broken in TorBrowser" From where I sit, here's the "and": The inbuilt mozilla update mechanism, replete with "maintenanceService" functionality, is triggered each time the browser launches (and, during long-running sessions, a timer performs additional update checks each 24hrs). Yes, the update mechanism is comparatively secure and (but) Mozilla "holds the keys". To those "multi billion dollar agencies", what's it worth to have on-demand backdoor access (out-of-band) to any firefox-installed device? Cha-ching! In addition to "slurping private data" via the updater, kiddie porn (or whatnot) could be downloaded onto the PC -- planted, in order to 'frame' a targeted "person of interest". Further, referring back to the issue I mentioned above, from gleaning user credentials (including domain/LAN login) the software stands ready to serve as on-demand "eyes and ears" -- from user devices within/behind private or corporate firewalls. This isn't tinfoil hat speculation. The mechanism for doing the above is REAL, and it's in place and functional within current "release channel" firefox. torproject lost my trust/respect when they decided to introduce the mozilla-created "update" mechanism into TorBrowser, and to setup their own update server(s). Cha-ching! Curiously (I'm sayin), within a few weeks mozila began wooing 'em... c'mon, drop what you're doing and let's be buddies. Ship OUR browser; use OUR update servers. Regardless how it plays out, I object to the inclusion of an out-of-band "updater" mechanism.
I do think we need to be concerned about persistent/sticky "connections", or rather "sessions". Especially if such a session can be multiplexed to carry traffic for different contexts (such as two different browsing windows open to the same site). Of greatest concern, I think, would be the ability to maintain sessions across context closings. For example, the ability to resume a session after closing all browsing windows and going back to the same site. Particularly if it is possible to resume a session despite an IP Address change. We want cookie-like behavior (the ability to correlate activity) to be a function of things we CAN change or block... we don't want it built into newer protocols that we may eventually have to use. I haven't studied SPDY or HTTP/2 properly, or for that matter QUIC. If someone has, and believes that one or more poses such such a threat *in practice*, I'd welcome a brief technical description as to why. Regarding websockets, there should be an upgrade request sent over http(s) and that is what you'd want to block. It is a shame that we have to install extensions in order to properly control behaviors, but that is our reality at present. In this case, I think an extension *should* be able to block *all/any* websocket use by targeting the upgrade request/response traffic. Even that generated by Mozilla's built-in features running off the main thread. If anyone knows of a test case where that doesn't work, please describe it or point to it. One extension I would try is uBlock, but I'm not up to speed on it. Regarding the Fetch API and immutable headers: It sounds like it could be a problem if implemented in certain ways, but is it an actual problem from an extension's point of view? IOW, has someone tested things and verified that an extension can't block or modify fetch requests/responses as desired?
QUIC is already deprecated. SPDY3 (er, 3.1) is the current flavor of the day. http://www.ghacks.net/2015/05/01/mozilla-deprecating-non-secure-http/ Although we can MITMproxy our https traffic... and can employ "an extension" to marshall the requests/responses which comprise that traffic. In contrast, SPDY is a tunnel, a black hole. Inside the TLS envelope, the traffic borne by its stream will not necessarily contain "requests"... and extension developers are provided no APIs (no "observable topics", no "on-condition-met" events) to marshall the stream. As of today, we can set prefs to disable SPDY. By year's end, I expect google et al will refuse to support "fallback" in case SPDY is not available. I'm already seeing, with increasing frequency, a generic banner conditionally displayed when visiting youtube and other google web properties "there was a problem... click HERE to upgrade to a modern browser". (Not steering user to adopting Chrome, specifically; more along the lines of "our way or the highway"... or "we don't serve YOUR kind here") Yes, across contexts, across windows... and under multiprocess firefox, via IPC (interprocess communication). That functionality is touted as a "feature" for ServiceWorkers (available for use within, but not exclusive to, SPDY and websocket streams). https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker_API "Service workers essentially act as proxy servers that sit between web applications, and the browser and network (when available.) They are intended to (amongst other things) enable the creation of effective offline experiences, intercepting network requests and taking appropriate action based on whether the network is available and updated assets reside on the server. They will also allow access to push notifications and background sync APIs" https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Basic_concepts "Fetch is basically a modern equivalent to XMLHttpRequest, which offers a lot of the same functionality, but designed in a more logical, extensible, efficient manner." Sounds fairly cut-and-dry. Which part of "immutable" dontcha unnerstand? I thought I'd already posted/ranted about this. https://developer.mozilla.org/en-US/Firefox/Releases/35 "The preference network.websocket.enabled, true by default, has been removed; Websocket API cannot be deactivated anymore (bug 1091016)" ^------------- verbatim, from releaseNotes page see also: https://bugzilla.mozilla.org/show_bug.cgi?id=1091016 Today, yes. Tomorrow... ServiceWorker 'guards' the remote server's response, granting immutable headers.
OK, but extensions developers do have ways to observe/modify/block higher level events. So there is at least some potential to police its use by policing what enters/exits, is there not? Based on very limited reading mind you, but I think ServiceWorkers are a higher level construct that may be capable of causing problems across contexts. However, what I was trying to determine is whether the new lower level communications protocols have inherent issues in this regard. A good example would be a protocol that requires the use of a session identifier which is passed to the remote server each time in order to resume a session. That's is, or could be, the equivalent of an evercookie that can't be avoided. So regardless of whether ServerWorkers are issuing requests or the user is navigating, everything becomes "autocorrelated" due to the way the lower level protocol works. We can't afford to have the rug pulled out from underneath us. I feel like I/we need to establish whether it is immutable from the point of view of Javascript utilizing the web API, immutable from the point of view of an extension, or both. If there is some "protection" against extension "tampering"... prohibition of end user enforced security/privacy enhancements, for those who think that way... then the question becomes whether the requests/responses are blockable in full. I saw that bug and your comment about it. Note that it refers to pref based control. Separate from that question is whether an extension can intercept/block all of the upgrade requests. Just trying to nail down what we can, or can't, do... at present.
According to the what the dev posted to the bugzilla ticket, websockets cannot be disabled on the main thread, period, and that's evident in the code commit. The 'issue' motivating this drastic decision (which was 'resolved' within 2 days of being reported, dontchaknow) was MozillaHello being 'broken' by users choosing to disable websockets via prefs. "the question becomes whether the requests/responses are blockable in full." Exactly. And how would one accomplish that? By stripping any "Upgrade: websocket" header. ------------v Yes, ServiceWorker is a higher level construct, but it stands as a valid example of how 'immutable' could be employed/invoked to 'guard' against tampering by extensions. (Content scripts cannot see/tamper http headers, so no need to guard against those). http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1 "The SPDY framing layer (or "session") runs atop a reliable transport layer such as TCP. The client is the TCP connection initiator. SPDY connections are persistent connections." Aside from setting a low (short) value for network.http.spdy.timeout, or disabling SPDY altogether (cut off my nose to spite my face, eh) I'm at a loss how to avoid "autocorrelation"
I had a moment and decided to try something. I modified an extension to reject all TYPE_WEBSOCKET in shouldLoad. Installed it in Firefox Portable 37.0.2. Tested it against https://www.websocket.org/echo.html and it blocked the connection. Then tried it against Firefox Hello. Now I've never enabled that outside of brief unrelated testing, and never even tried to use. So I'm not sure of the different paths that would need to be tested. However, I got to the point where you Start a Conversation without seeing any websocket related activity. Then clicked on the button and a received a Something went wrong message box. From the browser console: [MyExtension] shouldLoad TYPE_WEBSOCKET detected bootstrap.js:61:0 [MyExtension] Rejected TYPE_WEBSOCKET bootstrap.js:61:0 "WebSocketConnection:null:Could not connect to the Rumor socket, possibly because of a blocked port." sdk.js:910:14 "OT.exception :: title: Connect Failed (1006) msg: WebSocketConnection:null:Could not connect to the Rumor socket, possibly because of a blocked port." sdk.js:910:14 "Failed to complete connection" Object { code: 1006, message: "WebSocketConnection:null:Could not connect to the Rumor socket, possibly because of a blocked port." } otSdkDriver.js:197:8 Which leaves me somewhat hopeful. Selective modification of headers can be used to neutralize things. However, there is also the ability to simply block outbound requests. I haven't looked for a way to block inbound responses, but I have seen example code for throwing away the real response and substituting your own. All approaches would have to be explored before declaring something impossible. Well, the "could be..." bothers me. It creates a concern. One that is legitimate I think. Yet it doesn't really answer the question: is this definitely a problem that we absolutely can't work around? I'll take a look at that when I'm fresher and can concentrate.
There is a "network.http.spdy.enabled" setting in about:config... set to true. Wouldn't swapping it to false be enough?
I'm not using the current version of firefox. Even in this older version, _multiple_ prefs exist related to SPDY. network.http.spdy.enabled network.http.spdy.enabled.v2 network.http.spdy.enabled.v3 Yes, currently, setting each of the above to false seems to be "enough" to prevent SPDY.
