Windows 10: Microsoft is testing some changes to Edge's Tracking Prevention settings, and the browser...

/u/Leopeva64-2 · Dec 10, 2021

submitted by /u/Leopeva64-2
[link] [comments]

:)

Brink · Dec 10, 2021

Microsoft Improving Tracking Prevention in Microsoft Edge

Today, we’re excited to announce some improvements to our tracking prevention feature that have started rolling out with Microsoft Edge 79. In our last blog post about tracking prevention in Microsoft Edge, we mentioned that we are experimenting with ways that our Balanced mode can be further improved to provide even greater privacy protections by default without breaking sites. We are looking to strike a balance between two goals:

Blocking more types of trackers – Microsoft Edge’s tracking prevention feature is powered by Disconnect’s tracking protection lists. We wanted to build off our initial implementation of tracking prevention in Microsoft Edge 78 and maximize the protections we offered by default by exploring blocking other categories of trackers (such as those in the Content category) in Balanced mode. These changes resulted in Microsoft Edge 79 blocking ~25% more trackers than Microsoft Edge 78.

Maintaining compatibility on the web – We knew that blocking more categories of trackers (especially those in the Content category) had the potential to break certain web workflows such as federated login or embedded social media content.

We learned through experimentation that it is possible to manage these tradeoffs by relaxing tracking prevention for organizations with which a user has established a relationship. To determine this list, we built on-device logic that combines users’ personal site engagement scores with the observation that some organizations own multiple domains that they use to deploy functionality across the web. It’s worth mentioning that this compatibility mitigation only applies to Balanced mode; Strict mode will continue to block the largest set of trackers without any mitigations.

Site engagement

The Chromium project’s site engagement score is a measure of how engaged a specific user is with a specific site. Site engagement scores can range from 0 (meaning a user has no relationship with a site) to 100 (meaning that a user is extremely engaged with a site). Activities such as browsing to a site repeatedly/over several days, spending time interacting with a site, and playing media on a site all cause site engagement scores to increase, whereas not visiting a site causes site engagement scores to decay exponentially over time. You can view your own site engagement scores by navigating to edge://site-engagement.

It’s also worth noting that site engagement scores are computed on your device and never leave it. This means that they are not synced across your devices or sent to Microsoft at any time.

Through local experimentation, we found that a site engagement score of 4.1 was a suitable threshold to define a site that a user has an active relationship with. While this value is subject to change based on user feedback and future experiments, it was selected as an initial value for two reasons:

It is low enough to ensure successful interactions with a site that a user has not previously had a history of engagement with.

It is high enough to ensure that sites a user visits infrequently will drop off the list relatively quickly.

While site engagement helps signal which sites are important to individual users, allowing third party storage access/resource loads from only these sites would not consider the fact that organizations can serve content that users care about from multiple domains, which can still result in site breakages.

Combining site engagement with organizations

In our last blog post about tracking prevention, we introduced the concept of an organization, that is, a single company that can own multiple domains related to their business (such as Org1 owning “org1.test” and “org1-cdn.test”). We also shared that in order to keep sites working smoothly, our tracking prevention implementation groups such domains together and exempts storage/resource blocks when a domain in one organization requests resources from another domain in that same organization.

In order to keep sites that users engage with working as expected while also increasing the types of trackers that we block by default, we combined the concept of an organization together with site engagement to create a new mitigation. This mitigation takes effect whenever a user has established an ongoing relationship with a given site (currently defined by a site engagement score of 4.1 or greater). For example, consider the following organization which owns two domains:

Social Org

example

social-videos.example

A user will be considered to have a relationship with Social Org if they have established a site engagement score of at least 4.1 with any one of its domains.

If another site, content-embedder.example, includes third-party content (say an embedded video from social-videos.example) from any of Social Org’s domains that would normally be restricted by tracking prevention, it will be temporarily allowed as long as the user’s site engagement score with Social Org’s domains is maintained above the threshold.

If a site does not belong to an organization, a user will need to establish a site engagement score of at least 4.1 with it directly before any storage access/resource load blocks imposed by tracking prevention will be lifted.

What does this mean?

By exempting sites and organizations that you have an ongoing and established relationship with from tracking prevention, we can ensure that the web services and applications you care about continue to work as you expect across the web. Leveraging site engagement also allows us to only unblock content that is likely to be important to you and reflects your current needs. This ensures that actions such as briefly visiting a site or seeing a popup aren’t enough to unblock content by themselves. If content does get unblocked due to you interacting with a site, it is always unblocked in a temporary manner that is proportional to how highly engaged you are with that site/its parent organization. By combining these exemptions with more strict blocking of trackers by default, we can provide higher levels of protection while still maintaining compatibility on the ever-evolving set of sites that you engage with.

