wanderview
commented
2 years ago Thanks for the suggestion!
I think our concern with partitioning is how to handle non-tracking use cases. Many authentication flows require stateful bounces. With deletion we can handle these by waiting to see if the user interacts with the site (like logging in) and then choose not to delete if that validation happens.
Its unclear how to handle this with partitioning. For partitioning we would have to immediately partition if the browser visited a site the user has never seen before. Then we would have to somehow promote the partition to first-party state if the user interacted. We would also have to promote the partition to first-party state if it turned out there was no client-side redirect and it was not a bounce at all, but just a normal page visit.
Promoting partitions to first-party state is rather complicated and something we have been trying to avoid where possible.
Is there a significant advantage to partitioning over deletion that might counterbalance the significant added complexity?
RussStringham
Another option that you do not mention would be to use partitioned storage rather than deleting storage. Storage for tracker.example would be keyed to site1.example and only available when navigating from site1.example to tracker.example.
I'm not sure if this prevents any unintended breakages of authentication flows or similar, so I don't know that it is needed, but it is another alternative.
This approach can be abused without further mitigation if we get redirects from site1.example to tracker1.example to tracker2.example and then back. If site2.example also redirects to tracker1.example to tracker2.example, then the storage for tracker2 would be partitioned for tracker1, and available to be returned to site2. Mitigating this would require partitioning all storage in the chain of redirects to site1, or deleting storage when the source site (tracker1) is also identified as a bounce tracker.