Changes

Page history
various design doc edits: authored by Richard Pospesel's avatar Richard Pospesel 
- replaced all legacy gitweb URLs to updated gitlab URLs
- factual inaccuracies opportunistically fixed when a URL update was required
- updated list of included pluggable transports
- updated various reference to patches to point to issues
- removed reference to patches which have since been uplifted
- reference upstream Mozilla isues in some cses
Show whitespace changes
Inline Side-by-side
Design-Documents/Tor-Browser-Design-Doc.md
View page @ 0839e5d9
......@@ -87,13 +87,13 @@ For more practical information regarding Tor Browser development, please consult
### 1.1. Browser Component Overview
The Tor Browser is based on [Mozilla's Extended Support Release (ESR) Firefox branch](https://www.mozilla.org/en-US/firefox/organizations/). We have a [series of patches](https://gitweb.torproject.org/tor-browser.git) against this browser to enhance privacy and security. Browser behavior is additionally augmented through the [Torbutton extension](https://gitweb.torproject.org/torbutton.git/tree/), though we are in the process of moving this functionality into direct Firefox patches. We also [change a number of Firefox preferences](https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-52.5.2esr-7.0-2) from their defaults.
The Tor Browser is based on [Mozilla's Extended Support Release (ESR) Firefox branch](https://www.mozilla.org/en-US/firefox/organizations/). We have a [series of patches](https://gitlab.torproject.org/tpo/applications/tor-browser) against this browser to enhance privacy and security. Browser behavior is additionally augmented through the [Torbutton extension](https://gitlab.torproject.org/tpo/applications/torbutton), though we are in the process of moving this functionality into direct Firefox patches. We also [change a number of Firefox preferences](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/main/browser/app/profile/000-tor-browser.js) from their defaults.
Tor process management and configuration is accomplished through the [Tor Launcher](https://gitweb.torproject.org/tor-launcher.git) addon, which provides the initial Tor configuration splash screen and bootstrap progress bar. Tor Launcher is also compatible with Thunderbird, Instantbird, and XULRunner.
Tor process management and configuration is accomplished through the [Tor Launcher](https://gitlab.torproject.org/tpo/applications/tor-launcher) addon, which provides the initial Tor configuration splash screen and bootstrap progress bar. Tor Launcher is also compatible with Thunderbird, Instantbird, and XULRunner.
To help protect against potential Tor Exit Node eavesdroppers, we include [HTTPS-Everywhere](https://www.eff.org/https-everywhere). To provide users with optional defense-in-depth against JavaScript and other potential exploit vectors, we also include [NoScript](https://noscript.net/). We also modify several extension preferences from their defaults.
To provide censorship circumvention in areas where the public Tor network is blocked either by IP, or by protocol fingerprint, we include several [Pluggable Transports](https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPluggableTransports) in the distribution. As of this writing, we include [Obfs3proxy, Obfs4proxy](https://gitweb.torproject.org/pluggable-transports/obfs4.git), [meek](https://trac.torproject.org/projects/tor/wiki/doc/meek), and [FTE](https://fteproxy.org/).
To provide censorship circumvention in areas where the public Tor network is blocked either by IP, or by protocol fingerprint, we include several [pluggable transports](https://gitlab.torproject.org/legacy/trac/-/wikis/doc/AChildsGardenOfPluggableTransports) in the distribution. As of this writing, we include the [lyrebird](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird) and [Snowflake](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake) pluggable transports in the stable Tor Browser release distribution. The [WebTunnel](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel) and [conjure](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure) pluggable transports are added additionally to the alpha Tor Browser release.
## 2. Design Requirements and Philosophy
......@@ -313,19 +313,13 @@ Proxy obedience is assured through the following:
1. **Firefox proxy settings, patches, and build flags**
Our [Firefox preferences file](https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-52.5.2esr-7.0-2) sets the Firefox proxy settings to use Tor directly as a SOCKS proxy. It sets `network.proxy.socks_remote_dns`, `network.proxy.socks_version`, `network.proxy.socks_port`, and `network.dns.disablePrefetch`.
Our [Firefox preferences file](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/main/browser/app/profile/000-tor-browser.js) sets the Firefox proxy settings to use Tor directly as a SOCKS proxy. It sets `network.proxy.socks_remote_dns`, `network.proxy.socks_version`, `network.proxy.socks_port`, and `network.dns.disablePrefetch`.
To prevent proxy bypass by WebRTC calls, we disable WebRTC at compile time with the `--disable-webrtc` configure switch, as well as set the pref `media.peerconnection.enabled` to false.
We also patch Firefox in order to provide several defense-in-depth mechanisms for proxy safety. Notably, we [patch the DNS service](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=35ce9974e034c0374fb3c8e00e9eb0231c4f3378) to prevent any browser or addon DNS resolution, and we also [remove the DNS lookup for the profile lock signature](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=ee28d8f27fdb1e47481987535c7da70095042ee2). Furthermore, we patch [OCSP and PKIX code](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=ffba8d1b84431b4024d5012b326cbcb986047f27) 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, but it seemed better safe than sorry.
We also patch Firefox in order to provide several defense-in-depth mechanisms for proxy safety. We patch [OCSP and PKIX code](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/13028) to prevent any use of the non-proxied command-line tool utility functions from being functional while linked in to the browser. We could find no direct paths to these routines in the browser, but it seemed better safe than sorry.
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 `devtools.webide.autoinstallADBHelper`, `devtools.webide.autoinstallFxdtAdapters`, `devtools.webide.enabled,` and `devtools.appmanager.enabled` to **false**. Moreover, we removed the Roku Screen Sharing and screencaster code with a [Firefox patch](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=055bdffbef68bc8d5e8005b3c7dd2f5d99da1163) as these features can bypass proxy settings as well.
Further down on our road to proxy safety we [disable the network tickler](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=7222d02638689a64d7297b8e5c202f9c37547523) as it has the capability to send UDP traffic and we [disable mDNS support](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=5bc957b4f635a659f9aecaa374972ecca7f770a8), since mDNS uses UDP packets as well. We also disable Mozilla's TCPSocket by setting `dom.mozTCPSocket.enabled` to **false**. We [intend to rip out](https://trac.torproject.org/projects/tor/ticket/18866) the TCPSocket code in the future to have an even more solid guarantee that it won't be used by accident.
Finally, we [remove](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=55bd129f081bd37ae9e72ae32434fbb56ff4e446) potentially unsafe Rust code.
During every Extended Support Release transition, we perform [in-depth code audits](https://gitweb.torproject.org/tor-browser-spec.git/tree/audits) to verify that there were no system calls or XPCOM activity in the source tree that did not use the browser proxy settings.
During every Extended Support Release transition, we perform [in-depth code audits](https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/tree/main/audits) to verify that there were no system calls or XPCOM activity in the source tree that did not use the browser proxy settings.
We have verified that these settings and patches properly proxy HTTPS, OCSP, HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all JavaScript activity, including HTML5 audio and video objects, addon updates, WiFi geolocation queries, searchbox queries, XPCOM addon HTTPS/HTTP activity, WebSockets, and live bookmark updates. We have also verified that external protocol helpers, such as SMB URLs and other custom protocol handlers are all blocked.
......@@ -337,21 +331,21 @@ Proxy obedience is assured through the following:
If the user does enable plugins in this way, plugin-handled objects are still restricted from automatic load through Firefox's click-to-play preference `plugins.click_to_play`.
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 [prevent the load of any plugins except for Flash and Gnash](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=95a0100fd8ac0fdbe9f517e9b7ea86d6b77ec2c9). Even for Flash and Gnash, we also patch Firefox to [prevent loading them into the address space](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=39f5a767c0c082b1e4a001cf685a6efb31bd62c6) until they are explicitly enabled.
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 prevent the load of any plugins except for Flash and Gnash. Even for Flash and Gnash, we also patch Firefox to prevent loading them into the address space until they are explicitly enabled.
With [Gecko Media Plugins](https://wiki.mozilla.org/GeckoMediaPlugins) (GMPs) a second type of plugins is available. They are mainly third party codecs and [EME](https://www.w3.org/TR/encrypted-media/) content decryption modules. We currently disable these plugins as they either 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 `--disable-eme` configure switch and set `browser.eme.ui.enabled`, `media.gmp-eme-adobe.visible`, `media.gmp-eme-adobe.enabled`, `media.gmp-widevinecdm.visible`, `media.gmp-widevinecdm.enabled`, `media.eme.enabled`, and `media.eme.apiVisible` to **false** 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 `media.gmp-manager.url.override` to `data:text/plain`, and avoid any UI with `media.gmp-provider.enabled` set to **false**. Moreover, we disable GMP downloads via local fallback by setting `media.gmp-manager.updateEnabled` to **false**. To reduce our attack surface we exclude the ClearKey EME system, too.
3. **External App Blocking and Drag Event Filtering**
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, we ship [Firefox](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=d179d8a4861199e203934ecc36dd6d8ade549dfa) [patches](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=99173c3a5f83d9ac44091a72c5570efd296dff8f) and Torbutton installs a component to [provide the user with a popup](https://gitweb.torproject.org/torbutton.git/tree/src/components/external-app-blocker.js) whenever the browser attempts to launch a helper application.
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, we ship [Firefox](https://gitlab.torproject.org/legacy/trac/-/issues/8324) [patches](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41613) and Torbutton installs a component to provide the user with a popup whenever the browser attempts to launch a helper application.
Furthermore, we ship a [patch for Linux users](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=d75b79f6fa920e6a1e3043005dfd50060ea70e57) 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/GnomeVFS support. And proxy bypass risks due to `file://` URLs should be mitigated for macOS and Linux users by [two](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=8db44df10d1d82850e8b4cfe81ac3b5fce32a663) [further patches](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=a8e1fcc8678aa1583f73ef231c99f77cf17196d9).
Furthermore, we ship a [patch for Linux users](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/23044) 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/GnomeVFS support.
Additionally, modern desktops now preemptively fetch any URLs in Drag and Drop events as soon as the drag is initiated. This download happens independent of the browser's Tor settings, and can be triggered by something as simple as holding the mouse button down for slightly too long while clicking on an image link. We filter drag and drop events events [from Torbutton](https://gitweb.torproject.org/torbutton.git/tree/src/components/external-app-blocker.js) before the OS downloads the URLs the events contained.
Additionally, modern desktops now preemptively fetch any URLs in Drag and Drop events as soon as the drag is initiated. This download happens independent of the browser's Tor settings, and can be triggered by something as simple as holding the mouse button down for slightly too long while clicking on an image link. We filter drag and drop events events [from Torbutton](https://gitlab.torproject.org/tpo/applications/torbutton/-/blob/main/components/external-app-blocker.js) before the OS downloads the URLs the events contained.
4. **Disabling system extensions and clearing the addon whitelist**
Firefox addons can perform arbitrary activity on your computer, including bypassing Tor. It is for this reason we disable the addon whitelist (`xpinstall.whitelist.add`), so that users are prompted before installing addons regardless of the source. We also exclude system-level addons from the browser through the use of `extensions.enabledScopes` and `extensions.autoDisableScopes`. Furthermore, we set `extensions.systemAddon.update.url` and `extensions.hotfix.id` to an empty string in order to avoid the risk of getting extensions installed by Mozilla into Tor Browser, and remove unused system extensions with a [Firefox patch](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=4d90fcf15e328ca369751011ad0a9c0c1ba2f153). In order to make it harder for users to accidentally install extensions which Mozilla presents to them on the *about:addons* page, we hide the *Get Addons* option on it by setting `extensions.getAddons.showPane` to **false**.
Firefox addons can perform arbitrary activity on your computer, including bypassing Tor. It is for this reason we disable the addon whitelist (`xpinstall.whitelist.add`), so that users are prompted before installing addons regardless of the source. We also exclude system-level addons from the browser through the use of `extensions.enabledScopes` and `extensions.autoDisableScopes`. Furthermore, we set `extensions.systemAddon.update.url` and `extensions.hotfix.id` to an empty string in order to avoid the risk of getting extensions installed by Mozilla into Tor Browser, and remove unused system extensions with a [Firefox patch](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/21431). In order to make it harder for users to accidentally install extensions which Mozilla presents to them on the *about:addons* page, we hide the *Get Addons* option on it by setting `extensions.getAddons.showPane` to **false**.
### 4.2. State Separation
......@@ -363,8 +357,6 @@ Tor Browser State is separated from existing browser state through use of a cust
**Implementation Status**: We are working towards this goal through several mechanisms. First, we set the Firefox Private Browsing preference `browser.privatebrowsing.autostart` to **true**. We also had to disable the media cache with the pref `media.cache_size`, to prevent HTML5 videos from being written to the OS temporary directory, which happened regardless of the private browsing mode setting. Finally, we set `security.nocertdb` to **true** to make the intermediate certificate store memory-only.
Moreover, we prevent text leaking from the web console to the /tmp directory with a direct [Firefox patch](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=48b68533d113c5998d19d4e5acfb8967ba2d5f5b).
As an additional defense-in-depth measure, we set `browser.cache.disk.enable`, `browser.cache.offline.enable`, `signon.rememberSignons`, `browser.formfill.enable` to **true**, `browser.download.manager.retention` to **1**, and both `browser.sessionstore.privacy_level` and `network.cookie.lifetimePolicy` to **2**. Many of these preferences are likely redundant with `browser.privatebrowsing.autostart` enabled, but we have not done the auditing work to ensure that yet.
For more details on disk leak bugs and enhancements, see the [tbb-disk-leak tag in our bugtracker](https://trac.torproject.org/projects/tor/query?keywords=~tbb-disk-leak&status=!closed).
......@@ -434,9 +426,7 @@ Unfortunately, many aspects of browser state can serve as identifier storage, an
**Design Goal**: 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.
**Implementation Status**: The isolation functionality is provided by a Torbutton component that [sets the SOCKS username and password for each request](https://gitweb.torproject.org/torbutton.git/tree/src/components/domain-isolator.js). 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 connections with SOCKS proxies do not re-use existing HTTP Keep-Alive connections unless the proxy settings match. [We extended this logic](https://bugzilla.mozilla.org/show_bug.cgi?id=1200802) to cover SOCKS username and password authentication, providing us with HTTP Keep-Alive unlinkability.
While the vast majority of web requests adheres to the circuit and connection unlinkability requirement there are still corner cases we [need to treat separately](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=8661822237c56d543d5c9117c8a4708c402a110f) or that [lack a fix altogether](https://bugs.torproject.org/22343).
**Implementation Status**: The isolation functionality is provided by a Torbutton component that [sets the SOCKS username and password for each request](https://gitlab.torproject.org/tpo/applications/torbutton/-/blob/main/components/domain-isolator.js). 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 connections with SOCKS proxies do not re-use existing HTTP Keep-Alive connections unless the proxy settings match. [We extended this logic](https://bugzilla.mozilla.org/show_bug.cgi?id=1200802) to cover SOCKS username and password authentication, providing us with HTTP Keep-Alive unlinkability.
9. **SharedWorkers**
......@@ -496,7 +486,7 @@ Unfortunately, many aspects of browser state can serve as identifier storage, an
**Design Goal**: 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.
**Implementation Status**: Favicon requests are isolated to the URL bar domain by setting `privacy.firstparty.isolate` to **true**. However, we need an additional [Firefox patch](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=eaa22334adaf8f79544ee4318982e5f4990c1a6f) to take care of favicons in tab list menuitems.
**Implementation Status**: Favicon requests are isolated to the URL bar domain by setting `privacy.firstparty.isolate` to **true**.
19. **mediasource: URIs and MediaStreams**
......@@ -518,7 +508,7 @@ Unfortunately, many aspects of browser state can serve as identifier storage, an
**Design Goal**: Permissions MUST be isolated to the URL bar domain.
**Implementation Status**: Right now we provide a [Firefox patch](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=14374d30767f83923561084530b54c066bb661b4) that makes sure permissions are isolated to the URL bar domain.
**Implementation Status**: This functionality is provided by setting `privacy.firstparty.isolate` to **true**.
For more details on identifier linkability bugs and enhancements, see the [tbb-linkability tag in our bugtracker](https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability&status=!closed).
......@@ -632,17 +622,17 @@ Where our actual implementation differs from an ideal solution, we separately de
After plugins and plugin-provided information, we believe that the [HTML5 Canvas](https://developer.mozilla.org/en-US/docs/HTML/Canvas) is the single largest fingerprinting threat browsers face today. [Studies](https://cseweb.ucsd.edu/~hovav/dist/canvas.pdf) [show](https://securehomes.esat.kuleuven.be/~gacar/persistent/the_web_never_forgets.pdf) that the Canvas can provide an easy-access fingerprinting target: The adversary simply renders WebGL, font, and named color data to a Canvas element, extracts the image buffer, and computes a hash of that image data. Subtle differences in the video card, font packs, and even font and graphics library versions allow the adversary to produce a stable, simple, high-entropy fingerprint of a computer. In fact, the hash of the rendered image can be used almost identically to a tracking cookie by the web server.
In some sense, the canvas can be seen as the union of many other 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 [prompt before returning valid image data](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=196354d7951a48b4e6f5309d2a8e46962fff9d5f) 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 image data, pure white image data is returned to the JavaScript APIs. Extracting canvas image data by third parties is not allowed, though.
In some sense, the canvas can be seen as the union of many other 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, we gate canvas reading and related functionality behind a site permission. This functionality is provided by setting `privacy.resistFingerprinting` to **true**. If the user hasn't previously allowed the site in the URL bar to access Canvas image data, pure white image data is returned to the JavaScript APIs. Extracting canvas image data by third parties is not allowed, though.
3. **Open TCP Port and Local Network Fingerprinting**
In Firefox, by using either WebSockets or XHR, it is possible for remote content to [enumerate the list of TCP ports open on 127.0.0.1](http://www.andlabs.org/tools/jsrecon.html), as well as on any other machines on the local network. In other browsers, this can be accomplished by DOM events on image or script tags. This open vs filtered vs closed port list can provide a very unique fingerprint of a machine, because it essentially enables the detection of many different popular third party applications and optional system services (Skype, Bitcoin, Bittorrent and other P2P software, SSH ports, SMB and related LAN services, CUPS and printer daemon config ports, mail servers, and so on). It is also possible to determine when ports are closed versus filtered/blocked (and thus probe custom firewall configuration).
In Tor Browser, we prevent access to 127.0.0.1/localhost by ensuring that even these requests are still sent by Firefox to our SOCKS proxy (ie we set `network.proxy.no_proxies_on` 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. 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. Additionally, we [rip out](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=13baf9df4b47bd13bb7da045048ed4339615ac03) the option to collect local IP addresses via the NetworkInfoService.
In Tor Browser, we prevent access to 127.0.0.1/localhost by ensuring that even these requests are still sent by Firefox to our SOCKS proxy (ie we set `network.proxy.no_proxies_on` 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. 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.
4. **Invasive Authentication Mechanisms (NTLM and SPNEGO)**
Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in some cases the current username. The only reason why these aren't a more serious problem is that they typically involve user interaction, and likely aren't an attractive vector for this reason. However, because it is not clear if certain carefully-crafted error conditions in these protocols could cause them to reveal machine information and still fail silently prior to the password prompt, these authentication mechanisms should either be disabled, or placed behind a site permission before their use. We simply disable them [with a patch](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=fe465944545a76287842321175cc7713091e77b1).
Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in some cases the current username. The only reason why these aren't a more serious problem is that they typically involve user interaction, and likely aren't an attractive vector for this reason. However, because it is not clear if certain carefully-crafted error conditions in these protocols could cause them to reveal machine information and still fail silently prior to the password prompt, these authentication mechanisms should either be disabled, or placed behind a site permission before their use. This has been resolved upstream in the fix for [Mozilla 1046421](https://bugzilla.mozilla.org/show_bug.cgi?id=1046421).
5. **USB Device ID Enumeration via the GamePad API**
......@@ -658,7 +648,7 @@ Where our actual implementation differs from an ideal solution, we separately de
**Implementation Status**: We investigated shipping a predefined set of fonts to all of our users allowing only those fonts to be used by websites at the exclusion of system fonts. We are currently following this approach, which has been suggested by researchers previously. This defense is available for all three supported platforms: Windows, macOS, and Linux, although the implementations vary in detail.
For Windows and macOS we use a preference, `font.system.whitelist`, to restrict fonts being used to those in the whitelist. This functionality is provided by setting `privacy.resistFingerprinting` to **true**. The whitelist for Windows and macOS contains both a set of [Noto fonts](https://www.google.com/get/noto) which we bundle and fonts provided by the operating system. For Linux systems we only bundle fonts and [deploy](https://gitweb.torproject.org/builders/tor-browser-bundle.git/commit/?id=b88443f6d8af62f763b069eb15e008a46d9b468a) a fonts.conf file to restrict the browser to use those fonts exclusively. In addition to that we set the `font.name.*` preferences for macOS and Linux to make sure that a given code point is always displayed with the same font. This is not guaranteed even if we bundle all the fonts Tor Browser uses as it can happen that fonts are loaded in a different order on different systems. Setting the above mentioned preferences works around this issue by specifying the font to use explicitly.
For Windows and macOS we use a preference, `font.system.whitelist`, to restrict fonts being used to those in the whitelist. This functionality is provided by setting `privacy.resistFingerprinting` to **true**. The whitelist for Windows and macOS contains both a set of [Noto fonts](https://www.google.com/get/noto) which we bundle and fonts provided by the operating system. For Linux systems we only bundle fonts and [deploy](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/main/projects/browser/Bundle-Data/linux/Data/fontconfig/fonts.conf) a fonts.conf file to restrict the browser to use those fonts exclusively. In addition to that we set the `font.name.*` preferences for macOS and Linux to make sure that a given code point is always displayed with the same font. This is not guaranteed even if we bundle all the fonts Tor Browser uses as it can happen that fonts are loaded in a different order on different systems. Setting the above mentioned preferences works around this issue by specifying the font to use explicitly.
Allowing fonts provided by the operating system for Windows and macOS users is currently a compromise between fingerprintability resistance and usability concerns. We are still investigating the right balance between them and have created a [ticket in our bug tracker](https://trac.torproject.org/projects/tor/ticket/18097) to summarize the current state of our defense and future work that remains to be done.
......@@ -676,13 +666,13 @@ Where our actual implementation differs from an ideal solution, we separately de
**Design Goal**: A website MUST NOT be able infer anything that the user has configured about their computer. Additionally, it SHOULD NOT be able to infer machine-specific details such as screen orientation or type.
**Implementation Status**: We set `ui.use_standins_for_native_colors` to **true** and provide a [Firefox patch](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=9e84b962ae4e7369fcf13fdf3adb646877d48f1d) to report a fixed set of system colors to content window CSS, and prevent detection of font smoothing on macOS with the help of `privacy.resistFingerprinting` set to **true**. We use the same preference, too, to always report landscape-primary for the [screen orientation](https://w3c.github.io/screen-orientation/).
**Implementation Status**: We set `ui.use_standins_for_native_colors` to **true** to report a fixed set of system colors to content window CSS, and prevent detection of font smoothing on macOS with the help of `privacy.resistFingerprinting` set to **true**. We use the same preference, too, to always report landscape-primary for the [screen orientation](https://w3c.github.io/screen-orientation/).
9. **WebGL**
WebGL is fingerprintable both through information that is exposed about the underlying driver and optimizations, as well as through performance fingerprinting.
Because of the large amount of potential fingerprinting vectors and the [previously unexposed vulnerability surface](https://www.contextis.com/resources/blog/webgl-new-dimension-browser-exploitation/), 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 `webgl.disable-extensions`, `webgl.min_capability_mode`, and `webgl.disable-fail-if-major-performance-caveat` to **true** which reduces the information provided by the following WebGL API calls: `getParameter()`, `getSupportedExtensions()`, and `getExtension()`. Furthermore, WebGL2 is disabled by `setting webgl.enable-webgl2` to **false**. To make the minimal WebGL mode usable we additionally [normalize its properties with a Firefox patch](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=1acd0c7fae9121240401cf4a8f0e2b1f6fdb9827).
Because of the large amount of potential fingerprinting vectors and the [previously unexposed vulnerability surface](https://www.contextis.com/resources/blog/webgl-new-dimension-browser-exploitation/), 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 `webgl.disable-extensions`, `webgl.min_capability_mode`, and `webgl.disable-fail-if-major-performance-caveat` to **true** which reduces the information provided by the following WebGL API calls: `getParameter()`, `getSupportedExtensions()`, and `getExtension()`. Furthermore, WebGL2 is disabled by `setting webgl.enable-webgl2` to **false**. Making the minimal WebGL mode usable is accomplished in [Mozilla 1217290](https://bugzilla.mozilla.org/show_bug.cgi?id=1217290).
Another option for WebGL might be to use software-only rendering, using a library such as [Mesa](https://www.mesa3d.org/). The use of such a library would avoid hardware-specific rendering differences.
......@@ -700,7 +690,7 @@ Where our actual implementation differs from an ideal solution, we separately de
13. **Touch API**
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 `dom.w3c_touch_events.enabled` to **false**. 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 `Touch.radiusX`, `Touch.radiusY`, and `Touch.rotationAngle` does not leak further information and `Touch.force` does not reveal how much pressure a user applied to the surface. That is achieved by a direct [Firefox patch](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=7d9701c2b6a203b1b7a556f614858588e3e5976e) which reports back **1** for the first two properties and **0.0** for the two last ones.
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 `dom.w3c_touch_events.enabled` to **false**. 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 `Touch.radiusX`, `Touch.radiusY`, and `Touch.rotationAngle` does not leak further information and `Touch.force` does not reveal how much pressure a user applied to the surface. This is accomplished by reporting back **1** for the first two properties and **0.0** for the two last ones thanks to [Mozilla 1382499](https://bugzilla.mozilla.org/show_bug.cgi?id=1382499) when `privacy.resistFingerprinting` is set to **true**
14. **Battery Status API**
......@@ -716,7 +706,7 @@ Where our actual implementation differs from an ideal solution, we separately de
**Design Goal**: Websites MUST NOT be able to infer any information about the keyboard of a Tor Browser user.
**Implementation Status**: We provide [two](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=d6d29f155e60c63b38918c8879ee221b9c90b1f7) [Firefox patches](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=789bad5fe5a7a0c2d27e1d8dd7b9a7e35de91cc8) that take care of spoofing `KeyboardEvent.code` and `KeyboardEvent.keyCode` 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 are currently returning an empty `KeyboardEvent.code` and a `KeyboardEvent.keyCode` of 0. Moreover, neither `Alt` or `Shift`, or `AltGr` keyboard events are reported to content.
**Implementation Status**: [Mozilla 1222285](https://bugzilla.mozilla.org/show_bug.cgi?id=1222285) takes care of spoofing `KeyboardEvent.code` and `KeyboardEvent.keyCode` 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 are currently returning an empty `KeyboardEvent.code` and a `KeyboardEvent.keyCode` of 0. Moreover, neither `Alt` or `Shift`, or `AltGr` keyboard events are reported to content. This functionality is provided by setting `privacy.resistFingerprinting` to **true**
We are currently not taking the actually deployed browser locale or the locale indicated by a loaded document into account when spoofing the keyboard layout. We think that would be the right thing to do in the longer run, to mitigate possible usability issues and broken functionality on websites. Similarily to how users of non-english Tor Browser bundles right now can choose between keeping the Accept header spoofed or not they would then be able to keep a spoofed english keyboard or a spoofed one depending on the actual Tor Browser locale or language of the document.
......@@ -724,7 +714,7 @@ Where our actual implementation differs from an ideal solution, we separately de
**Design Goal**: All Tor Browser users MUST provide websites with an identical user agent and HTTP header set for a given request type. We omit the Firefox minor revision, and report a popular Windows platform. If the software is kept up to date, these headers should remain identical across the population even when updated.
**Implementation Status**: 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 [remove content script access](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=bd51d0c24d339c5135028297f5eeb591a65e99df) to Components.interfaces, which [can be used](http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html) to fingerprint OS, platform, and Firefox minor version.
**Implementation Status**: 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.
18. **Timing-based Side Channels**
......@@ -734,7 +724,7 @@ Where our actual implementation differs from an ideal solution, we separately de
**Implementation Status**: The cleanest solution to timing-based side channels would be to get rid of them. This has been [proposed](https://acmccs.github.io/papers/p163-caoA.pdf) in the research community. However, we remain skeptical as it does not seem to be trivial even considering just a [single](https://bugzilla.mozilla.org/show_bug.cgi?id=711043) [side channel](https://cseweb.ucsd.edu/~dkohlbre/papers/subnormal.pdf) and [more and more potential side channels](https://gruss.cc/files/fantastictimers.pdf) 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.
We set `dom.enable_user_timing` and `dom.enable_resource_timing` to **false** to disable these explicit timing sources. Furthermore, we clamp the resolution of explicit clocks to 100ms [with two Firefox](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=1736ea256276546c899d712dffdae2c8d050d8a0) [patches](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=a4c6d2c07d483acfd729c7a50dd3f7b07fcba03a). This includes `performance.now()`, `new Date().getTime()`, `audioContext.currentTime`, `canvasStream.currentTime`, `video.currentTime`, `audio.currentTime`, `new File([], "").lastModified` , `new File([], "").lastModifiedDate.getTime()`, `animation.startTime`, `animation.currentTime`, `animation.timeline.currentTime`, and `document.timeline.currentTime`.
We set `dom.enable_user_timing` and `dom.enable_resource_timing` to **false** to disable these explicit timing sources. Furthermore, we clamp the resolution of explicit clocks to 100ms by setting `privacy.resistFingerprinting` to **true** thanks to [Mozilla 1217238](https://bugzilla.mozilla.org/show_bug.cgi?id=1217238). This includes `performance.now()`, `new Date().getTime()`, `audioContext.currentTime`, `canvasStream.currentTime`, `video.currentTime`, `audio.currentTime`, `new File([], "").lastModified` , `new File([], "").lastModifiedDate.getTime()`, `animation.startTime`, `animation.currentTime`, `animation.timeline.currentTime`, and `document.timeline.currentTime`.
While clamping the clock resolution to 100ms is a step towards mitigating timing-based side channel fingerprinting, it is by no means sufficient. It turns out that it is possible to subvert our clamping of explicit clocks by using [implicit ones](https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_kohlbrenner.pdf), e.g. extrapolating the true time by running a busy loop with a predictable operation in it. We are tracking [this problem](https://trac.torproject.org/projects/tor/ticket/16110) in our bug tracker and are working with the research community and Mozilla to develop and test a proper solution to this part of our defense against timing-based side channel fingerprinting risks.
......@@ -742,13 +732,11 @@ Where our actual implementation differs from an ideal solution, we separately de
Due to [bugs in Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=1120398) it is possible to detect the locale and the platform of a Tor Browser user. Moreover, it is possible to [find out the extensions](https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-sanchez-rola.pdf) a user has installed. This is done by including `resource://` and/or `chrome://` URIs into web content, which point to resources included in Tor Browser itself or in installed extensions, and exploiting the different behavior resulting out of that: the browser raises an exception if a webpage requests a resource but the extension is not installed. This does not happen if the extension is indeed installed but the resource path does not exist.
We believe that it should be impossible for web content to extract information out of a Tor Browser user by deploying `resource://` and/or `chrome://` URIs. Until this is fixed in Firefox [we filter](https://gitweb.torproject.org/torbutton.git/tree/src/components/content-policy.js) `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. There are 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.
20. **Locale Fingerprinting**
In Tor Browser, we provide non-English users the option of concealing their OS and browser locale from websites. It is debatable if this should be as high of a priority as information specific to the user's computer, but for completeness, we attempt to maintain this property.
**Implementation Status**: We set the fallback character set to set to windows-1252 for all locales, via `intl.charset.default`. We also set `javascript.use_us_english_locale` to **true** 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 [en-US label for the isindexHTML element](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=d144738fedeeb23746d7a9f16067bd985b0d59aa) instead of letting the label leak the browser's UI locale.
**Implementation Status**: We set the fallback character set to set to windows-1252 for all locales, via `intl.charset.default`. We also set `javascript.use_us_english_locale` to **true** to instruct the JS engine to use en-US as its internal C locale for all Date, Math, and exception handling.
21. **Timezone and Clock Offset**
......@@ -756,7 +744,7 @@ Where our actual implementation differs from an ideal solution, we separately de
**Design Goal**: 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 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 [tlsdate](https://github.com/ioerror/tlsdate).
**Implementation Status**: We [set the timezone to UTC](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=dd1ba0b5c9281ee3207e5a87991159b8d2609a11) 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, [we make sure](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=008649e2ce0357f31eb67d874e6429c39ddd7e8f) the TZ environment variable is respected by the [ICU library](http://site.icu-project.org/) as well.
**Implementation Status**: We set the timezone to UTC by setting `privacy.resistFingerprinting` to **true** thanks to [Mozilla 1330890](https://bugzilla.mozilla.org/show_bug.cgi?id=1330890).
22. **JavaScript Performance Fingerprinting**
......@@ -772,7 +760,7 @@ Where our actual implementation differs from an ideal solution, we separately de
**Design Goal**: We intend to rely on the same mechanisms for defeating JavaScript performance fingerprinting: timestamp quantization and jitter.
**Implementation Status**: We clamp keyboard event resolution to 100ms with a [Firefox patch](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=1736ea256276546c899d712dffdae2c8d050d8a0).
**Implementation Status**: We clamp keyboard event resolution to 100ms by setting `privacy.resistFingerprinting` to **true** thanks to [Mozilla 1217238](https://bugzilla.mozilla.org/show_bug.cgi?id=1217238).
24. **Amount of Processor Cores (hardwareConcurrency)**
......@@ -804,7 +792,7 @@ Where our actual implementation differs from an ideal solution, we separately de
Tor Browser is based on Firefox which is a Mozilla product. Quite naturally, Mozilla is interested in making users aware of new features and in gathering information to learn about the most pressing needs Firefox users are facing. This is often implemented by contacting Mozilla services, be it for displaying further information about a new feature or by [sending (aggregated) data back for analysis](https://wiki.mozilla.org/Telemetry). While some of those mechanisms are disabled by default on release channels (such as telemetry data) others are not. We make sure that none of those Mozilla services are contacted to avoid possible fingerprinting risks.
In particular, we disable GeoIP-based search results by setting `browser.search.countryCode` and `browser.search.region` to **US** and `browser.search.geoip.url` to the empty string. Furthermore, we disable Selfsupport and Unified Telemetry by setting `browser.selfsupport.enabled` and `toolkit.telemetry.unified` to **false** and we make sure no related ping is reaching Mozilla by setting `datareporting.healthreport.about.reportUrlUnified` to **data:text/plain,**. The same is done with `datareporting.healthreport.about.reportUrl` and the new tiles feature related `browser.newtabpage.directory.ping` and `browser.newtabpage.directory.source` preferences. `browser.newtabpage.remote` is set to **false** in this context as well, as a defense-in-depth given that this feature is already of by default. Additionally, we disable the UITour backend by setting `browser.uitour.enabled` to **false** and avoid getting Mozilla experiments installed into Tor Browser by flipping `experiments.enabled` to **false**. On the update side we prevent the browser from pinging the new [Kinto](https://wiki.mozilla.org/Firefox/Kinto) service for blocklist updates as it is not used for it yet anyway. This is done by setting `services.blocklist.update_enabled` to **false**. The captive portal detection code is disabled as well as it phones home to Mozilla. We set `network.captive-portal-service.enabled` to **false** to achieve that. Unrelated to that we make sure that Mozilla does not get bothered with TLS error reports from Tor Browser users by hiding the respective checkbox with `security.ssl.errorReporting.enabled` set to **false**. And while we have the Push API disabled as there are no Service Workers available in Tor Browser yet, we remove the value for `dom.push.serverURL` as a defense-in-depth. Finally, we provide [a patch](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=9f24ce35cd8776a0f7c3a4d54992ecb0eaad6311) to prevent Mozilla's websites from querying whether particular extensions are installed and what their state in Tor Browser is by using the `window.navigator.AddonManager` 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.
In particular, we disable GeoIP-based search results by setting `browser.search.countryCode` and `browser.search.region` to **US** and `browser.search.geoip.url` to the empty string. Furthermore, we disable Selfsupport and Unified Telemetry by setting `browser.selfsupport.enabled` and `toolkit.telemetry.unified` to **false** and we make sure no related ping is reaching Mozilla by setting `datareporting.healthreport.about.reportUrlUnified` to **data:text/plain,**. The same is done with `datareporting.healthreport.about.reportUrl` and the new tiles feature related `browser.newtabpage.directory.ping` and `browser.newtabpage.directory.source` preferences. `browser.newtabpage.remote` is set to **false** in this context as well, as a defense-in-depth given that this feature is already of by default. Additionally, we disable the UITour backend by setting `browser.uitour.enabled` to **false** and avoid getting Mozilla experiments installed into Tor Browser by flipping `experiments.enabled` to **false**. On the update side we prevent the browser from pinging the new [Kinto](https://wiki.mozilla.org/Firefox/Kinto) service for blocklist updates as it is not used for it yet anyway. This is done by setting `services.blocklist.update_enabled` to **false**. The captive portal detection code is disabled as well as it phones home to Mozilla. We set `network.captive-portal-service.enabled` to **false** to achieve that. Unrelated to that we make sure that Mozilla does not get bothered with TLS error reports from Tor Browser users by hiding the respective checkbox with `security.ssl.errorReporting.enabled` set to **false**. And while we have the Push API disabled as there are no Service Workers available in Tor Browser yet, we remove the value for `dom.push.serverURL` as a defense-in-depth. Finally, we set `privacy.resistFingerprinting.block_mozAddonManager` to **true** to prevent Mozilla's websites from querying whether particular extensions are installed and what their state in Tor Browser is by using the `window.navigator.AddonManager` API.
We have [Safebrowsing](https://wiki.mozilla.org/Security/Safe_Browsing) disabled in Tor Browser. In order to avoid pinging providers for list updates we remove the entries for `browser.safebrowsing.provider.mozilla.updateURL` and `browser.safebrowsing.provider.mozilla.gethashURL` (and the values for Google related preferences as well).
......@@ -862,9 +850,7 @@ In addition to the above mechanisms that are devoted to preserving privacy while
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 [HTTPOS](https://freehaven.net/anonbib/cache/LZCLCP_NDSS11.pdf) and [better use of HTTP pipelining and/or SPDY](https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting). In the tunable/low-overhead category, we have [Adaptive Padding](https://arxiv.org/abs/1512.00524) and [Congestion-Sensitive BUFLO](https://www3.cs.stonybrook.edu/~xcai/fp.pdf). It may be also possible to [tune such defenses](https://trac.torproject.org/projects/tor/ticket/7028) such that they only use existing spare Guard bandwidth capacity in the Tor network, making them also effectively no-overhead.
**Implementation Status**: Currently, we patch Firefox to [randomize pipeline order and depth](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=b9fa77472aa67e26bd46a5ca889b20ce3448f9d1). 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 forcing the browser into non-pipelined behavior. Firefox also has code to back off and reduce or eliminate the pipeline if this happens. These shortcomings and fallback behaviors are the primary reason that Google developed SPDY as opposed to simply extending HTTP to improve pipelining. It turns out that we could actually deploy exit-side proxies that allow us to [use SPDY from the client to the exit node](https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-using-spdy.txt). This would make our defense not only free, but one that actually improves performance.
Knowing this, we created this defense as an [experimental research prototype](https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting) to help evaluate what could be done in the best case with full server support. Unfortunately, the bias in favor of compelling attack papers has caused academia to ignore this request thus far, instead publishing only cursory (yet "devastating") evaluations that fail to provide even simple statistics such as the rates of actual pipeline utilization during their evaluations, in addition to the other shortcomings and shortcuts mentioned earlier. We can accept that our defense might fail to work as well as others (in fact we expect it), but unfortunately the very same shortcuts that provide excellent attack results also allow the conclusion that all defenses are broken forever. So sadly, we are still left in the dark on this point.
**Implementation Status**: Nothing?
3. **Privacy-preserving update notification**
......@@ -872,7 +858,7 @@ In addition to the above mechanisms that are devoted to preserving privacy while
If the check fails, we cache this fact, and update the Torbutton graphic to display a flashing warning icon and insert a menu option that provides a link to our download page. Additionally, we reset the value for the browser homepage to point to a [page that informs the user](https://check.torproject.org/?lang=en-US&small=1&uptodate=0) that their browser is out of date.
We also make use of the in-browser Mozilla updater, and have [patched the updater](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=0efd496826cc3dfb0a6874d150e8acecd4eb6a92) to avoid sending OS and Kernel version information as part of its update pings.
We also make use of the in-browser Mozilla updater, and have [patched the updater](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/4234) to avoid sending OS and Kernel version information as part of its update pings.
## 5. Build Security and Package Integrity
......@@ -884,7 +870,7 @@ The GNU toolchain has been working on providing reproducible builds for some tim
For this reason, we decided to leverage the work done by the [Gitian Project](https://gitian.org/) from the Bitcoin community. Gitian is a wrapper around Ubuntu's virtualization tools that allows you to specify an Ubuntu or Debian version, architecture, a set of additional packages, a set of input files, and a bash build scriptlet in an YAML document called a "Gitian Descriptor". This document is used to install a qemu-kvm image, and execute your build scriptlet inside it.
We have created a [set of wrapper scripts](https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/refs/heads/master) around Gitian to automate dependency download and authentication, as well as transfer intermediate build outputs between the stages of the build process. Because Gitian creates a Linux build environment, we must use cross-compilation to create packages for Windows and macOS. For Windows, we use mingw-w64 as our cross compiler. For macOS, we use cctools and clang and a binary redistribution of the Mac OS 10.7 SDK.
We have created a set of wrapper scripts around Gitian to automate dependency download and authentication, as well as transfer intermediate build outputs between the stages of the build process. Because Gitian creates a Linux build environment, we must use cross-compilation to create packages for Windows and macOS. For Windows, we use mingw-w64 as our cross compiler. For macOS, we use cctools and clang and a binary redistribution of the Mac OS 10.7 SDK.
The use of the Gitian system eliminates build non-determinism by normalizing the build environment's hostname, username, build path, uname output, toolchain versions, and time. On top of what Gitian provides, we also had to address the following additional sources of non-determinism:
......@@ -892,15 +878,15 @@ The use of the Gitian system eliminates build non-determinism by normalizing the
The most prevalent source of non-determinism in the components of Tor Browser by far was various ways that archives (such as zip, tar, jar/ja, DMG, and Firefox manifest lists) could be reordered. Many file archivers walk the file system in inode structure order by default, which will result in ordering differences between two different archive invocations, especially on machines of different disk and hardware configurations.
The fix for this is to perform an additional sorting step on the input list for archives, but care must be taken to instruct libc and other sorting routines to use a fixed locale to determine lexicographic ordering, or machines with different locale settings will produce different sort results. We chose the 'C' locale for this purpose. We created wrapper scripts for [tar](https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/build-helpers/dtar.sh), [zip](https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/build-helpers/dzip.sh), and [DMG](https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/build-helpers/ddmg.sh) to aid in reproducible archive creation.
The fix for this is to perform an additional sorting step on the input list for archives, but care must be taken to instruct libc and other sorting routines to use a fixed locale to determine lexicographic ordering, or machines with different locale settings will produce different sort results. We chose the 'C' locale for this purpose. We created wrapper scripts for tar, zip, and DMG to aid in reproducible archive creation.
2. **Uninitialized memory in toolchain/archivers**
We ran into difficulties with both binutils and the DMG archive script using uninitialized memory in certain data structures that ended up written to disk. Our binutils fixes were merged upstream, but the DMG archive fix remains an [independent patch](https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/patches/libdmg.patch).
We ran into difficulties with both binutils and the DMG archive script using uninitialized memory in certain data structures that ended up written to disk. Our binutils fixes were merged upstream, but the DMG archive fix remains an independent patch.
3. **Fine-grained timestamps and timezone leaks**
The standard way of controlling timestamps in Gitian is to use libfaketime, which hooks time-related library calls to provide a fixed timestamp. However, due to our use of wine to run py2exe for python-based pluggable transports, pyc timestamps had to be addressed with an additional [helper script](https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/build-helpers/pyc-timestamp.sh). The timezone leaks were addressed by setting the `TZ` environment variable to UTC in our descriptors.
The standard way of controlling timestamps in Gitian is to use libfaketime, which hooks time-related library calls to provide a fixed timestamp. However, due to our use of wine to run py2exe for python-based pluggable transports, pyc timestamps had to be addressed with an additional helper script. The timezone leaks were addressed by setting the `TZ` environment variable to UTC in our descriptors.
4. **Deliberately generated entropy**
......@@ -946,7 +932,7 @@ Because the total elimination of side channels during cross-origin navigation wi
1. **The Referer Header**
When leaving a .onion domain we set the Referer header to an empty string by [providing a preference](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=021bffff111b6b93eecb5859e680d540991c20c9), `network.http.referer.hideOnionSource`, and setting it to **true**. 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.
When leaving a .onion domain we set the Referer header to an empty string by setting the `network.http.referer.hideOnionSource` preference to **true**. 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.
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, [a great deal of personal data](http://web2.research.att.com/export/sites/att_labs/people/Krishnamurthy_Balachander/papers/wosn09.pdf) is inadvertently leaked to third parties through the source URL parameters.
......
......