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

@@ -179,7 +179,7 @@ In addition to the above design requirements, the technology decisions about Tor
 
     Trying to resort to [filter methods based on machine learning](https://jonathanmayer.org/papers_data/bau13.pdf) does not solve the problem either: they don't provide a general solution to the tracking problem as they are working probabilistically. Even with a precision rate at 99% and a false positive rate at 0.1% trackers would be missed and sites would be wrongly blocked.
 
-    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 [whitelisting](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.
+    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.
 
@@ -343,9 +343,9 @@ Proxy obedience is assured through the following:
 
     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**
+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 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**.
+    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**.
 
 ### 4.2. State Separation
 
@@ -648,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://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 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 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.
 
@@ -792,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 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 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.
 
     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).