search

GoogleChrome / related-website-sets

Apache License 2.0
404 stars 499 forks source link

RWS PR# 418 Not Working! #424

Open vn31699 opened 3 months ago

vn31699 commented 3 months ago

Related to the successfully merged PR 'RWS entry for John Deere #418', we are still seeing the 3rd party calls to domain .johndeere.com from first party .deere.com applications being blocked with the below Chrome (126+ version) flags. Can you please help understand why this is not working, is there anything missing and how to test so that calls between our RWS domains not blocked with the below flags ?

third-party-cookie-deprecation-trial -> enabled

tracking-protection-3pcd -> enabled

tpcd-metadata-grants -> disabled

flags#tpcd-heuristics-grants-> disabled

sjledoux commented 3 months ago

Even though entry #418 has been merged, it takes some time for the RWS list to be consumed by the Chrome browser and shipped to clients. I would expect this problem to resolve in the near future as the list migrates into the browser, but if you continue to experience this problem after 2 weeks please reach out again on this thread and we can address this in more detail.

vn31699 commented 3 months ago

Thank you so much for the clarification, will monitor and get back.

vn31699 commented 3 months ago

Hello, I see RWS sets for our domains got update in my Chrome client however, the calls from .deere.com to .johndeere.com still being blocked with the below flags. Wondering with the RWS domains in place now and for testing, whether we need to use below flags to simulate 3rd cookies blocking issue and should see calls going through ?? Or, what is the correct way to test this ?? Appreciate any help in this regard. Thanks.

third-party-cookie-deprecation-trial -> enabled

tracking-protection-3pcd -> enabled

tpcd-metadata-grants -> disabled

flags#tpcd-heuristics-grants-> disabled

cfredric commented 3 months ago

Hi,

In the future, we recommend testing locally with the instructions here before you submit your PR, so that you don't run into this kind of issue.

Re: those Chrome flags, yes, RWS works when those flags are enabled. Chrome uses RWS to automatically grant storage access via document.requestStorageAccess(), so you should see those promises resolve (and then be able to access your cookies in cross-site contexts). Alternatively, you could use document.requestStorageAccessFor(), as well.

vn31699 commented 3 months ago

Hi, Will do, and thanks for the suggestion. As mentioned in the instructions, we tested with just one flag, 'test-third-party-cookie-phaseout,' instead of the four flags mentioned above. It works as expected, and calls between our domains are not being blocked, including the app within the iframe. Based on these results, we are unable to conclude that testing with just one flag, 'test-third-party-cookie-phaseout,' would suffice for RWS allowing cookies between our domains when fully enforced, or it might block since it is not working with all the four flags mentioned above. Can you please advise?

cfredric commented 3 months ago

Hm, the issue may be in your settings. If you set your preference to "block third-party cookies" on chrome://settings/cookies, then enable the #tracking-protection-3pcd flag, this will cause Chrome to block all third-party cookies; i.e. it disallows mechanisms like RWS from selectively allowing cookies in some scenarios.

To change this, you have two options:

  1. Go to chrome://settings/cookies, and set the choice to allow third-party cookies. Then enable #tracking-protection-3pcd, and test as usual.
  2. Enable #tracking-protection-3pcd, then go to chrome://settings/trackingProtection. Find the toggle labeled "Block all third-party cookies", and make sure it is toggled off. Now test as usual.

Please give one of those options a try and let me know how it goes.

vn31699 commented 3 months ago

Hi, For #1, it is working as expected with single flag '#tracking-protection-3pcd' enabled and chrome://settings/cookies set to allow third-party cookies (not blocking 3rd party cookies between our domains) For #2, it is NOT working with single flag '#tracking-protection-3pcd' enabled and chrome://settings/cookies set to block third-party cookies (blocking 3rd party cookies between our domains). Please let me know your comments.

cfredric commented 3 months ago

For https://github.com/GoogleChrome/related-website-sets/pull/1, it is working as expected with single flag '#tracking-protection-3pcd' enabled and chrome://settings/cookies set to allow third-party cookies (not blocking 3rd party cookies between our domains)

First, I assume you mean "with single flag '#tracking-protection-3pcd' disabled"? If the flag is enabled, then chrome://settings/cookies doesn't exist anymore (it redirects immediately to chrome://settings/trackingProtection).

