Tor Browser 4.0 is ready for testing
Hi, Tor Browser 4.0 is up for testing: https://people.torproject.org/~mikeperry/builds/4.0/ This is the first release in the 4.0 stable series and contains most notably the switch to Firefox ESR 31 as the base for Tor Browser and the switch to the 0.2.5.x series for tor. Moreover, the updater in Tor Browser is shipped for the first time to stable users which replaces the cumbersome and manual update process we currently have. The full changelog with all the new things compared to the last alpha release is: Tor Browser 4.0 -- Oct 14 2014 * All Platforms * Update Firefox to 31.2.0esr * Update Torbutton to 1.7.0.1 * Bug 13378: Prevent addon reordering in toolbars on first-run. * Bug 10751: Adapt Torbutton to ESR31's Australis UI. * Bug 13138: ESR31-about:tor shows "Tor is not working" * Bug 12947: Adapt session storage blocker to ESR 31. * Bug 10716: Take care of drag/drop events in ESR 31. * Bug 13366: Fix cert exemption dialog when disk storage is enabled. * Update Tor Launcher to 0.2.7.0.1 * Translation updates only * Udate fteproxy to 0.2.19 * Update NoScript to 2.6.9 * Bug 13027: Spoof window.navigator useragent values in JS WebWorker threads * Bug 13016: Hide CSS -moz-osx-font-smoothing values. * Bug 13356: Meek and other symlinks missing after complete update. * Bug 13025: Spoof screen orientation to landscape-primary. * Bug 13346: Disable Firefox "slow to start" warnings and recordkeeping. * Bug 13318: Minimize number of buttons on the browser toolbar. * Bug 10715: Enable WebGL on Windows (still click-to-play via NoScript) * Bug 13023: Disable the gamepad API. * Bug 13021: Prompt before allowing Canvas isPointIn*() calls. * Bug 12460: Several cross-compilation and gitian fixes (see child tickets) * Bug 13186: Disable DOM Performance timers * Bug 13028: Defense-in-depth checks for OCSP/Cert validation proxy usage The changes compared to the last stable release will be available in the blog post announcing the release of Tor Browser 4.0. Georg
Georg Koppen:
Tor Browser 4.0 is up for testing:
Testing: tor-browser-linux64-4.0_fr.tar.xz Platform: Debian sid Translation: ok All extensions are present and functional: yes WebBrowsing works as expected - HTTP, HTTPS, .onion browsing works - HTML5 videos work - https://panopticlick.eff.org/ - unique fingerprint, 22.13 bits (big hit with the user agent change, it seems) - Nothing found on samy.pl/evercookie after a new session Default search engine is DuckDuckGo. obfs3 ok. FTE ok. -- Lunar <lunar@torproject.org>
Testing: osx 32 en_us Platform: 10.9.4 Browsing works (HTTP/HTTPS/Onion) Youtube works https://panopticlick.eff.org/ - 22.13 bits of identifying information Nothing found on samy.pl/evercookie after a new session Default search engine is StartPage -tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/13/2014 12:18 PM, Georg Koppen wrote:
Hi,
Tor Browser 4.0 is up for testing:
https://people.torproject.org/~mikeperry/builds/4.0/
This is the first release in the 4.0 stable series and contains most notably the switch to Firefox ESR 31 as the base for Tor Browser and the switch to the 0.2.5.x series for tor. Moreover, the updater in Tor Browser is shipped for the first time to stable users which replaces the cumbersome and manual update process we currently have.
Testing: torbrowser-install-4.0_ar.exe OS: Windows 7 64-bit [Components] 31.2.0 (Tor Browser 4.0) Torbutton 1.7.0.1 NoScript 2.6.9 HTTPS-Everywhere 4.0.1 Default search engine: Startpage [Tests] Added a bridge - OK Socks5 - OK HTML5 video playback - OK http/https/onion websites - OK Clears history/cookies/session on “New Identity” - OK Localization files present - OK Testing: TorBrowser-4.0-osx32_en-US.dmg OS: Mac OS X 10.9.5 [Components] 31.2.0 (Tor Browser 4.0) Tor v0.2.5.8-rc (git-cc2477cc002ac542) Torbutton 1.7.0.1 NoScript 2.6.9 HTTPS-Everywhere 4.0.1 Default search engine: Startpage [Tests] Added a bridge - OK Socks5 - OK HTML5 video playback - OK http/https/onion websites - OK Clears history/cookies/session on “New Identity” - OK Notes: + Since Tor Browser 4.0 includes an updater, why does TorButton still point users to the website when it can also point them to the update menu? + While testing on OS X, I noticed that in the "Apps using significant energy" battery menu that "TorBrowser.app.meek-http-helper" is running but I never chose to run meek to begin with (only obfs3). - -- Sherief Alaa pgp 0x8623B882 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBAgAGBQJUO+fdAAoJEMcu85OGI7iCPaQMAJWHFOlPsqkwGkPBwO8BfTYF zcPF+UEupA4eoqwi3amAmFesVuuj/EGfaeuwFs+MJmCNupWNk18kARZTzFqdufYe SjF0Jw5Zu6VsHsazJHCp+ky3U2EtD7W2bbZuMW1an8CrL+fMYll9cDh2yfTrz7bk 6HDrudT2ddn+2UcQekeMpT+aa13WTOHDkoDHfcgXTOI+kpXpooqqW28czP1eYTPA Wl31rdvc1t8y2QHpTP4JhJElId8Poij0tRJX8z28WQqHIxc8ZU8HbiQPvEPYl3Wz mthCE2aBlme7rcKJ9gKoCLC86Giu2LJ6AcX1Y1txXreCpFU3C3oi+B1Ni8NiGn8M CZEMYD+SyLu6qW6kR0631ZOavugfvLSEC5T4zF13ne8keQ/RCK5wIDRLAyNnRhlp 98pegOsRkzF0ccDPzJ2vqqcqA2iRmbzjK2C4lZyScDnU47Lgms/o82za7IcGULVL LUTii+WnBwpR5RgXp8iY+OLSaVVY1QaIUEevmOfVBQ== =Nkeb -----END PGP SIGNATURE-----
On Mon, Oct 13, 2014 at 04:55:29PM +0200, Sherief Alaa wrote:
+ While testing on OS X, I noticed that in the "Apps using significant energy" battery menu that "TorBrowser.app.meek-http-helper" is running but I never chose to run meek to begin with (only obfs3).
Hmm, this shouldn't happen. Can you send me the tor log? If you manually kill TorBrowser.app.meek-http-helper, does it come back when you start Tor Browser again? David
On Oct 13, 2014, at 7:22 PM, David Fifield <david@bamsoftware.com> wrote:
On Mon, Oct 13, 2014 at 04:55:29PM +0200, Sherief Alaa wrote:
+ While testing on OS X, I noticed that in the "Apps using significant energy" battery menu that "TorBrowser.app.meek-http-helper" is running but I never chose to run meek to begin with (only obfs3).
Hmm, this shouldn't happen. Can you send me the tor log?
10/13/14, 21:05:25.930 [NOTICE] Bootstrapped 5%: Connecting to directory server 10/13/14, 21:05:25.931 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 10/13/14, 21:05:27.205 [NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection 10/13/14, 21:05:27.481 [NOTICE] Bootstrapped 20%: Asking for networkstatus consensus 10/13/14, 21:05:27.646 [NOTICE] Bootstrapped 25%: Loading networkstatus consensus 10/13/14, 21:05:28.387 [NOTICE] new bridge descriptor 'gamma' (fresh): $xxxxx~gamma at 37.13x.xx.xxx 10/13/14, 21:05:28.387 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. 10/13/14, 21:05:34.445 [NOTICE] We now have enough directory information to build circuits. 10/13/14, 21:05:34.445 [NOTICE] Bootstrapped 80%: Connecting to the Tor network 10/13/14, 21:05:34.949 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit 10/13/14, 21:05:39.955 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working. 10/13/14, 21:05:39.955 [NOTICE] Bootstrapped 100%: Done 10/13/14, 21:05:40.792 [NOTICE] New control connection opened from 127.0.0.1. Doesn’t say much really.
If you manually kill TorBrowser.app.meek-http-helper, does it come back when you start Tor Browser again?
I can’t even find it in the process list inside the Activity Monitor (see attached). I also tried $ ps -ax | grep meek and nothing showed up.
For what it's worth, I opened youtube, cnn.com and WebQuake ( http://webquake.quaddicted.com/Client/WebQuake.htm) and after opening those tabs was able to reproduce it. It didn't appear initially. -tom On 13 October 2014 16:54, Sherief Alaa <sheriefalaa.w@gmail.com> wrote:
On Oct 13, 2014, at 7:22 PM, David Fifield <david@bamsoftware.com> wrote:
On Mon, Oct 13, 2014 at 04:55:29PM +0200, Sherief Alaa wrote:
+ While testing on OS X, I noticed that in the "Apps using significant energy" battery menu that "TorBrowser.app.meek-http-helper" is running but I never chose to run meek to begin with (only obfs3).
Hmm, this shouldn't happen. Can you send me the tor log?
10/13/14, 21:05:25.930 [NOTICE] Bootstrapped 5%: Connecting to directory server 10/13/14, 21:05:25.931 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 10/13/14, 21:05:27.205 [NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection 10/13/14, 21:05:27.481 [NOTICE] Bootstrapped 20%: Asking for networkstatus consensus 10/13/14, 21:05:27.646 [NOTICE] Bootstrapped 25%: Loading networkstatus consensus 10/13/14, 21:05:28.387 [NOTICE] new bridge descriptor 'gamma' (fresh): $xxxxx~gamma at 37.13x.xx.xxx 10/13/14, 21:05:28.387 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. 10/13/14, 21:05:34.445 [NOTICE] We now have enough directory information to build circuits. 10/13/14, 21:05:34.445 [NOTICE] Bootstrapped 80%: Connecting to the Tor network 10/13/14, 21:05:34.949 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit 10/13/14, 21:05:39.955 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working. 10/13/14, 21:05:39.955 [NOTICE] Bootstrapped 100%: Done 10/13/14, 21:05:40.792 [NOTICE] New control connection opened from 127.0.0.1.
Doesn't say much really.
If you manually kill TorBrowser.app.meek-http-helper, does it come back when you start Tor Browser again?
I can't even find it in the process list inside the Activity Monitor (see attached). I also tried $ ps -ax | grep meek and nothing showed up.
_______________________________________________ tor-qa mailing list tor-qa@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-qa
On Mon, Oct 13, 2014 at 05:02:11PM -0500, Tom Ritter wrote:
For what it's worth, I opened youtube, cnn.com and WebQuake ([2]http:// webquake.quaddicted.com/Client/WebQuake.htm) and after opening those tabs was able to reproduce it. It didn't appear initially.
Did you turn meek on in the configuration? Or just obfs3 as Sherief did? My guess is that "Apps using significant energy" has some kind of memory, and it may be showing things that used energy in the recent past, but not necessarily right now. Maybe it was left over from a previous time that Sherief used the bundle? As for why the HTTP helper would be using battery, I suppose it is because of the base64 encoding and decoding that happens between the pluggable transport and the helper. That internal protocol is going to get overhauled anyway for #12857, and the base64 will probably go away. David Fifield
On 13 October 2014 17:07, David Fifield <david@bamsoftware.com> wrote:
On Mon, Oct 13, 2014 at 05:02:11PM -0500, Tom Ritter wrote:
For what it's worth, I opened youtube, cnn.com and WebQuake ([2]http:// webquake.quaddicted.com/Client/WebQuake.htm) and after opening those tabs was able to reproduce it. It didn't appear initially.
Did you turn meek on in the configuration? Or just obfs3 as Sherief did?
Actually, I never used PTs at all. That was 'normal' TorBrowser.
My guess is that "Apps using significant energy" has some kind of memory, and it may be showing things that used energy in the recent past, but not necessarily right now. Maybe it was left over from a previous time that Sherief used the bundle?
I've barely ever used PTs, and not in the past 2 weeks.
As for why the HTTP helper would be using battery, I suppose it is because of the base64 encoding and decoding that happens between the pluggable transport and the helper. That internal protocol is going to get overhauled anyway for #12857, and the base64 will probably go away.
I'm wondering if it's attributing the application name incorrectly, honestly. -tom
On Mon, Oct 13, 2014 at 05:10:28PM -0500, Tom Ritter wrote:
On 13 October 2014 17:07, David Fifield <david@bamsoftware.com> wrote:
As for why the HTTP helper would be using battery, I suppose it is because of the base64 encoding and decoding that happens between the pluggable transport and the helper. That internal protocol is going to get overhauled anyway for #12857, and the base64 will probably go away.
I'm wondering if it's attributing the application name incorrectly, honestly.
Ooh, good thought.
On Mon, Oct 13, 2014 at 11:54:30PM +0200, Sherief Alaa wrote:
On Oct 13, 2014, at 7:22 PM, David Fifield <david@bamsoftware.com> wrote:
On Mon, Oct 13, 2014 at 04:55:29PM +0200, Sherief Alaa wrote:
+ While testing on OS X, I noticed that in the "Apps using significant energy" battery menu that "TorBrowser.app.meek-http-helper" is running but I never chose to run meek to begin with (only obfs3).
Hmm, this shouldn't happen. Can you send me the tor log?
10/13/14, 21:05:25.930 [NOTICE] Bootstrapped 5%: Connecting to directory server 10/13/14, 21:05:25.931 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 10/13/14, 21:05:27.205 [NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection 10/13/14, 21:05:27.481 [NOTICE] Bootstrapped 20%: Asking for networkstatus consensus 10/13/14, 21:05:27.646 [NOTICE] Bootstrapped 25%: Loading networkstatus consensus 10/13/14, 21:05:28.387 [NOTICE] new bridge descriptor 'gamma' (fresh): $xxxxx~gamma at 37.13x.xx.xxx 10/13/14, 21:05:28.387 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. 10/13/14, 21:05:34.445 [NOTICE] We now have enough directory information to build circuits. 10/13/14, 21:05:34.445 [NOTICE] Bootstrapped 80%: Connecting to the Tor network 10/13/14, 21:05:34.949 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit 10/13/14, 21:05:39.955 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working. 10/13/14, 21:05:39.955 [NOTICE] Bootstrapped 100%: Done 10/13/14, 21:05:40.792 [NOTICE] New control connection opened from 127.0.0.1.
Maybe bump up the log level (add "Log info stdout" to Browser/TorBrowser/Data/Tor/torrc). The lines I'm looking for are: [info] parse_client_transport_line(): Pluggable transport proxy (fte exec ./TorBrowser/Tor/PluggableTransports/fteproxy.bin --managed) does not provide any needed transports and will not be launched. [info] parse_client_transport_line(): Pluggable transport proxy (flashproxy exec ./TorBrowser/Tor/PluggableTransports/flashproxy-client --register :0 :9000) does not provide any needed transports and will not be launched. [info] parse_client_transport_line(): Pluggable transport proxy (meek exec ./TorBrowser/Tor/PluggableTransports/meek-client-torbrowser -- ./TorBrowser/Tor/PluggableTransports/meek-client) does not provide any needed transports and will not be launched. David Fifield
On Oct 14, 2014, at 12:10 AM, David Fifield <david@bamsoftware.com> wrote:
On Mon, Oct 13, 2014 at 11:54:30PM +0200, Sherief Alaa wrote:
On Oct 13, 2014, at 7:22 PM, David Fifield <david@bamsoftware.com> wrote:
On Mon, Oct 13, 2014 at 04:55:29PM +0200, Sherief Alaa wrote:
+ While testing on OS X, I noticed that in the "Apps using significant energy" battery menu that "TorBrowser.app.meek-http-helper" is running but I never chose to run meek to begin with (only obfs3).
Hmm, this shouldn't happen. Can you send me the tor log?
10/13/14, 21:05:25.930 [NOTICE] Bootstrapped 5%: Connecting to directory server 10/13/14, 21:05:25.931 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 10/13/14, 21:05:27.205 [NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection 10/13/14, 21:05:27.481 [NOTICE] Bootstrapped 20%: Asking for networkstatus consensus 10/13/14, 21:05:27.646 [NOTICE] Bootstrapped 25%: Loading networkstatus consensus 10/13/14, 21:05:28.387 [NOTICE] new bridge descriptor 'gamma' (fresh): $xxxxx~gamma at 37.13x.xx.xxx 10/13/14, 21:05:28.387 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. 10/13/14, 21:05:34.445 [NOTICE] We now have enough directory information to build circuits. 10/13/14, 21:05:34.445 [NOTICE] Bootstrapped 80%: Connecting to the Tor network 10/13/14, 21:05:34.949 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit 10/13/14, 21:05:39.955 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working. 10/13/14, 21:05:39.955 [NOTICE] Bootstrapped 100%: Done 10/13/14, 21:05:40.792 [NOTICE] New control connection opened from 127.0.0.1.
Maybe bump up the log level (add "Log info stdout" to Browser/TorBrowser/Data/Tor/torrc). The lines I'm looking for are:
[info] parse_client_transport_line(): Pluggable transport proxy (fte exec ./TorBrowser/Tor/PluggableTransports/fteproxy.bin --managed) does not provide any needed transports and will not be launched. [info] parse_client_transport_line(): Pluggable transport proxy (flashproxy exec ./TorBrowser/Tor/PluggableTransports/flashproxy-client --register :0 :9000) does not provide any needed transports and will not be launched. [info] parse_client_transport_line(): Pluggable transport proxy (meek exec ./TorBrowser/Tor/PluggableTransports/meek-client-torbrowser -- ./TorBrowser/Tor/PluggableTransports/meek-client) does not provide any needed transports and will not be launched.
Did that and no new messages appeared in the log. BTW, I think Tom is right about OS X getting the wrong Application name but I don’t know why would it confuse TB with meek-http-helper when it’s not even running to being with.
Sherief Alaa wrote:
Notes: + Since Tor Browser 4.0 includes an updater, why does TorButton still point users to the website when it can also point them to the update menu?
Good question. Do you mind filing a ticket and explaining there what exactly Torbutton should do instead of pointing users to the website? Should there be an item in the Torbutton drop-down menu opening the about dialog instead? If so, how do users find an update in case the built-in updater is not working (for whatever reason)? Georg
participants (5)
-
David Fifield -
Georg Koppen -
Lunar -
Sherief Alaa -
Tom Ritter