commit 4f91198cecbcf88606820d192293655f29d88976 Author: Georg Koppen gk@torproject.org Date: Tue Jan 23 20:52:04 2018 +0000
Bug 21256: Update design document for 7.0.X --- design-doc/design.xml | 750 +++++++++++++++++++++++++++++--------------------- 1 file changed, 437 insertions(+), 313 deletions(-)
diff --git a/design-doc/design.xml b/design-doc/design.xml index ad6d5f5..a52e7aa 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -29,7 +29,7 @@ <address><email>gk#torproject org</email></address> </affiliation> </author> - <pubdate>March 10th, 2017</pubdate> + <pubdate>January 23th, 2017</pubdate> </articleinfo>
<sect1> @@ -41,7 +41,7 @@ This document describes the <link linkend="adversary">adversary model</link>, linkend="Implementation">implementation</link> <!-- and <link linkend="Packaging">packaging</link> and <link linkend="Testing">testing procedures</link> --> of the Tor Browser. It is current as of Tor Browser -6.5.1. +7.0.11.
</para> <para> @@ -75,7 +75,7 @@ additionally augmented through the <ulink url="https://gitweb.torproject.org/torbutton.git/tree/">Torbutton extension</ulink>, though we are in the process of moving this functionality into direct Firefox patches. We also <ulink -url="https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-t... +url="https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-t... a number of Firefox preferences</ulink> from their defaults.
</para> @@ -93,7 +93,7 @@ To help protect against potential Tor Exit Node eavesdroppers, we include <ulink url="https://www.eff.org/https-everywhere">HTTPS-Everywhere</ulink>. To provide users with optional defense-in-depth against JavaScript and other potential exploit vectors, we also include <ulink -url="http://noscript.net/%22%3ENoScript</ulink>. We also modify <ulink +url="https://noscript.net/%22%3ENoScript</ulink>. We also modify <ulink url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js">several extension preferences</ulink> from their defaults.
@@ -105,7 +105,7 @@ blocked either by IP, or by protocol fingerprint, we include several <ulink url="https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPluggableTransports">Pluggable Transports</ulink> in the distribution. As of this writing, we include <ulink url="https://gitweb.torproject.org/pluggable-transports/obfs4.git">Obfs3proxy, -Obfs4proxy, Scramblesuit</ulink>, +Obfs4proxy</ulink>, <ulink url="https://trac.torproject.org/projects/tor/wiki/doc/meek">meek</ulink>, and <ulink url="https://fteproxy.org/">FTE</ulink>. @@ -364,7 +364,7 @@ linkability. failure of Torbutton</ulink> was the options panel. Each option that detectably alters browser behavior can be used as a fingerprinting tool. Similarly, all extensions <ulink -url="http://blog.chromium.org/2010/06/extensions-in-incognito.html%22%3Eshould be +url="https://blog.chromium.org/2010/06/extensions-in-incognito.html%22%3Eshould be disabled in the mode</ulink> except as an opt-in basis. We should not load system-wide and/or operating system provided addons or plugins.
@@ -390,22 +390,22 @@ permissions can be written to disk. Otherwise, they should remain memory-only.
Site-specific or filter-based addons such as <ulink url="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/">AdBlock -Plus</ulink>, <ulink url="http://requestpolicy.com/">Request Policy</ulink>, -<ulink url="http://www.ghostery.com/about">Ghostery</ulink>, <ulink +Plus</ulink>, <ulink url="https://requestpolicy.com/">Request Policy</ulink>, +<ulink url="https://www.ghostery.com/about-ghostery/">Ghostery</ulink>, <ulink url="http://priv3.icsi.berkeley.edu/">Priv3</ulink>, and <ulink -url="http://sharemenot.cs.washington.edu/%22%3ESharemenot</ulink> are to be +url="https://sharemenot.cs.washington.edu/%22%3ESharemenot</ulink> are to be avoided. We believe that these addons do not add any real privacy to a proper <link linkend="Implementation">implementation</link> of the above <link linkend="privacy">privacy requirements</link>, and that development efforts -should be focused on general solutions that prevent tracking by all -third parties, rather than a list of specific URLs or hosts. +should be focused on general solutions that prevent tracking by all third +parties, rather than a list of specific URLs or hosts. </para> <para> Implementing filter-based blocking directly into the browser, such as done with <ulink -url="http://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_32.pdf%... +url="https://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_32.pdf... Firefox' Tracking Protection</ulink>, does not alleviate the concerns mentioned -in the previous paragraph. There is still just a list concerned with specific +in the previous paragraph. There is still just a list containing specific URLs and hosts which, in this case, are <ulink url="https://services.disconnect.me/disconnect-plaintext.json"> assembled</ulink> by <ulink url="https://disconnect.me/trackerprotection"> @@ -421,13 +421,16 @@ would be missed and sites would be wrongly blocked. </para> <para> Filter-based solutions in general can also introduce strange breakage and cause -usability nightmares. Coping with those easily leads to just <ulink +usability nightmares. For instance, there is a trend to observe that websites +start <ulink url="https://petsymposium.org/2017/papers/issue3/paper25-2017-3-source.pdf"> +detecting filer extensions and block access to content</ulink> on them. Coping +with this fallout easily leads to just <ulink url="https://github.com/mozilla-services/shavar-list-exceptions">whitelisting </ulink> -the affected domains defeating the purpose of the filter in the first place. -Filters will also fail to do their job if an adversary simply -registers a new domain or <ulink -url="http://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_24.pdf%... +the affected domains, hoping that this helps, defeating the purpose of the +filter in the first place. Filters will also fail to do their job if an +adversary simply registers a new domain or <ulink +url="https://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_24.pdf... creates a new URL path</ulink>. Worse still, the unique filter sets that each user creates or installs will provide a wealth of fingerprinting targets. </para> @@ -735,7 +738,7 @@ Also, JavaScript can be used to query the user's timezone via the url="https://www.khronos.org/registry/webgl/specs/1.0/#5.13%22%3EWebGL</ulink> can reveal information about the video card in use, and high precision timing information can be used to <ulink -url="http://w2spconf.com/2011/papers/jspriv.pdf%22%3Efingerprint the CPU and +url="https://cseweb.ucsd.edu/~hovav/dist/jspriv.pdf%22%3Efingerprint the cpu and interpreter speed</ulink>. JavaScript features such as <ulink url="https://www.w3.org/TR/resource-timing/">Resource Timing</ulink> may leak an unknown amount of network timing related information. And, moreover, @@ -758,7 +761,7 @@ fingerprintability. Additionally, plugins are capable of extracting font lists, interface addresses, and other machine information that is beyond what the browser would normally provide to content. In addition, plugins can be used to store unique identifiers that are more difficult to clear than standard -cookies. <ulink url="http://epic.org/privacy/cookies/flash.html">Flash-based +cookies. <ulink url="https://epic.org/privacy/cookies/flash.html">Flash-based cookies</ulink> fall into this category, but there are likely numerous other examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy settings of the browser. @@ -787,9 +790,9 @@ attack would take place between the user and the Guard node, or at the Guard node itself. </para>
- <para> The most comprehensive study of the statistical properties of this + <para> The most comprehensive study of the statistical properties of this attack against Tor was done by <ulink -url="http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf%22%3EPan... +url="https://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf%22%3EPa... et al</ulink>. Unfortunately, the publication bias in academia has encouraged the production of <ulink url="https://blog.torproject.org/blog/critique-website-traffic-fingerprinting-attacks">a @@ -811,7 +814,7 @@ categories to classify</ulink> while maintaining a limit on reliable feature information you can extract, you eventually run out of descriptive feature information, and either true positive accuracy goes down or the false positive rate goes up. This error is called the <ulink -url="http://www.cs.washington.edu/education/courses/csep573/98sp/lectures/lecture... +url="https://www.cs.washington.edu/education/courses/csep573/98sp/lectures/lectur... in your hypothesis space</ulink>. In fact, even for unbiased hypothesis spaces, the number of training examples required to achieve a reasonable error bound is <ulink @@ -827,7 +830,7 @@ complexity (and thus hinder a real world adversary who attempts this attack) are large numbers of dynamically generated pages, partially cached content, and also the non-web activity of the entire Tor network. This yields an effective number of "web pages" many orders of magnitude larger than even <ulink -url="http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf%22%3EPan... +url="https://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf%22%3EPa... "Open World" scenario</ulink>, which suffered continuous near-constant decline in the true positive rate as the "Open World" size grew (see figure 4). This large level of classification complexity is further confounded by a noisy and @@ -926,7 +929,7 @@ Proxy obedience is assured through the following: <para>
Our <ulink -url="https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-t... +url="https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-t... preferences file</ulink> sets the Firefox proxy settings to use Tor directly as a SOCKS proxy. It sets <command>network.proxy.socks_remote_dns</command>, <command>network.proxy.socks_version</command>, @@ -945,12 +948,12 @@ as set the pref <command>media.peerconnection.enabled</command> to false.
We also patch Firefox in order to provide several defense-in-depth mechanisms for proxy safety. Notably, we <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2es... the DNS service</ulink> to prevent any browser or addon DNS resolution, and we -also <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=6e17cef8f3cf61fdabf99e40d5e09a730142d6cd"> +also <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=ee28d8f27fdb1e47481987535c7da70095042ee2"> remove the DNS lookup for the profile lock signature</ulink>. Furhermore, we <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2es... OCSP and PKIX code</ulink> to prevent any use of the non-proxied command-line tool utility functions from being functional while linked in to the browser. In both cases, we could find no direct paths to these routines in the browser, @@ -960,7 +963,7 @@ but it seemed better safe than sorry.
<para>
-For further defense-in-depth we disabled WebIDE because it can bypass proxy +For further defense-in-depth we disable WebIDE because it can bypass proxy settings for remote debugging, and also because it downloads extensions we have not reviewed. We are doing this by setting @@ -969,30 +972,25 @@ are doing this by setting <command>devtools.webide.enabled</command>, and <command>devtools.appmanager.enabled</command> to <command>false</command>. Moreover, we removed the Roku Screen Sharing and screencaster code with a -<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id= ad4abdb2e724fec060063f460604b829c66ea08a"> +<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=055bdffbef68bc8d5e8005b3c7dd2f5d99da1163"> Firefox patch</ulink> as these features can bypass proxy settings as well. </para>
<para> -Shumway is removed, too, for possible proxy bypass risks. We did this by -backporting a <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=d020a4992d8d25baf7dfb5c8b308d80b47a8d312"> -number</ulink> <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=98bf6c81b22cb5e4651a5fc060182f27b26c8ee5"> -of</ulink> <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=14b723f28a6b1dd78093691013d1bf7d49dc4413">Mozilla patches</ulink>. -Further down on our road to proxy safety we <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=a9e1d8eac28abb364bbfd3adabeae287751a6a8e"> -disabled the network tickler</ulink> as it has the capability to send UDP -traffic. - </para> - - <para> - -Finally, we <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=8e52265653ab223dc5af679f9f0c073b44371fa4"> -disabled mDNS support</ulink>, since mDNS uses UDP packets. We also disable +Further down on our road to proxy safety we <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=7222d02638689a64d7297b8e5c202f9c37547523"> +disable the network tickler</ulink> as it has the capability to send UDP +traffic and we <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=5bc957b4f635a659f9aecaa374972ecca7f770a8"> +disable mDNS support</ulink>, since mDNS uses UDP packets as well. We also disable Mozilla's TCPSocket by setting <command>dom.mozTCPSocket.enabled</command> to <command>false</command>. We <ulink url="https://trac.torproject.org/projects/tor/ticket/18866">intend to rip out</ulink> the TCPSocket code in the future to have an even more solid guarantee that it won't be used by accident. + </para>
+ <para> +Finally, we <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=55bd129f081bd37ae9e72ae32434fbb56ff4e446"> +remove</ulink> potentially unsafe Rust code. </para>
<para> @@ -1017,7 +1015,7 @@ blocked.
<para> Plugins, like Flash, have the ability to make arbitrary OS system calls and -<ulink url="http://decloak.net/">bypass proxy settings</ulink>. This includes +<ulink url="https://ip-check.info/">bypass proxy settings</ulink>. This includes the ability to make UDP sockets and send arbitrary data independent of the browser proxy settings. </para> @@ -1038,10 +1036,10 @@ restricted from automatic load through Firefox's click-to-play preference In addition, to reduce any unproxied activity by arbitrary plugins at load time, and to reduce the fingerprintability of the installed plugin list, we also patch the Firefox source code to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2es... prevent the load of any plugins except for Flash and Gnash</ulink>. Even for Flash and Gnash, we also patch Firefox to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2es... prevent loading them into the address space</ulink> until they are explicitly enabled. </para> @@ -1054,14 +1052,20 @@ can't be built reproducibly or are binary blobs which we are not allowed to audit (or both). For the EME case we use the <command>--disable-eme</command> configure switch and set <command>browser.eme.ui.enabled</command>, +<command>media.gmp-eme-adobe.visible</command>, <command>media.gmp-eme-adobe.enabled</command>, +<command>media.gmp-widevinecdm.visible</command>, +<command>media.gmp-widevinecdm.enabled</command>, <command>media.eme.enabled</command>, and <command>media.eme.apiVisible</command> to <command>false</command> to indicate to the user that this feature is disabled. For GMPs in general we make sure that the external server is not even pinged for updates/downloads in the first place by setting <command>media.gmp-manager.url.override</command> to <command>data:text/plain,</command> and avoid any UI with <command> -media.gmp-provider.enabled</command> set to <command>false</command>. + media.gmp-provider.enabled</command> set to <command>false</command>. Moreover, +we disable GMP downloads via local fallback by setting +<command>media.gmp-manager.updateEnabled</command> to <command>false</command>. +To reduce our attack surface we exclude the ClearKey EME system, too.
</para> </listitem> @@ -1070,11 +1074,23 @@ media.gmp-provider.enabled</command> set to <command>false</command>.
External apps can be induced to load files that perform network activity. Unfortunately, there are cases where such apps can be launched automatically -with little to no user input. In order to prevent this, Torbutton installs a -component to <ulink +with little to no user input. In order to prevent this, we ship <ulink +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2es... +Firefox</ulink> <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=99173c3a5f83d9ac44091a72c5570efd296dff8f">patches</ulink> and Torbutton installs a component to <ulink url="https://gitweb.torproject.org/torbutton.git/tree/src/components/external-app-blocker.js"> provide the user with a popup</ulink> whenever the browser attempts to launch -a helper app. +a helper application. + + </para> + <para> + +Furthermore, we ship a <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=d75b79f6fa920e6a1e3043005dfd50060ea70e57">patch for Linux users</ulink> that makes +sure sftp:// and smb:// URLs are not passed along to the operating system as this +can lead to proxy bypasses on systems that have GIO/GnomeVS support. And proxy +bypass risks due to file:// URLs should be mitigated for macOS and Linux users +by <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=8db44df10d1d82850e8b4cfe81ac3b5fce32a663"> +two</ulink> <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=a8e1fcc8678aa1583f73ef231c99f77cf17196d9"> +further patches</ulink>.
</para> <para> @@ -1101,7 +1117,14 @@ system-level addons from the browser through the use of <command>extensions.autoDisableScopes</command>. Furthermore, we set <command>extensions.systemAddon.update.url</command> and <command> extensions.hotfix.id</command> to an empty string in order -to avoid the risk of getting extensions installed by Mozilla into Tor Browser. +to avoid the risk of getting extensions installed by Mozilla into Tor Browser, +and remove unused system extensions with a +<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=4d90fcf15e328ca369751011ad0a9c0c1ba2f153"> +Firefox patch</ulink>. +In order to make it harder for users to accidentally install extensions which +Mozilla presents to them on the <emphasis>about:addons</emphasis> page, we hide +the <emphasis>Get Addons</emphasis> option on it by setting +<command>extensions.getAddons.showPane</command> to <command>false</command>.
</para> </listitem> @@ -1137,40 +1160,37 @@ features if they so desire. <sect3> <title>Implementation Status:</title> <blockquote> - We are working towards this goal through several mechanisms. First, we set the Firefox Private Browsing preference - <command>browser.privatebrowsing.autostart</command>. + <command>browser.privatebrowsing.autostart</command> to <command>true</command>. We also had to disable the media cache with the pref <command>media.cache_size</command>, to prevent HTML5 videos from being written to the OS temporary directory, which happened regardless of the private browsing mode setting. - Finally, we needed to disable asm.js as it turns out that - <ulink url="https://bugzilla.mozilla.org/show_bug.cgi?id=1047105">asm.js - cache entries get written to disk</ulink> in private browsing mode. This - is done by setting <command>javascript.options.asmjs</command> to - <command>false</command> (for linkability concerns with asm.js see below). - </blockquote> - <blockquote> + Finally, we set <command>security.nocertdb</command> to <command>true</command> + to make the intermediate certificate store memory-only. + </blockquote> + <blockquote> + Moreover, we prevent text leaking from the web console to the /tmp + directory with a direct <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=48b68533d113c5998d19d4e5acfb8967ba2d5f5b">Firefox patch</ulink>. + </blockquote> + <blockquote>
-As an additional defense-in-depth measure, we set the following preferences: -<command></command>, +As an additional defense-in-depth measure, we set <command>browser.cache.disk.enable</command>, <command>browser.cache.offline.enable</command>, -<command>dom.indexedDB.enabled</command>, -<command>network.cookie.lifetimePolicy</command>, <command>signon.rememberSignons</command>, -<command>browser.formfill.enable</command>, -<command>browser.download.manager.retention</command>, -<command>browser.sessionstore.privacy_level</command>, -and <command>network.cookie.lifetimePolicy</command>. Many of these -preferences are likely redundant with -<command>browser.privatebrowsing.autostart</command>, but we have not done the -auditing work to ensure that yet. - - </blockquote> - <blockquote> +<command>browser.formfill.enable</command> to <command>true</command>, +<command>browser.download.manager.retention</command> to <command>1</command>, +and both <command>browser.sessionstore.privacy_level</command> and +<command>network.cookie.lifetimePolicy</command> to <command>2</command>. Many +of these preferences are likely redundant with +<command>browser.privatebrowsing.autostart</command> enabled, but we have not +done the auditing work to ensure that yet. + + </blockquote> + <blockquote>
For more details on disk leak bugs and enhancements, see the <ulink url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-disk-leak&status=!closed">tbb-disk-leak tag in our bugtracker</ulink> - </blockquote> + </blockquote> </sect3> </sect2> <sect2 id="app-data-isolation"> @@ -1240,11 +1260,14 @@ form history, login values, and so on within a context menu for each site. <para>
Unfortunately, many aspects of browser state can serve as identifier storage, -and no other browser vendor or standards body has invested the effort to +and no other browser vendor or standards body had invested the effort to enumerate or otherwise deal with these vectors for third party tracking. As such, we have had to enumerate and isolate these identifier sources on a -piecemeal basis. Here is the list that we have discovered and dealt with to -date: +piecemeal basis. This has gotten better lately with Mozilla stepping up and +helping us with uplifting our patches, and with contributing own ones where we +lacked proper fixes. However, we are not done yet with our unlinkability defense +as new identifier sources are still getting added to the web platform. Here is +the list that we have discovered and dealt with to date:
</para> <orderedlist> @@ -1252,19 +1275,19 @@ date: <para><command>Design Goal:</command>
All cookies MUST be double-keyed to the URL bar origin and third-party -origin. There exists a <ulink -url="https://bugzilla.mozilla.org/show_bug.cgi?id=565965%22%3EMozilla bug</ulink> -that contains a prototype patch, but it lacks UI, and does not apply to modern -Firefox versions. +origin.
</para> <para><command>Implementation Status:</command>
-As a stopgap to satisfy our design requirement of unlinkability, we currently -entirely disable 3rd party cookies by setting -<command>network.cookie.cookieBehavior</command> to <command>1</command>. We -would prefer that third party content continue to function, but we believe the -requirement for unlinkability trumps that desire. +Double-keying cookies should just work by setting <command>privacy.firstparty.isolate +</command> to <command>true</command>. However, +<ulink url="https://trac.torproject.org/projects/tor/ticket/21905">we have not +audited that</ulink> yet and there is still the +<ulink url="https://trac.torproject.org/projects/tor/ticket/10353">UI part +missing for managing cookies in Private Browsing Mode</ulink>. We therefore +opted to keep third-party cookies disabled for now by setting +<command>network.cookie.cookieBehavior</command> to <command>1</command>.
</para> </listitem> @@ -1272,94 +1295,74 @@ requirement for unlinkability trumps that desire. <para><command>Design Goal:</command> All cache entries MUST be isolated to the URL bar domain. </para> - <para><command>Implementation Status:</command> - -In Firefox, there are actually several distinct caching mechanisms: One is for -general content (HTML, JavaScript, CSS). That content cache is isolated to the -URL bar domain by <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... -each cache key</ulink> to include an additional ID that includes the URL bar -domain. This functionality can be observed by navigating to <ulink -url="about:cache">about:cache</ulink> and viewing the key used for each cache -entry. Each third party element should have an additional "string@:" -property prepended, which will list the base domain that was used to source it. - - </para> - <para> - -Additionally, there is the image cache. Because it is a separate entity from -the content cache, we had to patch Firefox to also <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... -this cache per URL bar domain</ulink>. + <para><command>Implementation Status:</command> +We isolate the content and image cache to the URL bar domain by setting +<command>privacy.firstparty.isolate</command> to <command>true</command>.
- </para> - <para> + </para> + <para> Furthermore there is the Cache API (CacheStorage). That one is currently not available in Tor Browser as we do not allow third party cookies and are in Private Browsing Mode by default. - </para> - <para> + </para> + <para> Finally, we have the asm.js cache. The cache entry of the sript is (among others things, like type of CPU, build ID, source characters of the asm.js module etc.) keyed <ulink url="https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/">to the origin of the script</ulink>. -Lacking a good solution for binding it to the URL bar domain instead (and given -the storage of asm.js modules in Private Browsing Mode) we decided to disable -asm.js for the time being by setting <command>javascript.options.asmjs</command> to -<command>false</command>. It remains to be seen whether keying the cache entry -to the source characters of the asm.js module helps to avoid using it for -cross-origin tracking of users. We did not investigate that yet. - </para> +Lacking a good solution for binding it to the URL bar domain instead we decided +to disable asm.js for the time being by setting +<command>javascript.options.asmjs</command> to <command>false</command>. It +remains to be seen whether keying the cache entry e.g. to the source characters +of the asm.js module helps to avoid using it for cross-origin tracking of users. +We did not investigate that yet. + </para> </listitem> <listitem><command>HTTP Authentication</command> - <para> + <para>
HTTP Authorization headers can be used to encode <ulink url="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.html">silent -third party tracking identifiers</ulink>. To prevent this, we remove HTTP -authentication tokens for third party elements through a <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... -to nsHTTPChannel</ulink>. +third party tracking identifiers</ulink>. To prevent this, we set +<command>privacy.firstparty.isolate</command> to <command>true</command>.
- </para> + </para> </listitem> <listitem><command>DOM Storage</command> - <para> + <para>
DOM storage for third party domains MUST be isolated to the URL bar domain, -to prevent linkability between sites. This functionality is provided through a -<ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... -to Firefox</ulink>. +to prevent linkability between sites. We achieve this by setting +<command>privacy.firstparty.isolate</command> to <command>true</command>.
- </para> - </listitem> + </para> + </listitem> <listitem><command>Flash cookies</command> - <para><command>Design Goal:</command> + <para><command>Design Goal:</command>
Users should be able to click-to-play flash objects from trusted sites. To make this behavior unlinkable, we wish to include a settings file for all platforms that disables flash cookies using the <ulink -url="http://www.macromedia.com/support/documentation/en/flashplayer/help/settings... +url="https://www.macromedia.com/support/documentation/en/flashplayer/help/setting... settings manager</ulink>.
- </para> - <para><command>Implementation Status:</command> + </para> + <para><command>Implementation Status:</command>
We are currently <ulink url="https://trac.torproject.org/projects/tor/ticket/3974">having difficulties</ulink> causing Flash player to use this settings file on Windows, so Flash remains difficult to enable.
- </para> + </para> </listitem> <listitem><command>SSL+TLS session resumption</command> - <para><command>Design Goal:</command> + <para><command>Design Goal:</command>
TLS session resumption tickets and SSL Session IDs MUST be limited to the URL bar domain.
- </para> - <para><command>Implementation Status:</command> + </para> + <para><command>Implementation Status:</command>
We disable TLS Session Tickets and SSL Session IDs by setting <command>security.ssl.disable_session_identifiers</command> to @@ -1369,21 +1372,23 @@ these performance optimizations, we also enable <ulink url="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00">TLS False Start</ulink> via the Firefox Pref <command>security.ssl.enable_false_start</command>. +However, URL bar domain isolation should be working both for session tickets and +session IDs but we <ulink url="https://trac.torproject.org/projects/tor/ticket/17252"> +have not verified that yet</ulink>.
- </para> + </para> </listitem> <listitem><command>Tor circuit and HTTP connection linkability</command> - <para> + <para><command>Design Goal:</command>
Tor circuits and HTTP connections from a third party in one URL bar origin MUST NOT be reused for that same third party in another URL bar origin.
- </para> - <para> + </para> + <para><command>Implementation Status:</command>
-This isolation functionality is provided by a Torbutton -component that <ulink -linkend="https://gitweb.torproject.org/torbutton.git/tree/src/components/domain-isola... +The isolation functionality is provided by a Torbutton component that <ulink +url="https://gitweb.torproject.org/torbutton.git/tree/src/components/domain-isola... the SOCKS username and password for each request</ulink>. The Tor client has logic to prevent connections with different SOCKS usernames and passwords from using the same Tor circuit. Firefox has existing logic to ensure that @@ -1393,30 +1398,32 @@ connections unless the proxy settings match. this logic</ulink> to cover SOCKS username and password authentication, providing us with HTTP Keep-Alive unlinkability.
- </para> + </para> + <para> + +While the vast majority of web requests adheres to the circuit and connection +unlinkability requirement there are still corner cases we +<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=8661822237c56d543d5c9117c8a4708c402a110f"> + need to treat separately</ulink> or that +<ulink href="https://bugs.torproject.org/22343">lack a fix altogether</ulink>. + </para> </listitem> <listitem><command>SharedWorkers</command> - <para> + <para>
<ulink url="https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker">SharedWorkers</ulink> are a special form of JavaScript Worker threads that have a shared scope between -all threads from the same Javascript origin. - - </para> - <para> - -The SharedWorker scope MUST be isolated to the URL bar domain. I.e. a -SharedWorker launched from a third party from one URL bar domain MUST NOT have -access to the objects created by that same third party loaded under another URL -bar domain. This functionality is provided by a -<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=d17c11445645908086c8d0af84e970e880f586eb"> -Firefox patch</ulink>. +all threads from the same Javascript origin. They MUST be isolated to the URL +bar domain. I.e. a SharedWorker launched from a third party from one URL bar +domain MUST NOT have access to the objects created by that same third party +loaded under another URL bar domain. This functionality is provided by setting +<command>privacy.firstparty.isolate</command> to <command>true</command>.
- </para> + </para> </listitem> <listitem><command>blob: URIs (URL.createObjectURL)</command> - <para> + <para>
The <ulink url="https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL">URL.createObjectURL</ulink> @@ -1428,29 +1435,24 @@ predictable, it can still be used to tag a set of users that are of high interest to an adversary.
</para> - <para><command>Design Goal:</command> + <para>
URIs created with URL.createObjectURL MUST be limited in scope to the first -party URL bar domain that created them. - - </para> - <para><command>Implementation Status:</command> - -We provide the isolation in Tor Browser via a <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... -patch to Firefox</ulink>. However, downloads of PDF files via the download button in the PDF viewer <ulink url="https://bugs.torproject.org/17933">are not isolated yet</ulink>. +party URL bar domain that created them. We provide the isolation in Tor +Browser by setting <command>privacy.firstparty.isolate</command> to +<command>true</command>.
- </para> + </para> </listitem> <listitem><command>SPDY and HTTP/2</command> - <para><command>Design Goal:</command> + <para><command>Design Goal:</command>
SPDY and HTTP/2 connections MUST be isolated to the URL bar domain. Furthermore, all associated means that could be used for cross-domain user tracking (alt-svc headers come to mind) MUST adhere to this design principle as well.
- </para> - <para><command>Implementation status:</command> + </para> + <para><command>Implementation status:</command>
SPDY and HTTP/2 are currently disabled by setting the Firefox preferences <command>network.http.spdy.enabled</command>, @@ -1462,10 +1464,10 @@ Firefox preferences <command>network.http.spdy.enabled</command>, <command>network.http.altsvc.enabled</command>, and <command>network.http.altsvc.oe</command> to <command>false</command>.
- </para> + </para> </listitem> <listitem><command>Automated cross-origin redirects</command> - <para><command>Design Goal:</command> + <para><command>Design Goal:</command>
To prevent attacks aimed at subverting the Cross-Origin Identifier Unlinkability <link linkend="privacy">privacy requirement</link>, the browser @@ -1475,34 +1477,34 @@ For example, if a user clicks on a bit.ly URL that redirects to a doubleclick.net URL that finally redirects to a cnn.com URL, only cookies from cnn.com should be retained after the redirect chain completes.
- </para> - <para> + </para> + <para>
Non-automated redirect chains that require user input at some step (such as federated login systems) SHOULD still allow identifiers to persist.
- </para> - <para><command>Implementation status:</command> + </para> + <para><command>Implementation status:</command>
There are numerous ways for the user to be redirected, and the Firefox API support to detect each of them is poor. We have a <ulink url="https://trac.torproject.org/projects/tor/ticket/3600">trac bug open</ulink> to implement what we can.
- </para> + </para> </listitem> - <listitem><command>window.name</command> - <para> + <listitem><command>window.name</command> + <para>
<ulink url="https://developer.mozilla.org/En/DOM/Window.name">window.name</ulink> is a magical DOM property that for some reason is allowed to retain a persistent value for the lifespan of a browser tab. It is possible to utilize this property for -<ulink url="http://www.thomasfrank.se/sessionvars.html">identifier +<ulink url="https://www.thomasfrank.se/sessionvars.html">identifier storage</ulink>.
- </para> - <para> + </para> + <para>
In order to eliminate non-consensual linkability but still allow for sites that utilize this property to function, we reset the window.name property of @@ -1511,10 +1513,10 @@ allows window.name to persist for the duration of a click-driven navigation session, but as soon as the user enters a new URL or navigates between HTTPS/HTTP schemes, the property is cleared.
- </para> + </para> </listitem> <listitem><command>Auto form-fill</command> - <para> + <para>
We disable the password saving functionality in the browser as part of our <link linkend="disk-avoidance">Disk Avoidance</link> requirement. However, @@ -1525,14 +1527,14 @@ preference to false to prevent saved values from immediately populating fields upon page load. Since JavaScript can read these values as soon as they appear, setting this preference prevents automatic linkability from stored passwords.
- </para> + </para> </listitem> - <listitem><command>HSTS and HPKP supercookies</command> + <listitem><command>HSTS and HPKP supercookies</command> <para>
An extreme (but not impossible) attack to mount is the creation of <ulink - url="http://www.leviathansecurity.com/blog/archives/12-The-Double-Edged-Sword-of-...</ulink> -<ulink url="http://www.radicalresearch.co.uk/lab/hstssupercookies/"> + url="https://www.leviathansecurity.com/blog/archives/12-The-Double-Edged-Sword-of...</ulink> +<ulink url="https://www.radicalresearch.co.uk/lab/hstssupercookies/"> supercookies</ulink>. Since HSTS effectively stores one bit of information per domain name, an adversary in possession of numerous domains can use them to construct cookies based on stored HSTS state. @@ -1560,9 +1562,8 @@ but we don't defend against the creation and usage of any of these supercookies between <command>New Identity</command> invocations.
</para> - </listitem> - - <listitem><command>Broadcast Channels</command> + </listitem> + <listitem><command>Broadcast Channels</command> <para>
The BroadcastChannel API allows cross-site communication within the same @@ -1572,10 +1573,8 @@ instead be isolated to the URL bar domain. </para> <para>
-We provide the isolation in Tor Browser via a <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... -patch to Firefox</ulink>. If we lack a window for determining the URL bar -domain (e.g. in some worker contexts) the use of broadcast channels is disabled. +We provide the isolation in Tor Browser by setting +<command>privacy.firstparty.isolate</command> to <command>true</command>.
</para> </listitem> @@ -1588,30 +1587,35 @@ no cached results are available. Thus, to avoid information leaks, e.g. to exit relays, OCSP requests MUST go over the same circuit as the HTTPS request causing them and MUST therefore be isolated to the URL bar domain. The resulting cache entries MUST be bound to the URL bar domain as well. This functionality is -provided by a -<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=7eb1568275acd4fdf61359c9b1e97c2753e7b2be">Firefox patch</ulink>. +provided by setting <command>privacy.firstparty.isolate</command> to +<command>true</command>.
</para> </listitem> <listitem><command>Favicons</command> - <para> + <para><command>Design Goal:</command>
When visiting a website its favicon is fetched via a request originating from the browser itself (similar to the OCSP mechanism mentioned in the previous -section). Those requests MUST be isolated to the URL bar domain. This -functionality is provided by a -<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=f29f3ff28bbc471ea209d2181770677223c394d1">Firefox patch</ulink>. +section). Those requests MUST be isolated to the URL bar domain.
</para> + <para><command>Implemetation Status:</command> + +Favicon requests are isolated to the URL bar domain by setting +<command>privacy.firstparty.isolate</command> to <command>true</command>. +However, we need an additional +<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=eaa22334adaf8f79544ee4318982e5f4990c1a6f">Firefox patch</ulink> +to take care of favicons in tab list menuitems. + </para> </listitem> <listitem><command>mediasource: URIs and MediaStreams</command> <para>
Much like blob URLs, mediasource: URIs and MediaStreams can be used to tag users. Therefore, mediasource: URIs and MediaStreams MUST be isolated to the URL bar domain. -This functionality is part of a -<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=7eb0b7b7a9c7257140ae5683718e82f3f0884f4f">Firefox patch</ulink> - +This functionality is provided by setting <command>privacy.firstparty.isolate</command> +to <command>true</command>. </para> </listitem> <listitem><command>Speculative and prefetched connections</command> @@ -1632,31 +1636,50 @@ url="https://trac.torproject.org/projects/tor/ticket/18762#comment:3%22%3E comment rel="prefetch" attribute is still performed, however.
</para> - <para><command>Design Goal:</command> + <para>
All pre-loaded links and speculative connections MUST be isolated to the URL bar domain, if enabled. This includes isolating both Tor circuit use, as well as the caching and associate browser state for the prefetched resource.
</para> - <para><command>Implementation Status:</command> + <para>
For automatic speculative connects and rel="preconnect", we leave them disabled as per the Mozilla default for proxy settings. However, if enabled, speculative connects will be isolated to the proper first party Tor circuit by -the same mechanism as is used for HTTP Keep-alive. This is true for rel="prefetch" -requests as well. For rel="preconnect", we isolate them <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... -this patch</ulink>. This isolation makes both preconnecting and cache warming -via rel=prefetch ineffective for links to domains other than the current URL -bar domain. For links to the same domain as the URL bar domain, the full cache -warming benefit is obtained. As an optimization, any preconnecting to domains -other than the current URL bar domain can thus be disabled (perhaps with the -exception of frames), but we do not do this. We allow these requests to -proceed, but we isolate them. +the same mechanism as is used for HTTP Keep-Alive. This is true for rel="prefetch" +requests as well. For rel="preconnect", we set <command>privacy.firstparty.isolate</command> +to <command>true</command>. This isolation makes both preconnecting and cache +warming via rel="prefetch" ineffective for links to domains other than the +current URL bar domain. For links to the same domain as the URL bar domain, +the full cache warming benefit is obtained. As an optimization, any +preconnecting to domains other than the current URL bar domain can thus be +disabled (perhaps with the exception of frames), but we do not do this. +We allow these requests to proceed, but we isolate them.
</para> + </listitem> + <listitem><command>Permissions API</command> + <para> + +The Permissions API allows a website to query the status of different +permissions. Although permissions are keyed to the origin, that is not enough to +alleviate cross-linkabilility concerns: the combined permission state could work +like an identifier given more and more permissions and their state being +accessible under this API. + + </para> + <para><command>Design Goal:</command>
+Permissions MUST be isolated to the URL bar domain. + + </para> + <para><command>Implementation Status:</command> + +Right now we provide a <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=14374d30767f83923561084530b54c066bb661b4">Firefox patch</ulink> that makes sure permissions are isolated to the URL bar domain. + + </para> </listitem> </orderedlist> <para> @@ -1908,10 +1931,10 @@ each interaction between a user and a site provides a different fingerprint. </para> <para>
-Although <ulink url="http://research.microsoft.com/pubs/209989/tr1.pdf">some -research suggests</ulink> 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: +Although <ulink url="https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr1-1.pdf"> +some research suggests</ulink> 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:
</para>
@@ -2058,8 +2081,8 @@ available, the rest are entirely blocked from loading by the Firefox patches mentioned in the <link linkend="proxy-obedience">Proxy Obedience section</link>. We also set the Firefox -preference <command>plugin.expose_full_path</command> to false, to avoid -leaking plugin installation information. +preference <command>plugin.expose_full_path</command> to +<command>false</command>, to avoid leaking plugin installation information.
</para> </listitem> @@ -2087,7 +2110,7 @@ fingerprinting vectors. If WebGL is normalized through software rendering, system colors were standardized, and the browser shipped a fixed collection of fonts (see later points in this list), it might not be necessary to create a canvas permission. However, until then, to reduce the threat from this vector, -we have patched Firefox to <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=526e6d0bc5c68d8c409cbaefc231c71973d949cc">prompt before returning valid image data</ulink> to the Canvas APIs, +we have patched Firefox to <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=196354d7951a48b4e6f5309d2a8e46962fff9d5f">prompt before returning valid image data</ulink> to the Canvas APIs, and for access to isPointInPath and related functions. Moreover, we put media streams on a canvas behind the site permission in that patch as well. If the user hasn't previously allowed the site in the URL bar to access Canvas @@ -2124,7 +2147,10 @@ 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. 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. +and associated network information to websites. Additionally, we +<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=13baf9df4b47bd13bb7da045048ed4339615ac03"> +rip out</ulink> the option to collect local IP addresses via the +NetworkInfoService.
</para>
@@ -2139,7 +2165,8 @@ aren't an attractive vector for this reason. However, because it is not clear if certain carefully-crafted error conditions in these protocols could cause them to reveal machine information and still fail silently prior to the password prompt, these authentication mechanisms should either be disabled, or -placed behind a site permission before their use. We simply disable them. +placed behind a site permission before their use. We simply disable them +<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=fe465944545a76287842321175cc7713091e77b1">with a patch</ulink>.
</para> </listitem> @@ -2171,7 +2198,7 @@ it via the pref <command>dom.gamepad.enabled</command>. <para>
According to the Panopticlick study, fonts provide the most linkability when -they are provided as an enumerable list in file system order, via either the +they are available as an enumerable list in file system order, via either the Flash or Java plugins. However, it is still possible to use CSS and/or JavaScript to query for the existence of specific fonts. With a large enough pre-built list to query, a large amount of fingerprintable information may @@ -2198,7 +2225,8 @@ vary in detail.
For Windows and macOS we use a preference, <command>font.system.whitelist</command>, to restrict fonts being used to those in the whitelist. This functionality is -provided <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=80d233db514a556d7255034ae057b138527cb2ea">by a Firefox patch</ulink>. +provided by setting <command>privacy.resistFingerprinting</command> to +<command>true</command>. The whitelist for Windows and macOS contains both a set of <ulink url="https://www.google.com/get/noto">Noto fonts</ulink> which we bundle and fonts provided by the operating system. For Linux systems we only bundle @@ -2261,12 +2289,13 @@ maximizing their windows can lead to fingerprintability under the current scheme </para> <para><command>Implementation Status:</command>
-We automatically resize new browser windows to a 200x100 pixel multiple <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... -on desktop resolution</ulink> which is provided by a Firefox patch. To minimize -the effect of the long tail of large monitor sizes, we also cap the window size -at 1000 pixels in each direction. In addition to that we set -<command>privacy.resistFingerprinting</command> +We automatically resize new browser windows to a 200x100 pixel multiple based +on desktop resolution by backporting patches from +<ulink href="https://bugzilla.mozilla.org/show_bug.cgi?id=1330882">bug 1330882</ulink> +and setting <command>privacy.resistfingerprinting</command> to +<command>true</command>. To minimize the effect of the long tail of large +monitor sizes, we also cap the window size at 1000 pixels in each direction. +In addition to that we set <command>privacy.resistFingerprinting</command> to <command>true</command> to use the client content window size for window.screen, and to report a window.devicePixelRatio of 1.0. Similarly, we use that preference to return content window relative points for DOM events. @@ -2304,12 +2333,12 @@ details such as screen orientation or type. <para><command>Implementation Status:</command>
We set <command>ui.use_standins_for_native_colors</command> to <command>true -</command> and provide a <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=c6be9ba561a69250c7d5926d90e0112091453643">Firefox patch</ulink> +</command> and provide a <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=9e84b962ae4e7369fcf13fdf3adb646877d48f1d">Firefox patch</ulink> to report a fixed set of system colors to content window CSS, and prevent detection of font smoothing on macOS with the help of -<command>privacy.resistFingerprinting</command>. We also always -<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=5a159c6bfa310b4339555de389ac16cf8e13b3f5"> -report landscape-primary</ulink> for the <ulink url="https://w3c.github.io/screen-orientation/">screen orientation</ulink>. +<command>privacy.resistFingerprinting</command> set to <command>true</command>. +We use the same preference, too, to always report landscape-primary for the +<ulink url="https://w3c.github.io/screen-orientation/">screen orientation</ulink>.
</para> </listitem> @@ -2324,25 +2353,26 @@ fingerprinting. <para>
Because of the large amount of potential fingerprinting vectors and the <ulink -url="http://www.contextis.com/resources/blog/webgl/%22%3Epreviously unexposed -vulnerability surface</ulink>, we deploy a similar strategy against WebGL as -for plugins. First, WebGL Canvases have click-to-play placeholders (provided -by NoScript), and do not run until authorized by the user. Second, we -obfuscate driver information by setting the Firefox preferences +url="https://www.contextis.com/resources/blog/webgl-new-dimension-browser-exploit... +previously unexposed vulnerability surface</ulink>, we deploy a similar strategy +against WebGL as for plugins. First, WebGL Canvases have click-to-play +placeholders (provided by NoScript), and do not run until authorized by the user. +Second, we obfuscate driver information by setting the Firefox preferences <command>webgl.disable-extensions</command>, <command>webgl.min_capability_mode</command>, and -<command>webgl.disable-fail-if-major-performance-caveat</command> which reduce -the information provided by the following WebGL API calls: -<command>getParameter()</command>, <command>getSupportedExtensions()</command>, -and <command>getExtension()</command>. To make the minimal WebGL mode usable we -additionally <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=7b0caa1224c3417754d688344eacc97fbbabf7d5"> +<command>webgl.disable-fail-if-major-performance-caveat</command> to +<command>true</command> which reduces the information provided by the following +WebGL API calls: <command>getParameter()</command>, +<command>getSupportedExtensions()</command>, and <command>getExtension()</command>. Furthermore, WebGL2 is disabled by setting <command>webgl.enable-webgl2</command> +to <command>false</command>. To make the minimal WebGL mode usable we +additionally <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=1acd0c7fae9121240401cf4a8f0e2b1f6fdb9827"> normalize its properties with a Firefox patch</ulink>.
</para> <para>
Another option for WebGL might be to use software-only rendering, using a -library such as <ulink url="http://www.mesa3d.org/">Mesa</ulink>. The use of +library such as <ulink url="https://www.mesa3d.org/">Mesa</ulink>. The use of such a library would avoid hardware-specific rendering differences.
</para> @@ -2368,11 +2398,46 @@ on the application software and/or drivers a user chose to install. Web pages can not only estimate the amount of MIME types registered by checking <command>navigator.mimetypes.length</command>. Rather, they are even able to test whether particular MIME types are available which can have a non-negligible -impact on a user's fingerprint. We prevent both of these information leaks with -a direct <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=38999857761196b0b7f59f49ee93ae13f73c6149">Firefox patch</ulink>. - +impact on a user's fingerprint. We prevent both of these information leaks by +setting <command>privacy.resistfingerprinting</command> to <command>true</command>. </para> </listitem> + <listitem><command>Web Speech API</command> + <para> + +The Web Speech API consists of two parts: SpeechSynthesis (Text-to-Speech) and +SpeechRecognition (Asynchronous Speech Recognition). The latter is still +disabled in Firefox. However, the former is enabled by default and there is the +risk that <command>speechSynthesis.getVoices()</command> has access to +computer-specific speech packages making them available in an enumerable +fashion. Morevover, there are callbacks that would allow JavaScript to time how +long a phrase takes to be "uttered". To prevent both we set +<command>media.webspeech.synth.enabled</command> to <command>false</command>. + + </para> + </listitem> + + <listitem><command>Touch API</command> + <para> + +Touch events are able to reveal the absolute screen coordinates of a device +which would defeat our approach to mitigate leaking the screen size as described +above. In order to prevent that we implemented two defenses: first we disable +the Touch API by setting <command>dom.w3c_touch_events.enabled</command> to +<command>false</command>. Second, for those user that really need or want to +have this API available we patched the code to give content-window related +coordinates back. Furthermore, we made sure that the touch area described by +<command>Touch.radiusX</command>, <command>Touch.radiusY</command>, and +<command>Touch.rotationAngle</command> does not leak further information and +<command>Touch.force</command> does not reveal how much pressure a user applied +to the surface. That is achieved by a direct +<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=7d9701c2b6a203b1b7a556f614858588e3e5976e"> +Firefox patch</ulink> which reports back <command>1</command> for the first two +properties and <command>0.0</command> for the two last ones. + + </para> + </listitem> + <listitem><command>System Uptime</command> <para>
@@ -2404,9 +2469,9 @@ Browser user. </para> <para><command>Implementation Status:</command>
-We provide <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=a65b5269ff04e4fbbb3689e2adf853543804ffbf">two</ulink> -<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=383b8e7e073ea79e70f19858efe1c5fde64b99cf">Firefox patches</ulink> that -take care of spoofing <command>KeyboardEvent.code</command> and <command> +We provide <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=d6d29f155e60c63b38918c8879ee221b9c90b1f7">two</ulink> +<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=789bad5fe5a7a0c2d27e1d8dd7b9a7e35de91cc8">Firefox patches</ulink> +that take care of spoofing <command>KeyboardEvent.code</command> and <command> KeyboardEvent.keyCode</command> by providing consensus (US-English-style) fake properties. This is achieved by hiding the user's use of the numpad, and any non-QWERTY US English keyboard. Characters from non-en-US languages @@ -2431,7 +2496,7 @@ Firefox provides several options for controlling the browser user agent string which we leverage. We also set similar prefs for controlling the Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2es... content script access</ulink> to Components.interfaces, which <ulink url="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html">can be used</ulink> to fingerprint OS, platform, and Firefox minor version. </para> @@ -2457,12 +2522,15 @@ timing-based side channels. <para><command>Implementation Status:</command>
The cleanest solution to timing-based side channels would be to get rid of them. -However, this does not seem to be trivial even considering just a +This has been <ulink url="https://acmccs.github.io/papers/p163-caoA.pdf">proposed</ulink> +in the research community. However, we remain skeptical as it does not seem to +be trivial even considering just a <ulink url="https://bugzilla.mozilla.org/show_bug.cgi?id=711043">single</ulink> -<ulink url="https://cseweb.ucsd.edu/~dkohlbre/papers/subnormal.pdf">side channel</ulink>. -Thus, we rely on disabling all possible timing sources or making them -coarse-grained enough in order to render timing side channels unsuitable as a -means for fingerprinting browser users. +<ulink url="https://cseweb.ucsd.edu/~dkohlbre/papers/subnormal.pdf">side channel</ulink> +and <ulink url="https://gruss.cc/files/fantastictimers.pdf">more and more +potential side channels</ulink> are showing up. Thus, we rely on disabling all +possible timing sources or making them coarse-grained enough in order to render +timing side channels unsuitable as a means for fingerprinting browser users.
</para>
@@ -2471,13 +2539,16 @@ means for fingerprinting browser users. We set <command>dom.enable_user_timing</command> and <command>dom.enable_resource_timing</command> to <command>false</command> to disable these explicit timing sources. Furthermore, we clamp the resolution of -explicit clocks to 100ms <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=1febc98f7ae5dbec845567415bd5b703ee45d774">with a Firefox patch</ulink>. +explicit clocks to 100ms <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=1736ea256276546c899d712dffdae2c8d050d8a0">with two Firefox</ulink> <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=a4c6d2c07d483acfd729c7a50dd3f7b07fcba03a">patches</ulink>.
This includes <command>performance.now()</command>, <command>new Date().getTime() </command>, <command>audioContext.currentTime</command>, <command> canvasStream.currentTime</command>, <command>video.currentTime</command>, <command>audio.currentTime</command>, <command>new File([], "").lastModified -</command>, and <command>new File([], "").lastModifiedDate.getTime()</command>. +</command>, <command>new File([], "").lastModifiedDate.getTime()</command>, +<command>animation.startTime</command>, <command>animation.currentTime</command>, +<command>animation.timeline.currentTime</command>, +and <command>document.timeline.currentTime</command>.
</para> <para> @@ -2513,7 +2584,7 @@ out of a Tor Browser user by deploying resource:// and/or chrome:// URIs. Until this is fixed in Firefox <ulink url="https://gitweb.torproject.org/torbutton.git/tree/src/components/content-policy.js"> we filter</ulink> resource:// and chrome:// requests done by web content denying them by default. We need a whitelist of resource:// and -chrome:// URIs, though, to avoid breaking parts of Firefox. Those nearly a +chrome:// URIs, though, to avoid breaking parts of Firefox. Those more than a dozen Firefox resources do not aid in fingerprinting Tor Browser users as they are not different on the platforms and in the locales we support.
@@ -2536,7 +2607,7 @@ We set the fallback character set to set to windows-1252 for all locales, via <command>javascript.use_us_english_locale</command> to <command>true</command> to instruct the JS engine to use en-US as its internal C locale for all Date, Math, and exception handling. Additionally, we provide a patch to use an -<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=0080b2d6bafcbfb8a57f54a26e53d7f74d239389"> +<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=d144738fedeeb23746d7a9f16067bd985b0d59aa"> en-US label for the <command>isindex</command> HTML element</ulink> instead of letting the label leak the browser's UI locale. </para> @@ -2556,7 +2627,7 @@ All Tor Browser users MUST report the same timezone to websites. Currently, we choose UTC for this purpose, although an equally valid argument could be made for EDT/EST due to the large English-speaking population density (coupled with the fact that we spoof a US English user agent). Additionally, the Tor -software should detect if the users clock is significantly divergent from the +software should detect if the user's clock is significantly divergent from the clocks of the relays that it connects to, and use this to reset the clock values used in Tor Browser to something reasonably accurate. Alternatively, the browser can obtain this clock skew via a mechanism similar to that used in @@ -2565,10 +2636,10 @@ the browser can obtain this clock skew via a mechanism similar to that used in </para> <para><command>Implementation Status:</command>
-We <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=0ee3aa4cbeb1be3301d8960d0cf3a64831ea6d1b"> +We <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=dd1ba0b5c9281ee3207e5a87991159b8d2609a11"> set the timezone to UTC</ulink> with a Firefox patch using the TZ environment variable, which is supported on all platforms. Moreover, with an additional -patch just needed for the Windows platform, <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=bdd0303a78347d17250950a4cf858de556afb1c7"> +patch just needed for the Windows platform, <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=008649e2ce0357f31eb67d874e6429c39ddd7e8f"> we make sure</ulink> the TZ environment variable is respected by the <ulink url="http://site.icu-project.org/">ICU library</ulink> as well.
@@ -2577,10 +2648,10 @@ we make sure</ulink> the TZ environment variable is respected by the <listitem><command>JavaScript Performance Fingerprinting</command> <para>
-<ulink url="http://w2spconf.com/2011/papers/jspriv.pdf">JavaScript performance -fingerprinting</ulink> is the act of profiling the performance -of various JavaScript functions for the purpose of fingerprinting the -JavaScript engine and the CPU. +<ulink url="https://cseweb.ucsd.edu/~hovav/dist/jspriv.pdf">JavaScript +performance fingerprinting</ulink> is the act of profiling the performance of +various JavaScript functions for the purpose of fingerprinting the JavaScript +engine and the CPU.
</para> <para><command>Design Goal:</command> @@ -2594,7 +2665,7 @@ Date() object, while also introducing jitter. We believe that JavaScript time resolution may be reduced all the way up to the second before it seriously impacts site operation. Our goal with this quantization is to increase the amount of time it takes to mount a successful attack. <ulink -url="http://w2spconf.com/2011/papers/jspriv.pdf%22%3EMowery et al</ulink> found +url="https://cseweb.ucsd.edu/~hovav/dist/jspriv.pdf%22%3EMowery et al</ulink> found that even with the default precision in most browsers, they required up to 120 seconds of amortization and repeated trials to get stable results from their feature set. We intend to work with the research community to establish the @@ -2608,12 +2679,13 @@ large number of people. <para><command>Implementation Status:</command>
Currently, our mitigation against performance fingerprinting is to -disable <ulink url="http://www.w3.org/TR/navigation-timing/">Navigation -Timing</ulink> through the Firefox preference -<command>dom.enable_performance</command>, and to disable the <ulink +disable <ulink url="https://www.w3.org/TR/navigation-timing/">Navigation +Timing</ulink> by setting the Firefox preference +<command>dom.enable_performance</command> to <command>false</command>, and to +disable the <ulink url="https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement#Gecko-specific_properties">Mozilla -Video Statistics</ulink> API extensions via the preference -<command>media.video_stats.enabled</command>. +Video Statistics</ulink> API extensions by setting the preference +<command>media.video_stats.enabled</command> to <command>false</command>, too.
</para> </listitem> @@ -2633,10 +2705,53 @@ fingerprinting: timestamp quantization and jitter.
<para><command>Implementation Status:</command>
-We clamp keyboard event resolution to 100ms with a <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=1febc98f7ae5dbec845567415bd5b703ee45d774">Firefox patch</ulink>. +We clamp keyboard event resolution to 100ms with a <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=1736ea256276546c899d712dffdae2c8d050d8a0">Firefox patch</ulink>.
</para> </listitem> + <listitem><command>Amount of Processor Cores (hardwareConcurrency)</command> + <para> + +Modern computers have multiple physical processor cores in their CPU available. +One core typically allows to run more than one thread at a time and +<command>navigator.hardwareConcurrency</command> makes the number of those +threads (i.e. logical processors) available to web content. + + </para> + <para><command>Design Goal:</command> + +Websites MUST NOT be able to fingerprint a Tor Browser user taking advantage of +the amount of logical processors available. + + </para> + <para><command>Implementation Status:</command> + +We set <command>dom.maxHardwareConcurrency</command> to <command>1</command> to +report the same amount of logical processors for everyone. However, there are +<ulink url="https://github.com/oftn/core-estimator">probablistic ways of +determining the same information available</ulink> which we are not defending +against currently. Moreover, we might even want to think about a more elaborate +approach defending against this fingerprinting technique by not making all users +uniform but rather <ulink url="https://bugs.torproject.org/22127">by following +a bucket approach</ulink> as we currently do in our defense against screen +size exfiltration. + + </para> + </listitem> + <listitem><command>MediaError.message</command> + <para> + +The <command>MediaError</command> object allows the user agent to report errors +that occurred while handling media, for instance using <command>audio</command> +or <command>video</command> elements. The <command>message</command> property +provides specific diagnostic information to help understanding the error +condition. As a defense-in-depth we make sure that no information aiding in +fingerprinting is leaking to websites that way +<command url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=ee404a8341b5ecef535bfc0cad89b1682598fb68"> +by returning just an empty string</command>. + + </para> + </listitem> <listitem><command>Connection State</command> <para>
@@ -2689,7 +2804,12 @@ datareporting.healthreport.about.reportUrl</command> and the new tiles feature related <command>browser.newtabpage.directory.ping</command> and <command> browser.newtabpage.directory.source</command> preferences. Additionally, we disable the UITour backend by setting <command>browser.uitour.enabled</command> -to <command>false</command>. +to <command>false</command>. Finally, we provide <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=9f24ce35cd8776a0f7c3a4d54992ecb0eaad6311">a patch</ulink> +to prevent Mozilla's websites from querying whether particular extensions are +installed and what their state in Tor Browser is by using the +<command>window.navigator.AddonManager</command> API. As a defense-in-depth the +patch makes sure that not only Mozilla's websites can't get at that information +but that the whitelist governing this access is empty in general. </para> </listitem> <listitem><command>Operating System Type Fingerprinting</command> @@ -2711,7 +2831,7 @@ We intend to reduce or eliminate OS type fingerprinting to the best extent possible, but recognize that the effort for reward on this item is not as high as other areas. The entropy on the current OS distribution is somewhere around 2 bits, which is much lower than other vectors which can also be used to -fingerprint configuration and user-specific information. You can see the +fingerprint configuration and user-specific information. You can see the major areas of OS fingerprinting we're aware of using the <ulink url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting-os">tbb-fingerprinting-os tag on our bug tracker</ulink>. @@ -2795,15 +2915,15 @@ After closing all tabs, we then clear the searchbox and findbox text and emit state). Then we manually clear the following state: HTTP auth, SSL state, crypto tokens, OCSP state, site-specific content preferences (including HSTS state), the undo tab history, content and image cache, offline and memory cache, -offline storage, cookies, DOM storage, the safe browsing key, the -Google wifi geolocation token (if it exists), and the domain isolator state. We -also clear NoScript's site and temporary permissions, and all other browser site -permissions. +offline storage, IndexedDB storage, asm.js cache, cookies, DOM storage, the +safe browsing key, the Google wifi geolocation token (if it exists), and the +domain isolator state. We also clear NoScript's site and temporary permissions, +and all other browser site permissions.
</para> <para>
-After the state is cleared, we then close all remaining HTTP keep-alive +After the state is cleared, we then close all remaining HTTP Keep-Alive connections and then send the NEWNYM signal to the Tor control port to cause a new circuit to be created. </para> @@ -2880,7 +3000,9 @@ includes three features that were formerly governed by the slider at higher security levels: <command>gfx.font_rendering.graphite.enabled</command> is set to <command>false</command> now after Mozilla got convinced that <ulink url="https://bugzilla.mozilla.org/show_bug.cgi?id=1255731">leaving -it enabled is too risky</ulink>. <command>network.jar.block-remote-files</command> +it enabled is too risky</ulink>. Even though Mozilla reverted that decision +after another round of fixing critical Graphite bugs, we remain skeptical +and keep that feature disabled for now. <command>network.jar.block-remote-files</command> is set to <command>true</command>. Mozilla tried to block remote JAR files in Firefox 45 but needed to revert that decision due to breaking IBM's iNotes. While Mozilla <ulink url="https://bugzilla.mozilla.org/show_bug.cgi?id=1329336"> @@ -2897,9 +3019,9 @@ Unlinkability</link> sections for further details. <para>
At this security level, we disable the ION JIT -(<command>javascript.options.ion.content</command>), TypeInference JIT -(<command>javascript.options.typeinference</command>), Baseline JIT -(<command>javascript.options.baselinejit.content</command>), WebAudio +(<command>javascript.options.ion</command>), native regular expressions +(<command>javascript.options.native_regexp</command>), Baseline JIT +(<command>javascript.options.baselinejit</command>), WebAudio (<command>media.webaudio.enabled</command>), MathML (<command>mathml.disabled</command>), SVG Opentype font rendering (<command>gfx.font_rendering.opentype_svg.enabled</command>), and make HTML5 audio @@ -2949,14 +3071,14 @@ Ideally, this mechanism would be as light-weight as possible, and would be tunable in terms of overhead. We suspect that it may even be possible to deploy a mechanism that reduces feature extraction resolution without any network overhead. In the no-overhead category, we have <ulink -url="http://freehaven.net/anonbib/cache/LZCLCP_NDSS11.pdf%22%3EHTTPOS</ulink> and +url="https://freehaven.net/anonbib/cache/LZCLCP_NDSS11.pdf%22%3EHTTPOS</ulink> and <ulink url="https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting">better use of HTTP pipelining and/or SPDY</ulink>. In the tunable/low-overhead category, we have <ulink url="https://arxiv.org/abs/1512.00524">Adaptive -Padding</ulink> and <ulink url="http://www.cs.sunysb.edu/~xcai/fp.pdf"> +Padding</ulink> and <ulink url="https://www3.cs.stonybrook.edu/~xcai/fp.pdf"> Congestion-Sensitive BUFLO</ulink>. It may be also possible to <ulink url="https://trac.torproject.org/projects/tor/ticket/7028">tune such defenses</ulink> such that they only use existing spare Guard bandwidth capacity in the Tor @@ -2970,7 +3092,7 @@ network, making them also effectively no-overhead. <blockquote> <para> Currently, we patch Firefox to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2es... pipeline order and depth</ulink>. Unfortunately, pipelining is very fragile. Many sites do not support it, and even sites that advertise support for pipelining may simply return error codes for successive requests, effectively @@ -3035,7 +3157,7 @@ date. <para>
We also make use of the in-browser Mozilla updater, and have <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0es... +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2es... the updater</ulink> to avoid sending OS and Kernel version information as part of its update pings.
@@ -3637,16 +3759,17 @@ occurring. <listitem><command>The Referer Header</command> <para>
-When leaving a .onion domain we <ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&id=09188cb14dfaa8ac22f687c978166c7bd171b576"> -set the Referer header to the destination</ulink> to avoid leaking information -which might be especially problematic in the case of transitioning from a .onion -domain to one reached over clearnet. Apart from that we haven't disabled or -restricted the Referer ourselves because of the non-trivial number of sites -that rely on the Referer header to "authenticate" image requests and deep-link -navigation on their sites. Furthermore, there seems to be no real privacy -benefit to taking this action by itself in a vacuum, because many sites have -begun encoding Referer URL information into GET parameters when they need it to -cross HTTP to HTTPS scheme transitions. Google's +1 buttons are the best +When leaving a .onion domain we set the Referer header to the destination by +<ulink url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=021bffff111b6b93eecb5859e680d540991c20c9"> +providing a preference</ulink>, <command>network.http.referer.hideOnionSource</command>, and setting it to <command>true</command>. That avoids leaking +information which might be especially problematic in the case of transitioning +from a .onion domain to one reached over clearnet. Apart from that we haven't +disabled or restricted the Referer ourselves because of the non-trivial number +of sites that rely on the Referer header to "authenticate" image requests and +deep-link navigation on their sites. Furthermore, there seems to be no real +privacy benefit to taking this action by itself in a vacuum, because many sites +have begun encoding Referer URL information into GET parameters when they need +it to cross HTTP to HTTPS scheme transitions. Google's +1 buttons are the best example of this activity.
</para> @@ -3655,9 +3778,9 @@ example of this activity. Because of the availability of these other explicit vectors, we believe the main risk of the Referer header is through inadvertent and/or covert data leakage. In fact, <ulink -url="http://www2.research.att.com/~bala/papers/wosn09.pdf%22%3Ea great deal of -personal data</ulink> is inadvertently leaked to third parties through the -source URL parameters. +url="http://web2.research.att.com/export/sites/att_labs/people/Krishnamurthy_Bala... +a great deal of personal data</ulink> is inadvertently leaked to third parties +through the source URL parameters.
</para> <para> @@ -3684,7 +3807,7 @@ attribute. url="https://developer.mozilla.org/En/DOM/Window.name%22%3Ewindow.name</ulink> is a DOM property that for some reason is allowed to retain a persistent value for the lifespan of a browser tab. It is possible to utilize this property for -<ulink url="http://www.thomasfrank.se/sessionvars.html">identifier +<ulink url="https://www.thomasfrank.se/sessionvars.html">identifier storage</ulink> during click navigation. This is sometimes used for additional CSRF protection and federated login. </para> @@ -3723,14 +3846,15 @@ permissions. <sect1> <title>Promising Standards</title> <orderedlist> - <listitem><ulink url="http://web-send.org">Web-Send Introducer</ulink> + <listitem><ulink url="https://web.archive.org/web/20130213034335/http://web-send.org:80/">Web-Send Introducer</ulink> <para>
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 cross-origin link-click side channels. It has a compelling list of <ulink -url="http://web-send.org/features.html%22%3Eprivacy and security features</ulink>, -especially if used as a "Like button" replacement. +url="https://web.archive.org/web/20130213034335/http://web-send.org:80/featurs.ht... +privacy and security features</ulink>, especially if used as a "Like button" +replacement.
</para> </listitem>
tor-commits@lists.torproject.org
-
gk＠torproject.org