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

The browser MUST NOT provide the content window with any state from any other browsers or any non-Tor browsing modes. This includes shared state from independent plugins, and shared state from Operating System implementations of TLS and other support libraries.

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.

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.

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.

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

The browser MUST provide an obvious, easy way for the user to remove all of its authentication tokens and browser state and obtain a fresh identity. Additionally, the browser SHOULD clear linkable state by default automatically upon browser restart, except at user option.

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

Another failure of Torbutton 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 except as an opt-in basis. We should not load system-wide and/or Operating System provided addons or plugins.

Instead of global browser privacy options, privacy decisions should be made per url bar origin 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, geo-location, and any other privacy permissions.

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.

Site-specific or filter-based addons such as AdBlock Plus, Request Policy, Ghostery, 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, 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.

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

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 high-risk features pending analysis, audit, and mitigation.

The adversary's primary goal is direct compromise and bypass of Tor, causing the user to directly connect to an IP of the adversary's choosing.

If direct proxy bypass is not possible, the adversary will likely happily settle for the ability to correlate something a user did via Tor with their non-Tor activity. This can be done with cookies, cache identifiers, javascript events, and even CSS. Sometimes the fact that a user uses Tor may be enough for some authorities.

The adversary may also be interested in history disclosure: the ability to query a user's history to see if they have issued certain censored search queries, or visited censored sites.

The primary goal of the advertising networks is to know that the user who visited siteX.com is the same user that visited siteY.com to serve them targeted ads. The advertising networks become our adversary insofar as they attempt to perform this correlation without the user's explicit consent.

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

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.

The adversary can run exit nodes, or alternatively, they may control routers upstream of exit nodes. Both of these scenarios have been observed in the wild.

The adversary can also run websites, or more likely, they can contract out ad space from a number of different ad servers and inject content that way. For some users, the adversary may be the ad servers themselves. It is not inconceivable that ad servers may try to subvert or reduce a user's anonymity through Tor for marketing purposes.

The adversary can also inject malicious content at the user's upstream router when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor activity.

Additionally, at this position the adversary can block Tor, or attempt to recognize the traffic patterns of specific web pages at the entrance to the Tor network.

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.

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. 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 and Long-Term Unlikability design requirements.

There is an absurd amount of information available to websites via attributes of the browser. This information can be used to reduce anonymity set, or even uniquely fingerprint individual users. Attacks of this nature are typically aimed at tracking users across sites without their consent, in an attempt to subvert our Cross-Origin Fingerprinting Unlinkability and Long-Term Unlikability design requirements.

Fingerprinting is an intimidating problem to attempt to tackle, especially without a metric to determine or at least intuitively understand and estimate which features will most contribute to linkability between visits.

The Panopticlick study done by the EFF uses the Shannon entropy - the number of identifying bits of information encoded in browser properties - as this metric. Their result data is definitely useful, and the metric is probably the appropriate one for determining how identifying a particular browser property is. However, some quirks of their study means that they do not extract as much information as they could from display information: they only use desktop resolution and do not attempt to infer the size of toolbars. In the other direction, they may be over-counting in some areas, as they did not compute joint entropy over multiple attributes that may exhibit a high degree of correlation. Also, new browser features are added regularly, so the data should not be taken as final.

Despite the uncertainty, all fingerprinting attacks leverage the following attack vectors:

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.

The most comprehensive study of the statistical properties of this attack against Tor was done by Panchenko et al. Unfortunately, the publication bias in academia has encouraged the production of a number of follow-on attack papers claiming "improved" success rates, in some cases even claiming to completely invalidate any attempt at defense. These "improvements" are actually enabled primarily by taking a number of shortcuts (such as classifying only very small numbers of web pages, neglecting to publish ROC curves or at least false positive rates, and/or omitting the effects of dataset size on their results). Despite these subsequent "improvements", we are skeptical of the efficacy of this attack in a real world scenario, especially in the face of any defenses.

