May 2015 - tor-commits - lists.torproject.org

[tor-browser/tor-browser-31.6.0esr-4.5-1] fixup! Bug #3455.2. Allow RFC1929 authentication (username/password) to SOCKS servers.
by mikeperry＠torproject.org 07 May '15

07 May '15

commit f259a80f3ee5a51e9826cdd1979d19a1f3943897 Author: Nicolas Vigier <boklm(a)torproject.org> Date: Mon May 4 16:55:15 2015 +0200 fixup! Bug #3455.2. Allow RFC1929 authentication (username/password) to SOCKS servers. Remove unused variables proxyHost and proxyPort to fix unused-but-set-variable build errors. --- netwerk/base/src/nsSocketTransport2.cpp | 4 ---- 1 file changed, 4 deletions(-) diff --git a/netwerk/base/src/nsSocketTransport2.cpp b/netwerk/base/src/nsSocketTransport2.cpp index baa14da..658f2e0 100644 --- a/netwerk/base/src/nsSocketTransport2.cpp +++ b/netwerk/base/src/nsSocketTransport2.cpp @@ -1080,8 +1080,6 @@ nsSocketTransport::BuildSocket(PRFileDesc *&fd, bool &proxyTransparent, bool &us const char *host = mHost.get(); int32_t port = (int32_t) mPort; - const char *proxyHost = mProxyHost.IsEmpty() ? nullptr : mProxyHost.get(); - int32_t proxyPort = (int32_t) mProxyPort; uint32_t proxyFlags = 0; nsCOMPtr<nsIProxyInfo> proxyInfo = mProxyInfo; @@ -1154,8 +1152,6 @@ nsSocketTransport::BuildSocket(PRFileDesc *&fd, bool &proxyTransparent, bool &us // since socks is transparent, any layers above // it do not have to worry about proxy stuff proxyInfo = nullptr; - proxyHost = nullptr; - proxyPort = -1; proxyTransparent = true; } }

1 0

[tor-browser/tor-browser-31.6.0esr-4.5-1] Bug 15857: Fix file descriptor leak in updater.
by mikeperry＠torproject.org 07 May '15

07 May '15

commit a8348a29adac38d64625fce35baba7684fef3fcd Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed May 6 20:11:40 2015 -0700 Bug 15857: Fix file descriptor leak in updater. Corresponds to Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1159826. --- toolkit/mozapps/update/updater/updater.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/toolkit/mozapps/update/updater/updater.cpp b/toolkit/mozapps/update/updater/updater.cpp index 3ba92b3..89f12ec 100644 --- a/toolkit/mozapps/update/updater/updater.cpp +++ b/toolkit/mozapps/update/updater/updater.cpp @@ -799,7 +799,7 @@ static int ensure_copy_recursive(const NS_tchar *path, const NS_tchar *dest, } } } - + NS_tclosedir(dir); return rv; }

1 0

[tor-browser/tor-browser-31.6.0esr-4.5-1] fixup! Bug #15502. Isolate blob URLs to first party; no blobURLs in Web Workers
by mikeperry＠torproject.org 07 May '15

07 May '15

commit 15bf754badd65bccc1ea898324392a4d34a8e97e Author: Arthur Edelstein <arthuredelstein(a)gmail.com> Date: Fri May 1 14:49:58 2015 -0700 fixup! Bug #15502. Isolate blob URLs to first party; no blobURLs in Web Workers --- browser/extensions/pdfjs/content/build/pdf.worker.js | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/browser/extensions/pdfjs/content/build/pdf.worker.js b/browser/extensions/pdfjs/content/build/pdf.worker.js index a8779ab..805cc66 100644 --- a/browser/extensions/pdfjs/content/build/pdf.worker.js +++ b/browser/extensions/pdfjs/content/build/pdf.worker.js @@ -1048,7 +1048,14 @@ PDFJS.createObjectURL = (function createObjectURLClosure() { if (!PDFJS.disableCreateObjectURL && typeof URL !== 'undefined' && URL.createObjectURL) { var blob = PDFJS.createBlob(data, contentType); - return URL.createObjectURL(blob); + try { + return URL.createObjectURL(blob); + } catch(e) { + // URL.createObjectURL has thrown an error; continue to + // data schema fallback. + // TODO: Remove this try-catch when we re-enable + // createObjectURL in workers. + } } var buffer = 'data:' + contentType + ';base64,';

1 0

