Interacting with embedded applications as top-level prior to granting permission

[andywang219]

Hi @cfredric,

I am trying to get a better understanding for the error message: Request denied because the embedded site has never been interacted as a top-level context.

My questions are:

1. What actions are considered as an interaction? Does visiting the site as a top-level context suffice or does the user need to click around?
2. Is there a workaround for this? In the scenario where an application is completely hidden from the end user, this might pose some issues because now the end user needs to interact with a site that they never knew they were using.
3. Who are considered to be new users when determining if the user needs to interact with the embedded site as top-level? If we have company A and B, and company B embeds company A as a third-party site. If an user at company B has interacted with company A as the top-level site, will every other user at company B be required to interact with A as the top-level site?

As an example for question 2, company A has a chat widget that also comes with APIs where developers can use to interact with said widget. Company A provides the option to hide the default chat widget from the HTML and allow company B to build their own UI and then interact with the chat widget via the APIs. The default chat widget becomes a proxy in this use case. Now with requestStorageAccess, users have to interact with the default widget in order to be granted permission.

[cfredric]

Hi @andywang219,

I'll jump right into your questions:

1. What actions are considered as an interaction? Does visiting the site as a top-level context suffice or does the user need to click around?

A user interaction (aka activation or user gesture) is something defined by the HTML standard. It lists the different kinds of interactions here: keypresses, mouse clicks, and touch events.

2. Is there a workaround for this? In the scenario where an application is completely hidden from the end user, this might pose some issues because now the end user needs to interact with a site that they never knew they were using.

There's no workaround for this in Chrome, if your application requires read/write access to unpartitioned state (and therefore really requires the Storage Access API). If an embedded cross-site application needs to access unpartitioned state (e.g. a user identifier), then the user ought to know that the application exists, and be aware that they're interacting with it.

(Just for context: the top-level user interaction requirement is to protect Chrome users from prompts that come from sites which the users have never heard of and have no intention of using. This is an attempt to avoid the kind of spam we've seen through push notifications prompts, for example.)

3. Who are considered to be new users when determining if the user needs to interact with the embedded site as top-level? If we have company A and B, and company B embeds company A as a third-party site. If an user at company B has interacted with company A as the top-level site, will every other user at company B be required to interact with A as the top-level site?

"Users" for these purposes are individual browser profiles in Chrome. If one Chrome profile/user interacts with company A, that is not sufficient to conclude that every Chrome profile/user is ok with seeing prompts from company A while it's embedded under another site (e.g. company B's site). So yes, every other Chrome user who visits company B's site and needs to use the company A embed will have to interact with company A's site in a top-level context beforehand.

---

I want to point out an important detail here though - my response to your second question said "if your application requires read/write access to unpartitioned state". You never mentioned needing to share your application's state regardless of which top-level site it's embedded under (e.g. A embedded under B, vs A embedded under C), so it's possible you don't actually need unpartitioned state. If you don't need to share that state, then partitioned state might be ok for you. In that case, I'd recommend checking out CHIPS, which require neither a prompt nor an interaction in a top-level context.

Similarly, if you require unpartitioned state but don't need to be able to both read and write to it, you could check out some of the other Privacy Sandbox proposals (particularly Fenced Frames and Shared Storage) and see if they address your needs.

[bretticus-mc]

How are third-party authentication cookies using SAML/SSO supposed to work then?

We support an application that's embedded in customer websites as an iframe. The customer will authenticate with their SAML provider in the top-level context, which will perform a SAML assertion to our product to retrieve a third-party authentication cookie. With the coming change, we need to use the StorageAccessAPI to access that cookie from our iframe. However, our customers interact with our product solely in an embedded context. Therefore, Chrome will deny the requestStorageAccess call saying they've never interacted with our application as a top-level context. This requirement completely breaks our authentication flow, and I imagine many others who aren't aware of this coming change.

If an embedded cross-site application needs to access unpartitioned state (e.g. a user identifier), then the user ought to know that the application exists, and be aware that they're interacting with it.

The storageAccessAPI already requires a user gesture; so the customer already knows the application exists.

[cfredric]

How are third-party authentication cookies using SAML/SSO supposed to work then?

