[Webkit-unassigned] [Bug 237474] Safari ITP deleting same site cookies when Service Worker in place

[bugzilla-daemon at webkit.org]

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

--- Comment #3 from erik.witt at baqend.com ---
Hey John! Thanks for the quick reply, really appreciate it! Thanks also for the clarifications on ITP.

Few points:
The Private Relay point got mixed up: With Private Relay the issue does NOT occur, only without it.
Calendar time vs. days of use is interesting but I think it is the same in this scenario. We only take the time between user sessions on the page and round down to days of absence.
At the moment the cookie is read from JS but there is certainly a solution where the cookie is set to HTTP-only. Unfortunately that is not under our direct control. I am certain it is NOT written from JS though. Regarding security, the cookie only lists AB test groups assigned to the user, no authentication or tokens.

The point with CNAME Cloaking Defense sounds pretty interesting when I think about it (have glanced over that before when reading up on ITP).

The reason why I think this is interesting:

As always with these kinds of issues, I have left out a few details in the description above to simplify to what I thought were the main points.

The Service Worker does one thing that I did not mention, that might be interesting here:
When the navigate (HTML) request gets to the Service Worker, it is forwarded to the network unchanged (mostly unchanged, see [1]). The response that comes back contains the AB test cookie on every navigation, so the browser should store it every time (even though the value does not change)
On some navigations though, the Service Worker will issue another request in parallel that will fetch a cached version of the HTML response from a different endpoint (different domain as the page). This cached response contains a static version of the HTML and the response has no cookies associated with it at all. This response will be sent back to the browser if it is faster than the original navigate request (which is very likely as it is cached in CDN node).
If the browser receives the HTML from the different domain, the original navigate response is held in the Service Worker until a special XHR request is received from the page. That XHR request gets the original navigate response (because it then inserts the personalized bit from that HTML into the DOM - that should not really matter for the issue at hand)

You probably understand why I left that bit out as it complicates things a bit as is might be important I wanted to update you on that.

Now, I don't really see CNAME cloaking in effect here since the original navigate request is fetched unchanged (mostly unchanged, see [1])
 and cookies should be applied in the browser once the Service Worker receives the response (it is not necessary for the Service Worker to hand it back to the browser as the response to the navigate is it), right? 


[1]: we used to send the request completely unmodified to the network but since identifying another bug in Safari, we need to copy the request object before sending it to ensure same site lax cookies are sent always: https://bugs.webkit.org/show_bug.cgi?id=232440

-- 
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/20220304/803b21d5/attachment-0001.htm>