requestStorageAccess API usage for embed only use-case.

[gurumvg]

From the Storage Access API documentation, the third-party website ( comments.com ) has to be accessed first as a first-party-site context by launching the third-party website in a 'standard browser address-bar' prior to landing into a page where the third-party website is embedded in the actual first party website (mysite.com).

However, this might not work for an embed only use-cases like Disqus or when there is sso / no-explicit authentication involved.

In such use-cases, how should the third-party establish itself as a first-party-site context ? If it is using popup window, we have observed that first-party-site context / cookies are lost when the popup is closed and manual switching between the popup and main window doesn't seem to be a good end-user interaction. Also the requestStorageAccess() doesn't work if you do not activate/focus the popup window manually.

Usage reference: https://webkit.org/blog/8124/introducing-storage-access-api/

[mpirog-hw]

To add to your example, @gurumvg...

The healthcare IT space makes heavy use of iframes and embed-only use cases. For example, a simple ASP.NET web app in an iframe that needs to store a session cookie currently fails in Safari.

Users often aren't aware of the third-party and shouldn't need to interact with those domains as a first-party every 24 hours just to be given the option to allow storage access.

[johnwilander]

Users often aren't aware of the third-party and shouldn't need to interact with those domains as a first-party every 24 hours just to be given the option to allow storage access.

Revealing/showing third parties that can track users across websites is an explicit goal of the prompt the Storage Access API shows.

I don’t know where you got the 24 hours from. WebKit’s implementation requires user interaction as first party or granted access through the Storage Access API every 30 days of browser use.

[johnwilander]

Hi! Thanks for filing and sorry for not responding to you first.

From the Storage Access API documentation, the third-party website ( comments.com ) has to be accessed first as a first-party-site context by launching the third-party website in a 'standard browser address-bar' prior to landing into a page where the third-party website is embedded in the actual first party website (mysite.com).

However, this might not work for an embed only use-cases like Disqus or when there is sso / no-explicit authentication involved.

It was a long time since I used Disqus but as far as I know, you log in to them. In fact, they are a canonical use case for the Storage Access API.

For what you refer to as embed only, the "authenticated embed" does not apply since it's not recommended to log users in when you are third-party (indistinguishable from phishing). In practice, all the cases of "authenticated embeds" involve taking the user to the website as first party and authenticating them.

If there is no authentication involved, there is no need for cookies or other unpartitioned storage.

In such use-cases, how should the third-party establish itself as a first-party-site context ? If it is using popup window, we have observed that first-party-site context / cookies are lost when the popup is closed and manual switching between the popup and main window doesn't seem to be a good end-user interaction.

Can you explain a bit more what you mean by "first-party-site context / cookies are lost"? If a site is first party, it has access to its first party storage. If it is third-party, it may not, depending on the browser's policy.

Also the requestStorageAccess() doesn't work if you do not activate/focus the popup window manually.

At least in the case of WebKit, the user has to have interacted with the requesting third-party as first party website the last 30 days of browser use. This requirement is naturally fulfilled through the authentication flow described above.

Usage reference: https://webkit.org/blog/8124/introducing-storage-access-api/

[mpirog-hw]

I don’t know where you got the 24 hours from. WebKit’s implementation requires user interaction as first party or granted access through the Storage Access API every 30 days of browser use.

@johnwilander, I think it must have come from a misinterpretation of expiration under the link decoration scenario described here: https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/

Thank you. It hasn't been easy to uncover these details and the 30 day distinction is an important one for several use cases. Firefox's implementation doesn't appear to have this requirement, only adding to my confusion.

However, the need to support embed-only use cases stands, Disqus aside. I am optimistic that the proposal being discussed in issue #41 will ameliorate this.

As it stands now, swaths of the healthcare IT space are broken for Safari users where prior first-party context is not an option.

[johnwilander]

I don’t know where you got the 24 hours from. WebKit’s implementation requires user interaction as first party or granted access through the Storage Access API every 30 days of browser use.

@johnwilander, I think it must have come from a misinterpretation of expiration under the link decoration scenario described here: https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/

Thank you. It hasn't been easy to uncover these details and the 30 day distinction is an important one for several use cases. Firefox's implementation doesn't appear to have this requirement, only adding to my confusion.

That’s unfortunate but I’m glad we got it sorted. You’d have to ask someone at Mozilla, such as @englehardt, to see if they have some similar requirements or if any third-party can be granted storage access through the API in Firefox.

However, the need to support embed-only use cases stands, Disqus aside. I am optimistic that the proposal being discussed in issue #41 will ameliorate this.

Can you provide some examples of embed-only use cases where the embedded content authenticates the user and needs to use cookies?

