- tor-commits - lists.torproject.org

r25143: {website} Fix a typo and some links in TBB design doc. (website/trunk/projects/torbrowser/design)
by Mike Perry 30 Sep '11

30 Sep '11

Author: mikeperry Date: 2011-09-30 20:40:18 +0000 (Fri, 30 Sep 2011) New Revision: 25143 Modified: website/trunk/projects/torbrowser/design/index.html.en Log: Fix a typo and some links in TBB design doc. Modified: website/trunk/projects/torbrowser/design/index.html.en =================================================================== --- website/trunk/projects/torbrowser/design/index.html.en 2011-09-30 18:59:25 UTC (rev 25142) +++ website/trunk/projects/torbrowser/design/index.html.en 2011-09-30 20:40:18 UTC (rev 25143) @@ -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.75.2" /></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">Sep 29 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2881557">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary">1.1. Adversary Model</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. Priv acy 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="#Implementation">3. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">3.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">3.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">3.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">3.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">3.5. Cross-Domain Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Domain Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">3.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#click-to-play">3.8. Click -to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</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="id2881557"></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.75.2" /></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">Sep 29 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2555242">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary">1.1. Adversary Model</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. Priv acy 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="#Implementation">3. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">3.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">3.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">3.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">3.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">3.5. Cross-Domain Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Domain Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">3.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#click-to-play">3.8. Click -to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</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="id2555242"></a>1. Introduction</h2></div></div></div><p> This document describes the <a class="link" href="#adversary" title="1.1. Adversary Model">adversary model</a>, <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, @@ -310,7 +310,7 @@ Filter-based addons can also introduce strange breakage and cause usability nightmares, and will also fail to do their job if an adversary simply registers a new domain or creates a new url path. Worse still, the unique -filter sets that each user is liable to create/install likely provide a wealth +filter sets that each user creates or installs will provide a wealth of fingerprinting targets. </p><p> @@ -352,7 +352,7 @@ supported mime types for all currently installed plugins. </p><p> In addition, to prevent any unproxied activity by plugins at load time, we -also patch the Firefox source code to <a class="ulink" href="" target="_top">prevent the load of any plugins except +also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…" target="_top">prevent the load of any plugins except for Flash and Gnash</a>. </p></li><li class="listitem">External App Blocking @@ -360,20 +360,20 @@ External apps, if launched automatically, can be induced to load files that perform network activity. In order to prevent this, Torbutton installs a component to -<a class="ulink" href="" target="_top"> +<a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components…" target="_top"> provide the user with a popup</a> whenever the browser attempts to launch a helper app. </p></li></ol></div></div><div class="sect2" title="3.2. State Separation"><div class="titlepage"><div><div><h3 class="title"><a id="state-separation"></a>3.2. State Separation</h3></div></div></div><p> 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="3.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>3.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2888086"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p></div><div class="sect2" title="3.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>3.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2561771"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> Tor Browser should optionally 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. Once we <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">simplify the preferences interface</a>, we will likely just enable Private Browsing mode by default to handle this goal. - </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2914304"></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="id2587990"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> For now, Tor Browser blocks write access to the disk through Torbutton using several Firefox preferences. @@ -439,7 +439,7 @@ into specific types of state. An exmaple of this simplifcation can be seen in Figure 1. - </p><div class="figure"><a id="id2909608"></a><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="CookieManagers.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + </p><div class="figure"><a id="id2543955"></a><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="CookieManagers.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> On the left is the standard Firefox cookie manager. On the right is a mock-up of how isolating identifiers to the URL bar domain might simplify the privacy @@ -453,7 +453,7 @@ <p><span class="command"><strong>Design Goal:</strong></span> All cookies should be double-keyed to the top-level domain. There exists a -<a class="ulink" href="" target="_top">Mozilla +<a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=565965" target="_top">Mozilla bug</a> that contains a prototype patch, but it lacks UI, and does not apply to modern Firefoxes. @@ -760,11 +760,11 @@ </p></li></ol></div></div><div class="sect2" title="3.7. Long-Term Unlinkability via "New Identity" button"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>3.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p> In order to avoid long-term linkability, we provide a "New Identity" context menu option in Torbutton. - </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2894546"></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="id2573074"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> All linkable identifiers and browser state should be cleared by this feature. - </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2904450"></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="id2588627"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> First, Torbutton disables all open tabs and windows via nsIContentPolicy blocking, and then closes each tab and window. The extra step for blocking tabs is done as a precaution to @@ -865,7 +865,7 @@ This patch prevents random URLs from being inserted into content-prefs.sqllite in the profile directory as content prefs change (includes site-zoom and perhaps other site prefs?). - </p></li></ol></div></div></div><div class="sect1" title="4. Packaging"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Packaging"></a>4. Packaging</h2></div></div></div><p> </p><div class="sect2" title="4.1. Build Process Security"><div class="titlepage"><div><div><h3 class="title"><a id="build-security"></a>4.1. Build Process Security</h3></div></div></div><p> </p></div><div class="sect2" title="4.2. External Addons"><div class="titlepage"><div><div><h3 class="title"><a id="addons"></a>4.2. External Addons</h3></div></div></div><p> </p><div class="sect3" title="Included Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2869647"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2906387"></a>Excluded Addons</h4></div></div></div></div><div class="sect3" title="Dangerous Addons"><div class="titlepage"><div><div><h4 cla ss="title"><a id="id2907827"></a>Dangerous Addons</h4></div></div></div></div></div><div class="sect2" title="4.3. Pref Changes"><div class="titlepage"><div><div><h3 class="title"><a id="prefs"></a>4.3. Pref Changes</h3></div></div></div><p> </p></div><div class="sect2" title="4.4. Update Security"><div class="titlepage"><div><div><h3 class="title"><a id="update-mechanism"></a>4.4. Update Security</h3></div></div></div><p> </p></div></div><div class="sect1" title="5. Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Testing"></a>5. Testing</h2></div></div></div><p> + </p></li></ol></div></div></div><div class="sect1" title="4. Packaging"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Packaging"></a>4. Packaging</h2></div></div></div><p> </p><div class="sect2" title="4.1. Build Process Security"><div class="titlepage"><div><div><h3 class="title"><a id="build-security"></a>4.1. Build Process Security</h3></div></div></div><p> </p></div><div class="sect2" title="4.2. External Addons"><div class="titlepage"><div><div><h3 class="title"><a id="addons"></a>4.2. External Addons</h3></div></div></div><p> </p><div class="sect3" title="Included Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2555211"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2581163"></a>Excluded Addons</h4></div></div></div></div><div class="sect3" title="Dangerous Addons"><div class="titlepage"><div><div><h4 cla ss="title"><a id="id2587402"></a>Dangerous Addons</h4></div></div></div></div></div><div class="sect2" title="4.3. Pref Changes"><div class="titlepage"><div><div><h3 class="title"><a id="prefs"></a>4.3. Pref Changes</h3></div></div></div><p> </p></div><div class="sect2" title="4.4. Update Security"><div class="titlepage"><div><div><h3 class="title"><a id="update-mechanism"></a>4.4. Update Security</h3></div></div></div><p> </p></div></div><div class="sect1" title="5. Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Testing"></a>5. Testing</h2></div></div></div><p> The purpose of this section is to cover all the known ways that Tor browser security can be subverted from a penetration testing perspective. The hope

1 0

r25142: {} Take the /en/ out of the TBB design doc. (in website/trunk/projects: . en)
by Mike Perry 30 Sep '11

30 Sep '11

Author: mikeperry Date: 2011-09-30 18:59:25 +0000 (Fri, 30 Sep 2011) New Revision: 25142 Added: website/trunk/projects/torbrowser/ Removed: website/trunk/projects/en/torbrowser/ Log: Take the /en/ out of the TBB design doc.

1 0

[torbrowser/maint-2.2] move all of the extension download locations to one file, and update noscript's url
by erinn＠torproject.org 30 Sep '11

30 Sep '11

