| Summary: | Cookies can be sent to a 3rd party context | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Eric Lawrence (MSFT) <ericlaw> | ||||
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED INVALID | ||||||
| Severity: | Normal | CC: | wilander | ||||
| Priority: | P2 | ||||||
| Version: | Safari 13 | ||||||
| Hardware: | Mac | ||||||
| OS: | macOS 10.15 | ||||||
| Attachments: |
|
||||||
|
Description
Eric Lawrence (MSFT)
2020-03-25 10:11:36 PDT
Thanks so much for filing, Eric! We appreciate developers and other browser engineers having a look at our features and letting us know about any unexpected behavior or bugs. I did testing with your test rig and I believe you are hitting our temporary compatibility fix for popups. If a debugtheweb.com window is opened from enhanceie.com via window.open(), and the debugtheweb.com child window gets user interaction, third-party cookie access is opened up for debugtheweb.com under the parent page from enhanceie.com. This is to allow legacy federated login flows to still work and originally shipped in 2018 (see "Temporary Compatibility Fix: Automatic Storage Access for Popups" in https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/) and was later restricted with the user interaction requirement in the popup/child window (see "Removed Compatibility Fix for Popups" in https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/). This compatibility measure has also been added to the explainer in the standardization process of the Storage Access API: https://github.com/privacycg/storage-access/blob/master/README.md#compatibility-measure With this information, could you confirm that what you're seeing is expected behavior? Thanks! Thanks, John! I'll play with this a bit more, but it certainly does sound like the window.open() accommodation. I tried enabling the ITP debug mode but I wasn't sure where the "Filter" option is in the console (as documented here: https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/)-- Are these still the right steps for the latest version of Safari? (In reply to Eric Lawrence (MSFT) from comment #2) > Thanks, John! I'll play with this a bit more, but it certainly does sound > like the window.open() accommodation. Thanks! > I tried enabling the ITP debug mode but I wasn't sure where the "Filter" > option is in the console (as documented here: > https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/)-- Are > these still the right steps for the latest version of Safari? I've always had best luck with Terminal filtering: log stream -info | grep ITPDebug Yes, it looks like this is the compat accommodation; the first time I refresh the page, I see: 2020-03-25 14:41:09.503790-0500 0xe1de Info 0x0 1501 0 com.apple.WebKit.Networking: (WebKit) [com.apple.WebKit:ITPDebug] [Temporary combatibility fix] Storage access was granted for debugtheweb.com under opener page from enhanceie.com, with user interaction in the opened window. Note: " [Temporary combatibility fix] " has what looks like a funny typo. :) So, based on this, I think you can resolve this as "Working as Intended" (In reply to Eric Lawrence (MSFT) from comment #4) > Yes, it looks like this is the compat accommodation; the first time I > refresh the page, I see: > > 2020-03-25 14:41:09.503790-0500 0xe1de Info 0x0 > 1501 0 com.apple.WebKit.Networking: (WebKit) > [com.apple.WebKit:ITPDebug] [Temporary combatibility fix] Storage access was > granted for debugtheweb.com under opener page from enhanceie.com, with user > interaction in the opened window. > > > > Note: " [Temporary combatibility fix] " has what looks like a funny typo. :) That is indeed funny. Issue of the day! > So, based on this, I think you can resolve this as "Working as Intended" Thanks! |