[Webkit-unassigned] [Bug 218396] ITP doesn't grant storage access to nested iframe unless first-party interaction is prompted by top frame

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from John Wilander <wilander at apple.com> ---
(In reply to Kelvin Liu from comment #3)
> Thanks for the quick reply. I don't think we can use Storage Access API. As
> I understand it, that API requires the iframe which requests access to be
> visible so that the request can be triggered via a user interaction in that
> iframe (e.g. click a button).
> The AMP framework hides our iframe, so interaction is impossible - AMP uses
> postMessage to communicate with it.

If a framework is making your site a third party when in reality it is the first party, I'd say that's a problem with the framework. 

> Since the Storage Access API probably won't work for us, I plan to use
> `fetch` to communicate with the server instead, using a token that the
> iframe has access to.
> 
> ==> My question in this case is: can I rely on the iframe's localStorage to
> continue to be capped at 7 days, or will this be further restricted in the
> near future? I plan to use this as a temporary cache so I won't need to
> fetch from the server so often.

The restriction is 7 days of Safari use *since the last user interaction as first party*. If your website is only rendered as a third-party in the particular browser instance, it will continuously be at 0 days since user interaction as first party.

> ==> Is there a roadmap for ITP that I can view to anticipate changes?

The purpose of ITP is to prevent cross-site tracking so it has to go where trackers go. A good rule of thumb is that if you have found some way to access the user's identity across websites without the user opting in, that capability is likely to change in the future.

There is a longer term effort that we are working on in the W3C Privacy CG called IsLoggedIn. One of our intentions with IsLoggedIn is to be able to protect website data from deletion where the user is logged in. You can take part in the work here: https://github.com/privacycg/is-logged-in

-- 
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/20201102/aa315ddb/attachment-0001.htm>