[Webkit-unassigned] [Bug 196852] Unchecked "Prevent cross-site tracking" option behaves incorrectly

[bugzilla-daemon at webkit.org]

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

--- Comment #5 from John Wilander <wilander at apple.com> ---
(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.

-- 
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/20190412/f7875769/attachment.html>