Apis to find if 3p cookies are enabled or not?

[jagadeeshaby]

As of now i'm relying on hasStorageAccess() i presume this is not exactly equal to this application has 3p cookie access or not correct? For Example after enabling 3p cookies myself , hasStorageAccess returns false and i need to invoke RSA to proceed which i don't want to happen. So is there a better alternative exists today?

For now as a workaround i'm using samesite:none, set cookie and get cookie method within the iframe to quickly validate whether the embedded iframe has access to cookie or not and then proceed with RSA and showing the banner, it seems to work well.

For me use case is, i expect our enterprise customers to use chrome policies to allow cookies, for which i want to skip RSA flow and directly take them to application.

[cfredric]

after enabling 3p cookies myself , hasStorageAccess returns false and i need to invoke RSA to proceed

I assume the main frame's site and the iframe's site are non-opaque, and are served over HTTPS, correct?

If so, that's interesting - this is not the intended behavior in Chrome (and is not what the spec requires), and we have a test that shows that Chrome follows the intended behavior.

Can you reproduce this bug? If so, can you share any info on what you're doing (and what version of Chrome you are using)? Is your browser using any enterprise policies (E.g. CookiesBlockedForUrls) or extensions? (Check chrome://policy and chrome://extensions.) If so, please disable them and let me know if you can still reproduce this.

[jagadeeshaby]

Unfortunately in the latest builds( 116) i can't really test this anymore as i'm not getting any browser permissions popups at all.

[cfredric]

i'm not getting any browser permissions popups at all.

Is that because Chrome is reusing the permission decisions you've already made while testing, instead of asking you again? If so, you can revoke those decisions through the UI on chrome://settings/content/storageAccess. That will let you continue testing from a "fresh" state.

[cfredric]

It also just occurred to me: in #6 (comment) you said you're testing in Chrome 116. This feature was not finished in time for Chrome 116; please use Chrome 117 for your testing (as noted in the testing instructions).

The behavior of hasStorageAccess is one of the things that was not finished in Chrome 116, so I suspect this is why you're not getting the intended behavior.

[jagadeeshaby]

If so, you can revoke those decisions through the UI on chrome://settings/content/storageAccess. That will let you continue testing from a "fresh" state.

this doesn't seem to work, I followed the exact instructions as detailed here https://github.com/cfredric/chrome-storage-access-api#testing-instructions

Under chrome://settings/content/storageAccess

I see Sites can ask to use info they’ve saved about you and disabled Customized behaviors section and no other options provided.

i'm able to consistently get the RSA banner showing up in edge from fresh state by cleaning the site permissions but couldn't do the same with Chrome canary 117 Version 117.0.5894.0 (Official Build) canary (arm64)

[cfredric]

I see Sites can ask to use info they’ve saved about you and disabled Customized behaviors section and no other options provided.

Can you please show what you are seeing? This is what I see in Chrome 117.0.5938.35 (Official Build) beta (64-bit):

If there's nothing listed under the You blocked these sites from using info they've saved about you or You allowed these sites to use info they've saved about you sections, that means you have not denied/granted any permission requests.

[jagadeeshaby]

Thank you that's helpful.

here is what i found:

• first time i forced to invoke RSA and i did see the explicit popup and i granted access
• and i see entries within the chrome://settings/content/storageAccess

Next time i deleted the permission and tried again , popup wouldn't show up. seems like this time chrome is automatically granting access and doesn't require a user interaction and it doesn't respect the chrome://settings/content/storageAccess settings ( like cleaning it off or turning off permissions fully). Could you clarify on this?

Confusion for me here is , i wouldn't want to forcefully show request access banner in all cases, meaning i would want this to show up where customers doesn't have access to the 3rd party cookies. The way i determine the same is by doing a quick cookie test by running a small Javascript within an embedded context, which first set a cookie with samesite:none and then try to access the same.

• if the result of cookie test is true then yes embedded frame can access cookie and simply open the login popup and proceed
• if not, then see if user has granted access before and follow RSA flow. ( where i show banner depending on the hasStorageAccess response)

So what i see here is , this new RSA chrome feature is specifically targeting request storage access grants and my cookie test would always results in true for some reasons and my site works as well without even RSA.

[jagadeeshaby]

Update:

I was able block 3p cookies by using privacy settings, but now RSA flow would show up but isn't granting access to any 3p cookies on the embedded domain.

i clearly see entries within chrome://settings/content/storageAccess saying my embedded site allows storage access but the embedded requests are failing with "this cookie is blocked due to user preferences"

[cfredric]

Can you please share what version of Chrome you are testing? You can find this on chrome://version.

Next time i deleted the permission and tried again , popup wouldn't show up. seems like this time chrome is automatically granting access and doesn't require a user interaction and it doesn't respect the chrome://settings/content/storageAccess settings ( like cleaning it off or turning off permissions fully). Could you clarify on this?

