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

• Status: NEW
• Component: Frames

[Kelvin Liu]

Brief Description:
In a nested iframe setup (2 levels deep), the *top* frame must open a window (with same origin as the nested iframe) to get user interaction before access is granted to the innermost iframe. Popups from intermediate iframes cannot be used to grant access.

Background scenario - 1 level nesting - This case works as expected:

- top frame www.site0.com contains iframe www.site1.com
- iframe is initially denied storage access
- a button on top frame opens popup window with a page on www.site1.com (popup is in 1st-party context)
- user interacts with popup (clicks a link). Thereafter, an event handler causes it to close
- iframe now has storage access

Bug scenario - 2-level nesting - This does not work as expected:

- top frame www.site0.com contains iframe-L1 www.site1.com (L1 = level 1 nesting)
- iframe-L1 (www.site1.com) contains iframe-L2 www.site2.com
- iframe-L2 is initially denied storage access
- a button on iframe-L1 opens popup window with a page on www.site2.com (popup is in 1st-party context) <== this is the key step
- user interacts with popup (clicks a link). Thereafter, an event handler causes it to close
- iframe-L2 is still denied storage access (expected: it should be granted access)

More info: if the same popup is opened by the top frame instead of iframe-L1, iframe-L2 is correctly granted access.


Real-life use case: Google AMP.
- www.google.com is the top frame, and it contains an iframe to a CDN-proxied page of my company's newspaper site ("cdn-proxy").
- cdn-proxy page contains an iframe that performs entitlements checking ("subscribe" site).
- cdn-proxy page has a button/link that opens a popup window to a page on the subscribe site.

We expected interaction on the popup to grant access to the nested iframe containing the subscribe site page, but the grant doesn't occur (e.g. cookies are unreadable). However, if I use the browser devtools to open the same popup from the top frame, access *is* granted.

Due to constraints of the AMP platform, we have no control over the top page, and very little control over the button on the cdn-proxed page.

[Radar WebKit Bug Importer]

<rdar://problem/70904696>

[John Wilander]

Hi! Storage access granted through mere interaction with a popup is a temporary compatibility measure and not something we intend to build on further. It will go away all together eventually.

Have you tried calling the Storage Access API?

[Kelvin Liu]

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.

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.

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

Thanks!

[John Wilander]

(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

[John Wilander]

Another thing to note is that third-party LocalStorage is partitioned and ephemeral. I.e. the third-party gets a unique LocalStorage instance per first-party and the LocalStorage is deleted on browser quit.

[Florian Schulz]

(In reply to John Wilander from comment #5)
> Another thing to note is that third-party LocalStorage is partitioned and
> ephemeral. I.e. the third-party gets a unique LocalStorage instance per
> first-party and the LocalStorage is deleted on browser quit.

Does this also apply to First-Party scenarios, where "foo.site.com" embeds an iframe to "bar.site.com" where the iframe uses IndexedDB? In my case, the same-site iframe gets treated with partitioned + ephemeral storage.