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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Oct 30 10:35:07 PDT 2020


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

            Bug ID: 218396
           Summary: ITP doesn't grant storage access to nested iframe
                    unless first-party interaction is prompted by top
                    frame
           Product: WebKit
           Version: Safari 14
          Hardware: Macintosh
                OS: macOS 10.14
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Frames
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: kliu at tribpub.com

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.

-- 
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/20201030/158bc75c/attachment.htm>


More information about the webkit-unassigned mailing list