I cannot reproduce this behavior in 117.0.5938.35 (Official Build) beta (64-bit). If I block third-party cookies, then use requestStorageAccess to grant permission (via a prompt), then revoke permission in settings, then call requestStorageAccess again, I see a prompt both times requestStorageAccess is called (even without refreshing the page in between). Please let me know what version of Chrome you are using, and exactly what steps you are doing, so that I can try to reproduce your scenario.

So what i see here is , this new RSA chrome feature is specifically targeting request storage access grants and my cookie test would always results in true for some reasons and my site works as well without even RSA.

If your site is working even without calling document.requestStorageAccess(), that suggests one of a few possibilities:

• Third-party cookies are not actually blocked.
  • Check that the "default behavior" on chrome://settings/cookies is "Block third-party cookies".
  • Check on chrome://settings/cookies under "Customized behaviors" that you have not allow-listed your site.
  • Check on chrome://policy that your enterprise is not using CookiesAllowedForUrls to allow-list your site.
• The scenario is not a cross-site scenario.
  • Check that the top-level site (the URL that is shown in the omnibox) is a different site than the iframe that you are embedding. If they're the same site, then third-party cookie blocking does not apply.
  • See here for the definition of "site". Note in particular that "site" is not the same thing as "hostname": different hostnames can be same-site, if they share the same eTLD+1 and scheme.

I was able block 3p cookies by using privacy settings, but now RSA flow would show up but isn't granting access to any 3p cookies on the embedded domain.

I'm also not able to reproduce this. Can you provide clear, specific reproduction steps and let me know what version of Chrome you are using? Additionally, are you using any extensions?

[jagadeeshaby]

Can you please share what version of Chrome you are testing? You can find this on chrome://version.

117.0.5894.0 (Official Build) canary (arm64)

Will provide the exact steps

[cfredric]

117.0.5894.0 (Official Build) canary (arm64)

Aha, that is just barely too old to have the correct behavior, and I think it explains some of what you're seeing. Specifically, that build doesn't include this commit, which changed document.hasStorageAccess().