commit b44210d6f9c79aa5c7e3b9fc0caf8558f6def7c5 Author: Erinn Clark <erinn(a)torproject.org> Date: Fri Sep 30 17:29:57 2011 +0100 move all of the extension download locations to one file, and update noscript's url --- build-scripts/linux.mk | 5 ----- build-scripts/osx.mk | 5 ----- build-scripts/versions.mk | 6 ++++++ build-scripts/windows.mk | 5 ----- 4 files changed, 6 insertions(+), 15 deletions(-) diff --git a/build-scripts/linux.mk b/build-scripts/linux.mk index bd16d4d..090ee8e 100644 --- a/build-scripts/linux.mk +++ b/build-scripts/linux.mk @@ -183,11 +183,6 @@ endif ## Extensions to install by default DEFAULT_EXTENSIONS=torbutton.xpi noscript.xpi httpseverywhere.xpi -## Where to download Torbutton from -TORBUTTON=https://www.torproject.org/dist/torbutton/torbutton-$(TORBUTTON_VER).xpi -NOSCRIPT=https://secure.informaction.com/download/releases/noscript-$(NOSCRIPT_VER).xpi -BETTERPRIVACY=https://addons.mozilla.org/en-US/firefox/downloads/latest/6623/addon-6623-latest.xpi -HTTPSEVERYWHERE=https://eff.org/files/https-everywhere-$(HTTPSEVERY_VER).xpi ## Where to download Mozilla language packs MOZILLA_LANGUAGE=http://releases.mozilla.org/pub/mozilla.org/firefox/releas… diff --git a/build-scripts/osx.mk b/build-scripts/osx.mk index d2de9dc..5d5dbc1 100644 --- a/build-scripts/osx.mk +++ b/build-scripts/osx.mk @@ -172,11 +172,6 @@ endif ## Extensions to install by default DEFAULT_EXTENSIONS=torbutton.xpi -## Where to download Torbutton from -TORBUTTON=https://www.torproject.org/dist/torbutton/torbutton-$(TORBUTTON_VER).xpi -NOSCRIPT=https://secure.informaction.com/download/releases/noscript-$(NOSCRIPT_VER).xpi -BETTERPRIVACY=https://addons.mozilla.org/en-US/firefox/downloads/latest/6623/addon-6623-latest.xpi -HTTPSEVERYWHERE=https://eff.org/files/https-everywhere-$(HTTPSEVERY_VER).xpi ## Where to download Mozilla language packs MOZILLA_LANGUAGE=http://releases.mozilla.org/pub/mozilla.org/firefox/releas… diff --git a/build-scripts/versions.mk b/build-scripts/versions.mk index 8856a87..f36759c 100644 --- a/build-scripts/versions.mk +++ b/build-scripts/versions.mk @@ -19,6 +19,12 @@ ZLIB_VER=1.2.5 ## Extension IDs FF_VENDOR_ID:=\{ec8030f7-c20a-464f-9b0e-13a3a9e97384\} +## Extensions +TORBUTTON=https://www.torproject.org/dist/torbutton/torbutton-$(TORBUTTON_VER).xpi +NOSCRIPT=https://addons.mozilla.org/firefox/downloads/latest/722/addon-722-latest.xpi +BETTERPRIVACY=https://addons.mozilla.org/en-US/firefox/downloads/latest/6623/addon-6623-latest.xpi +HTTPSEVERYWHERE=https://eff.org/files/https-everywhere-$(HTTPSEVERY_VER).xpi + ## File names for the source packages ZLIB_PACKAGE=zlib-$(ZLIB_VER).tar.gz OPENSSL_PACKAGE=openssl-$(OPENSSL_VER).tar.gz diff --git a/build-scripts/windows.mk b/build-scripts/windows.mk index b3e199c..8bfa747 100644 --- a/build-scripts/windows.mk +++ b/build-scripts/windows.mk @@ -161,11 +161,6 @@ endif ## Extensions to install by default DEFAULT_EXTENSIONS=torbutton.xpi -## Where to download Torbutton from -TORBUTTON=https://www.torproject.org/dist/torbutton/torbutton-$(TORBUTTON_VER).xpi -NOSCRIPT=https://secure.informaction.com/download/releases/noscript-$(NOSCRIPT_VER).xpi -BETTERPRIVACY=https://addons.mozilla.org/en-US/firefox/downloads/latest/6623/addon-6623-latest.xpi -HTTPSEVERYWHERE=https://eff.org/files/https-everywhere-$(HTTPSEVERY_VER).xpi ## Where to download Mozilla language packs MOZILLA_LANGUAGE=http://releases.mozilla.org/pub/mozilla.org/firefox/releas…

1 0

[torbrowser/maint-2.2] bump all tbb versions, update changelogs and readmes for firefox 7.0.1
by erinn＠torproject.org 30 Sep '11

30 Sep '11

commit 7a8765f0bb3c3fc3eb8affdf753d7272691ffbe3 Author: Erinn Clark <erinn(a)torproject.org> Date: Fri Sep 30 16:34:22 2011 +0100 bump all tbb versions, update changelogs and readmes for firefox 7.0.1 --- README.LINUX-2.2 | 2 +- README.OSX-2.2 | 2 +- README.WIN-2.2 | 4 ++-- build-scripts/linux.mk | 2 +- build-scripts/osx.mk | 2 +- build-scripts/windows.mk | 2 +- changelog.linux-2.2 | 6 ++++++ changelog.osx-2.2 | 6 ++++++ changelog.windows-2.2 | 6 ++++++ 9 files changed, 25 insertions(+), 7 deletions(-) diff --git a/README.LINUX-2.2 b/README.LINUX-2.2 index 5448f89..914b537 100644 --- a/README.LINUX-2.2 +++ b/README.LINUX-2.2 @@ -6,7 +6,7 @@ Included applications Vidalia 0.2.14 (with Qt 4.6.2) Tor 0.2.2.33 (with libevent-2.0.14-stable, zlib-1.2.5 and openssl-1.0.0e) -Firefox (Aurora) 7.0 +Firefox (Aurora) 7.0.1 \_ Torbutton 1.4.3 |_ NoScript 2.1.2.8 |_ HTTPS-Everywhere 1.0.3 diff --git a/README.OSX-2.2 b/README.OSX-2.2 index fd6ae31..dcb3e7e 100644 --- a/README.OSX-2.2 +++ b/README.OSX-2.2 @@ -6,7 +6,7 @@ Included applications Vidalia 0.2.14 (with Qt 4.6.2) Tor 0.2.2.33 (with libevent-2.0.14-stable, zlib-1.2.5 and openssl-1.0.0d) -Firefox (Aurora) 7.0 +Firefox (Aurora) 7.0.1 \_ Torbutton 1.4.3 |_ NoScript 2.1.2.8 |_ HTTPS-Everywhere 1.0.3 diff --git a/README.WIN-2.2 b/README.WIN-2.2 index bd27aa1..3cc6141 100644 --- a/README.WIN-2.2 +++ b/README.WIN-2.2 @@ -6,8 +6,8 @@ Included applications Vidalia 0.2.14 (with Qt 4.6.2) Tor 0.2.2.33 (with libevent-2.0.14-stable, zlib-1.2.5 and openssl-1.0.0e) -FirefoxPortable 7.0 - \_ Firefox (Aurora) 7.0 +FirefoxPortable 7.0.1 + \_ Firefox (Aurora) 7.0.1 \_ Torbutton 1.4.3 |_ NoScript 2.1.2.8 |_ HTTPS-Everywhere 1.0.3 diff --git a/build-scripts/linux.mk b/build-scripts/linux.mk index c37447d..bd16d4d 100644 --- a/build-scripts/linux.mk +++ b/build-scripts/linux.mk @@ -36,7 +36,7 @@ include $(PWD)/versions.mk ## Architecture ARCH_TYPE=$(shell uname -m) -BUILD_NUM=1 +BUILD_NUM=2 PLATFORM=Linux ## Location of directory for source unpacking diff --git a/build-scripts/osx.mk b/build-scripts/osx.mk index 1ea955b..d2de9dc 100644 --- a/build-scripts/osx.mk +++ b/build-scripts/osx.mk @@ -36,7 +36,7 @@ include $(PWD)/versions.mk ## Architecture ARCH_TYPE=i386 -BUILD_NUM=1 +BUILD_NUM=2 PLATFORM=MacOS ## Location of directory for source unpacking diff --git a/build-scripts/windows.mk b/build-scripts/windows.mk index 739317f..b3e199c 100644 --- a/build-scripts/windows.mk +++ b/build-scripts/windows.mk @@ -31,7 +31,7 @@ ## Include versions include $(PWD)/versions.mk -BUILD_NUM=1 +BUILD_NUM=2 PLATFORM=Windows ## Location of required libraries diff --git a/changelog.linux-2.2 b/changelog.linux-2.2 index df90085..285914c 100644 --- a/changelog.linux-2.2 +++ b/changelog.linux-2.2 @@ -1,3 +1,9 @@ +Tor Browser Bundle (2.2.33-2); suite=linux + + * Update Firefox to 7.0.1 + + -- Erinn Clark <erinn(a)torproject.org> Fri Sep 30 16:32:50 BST 2011 + Tor Browser Bundle (2.2.33-1); suite=linux * Update Firefox to 7 diff --git a/changelog.osx-2.2 b/changelog.osx-2.2 index 75eb8d8..ad31c2e 100644 --- a/changelog.osx-2.2 +++ b/changelog.osx-2.2 @@ -1,3 +1,9 @@ +Tor Browser Bundle (2.2.33-2); suite=osx + + * Update Firefox to 7.0.1 + + -- Erinn Clark <erinn(a)torproject.org> Fri Sep 30 16:31:59 BST 2011 + Tor Browser Bundle (2.2.33-1); suite=osx * Update Firefox to 7 diff --git a/changelog.windows-2.2 b/changelog.windows-2.2 index 510cac2..f183ae4 100644 --- a/changelog.windows-2.2 +++ b/changelog.windows-2.2 @@ -1,3 +1,9 @@ +Tor Browser Bundle (2.2.33-2); suite=windows + + * Update Firefox to 7.0.1 + + -- Erinn Clark <erinn(a)torproject.org> Fri Sep 30 16:32:33 BST 2011 + Tor Browser Bundle (2.2.33-1); suite=windows * Update Firefox to 7

1 0

r25141: {} Add design doc draft. (in website/trunk/projects/en: . torbrowser torbrowser/design)
by Mike Perry 30 Sep '11

30 Sep '11

