Store a log of tracker purges in Bounce Tracking Protection storage
Categories
(Core :: Privacy: Anti-Tracking, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox135 | --- | fixed |
People
(Reporter: emz, Assigned: emz)
References
(Blocks 2 open bugs)
Details
Attachments
(5 files)
This allows for better troubleshooting when we expose it via nsIBounceTrackingProtection. It also allows us to log a warning to the website console the next time a previously purged site is visited (Bug 1844561).
The data we're adding needs to be cleared properly via the existing cleaner in ClearDataService.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 1•1 year ago
|
||
Some implementation notes:
Extend BounceTrackingMapEntry to hold OriginAttributes so we can get the OA later to populate the purge log. While we’re at it we can use this entry type in a bunch of places where we currently only use array of string etc.
Add purged host list to state global
Can’t we directly in the purge logic after the callback append to this list? We should only do it on a successful purge.
Extend the database with an additional table for purge history. The columns should be:
- OA suffix
- Site host
- Purge time stamp
How do we ensure that this table doesn’t get over full? We could on startup do a cleanup job which removes entries older than 30 days.
Could also keep this log entirely in memory? Would give us limited insight into breakage potentially. PBM won’t have persistence anyway. Always on users will have limited traceability into purges.
The clear data service needs full integration with this table so it’s properly cleared when the user clears e.g. history.
On PBM exit the in memory state of the purge log needs to be dropped.
| Assignee | ||
Comment 2•1 year ago
|
||
I'm going a bit back and forth about whether data persistence is actually necessarily. It does add a lot of complexity for a troubleshooting / debug only feature. If a user notices within the same session that site data is missing they can look up the purge log. I'll go with this version for now. If we find it worthwhile to have disk persistence in the future we can easily iterate on the current patches.
| Assignee | ||
Comment 3•1 year ago
|
||
In the next patch we will use BounceTrackingMapEntry to store purged sites in storage.
| Assignee | ||
Comment 4•1 year ago
|
||
| Assignee | ||
Comment 5•1 year ago
|
||
| Assignee | ||
Comment 6•1 year ago
|
||
| Assignee | ||
Comment 7•1 year ago
|
||
Comment 9•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/8d981a08962b
https://hg.mozilla.org/mozilla-central/rev/178d8013d13e
https://hg.mozilla.org/mozilla-central/rev/54322c4cfda1
https://hg.mozilla.org/mozilla-central/rev/4173afd4efab
https://hg.mozilla.org/mozilla-central/rev/6779ac4a1374
Description
•