Giters

WICG / first-party-sets

Home Page:https://wicg.github.io/first-party-sets/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

serviceSites auto-grant access not working correctly

mkadzik opened this issue · comments

commented

When trying out working with serviceSites we could not make use of auto-gran access feature.

Indeed with document.requestStorageAccessFor everything works! Thanks for your help!
posted by @jczekaj3 in #163 (comment)_

commented

@mkadzik Could you share a few more details about your set-up? Have you already configured the set locally via command-line flags (see example here).

commented

@krgovind yes, I am launching chrome with:

open -a 'Google Chrome' --args \
  --enable-features='FirstPartySets:FirstPartySetsClearSiteDataOnChangedSets/1,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI' \
  --use-first-party-set='{"primary": "https://«primary»", "associatedSites": ["https://«associated»"], "serviceSites": ["https://«service»"]}'
commented

Hi @mkadzik,

That command line looks reasonable (though I'm unfamiliar with that open command - I'll defer to you on that). Can you please also share how your webpages are set up?

In order to get access to unpartitioned cookies on the service site, your pages need to:

  1. Call and await document.requestStorageAccessFor(serviceSite) from one of the non-service sites in your set, as a top-level (non-embedded) page.
    • Now the top-level site can issue cross-site subresource requests to the service site using CORS mode, and those requests will now carry the service site's SameSite=None cookies.
  2. Call and await document.requestStorageAccess() on the embedded service site. (This will resolve due to the previous call to document.requestStorageAccessFor, but it is necessary as a CSRF protection.)
    • Now the service site should be able to access its unpartitioned cookies while embedded under the site that called document.requestStorageAccessFor in step 1. (If the service site needs access while embedded under other sites in your set, those sites also need to call document.requestStorageAccessFor.)

Can you confirm your pages do both of these steps? And if you're already doing both of them, can you give more detail about which part of the process isn't behaving as you expect (e.g. calling and awaiting document.requestStorageAccessFor, calling and awaiting document.requestStorageAccess, accessing cookies via cross-site subresource requests from the top-level page, accessing cookies from the embedded page)?

commented

In our scenario, ServiceSite does not provide an HTML page that would be inserted into the main site’s DOM, but is a CDN and additionally sets some cookies.

We are a bit confused because here: https://github.com/WICG/first-party-sets#:~:text=limit%20on%20domains%2C-,auto%2Dgrant%20access,-.%20Not%20allowed%20to “auto-grant access” is mentioned for ServiceSite domains.

In the following example:

window.onload = async () => {
  const { state } = await navigator.permissions.query({
    name: 'top-level-storage-access',
    requestedOrigin: 'https://service.com'
  })

  if (state === 'granted') {
    await fetch('https://service.com/granted', { credentials: 'include' })
  } else if (state === 'prompt') {
    const button = document.createElement('button')

    button.innerText = 'Allow FPS'

    button.onclick = async () => {
      await document.requestStorageAccessFor('https://service.com')
      await fetch('https://service.com/prompt', { credentials: 'include' })
      document.body.removeChild(button)
    }

    document.body.appendChild(button)
  }
}

first state === 'prompt' and after clicking the “Allow FPS” button the request https://service.com/prompt is executed.
After reloading the page, we get state === 'granted' and the request https://service.com/granted is executed.

What does “auto-grant access” actually mean for ServiceSite domains?

commented

Hi @jczekaj3, thanks for testing this out!

What does “auto-grant access” actually mean for ServiceSite domains?

It means that when the top-level site requests storage access on behalf of the service site (via document.requestStorageAccessFor), that request is automatically granted by the browser. I.e., the browser does not prompt the user to grant the permission.

It does not mean that the top level site or service site always have top-level-storage-access permission, as you've seen. The top level site has to explicitly request permission before it is granted. (This is for security reasons.)

Does that clear things up for you?

commented

Hi @cfredric, thanks for your reply!

I still do not understand what you mean by “the browser does not prompt the user to grant the permission” because

window.onload = async () => {
  await document.requestStorageAccessFor('https://service.com')
  await fetch('https://service.com/granted', { credentials: 'include' })
}

doesn't work and seems to require prompt the user to grant the permission:

requestStorageAccessFor

commented

Ah, I think I see what the confusion is. The error message in that screenshot (requestStorageAccessFor: Must be handling a user gesture to use.) means that the top-level site may only call the document.requestStorageAccessFor API when the user is interacting with the page. More specifically, the page must have "transient activation" - which means that the user must have just clicked or pressed a key or similar. Typically people use onclick event handlers (or similar) to run code that requires transient activation.

