Bug 196852 – Unchecked "Prevent cross-site tracking" option behaves incorrectly

• Status: NEW
• Component: WebKit Misc.

[Remko Tronçon]

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.

[Radar WebKit Bug Importer]

<rdar://problem/49855574>

[John Wilander]

Thanks for your bug report. We've received at least one similar report before. I agree it should be flipped.

[John Wilander]

This said, the third-party resource can always try to set a cookie and read it back to check its status.

[Remko Tronçon]

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.

[John Wilander]

(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.

[Remko Tronçon]

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!

[Ahmad Saleem]

@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.

[Alexey Proskuryakov]

John would be a better person to answer this. It seems like we are tracking this as a WebKit issue at this point.