Hi All/Mike, My apologies for spinning up another thread. The original seemed like it was getting cluttered, and I believe the cause has been found. In this installation, the Tor bundle was installed in %PROGRAMFILES%. Specifically, C:\Program Files (x86)\Tor Browser. If I run "Start Tor Browser.exe" as a regular user, I receive an error message, "Firefox is already running, but not responding...". See "tor-firefox-windows-already-running.png" at http://postimg.org/image/cf8ily0sp/. When I trace the processes involved (Start Tor, Tor, and Firefox) using Sysinternal's Process Monitor, it appears Firefox is trying to write a lock file in %PROGRAMFILES%. The lock file is ...\Tor Browser\FirefoxPortable\Data\Profile\parent.lock, and it results in an ACCESS_DENIED. See "tor-firefox-windows-access-denied.png" at http://postimg.org/image/xlzmb3j1b/. If I run "Start Tor Browser.exe" as an Administrator, the browser works fine. When the Tor Browser is launched after installation (as part of the installation), the browser works fine. I believe this is because the setup/install program is not dropping privileges after it completes. In this case, FirefoxPortable should probably be writing its lock file to a temporary directory or the User's application data directory (CSIDL_APPDATA or FOLDERID_RoamingAppData, http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457%28v=vs.85%2...). It should not attempt to write to a read/execute directory. Jeff On Fri, Jun 14, 2013 at 10:39 PM, Mike Perry <mikeperry@torproject.org> wrote:

The new TBB 3.0 series is almost ready for its first alpha release!

Here are the major highlights of the 3.0 series:

1. Usability, usability, usability! We've attempted to solve several major usability issues in this series, including:

A. No more Vidalia. The Tor process management is handled by the Tor Launcher extension. If you want the Vidalia features, you can point an existing Vidalia binary at control port 9151 after Tor Browser has launched, and it should still work.

B. The browser now uses a local about:tor homepage instead of check.torproject.org. A local verification against the control port is still performed, to ensure Tor is working, and a link to check.torproject.org is provided from the about:Tor homepage for manual verification as well.

C. For Windows users: an NSIS-based extractor now guides you through the TBB extraction and ensures the extracted bundle ends up on your Desktop, or in a known location chosen by you. Hopefully this will mean no more losing track of the extracted bundle files!

2. The bundles are all under the 25M gmail attachment size limit, so direct email and gettor attachments are once again possible.

3. We now use Gitian to build the bundles. The idea behind Gitian is to allow independent people to take our source code and produce exactly identical binaries on their own. We're not quite at the point where you always get a matching build, but the remaining differences are minor, and within a couple more releases we should have it fully reproducible. For now, we are posting all of the builds for comparison, and you can of course build and compare your own: https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/git...

Please try these out, test them, and give us feedback! The plan is to post them on the blog by Monday, unless something goes horribly wrong.