[tor-browser/tor-browser-31.6.0esr-4.5-1] Merge remote-tracking branch 'arthur/15899' into tor-browser-31.6.0esr-4.5-1
by mikeperry＠torproject.org 07 May '15

07 May '15

commit 31c6bfb7ef8eb79fe526ceaece91d6236f8cdd8a Merge: 3006aa5 15bf754 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed May 6 19:42:54 2015 -0700 Merge remote-tracking branch 'arthur/15899' into tor-browser-31.6.0esr-4.5-1 browser/extensions/pdfjs/content/build/pdf.worker.js | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)

1 0

[tor-browser-bundle/master] Bug 15945: Disable NoScript's ClearClick protection for now.
by mikeperry＠torproject.org 07 May '15

07 May '15

commit a9619e0a54d7c134325ad5a9496ffc67d07b0dcf Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed May 6 18:56:45 2015 -0700 Bug 15945: Disable NoScript's ClearClick protection for now. Bug #14985 has analysis toward a more complete fix for enabling it. --- .../Data/Browser/profile.default/preferences/extension-overrides.js | 1 + .../Data/Browser/profile.default/preferences/extension-overrides.js | 1 + .../Data/Browser/profile.default/preferences/extension-overrides.js | 1 + 3 files changed, 3 insertions(+) diff --git a/Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js b/Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js index d1469a8..7a95619 100644 --- a/Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js +++ b/Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js @@ -61,3 +61,4 @@ pref("noscript.cascadePermissions", true); pref("noscript.restrictSubdocScripting", true); pref("noscript.showVolatilePrivatePermissionsToggle", false); pref("noscript.volatilePrivatePermissions", true); +pref("noscript.clearClick", 0); diff --git a/Bundle-Data/mac/TorBrowser/Data/Browser/profile.default/preferences/extension-overrides.js b/Bundle-Data/mac/TorBrowser/Data/Browser/profile.default/preferences/extension-overrides.js index d1469a8..7a95619 100644 --- a/Bundle-Data/mac/TorBrowser/Data/Browser/profile.default/preferences/extension-overrides.js +++ b/Bundle-Data/mac/TorBrowser/Data/Browser/profile.default/preferences/extension-overrides.js @@ -61,3 +61,4 @@ pref("noscript.cascadePermissions", true); pref("noscript.restrictSubdocScripting", true); pref("noscript.showVolatilePrivatePermissionsToggle", false); pref("noscript.volatilePrivatePermissions", true); +pref("noscript.clearClick", 0); diff --git a/Bundle-Data/windows/Data/Browser/profile.default/preferences/extension-overrides.js b/Bundle-Data/windows/Data/Browser/profile.default/preferences/extension-overrides.js index fb2141b..976d71c 100644 --- a/Bundle-Data/windows/Data/Browser/profile.default/preferences/extension-overrides.js +++ b/Bundle-Data/windows/Data/Browser/profile.default/preferences/extension-overrides.js @@ -61,3 +61,4 @@ pref("noscript.cascadePermissions", true); pref("noscript.restrictSubdocScripting", true); pref("noscript.showVolatilePrivatePermissionsToggle", false); pref("noscript.volatilePrivatePermissions", true); +pref("noscript.clearClick", 0);

1 0

[webwml/master] One more TBB design doc update..
by mikeperry＠torproject.org 06 May '15

06 May '15