Author: mikeperry Date: 2011-09-30 02:24:16 +0000 (Fri, 30 Sep 2011) New Revision: 25141 Added: website/trunk/projects/en/torbrowser/ website/trunk/projects/en/torbrowser/design/ website/trunk/projects/en/torbrowser/design/CookieManagers.png website/trunk/projects/en/torbrowser/design/index.html.en Log: Add design doc draft. Added: website/trunk/projects/en/torbrowser/design/CookieManagers.png =================================================================== (Binary files differ) Property changes on: website/trunk/projects/en/torbrowser/design/CookieManagers.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: website/trunk/projects/en/torbrowser/design/index.html.en =================================================================== --- website/trunk/projects/en/torbrowser/design/index.html.en (rev 0) +++ website/trunk/projects/en/torbrowser/design/index.html.en 2011-09-30 02:24:16 UTC (rev 25141) @@ -0,0 +1,955 @@ +<?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.75.2" /></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">Sep 29 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2881557">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary">1.1. Adversary Model</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. Priv acy 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="#Implementation">3. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">3.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">3.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">3.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">3.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">3.5. Cross-Domain Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Domain Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">3.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#click-to-play">3.8. Click -to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</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="id2881557"></a>1. Introduction</h2></div></div></div><p> + +This document describes the <a class="link" href="#adversary" title="1.1. Adversary Model">adversary model</a>, +<a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, +<a class="link" href="#Implementation" title="3. Implementation">implementation</a>, <a class="link" href="#Packaging" title="4. Packaging">packaging</a> and <a class="link" href="#Testing" title="5. Testing">testing +procedures</a> of the Tor Browser. It is +current as of Tor Browser 2.2.32-4. + + </p><p> + +This document is also meant to serve as a set of design requirements and to +describe a reference implementation of a Private Browsing Mode that defends +against both local and network adversaries. + + </p><div class="sect2" title="1.1. Adversary Model"><div class="titlepage"><div><div><h3 class="title"><a id="adversary"></a>1.1. Adversary Model</h3></div></div></div><p> + +A Tor web browser adversary has a number of goals, capabilities, and attack +types that can be used to guide us towards a set of requirements for the +Tor Browser. Let's start with the goals. + + </p><div class="sect3" title="Adversary Goals"><div class="titlepage"><div><div><h4 class="title"><a id="adversarygoals"></a>Adversary Goals</h4></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of +Tor, causing the user to directly connect to an IP of the adversary's +choosing.</p></li><li class="listitem"><span class="command"><strong>Correlation of Tor vs Non-Tor Activity</strong></span><p>If direct proxy bypass is not possible, the adversary will likely +happily settle for the ability to correlate something a user did via Tor with +their non-Tor activity. This can be done with cookies, cache identifiers, +javascript events, and even CSS. Sometimes the fact that a user uses Tor may +be enough for some authorities.</p></li><li class="listitem"><span class="command"><strong>History disclosure</strong></span><p> +The adversary may also be interested in history disclosure: the ability to +query a user's history to see if they have issued certain censored search +queries, or visited censored sites. + </p></li><li class="listitem"><span class="command"><strong>Location information</strong></span><p> + +Location information such as timezone and locality can be useful for the +adversary to determine if a user is in fact originating from one of the +regions they are attempting to control, or to zero-in on the geographical +location of a particular dissident or whistleblower. + + </p></li><li class="listitem"><span class="command"><strong>Miscellaneous anonymity set reduction</strong></span><p> + +Anonymity set reduction is also useful in attempting to zero in on a +particular individual. If the dissident or whistleblower is using a rare build +of Firefox for an obscure operating system, this can be very useful +information for tracking them down, or at least <a class="link" href="#fingerprinting">tracking their activities</a>. + + </p></li><li class="listitem"><span class="command"><strong>History records and other on-disk +information</strong></span><p> +In some cases, the adversary may opt for a heavy-handed approach, such as +seizing the computers of all Tor users in an area (especially after narrowing +the field by the above two pieces of information). History records and cache +data are the primary goals here. + </p></li></ol></div></div><div class="sect3" title="Adversary Capabilities - Positioning"><div class="titlepage"><div><div><h4 class="title"><a id="adversarypositioning"></a>Adversary Capabilities - Positioning</h4></div></div></div><p> +The adversary can position themselves at a number of different locations in +order to execute their attacks. + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Exit Node or Upstream Router</strong></span><p> +The adversary can run exit nodes, or alternatively, they may control routers +upstream of exit nodes. Both of these scenarios have been observed in the +wild. + </p></li><li class="listitem"><span class="command"><strong>Adservers and/or Malicious Websites</strong></span><p> +The adversary can also run websites, or more likely, they can contract out +ad space from a number of different adservers and inject content that way. For +some users, the adversary may be the adservers themselves. It is not +inconceivable that adservers may try to subvert or reduce a user's anonymity +through Tor for marketing purposes. + </p></li><li class="listitem"><span class="command"><strong>Local Network/ISP/Upstream Router</strong></span><p> +The adversary can also inject malicious content at the user's upstream router +when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor +activity. + </p></li><li class="listitem"><span class="command"><strong>Physical Access</strong></span><p> +Some users face adversaries with intermittent or constant physical access. +Users in Internet cafes, for example, face such a threat. In addition, in +countries where simply using tools like Tor is illegal, users may face +confiscation of their computer equipment for excessive Tor usage or just +general suspicion. + </p></li></ol></div></div><div class="sect3" title="Adversary Capabilities - Attacks"><div class="titlepage"><div><div><h4 class="title"><a id="attacks"></a>Adversary Capabilities - Attacks</h4></div></div></div><p> + +The adversary can perform the following attacks from a number of different +positions to accomplish various aspects of their goals. It should be noted +that many of these attacks (especially those involving IP address leakage) are +often performed by accident by websites that simply have Javascript, dynamic +CSS elements, and plugins. Others are performed by adservers seeking to +correlate users' activity across different IP addresses, and still others are +performed by malicious agents on the Tor network and at national firewalls. + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Inserting Javascript</strong></span><p> +If not properly disabled, Javascript event handlers and timers +can cause the browser to perform network activity after Tor has been disabled, +thus allowing the adversary to correlate Tor and Non-Tor activity and reveal +a user's non-Tor IP address. Javascript +also allows the adversary to execute <a class="ulink" href="http://whattheinternetknowsaboutyou.com/" target="_top">history disclosure attacks</a>: +to query the history via the different attributes of 'visited' links to search +for particular Google queries, sites, or even to <a class="ulink" href="http://www.mikeonads.com/2008/07/13/using-your-browser-url-history-estimate…" target="_top">profile +users based on gender and other classifications</a>. Finally, +Javascript can be used to query the user's timezone via the +<code class="function">Date()</code> object, and to reduce the anonymity set by querying +the <code class="function">navigator</code> object for operating system, CPU, locale, +and user agent information. + </p></li><li class="listitem"><span class="command"><strong>Inserting Plugins</strong></span><p> + +Plugins are abysmal at obeying the proxy settings of the browser. Every plugin +capable of performing network activity that the author has +investigated is also capable of performing network activity independent of +browser proxy settings - and often independent of its own proxy settings. +Sites that have plugin content don't even have to be malicious to obtain a +user's +Non-Tor IP (it usually leaks by itself), though <a class="ulink" href="http://decloak.net" target="_top">plenty of active +exploits</a> are possible as well. In addition, plugins can be used to store unique identifiers that are more +difficult to clear than standard cookies. +<a class="ulink" href="http://epic.org/privacy/cookies/flash.html" target="_top">Flash-based +cookies</a> fall into this category, but there are likely numerous other +examples. + + </p></li><li class="listitem"><span class="command"><strong>Inserting CSS</strong></span><p> + +CSS can also be used to correlate Tor and Non-Tor activity and reveal a user's +Non-Tor IP address, via the usage of +<a class="ulink" href="http://www.tjkdesign.com/articles/css%20pop%20ups/" target="_top">CSS +popups</a> - essentially CSS-based event handlers that fetch content via +CSS's onmouseover attribute. If these popups are allowed to perform network +activity in a different Tor state than they were loaded in, they can easily +correlate Tor and Non-Tor activity and reveal a user's IP address. In +addition, CSS can also be used without Javascript to perform <a class="ulink" href="http://ha.ckers.org/weird/CSS-history.cgi" target="_top">CSS-only history disclosure +attacks</a>. + </p></li><li class="listitem"><span class="command"><strong>Read and insert cookies</strong></span><p> + +An adversary in a position to perform MITM content alteration can inject +document content elements to both read and inject cookies for arbitrary +domains. In fact, many "SSL secured" websites are vulnerable to this sort of +<a class="ulink" href="http://seclists.org/bugtraq/2007/Aug/0070.html" target="_top">active +sidejacking</a>. In addition, the ad networks of course perform tracking +with cookies as well. + + </p></li><li class="listitem"><span class="command"><strong>Create arbitrary cached content</strong></span><p> + +Likewise, the browser cache can also be used to <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html" target="_top">store unique +identifiers</a>. Since by default the cache has no same-origin policy, +these identifiers can be read by any domain, making them an ideal target for +ad network-class adversaries. + + </p></li><li class="listitem"><a id="fingerprinting"></a><span class="command"><strong>Fingerprint users based on browser +attributes</strong></span><p> + +There is an absurd amount of information available to websites via attributes +of the browser. This information can be used to reduce anonymity set, or even +<a class="ulink" href="http://mandark.fr/0x000000/articles/Total_Recall_On_Firefox..html" target="_top">uniquely +fingerprint individual users</a>. </p><p> + +The <a class="ulink" href="https://wiki.mozilla.org/Fingerprinting#Data" target="_top">Panopticlick study +done</a> by the EFF attempts to measure the actual entropy - the number of +identifying bits of information encoded in browser properties. Their result +data is definitely useful, and the metric is probably the appropriate one for +determining how identifying a particular browser property is. However, some +quirks of their study means that they do not extract as much information as +they could from display information: they only use desktop resolution (which +Torbutton reports as the window resolution) and do not attempt to infer the +size of toolbars. + + + +</p></li><li class="listitem"><span class="command"><strong>Remotely or locally exploit browser and/or +OS</strong></span><p> + +Last, but definitely not least, the adversary can exploit either general +browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to +install malware and surveillance software. An adversary with physical access +can perform similar actions. Regrettably, this last attack capability is +outside of our ability to defend against, but it is worth mentioning for +completeness. <a class="ulink" href="http://tails.boum.org/contribute/design/" target="_top">The Tails +system</a> however can provide some limited defenses against this +adversary. + + </p></li></ol></div></div></div></div><div class="sect1" title="2. Design Requirements and Philosophy"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="DesignRequirements"></a>2. Design Requirements and Philosophy</h2></div></div></div><p> + +The Tor Browser Design Requirements are meant to describe the properties of a +Private Browsing Mode that defends against both network and local adversaries. + + </p><p> + +There are two main categories of requirements: <a class="link" href="#security" title="2.1. Security Requirements">Security Requirements</a>, and <a class="link" href="#privacy" title="2.2. Privacy Requirements">Privacy Requirements</a>. Security Requirements are the +minimum properties in order for a web client platform to be able to support +Tor. Privacy requirements are the set of properties that cause us to prefer +one platform over another. + + </p><p> + +We will maintain an alternate distribution of the web client in order to +maintain and/or restore privacy properties to our users. + + </p><div class="sect2" title="2.1. Security Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="security"></a>2.1. Security Requirements</h3></div></div></div><p> + +The security requirements are primarily concerned with ensuring the safe use +of Tor. Violations in these properties typically result in serious risk for +the user in terms of immediate deanonymization and/or observability. + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Proxy Obedience</strong></span><p>The browser +MUST NOT bypass Tor proxy settings for any content.</p></li><li class="listitem"><span class="command"><strong>State Separation</strong></span><p>The browser MUST NOT provide any stored state to the content window +from other browsers or other browsing modes, including shared state from +plugins, machine identifiers, and TLS session state. +</p></li><li class="listitem"><span class="command"><strong>Disk Avoidance</strong></span><p>The +browser SHOULD NOT write any browsing history information to disk, or store it +in memory beyond the duration of one Tor session, unless the user has +explicitly opted to store their browsing history information to +disk.</p></li><li class="listitem"><span class="command"><strong>Application Data Isolation</strong></span><p>The browser +MUST NOT write or cause the operating system to +write <span class="emphasis"><em>any information</em></span> to disk outside of the application +directory. All exceptions and shortcomings due to operating system behavior +MUST BE documented. + +</p></li><li class="listitem"><span class="command"><strong>Update Safety</strong></span><p>The browser SHOULD NOT perform unsafe updates or upgrades.</p></li></ol></div></div><div class="sect2" title="2.2. Privacy Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="privacy"></a>2.2. Privacy Requirements</h3></div></div></div><p> + +The privacy requirements are primarily concerned with reducing linkability: +the ability for a user's activity on one site to be linked with their +activity on another site without their knowledge or explicit consent. + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Cross-Domain Identifier Unlinkability</strong></span><p> + +User activity on one url bar domain MUST NOT be linkable to their activity in +any other domain by any third party. This property specifically applies to +linkability from stored browser identifiers, authentication tokens, and shared +state. This functionality SHOULD NOT interfere with federated login in a +substantial way. + + </p></li><li class="listitem"><span class="command"><strong>Cross-Domain Fingerprinting Unlinkability</strong></span><p> + +User activity on one url bar domain MUST NOT be linkable to their activity in +any other domain by any third party. This property specifically applies to +linkability from fingerprinting browser behavior. + + </p></li><li class="listitem"><span class="command"><strong>Long-Term Unlinkability</strong></span><p> + +The browser SHOULD provide an obvious, easy way to remove all of their authentication +tokens and browser state and obtain a fresh identity. Additionally, this +should happen by default automatically upon browser restart. + + </p></li></ol></div></div><div class="sect2" title="2.3. Philosophy"><div class="titlepage"><div><div><h3 class="title"><a id="philosophy"></a>2.3. Philosophy</h3></div></div></div><p> + +In addition to the above design requirements, the technology decisions about +Tor Browser are also guided by some philosophical positions about technology. + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Preserve existing user model</strong></span><p> + +The existing way that the user expects to use a browser must be preserved. If +the user has to maintain a different mental model of how the sites they are +using behave depending on tab, browser state, or anything else that would not +normally be what they experience in their default browser, the user will +inevitably be confused. They will make mistakes and reduce their privacy as a +result. Worse, they may just stop using the browser, assuming it is broken. + + </p><p> + +User model breakage was one of the <a class="ulink" href="https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton" target="_top">failures +of Torbutton</a>: Even if users managed to install everything properly, +the toggle model was too hard for the average user to understand, especially +in the face of accumulating tabs from multiple states crossed with the current +tor-state of the browser. + + </p></li><li class="listitem"><span class="command"><strong>Favor the implementation mechanism least likely to +break sites</strong></span><p> + +In general, we try to find solutions to privacy issues that will not induce +site breakage, though this is not always possible. + + </p></li><li class="listitem"><span class="command"><strong>Plugins must be restricted</strong></span><p> + +Even if plugins always properly used the browser proxy settings (which none of +them do) and could not be induced to bypass them (which all of them can), the +activities of closed-source plugins are very difficult to audit and control. +They can obtain and transmit all manner of system information to websites, +often have their own identifier storage for tracking users, and also +contribute to fingerprinting. + + </p><p> + +Therefore, if plugins are to be enabled in private browsing modes, they must +be restricted from running automatically on every page (via click-to-play +placeholders), and/or be sandboxed to restrict the types of system calls they +can execute. If the user decides to craft an exemption to allow a plugin to be +used, it MUST ONLY apply to the top level urlbar domain, and not to all sites, +to reduce linkability. + + </p></li><li class="listitem"><span class="command"><strong>Minimize Global Privacy Options</strong></span><p> + +<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">Another +failure of Torbutton</a> was (and still is) the options panel. Each option +that detectably alters browser behavior can be used as a fingerprinting tool. +Similarly, all extensions <a class="ulink" href="http://blog.chromium.org/2010/06/extensions-in-incognito.html" target="_top">should be +disabled in the mode</a> except as an opt-in basis. We should not load +system-wide addons or plugins. + + </p><p> +Instead of global browser privacy options, privacy decisions should be made +<a class="ulink" href="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI" target="_top">per +top-level url-bar domain</a> to eliminate the possibility of linkability +between domains. For example, when a plugin object (or a Javascript access of +window.plugins) is present in a page, the user should be given the choice of +allowing that plugin object for that top-level url-bar domain only. The same +goes for exemptions to third party cookie policy, geo-location, and any other +privacy permissions. + </p><p> +If the user has indicated they do not care about local history storage, these +permissions can be written to disk. Otherwise, they should remain memory-only. + </p></li><li class="listitem"><span class="command"><strong>No filters</strong></span><p> + +Filter-based addons such as <a class="ulink" href="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/" target="_top">AdBlock +Plus</a>, <a class="ulink" href="" target="_top">Request Policy</a>, <a class="ulink" href="http://priv3.icsi.berkeley.edu/" target="_top">Priv3</a>, and <a class="ulink" href="http://sharemenot.cs.washington.edu/" target="_top">Sharemenot</a> are to be +avoided. We believe that these addons do not add any real privacy to a proper +<a class="link" href="#Implementation" title="3. Implementation">implementation</a> of the above <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy requirements</a>, as all third parties are +prevented from tracking users between sites by the implementation. +Filter-based addons can also introduce strange breakage and cause usability +nightmares, and will also fail to do their job if an adversary simply +registers a new domain or creates a new url path. Worse still, the unique +filter sets that each user is liable to create/install likely provide a wealth +of fingerprinting targets. + + </p><p> + +As a general matter, we are also generally opposed to shipping an always-on Ad +blocker with Tor Browser. We feel that this would damage our credibility in +terms of demonstrating that we are providing privacy through a sound design +alone, as well as damage the acceptance of Tor users by sites who support +themselves through advertising revenue. + + </p><p> +Users are free to install these addons if they wish, but doing +so is not recommended, as it will alter the browser request fingerprint. + </p></li><li class="listitem"><span class="command"><strong>Stay Current</strong></span><p> +We believe that if we do not stay current with the support of new web +technologies, we cannot hope to substantially influence or be involved in +their proper deployment or privacy realization. However, we will likely disable +certain new features (where possible) pending analysis and audit. + </p></li></ol></div></div></div><div class="sect1" title="3. Implementation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Implementation"></a>3. Implementation</h2></div></div></div><p> + </p><div class="sect2" title="3.1. Proxy Obedience"><div class="titlepage"><div><div><h3 class="title"><a id="proxy-obedience"></a>3.1. Proxy Obedience</h3></div></div></div><p> + +Proxy obedience is assured through the following: + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Firefox Proxy settings + <p> + The Torbutton xpi sets the Firefox proxy settings to use Tor directly as a +SOCKS proxy. It sets <span class="command"><strong>network.proxy.socks_remote_dns</strong></span>, +<span class="command"><strong>network.proxy.socks_version</strong></span>, and +<span class="command"><strong>network.proxy.socks_port</strong></span>. + </p></li><li class="listitem">Disabling plugins + <p> + Plugins have the ability to make arbitrary OS system calls. This includes +the ability to make UDP sockets and send arbitrary data independent of the +browser proxy settings. + </p><p> +Torbutton disables plugins by using the +<span class="command"><strong>@mozilla.org/plugin/host;1</strong></span> service to mark the plugin tags +as disabled. Additionally, we set +<span class="command"><strong>plugin.disable_full_page_plugin_for_types</strong></span> to the list of +supported mime types for all currently installed plugins. + </p><p> +In addition, to prevent any unproxied activity by plugins at load time, we +also patch the Firefox source code to <a class="ulink" href="" target="_top">prevent the load of any plugins except +for Flash and Gnash</a>. + + </p></li><li class="listitem">External App Blocking + <p> +External apps, if launched automatically, can be induced to load files that +perform network activity. In order to prevent this, Torbutton installs a +component to +<a class="ulink" href="" target="_top"> +provide the user with a popup</a> whenever the browser attempts to +launch a helper app. + </p></li></ol></div></div><div class="sect2" title="3.2. State Separation"><div class="titlepage"><div><div><h3 class="title"><a id="state-separation"></a>3.2. State Separation</h3></div></div></div><p> +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="3.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>3.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2888086"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> +Tor Browser should optionally 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. Once we <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">simplify the +preferences interface</a>, we will likely just enable Private Browsing +mode by default to handle this goal. + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2914304"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> +For now, Tor Browser blocks write access to the disk through Torbutton +using several Firefox preferences. + + + +The set of prefs is: +<span class="command"><strong>dom.storage.enabled</strong></span>, +<span class="command"><strong>browser.cache.memory.enable</strong></span>, +<span class="command"><strong>network.http.use-cache</strong></span>, +<span class="command"><strong>browser.cache.disk.enable</strong></span>, +<span class="command"><strong>browser.cache.offline.enable</strong></span>, +<span class="command"><strong>general.open_location.last_url</strong></span>, +<span class="command"><strong>places.history.enabled</strong></span>, +<span class="command"><strong>browser.formfill.enable</strong></span>, +<span class="command"><strong>signon.rememberSignons</strong></span>, +<span class="command"><strong>browser.download.manager.retention</strong></span>, +and <span class="command"><strong>network.cookie.lifetimePolicy</strong></span>. + </blockquote></div></div><p> +In addition, three Firefox patches are needed to prevent disk writes, even if +Private Browsing Mode is enabled. We need to + +<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…" target="_top">prevent +the permissions manager from recording HTTPS STS state</a>, +<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…" target="_top">prevent +intermediate SSL certificates from being recorded</a>, and +<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…" target="_top">prevent +the content preferences service from recording site zoom</a>. + +For more details on these patches, <a class="link" href="#firefox-patches" title="3.9. Description of Firefox Patches">see the +Firefox Patches section</a>. + + </p></div><div class="sect2" title="3.4. Application Data Isolation"><div class="titlepage"><div><div><h3 class="title"><a id="app-data-isolation"></a>3.4. Application Data Isolation</h3></div></div></div><p> + +Tor Browser Bundle MUST NOT cause any information to be written outside of the +bundle directory. This is to ensure that the user is able to completely and +safely remove the bundle without leaving other traces of Tor usage on their +computer. + + </p><p>XXX: sjmurdoch, Erinn: explain what magic we do to satisfy this, +and/or what additional work or auditing needs to be done. + </p></div><div class="sect2" title="3.5. Cross-Domain Identifier Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"></a>3.5. Cross-Domain Identifier Unlinkability</h3></div></div></div><p> + +The Tor Browser MUST prevent a user's activity on one site from being linked +to their activity on another site. When this goal cannot yet be met with an +existing web technology, that technology or functionality is disabled. Our +<a class="link" href="#privacy" title="2.2. Privacy Requirements">design goal</a> is to ultimately eliminate the need to disable arbitrary +technologies, and instead simply alter them in ways that allows them to +function in a backwards-compatible way while avoiding linkability. Users +should be able to use federated login of various kinds to explicitly inform +sites who they are, but that information should not transparently allow a +third party to record their activity from site to site without their prior +consent. + + </p><p> + +The benefit of this approach comes not only in the form of reduced +linkability, but also in terms of simplified privacy UI. If all stored browser +state and permissions become associated with the top-level url-bar domain, the +six or seven different pieces of privacy UI governing these identifiers and +permissions can become just one piece of UI. For instance, a window that lists +the top-level url bar domains for which browser state exists with the ability +to clear and/or block them, possibly with a context-menu option to drill down +into specific types of state. An exmaple of this simplifcation can be seen in +Figure 1. + + </p><div class="figure"><a id="id2909608"></a><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="CookieManagers.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + +On the left is the standard Firefox cookie manager. On the right is a mock-up +of how isolating identifiers to the URL bar domain might simplify the privacy +UI for all data - not just cookies. Both windows represent the set of +Cookies accomulated after visiting just five sites, but the window on the +right has the option of also representing history, DOM Storage, HTTP Auth, +search form history, login values, and so on within a context menu for each +site. + +</div></div></div><br class="figure-break" /><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Cookies + <p><span class="command"><strong>Design Goal:</strong></span> + +All cookies should be double-keyed to the top-level domain. There exists a +<a class="ulink" href="" target="_top">Mozilla +bug</a> that contains a prototype patch, but it lacks UI, and does not +apply to modern Firefoxes. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +As a stopgap to satisfy our design requirement of unlinkability, we currently +entirely disable 3rd party cookies by setting +<span class="command"><strong>network.cookie.cookieBehavior</strong></span> to 1. We would prefer that +third party content continue to function , but we believe the requirement for +unlinkability trumps that desire. + + </p></li><li class="listitem">Cache + <p> +Cache is isolated to the top-level url bar domain by using a technique +pioneered by Colin Jackson et al, via their work on <a class="ulink" href="http://www.safecache.com/" target="_top">SafeCache</a>. The technique re-uses the +<a class="ulink" href="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel" target="_top">nsICachingChannel.cacheKey</a> +attribute that Firefox uses internally to prevent improper caching of HTTP POST data. + </p><p> +However, to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the +security of the isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve strange and +unknown conflicts with OCSP</a>, we had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…" target="_top">patch +Firefox to provide a cacheDomain cache attribute</a>. We use the full +url bar domain as input to this field. + </p><p> + + +Furthermore, we chose a different isolation scheme than the Stanford +implementation. First, we decoupled the cache isolation from the third party +cookie attribute. Second, we use several mechanisms to attempt to determine +the actual location attribute of the top-level window (the url bar domain) +used to load the page, as opposed to relying solely on the referer property. + </p><p> +Therefore, <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html" target="_top">the original +Stanford test +cases</a> are expected to fail. Functionality can still be verified by +navigating to <a class="ulink" href="about:cache" target="_top">about:cache</a> and viewing the key +used for each cache entry. Each third party element should have an additional +"domain=string" property prepended, which will list the top-level urlbar +domain that was used to source the third party element. + </p></li><li class="listitem">HTTP Auth + <p> + +HTTP authentication tokens are removed for third party elements using the +<a class="ulink" href="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers" target="_top">http-on-modify-request +observer</a> to remove the Authorization headers to prevent <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies…" target="_top">silent +linkability between domains</a>. We also needed to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…" target="_top">patch +Firefox to cause the headers to get added early enough</a> to allow the +observer to modify it. + + </p></li><li class="listitem">DOM Storage + <p><span class="command"><strong>Design Goal:</strong></span> + +DOM storage for third party domains MUST BE isolated to the url bar domain, +to prevent linkability between sites. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +Because it is isolated to third party domain as opposed to top level url bar +domain, we entirely disable DOM storage as a stopgap to ensure unlinkability. + + </p></li><li class="listitem">TLS session resumption and HTTP Keep-Alive + <p> +TLS session resumption and HTTP Keep-Alive must not allow third party origins +to track users via either TLS session IDs, or the fact that different requests +arrive on the same TCP connection. + </p><p><span class="command"><strong>Design Goal:</strong></span> + +TLS session resumption IDs must be limited to the top-level url bar domain. +HTTP Keep-Alive connections from a third party in one top-level domain must +not be reused for that same third party in another top-level domain. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +We <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/4099" target="_top">plan to +disable</a> TLS session resumption, and limit HTTP Keep-alive duration. + + </p></li><li class="listitem">window.name + <p> + +<a class="ulink" href="https://developer.mozilla.org/En/DOM/Window.name" target="_top">window.name</a> is +a magical DOM property that for some reason is allowed to retain a persistent value +for the lifespan of a browser tab. It is possible to utilize this property for +<a class="ulink" href="http://www.thomasfrank.se/sessionvars.html" target="_top">identifier +storage</a>. + + </p><p> + +In order to eliminate linkability but still allow for sites that utilize this +property to function, we reset the window.name property of tabs in Torbutton every +time we encounter a blank referer. This behavior allows window.name to persist +for the duration of a link-driven navigation session, but as soon as the user +enters a new URL or navigates between https/http schemes, the property is cleared. + + </p></li><li class="listitem">Exit node usage + <p><span class="command"><strong>Design Goal:</strong></span> + +Every distinct navigation session (as defined by a non-blank referer header) +MUST exit through a fresh Tor circuit in Tor Browser to prevent exit node +observers from linking concurrent browsing activity. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +The Tor feature that supports this ability only exists in the 0.2.3.x-alpha +series. <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3455" target="_top">Ticket +#3455</a> is the Torbutton ticket to make use of the new Tor +functionality. + + </p></li></ol></div></div><div class="sect2" title="3.6. Cross-Domain Fingerprinting Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>3.6. Cross-Domain Fingerprinting Unlinkability</h3></div></div></div><p> + +In order to properly address the fingerprinting adversary on a technical +level, we need a metric to measure linkability of the various browser +properties that extend beyond any stored origin-related state. <a class="ulink" href="https://panopticlick.eff.org/about.php" target="_top">The Panopticlick Project</a> +by the EFF provides us with exactly this metric. The researchers conducted a +survey of volunteers who were asked to visit an experiment page that harvested +many of the above components. They then computed the Shannon Entropy of the +resulting distribution of each of several key attributes to determine how many +bits of identifying information each attribute provided. + + </p><p> + +The study is not exhaustive, though. In particular, the test does not take in +all aspects of resolution information. It did not calculate the size of +widgets, window decoration, or toolbar size, which we believe may add high +amounts of entropy. It also did not measure clock offset and other time-based +fingerprints. Furthermore, as new browser features are added, this experiment +should be repeated to include them. + + </p><p> + +On the other hand, to avoid an infinite sinkhole, we reduce the efforts for +fingerprinting resistance by only concerning ourselves with reducing the +fingerprintable differences <span class="emphasis"><em>among</em></span> Tor Browser users. We +do not believe it is productive to concern ourselves with cross-browser +fingerprinting issues, at least not at this stage. + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Plugins + <p> + +Plugins add to fingerprinting risk via two main vectors: their mere presence in +window.navigator.plugins, as well as their internal functionality. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +All plugins that have not been specifically audited or sandboxed must be +disabled. To reduce linkability potential, even sandboxed plugins should not +be allowed to load objects until the user has clicked through a click-to-play +barrier. Additionally, version information should be reduced or obfuscated +until the plugin object is loaded. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +Currently, we entirely disable all plugins in Tor Browser. However, as a +compromise due to the popularity of Flash, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974" target="_top">work +towards</a> a +click-to-play barrier using NoScript that is available only after the user has +specifically enabled plugins. Flash will be the only plugin available, and we +will ship a settings.sol file to disable Flash cookies, and to restrict P2P +features that likely bypass proxy settings. + + </p></li><li class="listitem">Fonts + <p> + +According to the Panopticlick study, fonts provide the most linkability when +they are provided as an enumerable list in filesystem order, via either the +Flash or Java plugins. However, it is still possible to use CSS and/or +Javascript to query for the existence of specific fonts. With a large enough +pre-built list to query, a large amount of fingerprintable information may +still be available. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +To address the Javascript issue, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/2872" target="_top">limit the number of +fonts</a> an origin can load, gracefully degrading to built-in and/or +remote fonts once the limit is reached. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +Aside from disabling plugins to prevent enumeration, we have not yet +implemented any defense against CSS or Javascript fonts. + + </p></li><li class="listitem">User Agent and HTTP Headers + <p><span class="command"><strong>Design Goal:</strong></span> + +All Tor Browser users should provide websites with an identical user agent and +HTTP header set for a given request type. We omit the Firefox minor revision, +and report a popular Windows platform. If the software is kept up to date, +these headers should remain identical across the population even when updated. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +Firefox provides several options for controlling the browser user agent string +which we leverage. We also set similar prefs for controlling the +Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we +<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…" target="_top">remove +content script access</a> to Components.interfaces, which <a class="ulink" href="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html" target="_top">can be +used</a> to fingerprint OS, platform, and Firefox minor version. </p></li><li class="listitem">Desktop resolution and CSS Media Queries + <p> + +Both CSS and Javascript have a lot of irrelevant information about the screen +resolution, usable desktop size, OS widget size, toolbar size, title bar size, and +other desktop features that are not at all relevant to rendering and serve +only to provide information for fingerprinting. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +Our design goal here is to reduce the resolution information down to the bare +minimum required for properly rendering inside a content window. We intend to +report all rendering information correctly with respect to the size and +properties of the content window, but report an effective size of 0 for all +border material, and also report that the desktop is only as big as the +inner content window. Additionally, new browser windows are sized such that +their content windows are one of ~5 fixed sizes based on the user's +desktop resolution. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +We have implemented the above strategy for Javascript using Torbutton's <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/j…" target="_top">JavaScript +hooks</a> as well as a window observer to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/t…" target="_top">resize +new windows based on desktop resolution</a>. However, CSS Media Queries +still <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/2875" target="_top">need +to be dealt with</a>. + + </p></li><li class="listitem">Timezone and clock offset + <p><span class="command"><strong>Design Goal:</strong></span> + +All Tor Browser users should report the same timezone to websites. Currently, +we choose UTC for this purpose, although an equally valid argument could be +made for EDT/EST due to the large English-speaking population density. +Additionally, the Tor software should detect if the users clock is +significantly divergent from the clocks of the relays that it connects to, and +use this to reset the clock values used in Tor Browser to something reasonably +accurate. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +We set the timezone using the TZ environment variable, which is supported on +all platforms. Additionally, we plan to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3652" target="_top">obtain a clock +offset from Tor</a>, but this won't be available until Tor 0.2.3.x is in +use. + + </p></li><li class="listitem">Javascript performance fingerprinting + <p> + +<a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Javascript performance +fingerprinting</a> is the act of profiling the performance +of various Javascript functions for the purpose of fingerprinting the +Javascript engine and the CPU. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +We have <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3059" target="_top">several potential +mitigation approaches</a> to reduce the accuracy of performance +fingerprinting without risking too much damage to functionality. Our current +favorite is to reduce the resolution of the Event.timeStamp and the Javascript +Date() object, while also introducing jitter. Our goal is to increase the +amount of time it takes to mount a successful attack. <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Mowery et al</a> found that +even with the default precision in most browsers, they required up to 120 +seconds of amortization and repeated trials to get stable results from their +feature set. We intend to work with the research community to establish the +optimum tradeoff between quantization+jitter and amortization time. + + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +We have no implementation as of yet. + + </p></li><li class="listitem">Keystroke fingerprinting + <p> + +Keystroke fingerprinting is the act of measuring key strike time and key +flight time. It is seeing increasing use as a biometric. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +We intend to rely on the same mechanisms for defeating Javascript performance +fingerprinting: timestamp quantization and jitter. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> +We have no implementation as of yet. + </p></li><li class="listitem">WebGL + <p> + +WebGL is fingerprintable both through information that is exposed about the +underlying driver and optimizations, as well as through performance +fingerprinting. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +Because of the large amount of potential fingerprinting vectors, we intend to +deploy a similar strategy against WebGL as for plugins. First, WebGL canvases +will have click-to-play placeholders, and will not run until authorized by the +user. Second, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3323" target="_top">obfuscate driver +information</a> by hooking +<span class="command"><strong>getParameter()</strong></span>, +<span class="command"><strong>getSupportedExtensions()</strong></span>, +<span class="command"><strong>getExtension()</strong></span>, and +<span class="command"><strong>getContextAttributes()</strong></span> to provide standard minimal, +driver-neutral information. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +Currently we simply disable WebGL. + + </p></li></ol></div></div><div class="sect2" title="3.7. Long-Term Unlinkability via "New Identity" button"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>3.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p> +In order to avoid long-term linkability, we provide a "New Identity" context +menu option in Torbutton. + </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2894546"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + +All linkable identifiers and browser state should be cleared by this feature. + + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2904450"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + First, Torbutton disables +all open tabs and windows via nsIContentPolicy blocking, and then closes each +tab and window. The extra step for blocking tabs is done as a precaution to +ensure that any asynchronous Javascript is in fact properly disabled. After +closing all of the windows, we then clear the following state: OCSP (by +toggling security.OCSP.enabled), cache, site-specific zoom and content +preferences, Cookies, DOM storage, safe browsing key, the Google wifi +geolocation token (if exists), HTTP auth, SSL Session IDs, and the last opened URL +field (via the pref general.open_location.last_url). After clearing the +browser state, we then send the NEWNYM signal to the Tor control port to cause +a new circuit to be created. + </blockquote></div></div></div><div class="sect2" title="3.8. Click-to-play for plugins and invasive content"><div class="titlepage"><div><div><h3 class="title"><a id="click-to-play"></a>3.8. Click-to-play for plugins and invasive content</h3></div></div></div><p> +Some content types are too invasive and/or too opaque for us to properly +eliminate their linkability properties. For these content types, we use +NoScript to provide click-to-play placeholders that do not activate the +content until the user clicks on it. This will eliminate the ability for an +adversary to use such content types to link users in a dragnet fashion across +arbitrary sites. + </p><p> +Currently, the content types isolated in this way include Flash, WebGL, and +audio and video objects. + </p></div><div class="sect2" title="3.9. Description of Firefox Patches"><div class="titlepage"><div><div><h3 class="title"><a id="firefox-patches"></a>3.9. Description of Firefox Patches</h3></div></div></div><p> +The set of patches we have against Firefox can be found in the <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/tree/refs/heads/maint-2.2:/src…" target="_top">current-patches +directory of the torbrowser git repository</a>. They are: + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Block Components.interfaces and Components.lookupMethod + <p> + +In order to reduce fingerprinting, we block access to these two interfaces +from content script. Components.lookupMethod can undo our <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/j…" target="_top">Javascript +hooks</a>, +and Components.interfaces can be used for fingerprinting the platform, OS, and +Firebox version, but not much else. + + </p></li><li class="listitem">Make Permissions Manager memory only + <p> + +This patch exposes a pref 'permissions.memory_only' that properly isolates the +permissions manager to memory, which is responsible for all user specified +site permissions, as well as stored HTTPS STS policy from visited sites. + +The pref does successfully clear the permissions manager memory if toggled. It +does not need to be set in prefs.js, and can be handled by Torbutton. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +As an additional design goal, we would like to later alter this patch to allow this +information to be cleared from memory. The implementation does not currently +allow this. + + </p></li><li class="listitem">Make Intermediate Cert Store memory-only + <p> + +The intermediate certificate store holds information about SSL certificates +that may only be used by a limited number of domains. In some cases +effectively recording on disk the fact that a website owned by a certain +organization was viewed. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +As an additional design goal, we would like to later alter this patch to allow this +information to be cleared from memory. The implementation does not currently +allow this. + + </p></li><li class="listitem">Add HTTP auth headers before on-modify-request fires + <p> + +This patch provides a trivial modification to allow us to properly remove HTTP +auth for third parties. This patch allows us to defend against an adversary +attempting to use <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies…" target="_top">HTTP +auth to silently track users between domains</a>. + + </p></li><li class="listitem">Add a string-based cacheKey property for domain isolation + <p> + +To <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the +security of cache isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve strange and +unknown conflicts with OCSP</a>, we had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…" target="_top">patch +Firefox to provide a cacheDomain cache attribute</a>. We use the full +url bar domain as input to this field. + + </p></li><li class="listitem">Randomize HTTP pipeline order and depth + <p> +As an +<a class="ulink" href="https://blog.torproject.org/blog/experimental-defense-website-traffic-finge…" target="_top">experimental +defense against Website Traffic Fingerprinting</a>, we patch the standard +HTTP pipelining code to randomize the number of requests in a +pipeline, as well as their order. + </p></li><li class="listitem">Block all plugins except flash + <p> +We cannot use the <a class="ulink" href="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/c…" target="_top"> +(a)mozilla.org/extensions/blocklist;1</a> service, because we +actually want to stop plugins from ever entering the browser's process space +and/or executing code (for example, AV plugins that collect statistics/analyze +URLs, magical toolbars that phone home or "help" the user, skype buttons that +ruin our day, and censorship filters). Hence we rolled our own. + </p></li><li class="listitem">Make content-prefs service memory only + <p> +This patch prevents random URLs from being inserted into content-prefs.sqllite in +the profile directory as content prefs change (includes site-zoom and perhaps +other site prefs?). + </p></li></ol></div></div></div><div class="sect1" title="4. Packaging"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Packaging"></a>4. Packaging</h2></div></div></div><p> </p><div class="sect2" title="4.1. Build Process Security"><div class="titlepage"><div><div><h3 class="title"><a id="build-security"></a>4.1. Build Process Security</h3></div></div></div><p> </p></div><div class="sect2" title="4.2. External Addons"><div class="titlepage"><div><div><h3 class="title"><a id="addons"></a>4.2. External Addons</h3></div></div></div><p> </p><div class="sect3" title="Included Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2869647"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2906387"></a>Excluded Addons</h4></div></div></div></div><div class="sect3" title="Dangerous Addons"><div class="titlepage"><div><div><h4 cla ss="title"><a id="id2907827"></a>Dangerous Addons</h4></div></div></div></div></div><div class="sect2" title="4.3. Pref Changes"><div class="titlepage"><div><div><h3 class="title"><a id="prefs"></a>4.3. Pref Changes</h3></div></div></div><p> </p></div><div class="sect2" title="4.4. Update Security"><div class="titlepage"><div><div><h3 class="title"><a id="update-mechanism"></a>4.4. Update Security</h3></div></div></div><p> </p></div></div><div class="sect1" title="5. Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Testing"></a>5. Testing</h2></div></div></div><p> + +The purpose of this section is to cover all the known ways that Tor browser +security can be subverted from a penetration testing perspective. The hope +is that it will be useful both for creating a "Tor Safety Check" +page, and for developing novel tests and actively attacking Torbutton with the +goal of finding vulnerabilities in either it or the Mozilla components, +interfaces and settings upon which it relies. + + </p><div class="sect2" title="5.1. Single state testing"><div class="titlepage"><div><div><h3 class="title"><a id="SingleStateTesting"></a>5.1. Single state testing</h3></div></div></div><p> + +Torbutton is a complicated piece of software. During development, changes to +one component can affect a whole slough of unrelated features. A number of +aggregated test suites exist that can be used to test for regressions in +Torbutton and to help aid in the development of Torbutton-like addons and +other privacy modifications of other browsers. Some of these test suites exist +as a single automated page, while others are a series of pages you must visit +individually. They are provided here for reference and future regression +testing, and also in the hope that some brave soul will one day decide to +combine them into a comprehensive automated test suite. + + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://decloak.net/" target="_top">Decloak.net</a><p> + +Decloak.net is the canonical source of plugin and external-application based +proxy-bypass exploits. It is a fully automated test suite maintained by <a class="ulink" href="http://digitaloffense.net/" target="_top">HD Moore</a> as a service for people to +use to test their anonymity systems. + + </p></li><li class="listitem"><a class="ulink" href="http://deanonymizer.com/" target="_top">Deanonymizer.com</a><p> + +Deanonymizer.com is another automated test suite that tests for proxy bypass +and other information disclosure vulnerabilities. It is maintained by Kyle +Williams, the author of <a class="ulink" href="http://www.janusvm.com/" target="_top">JanusVM</a> +and <a class="ulink" href="http://www.januspa.com/" target="_top">JanusPA</a>. + + </p></li><li class="listitem"><a class="ulink" href="https://www.jondos.de/en/anontest" target="_top">JonDos +AnonTest</a><p> + +The <a class="ulink" href="https://www.jondos.de" target="_top">JonDos people</a> also provide an +anonymity tester. It is more focused on HTTP headers than plugin bypass, and +points out a couple of headers Torbutton could do a better job with +obfuscating. + + </p></li><li class="listitem"><a class="ulink" href="http://browserspy.dk" target="_top">Browserspy.dk</a><p> + +Browserspy.dk provides a tremendous collection of browser fingerprinting and +general privacy tests. Unfortunately they are only available one page at a +time, and there is not really solid feedback on good vs bad behavior in +the test results. + + </p></li><li class="listitem"><a class="ulink" href="http://analyze.privacy.net/" target="_top">Privacy +Analyzer</a><p> + +The Privacy Analyzer provides a dump of all sorts of browser attributes and +settings that it detects, including some information on your origin IP +address. Its page layout and lack of good vs bad test result feedback makes it +not as useful as a user-facing testing tool, but it does provide some +interesting checks in a single page. + + </p></li><li class="listitem"><a class="ulink" href="http://ha.ckers.org/mr-t/" target="_top">Mr. T</a><p> + +Mr. T is a collection of browser fingerprinting and deanonymization exploits +discovered by the <a class="ulink" href="http://ha.ckers.org" target="_top">ha.ckers.org</a> crew +and others. It is also not as user friendly as some of the above tests, but it +is a useful collection. + + </p></li><li class="listitem">Gregory Fleischer's <a class="ulink" href="http://pseudo-flaw.net/content/tor/torbutton/" target="_top">Torbutton</a> and +<a class="ulink" href="http://pseudo-flaw.net/content/defcon/dc-17-demos/d.html" target="_top">Defcon +17</a> Test Cases + <p> + +Gregory Fleischer has been hacking and testing Firefox and Torbutton privacy +issues for the past 2 years. He has an excellent collection of all his test +cases that can be used for regression testing. In his Defcon work, he +demonstrates ways to infer Firefox version based on arcane browser properties. +We are still trying to determine the best way to address some of those test +cases. + + </p></li><li class="listitem"><a class="ulink" href="https://torcheck.xenobite.eu/index.php" target="_top">Xenobite's +TorCheck Page</a><p> + +This page checks to ensure you are using a valid Tor exit node and checks for +some basic browser properties related to privacy. It is not very fine-grained +or complete, but it is automated and could be turned into something useful +with a bit of work. + + </p></li></ol></div><p> + </p></div></div></div></body></html>