In general, with machine learning, as you increase the number and/or complexity of categories to classify while maintaining a limit on reliable feature information you can extract, you eventually run out of descriptive feature information, and either true positive accuracy goes down or the false positive rate goes up. This error is called the bias in your hypothesis space. In fact, even for unbiased hypothesis spaces, the number of training examples required to achieve a reasonable error bound is a function of the complexity of the categories you need to classify.

In the case of this attack, the key factors that increase the classification complexity (and thus hinder a real world adversary who attempts this attack) are large numbers of dynamically generated pages, partially cached content, and also the non-web activity of entire Tor network. This yields an effective number of "web pages" many orders of magnitude larger than even Panchenko's "Open World" scenario, which suffered continous near-constant decline in the true positive rate as the "Open World" size grew (see figure 4). This large level of classification complexity is further confounded by a noisy and low resolution featureset - one which is also relatively easy for the defender to manipulate at low cost.

To make matters worse for a real-world adversary, the ocean of Tor Internet activity (at least, when compared to a lab setting) makes it a certainty that an adversary attempting examine large amounts of Tor traffic will ultimately be overwhelmed by false positives (even after making heavy tradeoffs on the ROC curve to minimize false positives to below 0.01%). This problem is known in the IDS literature as the Base Rate Fallacy, and it is the primary reason that anomaly and activity classification-based IDS and antivirus systems have failed to materialize in the marketplace (despite early success in academic literature).

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 that reduce the accuracy of this attack by further contributing noise to hinder successful feature extraction.

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.

For the purposes of the browser itself, we limit the scope of this adversary to one that has passive forensic access to the disk after browsing activity has taken place. This adversary motivates our Disk Avoidance defenses.

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

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.

We also patch Firefox in order to prevent a DNS leak due to a WebSocket rate-limiting check. As stated in the patch, we believe the direct DNS resolution performed by this check is in violation of the W3C standard, but this DNS proxy leak remains present in stock Firefox releases.

During the transition to Firefox 17-ESR, a code audit was undertaken to verify that there were no system calls or XPCOM activity in the source tree that did not use the browser proxy settings. The only violation we found was that WebRTC was capable of creating UDP sockets and was compiled in by default. We subsequently disabled it using the Firefox build option --disable-webrtc.

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 IPv6 connections are not attempted, through the proxy or otherwise (Tor does not yet support IPv6). We have also verified that external protocol helpers, such as smb urls and other custom protocol handlers are all blocked.

Numerous other third parties have also reviewed and tested the proxy settings and have provided test cases based on their work. See in particular decloak.net.

Plugins have the ability to make arbitrary OS system calls and bypass proxy settings. 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. This block can be undone through both the Torbutton Security UI, and the Firefox Plugin Preferences.

If the user does enable plugins in this way, plugin-handled objects are still restricted from automatic load through Firefox's click-to-play preference plugins.click_to_play.

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

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, Torbutton installs a component to provide the user with a popup whenever the browser attempts to launch a helper app.

Additionally, modern desktops now pre-emptively 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 had to patch Firefox to emit an observer event during dragging to allow us to filter the drag events from Torbutton before the OS downloads the URLs the events contained.

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.

Design Goal: All cookies MUST be double-keyed to the url bar origin and third-party origin. 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 url bar origin 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 and reuse of HTTP POST data.

However, to increase the security of the isolation and to solve conflicts with OCSP relying the cacheKey property for reuse of POST requests, we had to patch Firefox to provide a cacheDomain cache attribute. We use the fully qualified url bar domain as input to this field, to avoid the complexities of heuristically determining the second-level DNS name.

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 (to obtain the url bar FQDN) 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 FQDN that was used to source the third party element.

Additionally, because the image cache is a separate entity from the content cache, we had to patch Firefox to also isolate this cache per url bar domain.

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.