commit f344776616227f3e490969038aaaad991a464e1d Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed May 6 15:32:08 2015 -0700 One more TBB design doc update.. --- projects/torbrowser/design/index.html.en | 50 ++++++++++++++++++------------ 1 file changed, 30 insertions(+), 20 deletions(-) diff --git a/projects/torbrowser/design/index.html.en b/projects/torbrowser/design/index.html.en index c017f4e..9ba583d 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="#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> +<!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="#idp53435264">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="#idp55327360">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp55349120">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp55353648">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="#idp55389664">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="idp53435264"></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="idp66184288"></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="idp55029872"></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="idp66185680"></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="idp55031232"></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="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> + </p><div class="figure"><a id="idp55052928"></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="idp69892352"></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="idp55056352"></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 @@ -1124,7 +1124,7 @@ 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="idp69985904"></a>Strategies for Defense: Randomization versus Uniformity</h4></div></div></div><p> + </p></li></ol></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp55149888"></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 @@ -1298,7 +1298,9 @@ these requests are still sent by 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. Access to the local network is forbidden via the same -mechanism. +mechanism. We also disable the WebRTC API as mentioned previously, since even +if it were usable over Tor, it still currently provides the local IP address +and associated network information to websites. </p></li><li class="listitem"><span class="command"><strong>Invasive Authentication Mechanisms (NTLM and SPNEGO)</strong></span><p> @@ -1311,15 +1313,23 @@ 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"><span class="command"><strong>USB Device ID Enumeration</strong></span><p> + </p></li><li class="listitem"><span class="command"><strong>USB Device ID Enumeration via the GamePad API</strong></span><p> The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/API/Gamepad" target="_top">GamePad API</a> provides web pages with the <a class="ulink" href="https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html#widl-Gamepad-id" target="_top">USB device id, product id, and driver name</a> of all connected game -controllers, as well as detailed information about their capabilities. This API -should be behind a site permission in Private Browsing Modes, or should present a generic -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>. +controllers, as well as detailed information about their capabilities. + </p><p> + +It's our opinion that this API needs to be completely redesigned to provide an +abstract notion of a game controller rather than offloading all of the +complexity associated with handling specific game controller models to web +content authors. For systems without a game controller, a standard controller +can be virtualized through the keyboard, which will serve to both improve +usability by normalizing user interaction with different games, as well as +eliminate fingerprinting vectors. Barring that, this API should be behind a +site permission in Private Browsing Modes. For now though, we simply disable +it via the pref <span class="command"><strong>dom.gamepad.enabled</strong></span>. </p></li><li class="listitem"><span class="command"><strong>Fonts</strong></span><p> @@ -1599,11 +1609,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="idp70103376"></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="idp55268352"></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="idp70104624"></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="idp55269600"></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> @@ -1702,7 +1712,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="idp70138960"></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="idp55303936"></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 @@ -1724,7 +1734,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="idp70145856"></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="idp55310832"></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.0e…" 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 @@ -1789,7 +1799,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="idp70162016"></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="idp55327360"></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 @@ -1900,7 +1910,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="idp70184144"></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="idp55349120"></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 @@ -1933,7 +1943,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#BuildVerificat…" target="_top">Signature Verification</a> page. - </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> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp55353648"></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 @@ -2062,7 +2072,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="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> + </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp55389664"></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] Clarify GamePad API and Local Network defenses.
by mikeperry＠torproject.org 06 May '15

06 May '15

commit d989edc6c0e130869afe9c3253f65abfee079317 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed May 6 15:31:15 2015 -0700 Clarify GamePad API and Local Network defenses. --- design-doc/design.xml | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/design-doc/design.xml b/design-doc/design.xml index 8b77248..4ea0bff 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -1897,7 +1897,9 @@ these requests are still sent by Firefox to our SOCKS proxy (ie we set <command>network.proxy.no_proxies_on</command> to the empty string). The local Tor client then rejects them, since it is configured to proxy for internal IP addresses by default. Access to the local network is forbidden via the same -mechanism. +mechanism. We also disable the WebRTC API as mentioned previously, since even +if it were usable over Tor, it still currently provides the local IP address +and associated network information to websites. </para> @@ -1916,7 +1918,7 @@ placed behind a site permission before their use. We simply disable them. </para> </listitem> - <listitem><command>USB Device ID Enumeration</command> + <listitem><command>USB Device ID Enumeration via the GamePad API</command> <para> The <ulink @@ -1924,10 +1926,19 @@ url="https://developer.mozilla.org/en-US/docs/Web/Guide/API/Gamepad">GamePad API</ulink> provides web pages with the <ulink url="https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html#widl-Gamepad-id">USB device id, product id, and driver name</ulink> of all connected game -controllers, as well as detailed information about their capabilities. This API -should be behind a site permission in Private Browsing Modes, or should present a generic -controller type (perhaps a two button controller that can be mapped to the keyboard) in all cases. -We simply disable it via the pref <command>dom.gamepad.enabled</command>. +controllers, as well as detailed information about their capabilities. + </para> + <para> + +It's our opinion that this API needs to be completely redesigned to provide an +abstract notion of a game controller rather than offloading all of the +complexity associated with handling specific game controller models to web +content authors. For systems without a game controller, a standard controller +can be virtualized through the keyboard, which will serve to both improve +usability by normalizing user interaction with different games, as well as +eliminate fingerprinting vectors. Barring that, this API should be behind a +site permission in Private Browsing Modes. For now though, we simply disable +it via the pref <command>dom.gamepad.enabled</command>. </para> </listitem>

1 0

[webwml/master] More Tor Browser design doc updates.
by mikeperry＠torproject.org 06 May '15

06 May '15

