[Webkit-unassigned] [Bug 217134] StorageApi mismatch between WKWebView vs Safari in iOS 14

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from John Wilander <wilander at apple.com> ---
(In reply to Spambit from comment #2)
> I made xhr to third-party domain from http:127.0.0.1 and received cookies in
> WKWebView. I saw those in xhr-response in web-inspector. But I noticed those
> cookies never reached third-party server in subsequent network calls from
> iframe or even another xhr from http://127.0.0.1. I saw same behaviour with
> ITP off. I read that WKWebView now blocks all third-party cookies. Does this
> mean it won't send cookies to different domain other than 127.0.0.1 even
> when ITP is off? My original question was on mismatch behaviour in desktop
> safari and WkWebView. That stays same. I saw everything I explained above
> works fine in desktop safari as it should be according to me even with
> storage apis. But, I could not make it working in iOS safari and WKWebView.
> Anyway, to answer your question, if I set third-party cookie in first-party
> context, it does not work either with ITP on/off. However, my third-party
> domain was never first-party at all. There had been only xhr calls to
> third-party domain.

My understanding is that you see a Set-Cookie header in the HTTP response to your XHR. But do you see that cookie being accepted? When cookies are blocked, they still show up on responses but don't get accepted. Cookies that have been accepted should show up in the Storage –> Cookies pane in Web Inspector.

The mismatch you might be seeing here is that the "Prevent cross-site tracking" setting in Safari controls *both* ITP and the underlying cookie policy.

However, there has never been a user setting to control the cookie policy in WKWebViews. The change in iOS 14 that we're talking about is that ITP is enabled by default and that users can turn it off. The underlying cookie policy has not changed.

I suspect that what you're describing has never worked in WKWebView. The cookie policy says that a response to a third-party request can only set cookies if the third-party has set its initial cookie(s) as *first-party*. This used to be called "Accept cookies for sites I visit" in Safari's settings pre-ITP.

-- 
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/20201007/e6640a6d/attachment-0001.htm>