Also consider partitioned storage or cookie access as stateful for BTP
Categories
(Core :: Privacy: Anti-Tracking, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox129 | --- | fixed |
People
(Reporter: manuel, Assigned: pbz)
References
(Blocks 2 open bugs)
Details
Attachments
(5 files)
All data within the partitionKey needs to be cleared for detected bounce trackers. Make sure that iframes can't keep their state.
Rough sketch what should be protected from:
- a.com
- -> bounce.com
- iframe=c.com (Total cookie partitions this with partitionKey=bounce.com)
- -> d.com
- -> bounce.com
- PURGE bounce.com
- Then a.com
- -> bounce.com
- iframe=c.com (STILL HAS THE partitioned COOKIE FROM BEFORE due to same partitionKey=bounce.com)
- -> d.com
- -> bounce.com
Comment hidden (obsolete) |
Reporter | ||
Updated•7 months ago
|
Assignee | ||
Comment 2•7 months ago
|
||
It's not only about purging behavior, we'd also have to update the storage access checks to not skip partitioned storage access:
Here /toolkit/components/antitracking/bouncetrackingprotection/BounceTrackingStorageObserver.cpp#158 and here /toolkit/components/antitracking/bouncetrackingprotection/BounceTrackingStorageObserver.cpp#92
You also need to check if we skip partitioned access somewhere else in the call chain.
Assignee | ||
Comment 3•6 months ago
|
||
Here is how we currently purge:
BTP calls into nsIClearDataService DeleteDataFromBaseDomain
: https://searchfox.org/mozilla-central/rev/729361e481cf63c8d2b5617a6ff589f53e302520/toolkit/components/antitracking/bouncetrackingprotection/BounceTrackingProtection.cpp#674
For a given base domain example.com
this will clear cookies, cache and storage for:
example.com
and any subdomain- All partitioned state of
example.com
in third-party contexts. - All partitioned state under
example.com
, e.g.example.org
embedded underexample.com
. - All state owned by
example.com
across alluserContextId
(containers) andprivateBrowsingId
(normal and private browsing).
This behavior is almost what we want. We just don't want to clear (4) to keep containers and normal and private browsing seperated. E.g. a bounce in private browsing shouldn't delete data in normal browsing.
To support this we could extend DeleteDataFromBaseDomain
with an OriginAttributesPattern
argument.
See Bug 1842067 for changing the purging logic for BTP.
Assignee | ||
Updated•6 months ago
|
Assignee | ||
Updated•5 months ago
|
Assignee | ||
Comment 4•5 months ago
•
|
||
I've successfully removed the places where we skip looking at partitioned storage access, but I'm running into an algorithm / spec issue here:
Say we have a redirect: S1 -> T1 -> S2 where T1 embeds a cross-site iframe which sets a partitioned cookie. The BounceTrackingState after the extended navigation would look like this:
initialHost: S1
finalHost: S2
bounceHosts: [ T1 ]
storageAccessHosts: [ T2 ]
Note that T1 is not in storageAccessHosts
because e.g. cookie write is recorded for the site host that set the cookie, not the top level. See https://privacycg.github.io/nav-tracking-mitigations/#ref-for-bounce-tracking-record-storage-access-set
If we then run the "record stateful bounces for bounce tracking" algorithm we will not classify T1 because it's not in the storageAccessHosts
set as per https://privacycg.github.io/nav-tracking-mitigations/#ref-for-iteration-continue%E2%91%A5
T2 will also not be classified because it didn't bounce (we also only look at top level context here).
Ben, are we looking at a spec issue here? Assuming that partitioned iframes can be used for bounce tracking too this seems like a gap in the protection. Maybe we should record a storage access for the top context always for BTP.
Comment 5•5 months ago
|
||
Reading this such that T2 is the iframe embedded by T1...
I think this is a spec issue. And I think there may even be issues for general subresources rather than just iframes...
Consider the same case, but instead of embedding T2, T1 loads an image that sets cookies from T2.
Then, per https://privacycg.github.io/nav-tracking-mitigations/#process-a-fetch-storage-access-for-bounce-tracking-mitigations, we add the site's host from the origin of the request to the storage access set.
So it seems there are a couple of points of confusion in the spec here. First, subresource tracking .
Then if we resolve that and put T1 in the storage access, then we need to make sure that when we (clear cookies)[https://privacycg.github.io/nav-tracking-mitigations/#clear-cookies-for-host], we get the partitioned ones too. Which per the spec we shouldn't (and I disagree with that strongly).
So our second point of confusion is handling partitioned cookies.
I'll file 1 or 2 issues on the spec and link them here.
Assignee | ||
Comment 6•5 months ago
|
||
Thanks Ben!! I'll experiment with this in our implementation. I don't we currently handle the subresource case correctly either.
Comment 7•5 months ago
|
||
Maybe we should record a storage access for the top context always for BTP.
Yes, I'll recommend that in the issue.
Comment 8•5 months ago
|
||
Assignee | ||
Comment 9•5 months ago
|
||
Assignee | ||
Comment 10•5 months ago
|
||
Assignee | ||
Comment 11•5 months ago
|
||
Assignee | ||
Comment 12•5 months ago
|
||
Assignee | ||
Comment 13•5 months ago
|
||
Comment 14•5 months ago
|
||
Comment 15•5 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/339613a7c2ca
https://hg.mozilla.org/mozilla-central/rev/d25acd08947d
https://hg.mozilla.org/mozilla-central/rev/b33450d47d38
https://hg.mozilla.org/mozilla-central/rev/d4fc7f26b5f4
https://hg.mozilla.org/mozilla-central/rev/0a8d986a9315
Description
•