DOM storage for third party domains MUST be isolated to the url bar origin, to prevent linkability between sites. This functionality is provided through a patch to Firefox.

Design Goal: Users should be able to click-to-play flash objects from trusted sites. To make this behavior unlinkable, we wish to include a settings file for all platforms that disables flash cookies using the Flash settings manager.

Implementation Status: We are currently having difficulties causing Flash player to use this settings file on Windows, so Flash remains difficult to enable.

Design Goal: TLS session resumption tickets and SSL Session IDs MUST be limited to the url bar origin. HTTP Keep-Alive connections from a third party in one url bar origin MUST NOT be reused for that same third party in another url bar origin.

Implementation Status: We currently clear SSL Session IDs upon New Identity, we disable TLS Session Tickets via the Firefox Pref security.enable_tls_session_tickets. We disable SSL Session IDs via a patch to Firefox. To compensate for the increased round trip latency from disabling these performance optimizations, we also enable TLS False Start via the Firefox Pref security.ssl.enable_false_start.

Because of the extreme performance benefits of HTTP Keep-Alive for interactive web apps, and because of the difficulties of conveying urlbar origin information down into the Firefox HTTP layer, as a compromise we currently merely reduce the HTTP Keep-Alive timeout to 20 seconds (which is measured from the last packet read on the connection) using the Firefox preference network.http.keep-alive.timeout.

However, because SPDY can store identifiers and has extremely long keepalive duration, it is disabled through the Firefox preference network.http.spdy.enabled.

Design Goal: To prevent attacks aimed at subverting the Cross-Origin Identifier Unlinkability privacy requirement, the browser MUST NOT store any identifiers (cookies, cache, DOM storage, HTTP auth, etc) for cross-origin redirect intermediaries that do not prompt for user input. For example, if a user clicks on a bit.ly url that redirects to a doubleclick.net url that finally redirects to a cnn.com url, only cookies from cnn.com should be retained after the redirect chain completes.

Non-automated redirect chains that require user input at some step (such as federated login systems) SHOULD still allow identifiers to persist.

Implementation status: There are numerous ways for the user to be redirected, and the Firefox API support to detect each of them is poor. We have a trac bug open to implement what we can.

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 non-consensual 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 click-driven navigation session, but as soon as the user enters a new URL or navigates between https/http schemes, the property is cleared.

We disable the password saving functionality in the browser as part of our Disk Avoidance requirement. However, since users may decide to re-enable disk history records and password saving, we also set the signon.autofillForms preference to false to prevent saved values from immediately populating fields upon page load. Since Javascript can read these values as soon as they appear, setting this preference prevents automatic linkability from stored passwords.

An extreme (but not impossible) attack to mount is the creation of HSTS supercookies. Since HSTS effectively stores one bit of information per domain name, an adversary in possession of numerous domains can use them to construct cookies based on stored HSTS state.

Design Goal: There appears to be three options for us: 1. Disable HSTS entirely, and rely instead on HTTPS-Everywhere to crawl and ship rules for HSTS sites. 2. Restrict the number of HSTS-enabled third parties allowed per url bar origin. 3. Prevent third parties from storing HSTS rules. We have not yet decided upon the best approach.

Implementation Status: Currently, HSTS state is cleared by New Identity, but we don't defend against the creation of these cookies between New Identity invocations.

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.

Website Traffic Fingerprinting is a statistical attack to attempt to recognize specific encrypted website activity.

In order to inform the user when their Tor Browser is out of date, we perform a privacy-preserving update check asynchronously in the background. The check uses Tor to download the file https://check.torproject.org/RecommendedTBBVersions and searches that version list for the current value for the local preference torbrowser.version. If the value from our preference is present in the recommended version list, the check is considered to have succeeded and the user is up to date. If not, it is considered to have failed and an update is needed. The check is triggered upon browser launch, new window, and new tab, but is rate limited so as to happen no more frequently than once every 1.5 hours.

