The browser MUST NOT bypass Tor proxy settings for any content.

The browser MUST NOT provide any stored state to the content window from other browsers or other browsing modes, including shared state from plugins, machine identifiers, and TLS session state.

The browser SHOULD NOT write any browsing history information to disk, or store it in memory beyond the duration of one Tor session, unless the user has explicitly opted to store their browsing history information to disk.

The browser MUST NOT write or cause the operating system to write any information to disk outside of the application directory. All exceptions and shortcomings due to operating system behavior MUST BE documented.

The browser SHOULD NOT perform unsafe updates or upgrades.

User activity on one url bar domain MUST NOT be linkable to their activity in any other domain by any third party. This property specifically applies to linkability from stored browser identifiers, authentication tokens, and shared state. This functionality SHOULD NOT interfere with federated login in a substantial way.

User activity on one url bar domain MUST NOT be linkable to their activity in any other domain by any third party. This property specifically applies to linkability from fingerprinting browser behavior.

The browser SHOULD provide an obvious, easy way to remove all of their authentication tokens and browser state and obtain a fresh identity. Additionally, this should happen by default automatically upon browser restart.

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: 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.

In general, we try to find solutions to privacy issues that will not induce site breakage, though this is not always possible.

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 decides to craft an exemption to allow a plugin to be used, it MUST ONLY apply to the top level urlbar domain, and not to all sites, to reduce linkability.

Another failure of Torbutton was (and still is) 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 except as an opt-in basis. We should not load system-wide addons or plugins.

Instead of global browser privacy options, privacy decisions should be made per top-level url-bar domain 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 top-level url-bar domain only. The same goes for exemptions to third party cookie policy, geo-location, and any other privacy permissions.

If the user has indicated they do not care about local history storage, these permissions can be written to disk. Otherwise, they should remain memory-only.

Filter-based addons such as AdBlock Plus, Request Policy, Priv3, and Sharemenot are to be avoided. We believe that these addons do not add any real privacy to a proper implementation of the above privacy requirements, as all third parties are prevented from tracking users between sites by the implementation. Filter-based addons can also introduce strange breakage and cause usability nightmares, and will also fail to do their job if an adversary simply registers a new domain or creates a new url path. Worse still, the unique filter sets that each user is liable to create/install likely 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 who 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.

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 certain new features (where possible) pending analysis and audit.

The Torbutton xpi sets the Firefox proxy settings to use Tor directly as a SOCKS proxy. It sets network.proxy.socks_remote_dns, network.proxy.socks_version, and network.proxy.socks_port.

Plugins have the ability to make arbitrary OS system calls. This includes the ability to make UDP sockets and send arbitrary data independent of the browser proxy settings.

Torbutton disables plugins by using the @mozilla.org/plugin/host;1 service to mark the plugin tags as disabled. Additionally, we set plugin.disable_full_page_plugin_for_types to the list of supported mime types for all currently installed plugins.

In addition, to prevent any unproxied activity by plugins at load time, we also patch the Firefox source code to prevent the load of any plugins except for Flash and Gnash.

External apps, if launched automatically, can be induced to load files that perform network activity. In order to prevent this, Torbutton installs a component to provide the user with a popup whenever the browser attempts to launch a helper app.

Design Goal: All cookies should be double-keyed to the top-level domain. There exists a Mozilla bug that contains a prototype patch, but it lacks UI, and does not apply to modern Firefoxes.

Implementation Status: As a stopgap to satisfy our design requirement of unlinkability, we currently entirely disable 3rd party cookies by setting network.cookie.cookieBehavior to 1. We would prefer that third party content continue to function , but we believe the requirement for unlinkability trumps that desire.

Cache is isolated to the top-level url bar domain by using a technique pioneered by Colin Jackson et al, via their work on SafeCache. The technique re-uses the nsICachingChannel.cacheKey attribute that Firefox uses internally to prevent improper caching of HTTP POST data.

However, to increase the security of the isolation and to solve strange and unknown conflicts with OCSP, we had to patch Firefox to provide a cacheDomain cache attribute. We use the full url bar domain as input to this field.

Furthermore, we chose a different isolation scheme than the Stanford implementation. First, we decoupled the cache isolation from the third party cookie attribute. Second, we use several mechanisms to attempt to determine the actual location attribute of the top-level window (the url bar domain) used to load the page, as opposed to relying solely on the referer property.

Therefore, the original Stanford test cases are expected to fail. Functionality can still be verified by navigating to about:cache and viewing the key used for each cache entry. Each third party element should have an additional "domain=string" property prepended, which will list the top-level urlbar domain that was used to source the third party element.