1 0

[torbrowser/maint-2.2] a wild firefox 7.0.1 appears to prove that there is no god
by erinn＠torproject.org 30 Sep '11

30 Sep '11

commit bbef1f7a356da590a2cae5d6d389b9ba44740f99 Author: Erinn Clark <erinn(a)torproject.org> Date: Fri Sep 30 03:07:47 2011 +0100 a wild firefox 7.0.1 appears to prove that there is no god --- build-scripts/versions.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/build-scripts/versions.mk b/build-scripts/versions.mk index af6335e..8856a87 100644 --- a/build-scripts/versions.mk +++ b/build-scripts/versions.mk @@ -3,7 +3,7 @@ RELEASE_VER=2.2.33 HTTPSEVERY_VER=1.0.3 -FIREFOX_VER=7.0 +FIREFOX_VER=7.0.1 LIBEVENT_VER=2.0.14-stable LIBPNG_VER=1.4.8 NOSCRIPT_VER=2.1.2.8

1 0

[torbrowser/maint-2.2] give windows makefile the ability to use both normal wget and the python wget steven made
by erinn＠torproject.org 30 Sep '11

30 Sep '11

commit ff24c49c8444afcb0d8606c7997daa8cfef56fb5 Author: Erinn Clark <erinn(a)torproject.org> Date: Fri Sep 30 03:04:12 2011 +0100 give windows makefile the ability to use both normal wget and the python wget steven made --- build-scripts/windows.mk | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/build-scripts/windows.mk b/build-scripts/windows.mk index d62aeff..9d721db 100644 --- a/build-scripts/windows.mk +++ b/build-scripts/windows.mk @@ -50,7 +50,8 @@ PIDGIN=$(FETCH_DIR)/PidginPortable-$(PIDGIN_VER) PWD:=$(shell pwd) PYTHON=/c/Python26/python.exe SEVENZIP="/c/Program Files/7-Zip/7z.exe" -WGET=$(PYTHON) $(PWD)/pyget.py +PYGET=$(PYTHON) $(PWD)/pyget.py +WGET=wget VIRUSSCAN=$(PYTHON) $(PWD)/virus-scan.py WINRAR="/c/Program Files/WinRAR/WinRAR.exe" CC=gcc @@ -346,7 +347,7 @@ launcher: ## Torbutton development version torbutton.xpi: - $(WGET) -O $@ $(TORBUTTON) + $(PYGET) -O $@ $(TORBUTTON) ## English comes as default langpack_en-US.xpi: @@ -354,19 +355,19 @@ langpack_en-US.xpi: ## BetterPrivacy betterprivacy.xpi: - $(WGET) -O $@ $(BETTERPRIVACY) + $(PYGET) -O $@ $(BETTERPRIVACY) ## NoScript development version noscript.xpi: - $(WGET) -O $@ $(NOSCRIPT) + $(PYGET) -O $@ $(NOSCRIPT) ## HTTPS Everywhere httpseverywhere.xpi: - $(WGET) -O $@ $(HTTPSEVERYWHERE) + $(PYGET) -O $@ $(HTTPSEVERYWHERE) ## Generic language pack rule langpack_%.xpi: - $(WGET) -O $@ $(MOZILLA_LANGUAGE)/$*.xpi + $(PYGET) -O $@ $(MOZILLA_LANGUAGE)/$*.xpi ## ## Customize the bundle

