@trikolon raised an interesting vulnerability when thinking about partitioned iframes that generalizes to multiple types
Consider a bounce tracker bouncer.tracker.com that also controls a domain bounce-tracker.example.com. Instead of maintaining state directly on bouncer.tracker.com, they load a sub-resource from bounce-tracker.example.com which uses URL decoration to encode the context of the bounce and uses the cookies of bounce-tracker.example.com to maintain a user-id.
I think the best way to fix this is to delete CHIPS cookies (#75) and make the cookie write algorithm use the request's client's top-level origin rather than the request's origin directly.
@trikolon raised an interesting vulnerability when thinking about partitioned iframes that generalizes to multiple types
Consider a bounce tracker
bouncer.tracker.com
that also controls a domainbounce-tracker.example.com
. Instead of maintaining state directly onbouncer.tracker.com
, they load a sub-resource frombounce-tracker.example.com
which uses URL decoration to encode the context of the bounce and uses the cookies ofbounce-tracker.example.com
to maintain a user-id.Looking at the algorithms now, the (bounce set)[https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-record-bounce-set] would not contain
bounce-tracker.example.com
, as it is never navigated or redirected through so we don't add it in process response received for bounce tracking. Because of that, when we later record stateful bounces for bounce tracking, we don't considerbounce-tracker.example.com
. But, worse yet, we no longer havebouncer.tracker.com
to be purged either because it is never added to a storage access set . So nothing ends up purged.I think the best way to fix this is to delete CHIPS cookies (#75) and make the cookie write algorithm use the request's client's top-level origin rather than the request's origin directly.