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:

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

1. It is low enough to ensure successful interactions with a site that a user has not previously had a history of engagement with.
2. 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

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

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

1. Does not apply to Cryptomining or Fingerprinting categories.
2. 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:

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.

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

The post Improving Tracking Prevention in Microsoft Edge appeared first on Windows Blog.

Source: Improving Tracking Prevention in Microsoft Edge