On Tue, Feb 18, 2014 at 07:25:58PM +0000, Wilton Gorske wrote:
Testing: TorBrowserBundle-3.5.2-osx32_en-US.zip Platform: Mac OS X 10.9.1 (13B3116) Processor: 2.3GHz Intel Core i7 Memory: 16 GB 1600 MHz DDR3 Graphics: NVIDIA GeForce GT 750M 2048 MB Display: 15-inch (2880 x 1800 Retina) ISP: Telenet (Belgium)
TBB Launches successfully: yes Connects to the Tor network: yes Browser toolbars and menus work, tab dragging works: yes
All extensions are present and functional: yes
- HTTPS-Everywhere 3.4.5
- NoScript 2.6.8.13
- TorButton 1.6.6.0
- TorLauncher 0.2.4.4
WebBrowsing works as expected
- HTTP, HTTPS, .onion browsing works (http://duskgytldkxiuqc6.onion/)
- HTML5 videos work on http://videojs.com/ and YouTube
- http://ip-check.info/?lang=en - ok
- https://panopticlick.eff.org/ - only one in 1,291,815 , 20.3 bits of identifying information
- html5demos.com/web-socket - Not Connected / Socket Closed
SOCKS/external apps work as expected: yes (Torbirdy)
No crashes at all or unexpected behavior. Noticeably slower while starting up and browsing.
Thanks for testing it.
The slowness you observe has at least two causes. First is that every 64 KB or less gets wrapped up in an HTTP request, which is first sent to Google and then to the bridge.
The second is that HTTP requests and responses are serialized, so if you have something to send right now, you can't send it until you receive a response to your most recent request. Doing it this way is slower, but it's simple to implement and correct. We can imagine having multiple requests outstanding, each with different parts of the byte stream. Then we would need to start worrying about what happens if requests arrive out of order, or a request fails. A benefit of the more complicated model, apart from performance, is that being resilient to dropped requests, it would allow us to keep a Tor circuit alive even after an HTTP failure (which failures are happening to me a few times a day).
David Fifield