[tor-qa] Please test experimental bundles with meek transport (3.5.2.1-meek-1)

[David Fifield]

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