Assuming you meant "disabled" -- your sites are probably working because you're not blocking third-party cookies at all in this configuration, actually. What I was suggesting was to set your preferences this way, and then enable the #tracking-protection-3pcd flag to block some (but not all) third-party cookies, and then do your testing. Can you try that?

For https://github.com/GoogleChrome/related-website-sets/pull/2, it is NOT working with single flag '#tracking-protection-3pcd' enabled and chrome://settings/cookies set to block third-party cookies (blocking 3rd party cookies between our domains). Please let me know your comments.

I can't reproduce this. When I enable/disable the flags the way you've described, the https://deere.com and https://johndeere.com domains still appear in the list on chrome://system, which means Chrome is aware of that RWS and will use it when resolving calls to document.requestStorageAccess() and document.requestStorageAccessFor().

Can you confirm that you're using one of those APIs (as described here)? If you are, and it still isn't working properly for you, then a bug report with instructions for a Chromium engineer to reproduce your bug would be helpful.

vn31699 commented 3 months ago

HI, Thanks so much for the quick response.Apologies for the confusion on #1. I misread your earlier statement, 'Then enable #tracking-protection-3pcd, and test as usual.' I actually enabled it instead of disabling it. I have now retested by disabling the '#tracking-protection-3pcd' flag and selecting the 'Block third-party cookies' option. Now, I see calls being blocked between .deere.com and johndeere.com despite both being listed in chrome://system.

Regarding your second question, we are not currently calling any APIs such as document.requestStorageAccess() and document.requestStorageAccessFor() in any of our impacted applications. To be honest, we initially presumed that just by adding our domains to RWS, it would allow the first-party application hosted on .deere.com to make API calls to the IDP on .johndeere.com after initial authentication. We also assumed it would allow the iframe app, embedded within the same domain as the first-party app, to further send authorization calls using session cookies from the IDP on johndeere.com. Does RWS require application code changes to call either document.requestStorageAccess() or document.requestStorageAccessFor() ?

cfredric commented 3 months ago

Aha, that explains the behavior you're seeing, and now the behaviors with and without the #tracking-protection-3pcd flag sound consistent to me.

Does RWS require application code changes to call either document.requestStorageAccess() or document.requestStorageAccessFor() ?

Yes, exactly. Depending on your needs, you can arrange for the iframe to call document.requestStorageAccess(), and/or for the top-level document to call document.requestStorageAccessFor("https://mysite.com"). There are a few things to be aware of:

The reason that RWS requires these application changes (and why one of these APIs must be invoked in every frame/document that wants cookie access), is to improve security. Requiring an explicit opt-in like this makes it much harder for a malicious site to attack your site via CSRF.

vn31699 commented 3 months ago

Appreciate further clarification and details on this. Will review this internally with our teams, implement SAA, test and provide you the feedback. Is my understand correct that with our RWS domains added in the chrome://system/, making SSA calls will NOT prompt for end-user consent ?

cfredric commented 3 months ago

Is my understand correct that with our RWS domains added in the chrome://system/, making SSA calls will NOT prompt for end-user consent ?

Yes, that's correct (in Chrome). (Reference)

vn31699 commented 2 months ago

Hi, We have implemented requestStorageAccess changes in an embedded cross-origin iframe app using the domain .deere.com and target app on .johndeere.com. Using the following flags and RWS sites available in the chrome://system/:

third-party-cookie-deprecation-trial -> Enabled tracking-protection-3pcd -> Enabled tpcd-metadata-grants -> Disabled tpcd-heuristics-grants -> Disabled test-third-party-cookie-phaseout -> Enabled

and the RWS configuration:

{ 'AssociatedSites': ['https://deere.com/'], 'PrimarySites': ['https://johndeere.com/'] }

and Third-party cookies Limited (Using the eye icon in the address bar (Omnibox))

Note: Without above 5 flags we are unable to block cookies between our sites i.e .deere.com and .johndeere.com. Also, Block all third-party cookies from chrome://settings/trackingProtection is NOT enabled.

We tested, but the requests sent from the single-page React app using SDK are still being blocked with the following messages:

Reading third-party cookie is blocked Setting third-party cookie is blocked

Without using the condition 'navigator.permissions.query({name: 'storage-access'}).then', we are able to call document.requestStorageAccess().then and access has been granted. However, from the iframe React app, we are still unable to access cookies from .johndeere.com and send them in the requests to .johndeere.com application.

