Trackers can be “disguised” and embedded into first party domains, invisible to the user, which allows them to escape blocking
I will see if there is anything the developers have to say, but from my understanding, there is no way for the iodé blocker app to do anything to protect against these trackers, if they are truly only “seen” by your phone as “approved web addresses”.
Effectively in that case, the traffic the iodé blocker “sees” is again only to the approved address, but possibly at the app’s cloud / server instance they mangle / inject trackers and then deliver back to you via their “approved first party domain” again.
Now if these trackers are embedded at a subdomain level or have further identifiers in the FQDN, then those could be identified (and blocked, likely by default) by the iodé blocker. But if it truly delivered to your device using the same FQDN as valid traffic then there is no way to differentiate it (and thus block it).
It so happens that AdGuard maintains a blocklist targeting known cloaked trackers in first party domains. One or more of these lists can be added to mobile tracker-blocking apps, Pi-hole, etc.
Maybe. We’d have to do some comparison searches within the two lists, I guess. I think AdGuard’s cloaked CNAME lists might not be included in the main AdGuard lists, though. Research is needed.
With this first-party mode, you can now use the Google tag to collect the data using your own first-party server. With this, your server collects the data directly using your domain and then sends it to Google’s products - Google Analytics (GA4), Google Ads (GAds), and more.
This makes it an almost perfect method to send first-party data signals to Google Ads, that helps you maximize your ad campaign performance.
With first-party mode on, the server-side cookie set by your domain tracks the user journey despite the ad blockers, browser tracking protections (third-party cookies deprecation), and data privacy regulations. This gives a complete online journey of the user without any gaps.
)
)