March 2013 - tor-commits - lists.torproject.org

[ooni-probe/master] Add yaml file for controlling the continuous integration service.
by isis＠torproject.org 12 Mar '13

12 Mar '13

commit 690f8e3c5322519ca28c1e63d717983db87dd95a Author: Isis Lovecruft <isis(a)torproject.org> Date: Sun Mar 10 08:07:56 2013 +0000 Add yaml file for controlling the continuous integration service. * This is currently hooked to my personal repo, for testing purposes, before we decide whether or not to hook it to the common organization repo. * The continuous integration is pretty basic so far: it checks with python versions 2.6, 2.7, and 3.3, that we are able to install everything in the requirements.txt file, that "$ ./inputs/make" works, and then that the following test: "$ bin/ooniprobe nettests/blocking/dnsconsistency.py \ -f inputs/ooni-inputs/processed/alexa-top-1k.txt" completes successfully. * It uses Travis-CI, see http://about.travis-ci.org/docs/user/getting-started/ --- .travis.yml | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 0000000..13b421b --- /dev/null +++ b/.travis.yml @@ -0,0 +1,9 @@ +language: python +python: + - "3.3" + - "2.7" + - "2.6" +# command to install dependencies, e.g. pip install -r requirements.txt --use-mirrors +install: pip install -r requirements.txt && ./inputs/make +# command to run tests, e.g. python setup.py test +script: bin/ooniprobe nettest/blocking/tcpconnect.py -f inputs/ooni-inputs/processed/alexa-top-1k.txt

1 0

[ooni-probe/master] Oops. 'make' should be run from the ./inputs/ directory, it's not a script. Duh.
by isis＠torproject.org 12 Mar '13

12 Mar '13

commit d5c8b02d10689666deb4c3628fe4fef8ccb28b0f Author: Isis Lovecruft <isis(a)torproject.org> Date: Mon Mar 11 18:52:07 2013 +0000 Oops. 'make' should be run from the ./inputs/ directory, it's not a script. Duh. --- .travis.yml | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/.travis.yml b/.travis.yml index a2324e6..87135ff 100644 --- a/.travis.yml +++ b/.travis.yml @@ -4,6 +4,6 @@ python: - "2.7" - "2.6" # command to install dependencies, e.g. pip install -r requirements.txt --use-mirrors -install: pip install -r requirements.txt --use-mirrors && ./inputs/make +install: pip install -r requirements.txt --use-mirrors && cd ./inputs/ && make && cd .. # command to run tests, e.g. python setup.py test script: bin/ooniprobe nettest/blocking/tcpconnect.py -f inputs/ooni-inputs/processed/alexa-top-1k.txt

1 0

[ooni-probe/master] Update .travis.yml to copy the ooniprobe.conf.sample to ooniprobe.conf.
by isis＠torproject.org 12 Mar '13

12 Mar '13

commit 133045efef1666e4fafd3b587b645123020b2651 Author: Isis Lovecruft <isis(a)torproject.org> Date: Mon Mar 11 20:14:10 2013 +0000 Update .travis.yml to copy the ooniprobe.conf.sample to ooniprobe.conf. * Fixes #8450. --- .travis.yml | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/.travis.yml b/.travis.yml index 87135ff..6e373a0 100644 --- a/.travis.yml +++ b/.travis.yml @@ -4,6 +4,6 @@ python: - "2.7" - "2.6" # command to install dependencies, e.g. pip install -r requirements.txt --use-mirrors -install: pip install -r requirements.txt --use-mirrors && cd ./inputs/ && make && cd .. +install: pip install -r requirements.txt --use-mirrors && cp ooniprobe.conf.sample ooniprobe.conf # command to run tests, e.g. python setup.py test script: bin/ooniprobe nettest/blocking/tcpconnect.py -f inputs/ooni-inputs/processed/alexa-top-1k.txt

1 0

[ooni-probe/master] Use example_inputs in .travis.yml rather than ooni_inputs.
by isis＠torproject.org 12 Mar '13

12 Mar '13