1 0

[torbrowser/maint-2.2] update name of windows changelog in windows makefile
by erinn＠torproject.org 30 Sep '11

30 Sep '11

commit 797fe84498de96470e2bdeee8996c6026240ff53 Author: Erinn Clark <erinn(a)torproject.org> Date: Fri Sep 30 03:04:38 2011 +0100 update name of windows changelog in windows makefile --- build-scripts/windows.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/build-scripts/windows.mk b/build-scripts/windows.mk index 9d721db..739317f 100644 --- a/build-scripts/windows.mk +++ b/build-scripts/windows.mk @@ -291,7 +291,7 @@ install-docs: cp $(TOR)/LICENSE $(TOR)/README $(DOCSDIR)/Tor cp $(QT_LIB)/../LICENSE.GPL* $(QT_LIB)/../LICENSE.LGPL $(DOCSDIR)/Qt cp $(MING)/../msys/1.0/share/doc/MSYS/COPYING $(DOCSDIR)/MinGW - cp ../changelog.win-2.2 $(DOCSDIR)/changelog + cp ../changelog.windows-2.2 $(DOCSDIR)/changelog cp ../README.WIN-2.2 $(DOCSDIR)/README-TorBrowserBundle ## Copy over FirefoxPortable

1 0

r25140: {} add today's presentation (projects/presentations)
by Andrew Lewman 29 Sep '11

