Testing Tor Browser Bundle 1.2.0-dev

1) Changing the executable name ("firefox.exe") in FirefoxPortable.ini to "tbb-firefox.exe" solved the problem here. Without this change, FirefoxPortable.exe, if directly executed (without the rest of TBB already running) says "Mozilla Firefox Portable Edition cannot be started. You may wish to re-install to fix this issue. (ERROR: firefox.exe could not be found)". And no, I didn't mean to say this bug interfered with the normal operation of TBB, only that it prevents firefoxportable.exe from being directly executed if someone wants to start the TBB bundle's copy of Firefox Portable all by itself for various testing purposes.

2) By "the plugin scanning options still work", did you mean to say that the user_pref() options being stripped from prefs.js still have an effect on Firefox because they remain in "invalidprefs.js"? If so, I beg to differ. :)

Here's what happens, according to filemon, the very first time "start tor browser.exe" is executed (after a fresh unpacking of the 7Z executable):

(a) VIDALIA queries FirefoxPortable\App\DefaultData\Profile\prefs.js (result: SUCCESS/FOUND)
(b) VIDALIA queries FirefoxPortable\Data\profile\prefs.js (result: NOT FOUND)
(c) VIDALIA opens FirefoxPortable\App\DefaultData\Profile\prefs.js
(d) VIDALIA creates FirefoxPortable\Data\profile\prefs.js
(e) VIDALIA copies all 5545 bytes of FirefoxPortable\App\DefaultData\Profile\prefs.js to FirefoxPortable\Data\profile\prefs.js
(f) VIDALIA closes FirefoxPortable\App\DefaultData\Profile\prefs.js
(g) VIDALIA closes FirefoxPortable\Data\profile\prefs.js

So it's clear the intent so far is making a verbatim copy of prefs.js from the App locale to the Data locale. With that in mind, later on in the "start tor browser.exe" startup process, Firefox gets executed and this is observed by filemon:

(h) TBB-FIREFOX queries FirefoxPortable\Data\profile\prefs.js
(i) TBB-FIREFOX opens FirefoxPortable\Data\profile\prefs.js
(j) TBB-FIREFOX reads all 5545 bytes of FirefoxPortable\Data\profile\prefs.js
(k) TBB-FIREFOX closes FirefoxPortable\Data\profile\prefs.js
(l) TBB-FIREFOX opens FirefoxPortable\Data\profile\prefs.js
(m) TBB-FIREFOX creates FirefoxPortable\Data\profile\invalidprefs.js
(n) TBB-FIREFOX reads all 5545 bytes of FirefoxPortable\Data\profile\prefs.js
(o) TBB-FIREFOX writes 5545 bytes to FirefoxPortable\Data\profile\invalidprefs.js
(p) TBB-FIREFOX closes FirefoxPortable\Data\profile\prefs.js
(q) TBB-FIREFOX closes FirefoxPortable\Data\profile\invalidprefs.js

And based upon continuous filemon observation, that is the ONLY time "invalidprefs.js" is EVER accesssed for the entire life of the TBB installation. (I.e. it's never touched again for the remainder of the first execution of "start tor browser.exe", and it's not touched even once during any later executions thereof.)

And because only "invalidprefs.js" contains your anti-plugin-scanning options (i.e. because Firefox is stripping them out of the new "prefs.js" it creates after creating "invalidprefs.js" itself), those options are literally thrown away, permanently, the instant TBB starts for the first time.

In fact, more than just your anti-plugin-scanning options are being thrown away. Here is what IS NOT in FirefoxPortable\Data\profile\prefs.js (but IS in invalidprefs.js and in FirefoxPortable\App\DefaultData\profile\prefs.js) after the very first execution of Firefox in TBB:

user_pref("urlclassifier.tableversion.goog-black-enchash", "1.55536");
user_pref("urlclassifier.tableversion.goog-black-url", "1.23256");
user_pref("urlclassifier.tableversion.goog-white-domain", "1.481");
user_pref("urlclassifier.tableversion.goog-white-url", "1.371");
user_pref("plugin.scan.SunJRE", 99.0);
user_pref("plugin.scan.WindowsMediaPlayer", 99.0);
user_pref("plugin.scan.4xPluginFolder", false);
user_pref("security.enable_java", false);
user_pref("signon.rememberSignons", false);
user_pref("general.useragent.locale", "en-US");