commit 49483860c8da51059039e2b2b6129128f32a1e72 Author: Mike Perry <mikeperry-git(a)torproject.org> 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/nsIDocSh…" 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.0e…" 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#BuildVerificat…" 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

1 0

[tor-browser-spec/master] Some structural improvements to the fingerprinting section.
by mikeperry＠torproject.org 06 May '15

06 May '15

commit 75fe855aaf76029bb849ee4f2d80fc7b3c39740b Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed May 6 15:09:47 2015 -0700 Some structural improvements to the fingerprinting section. --- design-doc/design.xml | 134 ++++++++++++++++++++++++++----------------------- 1 file changed, 72 insertions(+), 62 deletions(-) diff --git a/design-doc/design.xml b/design-doc/design.xml index c43e4e5..8b77248 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -1449,26 +1449,34 @@ url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability&am <para> 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 <link linkend="identifier-linkability">preceding section on identifier -linkability</link>. +an attempt to differentiate and track individual users. + </para> + <para> - </para> +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 <link linkend="identifier-linkability">preceding section on +identifier linkability</link>. + </para> <para> - 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. + + </para> + <para> + 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. </para> @@ -1500,9 +1508,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. </para> </listitem> @@ -1514,9 +1523,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. </para> <para> @@ -1556,7 +1565,7 @@ 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 <ulink -url="https://github.com/psal/anonymouth">other tools</ulink>. +url="https://github.com/psal/anonymouth/blob/master/README.md">other tools</ulink>. </para> </listitem> @@ -1590,9 +1599,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. </para> <orderedlist> @@ -1607,18 +1617,18 @@ operating system, rather than obtain them directly. </para> </listitem> - <listitem><command>Subsystem Reimplementation</command> + <listitem><command>Subsystem Modification or Reimplementation</command> <para> 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. </para> @@ -1663,13 +1673,13 @@ may be simply removed. </orderedlist> </sect3> <sect3> - <title>Randomization or Uniformity?</title> + <title>Strategies for Defense: Randomization versus Uniformity</title> <para> 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. </para> @@ -1683,6 +1693,33 @@ for the following reasons: </para> <orderedlist> + <listitem><command>Evaluation and measurement difficulties</command> + <para> + +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 <ulink +url="https://panopticlick.eff.org/">Panopticlick</ulink> or <ulink +url="https://amiunique.org/">Am I Unique</ulink> 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. + + </para> + <para> + +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). + + </para> + </listitem> <listitem><command>Randomization is not a shortcut</command> <para> @@ -1709,33 +1746,6 @@ behaviors. </para> </listitem> - <listitem><command>Evaluation and measurement difficulties</command> - <para> - -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 <ulink -url="https://panopticlick.eff.org/">Panopticlick</ulink> or <ulink -url="https://amiunique.org/">Am I Unique</ulink> 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. - - </para> - <para> - -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). - - </para> - </listitem> <listitem><command>Usability issues</command> <para>

1 0

[webwml/master] Update Tor Browser design doc.
by mikeperry＠torproject.org 06 May '15

06 May '15

