commit 49483860c8da51059039e2b2b6129128f32a1e72
Author: Mike Perry <[email protected]>
Date: Wed May 6 15:12:28 2015 -0700
More Tor Browser design doc updates.
---
projects/torbrowser/design/index.html.en | 150 ++++++++++++++++--------------
1 file changed, 79 insertions(+), 71 deletions(-)
diff --git a/projects/torbrowser/design/index.html.en
b/projects/torbrowser/design/index.html.en
index ce3c916..c017f4e 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">May 6th,
2015</p></div></div><hr /></div><div class="toc"><p><strong>Table of
Contents</strong></p><dl class="toc"><dt><span class="sect1"><a
href="#idp54432272">1. Introduction</a></span></dt><dd><dl><dt><span
class="sect2"><a href="#components">1.1. Browser Component
Overview</a></span></dt></dl></dd><dt><span class="sect1"><a
href="#DesignRequirements">2. Design Requirements and
Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a
href="#security">2.1. Security
Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2.
Privacy Requirements</a></span></dt><dt><span class="sect2"><a
href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span
class="sect1"><a href="#adversary">3. Adversary
Model</a></span></dt><dd><dl><dt><span class="sect2"><a
href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span
class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities -
Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3.
Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span
class="sect1"><a href="#Implementation">4.
Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a
href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span
class="sect2"><a href="#state-separation">4.2. State
Separation</a></span></dt><dt><span class="sect2"><a
href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span
class="sect2"><a href="#app-data-isolation
">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a
href="#identifier-linkability">4.5. Cross-Origin Identifier
Unlinkability</a></span></dt><dt><span class="sect2"><a
href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting
Unlinkability</a></span></dt><dt><span class="sect2"><a
href="#new-identity">4.7. Long-Term Unlinkability via "New Identity"
button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8.
Other Security Measures</a></span></dt></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="#idp56215504">5.1. Achieving Binary
Reproducibility</a></span></dt><dt><span class="sect2"><a
href="#idp56237264">5.2. Package Signatures and
Verification</a></span></dt><dt><span class="sect2"><a href="#idp56241792">5.3.
Anonymous Verification</a></span></dt><dt><span class="sect2"><a
href="#update-safety">5.4. Update Safety</a></span></d
t></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards
Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span
class="sect1"><a href="#deprecate">A.1. Deprecation
Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp56278768">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="idp54432272"></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">May 6th,
2015</p></div></div><hr /></div><div class="toc"><p><strong>Table of
Contents</strong></p><dl class="toc"><dt><span class="sect1"><a
href="#idp69131840">1. Introduction</a></span></dt><dd><dl><dt><span
class="sect2"><a href="#components">1.1. Browser Component
Overview</a></span></dt></dl></dd><dt><span class="sect1"><a
href="#DesignRequirements">2. Design Requirements and
Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a
href="#security">2.1. Security
Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2.
Privacy Requirements</a></span></dt><dt><span class="sect2"><a
href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span
class="sect1"><a href="#adversary">3. Adversary
Model</a></span></dt><dd><dl><dt><span class="sect2"><a
href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span
class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities -
Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3.
Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span
class="sect1"><a href="#Implementation">4.
Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a
href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span
class="sect2"><a href="#state-separation">4.2. State
Separation</a></span></dt><dt><span class="sect2"><a
href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span
class="sect2"><a href="#app-data-isolation
">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a
href="#identifier-linkability">4.5. Cross-Origin Identifier
Unlinkability</a></span></dt><dt><span class="sect2"><a
href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting
Unlinkability</a></span></dt><dt><span class="sect2"><a
href="#new-identity">4.7. Long-Term Unlinkability via "New Identity"
button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8.
Other Security Measures</a></span></dt></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="#idp70162016">5.1. Achieving Binary
Reproducibility</a></span></dt><dt><span class="sect2"><a
href="#idp70184144">5.2. Package Signatures and
Verification</a></span></dt><dt><span class="sect2"><a href="#idp70188672">5.3.
Anonymous Verification</a></span></dt><dt><span class="sect2"><a
href="#update-safety">5.4. Update Safety</a></span></d
t></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards
Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span
class="sect1"><a href="#deprecate">A.1. Deprecation
Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp70225312">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="idp69131840"></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
@@ -655,13 +655,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="idp55920416"></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="idp66184288"></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="idp55921776"></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="idp66185680"></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
@@ -733,7 +733,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="idp55943472"></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="idp66208640"></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
@@ -741,7 +741,7 @@ browser identifiers and site permissions operate on a URL
bar basis, the same
privacy window can represent browsing history, DOM Storage, HTTP Auth, search
form history, login values, and so on within a context menu for each site.
-</div></div></div><br class="figure-break" /><div class="sect3"><div
class="titlepage"><div><div><h4 class="title"><a
id="idp55946896"></a>Identifier Unlinkability Defenses in the Tor
Browser</h4></div></div></div><p>
+</div></div></div><br class="figure-break" /><div class="sect3"><div
class="titlepage"><div><div><h4 class="title"><a
id="idp69892352"></a>Identifier Unlinkability Defenses in the Tor
Browser</h4></div></div></div><p>
Unfortunately, many aspects of browser state can serve as identifier storage,
and no other browser vendor or standards body has invested the effort to
@@ -953,25 +953,31 @@ For more details on identifier linkability bugs and
enhancements, see the <a cla
</p></div></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>
Browser fingerprinting is the act of inspecting browser behaviors and features
in
-an attempt to differentiate and track individual users. Fingerprinting attacks
-are typically broken up into passive and active vectors. Passive
-fingerprinting makes use of any information the browser provides automatically
-to a website without any specific action on the part of the website. Active
-fingerprinting makes use of any information that can be extracted from the
-browser by some specific website action, usually involving Javascript.
-Some definitions of browser fingerprinting also include supercookies and
-cookie-like identifier storage, but we deal with those issues separately in
-the <a class="link" href="#identifier-linkability" title="4.5. Cross-Origin
Identifier Unlinkability">preceding section on identifier
-linkability</a>.
-
- </p><p>
+an attempt to differentiate and track individual users.
+ </p><p>
+Fingerprinting attacks are typically broken up into passive and active
+vectors. Passive fingerprinting makes use of any information the browser
+provides automatically to a website without any specific action on the part of
+the website. Active fingerprinting makes use of any information that can be
+extracted from the browser by some specific website action, usually involving
+Javascript. Some definitions of browser fingerprinting also include
+supercookies and cookie-like identifier storage, but we deal with those issues
+separately in the <a class="link" href="#identifier-linkability" title="4.5.Â
Cross-Origin Identifier Unlinkability">preceding section on
+identifier linkability</a>.
+ </p><p>
For the most part, however, we do not differentiate between passive or active
fingerprinting sources, since many active fingerprinting mechanisms are very
rapid, and can be obfuscated or disguised as legitimate functionality.
+
+ </p><p>
+
Instead, we believe fingerprinting can only be rationally addressed if we
understand where the problem comes from, what sources of issues are the most
-severe, and how to study the efficacy of defenses properly.
+severe, what types of defenses are suitable for which sources, and have a
+consistent strategy for designing defenses that maximizes our ability to study
+defense efficacy. The following subsections address these issues from a high
+level, and we then conclude with a list of our current specific defenses.
</p><div class="sect3"><div class="titlepage"><div><div><h4
class="title"><a id="fingerprinting-scope"></a>Sources of Fingerprinting
Issues</h4></div></div></div><p>
@@ -995,9 +1001,10 @@ identify a user. We believe it is essential to avoid
exposing platform
configuration details to website content at all costs. We also discourage
excessive fine-grained customization of Tor Browser by minimizing and
aggregating user-facing privacy and security options, as well as by
-discouraging the use of additional addons. When it is necessary to expose
-configuration details in the course of providing functionality, we strive to
-do so only on a per-site basis via site permissions, to avoid linkability.
+discouraging the use of additional plugins and addons. When it is necessary to
+expose configuration details in the course of providing functionality, we
+strive to do so only on a per-site basis via site permissions, to avoid
+linkability.
</p></li><li class="listitem"><span class="command"><strong>Device and
Hardware Characteristics</strong></span><p>
@@ -1006,9 +1013,9 @@ be reported explicitly by the browser, they can be
inferred through browser
functionality, or they can be extracted through statistical measurements of
system performance. We are most concerned with the cases where this
information is either directly reported or can be determined via a single use
-of an API or feature, and prefer to place such APIs either behind site
-permissions, alter their functionality to prevent exposing the most variable
-aspects of these characteristics, or disable them entirely.
+of an API or feature, and prefer to either alter functionality to prevent
+exposing the most variable aspects of these characteristics, place such
+features behind site permissions, or disable them entirely.
</p><p>
@@ -1040,7 +1047,7 @@ fingerprinted through their behavior while interacting
with a website. This
behavior includes e.g. keystrokes, mouse movements, click speed, and writing
style. Basic vectors such as keystroke and mouse usage fingerprinting can be
mitigated by altering Javascript's notion of time. More advanced issues like
-writing style fingerprinting are the domain of <a class="ulink"
href="https://github.com/psal/anonymouth"; target="_top">other tools</a>.
+writing style fingerprinting are the domain of <a class="ulink"
href="https://github.com/psal/anonymouth/blob/master/README.md";
target="_top">other tools</a>.
</p></li><li class="listitem"><span class="command"><strong>Browser
Vendor and Version Differences</strong></span><p>
@@ -1063,9 +1070,10 @@ defenses for APIs that have already been standardized
and deployed. Once an
API or feature has been standardized and widely deployed, defenses to the
associated fingerprinting issues tend to have only a few options available to
compensate for the lack of up-front privacy design. In our experience, so far
-these options have been limited to value spoofing, subsystem reimplementation,
-virtualization, site permissions, and feature removal. We will now describe
-these options and the fingerprinting sources they tend to work best with.
+these options have been limited to value spoofing, subsystem modification or
+reimplementation, virtualization, site permissions, and feature removal. We
+will now describe these options and the fingerprinting sources they tend to
+work best with.
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li
class="listitem"><span class="command"><strong>Value Spoofing</strong></span><p>
@@ -1075,17 +1083,17 @@ or operating system directly to a website. It becomes
less useful when the
fingerprinting method relies on behavior to infer aspects of the hardware or
operating system, rather than obtain them directly.
- </p></li><li class="listitem"><span class="command"><strong>Subsystem
Reimplementation</strong></span><p>
+ </p></li><li class="listitem"><span class="command"><strong>Subsystem
Modification or Reimplementation</strong></span><p>
In cases where simple spoofing is not enough to properly conceal underlying
-device characteristics or operating system details, the underlying
-subsystem that provides the functionality for a feature or API may need
-to be completely reimplemented. This is most common in cases where
-customizable or version-specific aspects of the user's operating system are
-visible through the browser's featureset or APIs, usually because the browser
-directly exposes OS-provided implementations of underlying features. In these
-cases, such OS-provided implementations must be replaced by a generic
-implementation, or at least an implementation wrapper that makes effort to
+device characteristics or operating system details, the underlying subsystem
+that provides the functionality for a feature or API may need to be modified
+or completely reimplemented. This is most common in cases where customizable
+or version-specific aspects of the user's operating system are visible through
+the browser's featureset or APIs, usually because the browser directly exposes
+OS-provided implementations of underlying features. In these cases, such
+OS-provided implementations must be replaced by a generic implementation, or
+at least modified by an implementation wrapper layer that makes effort to
conceal any user-customized aspects of the system.
</p></li><li class="listitem"><span
class="command"><strong>Virtualization</strong></span><p>
@@ -1116,12 +1124,12 @@ narrow domain or use case, or when there are alternate
ways of accomplishing
the same task, these features and/or certain aspects of their functionality
may be simply removed.
- </p></li></ol></div></div><div class="sect3"><div
class="titlepage"><div><div><h4 class="title"><a
id="idp56040528"></a>Randomization or Uniformity?</h4></div></div></div><p>
+ </p></li></ol></div></div><div class="sect3"><div
class="titlepage"><div><div><h4 class="title"><a
id="idp69985904"></a>Strategies for Defense: Randomization versus
Uniformity</h4></div></div></div><p>
When applying a form of defense to a specific fingerprinting vector or source,
-there are two general strategies available. Either the implementation for all
+there are two general strategies available: either the implementation for all
users of a single browser version can be made to behave as uniformly as
-possible, or the user agent can attempt to randomize its behavior, so that
+possible, or the user agent can attempt to randomize its behavior so that
each interaction between a user and a site provides a different fingerprint.
</p><p>
@@ -1131,7 +1139,28 @@ research suggests</a> that randomization can be
effective, so far striving
for uniformity has generally proved to be a better strategy for Tor Browser
for the following reasons:
- </p><div class="orderedlist"><ol class="orderedlist" type="1"><li
class="listitem"><span class="command"><strong>Randomization is not a
shortcut</strong></span><p>
+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li
class="listitem"><span class="command"><strong>Evaluation and measurement
difficulties</strong></span><p>
+
+The fact that randomization causes behaviors to differ slightly with every
+site visit makes it appealing at first glance, but this same property makes it
+very difficult to objectively measure its effectiveness. By contrast, an
+implementation that strives for uniformity is very simple to evaluate. Despite
+their current flaws, a properly designed version of <a class="ulink"
href="https://panopticlick.eff.org/"; target="_top">Panopticlick</a> or <a
class="ulink" href="https://amiunique.org/"; target="_top">Am I Unique</a> could
report the entropy and
+uniqueness rates for all users of a single user agent version, without the
+need for complicated statistics about the variance of the measured behaviors.
+
+ </p><p>
+
+Randomization (especially incomplete randomization) may also provide a false
+sense of security. When a fingerprinting attempt makes naive use of randomized
+information, a fingerprint will appear unstable, but may not actually be
+sufficiently randomized to impede a dedicated adversary. Sophisticated
+fingerprinting mechanisms may either ignore randomized information, or
+incorporate knowledge of the distribution and range of randomized values into
+the creation of a more stable fingerprint (by either removing the randomness,
+modeling it, or averaging it out).
+
+ </p></li><li class="listitem"><span
class="command"><strong>Randomization is not a shortcut</strong></span><p>
While many end-user configuration details that the browser currently exposes
may be safely replaced by false information, randomization of these details
@@ -1153,28 +1182,7 @@ multiple reimplementations of the underlying operating
system functionality to
ensure that every operating system version is covered by the range of possible
behaviors.
- </p></li><li class="listitem"><span class="command"><strong>Evaluation
and measurement difficulties</strong></span><p>
-
-The fact that randomization causes behaviors to differ slightly with every
-site visit makes it appealing at first glance, but this same property makes it
-very difficult to objectively measure its effectiveness. By contrast, an
-implementation that strives for uniformity is very simple to measure. Despite
-their current flaws, a properly designed version of <a class="ulink"
href="https://panopticlick.eff.org/"; target="_top">Panopticlick</a> or <a
class="ulink" href="https://amiunique.org/"; target="_top">Am I Unique</a> could
report the entropy and
-uniqueness rates for all users of a single user agent version, without the
-need for complicated statistics about the variance of the measured behaviors.
-
- </p><p>
-
-Randomization (especially incomplete randomization) may also provide a false
-sense of security. When a fingerprinting attempt makes naive use of randomized
-information, a fingerprint will appear unstable, but may not actually be
-sufficiently randomized to prevent a dedicated adversary. Sophisticated
-fingerprinting mechanisms may either ignore randomized information, or
-incorporate knowledge of the distribution and range of randomized values into
-the creation of a more stable fingerprint (by either removing the randomness,
-modeling it, or averaging it out).
-
- </p></li><li class="listitem"><span class="command"><strong>Usability
issues</strong></span><p>
+ </p></li><li class="listitem"><span class="command"><strong>Usability
issues</strong></span><p>
When randomization is introduced to features that affect site behavior, it can
be very distracting for this behavior to change between visits of a given
@@ -1591,11 +1599,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="idp56156768"></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="idp70103376"></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="idp56158016"></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="idp70104624"></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/nsIDocShell#Attributes";
target="_top">browser.docShell.allowJavascript</a>
@@ -1694,7 +1702,7 @@ images (<span
class="command"><strong>svg.in-content.enabled</strong></span>).
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="idp56192352"></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="idp70138960"></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
@@ -1716,7 +1724,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="idp56199248"></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="idp70145856"></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/commit/?h=tor-browser-31.6.0esr-4.5-1&id=20a59cec9886cf2575b1fd8e92b43e31ba053fbd";
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
@@ -1781,7 +1789,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="idp56215504"></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="idp70162016"></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
@@ -1892,7 +1900,7 @@ but differs under LXC. We are also investigating currently
<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="idp56237264"></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="idp70184144"></a>5.2.Â
Package Signatures and Verification</h3></div></div></div><p>
The build process generates a single sha256sums.txt file that contains a sorted
list of the SHA-256 hashes of every package produced for that build version.
Each
@@ -1925,7 +1933,7 @@ In order to verify package integrity, the signature must
be stripped off using
the osslsigncode tool, as described on the <a class="ulink"
href="https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification";
target="_top">Signature
Verification</a> page.
- </p></div><div class="sect2"><div class="titlepage"><div><div><h3
class="title"><a id="idp56241792"></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="idp70188672"></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
@@ -2054,7 +2062,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="idp56278768"></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="idp70225312"></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
_______________________________________________
tor-commits mailing list
[email protected]
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits
