Dynamic data-driven Tracking Protection not possible with DNR

[chrmod]

Content Blocking is a de-facto standard in privacy protection, but it has its flaws. There are more advanced techniques that both benefit the user's privacy and overcomes limitations in content blocking.

In this issue I'm going to describe the Ghostery Anti-Tracking technology. I will refer to it as a "Dynamic approach" in contrast to a "Declarative approach" of content blockers based on block lists.

Description

Let us take the following 3rd party URL as an example:https://example.com/?utm_source=example+source&utm_medium=example+medium&utm_audience=example+audience+1&uid=3128741294715
The potentially sensitive part of the query string is 3128741294715. As example.com is not identified as a well known tracker, the request - instead of being blocked - still gets sent. However, the private part will get replaced with other value. The tracker assumes everything is fine, as the request is successful, but it fails to track the user as unique identifiers were removed from the request.

Read more in the whitepaper presenting original Cliqz Anti Tracking technology https://0x65.dev/static/docs/studies/TrackingTheTrackers.pdf

How it is possible

• Blocking webRequest - to modify parts of requests (path, headers, POST content)
• Persistent background page to keep bloom filters in memory (bloom filters are necessary due to memory considerations)
• CryptoWorker for secure and private communication with the backend (the communication with the backend is end-to-end encrypted to prevent leakage of sensitive data)

None of those will be available in Manifest V3.

Benefits of Dynamic approach

• Ability to prevent Zero-day privacy attacks - which is not feasible by traditional content blockers that rely on community lists to build consensus on the reputation of a domain. The Dynamic approach blocks unique identifiers not domains (new domains are used for tracking all the time and existing domain can turn rouge at any time).
• Reduce the breakage - as the requests are not blocked, trackers may not notice that the unique identifier is missing.
• Increased coverage: community have to manually curated, while the Dynamic approach will over time learn to block new trackers (without manual intervention)

Options to work under Manifest V3

As tracking protection is typically focused on 3rd party requests, the modification of requests could happen in a content script that monkey-patches fetch. This requires copying the bloom filter to each content script (which are a few megabytes of ArrayBuffer), or to send messages to the service worker with the assumption that it is alive.

Flaws:

• Performance degradation (copying of data, service worker initialisation, postMessage)
• Increased latency (postMessage, initialisation time)

Anti-tracking is another use case that showcases how inherently user hostile Manifest V3 is.