To my knowledge, we (Chrome) haven't yet seen an authenticated embed use case where the user is expected to never interact with the embedded site in a top-level context. In all the use cases we've seen, the user is brought through a flow that involves a login in a popup or some other top-level context (e.g. a redirect), which sets the unpartitioned cookie that gets accessed later on by the iframe. This flow is common enough that Firefox automatically grants storage access to any site that the user has interacted with in a top-level context; Safari also grants access in these situations, AFAIK. Chrome is prototyping this heuristic as well.

(On the subject of other browsers, what have you observed in browsers like Firefox and Safari which already block third-party cookies by default?)

We've also seen some use cases where the embedded iframe is invisible but still relies on the user's (unpartitioned) identity. Chrome and other browsers are still exploring the solution space for those scenarios; the latest proposal in this space is the Top-Level Storage Access API Extension, but this still assumes that the user will visit the embedded site as a top-level context to log in at some point.

Chrome also supports the FedCM API, which is an option for federated sign-in. This API does support usage from within an iframe, so if your application can use FedCM, it could be available to you in these iframes.

With all of this in mind, is it an option for you to open a top-level context (e.g. a popup) in which your users can log in, or at least click a "Proceed with <XYZ app>" button? If it is, then it would solve your problem, IIUC.

If an embedded cross-site application needs to access unpartitioned state (e.g. a user identifier), then the user ought to know that the application exists, and be aware that they're interacting with it.

The storageAccessAPI already requires a user gesture; so the customer already knows the application exists.

I was responding to @andywang219's "In the scenario where an application is completely hidden from the end user, this might pose some issues because now the end user needs to interact with a site that they never knew they were using" question (emphasis mine). This example shows why a user gesture in the embedded context cannot prove that the user knows that the embedded application exists. This is why that user gesture is necessary but not sufficient for getting the storage-access permission via document.requestStorageAccess in Chrome.

[jagadeeshaby]

@cfredric

Thanks for looking into the issue.

For a context its the same setup which we were discussing in the previous issues #6 . ( the one with videos and screenshots)

the only confusion here is the restrictions of site never been interacted as a top level context which is different from asking storage access with explicit grant access button interaction from the same site in an embedded context. In this case even though user s doing explicit interaction which isn't considered valid and rejected by RSA.

Yes our users always interacts( click) with embedded site which grants access to cookies set during SSO navigation.

Take an example of brand new chrome browser download, and first time user navigates to their company site which embeds third party site in question , which asks for storage access with explicit click interaction and then allow sso navigation to continue in a separate same site iframe or popup which sets un partitioned cookies( all 302s mostly) . In this flow explicit click action invokes rsa but fails with message that you never interacted with embedded site in top level, could u guide how to handle this use case? This goes away as soon as the user opens up embedded site once in a new tab, which i want to avoid.

[cfredric]

Thanks for the context.

the only confusion here is the restrictions of site never been interacted as a top level context which is different from asking storage access with explicit grant access button interaction from the same site in an embedded context. In this case even though user s doing explicit interaction which isn't considered valid and rejected by RSA.

To be clear, the Storage Access API in Chrome requires two distinct user interactions:

1. A user interaction in the embedded site as a top-level, sometime within the last 30 days. This is some reassurance to the browser that the user has some existing relationship with the site, they know what it is, etc.
2. A user interaction in the embedded site in the cross-site iframe, immediately before the call to document.requestStorageAccess.

Interaction #​1 is to reassure the browser that the user might actually have some relationship with the site in question. If the user has never interacted with the site in its own top-level context, the user is less likely to be familiar with the site in question. We (Chrome) want to be sure that when we show a permission prompt, the user has definitely heard of the site that's requesting permission. This is part of ensuring that the user understands as much as possible about the request.

Of course, a user interaction in a top-level context doesn't guarantee that the user is ok with that site asking for storage-access permission in the future. But it's at least a baseline requirement that Chrome can apply to protect the user from spammy permission prompts or prompts that they don't understand.

Interaction #​2 is a standard requirement for any permission prompt, and any powerful API in the web platform.

Yes our users always interacts( click) with embedded site which grants access to cookies set during SSO navigation.

Can you elaborate more on your SSO arrangement? How/when does the user sign into your application? Is it possible to do the sign-in before your application requests storage-access permission?

could u guide how to handle this use case? This goes away as soon as the user opens up embedded site once in a new tab, which i want to avoid.