commit 6b5e52973a7b56438bcc94794d794d32410190f1 Author: Isis Lovecruft <isis(a)torproject.org> Date: Mon Mar 11 20:22:28 2013 +0000 Use example_inputs in .travis.yml rather than ooni_inputs. * Fixes #8451 travis-lint checks out properly: (ooni)∃!isisⒶwintermute:~/code/torproject/ooni-probe ∴ travis-lint Hooray, /home/isis/code/torproject/ooni-probe/.travis.yml seems to be solid! (ooni)∃!isisⒶwintermute:~/code/torproject/ooni-probe ∴ date Mon Mar 11 20:22:20 UTC 2013 --- .travis.yml | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/.travis.yml b/.travis.yml index 6e373a0..e10e45b 100644 --- a/.travis.yml +++ b/.travis.yml @@ -6,4 +6,4 @@ python: # command to install dependencies, e.g. pip install -r requirements.txt --use-mirrors install: pip install -r requirements.txt --use-mirrors && cp ooniprobe.conf.sample ooniprobe.conf # command to run tests, e.g. python setup.py test -script: bin/ooniprobe nettest/blocking/tcpconnect.py -f inputs/ooni-inputs/processed/alexa-top-1k.txt +script: bin/ooniprobe nettest/blocking/tcpconnect.py -f example_inputs/alexa-top-1k.txt

1 0

[ooni-probe/master] Merge pull request #67 from isislovecruft/feature/continuous-integration
by isis＠torproject.org 12 Mar '13

12 Mar '13

commit 46f955f0847b20511a438747c9f65d56acd3b611 Merge: 325e0f2 d6e8b08 Author: aagbsn <aagbsn(a)extc.org> Date: Mon Mar 11 19:22:30 2013 -0700 Merge pull request #67 from isislovecruft/feature/continuous-integration Feature/continuous integration .travis.yml | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-)

1 0

[ooni-probe/master] Update .travis.yml to put the install commands under the install section.
by isis＠torproject.org 12 Mar '13

12 Mar '13

commit d6e8b08ce07a0664c2bbf55a2b40d47ea02cc795 Author: Isis Lovecruft <isis(a)torproject.org> Date: Mon Mar 11 21:00:38 2013 +0000 Update .travis.yml to put the install commands under the install section. * Separate commands for testing pip and setuptools installations. * TODO I believe there is a way to tell TravisCI to try both, we should check the docs. travis-lint results: (ooni)∃!isisⒶwintermute:~/code/torproject/ooni-probe ∴ travis-lint Hooray, /home/isis/code/torproject/ooni-probe/.travis.yml seems to be solid! (ooni)∃!isisⒶwintermute:~/code/torproject/ooni-probe ∴ date Mon Mar 11 21:00:27 UTC 2013 --- .travis.yml | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/.travis.yml b/.travis.yml index e2b5e29..9c89f6d 100644 --- a/.travis.yml +++ b/.travis.yml @@ -5,11 +5,13 @@ python: - "3.3" - "2.7" - "2.6" -# command to install dependencies, e.g. pip install -r requirements.txt --use-mirrors -install: pip install -r requirements.txt --use-mirrors && cp ooniprobe.conf.sample ooniprobe.conf +# command to install dependencies +# the first is for testing pip and the second for setuptools +install: + #- pip install -r requirements.txt --use-mirrors + - python setup.py install # command to run tests, e.g. python setup.py test script: - - python setup.py install # To be activated after merge of PR#64 # - trial ooni - cp ooniprobe.conf.sample ooniprobe.conf

1 0

[ooni-probe/master] Add travis-ci build script.
by isis＠torproject.org 12 Mar '13

12 Mar '13

commit 06d552c1c50974e17d58e91b173385653a7e2f9c Author: Arturo Filastò <art(a)fuffa.org> Date: Mon Mar 11 21:13:11 2013 +0100 Add travis-ci build script. (cherry picked from commit cfe357a546669c3ca70ee1f65dbc5034c2be4760) --- .travis.yml | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/.travis.yml b/.travis.yml index e10e45b..e2b5e29 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,4 +1,6 @@ language: python +before_install: + - sudo apt-get install tor python: - "3.3" - "2.7" @@ -6,4 +8,10 @@ python: # command to install dependencies, e.g. pip install -r requirements.txt --use-mirrors install: pip install -r requirements.txt --use-mirrors && cp ooniprobe.conf.sample ooniprobe.conf # command to run tests, e.g. python setup.py test -script: bin/ooniprobe nettest/blocking/tcpconnect.py -f example_inputs/alexa-top-1k.txt +script: + - python setup.py install + # To be activated after merge of PR#64 + # - trial ooni + - cp ooniprobe.conf.sample ooniprobe.conf + - sh scripts/before_i_commit.sh + - bin/ooniprobe nettest/blocking/tcpconnect.py -f example_inputs/alexa-top-1k.txt \ No newline at end of file

