Closed Bug 1598969 Opened 5 years ago Closed 2 years ago

Block trackers using CNAME Cloaking (1st-party tracker blocking)

Categories

(Core :: Privacy: Anti-Tracking, enhancement, P3)

enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: yoasif, Unassigned)

References

(Depends on 3 open bugs, Blocks 1 open bug)

Details

(Keywords: parity-safari)

Attachments

(1 file)

As per articles like https://medium.com/nextdns/cname-cloaking-the-dangerous-disguise-of-third-party-trackers-195205dc522a and https://github.com/uBlockOrigin/uBlock-issues/issues/780

It'd be nice if Firefox would automatically block first party trackers using CNAME cloaking to hide the tracking entity.

Priority: -- → P3
Assignee: nobody → ehsan
Attached image Sneak peak

Screenshot from my local build which has a fix for this bug applied.

When visiting walmart.com, a tracking pixel is loaded from https://omniture-ssl.walmart.com, which is a CNAME alias to walmart.com.ssl.d1.sc.omtrdc.net. ETP restrictions are applied to this tracking pixel (notice in the screenshot: no Cookie header, trimmed Referer header, devtools showing resource as coming from a tracker.)

This is landing in Brave soon: https://brave.com/privacy-updates-6/

Keywords: parity-safari

FYI: https://thehackernews.com/2021/02/online-trackers-increasingly-switching.html

Wouldn't incorrect partyness have consequences e.g. for heuristics, despite ETP's dFPI (in strict mode)

The bug assignee didn't login in Bugzilla in the last 7 months.
:timhuang, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: ehsan.akhgari → nobody
Flags: needinfo?(tihuang)
Flags: needinfo?(tihuang)

So we have moved slowly on this for a variety of reasons. The upside is that this provided us with a clear view of the second-order effects of blocking CNAMEs. One of the reactions we see is trackers asking for A records in the first-party's namespace, rather than CNAMES. This is an escalation by trackers that seems unwise to escalate against- I don't think it is wise to maintain an IP address blocklist or to try to identify proxying schemes by trackers that may crop up if we do.

We also see that CNAMEs can be a useful tool for solving legitimate use cases that are broken by third-party cookie deprecation, e.g. a third-party login provider. However, because of open issues around CNAMEs, potentially legitimate users hesitate to employ CNAMEs, in fear that their use case will be disabled by antitracking teams. This is also less than good.

The good news is that TCP is now enabled for all users by default. This greatly reduces the efficacy of tracking across first parties. And we can still add domains that are CNAMEd to trackers to our blocklist independently, which will require more effort but is an avenue available that maintains current abstractions over the network layer by antitracking.

Given all of this, we are making the tough call to WONTFIX this. However, if the conditions change such that CNAME tracking becomes critical despite TCP, we will change course.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: