This is an idea suggested by @stefanpopoveniuc as a possible way to keep some bounce related use cases working.
If you consider a redirect chain A->B->C, bounce tracking mitigations will delete site B's storage unless the user has interacted with it. This is to avoid B being able to store first party cookies with tracking information related to C. (And often C is the same as A.)
We could offer an opt-in mechanism for B to receive storage partitioned on site C. This would prevent B from tracking users across different bounce destination sites. B would have different storage for A->B->C than it would for A->B->A or A->B->D.
The opt-in mechanism would work based on a response header. For example, something like PartitionStorageOnDest: c.example. B would get partitioned cookies and other storage for its load. If it then navigates to its declared destination c.example, then that storage would be protected from bounce tracking deletion. If it navigates anywhere else then its storage is deleted as normal using the bounce tracking mitigation algorithm.
A secondary opt-in mechanism could be an additional attribute on a link tag; e.g. <a href='b.example' partition-on-dest='c.example'>.
Use cases like the email workflow in #28 could use the link tag attribute to partition appropriately.
Use cases like link shorteners in #27 would need a more complicated approach to opting-in. Because their links can be followed from anywhere they cannot rely on the link tag attribute. Instead, the server would reply to the initial link with a redirect back to its own domain with the header added. It would then redirect from there to the final site. (This would be a performance penalty, but it's purely opt-in and the site can make the determination if the partitioned storage is worth the cost.)
Edit: This glosses over some details in the redirect dance to add the header in the interests of providing an overview of the approach.
This is an idea suggested by @stefanpopoveniuc as a possible way to keep some bounce related use cases working.
If you consider a redirect chain A->B->C, bounce tracking mitigations will delete site B's storage unless the user has interacted with it. This is to avoid B being able to store first party cookies with tracking information related to C. (And often C is the same as A.)
We could offer an opt-in mechanism for B to receive storage partitioned on site C. This would prevent B from tracking users across different bounce destination sites. B would have different storage for A->B->C than it would for A->B->A or A->B->D.
The opt-in mechanism would work based on a response header. For example, something like
PartitionStorageOnDest: c.example. B would get partitioned cookies and other storage for its load. If it then navigates to its declared destinationc.example, then that storage would be protected from bounce tracking deletion. If it navigates anywhere else then its storage is deleted as normal using the bounce tracking mitigation algorithm.A secondary opt-in mechanism could be an additional attribute on a link tag; e.g.
<a href='b.example' partition-on-dest='c.example'>.Use cases like the email workflow in #28 could use the link tag attribute to partition appropriately.
Use cases like link shorteners in #27 would need a more complicated approach to opting-in. Because their links can be followed from anywhere they cannot rely on the link tag attribute. Instead, the server would reply to the initial link with a redirect back to its own domain with the header added. It would then redirect from there to the final site. (This would be a performance penalty, but it's purely opt-in and the site can make the determination if the partitioned storage is worth the cost.)
Edit: This glosses over some details in the redirect dance to add the header in the interests of providing an overview of the approach.