1 0

r26104: {website} TBB Design Doc: Mention use of SPDY at exits. This is an ext (website/trunk/projects/torbrowser/design)
by Mike Perry 12 Mar '13

12 Mar '13

Author: mikeperry Date: 2013-03-12 02:20:25 +0000 (Tue, 12 Mar 2013) New Revision: 26104 Modified: website/trunk/projects/torbrowser/design/index.html.en Log: TBB Design Doc: Mention use of SPDY at exits. This is an extremely important point with the pipelining/SPDY defense. We don't have to give up if the web doesn't upgrade. Modified: website/trunk/projects/torbrowser/design/index.html.en =================================================================== --- website/trunk/projects/torbrowser/design/index.html.en 2013-03-11 21:41:58 UTC (rev 26103) +++ website/trunk/projects/torbrowser/design/index.html.en 2013-03-12 02:20:25 UTC (rev 26104) @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /></head><body><div class="article" title="The Design and Implementation of the Tor Browser [DRAFT]"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class= "email"><<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>></code></p></div></div></div></div><div><p class="pubdate">March 8 2013</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="sect1"><a href="#idp2931312">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">4.4. Application Data Isolation</a></span></ dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">4.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp5839584">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp2931312"></a>1. Introduction</h2></div></div></div><p> +<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /></head><body><div class="article" title="The Design and Implementation of the Tor Browser [DRAFT]"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class= "email"><<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>></code></p></div></div></div></div><div><p class="pubdate">March 11, 2013</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="sect1"><a href="#idp3154416">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"> <a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">4.4. Application Data Isolation</a></span> </dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">4.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp5843792">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clea r: both"><a id="idp3154416"></a>1. Introduction</h2></div></div></div><p> This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>, <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, and <a class="link" href="#Implementation" title="4. Implementation">implementation</a> of the Tor Browser. It is current as of Tor Browser @@ -473,11 +473,12 @@ </p><p> -In fact, the ocean of Tor Internet activity (at least, when compared to a lab -setting) makes it a certainty that an adversary attempting examine large -amounts of Tor traffic will ultimately be overwhelmed by false positives (even -after making heavy tradeoffs on the ROC curve to minimize false positives to -below 0.01%). This problem is known in the IDS literature as the <a class="ulink" href="http://www.raid-symposium.org/raid99/PAPERS/Axelsson.pdf" target="_top">Base Rate +To make matters worse for a real-world adversary, the ocean of Tor Internet +activity (at least, when compared to a lab setting) makes it a certainty that +an adversary attempting examine large amounts of Tor traffic will ultimately +be overwhelmed by false positives (even after making heavy tradeoffs on the +ROC curve to minimize false positives to below 0.01%). This problem is known +in the IDS literature as the <a class="ulink" href="http://www.raid-symposium.org/raid99/PAPERS/Axelsson.pdf" target="_top">Base Rate Fallacy</a>, and it is the primary reason that anomaly and activity classification-based IDS and antivirus systems have failed to materialize in the marketplace (despite early success in academic literature). @@ -608,13 +609,13 @@ Tor Browser State is separated from existing browser state through use of a custom Firefox profile. Furthermore, plugins are disabled, which prevents Flash cookies from leaking from a pre-existing Flash directory. - </p></div><div class="sect2" title="4.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5584448"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p></div><div class="sect2" title="4.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5587232"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> The User Agent MUST (at user option) prevent all disk records of browser activity. The user should be able to optionally enable URL history and other history features if they so desire. - </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5585808"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5588592"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> We achieve this goal through several mechanisms. First, we set the Firefox Private Browsing preference @@ -694,7 +695,7 @@ context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1. - </p><div class="figure"><a id="idp5609888"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + </p><div class="figure"><a id="idp5612672"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> This example UI is a mock-up of how isolating identifiers to the URL bar origin can simplify the privacy UI for all data - not just cookies. Once @@ -1181,11 +1182,11 @@ menu option in Torbutton. This context menu option is active if Torbutton can read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT. - </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5727952"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5731056"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> All linkable identifiers and browser state MUST be cleared by this feature. - </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5729200"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5732304"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> First, Torbutton disables Javascript in all open tabs and windows by using both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocSh…" target="_top">browser.docShell.allowJavascript</a> @@ -1229,7 +1230,7 @@ Fingerprinting</a> is a statistical attack to attempt to recognize specific encrypted website activity. - </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5743360"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5746320"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> We want to deploy a mechanism that reduces the accuracy of <a class="ulink" href="https://en.wikipedia.org/wiki/Feature_selection" target="_top">useful features</a> available for classification. This mechanism would either impact the true and false @@ -1243,14 +1244,15 @@ deploy a mechanism that reduces feature extraction resolution without any network overhead. In the no-overhead category, we have <a class="ulink" href="http://freehaven.net/anonbib/cache/LZCLCP_NDSS11.pdf" target="_top">HTTPOS</a> and <a class="ulink" href="https://blog.torproject.org/blog/experimental-defense-website-traffic-finge…" target="_top">better -use of HTTP pipelining and/or SPDY</a>. In the tunable/low-overhead +use of HTTP pipelining and/or SPDY</a>. +In the tunable/low-overhead category, we have <a class="ulink" href="http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf" target="_top">Adaptive Padding</a> and <a class="ulink" href="http://www.cs.sunysb.edu/~xcai/fp.pdf" target="_top"> Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/7028" target="_top">tune such defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor network, making them also effectively no-overhead. - </p></blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5750176"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p></blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5753216"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…" target="_top">randomize pipeline order and depth</a>. Unfortunately, pipelining is very fragile. Many sites do not support it, and even sites that advertise support for @@ -1258,7 +1260,11 @@ forcing the browser into non-pipelined behavior. Firefox also has code to back off and reduce or eliminate the pipeline if this happens. These shortcomings and fallback behaviors are the primary reason that Google -developed SPDY as opposed simply extending HTTP to improve pipelining. +developed SPDY as opposed simply extending HTTP to improve pipelining. It +turns out that we could actually deploy exit-side proxies that allow us to +<a class="ulink" href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-us…" target="_top">use +SPDY from the client to the exit node</a>. This would make our defense not +only free, but one that actually <span class="emphasis"><em>improves</em></span> performance. </p><p> @@ -1583,7 +1589,7 @@ ourselves</a>, as they are comparatively rare and can be handled with site permissions. - </p></li></ol></div></div><div class="sect1" title="A.2. Promising Standards"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp5839584"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> + </p></li></ol></div></div><div class="sect1" title="A.2. Promising Standards"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp5843792"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> Web-Send is a browser-based link sharing and federated login widget that is designed to operate without relying on third-party tracking or abusing other

