Questions about the RWS usage

[daiyanze]

Hi there!
Hope someone could answer my questions about the RWS usage.

1. Is the .well-known folder required to be hosted on the "primary" domain (e.g. mydomain.com)? If so, do subdomains (e.g. service.mydomain.com & payment.mydomain.com) also need to host this folder?

2. Suppose we need to update the RWS config and opened up a PR which passed the CI automated-tests. How long does it take to get approvals?

PS: I've seen quite a few PRs being merged in more than 5 days after its opening. Hope there's somewhat method to accelerate the review process under urgent situation.

3. If the PR gets merged, does Chrome reflect the changes immediately or it'll take some time to?

4. Upon my local testing, I've found that the following settings result in the same behavior.

{"primary": "https://test.com", "associatedSites": ["https://mydomain.com/"]}

{"primary": "https://test.com", "serviceSites": ["https://mydomain.com/"]}

{"primary": "https://mydomain.com/", "associatedSites": ["https://test.com"]}

test.com is the client site. mydomain.com provides a 3rd party cookie.

test.com needs to send request to mydomain.com with that 3rd party cookie. In this case, I suppose we'll have to utilize the API document.requestStorageAccessFor to grant access after user properly interacted with the page.

The doc says if I put "mydomain.com" into "serviceSites", when I request 3rd party storage access I'll get blocked. However, it's on the contrary. Wonder why this happened.

[cfredric]

Hi @daiyanze,

1. Is the .well-known folder required to be hosted on the "primary" domain (e.g. mydomain.com)? If so, do subdomains (e.g. service.mydomain.com & payment.mydomain.com) also need to host this folder?

Yes, the .well-known files should be served from the sites that are declared in the related_website_sets.JSON file; i.e. they should be served from the eTLD+1s, not from subdomains. Subdomains do not need to serve the .well-known files separately.

If you'd like to run the CI on your submission locally before making it public, you can follow the instructions here.

2. Suppose we need to update the RWS config and opened up a PR which passed the CI automated-tests. How long does it take to get approvals?
   PS: I've seen quite a few PRs being merged in more than 5 days after its opening. Hope there's somewhat method to accelerate the review process under urgent situation.

The maintainers merge all acceptable contributions once weekly, on Tuesdays. In order to be merged in a timely fashion, a PR must pass the automated CI, must allow edits from maintainers (so that we can resolve merge conflicts), and the author must have signed the CLA.

The PRs you've seen which have taken more than 1 week to merge are either due to holidays, or because there are unresolved problems with the PR content.

3. If the PR gets merged, does Chrome reflect the changes immediately or it'll take some time to?

It takes some time. Chrome consumes the list regularly and ships it to users as an updateable component. Users' machines periodically check for updates when they're running Chrome and are connected to the internet.

4. Upon my local testing, I've found that the following settings result in the same behavior.

There are differences between those setups, but depending on how your sites work, you might not see any difference.

The doc says if I put "mydomain.com" into "serviceSites", when I request 3rd party storage access I'll get blocked. However, it's on the contrary. Wonder why this happened.

This section of the submission guidelines was inaccurate for a while; I recently fixed it, so it is correct now and should match the behavior you see in Chrome. Please let me know if you find otherwise.

[daiyanze]

Hi @cfredric ,
Thank you so much for answering! Allow me continue with some further confirmations.

Question about the user gesture,
is user-gesture required after Chrome app restart or OS reboot to grant permission for 3rd party storage access?

Chrome consumes the list regularly and ships it to users as an updateable component

I'd like to know about the updatable component update frequency.
Is this updatable component delivered along with the Chrome stable version updates every month? Or is there a minor / patch being rolled out regularly for instance every week? If so, does it require users to re-launch Chrome instance?

This section of the submission guidelines was inaccurate for a while; I recently fixed it, so it is correct now and should match the behavior you see in Chrome. Please let me know if you find otherwise.

That commit solved some ambiguous points. Appreciated that!

However, on our side, the 3rd party domain is not embedded into the primary domain. From primary domain, it's just sending requests to 3rd party domain.

In my case, I think the condition of 3rd party being blocked is as below:

• RWS config -> {"primary": "https://mydomain.com", "serviceSites": ["https://test.com/"]}
  (I think this config is simply not taking effect for test.com)
• Visit test.com -> request permission to mydomain.com

If the primary is test.com, it seems it doesn't matter mydomain.com is under either "service" or "associated" subset. It'll grant the permission in my case.

[cfredric]

Question about the user gesture,
is user-gesture required after Chrome app restart or OS reboot to grant permission for 3rd party storage access?

Yes, due to a an implementation detail in Chrome. We're open to changing this to match non-RWS Storage Access grants (which persist after restarts), if this is particularly painful for you.

Is this updatable component delivered along with the Chrome stable version updates every month? Or is there a minor / patch being rolled out regularly for instance every week? If so, does it require users to re-launch Chrome instance?

No, it is distributed via Component Updater, and doesn't require a new build of Chrome. A new RWS update doesn't take effect until the user restarts Chrome, in order to avoid having a disruptive user experience (since in theory, Chrome may have to clear some cookies and site data as a result of the update).

However, on our side, the 3rd party domain is not embedded into the primary domain. From primary domain, it's just sending requests to 3rd party domain.

I see. In that case you don't have an iframe so requestStorageAccess() won't be useful to you; only requestStorageAccessFor(origin) is relevant to your case.

In my case, I think the condition of 3rd party being blocked is as below:

• RWS config -> {"primary": "https://mydomain.com", "serviceSites": ["https://test.com/"]}
  (I think this config is simply not taking effect for test.com)
• Visit test.com -> request permission to mydomain.com

This makes sense to me. You've declared test.com as a service site, and service sites are not allowed to call requestStorageAccessFor(), so test.com cannot send credentialed requests to mydomain.com.

If the primary is test.com, it seems it doesn't matter mydomain.com is under either "service" or "associated" subset. It'll grant the permission in my case.

Correct; primary and associated sites can call requestStorageAccessFor(origin) on behalf of any other site in the RWS. So if test.com is the primary site, it can request acceess for mydomain.com.

[daiyanze]

@cfredric
Thank you so much for the explanations. I now had a better understanding of the RWS usage!