Cookie blocked when accessing application site deployed in different domain from Parent site in different domain

[srilakshmi-devarapalli-by]

We have a first party site (https://company.net/) and it has an embedded application site (https://app.com/cognos) both are owned by us but deployed on different domains.

When we launch the application site first time as an iframe url, with response header we add a sso cookie to the browser.

Issue1 - If we set Block third-party cookies from chrome://settings/cookies, we are unable to register the application cookies with parent site.
Issue2 - If we use partitioned tag, we are able to register cookie with parent site. But we have a use case where we will open the application site urls https://app.com/cognos directly in new tab. In this case the SSO cookies are not shared and authentication failed.

Could you please let us know how to fix this scenario?

Another thing, with new chrome browser we are seeing one warning message for our application cookies as - Cookie is blocked because it path (for example /cognos/bi/v1) was not same for or match with its superdirectory of request URL's path. How to fix this?

[srilakshmi-devarapalli-by]

Hi Team,

Could you please update on this?

[wanderview]

Since you own both of these domains, its possible related website sets (RWS) and storage access API (SAA) might be a solution. See references to these here:

https://developers.google.com/privacy-sandbox/3pcd

[srilakshmi-devarapalli-by]

Regarding related website sets , can we add just the domains for promary and releated parties. For example,

1. We will have a Primary/ Top site url in mutiple regions as regionname1.primarydomain.com , regionname2.primarydomain.com
2. we have app deployment per customer url as 1. servernameofCus1.appdomain.com 2. servernameodCust2.appdomain.com

in this case , shall we define RWS as

{
"contact": "",
"primary": "https://primaryDomain.com",
"associatedSites": [
"https://appDomain.com"
],
"rationaleBySite": {
"https://appDomain.com": "Application portal"
}
}

Another thing, after updating in RWS also, we still need to use Storage Access API for allowing cookies?

One more thing on testing, When i test our application with just the Flag enabled Test Third Party Cookie Phaseout everything is working. But when i test with Chrome/setting/Block third party cookies it is not allowing to add cookies. What is the right way of testing? Why the app is able to set the cookie with out any issue with Flag enabled Test Third Party Cookie Phaseout ?

[wanderview]

Storage access API is necessary even with RWS, but the RWS entry should make it auto-grant without any user prompt.

Regarding the cookie phaseout flag and the older "block 3P cookies" setting in chrome, see this documentation:

https://developers.google.com/privacy-sandbox/3pcd/prepare/test-for-breakage#flags_and_settings

Essentially, block 3P cookies is a more strict control which excludes a number of the newer mechanisms that allow 3P cookies.

I will have to defer to my colleagues on the RWS question.

[cfredric]

in this case , shall we define RWS as ...

That looks reasonable to me (assuming you supply a real contact email address), from the RWS perspective. There are still some technical requirements that will be checked when you open a pull request on the RWS repository, though.

Another thing, after updating in RWS also, we still need to use Storage Access API for allowing cookies?

Yes, either document.requestStorageAccess() or document.requestStorageAccessFor(). Note that neither of those APIs will show a permission prompt for RWS usage. Please see this troubleshooting section for some more info.

[srilakshmi-devarapalli-by]

Hi Team,

Thanks for the details.

I want to understand more on RWS,

Since this is public REPO, all our domains are visible to everyone right? what are the security measures around this? is there a way to hide these for other users?

Also is this the go forward for all organizations, who wants to share cookies to their internal subdomains launching as top-level site?

[cfredric]

Since this is public REPO, all our domains are visible to everyone right?

Yes, if you want all Chrome clients to be aware of your RWS, then it has to be public information. Re: security, RWS is designed to uphold existing security boundaries on the web (e.g. the Same Origin Policy). If you find a way that RWS regresses security, please let us know.

is there a way to hide these for other users?

If you only need to make your RWS available to your organization, you can use a Chrome Enterprise Policy to do so, specifically RelatedWebsiteSetsOverrides. This allows your enterprise to avoid exposing the domains within its intranet.

Also is this the go forward for all organizations, who wants to share cookies to their internal subdomains launching as top-level site?

This is one option, which may or may not work for your use case. You may also use the Storage Access API (without RWS), or try adopting other technologies like CHIPS, Private State Tokens, Shared Storage, Fenced Frames, Federated Credentials Management API, etc. Please see https://privacysandbox.com/intl/en_us/open-web/#proposals-for-the-web for more information.

share cookies to their internal subdomains

Note that it's possible to share cookies between subdomains of a given site already, without adopting any of the Privacy Sandbox proposals. You can use the Domain attribute to accomplish this.

[srilakshmi-devarapalli-by]

Hi Chris,

We are already using domain attribute and able to share the cookie to subdomains till now.

But in this case with third party cookie phaseout, since our primary site is in different domain and child iframes are in different domain (app domain), first we are unable to register cookies.

Post adding partitioned tag( with response header of cookie register), we are able to register cookies. But these cookies are not shared when we access child iframe url's (app domain url's) in new window tab / popups.