1 0

[stem/master] More changes for tutorial rename
by atagar＠torproject.org 12 Mar '13

12 Mar '13

commit 2c9710060e6194e30d6971377ddc80fa681eeaa9 Author: Damian Johnson <atagar(a)torproject.org> Date: Mon Mar 11 18:07:54 2013 -0700 More changes for tutorial rename Drats, I pushed the prior commit before I had intended to. Fixing the buttons too to reflect the rename. --- docs/_static/buttons/resources/tutorial.xcf | Bin 36318 -> 0 bytes docs/_static/buttons/resources/tutorials.xcf | Bin 0 -> 36681 bytes docs/_static/buttons/tutorial.png | Bin 14530 -> 0 bytes docs/_static/buttons/tutorials.png | Bin 0 -> 15255 bytes docs/index.rst | 2 +- 5 files changed, 1 insertions(+), 1 deletions(-) diff --git a/docs/_static/buttons/resources/tutorial.xcf b/docs/_static/buttons/resources/tutorial.xcf deleted file mode 100644 index 00246cd..0000000 Binary files a/docs/_static/buttons/resources/tutorial.xcf and /dev/null differ diff --git a/docs/_static/buttons/resources/tutorials.xcf b/docs/_static/buttons/resources/tutorials.xcf new file mode 100644 index 0000000..ebdfb70 Binary files /dev/null and b/docs/_static/buttons/resources/tutorials.xcf differ diff --git a/docs/_static/buttons/tutorial.png b/docs/_static/buttons/tutorial.png deleted file mode 100644 index 039f5a2..0000000 Binary files a/docs/_static/buttons/tutorial.png and /dev/null differ diff --git a/docs/_static/buttons/tutorials.png b/docs/_static/buttons/tutorials.png new file mode 100644 index 0000000..c867a3e Binary files /dev/null and b/docs/_static/buttons/tutorials.png differ diff --git a/docs/index.rst b/docs/index.rst index 7d18eeb..8e5e6f9 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -13,7 +13,7 @@ Stem is a python controller library for `Tor <https://www.torproject.org/>`_. Li License: LGPL v3 File: NuoveXT 2.2/128x128/categories/applications-development.png -.. image:: /_static/buttons/tutorial.png +.. image:: /_static/buttons/tutorials.png :target: tutorials.html .. Source: http://www.cipherdyne.com/images/anvil.png

