[tor-commits] [torbrowser/master] Update pipeline patch description.

[mikeperry at torproject.org]

commit a241fb26e00f804f954d510dd52c1e8ca67c99b1
Author: Mike Perry <mikeperry-git at fscked.org>
Date:   Thu Apr 11 02:34:31 2013 -0700

    Update pipeline patch description.
---
 ...ize-HTTP-request-order-and-pipeline-depth.patch |   33 +++++++++++++++-----
 1 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch b/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch
index a5d2957..cb29e76 100644
--- a/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch
+++ b/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch
@@ -1,23 +1,40 @@
-From a88adc5c3000c3e2a18b1065da77dd83d2b3ae7b Mon Sep 17 00:00:00 2001
+From 7b340f34e429a4cb3407f838b4d414a671668419 Mon Sep 17 00:00:00 2001
 From: Mike Perry <mikeperry-git at torproject.org>
 Date: Tue, 4 Dec 2012 17:38:51 -0800
 Subject: [PATCH 17/28] Randomize HTTP request order and pipeline depth.
 
-This is an experimental defense against
+This is an experimental defense against Website Traffic Fingerprinting:
 http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf
 
 See:
 https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting
 
-This defense has been improved since that blog post to additionally randomize
-the order and concurrency of non-pipelined HTTP requests.
+This patch is different from the approach described in that post, as well as
+the the 10.x ESR patch, as the pipelining code has changed significantly
+between the time of writing of that post and Firefox 17.
 
-This patch is also different from the 10.x ESR patch, as the pipelining
-code has changed significantly.
+The main control nob for this patch is now the about:config pref
+"network.http.pipelining.max-optimistic-requests". The value of that pref
+represents the minimum number of pipelined requests we will attempt to batch
+together.
 
-This patch may have some minor impact on SPDY request order, but the SPDY
+The total outstanding pipeline size is randomized between that value and
+"network.http.pipelining.maxrequests" on a per-host basis.
+
+Care must be taken when evaluating this defense, as pipeline behavior is
+extremely sensitive to browser performance. In fact, a debug build alone is
+enough to significantly impair request availability to the pipeline (due
+slower document parsing and rendering). For this reason, we provide two
+separate debug log defines. For most evaluation circumstances, you want to
+define only WTF_TEST in an optimized build to only log request order and
+combination behavior.
+
+This patch may also have some minor impact on SPDY request order, but the SPDY
 implementation has not been altered directly. It has several stream queues
-that may also benefit from reordering.
+that may also benefit from reordering and batching, as well as a more compact
+request representation that will allow more requests to be packed inside Tor
+cells. If you have interest in evaluating SPDY in a study of Website Traffic
+Fingerprinting, please contact me.
 ---
  netwerk/protocol/http/nsHttpConnectionMgr.cpp |  288 +++++++++++++++++--------
  netwerk/protocol/http/nsHttpConnectionMgr.h   |   15 +-