tor-commits November 2014

tor-commits@lists.torproject.org

24 participants
954 discussions

[webwml/master] More fingerprinting clarifications.
by mikeperry＠torproject.org 07 Nov '14

07 Nov '14

commit 8cf46843a14d29175e2b2e0cf599447c1396d8ba Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Thu Nov 6 17:33:32 2014 -0800 More fingerprinting clarifications. --- projects/torbrowser/design/index.html.en | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/projects/torbrowser/design/index.html.en b/projects/torbrowser/design/index.html.en index 8624b4a..1bd9530 100644 --- a/projects/torbrowser/design/index.html.en +++ b/projects/torbrowser/design/index.html.en @@ -1,5 +1,5 @@ <?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.78.1" /></head><body><div class="article"><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="a ffiliation"><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">November 6th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp65114112">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Secu rity Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isol ation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp67866160">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp67901104">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp67905040">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Tran sparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp67937488">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp65114112"></a>1. Introduction</h2></div></div></div><p> +<!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.78.1" /></head><body><div class="article"><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="a ffiliation"><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">November 6th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp59720528">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Secu rity Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isol ation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp60597904">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp60632800">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp60636736">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Tran sparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp60669376">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp59720528"></a>1. Introduction</h2></div></div></div><p> This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>, <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, and <a class="link" href="#Implementation" title="4. Implementation">implementation</a> of the Tor Browser. It is current as of Tor Browser @@ -654,13 +654,13 @@ system-wide extensions (through the use of disabled, which prevents Flash cookies from leaking from a pre-existing Flash directory. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp67642512"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60374176"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> The User Agent MUST (at user option) prevent all disk records of browser activity. The user should be able to optionally enable URL history and other history features if they so desire. - </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp67643872"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60375536"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> We achieve this goal through several mechanisms. First, we set the Firefox Private Browsing preference @@ -734,7 +734,7 @@ the url bar origin for which browser state exists, possibly with a context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1. - </p><div class="figure"><a id="idp67666576"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + </p><div class="figure"><a id="idp60398240"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> This example UI is a mock-up of how isolating identifiers to the URL bar origin can simplify the privacy UI for all data - not just cookies. Once @@ -1140,7 +1140,7 @@ To improve rendering, we exempt remote <a class="ulink" href="https://developer. fonts</a> from these counts, and if a font-family CSS rule lists a remote font (in any order), we use that font instead of any of the named local fonts. - </p></li><li class="listitem">Monitor and OS Desktop Resolution + </p></li><li class="listitem">Monitor, Widget, and OS Desktop Resolution <p> Both CSS and Javascript have access to a lot of information about the screen @@ -1189,8 +1189,8 @@ to privacy in this mode. Beyond simple resolution information, a large amount of so-called "Media" information is also exported to content. Even without Javascript, CSS has access to a lot of information about the device orientation, system theme -colors, and other desktop features that are not at all relevant to rendering -and also user configurable. Most of this +colors, and other desktop and display features that are not at all relevant to +rendering and also user configurable. Most of this information comes from <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries" target="_top">CSS Media Queries</a>, but Mozilla has exposed <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#System_Colors" target="_top">several user and OS theme defined color values</a> to CSS as well. @@ -1377,11 +1377,11 @@ In order to avoid long-term linkability, we provide a "New Identity" context menu option in Torbutton. This context menu option is active if Torbutton can read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT. - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp67813456"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60545136"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> All linkable identifiers and browser state MUST be cleared by this feature. - </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp67814704"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60546384"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> First, Torbutton disables Javascript in all open tabs and windows by using both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocSh…" target="_top">browser.docShell.allowJavascript</a> @@ -1461,7 +1461,7 @@ all non-WebM HTML5 codecs (<span class="command"><strong>media.ogg.enabled</stro Fingerprinting</a> is a statistical attack to attempt to recognize specific encrypted website activity. - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp67843072"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60574784"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> We want to deploy a mechanism that reduces the accuracy of <a class="ulink" href="https://en.wikipedia.org/wiki/Feature_selection" target="_top">useful features</a> available for classification. This mechanism would either impact the true and false @@ -1483,7 +1483,7 @@ Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor network, making them also effectively no-overhead. - </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp67849968"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60581680"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/27ef32d509ed1c9eeb…" target="_top">randomize pipeline order and depth</a>. Unfortunately, pipelining is very fragile. Many sites do not support it, and even sites that advertise support for @@ -1548,7 +1548,7 @@ contend with. For this reason, we have deployed a build system that allows anyone to use our source code to reproduce byte-for-byte identical binary packages to the ones that we distribute. - </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp67866160"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p> + </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60597904"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p> The GNU toolchain has been working on providing reproducible builds for some time, however a large software project such as Firefox typically ends up @@ -1665,7 +1665,7 @@ unitialized memory</a> that only appear in LXC mode, as well as <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/12240" target="_top">oddities related to time-based dependency tracking</a> that only appear in LXC containers. - </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp67901104"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> + </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60632800"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> The build process produces a single sha256sums.txt file that contains a sorted list of the SHA-256 hashes of every package produced for that build version. Each @@ -1699,7 +1699,7 @@ and by their nature are based on non-public key material, providing native code-signed packages while still preserving ease of reproducibility verification has not yet been achieved. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp67905040"></a>5.3. Anonymous Verification</h3></div></div></div><p> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60636736"></a>5.3. Anonymous Verification</h3></div></div></div><p> Due to the fact that bit-identical packages can be produced by anyone, the security of this build system extends beyond the security of the official @@ -1815,7 +1815,7 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t ourselves</a>, as they are comparatively rare and can be handled with site permissions. - </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp67937488"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> + </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp60669376"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> Web-Send is a browser-based link sharing and federated login widget that is designed to operate without relying on third-party tracking or abusing other

1 0

[tor-browser-spec/master] More fingerprinting clarifications
by mikeperry＠torproject.org 07 Nov '14

07 Nov '14

commit b9d29e071bd4ad3ef7ba8ce41b031e8798f79ac4 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Thu Nov 6 17:33:18 2014 -0800 More fingerprinting clarifications --- design-doc/design.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/design-doc/design.xml b/design-doc/design.xml index a303cc8..16007f3 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -1664,7 +1664,7 @@ font (in any order), we use that font instead of any of the named local fonts. </para> </listitem> - <listitem>Monitor and OS Desktop Resolution + <listitem>Monitor, Widget, and OS Desktop Resolution <para> Both CSS and Javascript have access to a lot of information about the screen @@ -1721,8 +1721,8 @@ to privacy in this mode. Beyond simple resolution information, a large amount of so-called "Media" information is also exported to content. Even without Javascript, CSS has access to a lot of information about the device orientation, system theme -colors, and other desktop features that are not at all relevant to rendering -and also user configurable. Most of this +colors, and other desktop and display features that are not at all relevant to +rendering and also user configurable. Most of this information comes from <ulink url="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries">CSS Media Queries</ulink>, but Mozilla has exposed <ulink

1 0

[webwml/master] Another fix to the design doc.
by mikeperry＠torproject.org 07 Nov '14

07 Nov '14

commit d1911650df97adf5c8c34de3f164adde3ec9086c Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Thu Nov 6 17:16:21 2014 -0800 Another fix to the design doc. --- projects/torbrowser/design/index.html.en | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/projects/torbrowser/design/index.html.en b/projects/torbrowser/design/index.html.en index b4e285c..8624b4a 100644 --- a/projects/torbrowser/design/index.html.en +++ b/projects/torbrowser/design/index.html.en @@ -1,5 +1,5 @@ <?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.78.1" /></head><body><div class="article"><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="a ffiliation"><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">November 6th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp42746080">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Secu rity Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isol ation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp45273472">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp45308512">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp45312448">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Tran sparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp45344896">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp42746080"></a>1. Introduction</h2></div></div></div><p> +<!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.78.1" /></head><body><div class="article"><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="a ffiliation"><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">November 6th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp65114112">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Secu rity Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isol ation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp67866160">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp67901104">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp67905040">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Tran sparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp67937488">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp65114112"></a>1. Introduction</h2></div></div></div><p> This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>, <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, and <a class="link" href="#Implementation" title="4. Implementation">implementation</a> of the Tor Browser. It is current as of Tor Browser @@ -654,13 +654,13 @@ system-wide extensions (through the use of disabled, which prevents Flash cookies from leaking from a pre-existing Flash directory. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45049760"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp67642512"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> The User Agent MUST (at user option) prevent all disk records of browser activity. The user should be able to optionally enable URL history and other history features if they so desire. - </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45051120"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp67643872"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> We achieve this goal through several mechanisms. First, we set the Firefox Private Browsing preference @@ -734,7 +734,7 @@ the url bar origin for which browser state exists, possibly with a context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1. - </p><div class="figure"><a id="idp45073824"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + </p><div class="figure"><a id="idp67666576"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> This example UI is a mock-up of how isolating identifiers to the URL bar origin can simplify the privacy UI for all data - not just cookies. Once @@ -982,7 +982,7 @@ operating system type and even processor speed. </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-defenses"></a>Fingerprinting defenses in the Tor Browser</h4></div></div></div><p> The following defenses are listed roughly in order of most severe -fingerprinting threat first. This ordering based on the above intuition that +fingerprinting threat first. This ordering is based on the above intuition that user configurable aspects of the computer are the most severe source of fingerprintability, though we are in need of updated measurements to determine this with certainty. @@ -1377,11 +1377,11 @@ In order to avoid long-term linkability, we provide a "New Identity" context menu option in Torbutton. This context menu option is active if Torbutton can read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT. - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45220704"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp67813456"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> All linkable identifiers and browser state MUST be cleared by this feature. - </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45221952"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp67814704"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> First, Torbutton disables Javascript in all open tabs and windows by using both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocSh…" target="_top">browser.docShell.allowJavascript</a> @@ -1461,7 +1461,7 @@ all non-WebM HTML5 codecs (<span class="command"><strong>media.ogg.enabled</stro Fingerprinting</a> is a statistical attack to attempt to recognize specific encrypted website activity. - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45250352"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp67843072"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> We want to deploy a mechanism that reduces the accuracy of <a class="ulink" href="https://en.wikipedia.org/wiki/Feature_selection" target="_top">useful features</a> available for classification. This mechanism would either impact the true and false @@ -1483,7 +1483,7 @@ Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor network, making them also effectively no-overhead. - </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45257248"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp67849968"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/27ef32d509ed1c9eeb…" target="_top">randomize pipeline order and depth</a>. Unfortunately, pipelining is very fragile. Many sites do not support it, and even sites that advertise support for @@ -1548,7 +1548,7 @@ contend with. For this reason, we have deployed a build system that allows anyone to use our source code to reproduce byte-for-byte identical binary packages to the ones that we distribute. - </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp45273472"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p> + </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp67866160"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p> The GNU toolchain has been working on providing reproducible builds for some time, however a large software project such as Firefox typically ends up @@ -1665,7 +1665,7 @@ unitialized memory</a> that only appear in LXC mode, as well as <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/12240" target="_top">oddities related to time-based dependency tracking</a> that only appear in LXC containers. - </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp45308512"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> + </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp67901104"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> The build process produces a single sha256sums.txt file that contains a sorted list of the SHA-256 hashes of every package produced for that build version. Each @@ -1699,7 +1699,7 @@ and by their nature are based on non-public key material, providing native code-signed packages while still preserving ease of reproducibility verification has not yet been achieved. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp45312448"></a>5.3. Anonymous Verification</h3></div></div></div><p> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp67905040"></a>5.3. Anonymous Verification</h3></div></div></div><p> Due to the fact that bit-identical packages can be produced by anyone, the security of this build system extends beyond the security of the official @@ -1815,7 +1815,7 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t ourselves</a>, as they are comparatively rare and can be handled with site permissions. - </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp45344896"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> + </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp67937488"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> Web-Send is a browser-based link sharing and federated login widget that is designed to operate without relying on third-party tracking or abusing other

1 0

[tor-browser-spec/master] Minor fix.
by mikeperry＠torproject.org 07 Nov '14

07 Nov '14

commit 6057abbc418b7a640b6fc88d3e2d07bcbbe8a6f1 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Thu Nov 6 17:14:58 2014 -0800 Minor fix. --- design-doc/design.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/design-doc/design.xml b/design-doc/design.xml index 5e7aaa3..a303cc8 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -1468,7 +1468,7 @@ operating system type and even processor speed. <para> The following defenses are listed roughly in order of most severe -fingerprinting threat first. This ordering based on the above intuition that +fingerprinting threat first. This ordering is based on the above intuition that user configurable aspects of the computer are the most severe source of fingerprintability, though we are in need of updated measurements to determine this with certainty.

1 0

[webwml/master] Updates to fingerprinting section of TBB design doc.
by mikeperry＠torproject.org 07 Nov '14

07 Nov '14

commit df98bb5b6f4c62dc67c75bad82d91ac31f0bb4ca Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Thu Nov 6 17:14:06 2014 -0800 Updates to fingerprinting section of TBB design doc. --- projects/torbrowser/design/index.html.en | 244 ++++++++++++++++-------------- 1 file changed, 134 insertions(+), 110 deletions(-) diff --git a/projects/torbrowser/design/index.html.en b/projects/torbrowser/design/index.html.en index abeace5..b4e285c 100644 --- a/projects/torbrowser/design/index.html.en +++ b/projects/torbrowser/design/index.html.en @@ -1,5 +1,5 @@ <?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.78.1" /></head><body><div class="article"><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="a ffiliation"><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">November 6th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp59241696">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Secu rity Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isol ation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp60746000">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp60781056">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp60784992">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Tran sparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp60816992">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp59241696"></a>1. Introduction</h2></div></div></div><p> +<!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.78.1" /></head><body><div class="article"><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="a ffiliation"><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">November 6th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp42746080">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Secu rity Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isol ation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp45273472">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp45308512">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp45312448">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Tran sparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp45344896">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp42746080"></a>1. Introduction</h2></div></div></div><p> This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>, <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, and <a class="link" href="#Implementation" title="4. Implementation">implementation</a> of the Tor Browser. It is current as of Tor Browser @@ -654,13 +654,13 @@ system-wide extensions (through the use of disabled, which prevents Flash cookies from leaking from a pre-existing Flash directory. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60523824"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45049760"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> The User Agent MUST (at user option) prevent all disk records of browser activity. The user should be able to optionally enable URL history and other history features if they so desire. - </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60525184"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45051120"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> We achieve this goal through several mechanisms. First, we set the Firefox Private Browsing preference @@ -734,7 +734,7 @@ the url bar origin for which browser state exists, possibly with a context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1. - </p><div class="figure"><a id="idp60547888"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + </p><div class="figure"><a id="idp45073824"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> This example UI is a mock-up of how isolating identifiers to the URL bar origin can simplify the privacy UI for all data - not just cookies. Once @@ -954,39 +954,50 @@ determine how many bits of identifying information each attribute provided. </p><p> -Because fingerprinting is a problem that potentially touches every aspect of -the browser, 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 possible -to solve cross-browser fingerprinting issues. +Unfortunately, there are limitations to the way the Panopticlick study was +conducted. Because the Panopticlick dataset is based on browser data spanning +a number of widely deployed browsers over a number of years, any +fingerprinting defenses attempted by browsers today are very likely to cause +Panopticlick to report an <span class="emphasis"><em>increase</em></span> in fingerprintability +and entropy, because those defenses will stand out in sharp contrast to +historical data. Moreover, because fingerprinting is a problem that +potentially touches every aspect of the browser, we do not believe it is +possible to solve cross-browser fingerprinting issues. 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. </p><p> -Unfortunately, the unsolvable nature of the cross-browser fingerprinting -problem means that the Panopticlick test website itself is not useful for -evaluating the actual effectiveness of our defenses, or the fingerprinting -defenses of any other web browser. Because the Panopticlick dataset is based -on browser data spanning a number of widely deployed browsers over a number of -years, any fingerprinting defenses attempted by browsers today are very likely -to cause Panopticlick to report an <span class="emphasis"><em>increase</em></span> in -fingerprintability and entropy, because those defenses will stand out in sharp -contrast to historical data. We have been <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/6119" target="_top">working to convince -the EFF</a> that it is worthwhile to release the source code to -Panopticlick to allow us to run our own version for this reason. +The unsolvable nature of the cross-browser fingerprinting problem also means +that the Panopticlick test website itself is not useful for evaluating the +actual effectiveness of our defenses, or the fingerprinting defenses of any +other web browser. We are interested in deploying an improved version of +Panopticlick that measures entropy and variance only among a specific user +agent population, but until then, intuition serves as a decent guide. +Essentially, anything that reveals custom user configuration, third party +software, highly variable hardware details, and external devices attached to +the users computer is likely to more fingerprintable than things like +operating system type and even processor speed. </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-defenses"></a>Fingerprinting defenses in the Tor Browser</h4></div></div></div><p> The following defenses are listed roughly in order of most severe -fingerprinting threat first, though we are desperately in need of updated -measurements to determine this with certainty. Where our actual implementation -differs from an ideal solution, we separately describe our <span class="command"><strong>Design -Goal</strong></span> and our <span class="command"><strong>Implementation Status</strong></span>. +fingerprinting threat first. This ordering based on the above intuition that +user configurable aspects of the computer are the most severe source of +fingerprintability, though we are in need of updated measurements to determine +this with certainty. + + </p><p> +Where our actual implementation differs from +an ideal solution, we separately describe our <span class="command"><strong>Design Goal</strong></span> +and our <span class="command"><strong>Implementation Status</strong></span>. </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. +Plugins add to fingerprinting risk via two main vectors: their mere presence +in window.navigator.plugins (because they are optional, end-user installed +third party software), as well as their internal functionality. </p><p><span class="command"><strong>Design Goal:</strong></span> @@ -1014,11 +1025,9 @@ leaking plugin installation information. </p></li><li class="listitem">HTML5 Canvas Image Extraction <p> -The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Canvas" target="_top">HTML5 -Canvas</a> is a feature that has been added to major browsers after the -EFF developed their Panopticlick study. After plugins and plugin-provided -information, we believe that the HTML5 Canvas is the single largest -fingerprinting threat browsers face today. <a class="ulink" href="http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf" target="_top">Initial +After plugins and plugin-provided information, we believe that the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Canvas" target="_top">HTML5 +Canvas</a> is the single largest fingerprinting threat browsers face +today. <a class="ulink" href="http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf" target="_top">Initial studies</a> show that the Canvas can provide an easy-access fingerprinting target: The adversary simply renders WebGL, font, and named color data to a Canvas element, extracts the image buffer, and computes a hash of that image @@ -1030,8 +1039,9 @@ image can be used almost identically to a tracking cookie by the web server. </p><p> In some sense, the canvas can be seen as the union of many other -fingerprinting vectors. If WebGL were normalized through software rendering, -and the browser shipped a fixed collection of fonts, it might not be necessary +fingerprinting vectors. If WebGL is normalized through software rendering, +system colors were standardized, and the browser shipped a fixed collection of +fonts (see later points in this list), it might not be necessary to create a canvas permission. However, until then, to reduce the threat from this vector, we have patched Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/3b53f525cfb68880e6…" target="_top">prompt before returning valid image data</a> to the Canvas APIs, and for <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/fb9f463fe3a69499d6…" target="_top">access @@ -1047,7 +1057,13 @@ In Firefox, by using either WebSockets or XHR, it is possible for remote content to <a class="ulink" href="http://www.andlabs.org/tools/jsrecon.html" target="_top">enumerate the list of TCP ports open on 127.0.0.1</a>. In other browsers, this can be accomplished by DOM events on image or script tags. This open vs filtered -vs closed port list can provide a very unique fingerprint of a machine. +vs closed port list can provide a very unique fingerprint of a machine, +because it essentially enables the detection of many different popular third +party applications and optional system services (Skype, Bitcoin, Bittorrent +and other P2P software, SSH ports, SMB and related LAN services, CUPS and +printer daemon config ports, mail servers, and so on). It is also possible to +determine when ports are closed versus filtered/blocked (and thus probe +custom firewall configuration). </p><p>In Tor Browser, we prevent access to 127.0.0.1/localhost by ensuring that even these requests are still sent by @@ -1055,7 +1071,19 @@ Firefox to our SOCKS proxy (ie we set <span class="command"><strong>network.proxy.no_proxies_on</strong></span> to the empty string). The local Tor client then rejects them, since it is configured to proxy for internal IP addresses by default. - </p></li><li class="listitem">USB Device ID enumeration + </p></li><li class="listitem">Invasive Authentication Mechanisms (NTLM and SPNEGO) + <p> + +Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in +some cases the current username. The only reason why these aren't a more +serious problem is that they typically involve user interaction, and likely +aren't an attractive vector for this reason. However, because it is not clear +if certain carefully-crafted error conditions in these protocols could cause +them to reveal machine information and still fail silently prior to the +password prompt, these authentication mechanisms should either be disabled, or +placed behind a site permission before their use. We simply disable them. + + </p></li><li class="listitem">USB Device ID Enumeration <p> The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/API/Gamepad" target="_top">GamePad @@ -1066,38 +1094,6 @@ should be behind a site permission in Private Browsing Modes, or should present controller type (perhaps a two button controller that can be mapped to the keyboard) in all cases. We simply disable it via the pref <span class="command"><strong>dom.gamepad.enabled</strong></span>. - </p></li><li class="listitem">Invasive Authentication Mechanisms (NTLM and SPNEGO) - <p> -Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in -some cases the machine username. These authentication mechanisms should either -be disabled, or placed behind a site permission before their use. We simply -disable them. - </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> - -Because of the large amount of potential fingerprinting vectors and the <a class="ulink" href="http://www.contextis.com/resources/blog/webgl/" target="_top">previously unexposed -vulnerability surface</a>, we deploy a similar strategy against WebGL as -for plugins. First, WebGL Canvases have click-to-play placeholders (provided -by NoScript), and do not run until authorized by the user. Second, we -obfuscate driver information by setting the Firefox preferences -<span class="command"><strong>webgl.disable-extensions</strong></span> and -<span class="command"><strong>webgl.min_capability_mode</strong></span>, which reduce the information -provided by the following WebGL API calls: <span class="command"><strong>getParameter()</strong></span>, -<span class="command"><strong>getSupportedExtensions()</strong></span>, and -<span class="command"><strong>getExtension()</strong></span>. - - </p><p> - -Another option for WebGL might be to use software-only rendering, using a -library such as <a class="ulink" href="http://www.mesa3d.org/" target="_top">Mesa</a>. The use of -such a library would avoid hardware-specific rendering differences. - </p></li><li class="listitem">Fonts <p> @@ -1106,7 +1102,8 @@ 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. +still be available, especially given that additional fonts often end up +installed by third party software and for multilingual support. </p><p><span class="command"><strong>Design Goal:</strong></span> The sure-fire way to address font linkability is to ship the browser with a font for every language, typeface, @@ -1143,13 +1140,16 @@ To improve rendering, we exempt remote <a class="ulink" href="https://developer. fonts</a> from these counts, and if a font-family CSS rule lists a remote font (in any order), we use that font instead of any of the named local fonts. - </p></li><li class="listitem">Monitor and OS Desktop resolution + </p></li><li class="listitem">Monitor and OS Desktop Resolution <p> Both CSS and Javascript have access to a lot of information about the screen resolution, usable desktop size, OS widget size, toolbar size, title bar size, and OS desktop widget sizing information that are not at all relevant to -rendering and serve only to provide information for fingerprinting. +rendering and serve only to provide information for fingerprinting. Since many +aspects of desktop widget positioning and size are user configurable, these +properties yield customized information about the computer, even beyond the +monitor size. </p><p><span class="command"><strong>Design Goal:</strong></span> @@ -1190,7 +1190,7 @@ Beyond simple resolution information, a large amount of so-called "Media" information is also exported to content. Even without Javascript, CSS has access to a lot of information about the device orientation, system theme colors, and other desktop features that are not at all relevant to rendering -and serve only to provide information for fingerprinting. Most of this +and also user configurable. Most of this information comes from <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries" target="_top">CSS Media Queries</a>, but Mozilla has exposed <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#System_Colors" target="_top">several user and OS theme defined color values</a> to CSS as well. @@ -1210,6 +1210,32 @@ detection of font smoothing on OSX</a>. We also always <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/09561f0e5452305b9e…" target="_top">report landscape-primary</a> for the screen orientation. + </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> + +Because of the large amount of potential fingerprinting vectors and the <a class="ulink" href="http://www.contextis.com/resources/blog/webgl/" target="_top">previously unexposed +vulnerability surface</a>, we deploy a similar strategy against WebGL as +for plugins. First, WebGL Canvases have click-to-play placeholders (provided +by NoScript), and do not run until authorized by the user. Second, we +obfuscate driver information by setting the Firefox preferences +<span class="command"><strong>webgl.disable-extensions</strong></span> and +<span class="command"><strong>webgl.min_capability_mode</strong></span>, which reduce the information +provided by the following WebGL API calls: <span class="command"><strong>getParameter()</strong></span>, +<span class="command"><strong>getSupportedExtensions()</strong></span>, and +<span class="command"><strong>getExtension()</strong></span>. + + </p><p> + +Another option for WebGL might be to use software-only rendering, using a +library such as <a class="ulink" href="http://www.mesa3d.org/" target="_top">Mesa</a>. The use of +such a library would avoid hardware-specific rendering differences. + </p></li><li class="listitem">User Agent and HTTP Headers <p><span class="command"><strong>Design Goal:</strong></span> @@ -1241,12 +1267,13 @@ We set the fallback character set to set to windows-1252 for all locales, via the JS engine</a> to use en-US as its internal C locale for all Date, Math, and exception handling. - </p></li><li class="listitem">Timezone and clock offset + </p></li><li class="listitem">Timezone and Clock Offset <p> While the latency in Tor connections varies anywhere from milliseconds to -several seconds, it is still possible for the remote site to detect large -differences between the user's clock and an official reference timesource. +a few seconds, it is still possible for the remote site to detect large +differences between the user's clock and an official reference time source. + </p><p><span class="command"><strong>Design Goal:</strong></span> All Tor Browser users MUST report the same timezone to websites. Currently, we @@ -1264,7 +1291,7 @@ the browser can obtain this clock skew via a mechanism similar to that used in We set the timezone using the TZ environment variable, which is supported on all platforms. - </p></li><li class="listitem">Javascript performance fingerprinting + </p></li><li class="listitem">Javascript Performance Fingerprinting <p> <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Javascript performance @@ -1278,13 +1305,18 @@ We have <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3 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 +Date() object, while also introducing jitter. We believe that Javascript time +resolution may be reduced all the way up to the second before it seriously +impacts site operation. Our goal with this quantization 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 trade-off between quantization+jitter and amortization time. - +optimum trade-off between quantization+jitter and amortization time, as well +as identify highly variable Javascript operations. As long as these attacks +take several seconds or more to execute, they are unlikely to be appealing to +advertisers, and are also very likely to be noticed if deployed against a +large number of people. </p><p><span class="command"><strong>Implementation Status:</strong></span> @@ -1293,17 +1325,7 @@ disable <a class="ulink" href="http://www.w3.org/TR/navigation-timing/" target=" Timing</a> through the Firefox preference <span class="command"><strong>dom.enable_performance</strong></span>. - </p></li><li class="listitem">Non-Uniform HTML5 API Implementations - <p> - -At least two HTML5 features have different implementation status across the -major OS vendors: the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery" target="_top">Battery -API</a> and the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection" target="_top">Network -Connection API</a>. We disable these APIs -through the Firefox preferences <span class="command"><strong>dom.battery.enabled</strong></span> and -<span class="command"><strong>dom.network.enabled</strong></span>. - - </p></li><li class="listitem">Keystroke fingerprinting + </p></li><li class="listitem">Keystroke Fingerprinting <p> Keystroke fingerprinting is the act of measuring key strike time and key @@ -1316,7 +1338,7 @@ 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">Operating system type fingerprinting + </p></li><li class="listitem">Operating System Type Fingerprinting <p> As we mentioned in the introduction of this section, OS type fingerprinting is @@ -1328,36 +1350,38 @@ scrollbar size, and other rendered details on a page. Also, directly exported OS routines, such as the Math library, expose differences in their implementations due to these results. - </p><p><span class="command"><strong>Design Goal:</strong></span> We intend to reduce or eliminate OS type fingerprinting to the best extent possible, but recognize that the effort for reward on this item is not as high as other areas. The entropy on the current OS distribution is somewhere around 2 bits, which is much lower than other vectors which can also be used to -fingerprint configuration and user-specific information. +fingerprint configuration and user-specific information. You can see the +major areas of OS fingerprinting we're aware of using the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…" target="_top">tbb-fingerprinting-os +tag on our bug tracker</a>. </p><p><span class="command"><strong>Implementation Status:</strong></span> -We have no defenses deployed that address OS type fingerprinting by itself. -Several defenses may help also mitigate it, in addition to reducing a lot more -entropy elsewhere. You can see the major areas of OS fingerprinting we're -aware of using the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…" target="_top">tbb-fingerprinting-os -tag on our bugtracker</a>. +At least two HTML5 features have different implementation status across the +major OS vendors: the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery" target="_top">Battery +API</a> and the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection" target="_top">Network +Connection API</a>. We disable these APIs through the Firefox preferences +<span class="command"><strong>dom.battery.enabled</strong></span> and +<span class="command"><strong>dom.network.enabled</strong></span>. </p></li></ol></div></div><p> -For more details on fingerprinting bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…" target="_top">tbb-fingerprinting tag in our bugtracker</a> +For more details on fingerprinting bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…" target="_top">tbb-fingerprinting tag in our bug tracker</a> </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>4.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. This context menu option is active if Torbutton can read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT. - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60693264"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45220704"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> All linkable identifiers and browser state MUST be cleared by this feature. - </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60694512"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45221952"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> First, Torbutton disables Javascript in all open tabs and windows by using both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocSh…" target="_top">browser.docShell.allowJavascript</a> @@ -1401,7 +1425,7 @@ privacy and security issues. In order to provide vulnerability surface reduction for users that need high security, we have implemented a "Security Slider" that essentially represents a tradeoff between usability and security. Using metrics collected from -Mozilla's bugtracker, we analyzed the vulnerability counts of core components, +Mozilla's bug tracker, we analyzed the vulnerability counts of core components, and used <a class="ulink" href="https://github.com/iSECPartners/publications/tree/master/reports/Tor%20Brow…" target="_top">information gathered from a study performed by iSec Partners</a> to inform which features should be disabled at which security levels. @@ -1437,7 +1461,7 @@ all non-WebM HTML5 codecs (<span class="command"><strong>media.ogg.enabled</stro Fingerprinting</a> is a statistical attack to attempt to recognize specific encrypted website activity. - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60722880"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45250352"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> We want to deploy a mechanism that reduces the accuracy of <a class="ulink" href="https://en.wikipedia.org/wiki/Feature_selection" target="_top">useful features</a> available for classification. This mechanism would either impact the true and false @@ -1459,7 +1483,7 @@ Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor network, making them also effectively no-overhead. - </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60729776"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45257248"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/27ef32d509ed1c9eeb…" target="_top">randomize pipeline order and depth</a>. Unfortunately, pipelining is very fragile. Many sites do not support it, and even sites that advertise support for @@ -1524,7 +1548,7 @@ contend with. For this reason, we have deployed a build system that allows anyone to use our source code to reproduce byte-for-byte identical binary packages to the ones that we distribute. - </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60746000"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p> + </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp45273472"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p> The GNU toolchain has been working on providing reproducible builds for some time, however a large software project such as Firefox typically ends up @@ -1641,7 +1665,7 @@ unitialized memory</a> that only appear in LXC mode, as well as <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/12240" target="_top">oddities related to time-based dependency tracking</a> that only appear in LXC containers. - </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60781056"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> + </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp45308512"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> The build process produces a single sha256sums.txt file that contains a sorted list of the SHA-256 hashes of every package produced for that build version. Each @@ -1675,7 +1699,7 @@ and by their nature are based on non-public key material, providing native code-signed packages while still preserving ease of reproducibility verification has not yet been achieved. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60784992"></a>5.3. Anonymous Verification</h3></div></div></div><p> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp45312448"></a>5.3. Anonymous Verification</h3></div></div></div><p> Due to the fact that bit-identical packages can be produced by anyone, the security of this build system extends beyond the security of the official @@ -1691,7 +1715,7 @@ privately download our source code, verify it against public signed, audited, and mirrored git repositories, and reproduce our builds exactly, without being subject to targeted attacks. If they notice any differences, they can alert the public builders/signers, hopefully using a pseudonym or our anonymous -bugtracker account, to avoid revealing the fact that they are a build +bug tracker account, to avoid revealing the fact that they are a build verifier. </p></div></div><div class="appendix"><h2 class="title" style="clear: both"><a id="Transparency"></a>A. Towards Transparency in Navigation Tracking</h2><p> @@ -1791,7 +1815,7 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t ourselves</a>, as they are comparatively rare and can be handled with site permissions. - </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp60816992"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> + </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp45344896"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> Web-Send is a browser-based link sharing and federated login widget that is designed to operate without relying on third-party tracking or abusing other

1 0

[tor-browser-spec/master] Fingerprinting section clarifications and fixes.
by mikeperry＠torproject.org 07 Nov '14

07 Nov '14

commit e3f784b0a555f632097ef8ba42744457c9ad55e7 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Thu Nov 6 17:13:29 2014 -0800 Fingerprinting section clarifications and fixes. --- design-doc/design.xml | 249 +++++++++++++++++++++++++++---------------------- 1 file changed, 136 insertions(+), 113 deletions(-) diff --git a/design-doc/design.xml b/design-doc/design.xml index 7c19700..5e7aaa3 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -1435,46 +1435,59 @@ determine how many bits of identifying information each attribute provided. </para> <para> -Because fingerprinting is a problem that potentially touches every aspect of -the browser, we reduce the efforts for fingerprinting resistance by only -concerning ourselves with reducing the fingerprintable differences -<emphasis>among</emphasis> Tor Browser users. We do not believe it is possible -to solve cross-browser fingerprinting issues. +Unfortunately, there are limitations to the way the Panopticlick study was +conducted. Because the Panopticlick dataset is based on browser data spanning +a number of widely deployed browsers over a number of years, any +fingerprinting defenses attempted by browsers today are very likely to cause +Panopticlick to report an <emphasis>increase</emphasis> in fingerprintability +and entropy, because those defenses will stand out in sharp contrast to +historical data. Moreover, because fingerprinting is a problem that +potentially touches every aspect of the browser, we do not believe it is +possible to solve cross-browser fingerprinting issues. We reduce the efforts +for fingerprinting resistance by only concerning ourselves with reducing the +fingerprintable differences <emphasis>among</emphasis> Tor Browser users. </para> <para> -Unfortunately, the unsolvable nature of the cross-browser fingerprinting -problem means that the Panopticlick test website itself is not useful for -evaluating the actual effectiveness of our defenses, or the fingerprinting -defenses of any other web browser. Because the Panopticlick dataset is based -on browser data spanning a number of widely deployed browsers over a number of -years, any fingerprinting defenses attempted by browsers today are very likely -to cause Panopticlick to report an <emphasis>increase</emphasis> in -fingerprintability and entropy, because those defenses will stand out in sharp -contrast to historical data. We have been <ulink -url="https://trac.torproject.org/projects/tor/ticket/6119">working to convince -the EFF</ulink> that it is worthwhile to release the source code to -Panopticlick to allow us to run our own version for this reason. +The unsolvable nature of the cross-browser fingerprinting problem also means +that the Panopticlick test website itself is not useful for evaluating the +actual effectiveness of our defenses, or the fingerprinting defenses of any +other web browser. We are interested in deploying an improved version of +Panopticlick that measures entropy and variance only among a specific user +agent population, but until then, intuition serves as a decent guide. +Essentially, anything that reveals custom user configuration, third party +software, highly variable hardware details, and external devices attached to +the users computer is likely to more fingerprintable than things like +operating system type and even processor speed. </para> + <sect3 id="fingerprinting-defenses"> <title>Fingerprinting defenses in the Tor Browser</title> <para> The following defenses are listed roughly in order of most severe -fingerprinting threat first, though we are desperately in need of updated -measurements to determine this with certainty. Where our actual implementation -differs from an ideal solution, we separately describe our <command>Design -Goal</command> and our <command>Implementation Status</command>. +fingerprinting threat first. This ordering based on the above intuition that +user configurable aspects of the computer are the most severe source of +fingerprintability, though we are in need of updated measurements to determine +this with certainty. + + </para> + + <para> +Where our actual implementation differs from +an ideal solution, we separately describe our <command>Design Goal</command> +and our <command>Implementation Status</command>. </para> <orderedlist> <listitem>Plugins <para> -Plugins add to fingerprinting risk via two main vectors: their mere presence in -window.navigator.plugins, as well as their internal functionality. +Plugins add to fingerprinting risk via two main vectors: their mere presence +in window.navigator.plugins (because they are optional, end-user installed +third party software), as well as their internal functionality. </para> <para><command>Design Goal:</command> @@ -1508,11 +1521,10 @@ leaking plugin installation information. <listitem>HTML5 Canvas Image Extraction <para> -The <ulink url="https://developer.mozilla.org/en-US/docs/HTML/Canvas">HTML5 -Canvas</ulink> is a feature that has been added to major browsers after the -EFF developed their Panopticlick study. After plugins and plugin-provided -information, we believe that the HTML5 Canvas is the single largest -fingerprinting threat browsers face today. <ulink +After plugins and plugin-provided information, we believe that the <ulink +url="https://developer.mozilla.org/en-US/docs/HTML/Canvas">HTML5 +Canvas</ulink> is the single largest fingerprinting threat browsers face +today. <ulink url="http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf">Initial studies</ulink> show that the Canvas can provide an easy-access fingerprinting target: The adversary simply renders WebGL, font, and named color data to a @@ -1526,8 +1538,9 @@ image can be used almost identically to a tracking cookie by the web server. <para> In some sense, the canvas can be seen as the union of many other -fingerprinting vectors. If WebGL were normalized through software rendering, -and the browser shipped a fixed collection of fonts, it might not be necessary +fingerprinting vectors. If WebGL is normalized through software rendering, +system colors were standardized, and the browser shipped a fixed collection of +fonts (see later points in this list), it might not be necessary to create a canvas permission. However, until then, to reduce the threat from this vector, we have patched Firefox to <ulink url="https://gitweb.torproject.org/tor-browser.git/commitdiff/3b53f525cfb68880e6…">prompt @@ -1548,7 +1561,13 @@ In Firefox, by using either WebSockets or XHR, it is possible for remote content to <ulink url="http://www.andlabs.org/tools/jsrecon.html">enumerate the list of TCP ports open on 127.0.0.1</ulink>. In other browsers, this can be accomplished by DOM events on image or script tags. This open vs filtered -vs closed port list can provide a very unique fingerprint of a machine. +vs closed port list can provide a very unique fingerprint of a machine, +because it essentially enables the detection of many different popular third +party applications and optional system services (Skype, Bitcoin, Bittorrent +and other P2P software, SSH ports, SMB and related LAN services, CUPS and +printer daemon config ports, mail servers, and so on). It is also possible to +determine when ports are closed versus filtered/blocked (and thus probe +custom firewall configuration). </para> @@ -1561,7 +1580,21 @@ addresses by default. </para> </listitem> - <listitem>USB Device ID enumeration + <listitem>Invasive Authentication Mechanisms (NTLM and SPNEGO) + <para> + +Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in +some cases the current username. The only reason why these aren't a more +serious problem is that they typically involve user interaction, and likely +aren't an attractive vector for this reason. However, because it is not clear +if certain carefully-crafted error conditions in these protocols could cause +them to reveal machine information and still fail silently prior to the +password prompt, these authentication mechanisms should either be disabled, or +placed behind a site permission before their use. We simply disable them. + + </para> + </listitem> + <listitem>USB Device ID Enumeration <para> The <ulink @@ -1576,45 +1609,6 @@ We simply disable it via the pref <command>dom.gamepad.enabled</command>. </para> </listitem> - <listitem>Invasive Authentication Mechanisms (NTLM and SPNEGO) - <para> -Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in -some cases the machine username. These authentication mechanisms should either -be disabled, or placed behind a site permission before their use. We simply -disable them. - </para> - </listitem> - <listitem>WebGL - <para> - -WebGL is fingerprintable both through information that is exposed about the -underlying driver and optimizations, as well as through performance -fingerprinting. - - </para> - <para> - -Because of the large amount of potential fingerprinting vectors and the <ulink -url="http://www.contextis.com/resources/blog/webgl/">previously unexposed -vulnerability surface</ulink>, we deploy a similar strategy against WebGL as -for plugins. First, WebGL Canvases have click-to-play placeholders (provided -by NoScript), and do not run until authorized by the user. Second, we -obfuscate driver information by setting the Firefox preferences -<command>webgl.disable-extensions</command> and -<command>webgl.min_capability_mode</command>, which reduce the information -provided by the following WebGL API calls: <command>getParameter()</command>, -<command>getSupportedExtensions()</command>, and -<command>getExtension()</command>. - - </para> - <para> - -Another option for WebGL might be to use software-only rendering, using a -library such as <ulink url="http://www.mesa3d.org/">Mesa</ulink>. The use of -such a library would avoid hardware-specific rendering differences. - - </para> - </listitem> <listitem>Fonts <para> @@ -1623,7 +1617,8 @@ 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. +still be available, especially given that additional fonts often end up +installed by third party software and for multilingual support. </para> @@ -1669,13 +1664,16 @@ font (in any order), we use that font instead of any of the named local fonts. </para> </listitem> - <listitem>Monitor and OS Desktop resolution + <listitem>Monitor and OS Desktop Resolution <para> Both CSS and Javascript have access to a lot of information about the screen resolution, usable desktop size, OS widget size, toolbar size, title bar size, and OS desktop widget sizing information that are not at all relevant to -rendering and serve only to provide information for fingerprinting. +rendering and serve only to provide information for fingerprinting. Since many +aspects of desktop widget positioning and size are user configurable, these +properties yield customized information about the computer, even beyond the +monitor size. </para> <para><command>Design Goal:</command> @@ -1724,7 +1722,7 @@ Beyond simple resolution information, a large amount of so-called "Media" information is also exported to content. Even without Javascript, CSS has access to a lot of information about the device orientation, system theme colors, and other desktop features that are not at all relevant to rendering -and serve only to provide information for fingerprinting. Most of this +and also user configurable. Most of this information comes from <ulink url="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries">CSS Media Queries</ulink>, but Mozilla has exposed <ulink @@ -1753,6 +1751,37 @@ landscape-primary</ulink> for the screen orientation. </para> </listitem> + <listitem>WebGL + <para> + +WebGL is fingerprintable both through information that is exposed about the +underlying driver and optimizations, as well as through performance +fingerprinting. + + </para> + <para> + +Because of the large amount of potential fingerprinting vectors and the <ulink +url="http://www.contextis.com/resources/blog/webgl/">previously unexposed +vulnerability surface</ulink>, we deploy a similar strategy against WebGL as +for plugins. First, WebGL Canvases have click-to-play placeholders (provided +by NoScript), and do not run until authorized by the user. Second, we +obfuscate driver information by setting the Firefox preferences +<command>webgl.disable-extensions</command> and +<command>webgl.min_capability_mode</command>, which reduce the information +provided by the following WebGL API calls: <command>getParameter()</command>, +<command>getSupportedExtensions()</command>, and +<command>getExtension()</command>. + + </para> + <para> + +Another option for WebGL might be to use software-only rendering, using a +library such as <ulink url="http://www.mesa3d.org/">Mesa</ulink>. The use of +such a library would avoid hardware-specific rendering differences. + + </para> + </listitem> <listitem>User Agent and HTTP Headers <para><command>Design Goal:</command> @@ -1774,7 +1803,6 @@ url="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html">can be used</ulink> to fingerprint OS, platform, and Firefox minor version. </para> </listitem> - <listitem>Locale Fingerprinting <para> @@ -1795,13 +1823,13 @@ and exception handling. </para> </listitem> - - <listitem>Timezone and clock offset + <listitem>Timezone and Clock Offset <para> While the latency in Tor connections varies anywhere from milliseconds to -several seconds, it is still possible for the remote site to detect large -differences between the user's clock and an official reference timesource. +a few seconds, it is still possible for the remote site to detect large +differences between the user's clock and an official reference time source. + </para> <para><command>Design Goal:</command> @@ -1824,7 +1852,7 @@ all platforms. </para> </listitem> - <listitem>Javascript performance fingerprinting + <listitem>Javascript Performance Fingerprinting <para> <ulink url="http://w2spconf.com/2011/papers/jspriv.pdf">Javascript performance @@ -1840,14 +1868,19 @@ url="https://trac.torproject.org/projects/tor/ticket/3059">several potential mitigation approaches</ulink> 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 +Date() object, while also introducing jitter. We believe that Javascript time +resolution may be reduced all the way up to the second before it seriously +impacts site operation. Our goal with this quantization is to increase the amount of time it takes to mount a successful attack. <ulink -url="http://w2spconf.com/2011/papers/jspriv.pdf">Mowery et al</ulink> found that -even with the default precision in most browsers, they required up to 120 +url="http://w2spconf.com/2011/papers/jspriv.pdf">Mowery et al</ulink> 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 trade-off between quantization+jitter and amortization time. - +optimum trade-off between quantization+jitter and amortization time, as well +as identify highly variable Javascript operations. As long as these attacks +take several seconds or more to execute, they are unlikely to be appealing to +advertisers, and are also very likely to be noticed if deployed against a +large number of people. </para> <para><command>Implementation Status:</command> @@ -1859,21 +1892,7 @@ Timing</ulink> through the Firefox preference </para> </listitem> - <listitem>Non-Uniform HTML5 API Implementations - <para> - -At least two HTML5 features have different implementation status across the -major OS vendors: the <ulink -url="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery">Battery -API</ulink> and the <ulink -url="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection">Network -Connection API</ulink>. We disable these APIs -through the Firefox preferences <command>dom.battery.enabled</command> and -<command>dom.network.enabled</command>. - - </para> - </listitem> - <listitem>Keystroke fingerprinting + <listitem>Keystroke Fingerprinting <para> Keystroke fingerprinting is the act of measuring key strike time and key @@ -1890,7 +1909,7 @@ fingerprinting: timestamp quantization and jitter. We have no implementation as of yet. </para> </listitem> - <listitem>Operating system type fingerprinting + <listitem>Operating System Type Fingerprinting <para> As we mentioned in the introduction of this section, OS type fingerprinting is @@ -1902,7 +1921,6 @@ scrollbar size, and other rendered details on a page. Also, directly exported OS routines, such as the Math library, expose differences in their implementations due to these results. - </para> <para><command>Design Goal:</command> @@ -1910,17 +1928,22 @@ We intend to reduce or eliminate OS type fingerprinting to the best extent possible, but recognize that the effort for reward on this item is not as high as other areas. The entropy on the current OS distribution is somewhere around 2 bits, which is much lower than other vectors which can also be used to -fingerprint configuration and user-specific information. +fingerprint configuration and user-specific information. You can see the +major areas of OS fingerprinting we're aware of using the <ulink +url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…">tbb-fingerprinting-os +tag on our bug tracker</ulink>. </para> <para><command>Implementation Status:</command> -We have no defenses deployed that address OS type fingerprinting by itself. -Several defenses may help also mitigate it, in addition to reducing a lot more -entropy elsewhere. You can see the major areas of OS fingerprinting we're -aware of using the <ulink -url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…">tbb-fingerprinting-os -tag on our bugtracker</ulink>. +At least two HTML5 features have different implementation status across the +major OS vendors: the <ulink +url="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery">Battery +API</ulink> and the <ulink +url="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection">Network +Connection API</ulink>. We disable these APIs through the Firefox preferences +<command>dom.battery.enabled</command> and +<command>dom.network.enabled</command>. </para> </listitem> @@ -1928,7 +1951,7 @@ tag on our bugtracker</ulink>. </sect3> <para> For more details on fingerprinting bugs and enhancements, see the <ulink -url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…">tbb-fingerprinting tag in our bugtracker</ulink> +url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…">tbb-fingerprinting tag in our bug tracker</ulink> </para> </sect2> <sect2 id="new-identity"> @@ -2031,7 +2054,7 @@ privacy and security issues. In order to provide vulnerability surface reduction for users that need high security, we have implemented a "Security Slider" that essentially represents a tradeoff between usability and security. Using metrics collected from -Mozilla's bugtracker, we analyzed the vulnerability counts of core components, +Mozilla's bug tracker, we analyzed the vulnerability counts of core components, and used <ulink url="https://github.com/iSECPartners/publications/tree/master/reports/Tor%20Brow…">information gathered from a study performed by iSec Partners</ulink> to inform which @@ -2754,7 +2777,7 @@ privately download our source code, verify it against public signed, audited, and mirrored git repositories, and reproduce our builds exactly, without being subject to targeted attacks. If they notice any differences, they can alert the public builders/signers, hopefully using a pseudonym or our anonymous -bugtracker account, to avoid revealing the fact that they are a build +bug tracker account, to avoid revealing the fact that they are a build verifier. </para>

1 0

[webwml/master] Update design document based on feedback.
by mikeperry＠torproject.org 06 Nov '14

06 Nov '14

commit 22456a9689c3251b781c36a1203f7b360470ffde Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Thu Nov 6 15:47:53 2014 -0800 Update design document based on feedback. Also include 4.5-alpha-1 items. --- projects/torbrowser/design/index.html.en | 240 +++++++++++++++++------------- 1 file changed, 136 insertions(+), 104 deletions(-) diff --git a/projects/torbrowser/design/index.html.en b/projects/torbrowser/design/index.html.en index 8a32571..abeace5 100644 --- a/projects/torbrowser/design/index.html.en +++ b/projects/torbrowser/design/index.html.en @@ -1,9 +1,9 @@ <?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.78.1" /></head><body><div class="article"><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="a ffiliation"><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">October 30th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp33097664">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Secu rity Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isol ation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp39143984">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp39178848">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp39182784">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Tran sparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp39214016">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp33097664"></a>1. Introduction</h2></div></div></div><p> +<!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.78.1" /></head><body><div class="article"><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="a ffiliation"><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">November 6th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp59241696">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Secu rity Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isol ation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp60746000">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp60781056">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp60784992">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Tran sparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp60816992">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp59241696"></a>1. Introduction</h2></div></div></div><p> This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>, <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, and <a class="link" href="#Implementation" title="4. Implementation">implementation</a> of the Tor Browser. It is current as of Tor Browser -4.0. +4.5-alpha-1. </p><p> @@ -26,7 +26,7 @@ a number of Firefox preferences</a> from their defaults. Tor process management and configuration is accomplished through the <a class="ulink" href="https://gitweb.torproject.org/tor-launcher.git" target="_top">Tor Launcher</a> addon, which provides the initial Tor configuration splash screen and bootstrap progress bar. Tor Launcher is also compatible with Thunderbird, -InstantBird, and XULRunner. +Instantbird, and XULRunner. </p><p> @@ -85,7 +85,7 @@ Separation</strong></span></a><p> The browser MUST NOT provide the content window with any state from any other browsers or any non-Tor browsing modes. This includes shared state from -independent plugins, and shared state from Operating System implementations of +independent plugins, and shared state from operating system implementations of TLS and other support libraries. </p></li><li class="listitem"><a class="link" href="#disk-avoidance" title="4.3. Disk Avoidance"><span class="command"><strong>Disk @@ -108,7 +108,7 @@ must be able to ensure that secure deletion of the software is sufficient to remove evidence of the use of the software. All exceptions and shortcomings due to operating system behavior MUST be wiped by an uninstaller. However, due to permissions issues with access to swap, implementations MAY choose to leave -it out of scope, and/or leave it to the Operating System/platform to implement +it out of scope, and/or leave it to the operating system/platform to implement ephemeral-keyed encrypted swap. </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="privacy"></a>2.2. Privacy Requirements</h3></div></div></div><p> @@ -209,7 +209,7 @@ failure of Torbutton</a> was 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 and/or Operating System provided addons or plugins. +system-wide and/or operating system provided addons or plugins. </p><p> Instead of global browser privacy options, privacy decisions should be made @@ -289,10 +289,14 @@ 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. +data are the primary goals here. Secondary goals may include confirming +on-disk identifiers (such as hostname and disk-logged spoofed MAC adddress +history) obtained by other means. + </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="adversary-positioning"></a>3.2. Adversary Capabilities - Positioning</h3></div></div></div><p> The adversary can position themselves at a number of different locations in order to execute their attacks. @@ -588,11 +592,6 @@ connections are not attempted, through the proxy or otherwise (Tor does not yet support IPv6). We have also verified that external protocol helpers, such as smb urls and other custom protocol handlers are all blocked. - </p><p> - -Numerous other third parties have also reviewed and tested the proxy settings -and have provided test cases based on their work. See in particular <a class="ulink" href="http://decloak.net/" target="_top">decloak.net</a>. - </p></li><li class="listitem">Disabling plugins <p>Plugins have the ability to make arbitrary OS system calls and <a class="ulink" href="http://decloak.net/" target="_top">bypass proxy settings</a>. This includes @@ -655,13 +654,13 @@ system-wide extensions (through the use of disabled, which prevents Flash cookies from leaking from a pre-existing Flash directory. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp38917584"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60523824"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> The User Agent MUST (at user option) prevent all disk records of browser activity. The user should be able to optionally enable URL history and other history features if they so desire. - </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp38918944"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60525184"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> We achieve this goal through several mechanisms. First, we set the Firefox Private Browsing preference @@ -735,7 +734,7 @@ the url bar origin for which browser state exists, possibly with a context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1. - </p><div class="figure"><a id="idp38941648"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + </p><div class="figure"><a id="idp60547888"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> This example UI is a mock-up of how isolating identifiers to the URL bar origin can simplify the privacy UI for all data - not just cookies. Once @@ -773,7 +772,7 @@ of HTTP POST data. 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 conflicts with OCSP relying the cacheKey property for reuse of POST requests</a>, we -had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…" target="_top">patch +had to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/18dfd3064aff23a402…" target="_top">patch Firefox to provide a cacheDomain cache attribute</a>. We use the fully qualified url bar domain as input to this field, to avoid the complexities of heuristically determining the second-level DNS name. @@ -799,7 +798,7 @@ FQDN that was used to source the third party element. </p><p> Additionally, because the image cache is a separate entity from the content -cache, we had to patch Firefox to also <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…" target="_top">isolate +cache, we had to patch Firefox to also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/114cd22282f8b3cd6e…" target="_top">isolate this cache per url bar domain</a>. </p></li><li class="listitem">HTTP Auth @@ -814,7 +813,7 @@ linkability between domains</a>. DOM storage for third party domains MUST be isolated to the url bar origin, to prevent linkability between sites. This functionality is provided through a -<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…" target="_top">patch +<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/973468a07fb9e7d999…" target="_top">patch to Firefox</a>. </p></li><li class="listitem">Flash cookies @@ -843,7 +842,7 @@ origin MUST NOT be reused for that same third party in another url bar origin. We currently clear SSL Session IDs upon <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via "New Identity" button">New Identity</a>, we disable TLS Session Tickets via the Firefox Pref <span class="command"><strong>security.enable_tls_session_tickets</strong></span>. We disable SSL Session -IDs via a <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…" target="_top">patch +IDs via a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/5524ae43780e473831…" target="_top">patch to Firefox</a>. To compensate for the increased round trip latency from disabling these performance optimizations, we also enable <a class="ulink" href="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00" target="_top">TLS @@ -934,20 +933,13 @@ cleared by <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkabi defend against the creation of these cookies between <span class="command"><strong>New Identity</strong></span> invocations. </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> + <p> -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. +All content elements associated with a given URL bar domain (including the +main page) are given a SOCKS username and password for this domain, which +causes Tor to isolate all of these requests on their own set of Tor circuits. - </p></li></ol></div><p> + </p></li></ol></div><p> For more details on identifier linkability bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability&am…" target="_top">tbb-linkability tag in our bugtracker</a> </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>4.6. Cross-Origin Fingerprinting Unlinkability</h3></div></div></div><p> @@ -962,14 +954,11 @@ determine how many bits of identifying information each attribute provided. </p><p> -Because fingerprinting is problem that potentially touches every aspect of the -browser, we reduce the efforts for fingerprinting resistance by only +Because fingerprinting is a problem that potentially touches every aspect of +the browser, 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 possible -to solve cross-browser fingerprinting issues. Similarly, we prioritize issues -that differentiate only MacOS, Windows, and Linux lower than those that -differentiate aspects of the hardware, third party installed software, and -configuration differences in those operating systems. +to solve cross-browser fingerprinting issues. </p><p> @@ -1017,7 +1006,7 @@ Currently, we entirely disable all plugins in Tor Browser. However, as a compromise due to the popularity of Flash, we allow users to re-enable Flash, and flash objects are blocked behind a click-to-play barrier that is available only after the user has specifically enabled plugins. Flash is the only plugin -available, the rest are <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…" target="_top">entirely +available, the rest are <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/1ef32dcf0cc64876f5…" target="_top">entirely blocked from loading by a Firefox patch</a>. We also set the Firefox preference <span class="command"><strong>plugin.expose_full_path</strong></span> to false, to avoid leaking plugin installation information. @@ -1130,17 +1119,18 @@ and <a class="ulink" href="https://fedorahosted.org/lohit/" target="_top">Lohit font set is fairly complete by itself, but Nanum and Lohit have smaller versions of many South Asian languages. When combined in a way that chooses the smallest font implementations for each locale, these three font sets provide -which provide coverage for the all languages used on Wikipedia with more than +poverage for the all languages used on Wikipedia with more than 10,000 articles, and several others as well, in approximately 3MB of compressed overhead. The <a class="ulink" href="https://www.google.com/get/noto/" target="_top">Noto font set</a> is another font set that aims for complete coverage, but is considerably larger than the combination of the Droid, Nanum, and Lohit fonts. + </p><p><span class="command"><strong>Implementation Status:</strong></span> In the meantime while we investigate shipping our own fonts, we disable -plugins, which prevents font enumeration. Additionally, we limit both the +plugins, which prevents font name enumeration. Additionally, we limit both the number of font queries from CSS, as well as the total number of fonts that can -be used in a document <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…" target="_top">with +be used in a document <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/d515c79ffd115b132c…" target="_top">with a Firefox patch</a>. We create two prefs, <span class="command"><strong>browser.display.max_font_attempts</strong></span> and <span class="command"><strong>browser.display.max_font_count</strong></span> for this purpose. Once these @@ -1153,13 +1143,13 @@ To improve rendering, we exempt remote <a class="ulink" href="https://developer. fonts</a> from these counts, and if a font-family CSS rule lists a remote font (in any order), we use that font instead of any of the named local fonts. - </p></li><li class="listitem">Monitor and Desktop resolution + </p></li><li class="listitem">Monitor and OS Desktop resolution <p> Both CSS and Javascript have access to a lot of information about the screen resolution, usable desktop size, OS widget size, toolbar size, title bar size, -screen orientation, and other desktop features that are not at all relevant -to rendering and serve only to provide information for fingerprinting. +and OS desktop widget sizing information 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> @@ -1193,20 +1183,23 @@ addition, we prevent auto-maximizing on browser start, and are investigating a user-friendly way of informing users that maximized windows are detrimental to privacy in this mode. - </p></li><li class="listitem">CSS Media Queries + </p></li><li class="listitem">Display Media information <p> -Even without Javascript, CSS has access to a lot of information about the screen -resolution, usable desktop size, OS widget size, toolbar size, title bar size, -system theme colors, and other desktop features that are not at all relevant -to rendering and serve only to provide information for fingerprinting. Most of this information comes from -<a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries" target="_top">CSS Media Queries</a>, but -Mozilla has exposed <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#System_Colors" target="_top">several user and OS theme defined color values</a> to CSS as well. +Beyond simple resolution information, a large amount of so-called "Media" +information is also exported to content. Even without Javascript, CSS has +access to a lot of information about the device orientation, system theme +colors, and other desktop features that are not at all relevant to rendering +and serve only to provide information for fingerprinting. Most of this +information comes from <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries" target="_top">CSS +Media Queries</a>, but Mozilla has exposed <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#System_Colors" target="_top">several +user and OS theme defined color values</a> to CSS as well. </p><p><span class="command"><strong>Design Goal:</strong></span> -In Private Browsing Mode, CSS should not be able infer anything that the user -has configured about their computer. Additionally, it should not be able to -infer machine-specific details such as screen orientation or type. + +CSS should not be able infer anything that the user has configured about their +computer. Additionally, it should not be able to infer machine-specific +details such as screen orientation or type. </p><p><span class="command"><strong>Implementation Status:</strong></span> @@ -1230,7 +1223,7 @@ these headers should remain identical across the population even when updated. 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/maint-2.4:/src/current-pa…" target="_top">remove +<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/95cd0e8071aa1fe3f4…" 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">Locale Fingerprinting <p> @@ -1264,14 +1257,12 @@ 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. Alternatively, the browser can obtain this clock skew via a mechanism similar to that used in -<a class="ulink" href="" target="_top">tlsdate</a>. +<a class="ulink" href="https://github.com/ioerror/tlsdate" target="_top">tlsdate</a>. </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. +all platforms. </p></li><li class="listitem">Javascript performance fingerprinting <p> @@ -1325,12 +1316,12 @@ 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">Operating System type fingerprinting + </p></li><li class="listitem">Operating system type fingerprinting <p> As we mentioned in the introduction of this section, OS type fingerprinting is currently considered a lower priority, due simply to the numerous ways that -characteristics of the Operating System type may leak into content, and the +characteristics of the operating system type may leak into content, and the comparatively low contribution of OS to overall entropy. In particular, there are likely to be many ways to measure the differences in widget size, scrollbar size, and other rendered details on a page. Also, directly exported @@ -1348,25 +1339,25 @@ fingerprint configuration and user-specific information. </p><p><span class="command"><strong>Implementation Status:</strong></span> -We have no defenses deployed that address OS type fingerprinting, but nothing -else. Several defenses may help also mitigate it, in addition to reducing a -lot more entropy elsewhere. You can see the major areas of OS fingerprinting -we're aware of using the tag <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…" target="_top">tbb-fingerprinting-os -on our bugtracker</a>. +We have no defenses deployed that address OS type fingerprinting by itself. +Several defenses may help also mitigate it, in addition to reducing a lot more +entropy elsewhere. You can see the major areas of OS fingerprinting we're +aware of using the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…" target="_top">tbb-fingerprinting-os +tag on our bugtracker</a>. </p></li></ol></div></div><p> -For more details on identifier linkability bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…" target="_top">tbb-fingerprinting tag in our bugtracker</a> +For more details on fingerprinting bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…" target="_top">tbb-fingerprinting tag in our bugtracker</a> </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>4.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. This context menu option is active if Torbutton can read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT. - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp39106608"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60693264"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> All linkable identifiers and browser state MUST be cleared by this feature. - </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp39107856"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60694512"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> First, Torbutton disables Javascript in all open tabs and windows by using both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocSh…" target="_top">browser.docShell.allowJavascript</a> @@ -1383,10 +1374,10 @@ After closing all tabs, we then emit "<a class="ulink" href="https://developer.m (which instructs addons and various Firefox components to clear their session state), and then manually clear the following state: searchbox and findbox text, HTTP auth, SSL state, OCSP state, site-specific content preferences -(including HSTS state), content and image cache, offline cache, Cookies, DOM -storage, crypto tokens, DOM local storage, the safe browsing key, and the +(including HSTS state), content and image cache, offline cache, offline +storage, Cookies, crypto tokens, DOM storage, the safe browsing key, and the Google wifi geolocation token (if it exists). We also clear NoScript's site -and temporary permissions. +and temporary permissions, and all other browser site permissions. </p><p> @@ -1405,13 +1396,48 @@ In addition to the above mechanisms that are devoted to preserving privacy while browsing, we also have a number of technical mechanisms to address other privacy and security issues. - </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a id="traffic-fingerprinting-defenses"></a><span class="command"><strong>Website Traffic Fingerprinting Defenses</strong></span><p> + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a id="security-slider"></a><span class="command"><strong>Security Slider</strong></span><p> + +In order to provide vulnerability surface reduction for users that need high +security, we have implemented a "Security Slider" that essentially represents a +tradeoff between usability and security. Using metrics collected from +Mozilla's bugtracker, we analyzed the vulnerability counts of core components, +and used <a class="ulink" href="https://github.com/iSECPartners/publications/tree/master/reports/Tor%20Brow…" target="_top">information +gathered from a study performed by iSec Partners</a> to inform which +features should be disabled at which security levels. + + </p><p> + +The Security Slider consists of four positions. At the lowest security level +(the default), we disable +<span class="command"><strong>gfx.font_rendering.graphite.enabled</strong></span> for Latin locales, as +well as <span class="command"><strong>gfx.font_rendering.graphite.enabled</strong></span>. At the +medium-low level, we disable most Javascript JIT and related optimizations +(<span class="command"><strong>javascript.options.ion.content</strong></span>, +<span class="command"><strong>javascript.options.typeinference</strong></span>, +<span class="command"><strong>javascript.options.asmjs</strong></span>). We also make HTML5 media +click-to-play (<span class="command"><strong>noscript.forbidMedia</strong></span>), and disable WebAudio +(<span class="command"><strong>media.webaudio.enabled</strong></span>). At the medium-high level, we +disable the baseline JIT +(<span class="command"><strong>javascript.options.baselinejit.content</strong></span>), disable +Javascript entirely all elements that are loaded when the URL bar is not +HTTPS (<span class="command"><strong>noscript.globalHttpsWhitelist</strong></span>), and fully disable +graphite font rendering for all locales +(<span class="command"><strong>gfx.font_rendering.graphite.enable</strong></span>). At the highest level, +Javascript is fully disabled (<span class="command"><strong>noscript.global</strong></span>), as well as +all non-WebM HTML5 codecs (<span class="command"><strong>media.ogg.enabled</strong></span>, +<span class="command"><strong>media.opus.enabled</strong></span>, <span class="command"><strong>media.opus.enabled</strong></span>, +<span class="command"><strong>media.DirectShow.enabled</strong></span>, +<span class="command"><strong>media.wave.enabled</strong></span>, and +<span class="command"><strong>media.apple.mp3.enabled</strong></span>). + + </p></li><li class="listitem"><a id="traffic-fingerprinting-defenses"></a><span class="command"><strong>Website Traffic Fingerprinting Defenses</strong></span><p> <a class="link" href="#website-traffic-fingerprinting">Website Traffic Fingerprinting</a> is a statistical attack to attempt to recognize specific encrypted website activity. - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp39122096"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60722880"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> We want to deploy a mechanism that reduces the accuracy of <a class="ulink" href="https://en.wikipedia.org/wiki/Feature_selection" target="_top">useful features</a> available for classification. This mechanism would either impact the true and false @@ -1433,8 +1459,8 @@ Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor network, making them also effectively no-overhead. - </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp39128912"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> -Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…" target="_top">randomize + </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60729776"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> +Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/27ef32d509ed1c9eeb…" target="_top">randomize pipeline order and depth</a>. Unfortunately, pipelining is very fragile. Many sites do not support it, and even sites that advertise support for pipelining may simply return error codes for successive requests, effectively @@ -1483,6 +1509,12 @@ homepage to point to a <a class="ulink" href="https://check.torproject.org/?lang informs the user</a> that their browser is out of date. + </p><p> + +We also make use of the in-browser Mozilla updater, and have <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/777695d09e3cff4c79…" target="_top">patched +the updater</a> to avoid sending OS and Kernel version information as part +of its update pings. + </p></li></ol></div></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="BuildSecurity"></a>5. Build Security and Package Integrity</h2></div></div></div><p> In the age of state-sponsored malware, <a class="ulink" href="https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and…" target="_top">we @@ -1492,7 +1524,7 @@ contend with. For this reason, we have deployed a build system that allows anyone to use our source code to reproduce byte-for-byte identical binary packages to the ones that we distribute. - </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp39143984"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p> + </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60746000"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p> The GNU toolchain has been working on providing reproducible builds for some time, however a large software project such as Firefox typically ends up @@ -1516,7 +1548,7 @@ authentication, as well as transfer intermediate build outputs between the stages of the build process. Because Gitian creates an Ubuntu build environment, we must use cross-compilation to create packages for Windows and Mac OS. For Windows, we use mingw-w64 as our cross compiler. For Mac OS, we -use toolchain4 in combination with a binary redistribution of the Mac OS 10.6 +use crosstools-ng in combination with a binary redistribution of the Mac OS 10.6 SDK. </p><p> @@ -1561,19 +1593,10 @@ patch</a>. The standard way of controlling timestamps in Gitian is to use libfaketime, which hooks time-related library calls to provide a fixed timestamp. However, -libfaketime does not spoof the millisecond and microsecond components of -timestamps, which found their way into pyc files and also in explicit Firefox -build process timestamp embedding. - </p><p> - -We addressed the Firefox issues with direct patches to their build process, -which have since been merged. However, pyc timestamps had to be address with -an additional <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi…" target="_top">helper -script</a>. - </p><p> - -The timezone leaks were addressed by setting the <span class="command"><strong>TZ</strong></span> -environment variable to UTC in our descriptors. +due to our use of wine to run py2exe for python-based pluggable transports, +pyc timestamps had to be address with an additional <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi…" target="_top">helper +script</a>. The timezone leaks were addressed by setting the +<span class="command"><strong>TZ</strong></span> environment variable to UTC in our descriptors. </p></li><li class="listitem">Deliberately generated entropy <p> @@ -1610,11 +1633,18 @@ hostname and Linux kernel version can leak from the host OS into the LXC container. We addressed umask by setting it explicitly in our Gitian descriptor scriptlet, and addressed the hostname and kernel version leaks by directly patching the aspects of the Firefox build process that included this -information into the build. - </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp39178848"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> +information into the build. It also turns out that some libraries (in +particular: libgmp) attempt to detect the current CPU to determine which +optimizations to compile in. This CPU type is uniform on our KVM instances, +but differs under LXC. We are also investigating currently <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/12239" target="_top">unknown sources of +unitialized memory</a> that only appear in LXC mode, as well as +<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/12240" target="_top">oddities related to +time-based dependency tracking</a> that only appear in LXC containers. + + </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60781056"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> The build process produces a single sha256sums.txt file that contains a sorted -list the SHA-256 hashes of every package produced for that build version. Each +list of the SHA-256 hashes of every package produced for that build version. Each official builder uploads this file and a GPG signature of it to a directory on a Tor Project's web server. The build scripts have an optional matching step that downloads these signatures, verifies them, and ensures that the @@ -1645,7 +1675,7 @@ and by their nature are based on non-public key material, providing native code-signed packages while still preserving ease of reproducibility verification has not yet been achieved. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp39182784"></a>5.3. Anonymous Verification</h3></div></div></div><p> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60784992"></a>5.3. Anonymous Verification</h3></div></div></div><p> Due to the fact that bit-identical packages can be produced by anyone, the security of this build system extends beyond the security of the official @@ -1717,14 +1747,16 @@ source URL parameters. </p><p> -We believe the Referer header should be made explicit. If a site wishes to -transmit its URL to third party content elements during load or during -link-click, it should have to specify this as a property of the associated HTML -tag. With an explicit property, it would then be possible for the user agent to -inform the user if they are about to click on a link that will transmit Referer -information (perhaps through something as subtle as a different color in the -lower toolbar for the destination URL). This same UI notification can also be -used for links with the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes" target="_top">"ping"</a> +We believe the Referer header should be made explicit, and believe that CSP +2.0 provides a <a class="ulink" href="http://www.w3.org/TR/CSP11/#directive-referrer" target="_top">decent step in this +direction</a>. If a site wishes to transmit its URL to third party content +elements during load or during link-click, it should have to specify this as a +property of the associated HTML tag or CSP policy. With an explicit property +or policy, it would then be possible for the user agent to inform the user if +they are about to click on a link that will transmit Referer information +(perhaps through something as subtle as a different color in the lower toolbar +for the destination URL). This same UI notification can also be used for links +with the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes" target="_top">"ping"</a> attribute. </p></li><li class="listitem">window.name @@ -1759,7 +1791,7 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t ourselves</a>, as they are comparatively rare and can be handled with site permissions. - </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp39214016"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> + </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp60816992"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> Web-Send is a browser-based link sharing and federated login widget that is designed to operate without relying on third-party tracking or abusing other

1 0

[tor-browser-spec/master] Minor phrase fixes.
by mikeperry＠torproject.org 06 Nov '14

06 Nov '14

commit c90ea472b7a3e5b14380daa805dbb74b8fca1291 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Fri Oct 31 23:01:51 2014 -0700 Minor phrase fixes. --- design-doc/design.xml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/design-doc/design.xml b/design-doc/design.xml index 9ff1b89..914a84d 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -1927,12 +1927,12 @@ fingerprint configuration and user-specific information. </para> <para><command>Implementation Status:</command> -We have no defenses deployed that address OS type fingerprinting, but nothing -else. Several defenses may help also mitigate it, in addition to reducing a -lot more entropy elsewhere. You can see the major areas of OS fingerprinting -we're aware of using the tag <ulink +We have no defenses deployed that address OS type fingerprinting by itself. +Several defenses may help also mitigate it, in addition to reducing a lot more +entropy elsewhere. You can see the major areas of OS fingerprinting we're +aware of using the <ulink url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…">tbb-fingerprinting-os -on our bugtracker</ulink>. +tag on our bugtracker</ulink>. </para> </listitem>

1 0

[tor-browser-spec/master] Update patch links.
by mikeperry＠torproject.org 06 Nov '14

06 Nov '14

commit a76069c8288bcf9d680a8a39264796e057701b92 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Thu Nov 6 15:42:17 2014 -0800 Update patch links. --- design-doc/design.xml | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/design-doc/design.xml b/design-doc/design.xml index e57def0..7c19700 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -1200,7 +1200,7 @@ security of the isolation</ulink> and to <ulink url="https://trac.torproject.org/projects/tor/ticket/3754">solve conflicts with OCSP relying the cacheKey property for reuse of POST requests</ulink>, we had to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">patch +url="https://gitweb.torproject.org/tor-browser.git/commitdiff/18dfd3064aff23a402…">patch Firefox to provide a cacheDomain cache attribute</ulink>. We use the fully qualified url bar domain as input to this field, to avoid the complexities of heuristically determining the second-level DNS name. @@ -1232,7 +1232,7 @@ FQDN that was used to source the third party element. Additionally, because the image cache is a separate entity from the content cache, we had to patch Firefox to also <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">isolate +url="https://gitweb.torproject.org/tor-browser.git/commitdiff/114cd22282f8b3cd6e…">isolate this cache per url bar domain</ulink>. </para> @@ -1254,7 +1254,7 @@ linkability between domains</ulink>. DOM storage for third party domains MUST be isolated to the url bar origin, to prevent linkability between sites. This functionality is provided through a <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">patch +url="https://gitweb.torproject.org/tor-browser.git/commitdiff/973468a07fb9e7d999…">patch to Firefox</ulink>. </para> @@ -1292,7 +1292,7 @@ We currently clear SSL Session IDs upon <link linkend="new-identity">New Identity</link>, we disable TLS Session Tickets via the Firefox Pref <command>security.enable_tls_session_tickets</command>. We disable SSL Session IDs via a <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">patch +url="https://gitweb.torproject.org/tor-browser.git/commitdiff/5524ae43780e473831…">patch to Firefox</ulink>. To compensate for the increased round trip latency from disabling these performance optimizations, we also enable <ulink url="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00">TLS @@ -1498,7 +1498,7 @@ compromise due to the popularity of Flash, we allow users to re-enable Flash, and flash objects are blocked behind a click-to-play barrier that is available only after the user has specifically enabled plugins. Flash is the only plugin available, the rest are <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">entirely +url="https://gitweb.torproject.org/tor-browser.git/commitdiff/1ef32dcf0cc64876f5…">entirely blocked from loading by a Firefox patch</ulink>. We also set the Firefox preference <command>plugin.expose_full_path</command> to false, to avoid leaking plugin installation information. @@ -1652,7 +1652,7 @@ In the meantime while we investigate shipping our own fonts, we disable plugins, which prevents font name enumeration. Additionally, we limit both the number of font queries from CSS, as well as the total number of fonts that can be used in a document <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">with +url="https://gitweb.torproject.org/tor-browser.git/commitdiff/d515c79ffd115b132c…">with a Firefox patch</ulink>. We create two prefs, <command>browser.display.max_font_attempts</command> and <command>browser.display.max_font_count</command> for this purpose. Once these @@ -1768,7 +1768,7 @@ 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 <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">remove +url="https://gitweb.torproject.org/tor-browser.git/commitdiff/95cd0e8071aa1fe3f4…">remove content script access</ulink> to Components.interfaces, which <ulink url="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html">can be used</ulink> to fingerprint OS, platform, and Firefox minor version. </para> @@ -2112,7 +2112,7 @@ network, making them also effectively no-overhead. <blockquote> <para> Currently, we patch Firefox to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa…">randomize +url="https://gitweb.torproject.org/tor-browser.git/commitdiff/27ef32d509ed1c9eeb…">randomize pipeline order and depth</ulink>. Unfortunately, pipelining is very fragile. Many sites do not support it, and even sites that advertise support for pipelining may simply return error codes for successive requests, effectively

1 0

[tor-browser-spec/master] Update design doc for 4.5-alpha-1.
by mikeperry＠torproject.org 06 Nov '14

06 Nov '14

commit f33dc32759d65bdf39748f5df5dc6d19044b5a85 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Thu Nov 6 14:44:59 2014 -0800 Update design doc for 4.5-alpha-1. --- design-doc/design.xml | 87 ++++++++++++++++++++++++++++++++++--------------- 1 file changed, 60 insertions(+), 27 deletions(-) diff --git a/design-doc/design.xml b/design-doc/design.xml index 914a84d..6e4bfc1 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -40,7 +40,7 @@ This document describes the <link linkend="adversary">adversary model</link>, linkend="Implementation">implementation</link>  of the Tor Browser. It is current as of Tor Browser -4.0. +4.5-alpha-1. </para> <para> @@ -530,10 +530,14 @@ least <link linkend="fingerprinting">tracking their activities</link>. <listitem><command>History records and other on-disk information</command> <para> + 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. +data are the primary goals here. Secondary goals may include confirming +on-disk identifiers (such as hostname and disk-logged spoofed MAC adddress +history) obtained by other means. + </para> </listitem> </orderedlist> @@ -938,13 +942,6 @@ yet support IPv6). We have also verified that external protocol helpers, such as smb urls and other custom protocol handlers are all blocked. </para> - <para> - -Numerous other third parties have also reviewed and tested the proxy settings -and have provided test cases based on their work. See in particular <ulink -url="http://decloak.net/">decloak.net</ulink>. - - </para> </listitem> <listitem>Disabling plugins @@ -1407,22 +1404,13 @@ Identity</command> invocations. </para> </listitem> <listitem>Exit node usage - <para><command>Design Goal:</command> - -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. - - </para> - <para><command>Implementation Status:</command> + <para> -The Tor feature that supports this ability only exists in the 0.2.3.x-alpha -series. <ulink -url="https://trac.torproject.org/projects/tor/ticket/3455">Ticket -#3455</ulink> is the Torbutton ticket to make use of the new Tor -functionality. +All content elements associated with a given URL bar domain (including the +main page) are given a SOCKS username and password for this domain, which +causes Tor to isolate all of these requests on their own set of Tor circuits. - </para> + </para> </listitem> </orderedlist> <para> @@ -1829,10 +1817,7 @@ the browser can obtain this clock skew via a mechanism similar to that used in <para><command>Implementation Status:</command> We set the timezone using the TZ environment variable, which is supported on -all platforms. Additionally, we plan to <ulink -url="https://trac.torproject.org/projects/tor/ticket/3652">obtain a clock -offset from Tor</ulink>, but this won't be available until Tor 0.2.3.x is in -use. +all platforms. </para> </listitem> @@ -2037,6 +2022,46 @@ privacy and security issues. </para> <orderedlist> + <listitem id="security-slider"><command>Security Slider</command> + <para> + +In order to provide vulnerability surface reduction for users that need high +security, we have implemented a "Security Slider" that essentially represents a +tradeoff between usability and security. Using metrics collected from +Mozilla's bugtracker, we analyzed the vulnerability counts of core components, +and used <ulink +url="https://github.com/iSECPartners/publications/tree/master/reports/Tor%20Brow…">information +gathered from a study performed by iSec Partners</ulink> to inform which +features should be disabled at which security levels. + + </para> + <para> + +The Security Slider consists of four positions. At the lowest security level +(the default), we disable +<command>gfx.font_rendering.graphite.enabled</command> for Latin locales, as +well as <command>gfx.font_rendering.graphite.enabled</command>. At the +medium-low level, we disable most Javascript JIT and related optimizations +(<command>javascript.options.ion.content</command>, +<command>javascript.options.typeinference</command>, +<command>javascript.options.asmjs</command>). We also make HTML5 media +click-to-play (<command>noscript.forbidMedia</command>), and disable WebAudio +(<command>media.webaudio.enabled</command>). At the medium-high level, we +disable the baseline JIT +(<command>javascript.options.baselinejit.content</command>), disable +Javascript entirely all elements that are loaded when the URL bar is not +HTTPS (<command>noscript.globalHttpsWhitelist</command>), and fully disable +graphite font rendering for all locales +(<command>gfx.font_rendering.graphite.enable</command>). At the highest level, +Javascript is fully disabled (<command>noscript.global</command>), as well as +all non-WebM HTML5 codecs (<command>media.ogg.enabled</command>, +<command>media.opus.enabled</command>, <command>media.opus.enabled</command>, +<command>media.DirectShow.enabled</command>, +<command>media.wave.enabled</command>, and +<command>media.apple.mp3.enabled</command>). + + </para> + </listitem> <listitem id="traffic-fingerprinting-defenses"><command>Website Traffic Fingerprinting Defenses</command> <para> @@ -2146,6 +2171,14 @@ informs the user</ulink> that their browser is out of date. </para> + <para> + +We also make use of the in-browser Mozilla updater, and have <ulink +url="https://gitweb.torproject.org/tor-browser.git/commitdiff/777695d09e3cff4c79…">patched +the updater</ulink> to avoid sending OS and Kernel version information as part +of its update pings. + + </para> </listitem> </orderedlist>

1 0

← Newer
1
...
75
76
77
78
79
80
81
...
96
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits November 2014