2056585 - BTP: ClearBySiteHost does not strip firstPartyDomain before state-global lookup, causing under-clear under FPI

Status: NEW

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

Description

[Emma Zühlcke [:emz]]

BounceTrackingStateGlobal objects and their persisted rows are always keyed by OriginAttributes with mFirstPartyDomain truncated (BounceTrackingState.cpp:219, and BounceTrackingProtectionStorage::GetStateGlobal/GetOrCreateStateGlobal at lines 50 and 73 strip it). However, BounceTrackingProtectionStorage::ClearBySiteHost (toolkit/components/antitracking/bouncetrackingprotection/BounceTrackingProtectionStorage.cpp) does NOT go through the truncating accessor:

• line 99 calls mStateGlobal.Get(*aOriginAttributes) directly with the raw, un-truncated OriginAttributes;
• the on-disk delete at line 120 (DeleteDBEntries) binds the un-truncated originAttributeSuffix.

When First-Party Isolation (privacy.firstparty.isolate=true) populates firstPartyDomain, this lookup and delete miss the truncated-key entry, so an explicit clear-by-host (ClearDataService deleteByPrincipal, i.e. "Forget about this site") leaves BTP state behind.

Steps / failure scenario:

1. Set privacy.firstparty.isolate=true (non-default). Cookies are in a restricted behavior, so BTP is active.
2. BTP classifies tracker.example; its state global and DB row are stored under an OriginAttributes key with mFirstPartyDomain="".
3. The user invokes "Forget about this site" for tracker.example, driving BounceTrackingProtectionStateCleaner.deleteByPrincipal with a principal whose OriginAttributes has firstPartyDomain populated by FPI.
4. ClearBySiteHost hashes the FPD-populated OA (line 99), misses the truncated-key entry, and the DB delete (line 120) binds the FPD-populated suffix so no row matches.

Expected: deleteByPrincipal removes the in-memory bounce-tracker/user-activation entries and the persisted row for tracker.example.
Actual: both survive the user's explicit deletion; stale classification/activation data persists and re-imports on restart.

Related to bug 1949016 (RESOLVED/FIXED, 'With first party isolation enabled BTP purges sites, not honoring user activation signals'), whose fix stripped firstPartyDomain on the user-activation RECORD path. That fix did not normalize this Storage clear-by-host lookup, which does not route through GetStateGlobal(). This is a distinct, still-unaddressed FPI code path.

Note: the sibling ClearBySiteHostAndOriginAttributesPattern is unaffected because it uses OriginAttributesPattern.Matches(), where an unspecified firstPartyDomain acts as a wildcard.

FPI is a non-default/unsupported config, so severity ~S4. Found during an audit of the BTP implementation.