There are several tools available online for comparing files. I'm finding it more difficult to compare TorBrowser with for example Pale Moon. Here is a small sample between TorBrowser (FirefoxESR) and Pale Moon. Tor is on the left and Pale Moon on right. TBB also includes NoScript, HTTPS Everywhere and TorButton preferences so a lot more work involved. NOTE: Some of Pale Moon default preferences have been changed.
Based on the lengths of the vertical scrollbars in your screencap... seems you are only diff'ing the (200 or so lines) in the TorBrowser profile.default/prefs.js file To gather the 1000+ prefs exposed in about:config, you can do the following: (TorBrowser 3.6.5 ships two "omni.ja" files, a 5Mb file in the top level installed directory, and another 3Mb omni.ja in the /browser/ subdirectory) Copy "/omni.ja" to (for instance) "top_omni.zip", create a new dir (e.g.) "top_omni_extracted" and extract the contents. Similarly, copy "/browser/omni.ja" to "omni.zip" and extract its contents to new dir (e.g.) "omni_extracted". Within the top-level omni you'll find default/pref/services-sync.js and the other omni houses a packed subdir defaults/preferences/ which contains: 000-tor-browser.js firefox-branding.js firefox-l10n.js firefox.js Collectively, AFAIK, their content comprises the overall set of prefs exposed in about:config Even armed with this long list, though, a diff will be forensically incomplete. You would (will) need to search the source code to find additional differences between which "undocumented" prefs exist. (undocumented, as in, will be recognized and acted upon if a config keyname suchandsuch is created, post-install, and assigned a value) To help with diff'ing, I can upload to pastebin.com code for a html page containing a "remove comment lines, sort and array_unique()" script. Output will be copy-able from 2 formfields ~~ you can save into new textfiles and view using "meld" diffing utility app (keeps left/right lines in sync and displays double-ended arrows, for visual reference)
FWIW, here is what I got using my own extension: Code: Firefox 32.0.2 Portable App: 2,193 prefs dumped Tor Browser 3.6.3: 2,651 prefs dumped Pale Moon 24.7.2 (x86) Portable: 2,058 prefs dumped These browsers weren't allowed an Internet connection and, apart from installing one extension, I didn't play with them or their settings. Some prefs get created as a result of usage and likely weren't present during the dump. Double check anything you think is .enable, because .enabled is by far the norm. Edit: Regenerated my own TorBrowser vs Palemoon diff. Comparing it to Compu KTed's pic, I see a few differences on the Palemoon side which can be dismissed. Otherwise, our diffs are identical. Even the line numbers match. Most of those preferences would not be found in prefs.js. IOW, it does seem consistent with "a small sample" of a fuller, expected list of preferences. I'd be interested to know the method used for getting the preferences into txt files.
The screenshot was taken from about:config preferences and not from the TorBrowser or Pale Moon profile files.(prefs.js) This was just a small selection of the about:config list I saved as txt files to compare both browsers. Isn't there an easier way to export just the data from the about:config page itself and then save it for comparing now and when browser gets updated? (all preferences) Haven't tried what inka recommended yet. As TheWindBringeth mentioned some preferences get created as result of usage. Page info about:config Type: application/vnd.mozilla.xul+xml
HOW did you do that save? I haven't found a way to copy/paste multiple lines from about:config or export the entries (using Firefox alone). Prototype code you can launch via CustomButtons extension or whatever... Edit: Code removed, updated version below
The slow time consuming not recommended way - copy/paste one line at a time and save to text editor. I managed to extract Pale Moon's 2 .ja files located in the install directory and browser subdirectory. Came up with the .js files and also greprefs.js file. (thanks to inka for sharing info) Looked into Mozilla default preference files (developer.mozilla.org website) greprefs.js - preferences shared by all applications using the Mozilla platform services/common/services-common.js - preferences for some shared services code, this should arguably be included in some other file defaults/pref/services-sync.js - default preferences for Firefox sync, also oddly misplaced browser/app/profile/channel-prefs.js - a file indicating the user's update channel. This is kept separate from other preferences because it can affect how updates are applied. browser/app/profile/firefox.js - defaults specific to Firefox browser/app/profile/firefox-branding.js - defaults specific to the specific kind of Firefox being installed (Nightly, Aurora, Beta, Release) browser/defaults/preferences/firefox-l10n.js - defaults specific to the installed language of Firefox. None of the other preference files contain locale-specific preferences. These preference settings set to default and do contain descriptions. Have created users.js file to keep track of changes I've made in about:config and there is also a list created by the browsers that show Important Modified Preferences in troubleshooting Information. (about:support) NOTE:This information (about:support) will help someone know how you have adjusted your installation of Firefox. Of course one can reset browser to default state or restart with Add-ons disabled if one runs into problems.
I'd be interested to know how you approached this and/or see that code. I started looking at Firefox omni extracted pref files earlier today. I spotted a number of dupe pref() calls, a number of conflicting pref() calls, and several multi-line pref() calls. Which would require some resolution. I decided to try this route: Edit: Code removed, updated version below
@TheWindBringeth Thanks for posting the prototype code. Was wondering when examining the list there are lines that don't line up exactly with the about:config preference lines. (not a big deal - can adjust) Also there is a large section of capability.policy.< policy name> preferences. They are listed in greprefs.js file and also when using CustomButtons extension and code you posted to produce the preferences. (greprefs.js file) // Default Capability Preferences: Security-Critical! // Editing these may create a security risk - be sure you know what you're doing //pref("capability.policy.default.barprop.visible.set", "UniversalXPConnect");
I revved the PrefFileMerger html file. Version is now in div at bottom. Partly because the earlier version wasn't overwriting prefs when a later pref() call had a different value. I think the basic approach is sound, but if anyone thinks it isn't and/or spots a bug please say so. Output from which tool? Lets refer to the first as PrefExporter and the second as PrefFileMerger. Can you show me a pic of what doesn't line up? So what is the question or problem? That //pref line is a comment line, as you may know.
I don't know if it matters what order preferences are in as long as they are all listed. Pale Moon 24.7.2 doesn't contain any capability.policy.<policy name> preferences in about:config. Can find them in greprefs.js file. Firefox 32.0.2 contains preference - capability.policy.default.SOAPCall.invokeVerifySourceHeader;allAccess I used CustomButtons extension with your prototype code posted and PrefExporter. ExamDiff reports 2131 lines of preferences when comparing. Minus the capability.policy... preferences I come up with 1979 lines.
Edit: Pref Exporter & Pref File Merger source deleted to prevent older versions from lingering in no longer editable posts. I intend to share improved versions in the not too distant future.
Thank you for the feedback. Both revved. Now sorting just on preference name; should match about:config. Changed default pref value separator to ; so that too should match. Various other changes. Looks like it hides capability.*, see https://github.com/MoonchildProduct...olkit/components/viewconfig/content/config.js Code: prefArray.forEach(function (prefName) { if (/^capability\./.test(prefName)) // avoid displaying "private" preferences return; fetchPref(prefName, gPrefArray.length); });
It's an html page containing a js-powered list-wrangling utility. Typically I resort to using this when diffing/merging blocklists (e.g. updated malwaredomains.com list into my DNSKong named.txt) I've pasted it to pastebin: http://pastebin.com/pVwJn39L Hard to keep up with the changes is an acceptable excuse for lack of tranparency?!? No, I'm not so forgiving... In fact, I've grown quite mistrustful of Mozoogle, based on the incessant stream of unwelcome changes (cough, cough, "features") which have been bundled into the firefox "release channel build" in ff versions 20 onward. Example: Initially, HealthReporting was optional (opt-in) but by doing it aboveboard, Moz only found a 3% acceptance rate... so they reneged, and HR was enabled by default. Further, as far as I can tell by checking clean install in a VM, the first-run (after HR is activated) "informed consent" page regarding HR is never displayed. REALLY pizzed me off when, after I had disabled HR, I discovered that a later pushed upgrade had "automagically" re-enabled it! Am I preaching to the choir? Do you understand where I'm coming from, or should I type out lamentations regarding a dozen or so additional Moz turn of events suggesting a shady/dubious agenda? For me, Pale Moon has never been an appealing alternative and, in any event, I'm in agreement with the "attitude" expressed recently in the mozillazine 3rd-party Builds subforum ~~ now that ff24esr is no longer being developed, I expect thed tagalong PM will wither and die. The current Tor Browser stable version is also 24esr-based, but their devs have been actively building a 31esr-based version as well. Speaks well toward TB's prospective longevity, but... Australis? Not for me, thanks. Anyhow, although I don't 'do' Tor, the TB 3.6.5 (with pre-installed extensions removed, and launched directly from the 'firefox.exe' executable is, for me, the "cleanest" current alternative. Ironically though (I'm thinking aloud here) I found that I disagreed with nearly 40 default preference(s) values, as shipped in TB 3.6.5 I am currently auditing the firefox v24.8esr source code, with intent to (re)build it to better suit me. In the process, I've confirmed several points of my suspicions that Mozoogle has notNOTnot designed the product with my (our) best interests in mind. No, I don't intend to discuss any details here. As a general remark, I will express my disdain toward Moz' hypocrisy; I'll also bemoan their practice of maintaining longstanding "embargoed bugs". Open source project? Hmm, sure isn't an open-source PRODUCT they're shipping ~~ hidden "features", known exploitable vectors unpatched in release channel, habitually, across spans of YEARS... and absence of documentation detailing the FULL set of "preferences". Actually, yes, I'll mention one detail, as an example of something which wasn't obvious, didn't even seem suspicious to me, until I had waded though the relevant source code: "NTLMauth". Just because I'm paranoid doesn't mean they're not out to get me, eh? Well, to my relief, the Tor Browser developers recently arrived at the same conclusion/realization I had, regarding firefox's inbuilt NTLM. Although I applaud your attention toward "what's what, with preferences", I'm convinced that tweaking user-set preferences (Moz overridable, during each lauch, when ff checks in with its mothership) amounts to "building a privacy fortress on a foundation of sand". Even if you're not a programmer by profession (I am not, FWIW) by downloading and perusing the firefox source code, you'll gain an understanding that the product is as much a swiss-army-knife SERVER as it is a "web browser".
Yes, really. Truly. HR was automagically re-enabled, without my knowledge/consent. My best guess as to how/why is: among the default preferences in the "release channel" firefox build: network.allow-experiments = true Back then, I hadn't yet scrounged to find what the hell that pref is/does/means. So, we're made to look like fools when we balk, and we meet skepticism like ~~ "What?!? Never happened for me!" ~~ "Naw! Mozilla would NEVER do that. They wouldn't dare..." "plausible deniability." Mozilla didn't invent it, but they've become damned proficient in practicing it.
@inka: Thanks for the script link. I will check it out. That "It is hard to keep up with FF changes. I doubt the list is perfect." comment you quoted was meant to be interpreted as: It is hard for me to keep up with FF changes, so the PrefsOfInterest_FF32.txt list I shared probably isn't as comprehensive as it should be. At this point I'm not prepared to commit to a broad source code review and my own builds. If you are, I wish you much success. FWIW, my basic approach is: Identify preferences/features of interest and research those (review related source code and bug reports, review full release notes, look for articles and discussions, etc). Address concerns through preference changes applied via autoconfig and lockPref(). I think this approach is in some ways better than making changes through GUI, about:config, and/or user.js. Including in terms of protecting against inappropriate resets of user modified preferences. Pay extra attention to those features that involve phone-home. Where applicable, disable the feature through preference changes and also take secondary steps to break the phone-home if it is attempted anyway. Example1: also change the preference that specifies the phone-home URL. I prefer to point those to a local server so I can more easily look for requests that shouldn't be happening. Others just set the pref values to an empty string. Example2: Use hosts file and/or DNS and/or proxy and/or firewall to block the phone-home requests you don't want to allow. Instead of automatic updates: download the files, check them, and then install updates while no Internet connection is active. This prevents phone-home during updates. Look over the new version, its preferences, etc. Update preference changes (autoconfig file) as necessary. Allow the new version to have an Internet connection only after you are satisfied with it's config. and that helped me avoid a few nasty surprises. At this point I think I am zero phone home except for extension blocklist downloads, but I'm still in the process of going over things. You thoughts on Tor Browser sound similar to my own. I'm intending to take a closer look at it once the 31 ESR base (and hopefully, security slider functionality) is in place. Meanwhile, I attempt to datamine it for ideas to apply to FF. Disabling support for NTLM and Negotiate sounds attractive to me. I'm not sure how the Tor developers are doing that. In FF 32 (Windows version) I found these related prefs and defaults: Code: network.auth.force-generic-ntlm;false network.auth.use-sspi;true network.automatic-ntlm-auth.allow-non-fqdn;false network.automatic-ntlm-auth.allow-proxies;true network.automatic-ntlm-auth.trusted-uris; network.negotiate-auth.allow-insecure-ntlm-v1-https;true network.negotiate-auth.allow-insecure-ntlm-v1;false network.negotiate-auth.allow-non-fqdn;false network.negotiate-auth.allow-proxies;true network.negotiate-auth.delegation-uris;false network.negotiate-auth.gsslib; network.negotiate-auth.trusted-uris; network.negotiate-auth.using-native-gsslib;true network.ntlm.send-lm-response;false I'm inclined to think these would best be changed from true to false: Code: network.automatic-ntlm-auth.allow-proxies network.negotiate-auth.allow-insecure-ntlm-v1-https network.negotiate-auth.allow-proxies but to be honest this is an area I'm not very knowledgeable about. Do you have any specific advice on NTLM and/or Negotiate related preference settings in latest Firefox?
IMO, users need to rethink this "gotta stay current" mentality that's been rammed down everyones throat. The majority of the browser updates are cosmetic and/or feature creep, many of which are not necessary or desirable. Is a patched vulnerability worth the negative privacy changes? Is it really worth going through all of those settings every time they release a new version?
Code: browser.contentHandlers.types.0.title;My Yahoo! browser.contentHandlers.types.0.uri;http://add.my.yahoo.com/rss?url=%s browser.menu.showCharacterEncoding;false browser.search.defaultenginename;DuckDuckGo browser.search.order.1;DuckDuckGo browser.search.order.2;Google browser.search.order.3;Yahoo browser.search.order.4;Bing about:config // also noticed {browser.menu.showCharacterEncoding} shown as string set to false Code: browser.contentHandlers.types.0.title;chrome://browser-region/locale/region.properties browser.contentHandlers.types.0.uri;chrome://browser-region/locale/region.properties browser.menu.showCharacterEncoding;chrome://browser/locale/browser.properties browser.search.defaultenginename;chrome://browser-region/locale/region.properties browser.search.order.1;chrome://browser-region/locale/region.properties browser.search.order.2;chrome://browser-region/locale/region.properties browser.search.order.3;chrome://browser-region/locale/region.properties browser.search.order.4;chrome://browser-region/locale/region.properties CustomButtons/PrefExporter 0.3 // exported prefs including pre-existing extension preferences. Prefs I mentioned earlier are now in right order. Good job!
@Compu KTed: Your Palemoon about:config is displaying a preference named {browser.menu.showCharacterEncoding} ? With curly braces? I am not seeing one in mine. I manually verified that a preference with such a name can be created. What does the status column say for that entry? The exportComplexValues option, enabled by default, in Pref Exporter 0.4 should address your second issue. There are some other changes that may be of interest. Scroll up a bit and grab a copy. At this point I can't think of a good reason to spend more time on Pref File Merger. So it remains at 0.3 and now lacks features that Pref Exporter has.
@TheWindBringeth browser.menu.showCharacterEncoding;false // this pref Status is set as default. I'm assuming this is one of the default strings already present in browser and not created by user. Code preferences in post #42 have been adjusted and match. (ExporterPref 0.4 code used) { } // just added that to Wilders post - not in actual above preference. Also noticed if you edit PrefExporter file you get this:  accessibility.accesskeycausesactivation;true So far the only pref differences I see are ones set by browser usage. Continuing to work through all about:config preferences to see if more changes are needed and maybe go through greprefs.js file. Hopefully if everything gets completed I'll do compare and post results.
Are you saying that you can actually defeat browser fingerprinting by going into about:config and making these changes?
I'm lost. If you think there is a problem, please provide a more detailed description and/or a pic so I can see exactly what you are seeing and where you are seeing it. Looks like a BOM at the front of the file. PrefExporter does not explicitly insert one (I might make that an option) and I haven't seen one inserted by the browsers I'm testing with. I checked with a hex editor to be sure. Perhaps the tool you used to manipulate the export file inserted it? FWIW, I've run into some UTF-8 related problems myself. AFAICT, some programs don't auto-detect that the export file is UTF-8 and thus don't display things the way that other programs do. Similarly, if I edit the file and save it, some tools save it in a different format. The intl.ellipsis preference value is one place where this has shown up. In the intl.properties file the value exists as 0xE2 0x80 0xA6 and that is what I see PrefExporter writing to the export file. However, some other tools convert the value to 0x85. Which can throw off diffs. Thanks for the testing/feedback.
You can click the "diff" link in this page to directly view the Tor Browser code change that short-circuits the NTLM auth function https://gitweb.torproject.org/tor-browser.git/commit/9ee3a8fe9824085a14281974095e69eeeae298c6 The values you posted for the NTLM prefs seem sensible. Without editing the cource code, there's nothing further to be done. From your "pref exporter", looks like you already understand this: Distributors of mozilla-built firefox (as well as corporate IT admins), can edit and repack omni.ja prior to redistribution. Each startup, the app overlays/overrides the "bone stock" values for any same-named pref keys found in the distributor's prefs files... followed by overlaying values from user.js (minus any for which prefIsLocked has been set). In firefox version 24.8esr (also Tor Browser v3.6.5), prefs seem to be respected; DNS proxy hasn't logged any DNS requests indicative of phone-home callouts. I hear ya about changing the prefs containing services.mozilla.org URLs. I have blanked those but it occurred to me that, if blank, firefox might might fallback to using the default (the pref value contained in the omni.ja copy of the prefs file(s)). That's something on my todo list to check out. FWIW, that (hiding capability.* prefs, aka "private" prefs) is identical/same as the stock firefox code. The combined prefs changes will not entirely defeat fingerprinting. No, disabling caching doesn't impede video playback, nor gif animation. (change the prefs and test this, to check for yourself) Using Sandboxie instead of disabling ff cache.memory is preferable, IMO.
Your browser reveals various bits of info that allows for "browser fingerprinting". Things like JavaScript, Java, flash, fonts, your useragent string are all useful in uniquely identifying a browser. The goal is to reduce the entropy it provides. The 2 prefs comments on fingerprinting due to... come from a Torproject page. Can you totally eliminate browser fingerprinting? Not that I'm aware of.