our cookie is more of SSO token for single sign on when users launch our app domain url's in new tab.

[cfredric]

our cookie is more of SSO token for single sign on when users launch our app domain url's in new tab.

Got it, thanks for that detail. In this case, yes, I believe something like RWS or FedCM is your easiest option.

What you are looking for is a way to (unobtrusively) convey the user's identity as they navigate from one site to another, which unfortunately is exactly what pervasive tracking tries to do. This is why the options available to you are limited: RWS only allows a limited number of top-level sites; FedCM and SAA require asking the user for permission.

[srilakshmi-devarapalli-by]

Hi Fedric,

I have tried using the storage access API and got popup to allow. Post allowing, we tried launching one of the embedded site requests (app domain) which should register the unpartitioned cookie with parent site, but it is unable to register. could you please help us how to fix this?

[cfredric]

I unfortunately don't have enough information in this thread to know what isn't working. I recommend opening Chrome DevTools and checking the Network tab to see why those unpartitioned cookies are being blocked. (If you are seeing and accepting the Storage Access API prompt, and the cookies are still blocked, then the cookies must be blocked by something else.)

[srilakshmi-devarapalli-by]

Hi Chris,

From Network tab, it is showing attempting to set cookie blocked because of user preferences - same message as before storage access API

[cfredric]

Can you confirm that when you launch the embedded site, the embedded site also calls document.requestStorageAccess() in the iframe, before the Set-Cookie header is received? Cross-site iframes do not get cookie access until they call document.requestStorageAccess(), even after permission has already been granted. See one of the key notes here. I think this is the most likely explanation for what you're seeing.

If the iframe is already calling requestStorageAccess() before it tries to set cookies, then one of the following must be happening:

• You have a setting that explicitly blocks cookies for that site. Check on chrome://settings/cookies to find out.
• Your Chrome profile is managed by an enterprise, and the enterprise blocks cookies from being set by that site. Check chrome://settings/cookies or chrome://policy to find out.

[srilakshmi-devarapalli-by]

Hi Chris,

I have included the code to call document.requestStorageAccess() in the child iframe , but still we are unable to set the cookie or access the cookie.

We dont have any settings or policy under chrome://settings/cookies , except third party cookie clocked.

[cfredric]

Can you provide a reproduction case so I can debug this myself?

[srilakshmi-devarapalli-by]

Hi Chris,

Here is our case.

1. We have main company portal url as - azureedge.net.
2. Within this portal, we launch our application url - appdomain.com as an iframe source
3. Iframe has a links to launch application pages (user requests)
4. When user clicks on any particular link, while processing the http request/loading the page, we will add a session cookie as part of http response.
5. This session cookie we are unable to set to browser when third party cookies disabled.
6. We need this cookie set to the browser without partitioned tag. Why because we have window.open in next tab with appdomain.com url and this cookie needs to be shared for new tab for authentication.

[cfredric]

Thanks for the details, but you don't mention calling document.requestStorageAccess() anywhere. In order for me to debug this for you, I need to know exactly what's going on in your code. I can't see what's going wrong from just a description/diagram; I need to be able to run and debug your application myself.

Alternatively, you can check out https://storage-access-api-demo.glitch.me/ and try to see what those pages do differently from your app.

[srilakshmi-devarapalli-by]

I have called document.requestStorageAccess() when first time Iframe launching with user interaction to allow.

After that called again, when user launching an application page frame.

[srilakshmi-devarapalli-by]

Hi Chris,

Let us know if we can have a meeting tomorrow to debug the issues.

[cfredric]

