Bug 206295

Summary: Third-party cookies blocked when "Prevent cross-site tracking" is disabled
Product: WebKit Reporter: Jixia Dai <jdai>
Component: WebKit APIAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: katherine_cheney, webkit-bug-importer, wilander
Priority: P2 Keywords: InRadar
Version: Safari 13   
Hardware: Mac   
OS: macOS 10.14   

Description Jixia Dai 2020-01-15 09:50:59 PST 
When a user disables "Prevent cross-site tracking", hasStorageAccess API still returns TRUE and the access to third-party storage is always blocked. 

Steps to reproduce:
  1. Testing with Safari 13.0.4 on Mac OS 10.14;
  2. Login to google.com and create a new Google Doc at https://docs.google.com/document/create, which will be redirected to a /edit page;
  3. Create an HTML page doc.html to embed the new Google Doc:
       <!DOCTYPE html>
       <meta charset="UTF-8">
       <html>
         <body>
           <iframe src="<Google Doc /edit url>" width=800px height=600px></iframe>
         </body>
       </html>
  4. Serve the HTML page locally at localhost:8000;
  5. Make sure "Prevent cross-site tracking" is enabled in Safari privacy settings;
  6. Load http://localhost:8000/doc.html. This should load a "Google Docs needs access" page that allows user to grant 3p cookie access for Google Docs. The Google Doc can be loaded if user agrees to grant access.
  7. So far, everything is expected;
  8. Disable/Uncheck "Prevent cross-site tracking" in Safari privacy settings;
  9. Reload http://localhost:8000/doc.html. This results in an error page. Basically, hasStorageAccess returned TRUE and Google Docs tried to reload itself and it failed due to the lack of credentials.
  10. We also noticed that requestStorageAccess always gets rejected when "Prevent cross-site tracking" is disabled.

It seems that when "Prevent cross-site tracking" is disabled, user will never be able to allow 3p cookies. I am not sure if this is intended behavior. If it is, it probably should be documented and hasStorageAccess should return FALSE instead. 

Additionally, this behavior is probably introduced in 13.0.4 and I think that previous Safari 13 versions worked properly either when "Prevent cross-site tracking" is on or off.
Comment 1 Radar WebKit Bug Importer 2020-01-15 15:19:17 PST 
<rdar://problem/58621877>
Comment 2 John Wilander 2020-01-15 15:27:11 PST 
Thanks for the report.

What happens if you restart Safari after you disable "Prevent cross-site tracking"?
Comment 3 Jixia Dai 2020-01-15 18:15:08 PST 
Thanks for getting on this so quickly. Restarting Safari does not affect the outcome.
Comment 4 John Wilander 2020-01-16 10:53:29 PST 
We are fairly confident this is a duplicate of a bug that was reported on WKWebView for iOS. It is already fixed in the next minor version of macOS which I believe went out in beta mid-December. If you have a chance to test there, please do.

If you're interested in details, please see the duplicate bug.

*** This bug has been marked as a duplicate of bug 204109 ***
Comment 5 Jixia Dai 2020-01-18 17:58:53 PST 
Thanks! I have verified with Safari Technology Preview (Version 13.1) that 3p cookies are allowed when ITP is disabled.