Issue 41 is about not showing the prompt, it is not about relaxing any other requirements, such as WebKit’s required user interaction as first-party website the last 30 days.

As it stands now, swaths of the healthcare IT space are broken for Safari users where prior first-party context is not an option.

If you have concrete examples of this, it would help. Thanks!

[mpirog-hw]

If you have concrete examples of this, it would help. Thanks!

A user logs in to their health plan provider's patient website. Within the website is a portal consisting of a third-party solution within a iframe. The first-party authorizes with the third-party to obtain a short-lived token, containing user authentication, which is passed to the third-party via the iframe's request. The third-party issues a session cookie to persist the authenticated context across navigation within the iframed website.

In this scenario, the user is likely unaware of the third-party's identity by design. Even if it were possible to prompt the user for tracking access via the Storage Access API, it would misrepresent the third-party's usage of storage -- all that is required is partitioned storage.

[gavri]

WebKit’s implementation requires user interaction as first party or granted access through the Storage Access API every 30 days of browser use.

@johnwilander Does the "or" in this statement mean that we either ensure user interaction as first party and if we don't, it's only then that the storage access request prompt shows up? Or alternatively, if we don't mind the storage access API prompt showing up, we don't need user interaction as first party?

[johnwilander]

WebKit’s implementation requires user interaction as first party or granted access through the Storage Access API every 30 days of browser use.

@johnwilander Does the "or" in this statement mean that we either ensure user interaction as first party and if we don't, it's only then that the storage access request prompt shows up? Or alternatively, if we don't mind the storage access API prompt showing up, we don't need user interaction as first party?

Neither. What I’m saying is that being granted storage access through the Storage Access API counts as user interaction as first party.

Let’s use news.example having comment.example as an embedded third party and comment.example needs cookie access.

For access to me possible the first time, the user has to have interacted with comment.example as first party website the last 30 days of Safari use. If all other requirements are fulfilled too, the prompt will show asking if the user allows comment.example to use website data under news.example. If the user chooses “Allow,” that counts as renewed user interaction as first party for comment.example.

Subsequent comment.example requests for storage access through the API under news.example will be granted without prompt since the user has already opted in. These grants also count as renewed user interaction as first party for comment.example.

As you can tell, this is designed to continue to work without frequent revisits to comment.example as first party website. If the user re-engages, things keep working without a new prompt.

[gavri]

@johnwilander It sounds like in the kind of use case where a user interacts with the embed at least once every 30 days, users won't be seeing the prompt or have to visit social.example as a first party ever again.

How does this new feature "Iframes maintain storage access through same-site navigations to allow re-render after access to login state" (from https://twitter.com/johnwilander/status/1243231094767403008) fit in here? Based on my understanding of your comment here (not the tweet), it seems like we shouldn't have to worry about same-site navigations inside an iframe losing storage access. (Unless, I guess, the navigation happens 30 days after storage access is granted in that iframe).

[johnwilander]

@johnwilander It sounds like in the kind of use case where a user interacts with the embed at least once every 30 days, users won't be seeing the prompt or have to visit social.example as a first party ever again.

How does this new feature "Iframes maintain storage access through same-site navigations to allow re-render after access to login state" (from https://twitter.com/johnwilander/status/1243231094767403008) fit in here? Based on my understanding of your comment here (not the tweet), it seems like we shouldn't have to worry about same-site navigations inside an iframe losing storage access. (Unless, I guess, the navigation happens 30 days after storage access is granted in that iframe).

Maintained storage access through same-site navigations in the iframe that was granted access is shipping behavior in WebKit.

[hober]

@johannhof to make some spec edits for this.

[acceleratorlastorder]

Hi.

Sorry to reopen this, following mpirog-hw example ISV usually integrate other company solution and often doesn't want to prompt the user to go onto the third party in a first party context, I currently work for a electronic signature company that can be integrated by our client, currently we're having an issue due to this blocking (on safari) the authentication token to be saved as a cookie, unfortunately our client does not want to redirect theirs own client outside of theirs solution.

In any case we did try a POC integrating this, the user is prompted to click up to 4 times!,

• First time for the "requestStorageAccess"
• Then when being redirected onto the embedded domain in a first party context (if storage access can't be granted) the user is again asked for the second time to click on a button to redirect onto the previous page(the ISV website)
• Third this time the embedded domain has been visited as first party so we can ask again the permissions with "requestStorageAccess"
• Finally the browser itself asks the user to allow or not the storage access
• From here we can refresh the page and have the access to the cookie

As you can see this is really heavy, especially for the mainstream user. What would be the best solution in this case?

[johannhof]

This is blocked on #122 telling us how storage access state would be persisted, e.g. between same-site navigations in a single iframe (presumably on the browsing context for per-frame).