Today, we’re releasing an experimental preview of tracking prevention for Microsoft Edge. We initially demoed this feature at Build 2019 as one of the concepts we’re exploring to offer greater transparency and control over your online data. Microsoft Edge Insiders can now try out tracking prevention by enabling the experimental flag on Microsoft Edge preview builds starting with version 188.8.131.52 (today’s Canary channel release). (Note: Today’s Canary release is not currently available for macOS due to a build issue. Tracking prevention will be available in the next update to the Canary channel on macOS.)
Tracking prevention is designed to protect you from being tracked by websites that you aren’t accessing directly. Whenever a website is visited, trackers from other sites may save information in the browser using cookies and other storage mechanisms. This information may include the sites you’ve visited and the content you’re interested in, building a digital profile which can be accessed by organizations to offer personalized content when visiting other sites.
The implementation in Microsoft Edge Insider preview builds is early and is likely to change as we hear from our customers and continue to test the feature. For that reason, it’s currently behind an experimental flag and disabled by default. There may be some bugs or site issues, but we want to get it into your hands to hear what you think.
Turning on tracking prevention
To try out tracking prevention, you’ll need to be on a Microsoft Edge Insider preview build (version 184.108.40.206 or higher – or at least today’s Canary channel release). Once you’re on the right build, you’ll need to manually enable the experiment.
In the address bar, enter
edge://flags#edge-tracking-prevention to open the experimental settings page. Click the dropdown and choose Enabled, then click the Relaunch Now button to close all Microsoft Edge windows and relaunch Microsoft Edge.
That’s it! Once the tracking prevention experiment is enabled, you can go to the Microsoft Edge privacy settings page to control settings for tracking prevention. In the address bar, enter
edge://settings/privacy and adjust the settings as desired:
The default tracking prevention setting is Balanced, which blocks 3rd party trackers and known malicious trackers for an experience that balances privacy and web compatibility. You can customize tracking prevention to your preferences by setting it to Strict, which blocks the majority of 3rd party trackers, or Basic, which only blocks malicious trackers.
How it works
When blocking a tracker, we aim to stop it from accessing previously stored tracking information and storing new tracking information. When tracking resources don’t add meaningful functionality to the page, we may even block them entirely. In order to do this, tracking prevention is made up of three main components.
- Classification: How we determine what is considered a tracking URL.
- Enforcement: The actions we take to protect our users from trackers.
- Mitigations: The mechanisms we use to make sure your favorite sites still work, while offering strong default protection.
We’ve added a new component to Microsoft Edge, Trust Protection Lists, that contains the latest information on which organizations may be trying to track users on the web. This component allows us to be flexible with where we source details on what a tracker is and when we deliver updated lists to our users.
To check if the URL is considered a tracker by our classification system, we check a series of hostnames, starting with an exact match and then proceeding to check for partial matches for up to 4 labels beyond the top-level domain.
If any of those hostnames represents a known tracker, we proceed with evaluating enforcement actions intended to prevent the user from being tracked.
To provide protection for our users from tracking actions on the web, we take two enforcement actions against 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, we will block that access. This includes restricting the ability for that tracker to get or set cookies as well as access storage APIs such as IndexedDB and localStorage.
- Block resource loads: If a known tracking resource is being loaded on a website, we may block that load before the request reaches the network depending on its compatibility impact and the tracking prevention setting you have 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 performance of the page as a side effect.
You can view the number of trackers blocked on a page by clicking the page info button next to the URL in the address bar at the top of the browser. Here you can change the tracking prevention setting on a site by site basis if you trust a site, or if something doesn’t seem to be working properly.
The web is a complex place and we realize there is no “one size fits all” solution to privacy. Depending on the mode of tracking prevention you enable, we will take different actions to balance our enforcement and put you in control of your personal experience on the web.
Every tracking resource is classified into a category that best represents the type of tracking activities it performs. Every tracking prevention mode uses a set of categories to represent what types of trackers will have storage access restricted or resource loads blocked.
Not all types of trackers are equal. Fingerprinting trackers are those trackers that attempt to identify you, or your browser based on its unique characteristics. Cryptomining scripts are scripts that attempt to abuse your processor and memory to generate cryptocurrencies, reducing your browser’s performance and battery life. Even when you’ve opted into our Basic mode you will be protected from these egregious types of tracking.
By default, in Balanced, all users will get a robust set of tracker categories that have storage access blocked, and a slightly smaller set that have resource loads blocked. We have taken care to ensure that these sets provide protection while ensuring compatibility as you browse the web and use your favorite applications. For example, Balanced will allow third party content to enable login flows using third party identities or social network commenting on third party sites.
Our Strict mode provides the largest set of categories to block storage access and resource loads. This is for users who don’t mind a little bit of site breakage in exchange for greater protection. This is also the default level of protection when you launch an InPrivate window.
Not all organizations do business on the internet using just one domain name. In order to help keep sites working smoothly, we group domains owned and operated by the same organization together. For instance, we might have a grouping that says “Org1” owns the domains “
org1.test” and “
org1-cdn.test”. If the user visits
https://org1.test/, and it tries to load a resource from
https://org1-cdn.test/, we won’t take any enforcement actions against that auxiliary domain even though it’s not a first party URL. However, if another organization, Org2 (
https://org2.test/), tries to load that same resource, it would be subject to restrictions because it is not part of the same organization.
We are currently experimenting with ways to provide even greater privacy protection by investigating opportunities to expand the types of trackers we block for you. For the Balanced setting, we may start to consider your recent interactions with sites. For example, for sites that you interact with in a first party context on a regular basis, access to cookies, localStorage, IndexedDB and other storage may be allowed in a broader context to ensure web functionality, like login flows or social network commenting, just works. For sites you don’t visit, we may more aggressively block that content in a third-party context. This will let us improve protection while the sites you care about continue to work across the web.
For our enterprise customers, we are experimenting with exposing policies to allow the right balance of control in order to ensure all their users are protected and existing line of business apps continue to work.
In order to help web developers identify trackers on their websites that may be affected by this feature, we’ve added some DevTools console messages to show when enforcement actions are taken. These can be used to see exactly what was restricted and help identify which parts of a site may need to be better tailored towards protecting a user’s privacy.
Send us feedback
We want to hear from you about this feature. If you think something’s not working right or it’s blocking too much or too little, please send us feedback using the “smiley face” icon in the top right corner of the browser.
If you’re a web developer, try out the DevTools experience with tracking preventing enabled and let us know what you think. If you’re a web surfer, catch some waves and let us know how tracking prevention fits into your browsing habits.
We’ll use your feedback on this experimental feature in the Canary and Dev channels to understand potential impact to web compatibility and iterate on the experience to be helpful and easy to use.
As we gather feedback and continue to tune the feature, we will begin rolling out tracking prevention to a broader audience.
Thanks for being a part of this early preview!
– Brandon Maslen, Senior Software Engineer
– Ryan Cropp, Software Engineer