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 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~`update to latest version`.
 
 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,9 +87,9 @@ For more practical information regarding Tor Browser development, please consult
 
 ### 1.1. Browser Component Overview
 
-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.
+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 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 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.
+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 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
 
@@ -117,18 +117,21 @@ The security requirements are primarily concerned with ensuring the safe use of
 
     The browser MUST NOT write any information that is derived from or that reveals browsing activity to the disk, or store it in memory beyond the duration of one browsing session, unless the user has explicitly opted to store their browsing history information to disk.
 
-4. [Application Data Isolation](#44-application-data-isolation)
+4. ~[Application Data Isolation](#44-application-data-isolation)~
+
+    ~The components involved in providing private browsing MUST be self-contained, or MUST provide a mechanism for rapid, complete removal of all evidence of the use of the mode. In other words, the browser MUST NOT write or cause the operating system to write any information about the use of private browsing to disk outside of the application's control. The user must be able to ensure that secure deletion of the software is sufficient to remove evidence of the use of the software. All exceptions and shortcomings due to operating system behavior MUST be wiped by an uninstaller. However, due to permissions issues with access to swap, implementations MAY choose to leave it out of scope, and/or leave it to the operating system/platform to implement ephemeral-keyed encrypted swap.~
+
+    `this section should be removed and we need to redirect users who need such protections to Tails`
 
-    The components involved in providing private browsing MUST be self-contained, or MUST provide a mechanism for rapid, complete removal of all evidence of the use of the mode. In other words, the browser MUST NOT write or cause the operating system to write any information about the use of private browsing to disk outside of the application's control. The user must be able to ensure that secure deletion of the software is sufficient to remove evidence of the use of the software. All exceptions and shortcomings due to operating system behavior MUST be wiped by an uninstaller. However, due to permissions issues with access to swap, implementations MAY choose to leave it out of scope, and/or leave it to the operating system/platform to implement ephemeral-keyed encrypted swap.
 
 ### 2.2. Privacy Requirements
 
 The privacy requirements are primarily concerned with reducing linkability: the ability for a user's activity on one site to be linked with their activity on another site without their knowledge or explicit consent. With respect to browser support, privacy requirements are the set of properties that cause us to prefer one browser over another.
 
-For the purposes of the unlinkability requirements of this section as well as the descriptions in the [implementation section](#4-implementation), a URL bar origin means at least the second-level DNS name. For example, for `mail.google.com`, the origin would be `google.com`. Implementations MAY, at their option, restrict the URL bar origin to be the entire fully qualified domain name.
+For the purposes of the unlinkability requirements of this section as well as the descriptions in the [implementation section](#4-implementation), a URL bar origin means at least the second-level DNS name. For example, for `mail.google.com`, the origin would be `google.com`. ~Implementations MAY, at their option, restrict the URL bar origin to be the entire fully qualified domain name.~ `it seems this document in the past also talks about what other browser implementations ought to do for us to like them`
 
 1. [Cross-Origin Identifier Unlinkability](#45-cross-origin-identifier-unlinkability)
-
+n
     User activity on one URL bar origin MUST NOT be linkable to their activity in any other URL bar origin by any third party automatically or without user interaction or approval. This requirement specifically applies to linkability from stored browser identifiers, authentication tokens, and shared state. The requirement does not apply to linkable information the user manually submits to sites, or due to information submitted during manual link traversal. This functionality SHOULD NOT interfere with interactive, click-driven federated login in a substantial way.
 
 2. [Cross-Origin Fingerprinting Unlinkability](#46-cross-origin-fingerprinting-unlinkability)
@@ -147,17 +150,21 @@ In addition to the above design requirements, the technology decisions about the
 
     The existing way that the user expects to use a browser must be preserved. If the user has to maintain a different mental model of how the sites they are using behave depending on tab, browser state, or anything else that would not normally be what they experience in their default browser, the user will inevitably be confused. They will make mistakes and reduce their privacy as a result. Worse, they may just stop using the browser, assuming it is broken.
 
-    User model breakage was one of the [failures of Torbutton](https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton): Even if users managed to install everything properly, the toggle model was too hard for the average user to understand, especially in the face of accumulating tabs from multiple states crossed with the current Tor-state of the browser.
+    ~User model breakage was one of the [failures of Torbutton](https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton): Even if users managed to install everything properly, the toggle model was too hard for the average user to understand, especially in the face of accumulating tabs from multiple states crossed with the current Tor-state of the browser.~
+
+    `not sure there's much value in keeping this historical aside`
 
 2. **Favor the implementation mechanism least likely to break sites**
 
     In general, we try to find solutions to privacy issues that will not induce site breakage, though this is not always possible.
 
-3. **Plugins must be restricted**
+3. **~Plugins must be restricted~**
+
+    ~Even if plugins always properly used the browser proxy settings (which none of them do) and could not be induced to bypass them (which all of them can), the activities of closed-source plugins are very difficult to audit and control. They can obtain and transmit all manner of system information to websites, often have their own identifier storage for tracking users, and also contribute to fingerprinting.~
 
-    Even if plugins always properly used the browser proxy settings (which none of them do) and could not be induced to bypass them (which all of them can), the activities of closed-source plugins are very difficult to audit and control. They can obtain and transmit all manner of system information to websites, often have their own identifier storage for tracking users, and also contribute to fingerprinting.
+    ~Therefore, if plugins are to be enabled in private browsing modes, they must be restricted from running automatically on every page (via click-to-play placeholders), and/or be sandboxed to restrict the types of system calls they can execute. If the user agent allows the user to craft an exemption to allow a plugin to be used automatically, it must only apply to the top level URL bar domain, and not to all sites, to reduce cross-origin fingerprinting linkability.~
 
-    Therefore, if plugins are to be enabled in private browsing modes, they must be restricted from running automatically on every page (via click-to-play placeholders), and/or be sandboxed to restrict the types of system calls they can execute. If the user agent allows the user to craft an exemption to allow a plugin to be used automatically, it must only apply to the top level URL bar domain, and not to all sites, to reduce cross-origin fingerprinting linkability.
+    `
 
 4. **Minimize Global Privacy Options**
 
@@ -167,19 +174,21 @@ In addition to the above design requirements, the technology decisions about the
 
     If the user has indicated they wish to record local history storage, these permissions can be written to disk. Otherwise, they should remain memory-only.
 
-5. **No filters**
+5. **~No filters~**
 
-    Site-specific or filter-based addons such as [AdBlock Plus](https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/), [Request Policy](https://requestpolicy.com/), [Ghostery](https://www.ghostery.com/about-ghostery/), [Priv3](http://priv3.icsi.berkeley.edu/), and [Sharemenot](https://sharemenot.cs.washington.edu/) are to be avoided. We believe that these addons do not add any real privacy to a proper [implementation](#4-implementation) of the above [privacy requirements](#22-privacy-requirements), and that development efforts should be focused on general solutions that prevent tracking by all third parties, rather than a list of specific URLs or hosts.
+    ~Site-specific or filter-based addons such as [AdBlock Plus](https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/), [Request Policy](https://requestpolicy.com/), [Ghostery](https://www.ghostery.com/about-ghostery/), [Priv3](http://priv3.icsi.berkeley.edu/), and [Sharemenot](https://sharemenot.cs.washington.edu/) are to be avoided. We believe that these addons do not add any real privacy to a proper [implementation](#4-implementation) of the above [privacy requirements](#22-privacy-requirements), and that development efforts should be focused on general solutions that prevent tracking by all third parties, rather than a list of specific URLs or hosts.~
 
-    Implementing filter-based blocking directly into the browser, such as done with [Firefox' Tracking Protection](https://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_32.pdf), does not alleviate the concerns mentioned in the previous paragraph. There is still just a list containing specific URLs and hosts which, in this case, are [assembled](https://services.disconnect.me/disconnect-plaintext.json) by [Disconnect](https://disconnect.me/trackerprotection) and adapted by [Mozilla](https://github.com/mozilla-services/shavar-list-exceptions).
+    ~Implementing filter-based blocking directly into the browser, such as done with [Firefox' Tracking Protection](https://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_32.pdf), does not alleviate the concerns mentioned in the previous paragraph. There is still just a list containing specific URLs and hosts which, in this case, are [assembled](https://services.disconnect.me/disconnect-plaintext.json) by [Disconnect](https://disconnect.me/trackerprotection) and adapted by [Mozilla](https://github.com/mozilla-services/shavar-list-exceptions).~
 
-    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.
+    ~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 [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.
+    ~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 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.
+    ~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.
+    ~Users are free to install these addons if they wish, but doing so is not recommended, as it will alter the browser request fingerprint.~
+
+    `this whole section can probably be removed entirely since we're seriously considering adding uBlock-origin support`
 
 6. **Stay Current**
 
@@ -209,12 +218,16 @@ A Tor web browser adversary has a number of goals, capabilities, and attack type
 
 5. **Fingerprinting/anonymity set reduction**
 
-    Fingerprinting (more generally: "anonymity set reduction") is used to attempt to gather identifying information on a particular individual without the use of tracking identifiers. If the dissident's or whistleblower's timezone is available, and they are using a rare build of Firefox for an obscure operating system, and they have a specific display resolution only used on one type of laptop, this can be very useful information for tracking them down, or at least [tracking their activities](https://2019.www.torproject.org/projects/torbrowser/design/#fingerprinting).
+    Fingerprinting (more generally: "anonymity set reduction") is used to attempt to gather identifying information on a particular individual without the use of tracking identifiers. If the dissident's or whistleblower's timezone is available, and they are using a rare build of Firefox for an obscure operating system, and they have a specific display resolution only used on one type of laptop, this can be very useful information for tracking them down, or at least tracking their activities .
 
 6. **History records and other on-disk information**
 
     In some cases, the adversary may opt for a heavy-handed approach, such as seizing the computers of all Tor users in an area (especially after narrowing the field by the above two pieces of information). History records and cache data are the primary goals here. Secondary goals may include confirming on-disk identifiers (such as hostname and disk-logged spoofed MAC address history) obtained by other means.
 
+7. **Censorship**
+
+    `section about censorship goals`
+
 ### 3.2. Adversary Capabilities - Positioning
 
 The adversary can position themselves at a number of different locations in order to execute their attacks.
@@ -237,6 +250,8 @@ The adversary can position themselves at a number of different locations in orde
 
     Some users face adversaries with intermittent or constant physical access. Users in Internet cafes, for example, face such a threat. In addition, in countries where simply using tools like Tor is illegal, users may face confiscation of their computer equipment for excessive Tor usage or just general suspicion.
 
+    `also mention adversaries in the home`
+
 ### 3.3. Adversary Capabilities - Attacks
 
 The adversary can perform the following attacks from a number of different positions to accomplish various aspects of their goals. It should be noted that many of these attacks (especially those involving IP address leakage) are often performed by accident by websites that simply have JavaScript, dynamic CSS elements, and plugins. Others are performed by ad servers seeking to correlate users' activity across different IP addresses, and still others are performed by malicious agents on the Tor network and at national firewalls.
@@ -245,7 +260,7 @@ The adversary can perform the following attacks from a number of different posit
 
     The browser contains multiple facilities for storing identifiers that the adversary creates for the purposes of tracking users. These identifiers are most obviously cookies, but also include HTTP auth, DOM storage, cached scripts and other elements with embedded identifiers, client certificates, and even TLS Session IDs.
 
-    An adversary in a position to perform MITM content alteration can inject document content elements to both read and inject cookies for arbitrary domains. In fact, even many "SSL secured" websites are vulnerable to this sort of [active sidejacking](http://seclists.org/bugtraq/2007/Aug/0070.html). In addition, the ad networks of course perform tracking with cookies as well.
+    An adversary in a position to perform MITM content alteration can inject document content elements to both read and inject cookies for arbitrary domains. In fact, even many "SSL secured" websites are vulnerable to this sort of [active sidejacking](http://seclists.org/bugtraq/2007/Aug/0070.html) `ma1 should review this`. In addition, the ad networks of course perform tracking with cookies as well.
 
     These types of attacks are attempts at subverting our [Cross-Origin Identifier Unlinkability](#45-cross-origin-identifier-unlinkability) and [Long-Term Unlinkability](#47-long-term-unlinkability-via-new-identity-button) design requirements.
 
@@ -267,14 +282,18 @@ The adversary can perform the following attacks from a number of different posit
 
         JavaScript can reveal a lot of fingerprinting information. It provides DOM objects such as window.screen and window.navigator to extract information about the user agent. Also, JavaScript can be used to query the user's timezone via the `Date()` object, [WebGL](https://www.khronos.org/registry/webgl/specs/1.0/#5.13) can reveal information about the video card in use, and high precision timing information can be used to [fingerprint the CPU and interpreter speed](https://cseweb.ucsd.edu/~hovav/dist/jspriv.pdf). JavaScript features such as [Resource Timing](https://www.w3.org/TR/resource-timing/) may leak an unknown amount of network timing related information. And, moreover, JavaScript is able to [extract](https://seclab.cs.ucsb.edu/media/uploads/papers/sp2013_cookieless.pdf) [available](https://www.cosic.esat.kuleuven.be/fpdetective/) [fonts](https://hal.inria.fr/hal-01285470v2/document) on a device with high precision.
 
-    3. **Inserting Plugins**
+    3. **~Inserting Plugins~**
+
+        ~The Panopticlick project found that the mere list of installed plugins (in navigator.plugins) was sufficient to provide a large degree of fingerprintability. Additionally, plugins are capable of extracting font lists, interface addresses, and other machine information that is beyond what the browser would normally provide to content. In addition, plugins can be used to store unique identifiers that are more difficult to clear than standard cookies. [Flash-based cookies](https://epic.org/privacy/cookies/flash.html) fall into this category, but there are likely numerous other examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy settings of the browser.~
 
-        The Panopticlick project found that the mere list of installed plugins (in navigator.plugins) was sufficient to provide a large degree of fingerprintability. Additionally, plugins are capable of extracting font lists, interface addresses, and other machine information that is beyond what the browser would normally provide to content. In addition, plugins can be used to store unique identifiers that are more difficult to clear than standard cookies. [Flash-based cookies](https://epic.org/privacy/cookies/flash.html) fall into this category, but there are likely numerous other examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy settings of the browser.
+        `plugins are no longer relevant but we could arguably add a section about codec support as a fingerprinting vector`
 
     4. **Inserting CSS**
 
         [CSS media queries](https://developer.mozilla.org/En/CSS/Media_queries) can be inserted to gather information about the desktop size, widget size, display type, DPI, user agent type, and other information that was formerly available only to JavaScript.
 
+    `thorin should also review and suggest additions to this section`
+
 3. **Website traffic fingerprinting**
 
     Website traffic fingerprinting is an attempt by the adversary to recognize the encrypted traffic patterns of specific websites. In the case of Tor, this attack would take place between the user and the Guard node, or at the Guard node itself.
@@ -289,6 +308,8 @@ The adversary can perform the following attacks from a number of different posit
 
     Still, we do not believe that these issues are enough to dismiss the attack outright. But we do believe these factors make it both worthwhile and effective to [deploy light-weight defenses](https://2019.www.torproject.org/projects/torbrowser/design/#traffic-fingerprinting-defenses) that reduce the accuracy of this attack by further contributing noise to hinder successful feature extraction.
 
+    `so this whole section is very long to say not a lot, revise this down to the relevant bits`
+
 4. **Remotely or locally exploit browser and/or OS**
 
     Last, but definitely not least, the adversary can exploit either general browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to install malware and surveillance software. An adversary with physical access can perform similar actions.
@@ -297,6 +318,8 @@ The adversary can perform the following attacks from a number of different posit
 
     An adversary with arbitrary code execution typically has more power, though. It can be quite hard to really significantly limit the capabilities of such an adversary. [The Tails system](https://tails.boum.org/contribute/design/) can provide some defense against this adversary through the use of readonly media and frequent reboots, but even this can be circumvented on machines without Secure Boot through the use of BIOS rootkits.
 
+    `adversaries with arbitrary code execution are outside the scope of what the browser can protect against`
+
 ## 4. Implementation
 
 The Implementation section is divided into subsections, each of which corresponds to a [Design Requirement](#2-design-requirements-and-philosophy). Each subsection is divided into specific web technologies or properties. The implementation is then described for that property.
@@ -309,7 +332,7 @@ Proxy obedience is assured through the following:
 
 1. **Firefox proxy settings, patches, and build flags**
 
-    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`.
+    Our Firefox preferences file 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.
 
@@ -319,6 +342,8 @@ Proxy obedience is assured through the following:
 
     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.
 
+    `build with --enable-proxy-bypass-protection`
+
 2. **Disabling plugins**
 
     NPAPI plugins have been historically a major source of vulnerabilities and proxy bypasses, which the browser had specifically to deal with in the past.
@@ -331,14 +356,20 @@ Proxy obedience is assured through the following:
 
     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) 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://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.
+    ~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.~
+
+    `this patch has been uplifted and is a pref now`
 
     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](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41613) before the OS downloads the URLs the events contained.
 
+    `this bit should be updated by ma1 to talk about our updated drag+drop patches`
+
 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 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**.
 
+    `not quiet true, pdfjs is system extension we include`
+
 ### 4.2. State Separation
 
 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.
@@ -353,32 +384,36 @@ As an additional defense-in-depth measure, we set `browser.cache.disk.enable`, `
 
 For more details on disk leak bugs and enhancements, see the [Disk Leak](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=Disk%20Leak&first_page_size=20) tag in our issue tracker.
 
-### 4.4. Application Data Isolation
+### ~4.4. Application Data Isolation~
 
-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.
+~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 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.
+~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.~
+
+`purge purge`
 
 ### 4.5. Cross-Origin Identifier Unlinkability
 
-The Cross-Origin Identifier Unlinkability design requirement is satisfied through first party isolation of all browser identifier sources. First party isolation means that all identifier sources and browser state are scoped (isolated) using the URL bar domain. This scoping is performed in combination with any additional third party scope. When first party isolation is used with explicit identifier storage that already has a constrained third party scope (such as cookies and DOM storage), this approach is referred to as "double-keying".
+The Cross-Origin Identifier Unlinkability design requirement is satisfied through first party isolation of all browser identifier sources. First party isolation means that all identifier sources and browser state are scoped (isolated) using the URL bar domain. This scoping is performed in combination with any additional third party scope. When first party isolation is used with explicit identifier storage that already has a constrained third party scope (such as cookies and DOM storage), this approach is referred to as "double-keying". `3rd party cookies are disabled, not double-keyed`
 
-The benefit of this approach comes not only in the form of reduced linkability, but also in terms of simplified privacy UI. If all stored browser state and permissions become associated with the URL bar origin, the six or seven different pieces of privacy UI governing these identifiers and permissions can become just one piece of UI. For instance, a window that lists the URL bar origin for which browser state exists, possibly with a context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1.
+~The benefit of this approach comes not only in the form of reduced linkability, but also in terms of simplified privacy UI. If all stored browser state and permissions become associated with the URL bar origin, the six or seven different pieces of privacy UI governing these identifiers and permissions can become just one piece of UI. For instance, a window that lists the URL bar origin for which browser state exists, possibly with a context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1.~
 
-#### Figure 1. Improving the Privacy UI
+#### ~Figure 1. Improving the Privacy UI~
 ![Improving the Privacy UI](uploads/b60467a8bfbfa04789c316dfd20cf097/improving-privacy-ui.png)
 
-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.
+~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
 
-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:
+~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.~ `less commentary here` Here is the list that we have discovered and dealt with to date:
 
 1. **Cookies**
 
-    **Design Goal**: All cookies MUST be double-keyed to the URL bar origin and third-party origin.
+    ~**Design Goal**: All cookies MUST be double-keyed to the URL bar origin and third-party origin.~
+
+    ~**Implementation Status**: Double-keying cookies should just work by setting `privacy.firstparty.isolate` to **true**. However, [we have not audited that](https://gitlab.torproject.org/legacy/trac/-/issues/21905) yet and there is still the [UI part missing for managing cookies in Private Browsing Mode](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/10353). We therefore opted to keep third-party cookies disabled for now by setting `network.cookie.cookieBehavior` to **1**.~
 
-    **Implementation Status**: Double-keying cookies should just work by setting `privacy.firstparty.isolate` to **true**. However, [we have not audited that](https://gitlab.torproject.org/legacy/trac/-/issues/21905) yet and there is still the [UI part missing for managing cookies in Private Browsing Mode](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/10353). We therefore opted to keep third-party cookies disabled for now by setting `network.cookie.cookieBehavior` to **1**.
+    `So 3rd party cookies realistically are going away relatively soon, chrome is starting to phase them out entirely in 2024: https://developers.google.com/privacy-sandbox/3pcd`
 
 2. **Cache**