Cross-Domain Cookie Access Solution for a.com and b.com

[anushshukla]

Problem Statement

With Google Chrome's impending restriction on third-party cookies, the cross-domain cookie access between websites like a.com and b.com, both relying on third-party scripts from c.com, becomes a challenge. These scripts create cookies on a.com that need to be accessible on b.com.

Proposed Solution

To address this issue, we propose implementing the following steps:

1. Generate RWS JSON: a.com and b.com website owners need to visit https://rws-json-generator.ue.r.appspot.com to generate the necessary RWS JSON.

2. Add .well-known Folder: If not already present, a.com and b.com should add a ".well-known" folder in their respective web root directories.

3. Add JSON File: Within the ".well-known" folder, a.com and b.com should add a JSON file named "related-website-set.json" containing the generated RWS JSON.

4. Host Cross-Site Cookie URL: Both a.com and b.com need to host a URL that provides the cross-site cookie in the response, following the guidelines specified in the official documentation.

5. Implement c.com Changes: The javascript files hosted on c.com need to implement requestStorageAccessFor, and upon the end user's consent, a network request is made to the related websites for cookie fetching in its response.

Desired Outcome

Our goal is to establish a solution that minimizes the effort required by a.com and b.com to achieve the desired cross-domain cookie access. This approach is particularly beneficial in scenarios where there are numerous domains involved in the related website set (RWS).

Seeking Input

We are seeking input on the best possible way to implement this solution effectively while ensuring minimal disruption to the existing workflows of a.com and b.com. Any insights or alternative approaches are welcome to optimize this process further.

[cfredric]

Hi @anushshukla,

Related Website Sets is a viable solution for this use case if (and only if) a.com, b.com, and c.com are all in the same set.

In other words - if c.com's scripts are used this way by many different domains or sets of domains (e.g. {x.com, y.com}, {p.com, q.com}, {f.com, g.com}), then Related Website Sets will not help here, since c.com may be in at most one set. (This scenario is related to WICG/first-party-sets#94, which we haven't found a solution for yet.)

But if c.com's scripts are only used by a.com and b.com, and all three domains are controlled by the same entity, then RWS will help. You can follow the instructions on https://developers.google.com/privacy-sandbox/3pcd/related-website-sets-integration for how to use RWS. You can look at an example demo at https://related-website-sets.glitch.me/.

[anushshukla]

To clarify c.com is not part of the RWS which a.com and b.com are.

The question remains!

Can b.com access first-party cookies created by c.om on a.com directly on the browser using requestStorageAccessFor("https://a.com") and without making server-side changes other than RWS prerequisites?

Please be informed that https://related-website-sets.glitch.me has been explored thoroughly.

[cfredric]

To clarify c.com is not part of the RWS which a.com and b.com are.

Thanks for that clarification. This does indeed look like a case that would benefit from a solution to WICG/first-party-sets#94.

Can b.com access first-party cookies created by c.om on a.com directly

No, b.com can never directly access cookies that belong to a different site. This is an important security property of the web, called the Same Origin Policy.

But I don't think you need b.com to have direct access to c.com's cookies in this case; it would be sufficient if c.com could access its cookies and then postMessage them to b.com if it chooses to.

c.com can make this work today by using the Storage Access API and requesting permission to access its unpartitioned data in both embedded contexts (i.e. embedded in a.com, and embedded in b.com). However, this involves a user prompt, because this access to unpartitioned data is the same capability that allows pervasive user tracking today.

I presume that your use case does not need to give c.com access to fully unpartitioned data, though; it would probably be sufficient to use a partition that corresponds just to {a.com, b.com} embedded contexts (and therefore would not allow c.com to do pervasive tracking). This is exactly what WICG/first-party-sets#94 is about, but unfortunately there is no easy solution there, for various reasons. It's not clear whether this is something we can support, but the discussion is still open in that issue.

[anushshukla]

Appreciate the prompt response.

WICG/first-party-sets#94 is also what we're looking for.

We shall closely follow its thread while brainstorming for ideas for handling such use cases.

Thanks again!