Unfortunately not. I'd recommend looking at https://storage-access-api-demo.glitch.me/ or https://rws-member-1.glitch.me/request-storage-access.html to see how document.requestStorageAccess() is used.

[srilakshmi-devarapalli-by]

Hi Chris,

We have already looked at above links, but still cookie is not sending through the request.

Also, privacycg/CHIPS#82 is the issue what we are facing exactly.

Either Partitioned cookies need to be shared to Window.opener or StorageAccess API need to send unpartitioned cookies as request headers.

Seems StorageAccess API is not working as expected with request , response headers.

[srilakshmi-devarapalli-by]

Hi @cfredric

Could you please clarify on the below issues related to Storage access API's?

1. When we implemented the SAA, the very first time we launch a site, we are seeing below error message and prompt to allow cookies is not coming.

OVR:1 requestStorageAccess: Request denied because the embedded site has never been interacted with as a top-level context

We have clicked on the window open link which opens the embedded site in new tab since there is no cookie share it will fail. Then we have refreshed the site again, the prompt came to allow cookies or not.

How the browser tracks whether user interacted or not? is this expected behavior with SAA? If yes, this will break user experience and how do we make the prompt to allow cookies always comes.

2. What if user by mistake rejected the prompt? Is there a way to prompt again?
3. Once user accepted prompt how long the access is given, I see it is 30 days, after 30 days does it prompt again?
4. The allow cookies prompt is coming only when user click on button. Is there a way to make this prompt during page load? without user interaction?

[cfredric]

Hey @srilakshmi-devarapalli-by,

I think most of the info you're looking for is explained on https://github.com/cfredric/chrome-storage-access-api?tab=readme-ov-file#chrome-specific-behavior. Briefly:

• How the browser tracks whether user interacted or not?

  • It uses "User activation" as defined in the HTML spec, here.

• Is this expected behavior with SAA?

  • In Chrome, yes.

• How do we make the prompt to allow cookies always comes

  • Ensure that the user has visited your site directly, before your site is embedded and asks for storage access. This maximizes the chance that the user will understand why they should accept the prompt, and minimizes the chance that the user will consider it to be spam/abuse. (Chrome blocks prompts from sites that the user has never interacted with, because it's highly likely that the user has never interacted with spammy/abusive sites.)

• What if user by mistake rejected the prompt? Is there a way to prompt again?

  • This depends on which browser the user is using. In Chrome, the user can easily change their mind and grant permission via the PageInfo bubble (at the left of the omnibox) or by managing the permissions on chrome://settings/content/storageAccess.

• Once user accepted prompt how long the access is given, I see it is 30 days, after 30 days does it prompt again?

  • Yes, the access lasts for (at least) 30 days.
  • The permission lifetime can be "renewed" (reset to 30 days) by certain user interactions. (Reference)

• The allow cookies prompt is coming only when user click on button. Is there a way to make this prompt during page load? without user interaction?

  • No, there is no way to avoid that requirement. (Reference)

[srilakshmi-devarapalli-by]

Hi @cfredric

Regarding

The allow cookies prompt is coming only when user click on button. Is there a way to make this prompt during page load? without user interaction?

No, there is no way to avoid that requirement

Today many public sites when we just lunch itself, we are getting prompt to accept cookies or not.

Why we need again user action here (to click on some button to get prompt)? This breaks the regular user flows as we need to add the call to storage access Api for all IFrames.

[cfredric]

Today many public sites when we just lunch itself, we are getting prompt to accept cookies or not.

Why we need again user action here (to click on some button to get prompt)?

Are you asking why the prompt requires a user gesture first? That is a standard requirement for most permission prompts.

If you're asking why you need to show both a permission prompt and a cookie consent banner -- I'm not a lawyer, but my understanding is that some cookie consent banners satisfy legal requirements placed on websites in some jurisdictions. The browser's permission prompt is not related to that.

Why we need again user action here (to click on some button to get prompt)? This breaks the regular user flows as we need to add the call to storage access Api for all IFrames.

To be clear:

• Yes, all iframes that want access to cross-site cookies must call the Storage Access API. This is a security protection against CSRF attacks. See here for more info.
• Not every iframe needs to get a user gesture before calling the Storage Access API. If the permission has already been granted, then no user gesture is required.

[samdutton]

No further replies in nearly two months so I'll close this, but feel free to reopen if necessary.