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

Should bounce tracking mitigations honor Storage Access API #65

Open
wanderview opened this issue Oct 9, 2023 · 0 comments
Open

Should bounce tracking mitigations honor Storage Access API #65

wanderview opened this issue Oct 9, 2023 · 0 comments
Labels
bounce-tracking Issues related to bounce tracking mitigations.

Comments

@wanderview
Copy link
Collaborator

(The following was discussed briefly at TPAC 2023. Filing this to document the question and for further discussion.)

In chromium we have implemented bounce tracking mitigations so that it only takes action on tracking sites that do not have access to 3P cookies. We originaly envisioned that as pertaining to the global "block 3P cookie" setting, but it was later enhanced to support UX elements that users could use to unbreak sites by re-enabling cookies just for that site.

In chromium cookie access is computed as a combination of 1P+3P where wildcards are permitted. So you can have all 3P cookies under a specific 1P permitted, a particular 3P permitted under any 1P, or a particular 3P only permitted under a specific 1P.

For bounce tracking mitigations we had to fit the redirect flow into this 1P+3P setup. To do this we treat the redirection source and destination sites as the 1P site and the bounced site as the 3P site. (You can think of the source site as writing the 3P cookie via a bounce and the destination as reading the 3P cookies via the bounce.) So an A->B->A redirection would check for an A+B 3P cookie rule. An A->B->C would consult both the A+B and C+B cookie rules.

One unintended consequence of this work is that bounce tracking mitigations in chromium will honor 3P cookie grants from storage access API (SAA). If an B iframe embedded under A gets cookie access via requestStorageAccess(), then if A redirects to B and back, B can access first-party cookies without triggering bounce tracking mitigations.

This seems reasonable and appropriate given that bounces are semantically very similar to normal 3P cookie access. There were no immediate concerns raised about this at TPAC, but we also had very limited time.

@bvandersloot-mozilla @Trikolon @johnwilander do you have any thoughts or concerns about allowing bounce access to cookies when SAA has granted a related cookie permission?

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

1 participant