commit a241fb26e00f804f954d510dd52c1e8ca67c99b1 Author: Mike Perry mikeperry-git@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@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-finger...
-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 +-
tor-commits@lists.torproject.org