Open Bug 1894040 Opened 2 months ago Updated 21 days ago

Ability to init / uninit BounceTrackingProtection during runtime

Categories

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

enhancement

Tracking

()

People

(Reporter: manuel, Assigned: manuel)

References

(Blocks 2 open bugs)

Details

Follow up on Bug 1892494. See review comment on D208870:

We can consider adding an optimization (maybe in a follow-up bug?): Currently the feature will be initialized even if both normal and private browsing cookie behaviors are set to ACCEPT or REJECT. In this case we could disable the entire feature rather than only not handling out BounceTrackingState objects. The biggest perf impact would most likely be that we no longer have to import our state global maps from storage on startup.
We can additionally check for cookie behavior on startup and if its an unsupported mode for both normal and private browsing we can bail out early and not do init. The problem with this approach is that we can't react to pref changes during runtime. The mechanism currently only checks if it should init on startup and doesn't react to pref changes; there is no "uninit". If a user switches to e.g. cookie behavior 5 during runtime the mechanism wouldn't be active until the next browser restart.

We could also investigate not blocking startup loading the bounce tracking protection database in memory, but collect bounce tracking protection info already on startup and then merging the info with the database (not sure how the current architecture looks like concretely).

Wouldn't we risk state conflicts here? e.g. if something is classified as a bounce tracker but then later we load the DB and it has user activation. How do we prevent purging it?
I think a better solution to the issue described in my comment would be to teach the feature how to init / uninit during runtime + add an additional check at startup to see if the pref environment makes sense to enable in (cookie behavior).

See Also: → 1896935
Assignee: nobody → manuel

This is a requirement for ETP strict. Users may switch to ETP strict or away from it which means we need to init /uninit the feature.

Summary: Initialize BounceTrackingProtection on demand → Ability to init / uninit BounceTrackingProtection during runtime
Severity: S4 → N/A
Priority: P3 → P2
You need to log in before you can comment on or make changes to this bug.