Some of the items Compu KTed mentions are contained in browser headers. Others are revealed by plugins, javascript, etc. Focusing on browser headers for the moment, there's more involved than the actual information contained in the headers. The order that those headers are sent is often unique to specific browsers. You can see this at Shields Up with the browser headers test. As far as I know, filtering proxies, extensions, and to an extent the browsers own configuration can change the data contained in individual headers, but they can't change the order that the browser sends those headers. I suspect that this is by design.
UTF-8 A text editor or web browser interpreting the text as ISO-8859-1 or CP1252 will display the characters  for this. The downloaded list created by using Custom Buttons extension and inserting PrefExporter code into extension doesn't contain the BOM in the pref I posted. It's only after opening & edit/delete some prefs with a text editor the BOM appears. The preference browser.menu.showCharacterEncoding;false shows as is. A default string set as false Both PrefExporter and about:config show same. If this is what your seeing then I'll take it as correct and not a problem. Thanks for info.
I see these in Tor Browser, Palemoon, and Firefox: Code: browser.menu.showCharacterEncoding;default;string;false Complex value from: chrome://browser/locale/browser.properties intl.menuitems.insertseparatorbeforeaccesskeys;default;string;true Complex value from: chrome://global/locale/intl.properties Seems OK per comments in those files, and consistent with the string=string format of those files. Good observation though.
I set it in my browser and as far as I can tell, I still can watch videos on YouTube and Dailymotion. I only use HTML5 though. Well, the tweak will prevent caching since the first place. Sandboxie will only contain the data and then wipe it after closing the sandbox. Heck, you don't even need Sandboxie to do the later, Firefox itself can be set to delete all browsing data upon exit.
I noticed to the about:config preference list contains characters in Unicode format. Look at preference network.IDN.blacklist_chars. Your right about programs don't auto-detect the export file is encoded UTF-8. Try saving the preference above in a different format. ANSI will give you a bunch of ?'s.
Code: // You MUST adjust this list of pref files, and order, to suit your purpose var prefFiles = ["greprefs.js", "services-sync.js", // Can't find this in an omni.ja // "services-common.js", "channel-prefs.js", "firefox.js", "firefox-branding.js", "firefox-l10n.js", // Leaving out this webapprt related file // "prefs.js" ]; The file services-common.js should only be present following a custom build in which testing or debug build option was declared enabled. Confusingly (to me), although services-common.js is absent in Tor Browser, that file is not mentioned within removed-files. FWIW, in the ff v24esr source code distribution, services-common.js declares only these 3 prefs Code: pref("services.common.log.logger.rest.request", "Debug"); pref("services.common.log.logger.rest.response", "Debug"); pref("services.common.storageservice.sendVersionInfo", true);
That's sort of what I was thinking, but didn't have the time to firmly establish as fact. So thanks for the info. I now suspect a slightly different load order than what I originally assumed, but haven't had the time to prove that either. In testing, it didn't make a difference since not every pref file conflicts with another. If you do reach a point where you are sure of order, know of a logging feature that could be turned on to reveal it, whatever... I'd welcome a post or PM. FWIW, the best I've been able to achieve is an 8 pref difference between prefs as exported and prefs as determined by merging pref files. That was with an unreleased version of Pref File Merger that can also load a copy of the prefs.js file that exists in the profile directory. I moved the last posted versions of Pref Exporter and Pref File Merger to my profile page. I'll try to setup a better means of sharing them before the next release.
What you're finding with a newer ff version may differ from what I'm seeing in 24esr source code. As to the order of loading prefs files, this reference is still current AFAIK: https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/A_brief_guide_to_Mozilla_preferences One of your posts mentions the prospect of using lockPref() That should be a fine solution but I've I've seldom seen it used. I've encountered only two extensions which employ lockPref(): NoScript and FlashBlock https://developer.mozilla.org/en-US/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig Distributors like Ubuntu and LinuxMint may be perversely using prefLock() as one of the mechanisms for preventing removal of their "search enhancer" addon. (Perverse, because the resulting affiliateID appended to search queries adds a fingerprinting datapoint). I dug through collected extensions, expecting to find that "preferences monitor" (nee "eCleaner") utilized lockPref(). No, it just observes, injects a prompt and offers a "cancel". Although the about:config "Status" column has the ability to display "locked" where appropriate... ...across 10 yrs of ff usage, I don't recall EVER seeing "locked" displayed for any pref. Interestingly (to me), even in v34esr as modded by Tor Browser devs, nothing is "locked" -- not even app.update.auto nor app.update.enabled nor (hello Tor users!) toolkit.telemetry.enabled. To be clear, in Tor Browser that last pref is set false by default (but it is not locked!) The posted version of your Pref Exporter was already elegant. I sorta lost track of a/the goal ~~ I'm just exploring. Knowing the source (firefox.js vs all.js vs prefs.js vs user.js) of each given pref might be interesting (toward comparing PaleMoon vs TorBrowser) ...but really need to code outside the box to collect that detail. Drilling down to determine how/why 500+ prefs are "missing" in one build vs another (as posted earlier in this thread), yeah that begs investigation. The XUL/js driving the stock ff 24esr about:config intentionally omits the display of the "private" (e.g. "capability.") prefs branch. Somehow, the rationale for the omission was toward "privacy". (A rogue extension might exfiltrate those prefs ?/?) The omission motivated a 2005 bugreport/complaint... which sat, unpatched, until early 2014. A few weeks after a patch exposed those prefs to viewing, a further patch removed the "capability" mechanism altogether ~~ deprecated in favor of storing same within permissions.sqlite In a fresh install, the "capability" branch wouldn't amount to 500 entries, but that's the largest chunk o' differences I would expect to notice.
An example of a lockPref created in PM. I haven't used this , but gave it a try. To verify that the preference is actually locked, go into the Config Editor (about:config) and look up the preference. If the lock was successfully applied, the entry appears in italic and should state locked in the status column.
Yes, that's the usage scenario I was referring to. Also discussed across several blog entries at http://mike.kaply.com/2012/03/16/customizing-firefox-autoconfig-files/. I've been meaning to take a look at his CCK2 Wizard extension but haven't done so yet: https://addons.mozilla.org/en-US/firefox/addon/cck2wizard/. That would be easy to do via Pref File Merger. I just don't find it very pleasant to use, because you first have to extract/gather said files. A script could make the extract/gather much easier though, and even pass the files in via query params. Since I've decided to rev it, I'll see what useful features I can stuff in. I'm inclined to think that an extension wouldn't be able to get in there early enough to hook such loads, and haven't seen anything to indicate the browser stores such detailed information. I'll keep an eye open though. TorBrowser: capability.* = 156 prefs TorBrowser: extensions.torbutton.* + extensions.torlauncher.* = 219 prefs TorBrowser: noscript.* = 339 prefs Firefox: services.sync.* = 122 prefs I quickly looked at probably the same bug reports the other day, after you mentioned that Palemoon's about:config filter was inherited. I knew I hadn't seen such a filter in release (recently, anyway), and figured that might be due to CAPS removal, but wasn't sure. I thought by "private" they meant "browser internal settings that few would be interested in and even fewer should be messing with". I recall discovering CAPS and thinking it would/could be quite valuable for fine-grained control. Even used it via autoconfig for awhile. Then dropped the idea once I heard it was on the hit list. I've at times wondered if we lost something important.
I think you'd normally see it in an autoconfig situation, which in turn you'd normally see in an environment where admins are configuring machines for use by others. I've wondered a) whether an extension could in some way modify an autoconfig locked pref, and b) whether lockPref would be useful to extensions. So this context provided an excuse to run some tests (via CustomButtons launched code). I *was* able to modify the runtime values of prefs that were set by lockPref() in an autoconfig file, and also able to modify prefs that were set by lockPref() in an extension. I'll do some more testing to double check, but at this point it appears to me that it offers "shallow" protection against an[other] extension. Edit: if one could be installed and it was inclined to make trouble. When I get a chance I'll look at the NoScript source to see what he is using it for.
These tools for viewing and exporting preference settings are quite interesting. Would it be possible to build these tools so they could import preferences, similar to the way PServ works with system services? It would be so nice to be able to import a configuration file that could lock down the browser.
Really? I few years ago I had Firefox set to delete everything. I opened it in Sandboxie, browsed, and deleted the sandbox. Dat files were left that showed websites that I had visited. But when I added Eraser nothing was left. So maybe this is true of Firefox now, but it didn't use to be. It use to leave data no matter what.
I have no certainty regarding that, but the tweak should disallow caching to start with, so even using Sandboxie for this specific purpose is not relevant anymore IMO.
Sandboxie and index.dat ( sandboxname\user\current\Local Settings\History\History.IE5\index.dat ) I checked just now, across several sandboxes. Apparently a index.dat is created each time a new sandbox is created. It is copied from the live filesystem, and its content reflects whatever was there (natively) when the dat file got copied. Natively, I use ccleaner utility to purge those dat files and various custom paths, but (obviously, now that I've looked) index.dat isn't always queaky clean at time of sandbox creation. "Dat files were left that showed websites that I had visited" No. I'm seeing mostly file:/// URIs in the datfiles, and nothing at all matching recently visited files or website URLs. (FWIW, my use is probably not "typical" sandboxie usage. Many of my sandboxes are several years old. Good way to prevent registry bloat, walling off programs which each install hundreds of regkeys) Jumping back and forth between versions, I've lost track of which ff version(s) natively cleanup macromedia..support..dangerWillRobinson..settings.sol files. I think ff20 did not, and ff24esr does. Respectfully, that statement / remembrance seems nonsensical. By design, datfiles of the app running sandboxed would not be written OUTSIDE the sandbox path. Upon "removing the sandbox" (not "delete sandbox contents"), those datfiles written to the sandbox path surely would not still remain. ==edit== retested: followinng "delete sandbox contents", the content of index.dat files which remain within the sandbox path reflect files I've accessed using explorer.exe (and the sandbox now contains nothing browser-related)
https://mail.mozilla.org/pipermail/firefox-dev/2014-September/002246.html Just to kick around autoconfig ideas... Code: Components.utils.import("resource://gre/modules/Services.jsm"); var inFirefox = (Services.appinfo.ID == "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"); if(inFirefox) { if(Services.vc.compare(Services.appinfo.platformVersion, "35pre") < 0) { // Versions prior to 35 lockPref("xpinstall.whitelist.add", ""); lockPref("xpinstall.whitelist.add.180", ""); lockPref("browser.uitour.whitelist.add.260", ""); lockPref("browser.uitour.whitelist.add.340", ""); ... } else { // Version 35 or later lockPref("permissions.manager.defaultsUrl", ""); ... } }
Shows both Firefox 32.0.3 and Pale Moon 24.7.2 Telemetry Data page. Click on: Click to toggle section to reveal more info. Both browsers indicate Telemetry as disabled.
"telemetry", as a component (er, service) collects performance profiling data whenever the "profiler.enabled" is set true. "toolkit.telemetry.enabled", as a preference, determines whether or not the info is transmitted to ht tps: // data.mozilla.com (or whatever destination is reflected in the "toolkit.telemetry.server" pref) You can audit you network traffic to verify that no outbounds to that domain are ever sent while false is set for "toolkit.telemetry.enabled". ps: IIRC, even if you currently have "profiler.enabled" set false (but that pref had been set true previously) the about:telemetry screen will still display (that stale) collected data. While profiling is enabled, or when it is re-enabled, the telemetry component self-deletes data older than 180 days -=- Hmm, theres also a 'devtools.profiler.enabled' pref...
FEBE (Firefox Environment Backup Extension) docs claim that it performs preferences backup, but (I just checked) it's only backing prefs.js (user_prefs, not a snapshot containing a full set of the current prefs. An extension named "PreferenceMonitor" (aka prefMon) will monitor for changes to prefs (pops an infoBar, where you can decline/revert changes as they occur) and (I tested) it catches creation of new prefkeys as well. What I feel is needed (and not available AFAIK) is an extension which exports a snapshot containing a full set of prefs+values to serve as a baseline... ...then, at each startup and perhaps again at timed intervals (on second thought, maybe just on-demand) compares against that baseline & reports the differences. Separate train of thought: Once a baseline is set, that could be fed through something like CCK ~~ so even if not locked, each of the desired values would be "recognized" as defaults and would not display in bold print (and a click of "sort by status" in about:config would float any changed-this-session prefs to top of the tree + they would be easily identified (few of 'em and displayed in bold print).
"Config Descriptions" extension https://addons.mozilla.org/en-US/firefox/addon/config-descriptions/ cleverly parses the various .js files containing prefs and extracts any comments/hints (outcommented lines, or end-of line comments). It adds a 4th column to the about:config treeview to display the extracted comments/descriptions it found. http://i.imgur.com/60ADAXK.png caveat: The manifest of .js filenames (and resource:// URIs) the extension checks is hardcoded, so unless you unzip the xpi and edit the listed filenames, the extension will not know to check (for instance) 000-tor-browser.js Unfortunately, relatively few prefs are accompanied within js file by a description/comment line... and some of the comments are unhelpful, like the comment "clipboard behavior" associated with the prefname "clipboard.autocopy" (Duh! really?) Although the extension "works, as described", I'm reminded that context menu links to lookup a given prefname at Mozilla KB or via Google (other extensions are available to add such) are probably more helpful. More often than not, a single-line of description text just isn't sufficient to describe / explain / enumerate values for a pref.
Ah, accessing pref files via resource URLs. Some of those (such as resource:///greprefs.js) aren't working for me. Perhaps I'll understand why once I look into it. Distracted by work ATM
"search term dot star" isn't an ideal pattern. Recheck TorBrowser and PaleMoon. You should find "network.allow-experiments" (and others, autocompleted as you type into the about:config searchbox e-x-p-e-r-i-m Earlier, I mentioned that I was foggy as to the goal. Okay overlapping goals (your goals, my goals, shared goals)... but here, I'm at a loss to understand: What do we gain from just knowing the comparative number of urlclassifier prefs, for instance? If the goal is simply to compare, reviewing the details displayed to about:buildconfig would certainly be more interesting for me than "counting how many prefs in each branch".