I would recommend exactly what you said: opening the embedded site once in a new tab, before asking for storage-access permission. Are there constraints that make that difficult/impossible for you?

Coming at this from a different angle - in browsers that don't require the top-level interaction (Safari and Firefox, to my knowledge), what do you observe? Do your users understand the permission prompts and why they might want to grant or deny permission? How often do your users accept the prompt and continue with the SSO flow? How often do they deny permission or dismiss the prompt?

[andywang219]

Hi @cfredric,

Could you clarify if the 30 days in Interaction #1 is a rolling 30 days or strict 30 days?
IE. Does the 30 days reset if the user interacts with the website as top-level on day 29?

[cfredric]

Hi @andywang219, I'm not sure what you mean by "rolling" vs "strict". But to hopefully answer your question anyway - at the time when document.requestStorageAccess is called, Chrome finds the timestamp of the most recent user interaction in the third-party site in a top-level context. If that timestamp is more than 30 days ago, Chrome rejects the document.requestStorageAccess call. Otherwise, Chrome prompts the user to allow/deny/dismiss the request.

So, if the user interacts with the site on day 0, then interacts with the site on day 29, then calls document.requestStorageAccess() on day 31, the most recent top-level user interaction on that site would be from day 29 which is less than 30 days from the present (day 31). So Chrome would show a prompt.

If instead, the user interacts with the site on day 0, then calls document.requestStorageAccess() on day 31, the most recent top-level user interaction on that site is from day 0 which is more than 30 days from the present (day 31). So Chrome would not show a prompt in this scenario, and would deny the request automatically.

[andywang219]

Thank you for the clarification!

[andywang219]

One follow up question, will Chrome expose an API to allow developers retrieve the timestamp that you mentioned?

[johannhof]

There's currently no proposal for that, however, you should be able to store this information in storage or cookies relatively easily, if it matters to you (I'm not really sure there's a use case for this).

[cfredric]