HTTP authentication tokens are removed for third party elements using the http-on-modify-request observer to remove the Authorization headers to prevent silent linkability between domains. We also needed to patch Firefox to cause the headers to get added early enough to allow the observer to modify it.

Design Goal: DOM storage for third party domains MUST BE isolated to the url bar domain, to prevent linkability between sites.

Implementation Status: Because it is isolated to third party domain as opposed to top level url bar domain, we entirely disable DOM storage as a stopgap to ensure unlinkability.

TLS session resumption and HTTP Keep-Alive must not allow third party origins to track users via either TLS session IDs, or the fact that different requests arrive on the same TCP connection.

Design Goal: TLS session resumption IDs must be limited to the top-level url bar domain. HTTP Keep-Alive connections from a third party in one top-level domain must not be reused for that same third party in another top-level domain.

Implementation Status: We plan to disable TLS session resumption, and limit HTTP Keep-alive duration.

window.name is a magical 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.

In order to eliminate linkability but still allow for sites that utilize this property to function, we reset the window.name property of tabs in Torbutton every time we encounter a blank referer. This behavior allows window.name to persist for the duration of a link-driven navigation session, but as soon as the user enters a new URL or navigates between https/http schemes, the property is cleared.

Design Goal: Every distinct navigation session (as defined by a non-blank referer header) MUST exit through a fresh Tor circuit in Tor Browser to prevent exit node observers from linking concurrent browsing activity.

Implementation Status: The Tor feature that supports this ability only exists in the 0.2.3.x-alpha series. Ticket #3455 is the Torbutton ticket to make use of the new Tor functionality.

Plugins add to fingerprinting risk via two main vectors: their mere presence in window.navigator.plugins, as well as their internal functionality.

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.

Implementation Status: Currently, we entirely disable all plugins in Tor Browser. However, as a compromise due to the popularity of Flash, we intend to work towards a click-to-play barrier using NoScript that is available only after the user has specifically enabled plugins. Flash will be the only plugin available, and we will ship a settings.sol file to disable Flash cookies, and to restrict P2P features that likely bypass proxy settings.

According to the Panopticlick study, fonts provide the most linkability when they are provided as an enumerable list in filesystem order, via either the Flash or Java plugins. However, it is still possible to use CSS and/or Javascript to query for the existence of specific fonts. With a large enough pre-built list to query, a large amount of fingerprintable information may still be available.

Design Goal: To address the Javascript issue, we intend to limit the number of fonts an origin can load, gracefully degrading to built-in and/or remote fonts once the limit is reached.

Implementation Status: Aside from disabling plugins to prevent enumeration, we have not yet implemented any defense against CSS or Javascript fonts.

Design Goal: All Tor Browser users should 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. Additionally, we remove content script access to Components.interfaces, which can be used to fingerprint OS, platform, and Firefox minor version.

Both CSS and Javascript have a lot of irrelevant information about the screen resolution, usable desktop size, OS widget size, toolbar size, title bar size, and other desktop features that are not at all relevant to rendering and serve only to provide information for fingerprinting.

Design Goal: Our design goal here is to reduce the resolution information down to the bare minimum required for properly rendering inside a content window. We intend to report all rendering information correctly with respect to the size and properties of the content window, but report an effective size of 0 for all border material, and also report that the desktop is only as big as the inner content window. Additionally, new browser windows are sized such that their content windows are one of ~5 fixed sizes based on the user's desktop resolution.

Implementation Status: We have implemented the above strategy for Javascript using Torbutton's JavaScript hooks as well as a window observer to resize new windows based on desktop resolution. However, CSS Media Queries still need to be dealt with.

Design Goal: All Tor Browser users should 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. Additionally, the Tor software should detect if the users 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.

Implementation Status: We set the timezone using the TZ environment variable, which is supported on all platforms. Additionally, we plan to obtain a clock offset from Tor, but this won't be available until Tor 0.2.3.x is in use.

Javascript performance fingerprinting is the act of profiling the performance of various Javascript functions for the purpose of fingerprinting the Javascript engine and the CPU.

Design Goal: We have several potential mitigation approaches to reduce the accuracy of performance fingerprinting without risking too much damage to functionality. Our current favorite is to reduce the resolution of the Event.timeStamp and the Javascript Date() object, while also introducing jitter. Our goal is to increase the amount of time it takes to mount a successful attack. Mowery et al found that even with the default precision in most browsers, they required up to 120 seconds of amortization and repeated trials to get stable results from their feature set. We intend to work with the research community to establish the optimum tradeoff between quantization+jitter and amortization time.