If the check fails, we cache this fact, and update the Torbutton graphic to display a flashing warning icon and insert a menu option that provides a link to our download page. Additionally, we reset the value for the browser homepage to point to a page that informs the user that their browser is out of date.

In order to reduce fingerprinting, we block access to this interface from content script. 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 HSTS 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.

The intermediate certificate store records the intermediate SSL certificates the browser has seen to date. Because these intermediate certificates are used by a limited number of domains (and in some cases, only a single domain), the intermediate certificate store can serve as a low-resolution record of browsing history.

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.

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 url bar FQDN as input to this field.

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.sqlite in the profile directory as content prefs change (includes site-zoom and perhaps other site prefs?).

It turns out that on Windows 7 and later systems, the Taskbar attempts to automatically learn the most frequent apps used by the user, and it recognizes Tor Browser as a separate app from Vidalia. This can cause users to try to launch Tor Browser without Vidalia or a Tor instance running. Worse, the Tor Browser will automatically find their default Firefox profile, and properly connect directly without using Tor. This patch is a simple hack to cause Tor Browser to immediately exit in this case.

This patch is a simple 1-line hack to prevent SSL connections from caching (and then later transmitting) their Session IDs. There was no preference to govern this behavior, so we had to hack it by altering the SSL new connection defaults.

This patch creates an observer event in the HTTP connection manager to close all keep-alive connections that still happen to be open. This event is emitted by the New Identity button.

CSS Media Queries have a fingerprinting capability approaching that of Javascript. This patch causes such Media Queries to evaluate as if the device resolution was equal to the content window resolution.

Font availability can be queried by CSS and Javascript and is a fingerprinting vector. This patch limits the number of times CSS and Javascript can cause font-family rules to evaluate. Remote @font-face fonts are exempt from the limits imposed by this patch, and remote fonts are given priority over local fonts whenever both appear in the same font-family rule. We do this by explicitly altering the nsRuleNode rule represenation itself to remove the local font families before the rule hits the font renderer.

This patch updates our branding in compliance with Mozilla's trademark policy.

This patch prevents disk leaks from the download manager. The original behavior is to write the download history to disk and then delete it, even if you disable download history from your Firefox preferences.

This patch adds DuckDuckGo and StartPage to the Search Box, and sets our default search engine to StartPage. We deployed this patch due to excessive Captchas and complete 403 bans from Google.

This patch eliminates a race condition with "New Identity". Without it, cache-based Evercookies survive for up to a minute after clearing the cache on some platforms.

This patch prevents a DNS leak when using WebSockets. It also prevents other similar types of DNS leaks.

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.

This patch allows us to block external Drag and Drop events from Torbutton. We need to block Drag and Drop because Mac OS and Ubuntu both immediately load any URLs they find in your drag buffer before you even drop them (without using your browser's proxy settings, of course). This can lead to proxy bypass during user activity that is as basic as holding down the mouse button for slightly too long while clicking on an image link.

This patch provides an API that allows us to more easily isolate identifiers to the URL bar domain.

This patch prompts the user before returning canvas image data. Canvas image data can be used to create an extremely stable, high-entropy fingerprint based on the unique rendering behavior of video cards, OpenGL behavior, system fonts, and supporting library versions.

This patch causes mouse events to return coordinates relative to the content window instead of the desktop.

This patch causes window.screen to return the display resolution size of the content window instead of the desktop resolution size.

This patch prevents CSS and Javascript from discovering your desktop color scheme and/or theme.

This patch prevents cached images from being used to store third party tracking identifiers.

This patch provides HTTPS-Everywhere with an API to perform redirections more securely and without addon conflicts.

This patch prevents DOM Storage from being used to store third party tracking identifiers.

This patch removes a barrier that was informing users that plugins were disabled and providing them with a link to enable them. We felt this was poor user experience, especially since the barrier was displayed even for sites with dual Flash+HTML5 video players, such as YouTube.