+1 to Johann's comment. I'd also add that if Chrome were to expose the most recent top-level interaction timestamp, and the embedded context were able to read it (before having called document.requestStorageAccess()), that would represent a cross-site data leak. (Being able to match up a timestamp like 1699018458019 between two visitors to your site is a pretty strong signal that it's actually the same visitor.) Chrome and other browsers are working to reduce passively-available cross-site signals like that, so I don't think such an API is likely to be built.

[andywang219]

Got it, thank you both

[jagadeeshaby]

thank you @cfredric

Apologies for the delay in response.

A user interaction in the embedded site as a top-level, sometime within the last 30 days. This is some reassurance to the browser that the user has some existing relationship with the site, they know what it is, etc.

To me this doesn't sound right and not practical and makes it completely painful for our third party SASS applications.

Take an example of the typical SASS app usage, the whole point of embedded app is to take away the need for users to navigate to a different domain/tab and rather have it within the users workspace and work along side with other apps. (Example Call handling app along side with the CRM providers like Salesforce , zendesk or even customer own solution) so in this case asking users to open embedded site in a top level site is breaking the whole usability aspect of it.

in browsers that don't require the top-level interaction (Safari and Firefox, to my knowledge), what do you observe? Do your users understand the permission prompts and why they might want to grant or deny permission? How often do your users accept the prompt and continue with the SSO flow? How often do they deny permission or dismiss the prompt?

that's at least perfect for our SASS applications and Firefox and Safari does great in this area.

Do your users understand the permission prompts and why they might want to grant or deny permission?

Yes they do understand the prompt as we make it clear to them with a banner which asks to grant access and provides links to SASS app FAQs.

How often do your users accept the prompt and continue with the SSO flow?

At least from our data, it's Always.

How do we discuss further about making the top level interactions optional or follow the same model as safari or firefox to be consistent?

[cfredric]

Hi @jagadeeshaby,

To me this doesn't sound right and not practical and makes it completely painful for our third party SASS applications.

Take an example of the typical SASS app usage, the whole point of embedded app is to take away the need for users to navigate to a different domain/tab and rather have it within the users workspace and work along side with other apps. (Example Call handling app along side with the CRM providers like Salesforce , zendesk or even customer own solution) so in this case asking users to open embedded site in a top level site is breaking the whole usability aspect of it.

To be clear, the requirement of an interaction in a top-level context is only necessary if your embedded application needs to use unpartitioned state. Unpartitioned state is particularly sensitive because it allows an embedded site/app to track a user as they browse the web.

If your SaaS (I assume this is what you mean instead of SASS?) application does not need unpartitioned state, then it can freely use partitioned cookies and partitioned storage without needing to prompt the user and without the user visiting it as a top-level site.

With that in mind, I'd like to understand your application's requirements better, to understand the following:

1. Why an application (which is always embedded) needs access to unpartitioned state?
2. How you ensure that the user understands what your application is and why they might want to enable/use it, given that the user never visits your site in a top-level context?

If I understand correctly, the only reason for a SaaS app (which is always embedded) to require access to unpartitioned state would be if the app is embedded under multiple top-level sites and needs to recognize a single user as they visit multiple of those sites. I understand your app is embedded under many top-level sites, but does it actually need to recognize a single user across multiple sites? If so, can you elaborate on why? (My impression is that this isn't necessarily required for an embedded SaaS application, but I'm happy to be educated otherwise.)

Alternatively - can you rely on partitioned state for the majority of your users, and only impose the top-level user interaction and Storage Access API permission prompt for the presumably-small population of users who use your application across multiple sites?

I'm also curious about the answer to a previous question of mine:

I would recommend exactly what you said: opening the embedded site once in a new tab, before asking for storage-access permission. Are there constraints that make that difficult/impossible for you?

Can you help me understand why opening a single tab (once) is an unrealistic burden for your app? I understand that the UX is no longer "seamless"/transparent, but from the browser's point of view, that can be viewed as an improvement since the user now has more control and awareness of how their data is used and flows throughout the web. When designing the Web Platform, Chrome strives to put users' needs (e.g. for control and information) above web developers' needs (e.g. for seamless UX). See https://www.w3.org/TR/design-principles/#priority-of-constituencies.

Do your users understand the permission prompts and why they might want to grant or deny permission?

Yes they do understand the prompt as we make it clear to them with a banner which asks to grant access and provides links to SASS app FAQs.

Interesting, this seems like it disagrees with a previous statement in this thread: "now the end user needs to interact with a site that they never knew they were using" (emphasis mine). Did your app recently change to show the banner to users? Or do users get a different experience depending on which browser they are using?

How do we discuss further about making the top level interactions optional or follow the same model as safari or firefox to be consistent?

I think this is the appropriate forum to discuss Chrome's behavior in this regard. CC @helenyc

[jagadeeshaby]

Thank you for the response, and yes my bad and thanks again for Correcting SASS as SaaS.

Why an application (which is always embedded) needs access to unpartitioned state?

This is for the SSO use case, where Unpartitioned cookies are set ( either via SSO Popup, Redirections - Form Post) and made available on the SaaS app domain which are required for embedded SaaS app to function.

How you ensure that the user understands what your application is and why they might want to enable/use it, given that the user never visits your site in a top-level context?

SaaS app is behind the specific Authentication and our users well aware of the SaaS app provider. As a first step , SaaS app displays a Banner which talks about why they need to provide access and links to public FAQs doc for more details.

Would be if the app is embedded under multiple top-level sites

Partially true, but it's more of Customer A using SSO enabled link to access the embedded SaaS app, consider User clicking on a SAML enabled link which does some redirections and after the successful SAML token assertion, it reaches the SaaS app domain which sets the cookie and ultimately redirects to Customer domain. Below is the simplified version of the interactions.

Step1: User clicks on login button (points to SAML SSO) on their company website, which looks like - https://saml-sso?relay-state=https://SaaS.com?destination='https://customer.com'

Step 2: SAML SSO URL redirects to relay state after the SAML token assertion (success(), which looks like https://SaaS.com -> recognizes the user and sets the cookie and redirects to destination URL - https://customer.com which gets validated against the customer registered URLs.

Step 3: https://Customer.com -> uses the Javascript library and loads the SaaS app in an iframe and at this point the SaaS app should have access to the cookie set in step 2, but it fails due to all the 3p cookie deprecations.

Step 4: to tackle the failure in Step 3 and to keep least integration changes on the customer side, we introduced RSA banner to get access to unpartitioned cookies which explains why users should click on continue and grant access ,

Step 5: user clicks continue button within the RSA banner and supposed to continue accessing the SaaS app but it fails with top level interaction error. This is where we are stuck!

Will respond to other questions in the next thread ( becoming too long)