The intent here is to indicate to the browser that the user is interested in using your page, before your page is allowed to get a new top-level-storage-access permission grant. Once the user has interacted with your page, you may request permission via document.requestStorageAccessFor, and the browser will grant the permission without needing to ask the user.

commented

Hi @cfredric and thanks again for your reply!

Unfortunately, I don’t see any difference in running the example code (the one with the navigator.permissions.query call) regardless of whether https://service.com is serviceSites or associatedSites, i.e. regardless of whether Google Chrome starts with the command

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --enable-features='FitPartySets:FirstPartySetsClearSiteDataOnChangedSets/true,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI' \
  --use-first-party-set='{"primary": "https://primary.com", "associatedSites": ["https://associated.com"], "serviceSites": ["https://service.com"]}'

or with the command

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --enable-features='FitPartySets:FirstPartySetsClearSiteDataOnChangedSets/true,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI' \
  --use-first-party-set='{"primary": "https://primary.com", "associatedSites": ["https://associated.com", "https://service.com"]}'

in both cases the browser does not prompt the user to grant the permission and in both cases the requestStorageAccessFor must be handling a user gesture to use.

commented

Thanks for including the command lines you're using, that's helpful info for debugging. I do see a typo there: --enable-features='FitPartySets,... should be --enable-features='FirstPartySets,.... You can copy/paste the command listed here, and adapt it to your use case.

However, the --use-first-party-set=... flag automatically enables the FirstPartySets feature, so you happen to be enabling the right set of features anyway :)

in both cases the browser does not prompt the user to grant the permission and in both cases the requestStorageAccessFor must be handling a user gesture to use.

This sounds correct to me - neither case should trigger a prompt to the user, both cases should require a user gesture, and in both cases the browser should automatically grant the permission (once it is requested). Are you expecting a different behavior?

The description of service sites / associated sites might not be precise enough; we can improve that if that's the case and it led you to expect something different. The differences between service sites and associated sites are:

  • Service sites cannot call document.requestStorageAccessFor on behalf of some other site; associated sites can.
  • Service sites cannot be the top-level site when some embedded iframe calls document.requestStorageAccess; associated sites can.
  • There is a limit on the number of associated sites that are allowed to be in a single First-Party Set; there is no limit to the number of service sites.

In particular, both associated sites and service sites should have storage access requests auto-granted (without prompting the user) if the request is within a First-Party Set (and that request satisfies all the security constraints, e.g. having a user gesture). Which I think matches the behavior you're seeing!

commented

Hi @cfredric, thanks again for your reply!

One more question: What is the limit on the number of associated sites that are allowed to be in a single First-Party Set?

Here: https://github.com/WICG/first-party-sets#:~:text=or%20similar%20forms).-,Limit%20of%203*%20domains,-.%20If%20greater%20than there is mention of a limit of 3 with the information that the limit will be given later. We are one of the larger publishers, and would rather need a limit of several hundred associated sites.

Is it known what the limit is, or when it will be determined?

commented

What is the limit on the number of associated sites that are allowed to be in a single First-Party Set?

We publicly announced a new limit yesterday, of 5 associated sites: https://developer.chrome.com/blog/related-website-sets/

commented

We publicly announced a new limit yesterday, of 5 associated sites: https://developer.chrome.com/blog/related-website-sets/

We are one of the larger publishers, and would rather need a limit of several hundred associated sites.
First-Party Sets feature with a limit of 5 associated sites is useless. Is this the final value of the limit?

commented

When trying out working with serviceSites we could not make use of auto-gran access feature.

Indeed with document.requestStorageAccessFor everything works! Thanks for your help!
posted by @jczekaj3 in #163 (comment)_

commented

Hi @jczekaj3 - thanks for your feedback and apologies for the delay. Like all things on the web platform, RWS is subject to improvements in usability, privacy/security considerations, etc, but Chrome intends for the RWS associated limit to remain at 5, while exploring alternative ways to mitigate user-facing breakage for use cases that remain impacted. We encourage you to examine how other Privacy Sandbox technologies may work for your use cases, if not addressed by RWS. If there is a use case that is not supported, please let us know.

commented

There hasn't been any activity on this issue in months, so I'll consider this question answered. Closing.

commented