It’s worth noting that tracking prevention, when enabled, will always block storage access and resource loads for sites that fall into the Fingerprinting or Cryptomining categories on Disconnect’s tracking protection lists. We will also not apply the site engagement-based mitigation outlined above for our most privacy-minded users who opt into tracking prevention’s Strict mode.

Putting everything together: What’s changed?

The best way to learn what’s changed with tracking prevention in Microsoft Edge 79 is to take a look at the table below:

Along the top are the categories of trackers as defined by Disconnect’s tracking protection list categories.

Along the left side are comparisons of the improvements made to our tracking prevention feature broken down into Basic, Balanced, and Strict.

The letter “S” in a cell denotes that storage access is blocked.

The letter “B” in a cell denotes that both storage access and resource loads (i.e. network requests) are blocked.

A “-“ in a cell denotes that no block will be applied to either storage access or resource loads.

The “Same-Org Mitigation” refers to the first mitigation that we introduced in our previous blog post and recapped above.

The “Org Engagement Mitigation” refers to the second mitigation based on site engagement that we introduced earlier in this post.

[table][tr][td][/td] [td]Advertising[/td] [td]Analytics[/td] [td]Content[/td] [td]Cryptomining[/td] [td]Fingerprinting[/td] [td]Social[/td] [td]Other[/td] [td]Same Org Mitigation[/td] [td]Org Engagement Mitigation[/td] [/tr] [tr][td]Basic[/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [/tr] [tr][td]Microsoft Edge 78[/td] [td]–[/td] [td]–[/td] [td]–[/td] [td]B[/td] [td]B[/td] [td]–[/td] [td]–[/td] [td]Enabled[/td] [td]Not impl.[/td] [/tr] [tr][td]Microsoft Edge 79[/td] [td]–[/td] [td]–[/td] [td]–[/td] [td]B[/td] [td]B[/td] [td]–[/td] [td]–[/td] [td]Enabled[/td] [td]N/A[/td] [/tr] [tr][td]Balanced[/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [/tr] [tr][td]Microsoft Edge 78[/td] [td]S[/td] [td]–[/td] [td]–[/td] [td]B[/td] [td]B[/td] [td]S[/td] [td]–[/td] [td]Enabled[/td] [td]Not impl.[/td] [/tr] [tr][td]Microsoft Edge 79[/td] [td]S[/td] [td]–[/td] [td]S[/td] [td]B[/td] [td]B[/td] [td]S[/td] [td]S[/td] [td]Enabled[/td] [td]Enabled1[/td] [/tr] [tr][td]Strict 2[/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [td][/td] [/tr] [tr][td]Microsoft Edge 78[/td] [td]B[/td] [td]B[/td] [td]–[/td] [td]B[/td] [td]B[/td] [td]B[/td] [td]B[/td] [td]Enabled[/td] [td]Not impl.[/td] [/tr] [tr][td]Microsoft Edge 79[/td] [td]B[/td] [td]B[/td] [td]S[/td] [td]B[/td] [td]B[/td] [td]B[/td] [td]B[/td] [td]Enabled[/td] [td]Disabled[/td] [/tr] [/table]

Does not apply to Cryptomining or Fingerprinting categories.

Strict mode blocks more resource loads than Balanced. This can result in Strict mode appearing to block less tracking requests than Balanced since the trackers making the requests are never even loaded to begin with.

With our recent updates in Microsoft Edge 79, we have seen, on average, 25% more trackers blocked in Balanced mode. Close monitoring of user feedback and engagement time also showed no signs of negative compatibility impact, suggesting that the org engagement mitigation is effective at minimizing breakage on sites that users actively engage with. While this does mean that top sites have the org engagement mitigation applied more often, we believe this is an acceptable tradeoff versus compatibility, especially as more top sites are starting to give users mechanisms to transparently view, control, and delete their data.

As with all our features, we’ll continue to monitor telemetry and user feedback channels to learn more and continually improve tracking prevention in future releases. We are also exploring additional compatibility mitigations such as the Storage Access API, which we intend to experiment with in a future version of Microsoft Edge.

InPrivate Changes

In our previous blog post, we mentioned that users browsing in InPrivate will automatically get Strict mode protections. By listening to the feedback our users provided, we found that this led to unexpected behavior (such as causing sites that worked in a normal browsing window to fail to load InPrivate) and broke some important use cases. That’s why in Microsoft Edge 79, your current tracking prevention settings will be carried over to InPrivate sessions.

We are currently experimenting in our Canary and Dev channels with a switch at the bottom of our settings panel (which you can reach by navigating to edge://settings/privacy) that will allow you to re-enable Strict mode protections InPrivate by default:

Turn On or Off Always Use Strict Tracking Prevention when Browsing InPrivate in Microsoft Edge Chromium

See blocked trackers

We’ve also made it easier for you to view the trackers that Microsoft Edge has blocked for you. Navigate to edge://settings/privacy/blockedTrackers to test out this new experience today!

Send us feedback

We’d love to hear your thoughts on our next iteration of tracking prevention. If something looks broken, or if you have feedback to share on these changes, we’d love to hear from you. Please send us feedback using the “smiley face” in the top right corner of the browser.

Send feedback at any time with the Send a Smile button in Microsoft Edge

As always, thanks for being a part of this journey towards a more private web!

– Scott Low, Senior Program Manager
– Brandon Maslen, Senior Software Engineer
Click to expand...

Source: Improving Tracking Prevention in Microsoft Edge - Microsoft Edge Blog

How to Turn On or Off Tracking Prevention in Microsoft Edge Chromium

Turn On or Off Always Use Strict Tracking Prevention when Browsing InPrivate in Microsoft Edge Chromium

How to Add and Remove Tracking Prevention Exceptions for Sites in Microsoft Edge Chromium

Tweet

— Twitter API (@user) View on Twitter
Click to expand...

Brink · Dec 10, 2021

Tracking prevention now available in Microsoft Edge preview builds

Today, we’re releasing an experimental preview of tracking prevention for Microsoft Edge. We 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 77.0.203.0 (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 77.0.203.0 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.

Tracking prevention can be enabled via edge://flags

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.

Classification

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

URL: https://a.subdomain.of.a.known.tracker.test/some/path

Tested hostnames:

subdomain.of.a.known.tracker.test

a.known.tracker.test

known.tracker.test

tracker.test

test

If any of those hostnames represents a known tracker, we proceed with evaluating enforcement actions intended to prevent the user from being tracked.
Enforcement

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.

Mitigations

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.

Tracker categorization

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.

Organizations

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.

Debugging tools

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
Click to expand...

Source: Introducing tracking prevention, now available in Microsoft Edge preview builds - Microsoft Edge Blog

Tweet

— Twitter API (@User) View on Twiiter

Brink · Dec 10, 2021

Tracking prevention now available in Microsoft Edge preview builds

Today, we’re releasing an experimental preview of tracking prevention for Microsoft Edge. We 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 77.0.203.0 (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 77.0.203.0 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.

Tracking prevention can be enabled via edge://flags

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.

Classification

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

URL: https://a.subdomain.of.a.known.tracker.test/some/path

Tested hostnames:

subdomain.of.a.known.tracker.test

a.known.tracker.test

known.tracker.test

tracker.test

test

If any of those hostnames represents a known tracker, we proceed with evaluating enforcement actions intended to prevent the user from being tracked.
Enforcement

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.

Mitigations

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.

Tracker categorization

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.

Organizations

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.

Debugging tools

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
Click to expand...

Source: Introducing tracking prevention, now available in Microsoft Edge preview builds - Microsoft Edge Blog

Tweet

— Twitter API (@user) View on Twiiter
Click to expand...

Windows 10: Microsoft is testing some changes to Edge's Tracking Prevention settings, and the browser...

Microsoft is testing some changes to Edge's Tracking Prevention settings, and the browser...

Microsoft is testing some changes to Edge's Tracking Prevention settings, and the browser...

Microsoft is testing some changes to Edge's Tracking Prevention settings, and the browser...

Microsoft is testing some changes to Edge's Tracking Prevention settings, and the browser... - Similar Threads - Microsoft testing changes

Microsoft is testing an Automatic HTTPS Mode in the Edge web browser

Prevent deleting browser history and download history in Microsoft Edge

Microsoft is testing a startup booster for its Edge browser

How to add a site to Tracking Prevention Exceptions list in Edge browser

Microsoft Improving Tracking Prevention in Microsoft Edge

Microsoft adds new options for tracking prevention in the latest Edge Canary build, in...

How to enable & configure Tracking Prevention feature in Microsoft Edge

Tracking prevention now available in Microsoft Edge preview builds

Test Report on Edge Browser