Any advice or help would be greatly appreciated. Thank you.

cfredric commented 2 months ago

Those flags look reasonable to me, as does the RWS itself, so I think the issue lies in how document.requestStorageAccess() and/or document.requestStorageAccessFor() are being called.

we are able to call document.requestStorageAccess().then and access has been granted.

Great!

However, from the iframe React app, we are still unable to access cookies from .johndeere.com and send them in the requests to .johndeere.com application.

Is that a separate iframe from the one that called document.requestStorageAccess()? If so, the React app iframe also needs to call document.requestStorageAccess() in order to access its cross-site cookies.

Also, where is the React app iframe served from (i.e. what site?)? If it's not from https://johndeere.com, then that iframe won't be able to access https://johndeere.com's cookies. (You'd need something like https://github.com/cfredric/storage-access-headers in order to enable that kind of pattern.)

vn31699 commented 2 months ago

Hi, Thanks much for the response.

No, parent React app1 hosted on .deere.com is calling another React app2 hosted on the same domain .deere.com using " " in a popup window.

And, currently the parent app1 is not calling document.requestStorageAccess() before loading iframe app2. The document.requestStorageAccess() is only called from the iframe app2 before redirecting to app3 on *.johndeere.com where its unable to access cookies and send them to app3.

The React app2 iframe is served from the Parent React app1 and both hosted on the same domain .deere.com. And, app2 on .deere.com calling app3 hosted on *.johndeere.com.

Thanks

vn31699 commented 2 months ago

Hi, Wondering you have any additional questions here. Meanwhile, i went through https://github.com/cfredric/storage-access-headers and implemented New Flow specific changes. I am facing an issue the Parent React app1 on .deere.com is unable to pass the header Sec-Fetch-Storage-Access to server while loading the iframe React app2 which is also on .deere.com. Is it due to Fetch API does not allow setting certain headers, including those prefixed with Sec-, for security reasons ? does it only work with https and not with http://localhost ?? can i simulate the behavior locally by using custom headers that my server can recognize and respond to accordingly or any other option(s) here ?

Thanks

cfredric commented 2 months ago

The document.requestStorageAccess() is only called from the iframe app2 before redirecting to app3 on *.johndeere.com where its unable to access cookies and send them to app3.

Since you are trying to access cookies on https://johndeere.com, you need that iframe to call document.requestStorageAccess().

It's not sufficient to call document.requestStorageAccess() in the "same" iframe and then do a cross-site navigation to get to johndeere.com; the cross-site navigation means that the "before" (app2) and "after" (app3) are two entirely different security/privacy contexts. So app3 is responsible for requesting access to its own cookies, since it is the only thing served from https://johndeere.com in this scenario.

cfredric commented 2 months ago

I am facing an issue the Parent React app1 on .deere.com is unable to pass the header Sec-Fetch-Storage-Access to server while loading the iframe React app2 which is also on .deere.com. Is it due to Fetch API does not allow setting certain headers, including those prefixed with Sec-, for security reasons ?

Thanks for checking out that proposal. Yes, the request header uses a "forbidden" name, which means that websites are not allowed to set that header (for security reasons); only the browser itself is allowed to set the header's value.

We're still in the process of implementing a prototype of that proposal; it is not available on Stable Chrome yet. You can try out the prototype in pre-release versions of Chrome by enabling the chrome://flags#storage-access-headers flag, if you want to try it out. But beware that it is not shipped in Chrome yet, and the semantics/behavior are likely to change.

vn31699 commented 2 months ago

It's not sufficient to call document.requestStorageAccess() in the "same" iframe and then do a cross-site navigation to get to johndeere.com; the cross-site navigation means that the "before" (app2) and "after" (app3) are two entirely different security/privacy contexts. So app3 is responsible for requesting access to its own cookies, since it is the only thing served from https://johndeere.com in this scenario.

How can i implement changes for app3 (johndeere.com) requesting its own cookies in the context of app2 (deere.com) ? is it even feasible without chrome://flags#storage-access-headers feature ? If it's not feasible, any other options here ?

Thanks

vn31699 commented 2 months ago