All of the Chrome release branches (besides Stable, and Android's canary DCHECK build) are shipping a newer version than that. Can you please upgrade Chrome (visit chrome://settings/help) to 117.0.5938.0 or newer, and try your site again? 117.0.5938.0 is the oldest version of Chrome that I expect to work as intended for the Storage Access API.

[cfredric]

I also just realized that you provided that version in a previous comment earlier today, and I didn't see it. Sorry about that!

[jagadeeshaby]

Tested the same on 117.0.5938.35 (Official Build) beta (arm64)

• i see that permission reset is taking an effect
• but i still don't get access to 3p cookies

in addition now i see below error as well

login:59 Uncaught DOMException: Failed to read the 'sessionStorage' property from 'Window': Access is denied for this document.

[jagadeeshaby]

Uncaught DOMException: Failed to read the 'sessionStorage' property from 'Window': Access is denied

this goes away as soon as i enable Experimental third-party storage partitioning flag , will this be enabled by default when cookies phase out happens?

In terms of steps

• First access the main site which embeds the sass app
• SAss app will load the rsa page which first checks for hasStorage access and then show button to grant access
• after the explicit access grant - rsa page navigates to same domain page within the iframe
• Same domain page then checks if user has logged in or not and opens a login popup on the same domain
• popup login sets the cookies with same site none once users enters creds
• embedded same domain page keep refreshing until it finds the cookies set by the popup

in our case cookies are available but not accessible inside embedded context

Screenshare.-.2023-08-31.3_13_35.PM.mp4

[cfredric]

this goes away as soon as i enable Experimental third-party storage partitioning flag , will this be enabled by default when cookies phase out happens?

I'm not involved in that project, so I don't know about their plans other than what they've already announced publicly. This message indicates that it will be enabled by default next month.

Thanks for the description of your use case and the screenshare, those are helpful. I think whatever's going on here is subtle, since it's related to navigation, as opposed to subresource fetches or script access. Some followup questions:

• You said: "after the explicit access grant - rsa page navigates to same domain page within the iframe". I understand that this navigation is what you expect to include the auth cookies. So:
  • It looks like the navigation is not just same-domain, it's same-origin (not cross-origin). Can you confirm?
  • Are there any cross-origin redirects during that navigation?
  • Which document initiates that navigation? (I.e. is it initiated by a script running in the embedded frame itself, or in the top-level page?)

Navigations of the frame that got storage access (as opposed to subresource requests from the frame that got storage access) can only use the third-party cookies under certain circumstances:

• They have to be same-origin navigations with no cross-origin redirects; and
• they have to be initiated by the same frame that is being navigated. (I.e. if the top-level document executes iframe.src = <some url>;, that won't work.)

FWIW, we do have some tests here (and more here) that illustrate (and verify) the expected behaviors in Chrome. Maybe you can take a look at those to see what your code does differently?

[jagadeeshaby]

It looks like the navigation is not just same-domain, it's same-origin (not cross-origin). Can you confirm?

yes it's the same origin

Are there any cross-origin redirects during that navigation?

No

Which document initiates that navigation? (I.e. is it initiated by a script running in the embedded frame itself, or in the top-level page?)

Embedded iframe instructs top level page to load the desired same origin page, so in my case it's the top page. this is important as in few cases customer may not even want to load any pages rather they show their own custom implementation.

they have to be initiated by the same frame that is being navigated. (I.e. if the top-level document executes iframe.src = ;, that won't work.)

this does not seem practical. In my case -> top level domain loads the desired embedded resource , and because of all the cookie issues now it has a pre-requisite to load /request-storage-access page (rsa page) hosted on the same origin of embedded resource and then embedded rsa page does all the request access and once after the grant it instructs the top level domain who opened rsa page about the grant and then top level domain decides to load the actual same origin desired page.

[cfredric]

this does not seem practical.

Unfortunately this is necessary for security reasons. If the top-level document were allowed to navigate a frame that has storage access to a page of its choosing, and the navigation included the frame's unpartitioned cookies, that would be a vector for a cross-site request forgery attack. Please see here for lots of discussion on possible attacks using the Storage Access API.

Your application should be able to work around this restriction by changing the communication flow slightly:

• Embedded iframe tells top-level it has been granted access.
• [NEW] Top-level asks frame to navigate to a particular URL (the CCP).
• [NEW] Embedded iframe validates the URL (checks that it's safe to visit), then navigates itself to it.

If that would work for you, please give it a try, and let me know if you run into more problems.

[jagadeeshaby]

Yup, trying the same already! will keep you posted

[cfredric]

Hi @jagadeeshaby, any update? If I don't hear from you in a few days I'll assume that we found the root of the issue, and I'll consider this issue closed.

[jagadeeshaby]

Updating :)

[jagadeeshaby]

So i went ahead and updated the flow, it seem to work fine. but now i have problem testing end to end again by clearing the state.

Below video shows that there is nothing show up on embedded content settings even then the access is granted and i'm able to load the app.

Screenshare.-.2023-09-06.10_24_00.AM.mp4

Same time , on localhost i clearly see new entries and browser popup for permissions. i double checked cookie settings and allowed websites everything looks fine.

[jagadeeshaby]

The new flow is

• Outer context (customer website) loads the RSA embedded page and RSA page asks permissions and navigates to destination app which is hosted on the same domain.

i see that the RSA flow is working as intended just that not able to test the browser popup as it doesn't show up. are there any implicit grants based on usage?

[cfredric]

are there any implicit grants based on usage?

No, the only implicit grants supported by Chrome are via First-Party Sets (but I can see that you're not using the command-line flag that would make those relevant right now).

i see that the RSA flow is working as intended just that not able to test the browser popup as it doesn't show up.

I suspect this is because your page relies on the third-party cookies during navigation, rather than during the embedded document's lifetime. I'd guess the pageinfo bubble only shows up when the embedded page indicates a need for the storage-access permission after the page has been received by the browser; not before.

You should still be able to reset the state by clearing the permissions on chrome://settings/content/storageAccess. Can you check there?

cc @xchrdw, FYI.

[jagadeeshaby]

You should still be able to reset the state by clearing the permissions on chrome://settings/content/storageAccess. Can you check there?

Not really ,as i mentioned earlier i don't see any entries here.

I suspect this is because your page relies on the third-party cookies during navigation, rather than during the embedded document's lifetime. I'd guess the page info bubble only shows up when the embedded page indicates a need for the storage-access permission after the page has been received by the browser; not before.

Not sure i follow, do you believe this is a bug or this is how it's expected to work?

Great that it works, i worry that this being a bug.

[jagadeeshaby]

Okay i found the root cause!!

Seems like chrome beta doesn't list the org managed policies but in turn applies those. So in my case the domain i was trying to use is allowed to use cookies by the policy and hence cookie access was granted implicitly and i tried the other URL which isn't included in the policy which works as expected.

Feel free to close the Issue. thanks for all the input. Hope to test this out chrome GA version soon

[Sauski]

in my case the domain i was trying to use is allowed to use cookies by the policy

Do you mean that the CookiesAllowedForUrls policy was applying?

If so, this should be reflected as an entry on the chrome://settings/content/siteData page. If it's not, that's certainly a bug.

[jagadeeshaby]

Do you mean that the CookiesAllowedForUrls policy was applying?

i believe so, i do see these entries on chrome but on chrome beta i only see that your browser is managed and doesn't list the allow listed URLs

If so, this should be reflected as an entry on the chrome://settings/content/siteData page. If it's not, that's certainly a bug.

I do see those URLs under /siteData.

i was expecting this to appear under chrome://settings/content/storageAccess as well but it's not.

[cfredric]

Circling back to this after some vacation - in summary of what we discovered in this issue:

• Be sure to use an up-to-date version of Chrome M117 or later.
• Navigations don't necessarily carry cross-site cookies even if the frame being navigated can access those cookies.
• Make sure that third-party cookies are blocked in settings.
• Make sure that enterprise policies and/or user settings aren't unexpectedly allowing third-party cookie access.

Seems like Chrome was behaving as intended and now you are unblocked. Closing.