[Additionally, user_pref("general.productSub.override", "20080404") gets changed to "user_pref("general.productSub.override", "2009021910")]

Now that's quite bad. You may be right that torbutton thwarts *activation* of those plug-ins regardless of the plugin.scan.* options, but you're still losing the extra protection acquired by having them (having them = Firefox fails to realize they even exist and thus never *tries* to activate them), and even worse, you're losing several other critical options like the disabling of Java and remember-signons. Ouch! And of course, this can be confirmed just by starting TBB and looking in "Tools > Options > Content > Enable Java", where you will see it CHECKED. And in Tools > Add-Ons > Plugins, where you will see that Firefox is detecting Java, WMP, and NN4x plugins. (I'm not sure what security implications are involved in the loss of the urlclassifier and general.useragent options, and in general.productSub.override being changed, but yeah, they're toasted/altered too.)

So this is a serious problem. As far as why "invalidprefs.js" is being created and why the aforementioned options are being stripped from the new "prefs.js" Firefox creates at the same time, check this out:

https://bugzilla.mozilla.org/show_bug.cgi?id=361102
https://bugzilla.mozilla.org/attachment.cgi?id=245907&action=edit (relevant source code)

This seems to be a newish function designed to backup your prefs.js (to "invalidprefs.js") if your prefs.js contains unparseable lines -- and then discard all non-parseable lines from your prefs.js. That in mind, I looked through your FirefoxPortable\App\DefaultData\profile\prefs.js file, and did in deed find two unparseable lines:

user_pref("plugin.scan.SunJRE", 99.0);
user_pref("plugin.scan.WindowsMediaPlayer", 99.0);

Those should have quotes around the values, like this:

user_pref("plugin.scan.SunJRE", "99.0");
user_pref("plugin.scan.WindowsMediaPlayer", "99.0");

So here's what I tried. I completely deleted my TBB folder from my HDD. Then I re-extracted TBB fresh from the 7Z executable. But before running "start tor browser.exe" for the first time, I manually notepad-edited FirefoxPortable\App\DefaultData\profile\prefs.js and added the necessary quotes as shown above. THEN I ran "start tor browser.exe" for the first time. The results? No "invalidprefs.js" file was generated, AND absolutely NO options went missing from the FirefoxPortable\Data\profile\prefs.js file (not the plugin.scan.* options, not the security.enable_java option, not the signon.rememberSignons optin -- NONE were lost)!

So that's the fix. :)

Which I suppose means there are actually two bugs here:

* You simply need to fix your FirefoxPortable\App\DefaultData\profile\prefs.js file (add those quotes) and everything will be fine.

* Someone needs to tell Mozilla that Firefox has a bug which deletes some uncorrupted lines from prefs.js when removing corrupted ones.

Anyway. Thanks for listening and thanks for all your hard work on this great bundle.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Incidentally, I second some of the first commenter's suggested additions to your master FirefoxPortable\App\DefaultData\profile\prefs.js file. Specifically these:

user_pref("network.prefetch-next", false); - Definitely a good one. Disables Firefox downloading web pages the user didn't explicitly request. On the onion network, any unnecessary traffic can only be detrmimental, after all.

user_pref("plugin.scan.Acrobat", "99.0");
user_pref("plugin.scan.Quicktime", "99.0"); - Yup, these definitely should've been included when the 4x/WMP/SunJRE options were themselves added. Just don't forget the quotes. ;)