I am facing an issue the Parent React app1 on .deere.com is unable to pass the header Sec-Fetch-Storage-Access to server while loading the iframe React app2 which is also on .deere.com. Is it due to Fetch API does not allow setting certain headers, including those prefixed with Sec-, for security reasons ?

Thanks for checking out that proposal. Yes, the request header uses a "forbidden" name, which means that websites are not allowed to set that header (for security reasons); only the browser itself is allowed to set the header's value.

We're still in the process of implementing a prototype of that proposal; it is not available on Stable Chrome yet. You can try out the prototype in pre-release versions of Chrome by enabling the chrome://flags#storage-access-headers flag, if you want to try it out. But beware that it is not shipped in Chrome yet, and the semantics/behavior are likely to change.

Thanks for the clarification. We will hold off on this until the feature has been rolled out to the stable Chrome version. In the meantime, please advise on how we can proceed without this feature, if possible.

cfredric commented 2 months ago

How can i implement changes for app3 (johndeere.com) requesting its own cookies in the context of app2 (deere.com) ?

App3 is embedded in app1 (which is on https://deere.com), correct? If so, then you can make app3 invoke document.requestStorageAccess(). That's what I meant by "request access" in the context of deere.com. Please see https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using for information on using that API.

vn31699 commented 2 months ago

How can i implement changes for app3 (johndeere.com) requesting its own cookies in the context of app2 (deere.com) ?

App3 is embedded in app1 (which is on https://deere.com), correct? If so, then you can make app3 invoke document.requestStorageAccess(). That's what I meant by "request access" in the context of deere.com. Please see https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using for information on using that API.

App3 on johndeere.com is not embedded in either app1 or app2 on deere.com, but users are redirected to it for authentication/authorization purposes. In this situation, will the method https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using work?

cfredric commented 2 months ago

I see, so if I understand correctly, your setup sounds similar to the embedded non-iframe example in the Storage Access Headers explainer. In that case, there is no solution until/unless https://github.com/cfredric/storage-access-headers is shipped - in Chrome and/or in other browsers.

vn31699 commented 2 months ago

I see, so if I understand correctly, your setup sounds similar to the embedded non-iframe example in the Storage Access Headers explainer. In that case, there is no solution until/unless https://github.com/cfredric/storage-access-headers is shipped - in Chrome and/or in other browsers.

Thanks for the clarification. Let me go through the non-iframe example and get back. Thanks.

Also, is my understanding correct that the RWS Iframe example only works if app1 on deere.com loads app2 on johndeere.com in an iframe and subsequently calls document.requestStorageAccess() within the iframe of app2? This method would not work for our setup, correct?

vn31699 commented 2 months ago

Hi, Based on Google's recent update on Privacy Sandbox on the web update, we will no longer pursue the RWS and Storage API solution. We have learned that Google currently does not have a solution to meet our iframe use case. Consequently, we hope that our applications and customers will not be impacted starting in 2025.

Aside from migrating our IDP to a first-party domain along with all applications, which is a considerable effort, please inform us if there are any better options requiring less effort.

We appreciate your understanding and support.

ratchanonsuttawas commented 1 week ago

4fe104ef461bc17146db6acc5f1809b705d92712

ratchanonsuttawas commented 1 week ago

Related to the successfully merged PR 'RWS entry for John Deere #418', we are still seeing the 3rd party calls to domain .johndeere.com from first party .deere.com applications being blocked with the below Chrome (126+ version) flags. Can you please help understand why this is not working, is there anything missing and how to test so that calls between our RWS domains not blocked with the below flags ?

third-party-cookie-deprecation-trial -> enabled

tracking-protection-3pcd -> enabled

tpcd-metadata-grants -> disabled

flags#tpcd-heuristics-grants-> disabled

ratchanonsuttawas commented 1 week ago

Good

ratchanonsuttawas commented 1 week ago

Related to the successfully merged PR 'RWS entry for John Deere #418', we are still seeing the 3rd party calls to domain .johndeere.com from first party .deere.com applications being blocked with the below Chrome (126+ version) flags. Can you please help understand why this is not working, is there anything missing and how to test so that calls between our RWS domains not blocked with the below flags ?

third-party-cookie-deprecation-trial -> enabled

tracking-protection-3pcd -> enabled

tpcd-metadata-grants -> disabled

flags#tpcd-heuristics-grants-> disabled