29 Sep '11

Author: phobos Date: 2011-09-29 16:14:46 +0000 (Thu, 29 Sep 2011) New Revision: 25140 Added: projects/presentations/2011-09-29-FCADV-data-security.pdf projects/presentations/2011-09-29-FCADV-data-security.tex Log: add today's presentation Added: projects/presentations/2011-09-29-FCADV-data-security.pdf =================================================================== (Binary files differ) Property changes on: projects/presentations/2011-09-29-FCADV-data-security.pdf ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: projects/presentations/2011-09-29-FCADV-data-security.tex =================================================================== --- projects/presentations/2011-09-29-FCADV-data-security.tex (rev 0) +++ projects/presentations/2011-09-29-FCADV-data-security.tex 2011-09-29 16:14:46 UTC (rev 25140) @@ -0,0 +1,130 @@ +\documentclass{beamer} +\mode<presentation> +\usetheme{Boadilla} +\title{FCADV Data Security} +\author{Andrew Lewman \\ andrew(a)torproject.org} +\date{September 29, 2011} +\begin{document} + +\begin{frame} +\maketitle +\begin{center} +\includegraphics[height=3cm]{./images/2009-tor-logo} +\end{center} +\end{frame} + +\begin{frame} +\frametitle{What are we talking about?} +\begin{itemize} +\item Quick overview of data security and privacy +\item Securing data independent of location +\item Shelters, survivors, and Internets +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{} +\begin{quotation} +\noindent \includegraphics[width=1cm]{./images/opquo}\quad +Knowledge is power... Knowledge is happiness. +\end{quotation} +\bigskip +\textbf{Thomas Jefferson, 1817} +\end{frame} + +\begin{frame} +\frametitle{The Tor Project, Inc.} +501(c)(3) non-profit organization dedicated to the research and development of technologies for online anonymity and privacy +\begin{center} +\includegraphics[height=5cm]{./images/2009-oval_sticker_new} +\end{center} +\end{frame} + +\begin{frame} +\frametitle{Crashing into data security and privacy} +\begin{itemize} +\item Encryption +\pause \item Access controls +\pause \item Backups +\pause \item Masking +\pause \item Erasure +\pause \item ISO/IEC 27002 Standard +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Crashing into data security} +Follow the data itself. Ignore the technology used to touch it. +\end{frame} + +\begin{frame} +\frametitle{The life of a case file} +\begin{itemize} +\item Data is collected. +\item Data entered into ALICE. +\item Then what? +\pause \item who gets access to it? +\pause \item how is it transmitted to the next stop? +\pause \item where is it living? +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Forget Alice, think about the data} +\begin{itemize} +\item zip code, sex, date of birth are all that's needed to deanonymize someone +\item ALICE computers should be separate from any other networks, such as survivor networks in a shelter, or reachable from outside the shelter. +\item firewalls are just locks on a door, they stop honest people from going further. +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Securing data} +\begin{itemize} +\item disaster recovery, or where do I send a safe full of valuables? +\pause \item encryption? It should solve all my problems, right? +\pause \item how did you encrypt the case file? all as one big file, or individually? +\pause \item subpoena can force decryption +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Internet access in the shelter} +\begin{itemize} +\item survivors will find a way to connect to the 'net +\item may circumvent your controls to their own detriment +\item IP address gives them away +\item shared computer, cookies (browser, flash, dom, html5) +\item wifi access means everyone can get on it +\item private browsing mode is hardly private +\item use read-only operating systems, livecd/liveusb so no one can save + anything locally. Tor makes one of these, btw. +\item virtual machines +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{OMG nevar goin' on dar Internets again!} +\begin{itemize} +\item Risk assessment +\pause \item minimization of harm +\pause \item containment +\pause \item work with your vendors +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Questions?} +\begin{center} +\includegraphics[scale=1.0]{images/question-mark} +\end{center} +\end{frame} + +\begin{frame} +\frametitle{Copyrights} +\begin{itemize} +\item question mark, http://how-to-do-it.net/ +\end{itemize} +\end{frame} + +\end{document} \ No newline at end of file Property changes on: projects/presentations/2011-09-29-FCADV-data-security.tex ___________________________________________________________________ Added: svn:mime-type + text/x-tex

