This document describes the [design requirements](#2-design-requirements-and-philosophy), [adversary model](#3-adversary-model) , and [implementation](#4-implementation) of a browser which defends against active network adversaries and passive local forensic adversaries.
This document describes the [design requirements](#2-design-requirements-and-philosophy), [adversary model](#3-adversary-model) , and [implementation](#4-implementation) of a browser which defends against active network adversaries and passive local forensic adversaries.
...
@@ -485,60 +479,3 @@ We make use of certificate pinning to ensure that update checks cannot be tamper
...
@@ -485,60 +479,3 @@ We make use of certificate pinning to ensure that update checks cannot be tamper
The Firefox updater also has code to ensure that it can reliably access the update server to prevent availability attacks, and complains to the user after 48 hours go by without a successful response from the server.
The Firefox updater also has code to ensure that it can reliably access the update server to prevent availability attacks, and complains to the user after 48 hours go by without a successful response from the server.
Additionally, we use Tor's SOCKS username and password isolation to ensure that every new request to the updater (provided the former got issued more than 10 minutes ago) traverses a separate circuit, to avoid holdback attacks by exit nodes.
Additionally, we use Tor's SOCKS username and password isolation to ensure that every new request to the updater (provided the former got issued more than 10 minutes ago) traverses a separate circuit, to avoid holdback attacks by exit nodes.
## 6. Towards Transparency in Navigation Tracking
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.
Because the total elimination of side channels during cross-origin navigation will undoubtedly break federated login as well as destroy ad revenue, we also describe auditable alternatives and promising web draft standards that would preserve this functionality while still providing transparency when tracking is occurring.
### 6.1 Deprecation Wishlist
1.**The Referer Header**
When leaving a .onion domain we set the Referer header to an empty string by setting the `network.http.referer.hideOnionSource` preference to **true**.
That avoids leaking information which might be especially problematic in the case of transitioning from a .onion domain to one reached over clearnet.
Apart from that we haven't disabled or restricted the Referer ourselves because of the non-trivial number of sites that rely on the Referer header to "authenticate" image requests and deep-link navigation on their sites.
Furthermore, there seems to be no real privacy benefit to taking this action by itself in a vacuum, because many sites have begun encoding Referer URL information into GET parameters when they need it to cross HTTP to HTTPS scheme transitions.
Google's +1 buttons are the best example of this activity.
Because of the availability of these other explicit vectors, we believe the main risk of the Referer header is through inadvertent and/or covert data leakage.
In fact, [a great deal of personal data](http://web2.research.att.com/export/sites/att_labs/people/Krishnamurthy_Balachander/papers/wosn09.pdf) is inadvertently leaked to third parties through the source URL parameters.
We believe the Referer header should be made explicit, and believe that Referrer Policy, which is available since Firefox 52, provides a [decent step in this direction](https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-header).
If a site wishes to transmit its URL to third party content elements during load or during link-click, it should have to specify this as a property of the associated [HTML tag](https://blog.mozilla.org/security/2015/01/21/meta-referrer/) or in an HTTP response header.
With an explicit property or response header, it would then be possible for the user agent to inform the user if they are about to click on a link that will transmit Referer information (perhaps through something as subtle as a different color in the lower toolbar for the destination URL).
This same UI notification can also be used for links with the ["ping"](https://developers.whatwg.org/links.html#ping) attribute.
2.**window.name**
[window.name](https://developer.mozilla.org/En/DOM/Window.name) is a DOM property that for some reason is allowed to retain a persistent value for the lifespan of a browser tab.
It is possible to utilize this property for [identifier storage](https://www.thomasfrank.se/sessionvars.html) during click navigation.
This is sometimes used for additional CSRF protection and federated login.
It's our opinion that the contents of window.name should not be preserved for cross-origin navigation, but doing so may break federated login for some sites.
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 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.
Web-Send is a browser-based link sharing and federated login widget that is designed to operate without relying on third-party tracking or abusing other cross-origin link-click side channels.
It has a compelling list of [privacy and security features](https://web.archive.org/web/20130213034335/http://web-send.org:80/featurs.html), especially if used as a "Like button" replacement.
Mozilla's Persona is designed to provide decentralized, cryptographically authenticated federated login in a way that does not expose the user to third party tracking or require browser redirects or side channels.
While it does not directly provide the link sharing capabilities that Web-Send does, it is a better solution to the privacy issues associated with federated login than Web-Send is.
