Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Partitioned State rather than Deleting #25

Open
RussStringham opened this issue Sep 7, 2022 · 2 comments
Open

Use Partitioned State rather than Deleting #25

RussStringham opened this issue Sep 7, 2022 · 2 comments
Labels
bounce-tracking Issues related to bounce tracking mitigations.

Comments

@RussStringham
Copy link

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.

@wanderview
Copy link
Collaborator

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
Copy link
Author

I would think there are some cases where partitioning would provide a better experience than deletion, but I am not aware of any and obviously you would not want the added complexity simply to cover a theoretical use case. Perhaps someone else reviewing this thread can provide one? I mainly created this issue for completeness.

@wanderview wanderview transferred this issue from wanderview/bounce-tracking-mitigations Oct 24, 2022
@wanderview wanderview added the bounce-tracking Issues related to bounce tracking mitigations. label Oct 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bounce-tracking Issues related to bounce tracking mitigations.
Projects
None yet
Development

No branches or pull requests

2 participants