1 0

[stem/master] Dropping 'aka' from tutorial labels
by atagar＠torproject.org 12 Mar '13

12 Mar '13

commit 98f878087dfb5eeac3fd2720b47b4ffe1fe1bc75 Author: Damian Johnson <atagar(a)torproject.org> Date: Mon Mar 11 18:28:24 2013 -0700 Dropping 'aka' from tutorial labels The labels look a little nicer this way. Suggested by Josh Barr. --- .../label/double_double_toil_and_trouble.png | Bin 3785 -> 3464 bytes docs/_static/label/mirror_mirror_on_the_wall.png | Bin 4056 -> 3734 bytes .../resources/double_double_toil_and_trouble.xcf | Bin 8536 -> 8146 bytes .../label/resources/mirror_mirror_on_the_wall.xcf | Bin 8960 -> 8553 bytes .../resources/the_little_relay_that_could.xcf | Bin 8870 -> 8496 bytes .../label/resources/to_russia_with_love.xcf | Bin 7612 -> 7224 bytes docs/_static/label/the_little_relay_that_could.png | Bin 4301 -> 4001 bytes docs/_static/label/to_russia_with_love.png | Bin 4265 -> 3965 bytes 8 files changed, 0 insertions(+), 0 deletions(-) diff --git a/docs/_static/label/double_double_toil_and_trouble.png b/docs/_static/label/double_double_toil_and_trouble.png index 5286872..6105401 100644 Binary files a/docs/_static/label/double_double_toil_and_trouble.png and b/docs/_static/label/double_double_toil_and_trouble.png differ diff --git a/docs/_static/label/mirror_mirror_on_the_wall.png b/docs/_static/label/mirror_mirror_on_the_wall.png index b6e5622..d4aac7e 100644 Binary files a/docs/_static/label/mirror_mirror_on_the_wall.png and b/docs/_static/label/mirror_mirror_on_the_wall.png differ diff --git a/docs/_static/label/resources/double_double_toil_and_trouble.xcf b/docs/_static/label/resources/double_double_toil_and_trouble.xcf index 214dd30..0615994 100644 Binary files a/docs/_static/label/resources/double_double_toil_and_trouble.xcf and b/docs/_static/label/resources/double_double_toil_and_trouble.xcf differ diff --git a/docs/_static/label/resources/mirror_mirror_on_the_wall.xcf b/docs/_static/label/resources/mirror_mirror_on_the_wall.xcf index d50672e..eba104a 100644 Binary files a/docs/_static/label/resources/mirror_mirror_on_the_wall.xcf and b/docs/_static/label/resources/mirror_mirror_on_the_wall.xcf differ diff --git a/docs/_static/label/resources/the_little_relay_that_could.xcf b/docs/_static/label/resources/the_little_relay_that_could.xcf index d54dc8c..088075a 100644 Binary files a/docs/_static/label/resources/the_little_relay_that_could.xcf and b/docs/_static/label/resources/the_little_relay_that_could.xcf differ diff --git a/docs/_static/label/resources/to_russia_with_love.xcf b/docs/_static/label/resources/to_russia_with_love.xcf index 0a36e7c..6387112 100644 Binary files a/docs/_static/label/resources/to_russia_with_love.xcf and b/docs/_static/label/resources/to_russia_with_love.xcf differ diff --git a/docs/_static/label/the_little_relay_that_could.png b/docs/_static/label/the_little_relay_that_could.png index 1d72669..b87f27c 100644 Binary files a/docs/_static/label/the_little_relay_that_could.png and b/docs/_static/label/the_little_relay_that_could.png differ diff --git a/docs/_static/label/to_russia_with_love.png b/docs/_static/label/to_russia_with_love.png index d85d109..df0ca87 100644 Binary files a/docs/_static/label/to_russia_with_love.png and b/docs/_static/label/to_russia_with_love.png differ

1 0