Implementation Status: We have no implementation as of yet.

Keystroke fingerprinting is the act of measuring key strike time and key flight time. It is seeing increasing use as a biometric.

Design Goal: We intend to rely on the same mechanisms for defeating Javascript performance fingerprinting: timestamp quantization and jitter.

Implementation Status: We have no implementation as of yet.

WebGL is fingerprintable both through information that is exposed about the underlying driver and optimizations, as well as through performance fingerprinting.

Design Goal: Because of the large amount of potential fingerprinting vectors, we intend to deploy a similar strategy against WebGL as for plugins. First, WebGL canvases will have click-to-play placeholders, and will not run until authorized by the user. Second, we intend to obfuscate driver information by hooking getParameter(), getSupportedExtensions(), getExtension(), and getContextAttributes() to provide standard minimal, driver-neutral information.

Implementation Status: Currently we simply disable WebGL.

In order to reduce fingerprinting, we block access to these two interfaces from content script. Components.lookupMethod can undo our Javascript hooks, and Components.interfaces can be used for fingerprinting the platform, OS, and Firebox version, but not much else.

This patch exposes a pref 'permissions.memory_only' that properly isolates the permissions manager to memory, which is responsible for all user specified site permissions, as well as stored HTTPS STS policy from visited sites. The pref does successfully clear the permissions manager memory if toggled. It does not need to be set in prefs.js, and can be handled by Torbutton.

Design Goal: As an additional design goal, we would like to later alter this patch to allow this information to be cleared from memory. The implementation does not currently allow this.

The intermediate certificate store holds information about SSL certificates that may only be used by a limited number of domains. In some cases effectively recording on disk the fact that a website owned by a certain organization was viewed.

Design Goal: As an additional design goal, we would like to later alter this patch to allow this information to be cleared from memory. The implementation does not currently allow this.

This patch provides a trivial modification to allow us to properly remove HTTP auth for third parties. This patch allows us to defend against an adversary attempting to use HTTP auth to silently track users between domains.

To increase the security of cache isolation and to solve strange and unknown conflicts with OCSP, we had to patch Firefox to provide a cacheDomain cache attribute. We use the full url bar domain as input to this field.

As an experimental defense against Website Traffic Fingerprinting, we patch the standard HTTP pipelining code to randomize the number of requests in a pipeline, as well as their order.

We cannot use the @mozilla.org/extensions/blocklist;1 service, because we actually want to stop plugins from ever entering the browser's process space and/or executing code (for example, AV plugins that collect statistics/analyze URLs, magical toolbars that phone home or "help" the user, skype buttons that ruin our day, and censorship filters). Hence we rolled our own.

This patch prevents random URLs from being inserted into content-prefs.sqllite in the profile directory as content prefs change (includes site-zoom and perhaps other site prefs?).

Decloak.net is the canonical source of plugin and external-application based proxy-bypass exploits. It is a fully automated test suite maintained by HD Moore as a service for people to use to test their anonymity systems.

Deanonymizer.com is another automated test suite that tests for proxy bypass and other information disclosure vulnerabilities. It is maintained by Kyle Williams, the author of JanusVM and JanusPA.

The JonDos people also provide an anonymity tester. It is more focused on HTTP headers than plugin bypass, and points out a couple of headers Torbutton could do a better job with obfuscating.

Browserspy.dk provides a tremendous collection of browser fingerprinting and general privacy tests. Unfortunately they are only available one page at a time, and there is not really solid feedback on good vs bad behavior in the test results.

The Privacy Analyzer provides a dump of all sorts of browser attributes and settings that it detects, including some information on your origin IP address. Its page layout and lack of good vs bad test result feedback makes it not as useful as a user-facing testing tool, but it does provide some interesting checks in a single page.

Mr. T is a collection of browser fingerprinting and deanonymization exploits discovered by the ha.ckers.org crew and others. It is also not as user friendly as some of the above tests, but it is a useful collection.

Gregory Fleischer has been hacking and testing Firefox and Torbutton privacy issues for the past 2 years. He has an excellent collection of all his test cases that can be used for regression testing. In his Defcon work, he demonstrates ways to infer Firefox version based on arcane browser properties. We are still trying to determine the best way to address some of those test cases.

This page checks to ensure you are using a valid Tor exit node and checks for some basic browser properties related to privacy. It is not very fine-grained or complete, but it is automated and could be turned into something useful with a bit of work.