196852 2019-04-11 23:30:11 -0700 Unchecked "Prevent cross-site tracking" option behaves incorrectly 2024-03-11 09:20:34 -0700 1 1 1 Unclassified WebKit WebKit Misc. Safari 12 Mac macOS 10.13 NEW InRadar P2 Normal --- 1 r+webkit webkit-unassigned ahmad.saleem792 ap bfulgham webkit-bug-importer wilander oldest_to_newest 1526661 0 r+webkit 2019-04-11 23:30:11 -0700 The "Prevent cross-site tracking" option in Safari is either misnamed, or behaves incorrectly when unchecked. When unchecked, all storage API requests are rejected automatically, so cross-site iframes stop working altogether. I was expecting the storage API to always grant storage access with this option unchecked. 1526806 1 webkit-bug-importer 2019-04-12 10:34:10 -0700 <rdar://problem/49855574> 1526814 2 wilander 2019-04-12 10:45:28 -0700 Thanks for your bug report. We've received at least one similar report before. I agree it should be flipped. 1526815 3 wilander 2019-04-12 10:46:59 -0700 This said, the third-party resource can always try to set a cookie and read it back to check its status. 1526852 4 r+webkit 2019-04-12 11:31:45 -0700 Thanks! Not sure I understand yet how reading back the cookie can help. You can't do it pre-storage-access-request, since cookies aren't guaranteed to work yet (if the 3rd party is classified as tracker); and it's not supposed to work in the reject handler either (which is where the unchecked option takes you), since cookies won't work anyway for potentially other reasons (the user explicitly denying access, missing first party interaction, ...)? I haven't tested what happens if the 3rd party isn't classified as a tracker, but we already do the cookie-write-read check in that case to detect the old WebKit behavior where cookies don't work if the site hasn't been opened (and used cookies) as first party yet. 1526872 5 wilander 2019-04-12 12:20:35 -0700 (In reply to r+webkit from comment #4) > Thanks! > > Not sure I understand yet how reading back the cookie can help. You can't do > it pre-storage-access-request, since cookies aren't guaranteed to work yet > (if the 3rd party is classified as tracker); and it's not supposed to work > in the reject handler either (which is where the unchecked option takes > you), since cookies won't work anyway for potentially other reasons (the > user explicitly denying access, missing first party interaction, ...)? > > I haven't tested what happens if the 3rd party isn't classified as a > tracker, but we already do the cookie-write-read check in that case to > detect the old WebKit behavior where cookies don't work if the site hasn't > been opened (and used cookies) as first party yet. If ITP is turned off, you can always set cookies. Thus, the third-party who calls hasStorageAccess() can also try to read cookies. If they're available, there's no need for calling the Storage Access API. If they're not, the third-party can try to write a cookie and read it back. If it works, either ITP is turned off or the third-party has not been classified but ITP and has existing cookies that are not exposed in document.cookie, for instance HttpOnly cookies. The reason I mention cookies not exposed in document.cookie is Safari's 10+ year old cookie policy where a domain has to set its initial cookie(s) as first-party. Otherwise it cannot use cookies as third-party, regardless of calls to the Storage Access API. 1526882 6 r+webkit 2019-04-12 12:55:37 -0700 Ah, I didn't realize it was just the access API that was rejecting requests, but that storage was still working. Your workaround looks good, thanks! 2020007 7 ahmad.saleem792 2024-03-10 19:49:44 -0700 @Alexey - if it is something need to change on Safari UI level, should we mark this as "RESOLVED MOVED"? Safari > Settings > Privacy Website tracking: Prevent cross-site tracking ____ Appreciate if you can share your input. 2020140 8 ap 2024-03-11 09:20:34 -0700 John would be a better person to answer this. It seems like we are tracking this as a WebKit issue at this point.