Tracking prevention in Microsoft Edge
The tracking prevention feature in Microsoft Edge protects users from online tracking by restricting the ability of trackers to access browser-based storage as well as the network. It is built to uphold the Microsoft Edge browser privacy promise while also ensuring that there is no impact by default to website compatibility or the economic viability of the web.
Microsoft Edge currently offers users three levels of tracking prevention, which are selected by navigating to
- Basic - The least restrictive level of tracking prevention that is designed for users who enjoy personalized advertisements and who do not mind being tracked on the web. Basic only protects users against malicious trackers such as fingerprinters and cryptominers.
- Balanced (Default) - The default level of tracking prevention that is designed for users who want to see less personalized advertisements while minimizing the risk of compatibility issues as they browse the web. Balanced aims to block trackers from sites that users never engage with.
- Strict - The most restrictive level of tracking prevention that is designed for users who are okay trading website compatibility for maximum privacy.
The tracking prevention feature in Microsoft Edge is made up of three main components that work together to determine whether a specific resource from a website should be classified as a tracker and blocked. The components are as follows:
- Classification - The way Microsoft Edge determines whether a URL belongs to a tracker.
- Enforcement - The actions taken to protect Microsoft Edge users from URLs classified as trackers.
- Mitigations - The mechanisms provided to ensure user-specified favorite sites still work, while offering strong default protection.
Each of the components are explored and explained in detail on this page.
The first component of the tracking prevention feature in Microsoft Edge is classification. To classify online trackers and group them into categories, Microsoft Edge uses the Disconnect open source tracking protection lists. The lists are delivered via the "Trust Protection Lists" component, which is viewable at
edge://components. After being downloaded, the lists are stored on disk where you may use them to determine whether/how a particular URL is classified.
To determine if a URL is considered a tracker by the classification system in Microsoft Edge, a series of host names are checked, starting with an exact match and then proceeding to check for partial matches for up to four labels beyond the top-level domain.
Tested host names:
To provide protection from tracking actions on the web, Microsoft Edge takes two enforcement actions against classified trackers:
- Restrict storage access - If a known tracking resource tries to access any web storage where it may try to persist data about the user, Microsoft Edge blocks that access. This includes restricting the ability for that tracker to get or set cookies as well as access storage APIs such as
- Block resource loads - If a known tracking resource is being loaded on a website, Microsoft Edge may block that load before the request reaches the network depending on compatibility impact of the load and the tracking prevention setting a user has set. Blocked loads may include tracking scripts, pixels, iframes, and more. This prevents any data potentially being sent to the tracking domain and may even improve load times and page performance as a side effect.
A user may choose the page info flyout icon on the left side of the address bar to find out which trackers were blocked on a specific page:
How the enforcements are applied depends on what level of tracking prevention the user selected and the mitigations that may apply.
To ensure that web compatibility is preserved as much as possible, Microsoft Edge has three mitigations to help balance enforcements in specific situations. These are the Org Relationship mitigation, the Org Engagement mitigation, and the CompatExceptions List.
Before diving into the mitigations, it is worth defining the concept of an "Organization" or "Org" for short. Disconnect also maintains a list called entities.json that defines groups of URLs that are owned by the same parent organization/company. The tracking prevention feature in Microsoft Edge uses this list in both the Org Relationship mitigation and the Org Engagement mitigation to minimize the occurrence of compatibility issues caused by tracking prevention affecting cross-organizational requests.
Org Relationship Mitigation
Several popular websites maintain both websites and Content Delivery Networks (CDNs) to serve static resources and content to those sites. To ensure that these types of scenarios are not affected by tracking prevention, Microsoft Edge exempts a site from tracking prevention when the site is making third-party requests to other sites owned by the same parent organization (as defined in the Disconnect entities.json list). This is best illustrated by an example.
An organization named Org1 owns the domains
org1-cdn.test, as defined in the Disconnect entities.json list. Imagine that
org1-cdn.testis classified as a tracker and would normally have tracking prevention enforcements applied to it. If a user visits
https://org1.testand the site tries to load a resource from
https://org1-cdn.test, Microsoft Edge does not take any enforcement actions against requests made to
org1-cdn.testeven though it is not a first-party URL. If another URL that is not part of the Org1 organization tries to load that same resource, however, then the request would be subject to enforcements because it is not part of the same organization.
Even though this relaxes tracking prevention enforcements for sites that belong to the same organization, it is unlikely that this introduces a high amount of privacy risk since such organizations are able to determine which sites/resources you have accessed on
https://org1-cdn.testusing internal back-end data.
Org Engagement Mitigation
The org engagement mitigation was created to minimize compatibility risks introduced by tracking prevention by ensuring that sites owned by organizations that users sufficiently engage with continue to work as expected across the web. It makes use of site engagement to relax enforcements whenever a user has established an ongoing relationship (currently defined by a site engagement score of 4.1 or greater) with a given site. This again is best illustrated by an example:
An organization named Social Org owns the domains
Users are considered to have a relationship with Social Org if they have established a site engagement score of 4.1 or greater with any one of domains owned by Social Org.
If another site,
https://content-embedder.example, includes third-party content (say an embedded video from
social-videos.example) from any of the domains owned by Social Org that would normally be restricted by tracking prevention enforcements, the site is exempt from tracking prevention enforcements as long as the user's site engagement score with domains owned by Social Org is maintained above the threshold.
If a site does not belong to an organization, a user must establish a site engagement score of 4.1 or greater with it directly before any storage access/resource load blocks imposed by tracking prevention are relaxed.
The org engagement mitigation is currently only applied in Balanced mode so that Microsoft Edge is offering the highest possible protections for users who have opted into Strict.
The CompatExceptions List
Based on recent user feedback Microsoft received, Microsoft Edge maintains a small list of sites (most of which are in the Disconnect Content category) that were breaking due to tracking prevention despite having the above two mitigations in place. Sites on this list are exempt from tracking prevention enforcements. The list can be found on disk at the locations described below. Users may override entries on it using the Block option in
To avoid maintaining this list moving forwards, Microsoft is currently working on the Storage Access API in the open-source codebase. The Storage Access API gives site developers a way to request storage access from users directly, providing users with more transparency into how their privacy settings are affecting their browsing experience, and giving site developers controls to quickly and intuitively unblock themselves.
After the Storage Access API is implemented, Microsoft will deprecate the CompatExceptions list and reach out to the affected sites both to make them aware of the issues, and to request that they use the Storage Access API moving forward.
Current tracking prevention behavior
The following table shows the enforcement actions and mitigations that are applied to each category of classified tracker in Microsoft Edge.
- Along the top are the categories of trackers as defined by Disconnect tracking protection list categories.
- Along the left side are the three levels of tracking prevention in Microsoft Edge (Basic, Balanced, and Strict).
- The letter
Sindicates that storage access is blocked.
- The letter
Bindicates that both storage access and resource loads (such as network requests) are blocked.
- A hyphen (
-) indicates that no block is applied to either storage access or resource loads.
|Advertizing||Analytics||Content||Cryptomining||Fingerprinting||Social||Other||Same Org Mitigation||Org Engagement Mitigation|
The org engagement mitigation does not apply to the Cryptomining or Fingerprinting categories.
Strict mode blocks more resource loads than Balanced. The blocking of more resource loads may result in Strict mode appearing to block less tracking requests than Balanced since the trackers making the requests are never loaded.
The Fingerprinting column in Current tracking prevention behavior refers to trackers that are on the Fingerprinting list in addition to another list. Trackers that appear on solely on the Fingerprinting list are considered non-malicious fingerprinters and are not blocked.
In Microsoft Edge 79, the default behavior was to apply Strict mode protections in InPrivate. In Microsoft Edge 80, this behavior was replaced by a switch in
edge://settings/privacy that allows users to decide whether to apply Strict mode protections or to keep their regular settings while browsing InPrivate.
Determining whether/how a particular URL is classified
The easiest way to determine whether a specific URL is classified as a known tracker is to perform the following steps.
- Open DevTools and navigate to the Console tab.
- Refresh the webpage.
- You may want to clear Cookies and other site data first to reset site engagement scores and ensure a completely clean slate.
- Look for any messages that read
Tracking Prevention blocked access to storage for <URL>.
- You may expand the messages to see the individual URLs that were blocked.
- If you need to determine which category a specific blocked site is in, the easiest way to do this is to search for it on the Disconnect services.json list. The entries are alphabetized, so scrolling to the top of a block of site entries enables you to find the specific category for a particular site.
If you need to access the tracking prevention lists that are stored on disk, each may be found in one of two locations.
Component-based updates - The lists that are downloaded from the "Trust Protection Lists" component
%LOCALAPPDATA%\Microsoft\Edge <OptionalChannelName>\User Data\Trust Protection Lists
~/Library/Application Support/Microsoft Edge <OptionalChannelName>/Trust Protection Lists
Installation directory - The lists that are bundled with the Microsoft Edge Installer. If you selected a different installation directory, your exact paths may be different.
%PROGRAMFILES(x86)%\Microsoft\ Edge <OptionalChannelName>\Application<Version>\Trust Protection Lists
/Applications/Microsoft Edge.app/Contents/Frameworks/Microsoft Edge Framework.framework/Libraries/Trust Protection Lists
Frequently Asked Questions
The following section contains answers to frequently asked questions about the tracking prevention feature in Microsoft Edge.
Is there a way to block or allow specific trackers for debugging purposes?
Currently, Microsoft Edge only exposes an option to disable tracking prevention enforcements from running on a specified site. This option is accessed via the page info flyout or through the
That being said, the Block and Allow options on the
edge://settings/content/cookies page may be used to allow or deny specific domains access to storage such as cookies and other browser storage mechanisms. This is useful for debugging site issues that are caused by tracking prevention enforcements blocking access to storage for a specific site.