@@ -125,6 +125,7 @@ Violations in these properties typically result in serious risk for the user in
3.[Disk Avoidance](#43-disk-avoidance)
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.
Built-in extensions also MUST follow these requirements.
4.[Least Privilege](#44-least-privilege)
...
...
@@ -165,37 +166,24 @@ In addition to the above design requirements, the technology decisions about the
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.~
`TODO: 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~**
~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.~
4.**Minimize Global Privacy Options**
3.**Minimize global privacy-affecting features and settings**
[Another failure of Torbutton](https://gitlab.torproject.org/legacy/trac/-/issues/3100) was the options panel.
Each option that detectably alters browser behavior can be used as a fingerprinting tool.
Similarly, all extensions [should be disabled in the mode](https://blog.chromium.org/2010/06/extensions-in-incognito.html) except as an opt-in basis.
We should not load system-wide and/or operating system provided addons or plugins.
User customizable settings which measurably alters browser behavior can be used by adversaries as a fingerprinting tool.
Therefore the such settings SHOULD NOT be made available to users.
However, browser features which affect accessibility MUST be configurable by the user.
Instead of global browser privacy options, privacy decisions should be made [per URL bar origin](https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI) to eliminate the possibility of linkability between domains.
For example, when a plugin object (or a JavaScript access of window.plugins) is present in a page, the user should be given the choice of allowing that plugin object for that URL bar origin only.
The same goes for exemptions to third party cookie policy, geolocation, and any other privacy permissions.
Browser features which affect privacy and is not required for general web-browsing but is required for particular website functionality should be allowed with explicit user-consent on a per first-party domain basis to eliminate the possibility of linkability between domains.
Such functionality includes webcam and microphone access, geolocation, and canvas read-access.
Built-in extensions MUST follow these same guidelines.
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.
Browser or extension features which affect privacy MUST be kept in lock-step with the browser version maximize user privacy.
Out-of-band updates affecting such functionality MUST not be enabled.
5.**~No filters~**
4.**~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.~
...
...
@@ -219,7 +207,7 @@ In addition to the above design requirements, the technology decisions about the
`TODO: this whole section can probably be removed entirely since we're seriously considering adding uBlock-origin support`
6.**Stay Current**
5.**Stay Current**
We believe that if we do not stay current with the support of new web technologies, we cannot hope to substantially influence or be involved in their proper deployment or privacy realization.
However, we will likely disable high-risk features pending analysis, audit, and mitigation.
