[Webkit-unassigned] [Bug 217670] Safari blocking third party iframe cookies

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=217670

--- Comment #3 from John Wilander <wilander at apple.com> ---
(In reply to Amol Patel from comment #2)
> Thanks for getting back John. So just to clarify, our use case will probably
> not work correct? By that I mean allowing an iframe to set cookies without
> user interaction? There is no way to get around the user interaction
> requirement even if we prompt the user to give us access?

First, third-party content, including iframes, have never been able to set cookies under default settings in Safari unless they have “seeded” their cookie jar as first party.

Second, your iframe *cannot* prompt the user for storage access unless it has received user interaction as first party the last 30 days of Safari use. Some websites load resources from in the order of a hundred different third-parties. If they were all allowed to prompt the user for storage access, we’d likely end up with an unusable web.

The intention of the Storage Access API is to allow for authenticated embeds. This means the user has already logged in to the website as first party and now the embedded content needs access to the authentication state.

> I also wanted to bring up something we found during testing. Described below:
> 
> We created a parent page that contained an iframe with a different domain.
> We had JS on the iframed child page that would attempt to set a cookie on
> the document. It was being blocked as expected. We introduced storage access
> which then prompted the user to accept/deny. We clicked deny. We cleared all
> cookies/browser history, and started from scratch. We attempted to visit the
> parent page again and every request for storage access was immediately
> blocked until we visited the child page in a first party context. Is that
> expected? It seems like it might be a poor user experience especially if the
> user accidentally clicked deny.

Clearing browsing history clears cookies and the browsers “memory” of which sites the user has interacted with. This means 1) the user cannot be logged in to the embedee and needs to go to that website and log in, and 2) the requirement to have interacted with the embedee as first party website is no longer fulfilled and thus it cannot request storage access.

If the user accidentally clicks deny, they can just try again. The iframe gets two tries as it’s currently implemented. This may change because there are bad actors already misusing the API to pressure users to grant access. All of that is being discussed in the standards GitHub repository since it’s a cross-browser concern.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201015/0eba5fc4/attachment-0001.htm>