user_pref("browser.microsummary.updateGenerators", false); - Stops spontaneous microsummary-type phone-home-to-update-your-bookmarks traffic. The danger here is these phone-outs could happen when tor is enabled and again when tor is disabled (linking anonymous to non-anonymous identities through cookies set/read in each case). (See http://kb.mozillazine.org/Browser.microsummary.updateGenerators for more information.)

user_pref("network.hosts.pop_server", ""); - Good idea in general to blank this (the default hostname is 'mail'). I would also blank these other two: network.hosts.smtp_server and network.hosts.nntp_server.

user_pref("extensions.blocklist.enabled", false);
user_pref("extensions.blocklist.url", ""); - These two are also a good idea. The blocklist feature downloads a list of extensions considered malicious by Mozilla from addons.mozilla.org. So we encounter the same danger as with browser.microsummary.updateGenerators -- linking anonymous and non-anonymous identities could happen through this.

user_pref("browser.sessionstore.privacy_level", 2); - Another good idea, because I believe Firefox gives you the choice whether to save your tabs (i.e. current browsing state) to disk when closing it normally but does *not* offer you that choice if FF crashes (i.e. it immediately writes said info to disk so your next session will open with your previous tabs). Disabling the session restore feature entirely seems to be the only way to make sure unrequested writes-to-disk of browsing state information won't happen upon a FF crash.

user_pref("browser.chrome.site_icons", false);
user_pref("browser.chrome.favicons", false);
user_pref("browser.chrome.image_icons.max_size", 0); - Not sure why he suggested these, unless the favicon.ico files Firefox caches in its bookmarks file are ever updated at any time OTHER than when the user intentionally clicks one of those bookmarks. If they *are* updated at any other times, then the same anonymous/non-anonymous identity association problem previously mentioned would occur. Original commenter: do you know something I don't? TBB: In either case, if you do decide to implement these, be sure to also take http://kb.mozillazine.org/Browser.chrome.load_toolbar_icons into account (whose value can override these three).

I'm also confused by what the original commenter meant by "disable mime type" (huh?), and what the danger of having XMLHttpRequests enabled could be. Does Firefox not send XMLHttpRequests through the user-selected SOCKS/HTTP/FTP/Gopher proxies? Or maybe he was just concerned about XMLHttpRequests being used as "web bugs" for tracking)? Anyway, seems to me XMLHttpRequests is a fairly vital feature in the Web 2.0 world. Maybe the original poster can explain his reasoning behind suggesting it be turned off?

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

And now a couple suggestions of my own (derived from comparing my personal prefs.js settings with TBB's):

user_pref("browser.download.manager.retention", 1); - Your current setting is 0. Changing this to "1" would make the DL manager list clear upon browser exit instead of immediately when each file stops downloading (which is what "0" causes). Reason I suggest "1" is, immediate clearing stops you from seeing "successful/done" vs. "failed" style messages for downloads that have stopped. So as long as changing to "1" causes no data to be written to disk (not confirmed by me), "1" would be the most user-friendly IMO.

user_pref("browser.send_pings", false); - A privacy risk (in the sense of web bugs) if enabled. Also a security risk if enabled (hovering your mouse over a link doesn't show you the URL your browser will hit as the "ping" itself). See http://kb.mozillazine.org/Browser.send_pings for more info.

user_pref("dom.event.contextmenu.enabled", false); - Stop various right-click hijacking/denial/alteration.

user_pref("plugin.expose_full_path", true); - VERY handy (makes exact full paths of each plugin filename firefox is detecting visible in about:plugins)

user_pref("extensions.getAddons.showPane", false); - Prevents the "Get Add-ons" pane from appearing in the Tools > Add-Ons dialogue. If this is enabled, Firefox phones out to Mozilla as soon as you bring this pane into view. Which poses yet another anonymous/non-anonymous identity association risk (via cookies) if accessed when tor is on and again when tor is off, or vice versa.

user_pref("xpinstall.whitelist.add", "");
user_pref("xpinstall.whitelist.add.103", ""); - In the current version of TBB, you have "xpinstall.whitelist.required" set to its default ("true"), which is what makes Tools > Options > Security > "Warn me when sites try to install add-ons" appear checked. However, the [Exceptions] button right next to that option contains "addons.mozilla.org" and "update.mozilla.org". Hence, no warning from those sites. Even though \FirefoxPortable\Data\profile\permissions.sqlite is where the list of those [Exceptions] is stored, "permissions.sqlite" is only generated when Firefox first runs, and its initial content ("addons.mozilla.org" and "update.mozilla.org") comes from the default values of these xpinstall.whitelist.add.* options. So, setting these xpinstall.whitelist.add.* options to blank strings prevents "addons.mozilla.org" and "update.mozilla.org" from becoming default entries in [Exceptions]. (FYI: once "permissions.sqlite" is generated for the first time, all future user changes to the Exceptions list are stored there; the xpinstall.whitelist.add.* options are apparently never altered again in prefs.js, even if the user adds "addons.mozilla.org" and "update.mozilla.org" themselves back to his/her Exceptions list.)

user_pref("browser.safebrowsing.malware.enabled", false); - I noticed you have "browser.safebrowsing.enabled" set "false" (which unchecks Tools > Options > Security > "Tell me if the site I'm visiting is a suspected forgery." But you have "Tell me if the site I'm visiting is a suspected attack site" checked. I'm assuming you don't want any "safe browsing" stuff enabled at all? If so, then adding "browser.safebrowsing.malware.enabled", and set false, will uncheck the "is a suspected attack site" option too.

user_pref("network.protocol-handler.external-default", false);
user_pref("network.protocol-handler.external.mailto", false);
user_pref("network.protocol-handler.external.news", false);
user_pref("network.protocol-handler.external.nntp", false);
user_pref("network.protocol-handler.external.snews", false); - Might be good to have these in addition to your existing "network.protocol-handler.warn-external.*" settings, as extra Firefox hardening. These (via "false") tell Firefox to handle those protocols exclusively internally (no external launching). And since Firefox can't handle these internally, these options effectively /dev/null these protocols (at least according to http://kb.mozillazine.org/Network.protocol-handler.external-default).

user_pref("privacy.sanitize.sanitizeOnShutdown", true); - Forces Ctrl+Shift+Del (Clear Private Data) to happen on FF shutdowns. If you decide to implement this, be sure to note the "privacy.item.*" prefs.js options explained at http://kb.mozillazine.org/About:config_entries (cache/cookies/downloads/formdata/history/offlineApps/passwords/sessions/siteprefs) ... because you'll want to add them (set true) so Firefox knows which ones to clear when the auto-sanitize happens.

user_pref("browser.history_expire_days", 0);
user_pref("browser.history_expire_days.mirror", 0); - These I think used to be in TBB but aren't now. Any reason why? (I see TBB still keeps no history info, but still, this is kind of concerning.)

Guess that's it. Pfew. :)

Is vidalia is safe?