1 0

[arm/packaging] Dropping cagraph from arm exports
by atagar＠torproject.org 29 Sep '11

29 Sep '11

commit 6bf70593d32977b78789f509107509be717d889b Author: Damian Johnson <atagar(a)torproject.org> Date: Thu Sep 29 08:54:08 2011 -0700 Dropping cagraph from arm exports Removing cagraph from the package exports. This can be fetched dynamically if the user wants to try the gui prototype, the only gotcha being a likely permission issue during the fetch (I should clarify that message...). --- export.sh | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/export.sh b/export.sh index ffa886a..ef33bd7 100755 --- a/export.sh +++ b/export.sh @@ -26,11 +26,11 @@ echo "5460adb1394c368ba492cc33d6681618b3d3062b3f5f70b2a87520fc291701c3 <- expect tar -C $exportDst/src -xzf torctl.tar.gz rm torctl.tar.gz -wget --quiet http://www.atagar.com/arm/resources/deps/11-06-10/cagraph.tar.gz -sha256sum cagraph.tar.gz -echo "1439acd40ce016f4329deb216d86f36a749e4b8bf73a313a757396af6f95310d <- expected" -tar -C $exportDst/src -xzf cagraph.tar.gz -rm cagraph.tar.gz +#wget --quiet http://www.atagar.com/arm/resources/deps/11-06-10/cagraph.tar.gz +#sha256sum cagraph.tar.gz +#echo "1439acd40ce016f4329deb216d86f36a749e4b8bf73a313a757396af6f95310d <- expected" +#tar -C $exportDst/src -xzf cagraph.tar.gz +#rm cagraph.tar.gz # the following installed torctl from its master repo rather than our # dependency mirror

1 0