With latest /e/ update I got a popup summarizing what apps on my phone attempted to resolve DNSs related to tracking services. The only app that falls under this condition on my phone is DuckDuckGo Browser, that a bit surprised me. When I opened a list of trackers that /e/ blocked, I found some well known trackers, that are listed as known by DDG.
Now here is a question: Why DDG Browser tries to access trackers that /e/ blocked? I suspect this is because DDG first resolve DNS in order to understand what to block, and /e/ catches it before that? If it’s so, then any browser will always have a long list of trackers at /e/ tracker blocker app, even if they don’t have intention to establish connection to them…
hard to answer without debugging that browsers blocking behaviour in Android - how early it can cancel/block a DNS request in its own networking stack before reaching the system (if it got its own networking stack at all to do so - in ddg case I think rather not as it uses the webview. So I think your assumption at (1) can be fitting).
In the naive case the filter lists between ddg and AP-TP aren’t congruent, and AP sees the DNS queries of ddg that weren’t on its own filter lists.
In what you describe, even what ddg would block itself (1) gets counted towards an attempt by AP-TP, because ddg will always do the dns lookup? - Not unlikely.
To really settle this, no way around debugging ddg browser.
(In-browser javascript snippet blocking goes beyond what AP-TP (or ddgs own tracking blocker) can so. So even if the tracking domain is resolved, the .js doing the collection never loads, no requests happens - no signal for the tracker - but still counted by AP-TP as attempt averted, because all it cares about is dns)
