Design-Documents/Tor-Browser-Design-Doc.md

@@ -78,7 +78,7 @@ June 15, 2018
 
 ## 1. Introduction
 
-This document describes the [adversary model](#3-adversary-model), [design requirements](#2-design-requirements-and-philosophy), and [implementation](#4-implementation) of the Tor Browser. It is current as of Tor Browser 7.0.11.
+This document describes the [adversary model](#3-adversary-model), [design requirements](#2-design-requirements-and-philosophy), and [implementation](#4-implementation) of the browser. It is current as of Tor Browser 7.0.11.
 
 This document is also meant to serve as a set of design requirements and to describe a reference implementation of a Private Browsing Mode that defends against active network adversaries, in addition to the passive forensic local adversary currently addressed by the major browsers.
 
@@ -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://gitlab.torproject.org/tpo/applications/tor-browser) against this browser to enhance privacy and security. 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.
+The 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. 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.
 
-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.
+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 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 release distribution.
 
 ## 2. Design Requirements and Philosophy
 
-The Tor Browser Design Requirements are meant to describe the properties of a Private Browsing Mode that defends against both network and local forensic adversaries.
+The browser design requirements are meant to describe the properties of a Private Browsing Mode that defends against both network and local forensic adversaries.
 
 There are two main categories of requirements: [Security Requirements](#21-security-requirements), and [Privacy Requirements](#22-privacy-requirements). Security Requirements are the minimum properties in order for a browser to be able to support Tor and similar privacy proxies safely. Privacy requirements are the set of properties that cause us to prefer one browser over another.
 
@@ -141,7 +141,7 @@ For the purposes of the unlinkability requirements of this section as well as th
 
 ### 2.3. Philosophy
 
-In addition to the above design requirements, the technology decisions about Tor Browser are also guided by some philosophical positions about technology.
+In addition to the above design requirements, the technology decisions about the browser are also guided by some philosophical positions about technology.
 
 1. **Preserve existing user model**
 
@@ -177,7 +177,7 @@ In addition to the above design requirements, the technology decisions about Tor
 
     Filter-based solutions in general can also introduce strange breakage and cause usability nightmares. For instance, there is a trend to observe that websites start [detecting filer extensions and block access to content](https://petsymposium.org/2017/papers/issue3/paper25-2017-3-source.pdf) on them. Coping with this fallout easily leads to just [allow-listing](https://github.com/mozilla-services/shavar-list-exceptions) 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 [creates a new URL path](https://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_24.pdf). Worse still, the unique filter sets that each user creates or installs will provide a wealth of fingerprinting targets.
 
-    As a general matter, we are also generally opposed to shipping an always-on Ad blocker with Tor Browser. We feel that this would damage our credibility in terms of demonstrating that we are providing privacy through a sound design alone, as well as damage the acceptance of Tor users by sites that support themselves through advertising revenue.
+    As a general matter, we are also generally opposed to shipping an always-on Ad blocker with the browser. We feel that this would damage our credibility in terms of demonstrating that we are providing privacy through a sound design alone, as well as damage the acceptance of Tor users by sites that support themselves through advertising revenue.
 
     Users are free to install these addons if they wish, but doing so is not recommended, as it will alter the browser request fingerprint.
 
@@ -187,7 +187,7 @@ In addition to the above design requirements, the technology decisions about Tor
 
 ## 3. Adversary Model
 
-A Tor web browser adversary has a number of goals, capabilities, and attack types that can be used to illustrate the design requirements for the Tor Browser. Let's start with the goals.
+A Tor web browser adversary has a number of goals, capabilities, and attack types that can be used to illustrate the design requirements for the browser. Let's start with the goals.
 
 ### 3.1. Adversary Goals
 
@@ -341,11 +341,11 @@ Proxy obedience is assured through the following:
 
 4. **Disabling system extensions and clearing the addon allow-list**
 
-    Firefox addons can perform arbitrary activity on your computer, including bypassing Tor. It is for this reason we disable the addon allow-list (`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**.
+    Firefox addons can perform arbitrary activity on your computer, including bypassing Tor. It is for this reason we disable the addon allow-list (`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 the 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
 
-Tor Browser State is separated from existing browser state through use of a custom Firefox profile, and by setting the `$HOME` environment variable to the root of the bundle's directory. The browser also does not load any system-wide extensions (through the use of `extensions.enabledScopes` and `extensions.autoDisableScopes`). Furthermore, plugins are disabled, which prevents Flash cookies from leaking from a pre-existing Flash directory.
+The browser state is separated from existing browser state through use of a custom Firefox profile, and by setting the `$HOME` environment variable to the root of the bundle's directory. The browser also does not load any system-wide extensions (through the use of `extensions.enabledScopes` and `extensions.autoDisableScopes`). Furthermore, plugins are disabled, which prevents Flash cookies from leaking from a pre-existing Flash directory.
 
 ### 4.3. Disk Avoidance
 
@@ -359,9 +359,9 @@ For more details on disk leak bugs and enhancements, see the [Disk Leak](https:/
 
 ### 4.4. Application Data Isolation
 
-Tor Browser MUST NOT cause any information to be written outside of the bundle directory. This is to ensure that the user is able to completely and safely remove it without leaving other traces of Tor usage on their computer.
+The browser MUST NOT cause any information to be written outside of the bundle directory. This is to ensure that the user is able to completely and safely remove it without leaving other traces of Tor usage on their computer.
 
-To ensure Tor Browser directory isolation, we set `browser.download.useDownloadDir`, `browser.shell.checkDefaultBrowser`, and `browser.download.manager.addToRecentDocs`. We also set the `$HOME` environment variable to be the Tor Browser extraction directory.
+To ensure browser directory isolation, we set `browser.download.useDownloadDir`, `browser.shell.checkDefaultBrowser`, and `browser.download.manager.addToRecentDocs`. We also set the `$HOME` environment variable to be the browser extraction directory.
 
 ### 4.5. Cross-Origin Identifier Unlinkability
 
@@ -374,7 +374,7 @@ The benefit of this approach comes not only in the form of reduced linkability,
 
 This example UI is a mock-up of how isolating identifiers to the URL bar domain can simplify the privacy UI for all data - not just cookies. Once browser identifiers and site permissions operate on a URL bar basis, the same privacy window can represent browsing history, DOM Storage, HTTP Auth, search form history, login values, and so on within a context menu for each site.
 
-#### Identifier Unlinkability Defenses in the Tor Browser
+#### Identifier Unlinkability Defenses
 
 Unfortunately, many aspects of browser state can serve as identifier storage, 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. This has gotten better lately with Mozilla stepping up and helping us with uplifting our patches, and with contributing their own patches 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:
 
@@ -390,7 +390,7 @@ Unfortunately, many aspects of browser state can serve as identifier storage, an
 
     **Implementation Status**: We isolate the content and image cache to the URL bar domain by setting privacy.firstparty.isolate to true.
 
-    Furthermore there is the [CacheStorage API](https://developer.mozilla.org/en-US/docs/Web/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. As the cache entries are written to disk the CacheStorage API [got disabled](https://bugzilla.mozilla.org/show_bug.cgi?id=1173467) in that mode in Firefox, similar to how IndexedDB is handled. There are [thoughts](https://bugzilla.mozilla.org/show_bug.cgi?id=1117808) about enabling it by providing a memory-only database but that is still work in progress. But even if users are leaving the Private Browsing Mode and are enabling third party cookies the storage is isolated to the URL bar domain by `privacy.firstparty.isolate` set to **true**.
+    Furthermore there is the [CacheStorage API](https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage). That one is currently not available in the browser as we do not allow third party cookies and are in Private Browsing Mode by default. As the cache entries are written to disk the CacheStorage API [got disabled](https://bugzilla.mozilla.org/show_bug.cgi?id=1173467) in that mode in Firefox, similar to how IndexedDB is handled. There are [thoughts](https://bugzilla.mozilla.org/show_bug.cgi?id=1117808) about enabling it by providing a memory-only database but that is still work in progress. But even if users are leaving the Private Browsing Mode and are enabling third party cookies the storage is isolated to the URL bar domain by `privacy.firstparty.isolate` set to **true**.
 
     Finally, we have the asm.js cache. The cache entry of the script is (among others things, like type of CPU, build ID, source characters of the asm.js module etc.) keyed [to the origin of the script](https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/). 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 `javascript.options.asmjs` to **false**. 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.
 
@@ -404,7 +404,7 @@ Unfortunately, many aspects of browser state can serve as identifier storage, an
 
 5. **IndexedDB Storage**
 
-    IndexedDB storage for third party domains MUST be isolated to the URL bar domain, to prevent linkability between sites. By default [IndexedDB storage](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API) is disabled as Tor Browser is using Firefox's Private Browsing Mode and does not allow third party cookies. There are [thoughts](https://bugzilla.mozilla.org/show_bug.cgi?id=781982) about enabling this API in Private Browsing Mode as well but that is still work in progress. However, if users are leaving this mode and are enabling third party cookies, isolation to the URL bar is achieved, though, by `privacy.firstparty.isolate` set to **true**.
+    IndexedDB storage for third party domains MUST be isolated to the URL bar domain, to prevent linkability between sites. By default [IndexedDB storage](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API) is disabled as the browser is using Firefox's Private Browsing Mode and does not allow third party cookies. There are [thoughts](https://bugzilla.mozilla.org/show_bug.cgi?id=781982) about enabling this API in Private Browsing Mode as well but that is still work in progress. However, if users are leaving this mode and are enabling third party cookies, isolation to the URL bar is achieved, though, by `privacy.firstparty.isolate` set to **true**.
 
 6. **Flash cookies**
 
@@ -432,7 +432,7 @@ Unfortunately, many aspects of browser state can serve as identifier storage, an
 
     The [URL.createObjectURL](https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL) API allows a site to load arbitrary content into a random UUID that is stored in the user's browser, and this content can be accessed via a URL of the form `blob:UUID` from any other content element anywhere on the web. While this UUID value is neither under control of the site nor predictable, it can still be used to tag a set of users that are of high interest to an adversary.
 
-    URIs created with URL.createObjectURL MUST be limited in scope to the first party URL bar domain that created them. We provide the isolation in Tor Browser by setting `privacy.firstparty.isolate` to **true**.
+    URIs created with URL.createObjectURL MUST be limited in scope to the first party URL bar domain that created them. We provide the isolation in the browser by setting `privacy.firstparty.isolate` to **true**.
 
 11. **SPDY and HTTP/2**
 
@@ -472,7 +472,7 @@ Unfortunately, many aspects of browser state can serve as identifier storage, an
 
     The BroadcastChannel API allows cross-site communication within the same origin. However, to avoid cross-origin linkability broadcast channels MUST instead be isolated to the URL bar domain.
 
-    We provide the isolation in Tor Browser by setting `privacy.firstparty.isolate` to **true**.
+    We provide the isolation by setting `privacy.firstparty.isolate` to **true**.
 
 17. **OCSP**
 
@@ -526,7 +526,7 @@ In order to help prioritize and inform defenses, we now list these sources in or
 
 1. **End-user Configuration Details**
 
-    End-user configuration details are by far the most severe threat to fingerprinting, as they will quickly provide enough information to uniquely identify a user. We believe it is essential to avoid exposing platform configuration details to website content at all costs. We also discourage excessive fine-grained customization of Tor Browser by minimizing and aggregating user-facing privacy and security options, as well as by discouraging the use of additional plugins and addons. When it is necessary to expose configuration details in the course of providing functionality, we strive to do so only on a per-site basis via site permissions, to avoid linkability.
+    End-user configuration details are by far the most severe threat to fingerprinting, as they will quickly provide enough information to uniquely identify a user. We believe it is essential to avoid exposing platform configuration details to website content at all costs. We also discourage excessive fine-grained customization by minimizing and aggregating user-facing privacy and security options, as well as by discouraging the use of additional plugins and addons. When it is necessary to expose configuration details in the course of providing functionality, we strive to do so only on a per-site basis via site permissions, to avoid linkability.
 
 2. **Device and Hardware Characteristics**
 
@@ -544,11 +544,11 @@ In order to help prioritize and inform defenses, we now list these sources in or
 
 5. **Browser Vendor and Version Differences**
 
-    Due to vast differences in feature set and implementation behavior even between different ([minor](https://tsyrklevich.net/2014/10/28/abusing-strict-transport-security/)) versions of the same browser, browser vendor and version differences are simply not possible to conceal in any realistic way. It is only possible to minimize the differences among different installations of the same browser vendor and version. We make no effort to mimic any other major browser vendor, and in fact most of our fingerprinting defenses serve to differentiate Tor Browser users from normal Firefox users. Because of this, any study that lumps browser vendor and version differences into its analysis of the fingerprintability of a population is largely useless for evaluating either attacks or defenses. Unfortunately, this includes popular large-scale studies such as [Panopticlick](https://panopticlick.eff.org/) and [Am I Unique](https://amiunique.org/). To gather usable data about Tor Browser's fingerprinting defenses we launched a Google Summer of Code project in 2016, called [FPCentral](https://github.com/plaperdr/fp-central), with the aim to provide us an own testbed. We set this up during 2017 and [have it available now](https://fpcentral.tbb.torproject.org/) for further integration into our quality assurance efforts and possible research into improving our fingerprinting defenses and measuring their effectiveness.
+    Due to vast differences in feature set and implementation behavior even between different ([minor](https://tsyrklevich.net/2014/10/28/abusing-strict-transport-security/)) versions of the same browser, browser vendor and version differences are simply not possible to conceal in any realistic way. It is only possible to minimize the differences among different installations of the same browser vendor and version. We make no effort to mimic any other major browser vendor, and in fact most of our fingerprinting defenses serve to differentiate users from normal Firefox users. Because of this, any study that lumps browser vendor and version differences into its analysis of the fingerprintability of a population is largely useless for evaluating either attacks or defenses. Unfortunately, this includes popular large-scale studies such as [Panopticlick](https://panopticlick.eff.org/) and [Am I Unique](https://amiunique.org/). To gather usable data about the browser's fingerprinting defenses we launched a Google Summer of Code project in 2016, called [FPCentral](https://github.com/plaperdr/fp-central), with the aim to provide us an own testbed. We set this up during 2017 and [have it available now](https://fpcentral.tbb.torproject.org/) for further integration into our quality assurance efforts and possible research into improving our fingerprinting defenses and measuring their effectiveness.
 
 #### General Fingerprinting Defenses
 
-To date, the Tor Browser team has concerned itself only with developing defenses for APIs that have already been standardized and deployed. Once an API or feature has been standardized and widely deployed, defenses to the associated fingerprinting issues tend to have only a few options available to compensate for the lack of up-front privacy design. In our experience, so far these options have been limited to value spoofing, subsystem modification or reimplementation, virtualization, site permissions, and feature removal. We will now describe these options and the fingerprinting sources they tend to work best with.
+To date, the team has concerned itself only with developing defenses for APIs that have already been standardized and deployed. Once an API or feature has been standardized and widely deployed, defenses to the associated fingerprinting issues tend to have only a few options available to compensate for the lack of up-front privacy design. In our experience, so far these options have been limited to value spoofing, subsystem modification or reimplementation, virtualization, site permissions, and feature removal. We will now describe these options and the fingerprinting sources they tend to work best with.
 
 1. **Value Spoofing**
 
@@ -574,11 +574,11 @@ To date, the Tor Browser team has concerned itself only with developing defenses
 
 When applying a form of defense to a specific fingerprinting vector or source, there are two general strategies available: either the implementation for all users of a single browser version can be made to behave as uniformly as possible, or the user agent can attempt to randomize its behavior so that each interaction between a user and a site provides a different fingerprint.
 
-Although [some research suggests](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr1-1.pdf) 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 [some research suggests](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr1-1.pdf) that randomization can be effective, so far striving for uniformity has generally proved to be a better strategy for the browser for the following reasons:
 
 1. **Evaluation and measurement difficulties**
 
-    The fact that randomization causes behaviors to differ slightly with every site visit makes it appealing at first glance, but this same property makes it very difficult to objectively measure its effectiveness. By contrast, an implementation that strives for uniformity is very simple to evaluate. Despite their current flaws, a properly designed version of [Panopticlick](https://panopticlick.eff.org/) or [Am I Unique](https://amiunique.org/) could report the entropy and uniqueness rates for all users of a single user agent version, without the need for complicated statistics about the variance of the measured behaviors. [FPCentral](https://fpcentral.tbb.torproject.org/fp) is trying to achieve that for Tor Browser by providing feedback on acceptable browser properties and giving guidance on possible improvements.
+    The fact that randomization causes behaviors to differ slightly with every site visit makes it appealing at first glance, but this same property makes it very difficult to objectively measure its effectiveness. By contrast, an implementation that strives for uniformity is very simple to evaluate. Despite their current flaws, a properly designed version of [Panopticlick](https://panopticlick.eff.org/) or [Am I Unique](https://amiunique.org/) could report the entropy and uniqueness rates for all users of a single user agent version, without the need for complicated statistics about the variance of the measured behaviors. [FPCentral](https://fpcentral.tbb.torproject.org/fp) is trying to achieve that for the browser by providing feedback on acceptable browser properties and giving guidance on possible improvements.
 
     Randomization (especially incomplete randomization) may also provide a false sense of security. When a fingerprinting attempt makes naive use of randomized information, a fingerprint will appear unstable, but may not actually be sufficiently randomized to impede a dedicated adversary. Sophisticated fingerprinting mechanisms may either ignore randomized information, or incorporate knowledge of the distribution and range of randomized values into the creation of a more stable fingerprint (by either removing the randomness, modeling it, or averaging it out).
 
@@ -600,7 +600,7 @@ Although [some research suggests](https://www.microsoft.com/en-us/research/wp-co
 
     Improper randomization might introduce a new fingerprinting vector, as the process of generating the values for the fingerprintable attributes could be itself susceptible to side-channel attacks, analysis, or exploitation.
 
-#### Specific Fingerprinting Defenses in the Tor Browser
+#### Specific Fingerprinting Defenses
 
 The following defenses are listed roughly in order of most severe fingerprinting threat first. This ordering is based on the above intuition that user configurable aspects of the computer are the most severe source of fingerprintability, followed by device characteristics and hardware, and then finally operating system vendor and version information.
 
@@ -612,7 +612,7 @@ Where our actual implementation differs from an ideal solution, we separately de
 
     **Design Goal**: All plugins that have not been specifically audited or sandboxed MUST be disabled. To reduce linkability potential, even sandboxed plugins SHOULD NOT be allowed to load objects until the user has clicked through a click-to-play barrier. Additionally, version information SHOULD be reduced or obfuscated until the plugin object is loaded. For Flash, we wish to [provide a settings.sol](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/3974) file to disable Flash cookies, and to restrict P2P features that are likely to bypass proxy settings. We'd also like to restrict access to fonts and other system information (such as IP address and MAC address) in such a sandbox.
 
-    **Implementation Status**: Currently, we entirely disable all plugins in Tor Browser. However, as a compromise due to the popularity of Flash, we allow users to re-enable Flash, and flash objects are blocked behind a click-to-play barrier that is available only after the user has specifically enabled plugins. Flash is the only plugin available, the rest are entirely blocked from loading by the Firefox patches mentioned in the [Proxy Obedience section](#41-proxy-obedience). We also set the Firefox preference `plugin.expose_full_path` to false, to avoid leaking plugin installation information.
+    **Implementation Status**: Currently, we entirely disable all plugins in the browser. However, as a compromise due to the popularity of Flash, we allow users to re-enable Flash, and flash objects are blocked behind a click-to-play barrier that is available only after the user has specifically enabled plugins. Flash is the only plugin available, the rest are entirely blocked from loading by the Firefox patches mentioned in the [Proxy Obedience section](#41-proxy-obedience). We also set the Firefox preference `plugin.expose_full_path` to false, to avoid leaking plugin installation information.
 
 2. **HTML5 Canvas Image Extraction**
 
@@ -624,7 +624,7 @@ Where our actual implementation differs from an ideal solution, we separately de
 
     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.
+    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)**
 
@@ -644,7 +644,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 allow-list. This functionality is provided by setting `privacy.resistFingerprinting` to **true**. The allow-list 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.
+    For Windows and macOS we use a preference, `font.system.whitelist`, to restrict fonts being used to those in the allow-list. This functionality is provided by setting `privacy.resistFingerprinting` to **true**. The allow-list 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 the 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 issue tracker](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18097) to summarize the current state of our defense and future work that remains to be done.
 
@@ -694,21 +694,21 @@ Where our actual implementation differs from an ideal solution, we separately de
 
 15. **System Uptime**
 
-    It is possible to get the system uptime of a Tor Browser user by querying the **Event.timestamp** property. We avoid this by setting `dom.event.highrestimestamp.enabled` to **true**. This might seem to be counterintuitive at first glance but the effect of setting that preference to true is a [normalization](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17046) of `evt.timestamp` and `new Event('').timeStamp`. Together with clamping the timer resolution to 100ms this provides an effective means against system uptime fingerprinting.
+    It is possible to get the system uptime of a user by querying the **Event.timestamp** property. We avoid this by setting `dom.event.highrestimestamp.enabled` to **true**. This might seem to be counterintuitive at first glance but the effect of setting that preference to true is a [normalization](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17046) of `evt.timestamp` and `new Event('').timeStamp`. Together with clamping the timer resolution to 100ms this provides an effective means against system uptime fingerprinting.
 
 16. **Keyboard Layout Fingerprinting**
 
     Keyboard events provide a way for a website to find out information about the keyboard layout of its visitors. In fact there are [several dimensions](https://developers.google.com/web/updates/2016/04/keyboardevent-keys-codes) to this fingerprinting vector. The `KeyboardEvent.code` property represents a physical key that can't be changed by the keyboard layout nor by the modifier state. On the other hand the `KeyboardEvent.key` property contains the character that is generated by that key. This is dependent on things like keyboard layout, locale and modifier keys.
 
-    **Design Goal**: Websites MUST NOT be able to infer any information about the keyboard of a Tor Browser user.
+    **Design Goal**: Websites MUST NOT be able to infer any information about the keyboard of a user.
 
     **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.
+    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 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 browser locale or language of the document.
 
 17. **User Agent and HTTP Headers**
 
-    **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.
+    **Design Goal**: All 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.
 
@@ -716,7 +716,7 @@ Where our actual implementation differs from an ideal solution, we separately de
 
     Attacks based on timing side channels are nothing new in the browser context. [Cache-based](http://sip.cs.princeton.edu/pub/webtiming.pdf), [cross-site timing](https://www.abortz.net/papers/timingweb.pdf), and [pixel stealing](https://www.contextis.com/documents/2/Browser_Timing_Attacks.pdf), to name just a few, got investigated in the past. While their fingerprinting potential varies all timing-based attacks have in common that they need sufficiently fine-grained clocks.
 
-    **Design Goal**: Websites MUST NOT be able to fingerprint a Tor Browser user by exploiting timing-based side channels.
+    **Design Goal**: Websites MUST NOT be able to fingerprint a user by exploiting timing-based side channels.
 
     **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.
 
@@ -726,11 +726,11 @@ Where our actual implementation differs from an ideal solution, we separately de
 
 19. **resource:// and chrome:// URIs Leaks**
 
-    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.
+    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 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 the 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.
 
 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.
+    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.
 
@@ -738,7 +738,7 @@ Where our actual implementation differs from an ideal solution, we separately de
 
     While the latency in Tor connections varies anywhere from milliseconds to a few seconds, it is still possible for the remote site to detect large differences between the user's clock and an official reference time source.
 
-    **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).
+    **Design Goal**: All 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 the 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 by setting `privacy.resistFingerprinting` to **true** thanks to [Mozilla 1330890](https://bugzilla.mozilla.org/show_bug.cgi?id=1330890).
 
@@ -762,7 +762,7 @@ Where our actual implementation differs from an ideal solution, we separately de
 
     Modern computers have multiple physical processor cores available in their CPU. For optimum performance, native code typically attempts to run as many threads as there are cores, and `navigator.hardwareConcurrency` makes the number of those threads (i.e. logical processors) available to web content.
 
-    **Design Goal**: Websites MUST NOT be able to fingerprint a Tor Browser user taking advantage of the amount of logical processors available.
+    **Design Goal**: Websites MUST NOT be able to fingerprint a user taking advantage of the amount of logical processors available.
 
     **Implementation Status**: We set `dom.maxHardwareConcurrency` to **1** to report the same amount of logical processors for everyone. However, there are [probabilistic ways of determining the same information available](https://github.com/oftn/core-estimator) 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 [by following a bucket approach](https://bugs.torproject.org/22127) as we currently do in our defense against screen size exfiltration.
 
@@ -782,15 +782,15 @@ Where our actual implementation differs from an ideal solution, we separately de
 
 28. **Reader View**
 
-    [Reader View](https://support.mozilla.org/t5/Basic-Browsing/Firefox-Reader-View-for-clutter-free-web-pages/ta-p/38466) is a Firefox feature to view web pages clutter-free and easily adjusted to own needs and preferences. To avoid fingerprintability risks we make Tor Browser users uniform by setting `reader.parse-on-load.enabled` to **false** and `browser.reader.detectedFirstArticle` to **true**. This makes sure that documents are not parsed on load as this is disabled on some devices due to memory consumption and we pretend that everybody has already been using that feature in the past.
+    [Reader View](https://support.mozilla.org/t5/Basic-Browsing/Firefox-Reader-View-for-clutter-free-web-pages/ta-p/38466) is a Firefox feature to view web pages clutter-free and easily adjusted to own needs and preferences. To avoid fingerprintability risks we make users uniform by setting `reader.parse-on-load.enabled` to **false** and `browser.reader.detectedFirstArticle` to **true**. This makes sure that documents are not parsed on load as this is disabled on some devices due to memory consumption and we pretend that everybody has already been using that feature in the past.
 
 29. **Contacting Mozilla Services**
 
-    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.
+    The 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 block-list 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.
+    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 the 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 block-list 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 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 the 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 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).
+    We have [Safebrowsing](https://wiki.mozilla.org/Security/Safe_Browsing) disabled in the 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).
 
 30. **Operating System Type Fingerprinting**
 
@@ -804,11 +804,11 @@ For more details on fingerprinting bugs and enhancements, see the [Fingerprintin
 
 ### 4.7. Long-Term Unlinkability via "New Identity" button
 
-In order to avoid long-term linkability, we provide a "New Identity" context menu option in Tor Browser.
+In order to avoid long-term linkability, we provide a "New Identity" context menu option in the browser.
 
 **Design Goal**: All linkable identifiers and browser state MUST be cleared by this feature.
 
-**Implementation Status**: First, Tor Browser disables JavaScript in all open tabs and windows by using both the [browser.docShell.allowJavaScript](https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocShell#Attributes) attribute as well as [nsIDOMWindowUtil.suppressEventHandling()](https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDOMWindowUtils#suppressEventHandling%28%29). We then stop all page activity for each tab using [browser.webNavigation.stop(nsIWebNavigation.STOP_ALL)](https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIWebNavigation#stop%28%29). We then clear the site-specific Zoom by temporarily disabling the preference `browser.zoom.siteSpecific`, and clear the GeoIP wifi token URL `geo.wifi.access_token` and the last opened URL preference (if it exists). Each tab is then closed.
+**Implementation Status**: First, the browser disables JavaScript in all open tabs and windows by using both the [browser.docShell.allowJavaScript](https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocShell#Attributes) attribute as well as [nsIDOMWindowUtil.suppressEventHandling()](https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDOMWindowUtils#suppressEventHandling%28%29). We then stop all page activity for each tab using [browser.webNavigation.stop(nsIWebNavigation.STOP_ALL)](https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIWebNavigation#stop%28%29). We then clear the site-specific Zoom by temporarily disabling the preference `browser.zoom.siteSpecific`, and clear the GeoIP wifi token URL `geo.wifi.access_token` and the last opened URL preference (if it exists). Each tab is then closed.
 
 After closing all tabs, we then clear the searchbox and findbox text and emit ["browser:purge-session-history"](https://developer.mozilla.org/en-US/docs/Supporting_private_browsing_mode#Private_browsing_notifications) (which instructs addons and various Firefox components to clear their session 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, Cache 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.
 
@@ -828,7 +828,7 @@ In addition to the above mechanisms that are devoted to preserving privacy while
 
     - **Low (default)**
 
-        At this security level, the preferences are the Tor Browser defaults. This includes three features that were formerly governed by the slider at higher security levels: `gfx.font_rendering.graphite.enabled` is set to **false** now after Mozilla got convinced that [leaving it enabled is too risky](https://bugzilla.mozilla.org/show_bug.cgi?id=1255731). Even though Mozilla reverted that decision after another round of fixing critical Graphite bugs, we remain skeptical and keep that feature disabled for now. `network.jar.block-remote-files` is set to **true**. Mozilla tried to block remote JAR files in Firefox 45 but needed to revert that decision due to breaking IBM's iNotes. While Mozilla [is working on getting this disabled again](https://bugzilla.mozilla.org/show_bug.cgi?id=1329336) we take the protective stance already now and block remote JAR files even on the low security level. Finally, we exempt asm.js from the security slider and block it on all levels. See the [Disk Avoidance](#43-disk-avoidance) and the cache linkability concerns in the [Cross-Origin Identifier Unlinkability](#45-cross-origin-identifier-unlinkability) sections for further details.
+        At this security level, the preferences are the browser defaults. This includes three features that were formerly governed by the slider at higher security levels: `gfx.font_rendering.graphite.enabled` is set to **false** now after Mozilla got convinced that [leaving it enabled is too risky](https://bugzilla.mozilla.org/show_bug.cgi?id=1255731). Even though Mozilla reverted that decision after another round of fixing critical Graphite bugs, we remain skeptical and keep that feature disabled for now. `network.jar.block-remote-files` is set to **true**. Mozilla tried to block remote JAR files in Firefox 45 but needed to revert that decision due to breaking IBM's iNotes. While Mozilla [is working on getting this disabled again](https://bugzilla.mozilla.org/show_bug.cgi?id=1329336) we take the protective stance already now and block remote JAR files even on the low security level. Finally, we exempt asm.js from the security slider and block it on all levels. See the [Disk Avoidance](#43-disk-avoidance) and the cache linkability concerns in the [Cross-Origin Identifier Unlinkability](#45-cross-origin-identifier-unlinkability) sections for further details.
 
     - **Medium**
 
@@ -850,7 +850,7 @@ In addition to the above mechanisms that are devoted to preserving privacy while
 
 3. **Privacy-preserving update notification**
 
-    ~In order to inform the user when their Tor Browser is out of date, we perform a privacy-preserving update check asynchronously in the background. The check uses Tor to download the file https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions and searches that version list for the current value for the local preference `torbrowser.version`. If the value from our preference is present in the recommended version list, the check is considered to have succeeded and the user is up to date. If not, it is considered to have failed and an update is needed. The check is triggered upon browser launch, new window, and new tab, but is rate limited so as to happen no more frequently than once every 1.5 hours.~
+    ~In order to inform the user when their browser is out of date, we perform a privacy-preserving update check asynchronously in the background. The check uses Tor to download the file https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions and searches that version list for the current value for the local preference `torbrowser.version`. If the value from our preference is present in the recommended version list, the check is considered to have succeeded and the user is up to date. If not, it is considered to have failed and an update is needed. The check is triggered upon browser launch, new window, and new tab, but is rate limited so as to happen no more frequently than once every 1.5 hours.~
 
     ~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.~
 
@@ -872,7 +872,7 @@ The use of the Gitian system eliminates build non-determinism by normalizing the
 
 1. **Filesystem and archive reordering**
 
-    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 most prevalent source of non-determinism in the components of the 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, zip, and DMG to aid in reproducible archive creation.
 
@@ -918,7 +918,7 @@ The Firefox updater also has code to ensure that it can reliably access the upda
 
 ## 6. Towards Transparency in Navigation Tracking
 
-The [privacy properties](#22-privacy-requirements) of Tor Browser are based upon the assumption that link-click navigation indicates user consent to tracking between the linking site and the destination site. While this definition is sufficient to allow us to eliminate cross-site third party tracking with only minimal site breakage, it is our long-term goal to further reduce cross-origin click navigation tracking to mechanisms that are detectable by attentive users, so they can alert the general public if cross-origin click navigation tracking is happening where it should not be.
+The [privacy properties](#22-privacy-requirements) of the browser are based upon the assumption that link-click navigation indicates user consent to tracking between the linking site and the destination site. While this definition is sufficient to allow us to eliminate cross-site third party tracking with only minimal site breakage, it is our long-term goal to further reduce cross-origin click navigation tracking to mechanisms that are detectable by attentive users, so they can alert the general public if cross-origin click navigation tracking is happening where it should not be.
 
 In an ideal world, the mechanisms of tracking that can be employed during a link click would be limited to the contents of URL parameters and other properties that are fully visible to the user before they click. However, the entrenched nature of certain archaic web features make it impossible for us to achieve this transparency goal by ourselves without substantial site breakage. So, instead we maintain a [Deprecation Wishlist](#61-deprecation-wishlist) of archaic web technologies that are currently being (ab)used to facilitate federated login and other legitimate click-driven cross-domain activity but that can one day be replaced with more privacy friendly, auditable alternatives.
 
@@ -942,7 +942,7 @@ Because the total elimination of side channels during cross-origin navigation wi
 
 3. **JavaScript link rewriting**
 
-    In general, it should not be possible for onclick handlers to alter the navigation destination of 'a' tags, silently transform them into POST requests, or otherwise create situations where a user believes they are clicking on a link leading to one URL that ends up on another. This functionality is deceptive and is frequently a vector for malware and phishing attacks. Unfortunately, many legitimate sites also employ such transparent link rewriting, and blanket disabling this functionality ourselves will simply cause Tor Browser to fail to navigate properly on these sites.
+    In general, it should not be possible for onclick handlers to alter the navigation destination of 'a' tags, silently transform them into POST requests, or otherwise create situations where a user believes they are clicking on a link leading to one URL that ends up on another. This functionality is deceptive and is frequently a vector for malware and phishing attacks. Unfortunately, many legitimate sites also employ such transparent link rewriting, and blanket disabling this functionality ourselves will simply cause the browser to fail to navigate properly on these sites.
 
     Automated cross-origin redirects are one form of this behavior that is possible for us to [address ourselves](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40787), as they are comparatively rare and can be handled with site permissions.