Should bounce tracking mitigations honor Storage Access API

[wanderview]

(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?