Mike Perry commited on 2015-05-07 00:12:28
Zeige 1 geänderte Dateien mit 77 Einfügungen und 69 Löschungen.
... | ... |
@@ -1,5 +1,5 @@ |
1 | 1 |
<?xml version="1.0" encoding="UTF-8"?> |
2 |
-<!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="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>></code></p></div></div></div></div><div><p class="pubdate">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></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#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> |
|
2 |
+<!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="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>></code></p></div></div></div></div><div><p class="pubdate">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></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#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> |
|
3 | 3 |
|
4 | 4 |
This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>, |
5 | 5 |
<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 |
655 | 655 |
disabled, which prevents Flash cookies from leaking from a pre-existing Flash |
656 | 656 |
directory. |
657 | 657 |
|
658 |
- </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"> |
|
658 |
+ </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"> |
|
659 | 659 |
|
660 | 660 |
The User Agent MUST (at user option) prevent all disk records of browser activity. |
661 | 661 |
The user should be able to optionally enable URL history and other history |
662 | 662 |
features if they so desire. |
663 | 663 |
|
664 |
- </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"> |
|
664 |
+ </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"> |
|
665 | 665 |
|
666 | 666 |
We achieve this goal through several mechanisms. First, we set the Firefox |
667 | 667 |
Private Browsing preference |
... | ... |
@@ -733,7 +733,7 @@ the URL bar origin for which browser state exists, possibly with a |
733 | 733 |
context-menu option to drill down into specific types of state or permissions. |
734 | 734 |
An example of this simplification can be seen in Figure 1. |
735 | 735 |
|
736 |
- </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> |
|
736 |
+ </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> |
|
737 | 737 |
|
738 | 738 |
This example UI is a mock-up of how isolating identifiers to the URL bar |
739 | 739 |
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 |
741 | 741 |
privacy window can represent browsing history, DOM Storage, HTTP Auth, search |
742 | 742 |
form history, login values, and so on within a context menu for each site. |
743 | 743 |
|
744 |
-</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> |
|
744 |
+</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> |
|
745 | 745 |
|
746 | 746 |
Unfortunately, many aspects of browser state can serve as identifier storage, |
747 | 747 |
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 |
953 | 953 |
</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> |
954 | 954 |
|
955 | 955 |
Browser fingerprinting is the act of inspecting browser behaviors and features in |
956 |
-an attempt to differentiate and track individual users. Fingerprinting attacks |
|
957 |
-are typically broken up into passive and active vectors. Passive |
|
958 |
-fingerprinting makes use of any information the browser provides automatically |
|
959 |
-to a website without any specific action on the part of the website. Active |
|
960 |
-fingerprinting makes use of any information that can be extracted from the |
|
961 |
-browser by some specific website action, usually involving Javascript. |
|
962 |
-Some definitions of browser fingerprinting also include supercookies and |
|
963 |
-cookie-like identifier storage, but we deal with those issues separately in |
|
964 |
-the <a class="link" href="#identifier-linkability" title="4.5. Cross-Origin Identifier Unlinkability">preceding section on identifier |
|
965 |
-linkability</a>. |
|
966 |
- |
|
956 |
+an attempt to differentiate and track individual users. |
|
967 | 957 |
</p><p> |
968 | 958 |
|
959 |
+Fingerprinting attacks are typically broken up into passive and active |
|
960 |
+vectors. Passive fingerprinting makes use of any information the browser |
|
961 |
+provides automatically to a website without any specific action on the part of |
|
962 |
+the website. Active fingerprinting makes use of any information that can be |
|
963 |
+extracted from the browser by some specific website action, usually involving |
|
964 |
+Javascript. Some definitions of browser fingerprinting also include |
|
965 |
+supercookies and cookie-like identifier storage, but we deal with those issues |
|
966 |
+separately in the <a class="link" href="#identifier-linkability" title="4.5. Cross-Origin Identifier Unlinkability">preceding section on |
|
967 |
+identifier linkability</a>. |
|
968 |
+ </p><p> |
|
969 | 969 |
For the most part, however, we do not differentiate between passive or active |
970 | 970 |
fingerprinting sources, since many active fingerprinting mechanisms are very |
971 | 971 |
rapid, and can be obfuscated or disguised as legitimate functionality. |
972 |
+ |
|
973 |
+ </p><p> |
|
974 |
+ |
|
972 | 975 |
Instead, we believe fingerprinting can only be rationally addressed if we |
973 | 976 |
understand where the problem comes from, what sources of issues are the most |
974 |
-severe, and how to study the efficacy of defenses properly. |
|
977 |
+severe, what types of defenses are suitable for which sources, and have a |
|
978 |
+consistent strategy for designing defenses that maximizes our ability to study |
|
979 |
+defense efficacy. The following subsections address these issues from a high |
|
980 |
+level, and we then conclude with a list of our current specific defenses. |
|
975 | 981 |
|
976 | 982 |
</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> |
977 | 983 |
|
... | ... |
@@ -995,9 +1001,10 @@ identify a user. We believe it is essential to avoid exposing platform |
995 | 1001 |
configuration details to website content at all costs. We also discourage |
996 | 1002 |
excessive fine-grained customization of Tor Browser by minimizing and |
997 | 1003 |
aggregating user-facing privacy and security options, as well as by |
998 |
-discouraging the use of additional addons. When it is necessary to expose |
|
999 |
-configuration details in the course of providing functionality, we strive to |
|
1000 |
-do so only on a per-site basis via site permissions, to avoid linkability. |
|
1004 |
+discouraging the use of additional plugins and addons. When it is necessary to |
|
1005 |
+expose configuration details in the course of providing functionality, we |
|
1006 |
+strive to do so only on a per-site basis via site permissions, to avoid |
|
1007 |
+linkability. |
|
1001 | 1008 |
|
1002 | 1009 |
</p></li><li class="listitem"><span class="command"><strong>Device and Hardware Characteristics</strong></span><p> |
1003 | 1010 |
|
... | ... |
@@ -1006,9 +1013,9 @@ be reported explicitly by the browser, they can be inferred through browser |
1006 | 1013 |
functionality, or they can be extracted through statistical measurements of |
1007 | 1014 |
system performance. We are most concerned with the cases where this |
1008 | 1015 |
information is either directly reported or can be determined via a single use |
1009 |
-of an API or feature, and prefer to place such APIs either behind site |
|
1010 |
-permissions, alter their functionality to prevent exposing the most variable |
|
1011 |
-aspects of these characteristics, or disable them entirely. |
|
1016 |
+of an API or feature, and prefer to either alter functionality to prevent |
|
1017 |
+exposing the most variable aspects of these characteristics, place such |
|
1018 |
+features behind site permissions, or disable them entirely. |
|
1012 | 1019 |
|
1013 | 1020 |
</p><p> |
1014 | 1021 |
|
... | ... |
@@ -1040,7 +1047,7 @@ fingerprinted through their behavior while interacting with a website. This |
1040 | 1047 |
behavior includes e.g. keystrokes, mouse movements, click speed, and writing |
1041 | 1048 |
style. Basic vectors such as keystroke and mouse usage fingerprinting can be |
1042 | 1049 |
mitigated by altering Javascript's notion of time. More advanced issues like |
1043 |
-writing style fingerprinting are the domain of <a class="ulink" href="https://github.com/psal/anonymouth" target="_top">other tools</a>. |
|
1050 |
+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>. |
|
1044 | 1051 |
|
1045 | 1052 |
</p></li><li class="listitem"><span class="command"><strong>Browser Vendor and Version Differences</strong></span><p> |
1046 | 1053 |
|
... | ... |
@@ -1063,9 +1070,10 @@ defenses for APIs that have already been standardized and deployed. Once an |
1063 | 1070 |
API or feature has been standardized and widely deployed, defenses to the |
1064 | 1071 |
associated fingerprinting issues tend to have only a few options available to |
1065 | 1072 |
compensate for the lack of up-front privacy design. In our experience, so far |
1066 |
-these options have been limited to value spoofing, subsystem reimplementation, |
|
1067 |
-virtualization, site permissions, and feature removal. We will now describe |
|
1068 |
-these options and the fingerprinting sources they tend to work best with. |
|
1073 |
+these options have been limited to value spoofing, subsystem modification or |
|
1074 |
+reimplementation, virtualization, site permissions, and feature removal. We |
|
1075 |
+will now describe these options and the fingerprinting sources they tend to |
|
1076 |
+work best with. |
|
1069 | 1077 |
|
1070 | 1078 |
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Value Spoofing</strong></span><p> |
1071 | 1079 |
|
... | ... |
@@ -1075,17 +1083,17 @@ or operating system directly to a website. It becomes less useful when the |
1075 | 1083 |
fingerprinting method relies on behavior to infer aspects of the hardware or |
1076 | 1084 |
operating system, rather than obtain them directly. |
1077 | 1085 |
|
1078 |
- </p></li><li class="listitem"><span class="command"><strong>Subsystem Reimplementation</strong></span><p> |
|
1086 |
+ </p></li><li class="listitem"><span class="command"><strong>Subsystem Modification or Reimplementation</strong></span><p> |
|
1079 | 1087 |
|
1080 | 1088 |
In cases where simple spoofing is not enough to properly conceal underlying |
1081 |
-device characteristics or operating system details, the underlying |
|
1082 |
-subsystem that provides the functionality for a feature or API may need |
|
1083 |
-to be completely reimplemented. This is most common in cases where |
|
1084 |
-customizable or version-specific aspects of the user's operating system are |
|
1085 |
-visible through the browser's featureset or APIs, usually because the browser |
|
1086 |
-directly exposes OS-provided implementations of underlying features. In these |
|
1087 |
-cases, such OS-provided implementations must be replaced by a generic |
|
1088 |
-implementation, or at least an implementation wrapper that makes effort to |
|
1089 |
+device characteristics or operating system details, the underlying subsystem |
|
1090 |
+that provides the functionality for a feature or API may need to be modified |
|
1091 |
+or completely reimplemented. This is most common in cases where customizable |
|
1092 |
+or version-specific aspects of the user's operating system are visible through |
|
1093 |
+the browser's featureset or APIs, usually because the browser directly exposes |
|
1094 |
+OS-provided implementations of underlying features. In these cases, such |
|
1095 |
+OS-provided implementations must be replaced by a generic implementation, or |
|
1096 |
+at least modified by an implementation wrapper layer that makes effort to |
|
1089 | 1097 |
conceal any user-customized aspects of the system. |
1090 | 1098 |
|
1091 | 1099 |
</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 |
1116 | 1124 |
the same task, these features and/or certain aspects of their functionality |
1117 | 1125 |
may be simply removed. |
1118 | 1126 |
|
1119 |
- </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> |
|
1127 |
+ </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> |
|
1120 | 1128 |
|
1121 | 1129 |
When applying a form of defense to a specific fingerprinting vector or source, |
1122 |
-there are two general strategies available. Either the implementation for all |
|
1130 |
+there are two general strategies available: either the implementation for all |
|
1123 | 1131 |
users of a single browser version can be made to behave as uniformly as |
1124 |
-possible, or the user agent can attempt to randomize its behavior, so that |
|
1132 |
+possible, or the user agent can attempt to randomize its behavior so that |
|
1125 | 1133 |
each interaction between a user and a site provides a different fingerprint. |
1126 | 1134 |
|
1127 | 1135 |
</p><p> |
... | ... |
@@ -1131,7 +1139,28 @@ research suggests</a> that randomization can be effective, so far striving |
1131 | 1139 |
for uniformity has generally proved to be a better strategy for Tor Browser |
1132 | 1140 |
for the following reasons: |
1133 | 1141 |
|
1134 |
- </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Randomization is not a shortcut</strong></span><p> |
|
1142 |
+ </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Evaluation and measurement difficulties</strong></span><p> |
|
1143 |
+ |
|
1144 |
+The fact that randomization causes behaviors to differ slightly with every |
|
1145 |
+site visit makes it appealing at first glance, but this same property makes it |
|
1146 |
+very difficult to objectively measure its effectiveness. By contrast, an |
|
1147 |
+implementation that strives for uniformity is very simple to evaluate. Despite |
|
1148 |
+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 |
|
1149 |
+uniqueness rates for all users of a single user agent version, without the |
|
1150 |
+need for complicated statistics about the variance of the measured behaviors. |
|
1151 |
+ |
|
1152 |
+ </p><p> |
|
1153 |
+ |
|
1154 |
+Randomization (especially incomplete randomization) may also provide a false |
|
1155 |
+sense of security. When a fingerprinting attempt makes naive use of randomized |
|
1156 |
+information, a fingerprint will appear unstable, but may not actually be |
|
1157 |
+sufficiently randomized to impede a dedicated adversary. Sophisticated |
|
1158 |
+fingerprinting mechanisms may either ignore randomized information, or |
|
1159 |
+incorporate knowledge of the distribution and range of randomized values into |
|
1160 |
+the creation of a more stable fingerprint (by either removing the randomness, |
|
1161 |
+modeling it, or averaging it out). |
|
1162 |
+ |
|
1163 |
+ </p></li><li class="listitem"><span class="command"><strong>Randomization is not a shortcut</strong></span><p> |
|
1135 | 1164 |
|
1136 | 1165 |
While many end-user configuration details that the browser currently exposes |
1137 | 1166 |
may be safely replaced by false information, randomization of these details |
... | ... |
@@ -1153,27 +1182,6 @@ multiple reimplementations of the underlying operating system functionality to |
1153 | 1182 |
ensure that every operating system version is covered by the range of possible |
1154 | 1183 |
behaviors. |
1155 | 1184 |
|
1156 |
- </p></li><li class="listitem"><span class="command"><strong>Evaluation and measurement difficulties</strong></span><p> |
|
1157 |
- |
|
1158 |
-The fact that randomization causes behaviors to differ slightly with every |
|
1159 |
-site visit makes it appealing at first glance, but this same property makes it |
|
1160 |
-very difficult to objectively measure its effectiveness. By contrast, an |
|
1161 |
-implementation that strives for uniformity is very simple to measure. Despite |
|
1162 |
-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 |
|
1163 |
-uniqueness rates for all users of a single user agent version, without the |
|
1164 |
-need for complicated statistics about the variance of the measured behaviors. |
|
1165 |
- |
|
1166 |
- </p><p> |
|
1167 |
- |
|
1168 |
-Randomization (especially incomplete randomization) may also provide a false |
|
1169 |
-sense of security. When a fingerprinting attempt makes naive use of randomized |
|
1170 |
-information, a fingerprint will appear unstable, but may not actually be |
|
1171 |
-sufficiently randomized to prevent a dedicated adversary. Sophisticated |
|
1172 |
-fingerprinting mechanisms may either ignore randomized information, or |
|
1173 |
-incorporate knowledge of the distribution and range of randomized values into |
|
1174 |
-the creation of a more stable fingerprint (by either removing the randomness, |
|
1175 |
-modeling it, or averaging it out). |
|
1176 |
- |
|
1177 | 1185 |
</p></li><li class="listitem"><span class="command"><strong>Usability issues</strong></span><p> |
1178 | 1186 |
|
1179 | 1187 |
When randomization is introduced to features that affect site behavior, it can |
... | ... |
@@ -1591,11 +1599,11 @@ In order to avoid long-term linkability, we provide a "New Identity" context |
1591 | 1599 |
menu option in Torbutton. This context menu option is active if Torbutton can |
1592 | 1600 |
read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT. |
1593 | 1601 |
|
1594 |
- </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"> |
|
1602 |
+ </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"> |
|
1595 | 1603 |
|
1596 | 1604 |
All linkable identifiers and browser state MUST be cleared by this feature. |
1597 | 1605 |
|
1598 |
- </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> |
|
1606 |
+ </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> |
|
1599 | 1607 |
|
1600 | 1608 |
First, Torbutton disables Javascript in all open tabs and windows by using |
1601 | 1609 |
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>). |
1694 | 1702 |
Fingerprinting</a> is a statistical attack to attempt to recognize specific |
1695 | 1703 |
encrypted website activity. |
1696 | 1704 |
|
1697 |
- </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> |
|
1705 |
+ </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> |
|
1698 | 1706 |
|
1699 | 1707 |
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 |
1700 | 1708 |
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 |
1716 | 1724 |
defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor |
1717 | 1725 |
network, making them also effectively no-overhead. |
1718 | 1726 |
|
1719 |
- </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> |
|
1727 |
+ </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> |
|
1720 | 1728 |
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 |
1721 | 1729 |
pipeline order and depth</a>. Unfortunately, pipelining is very fragile. |
1722 | 1730 |
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 |
1781 | 1789 |
that allows anyone to use our source code to reproduce byte-for-byte identical |
1782 | 1790 |
binary packages to the ones that we distribute. |
1783 | 1791 |
|
1784 |
- </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> |
|
1792 |
+ </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> |
|
1785 | 1793 |
|
1786 | 1794 |
The GNU toolchain has been working on providing reproducible builds for some |
1787 | 1795 |
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 |
1892 | 1900 |
<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/12240" target="_top">oddities related to |
1893 | 1901 |
time-based dependency tracking</a> that only appear in LXC containers. |
1894 | 1902 |
|
1895 |
- </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> |
|
1903 |
+ </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> |
|
1896 | 1904 |
|
1897 | 1905 |
The build process generates a single sha256sums.txt file that contains a sorted |
1898 | 1906 |
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 |
1925 | 1933 |
the osslsigncode tool, as described on the <a class="ulink" href="https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification" target="_top">Signature |
1926 | 1934 |
Verification</a> page. |
1927 | 1935 |
|
1928 |
- </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> |
|
1936 |
+ </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> |
|
1929 | 1937 |
|
1930 | 1938 |
Due to the fact that bit-identical packages can be produced by anyone, the |
1931 | 1939 |
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 |
2054 | 2062 |
ourselves</a>, as they are comparatively rare and can be handled with site |
2055 | 2063 |
permissions. |
2056 | 2064 |
|
2057 |
- </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> |
|
2065 |
+ </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> |
|
2058 | 2066 |
|
2059 | 2067 |
Web-Send is a browser-based link sharing and federated login widget that is |
2060 | 2068 |
designed to operate without relying on third-party tracking or abusing other |
2061 | 2069 |