2030052 - Update Anti Tracking Database to Ingest Real Time Tracking Data

Status: RESOLVED FIXED

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

Description

[James Han]

The anti-tracking database (protections.sqlite, backed by TrackingDBService) today is only written to when a WindowGlobalParent is destroyed: i.e. when a page unloads or a tab closes (dom/ipc/WindowGlobalParent.cpp). Long-lived tabs (Gmail, YouTube, Discord, etc.) accumulate blocking events in ContentBlockingLog for hours or days and never flush them, so anything reading the database: the Protection Dashboard, milestone messaging, and the upcoming Android Global Protections Dashboard (Bug 2016140, Bug 2030080), sees stale data.

We need to ingest tracking events from browser content in real time instead of waiting for page destruction.
Proposed approach:

• Add a periodic flush from ContentBlockingLog to TrackingDBService while the window is alive (timer-based, interval configurable via pref).
• Also flush on visibility change (tab hidden / pagehide) so dashboards are fresh when the user switches away.
• Make ContentBlockingLog::ReportLog() incremental — track a "last reported" cursor per LogEntry so repeated flushes don't double-count. Today Stringify() serializes the entire mLog.
• Preserve existing exclusions: private browsing, non-top-level documents, and the browser.contentblocking.database.enabled pref.

Comment 1

[James Han]

Attachment: Bug 2030052 - Flush live ContentBlockingLogs on anti-tracking DB query r?timhuang

TrackingDBService previously only wrote to protections.sqlite when a
WindowGlobalParent was destroyed, so long-lived top-level tabs never
contributed their blocking events until the tab closed. Consumers like the
Protection Dashboard and milestone messaging saw stale data.

This change adds a flush-on-query barrier: before each read, TrackingDBService
forces every live top-level WindowGlobalParent to flush its in-memory log
to the database, then awaits the pending DeferredTask writes.

To keep repeated flushes from double-counting against the daily aggregated
counters, ContentBlockingLog::Stringify() gains a delta mode that emits
only entries added since the last MarkAsReported() call, and ReportLog()
skips the IPC round-trip when the delta is empty.

Gated behind browser.contentblocking.database.flushOnQuery.enabled (default
true). Preserves the existing private-browsing, out-of-process, and
top-level-content gates by routing both the teardown and query-time flushes
through a shared WindowGlobalParent::MaybeReportContentBlockingLog helper.

Comment 2

[James Han]

Attachment: Bug 2030052 - Part 2: Browser test for anti-tracking DB flush-on-query r?timhuang

Opens a tab with a blocked tracker and, without closing the tab, queries
TrackingDBService.getEventsByDateRange. The event count must be nonzero —
verifying the query-time flush barrier routed the live ContentBlockingLog
through to the database.

Also covers the idempotency path: a second query returns the same count
(per-origin Stringify cursor prevents re-emitting entries), and closing the
tab afterwards triggers the teardown flush without increasing the count.

A separate sub-test flips browser.contentblocking.database.flushOnQuery.enabled
off and verifies the live events do NOT appear — the pref gates the barrier.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/14716cb80c5f
https://hg.mozilla.org/integration/autoland/rev/8711c8c81f6d
Flush live ContentBlockingLogs on anti-tracking DB query r=emz
https://github.com/mozilla-firefox/firefox/commit/45a87d2e0b70
https://hg.mozilla.org/integration/autoland/rev/8f8f367b43fc
Part 2: Browser test for anti-tracking DB flush-on-query r=emz

Comment 4

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/8711c8c81f6d
https://hg.mozilla.org/mozilla-central/rev/8f8f367b43fc