commit 2b143bac2753100c1312719048341416a7271183 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed May 6 14:00:38 2015 -0700 Update Tor Browser design doc. --- projects/torbrowser/design/index.html.en | 80 +++++++++++++++--------------- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/projects/torbrowser/design/index.html.en b/projects/torbrowser/design/index.html.en index a3c344e..ce3c916 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 5th, 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="#idp64554400">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="#idp66457392">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp66479152">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp66483680">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="#idp66520624">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="idp64554400"></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="#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> 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="idp66162928"></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="idp55920416"></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="idp66164288"></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="idp55921776"></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 @@ -719,7 +719,7 @@ isolation means that all identifier sources and browser state are scoped (isolated) using the URL bar domain. This scoping is performed in combination with any additional third party scope. When first party isolation is used with explicit identifier storage that already has a constrained third -party scope (such as cookies, DOM storage, and cache), this approach is +party scope (such as cookies and DOM storage), this approach is referred to as "double-keying". </p><p> @@ -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="idp66186000"></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="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> 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="idp66189424"></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="idp55946896"></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 @@ -1051,7 +1051,7 @@ is only possible to minimize the differences among different installations of the same browser vendor and version. We make no effort to mimic any other major browser vendor, and in fact most of our fingerprinting defenses serve to differentiate Tor Browser users from normal Firefox users. Because of this, -any study that lumps browser vendor and version differences in to its analysis +any study that lumps browser vendor and version differences into its analysis of the fingerprintability of a population is largely useless for evaluating either attacks or defenses. Unfortunately, this includes popular large-scale studies such as <a class="ulink" href="https://panopticlick.eff.org/" target="_top">Panopticlick</a> and <a class="ulink" href="https://amiunique.org/" target="_top">Am I Unique</a>. @@ -1059,11 +1059,11 @@ studies such as <a class="ulink" href="https://panopticlick.eff.org/" target="_t </p></li></ol></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-defenses-general"></a>General Fingerprinting Defenses</h4></div></div></div><p> To date, the Tor Browser team has concerned itself only with developing -defenses for APIs that have already been standardized and deployed. Once an +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 -address the lack up-front privacy design. In our experience, these options -tend to be limited to value spoofing, subsystem reimplementation, +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. @@ -1102,12 +1102,12 @@ fingerprinting vector to attain high accuracy. In the event that reimplementation or virtualization is too expensive in terms of performance or engineering effort, and the relative expected usage of a feature is rare, site permissions can be used to prevent the usage of a -feature except in cases where the user actually wishes to use it. -Unfortunately, this mechanism becomes less effective once a feature becomes -widely overused and abused by many websites, as warning fatigue quickly sets -in for most users. +feature for cross-site tracking. Unfortunately, site permissions become less +effective once a feature is already widely overused and abused by many +websites, since warning fatigue typically sets in for most users after just a +few permission requests. - </p></li><li class="listitem"><span class="command"><strong>Feature/Functionality Removal</strong></span><p> + </p></li><li class="listitem"><span class="command"><strong>Feature or Functionality Removal</strong></span><p> Due to the current bias in favor of invasive APIs that expose the maximum amount of platform information, some features and APIs are simply not @@ -1116,11 +1116,11 @@ 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="idp66282416"></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="idp56040528"></a>Randomization or Uniformity?</h4></div></div></div><p> -When applying a form of defense to a specific fingerprinting vector or source, +When applying a form of defense to a specific fingerprinting vector or source, there are two general strategies available. Either the implementation for all -users of a single browser implementation can be made to behave as uniformly as +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 each interaction between a user and a site provides a different fingerprint. @@ -1136,9 +1136,9 @@ for the following reasons: While many end-user configuration details that the browser currently exposes may be safely replaced by false information, randomization of these details must be just as exhaustive as an approach that seeks to make these behaviors -uniform. In the face of either strategy, the adversary can still make use of -those features which have not been altered to be either sufficiently uniform -or sufficiently random. +uniform. When confronting either strategy, the adversary can still make use of +any details which have not been altered to be either sufficiently uniform or +sufficiently random. </p><p> @@ -1146,12 +1146,12 @@ Furthermore, the randomization approach seems to break down when it is applied to deeper issues where underlying system functionality is directly exposed. In particular, it is not clear how to randomize the capabilities of hardware attached to a computer in such a way that it either convincingly behaves like -other hardware, or where the exact properties of the hardware that vary from -user to user are sufficiently randomized. Similarly, truly concealing operating -system version differences through randomization may require reimplementation -of the underlying operating system functionality to ensure that every version -that your randomization is trying to blend in with is covered by the range of -possible behaviors. +other hardware, or such that the exact properties of the hardware that vary +from user to user are sufficiently randomized. Similarly, truly concealing +operating system version differences through randomization may require +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> @@ -1172,16 +1172,16 @@ 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). +modeling it, or averaging it out). </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 -site. For simple cases such as when this information affects layout behavior, -this will lead to visual nuisances. However, when this information affects -reported functionality or hardware characteristics, sometimes a site will -function one way on one visit, and another way on a subsequent visit. +site. For the simplest cases, this will lead to minor visual nuisances. +However, when this information affects reported functionality or hardware +characteristics, sometimes a site will function one way on one visit, and +another way on a subsequent visit. </p></li><li class="listitem"><span class="command"><strong>Performance costs</strong></span><p> @@ -1591,11 +1591,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="idp66398752"></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="idp56156768"></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="idp66400000"></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="idp56158016"></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> @@ -1694,7 +1694,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="idp66434336"></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="idp56192352"></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 +1716,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="idp66441232"></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="idp56199248"></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.0e…" 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 +1781,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="idp66457392"></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="idp56215504"></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 +1892,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="idp66479152"></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="idp56237264"></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 +1925,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#BuildVerificat…" target="_top">Signature Verification</a> page. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp66483680"></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="idp56241792"></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 +2054,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="idp66520624"></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="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> 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