[Webkit-unassigned] [Bug 198181] Cookies with SameSite=None or SameSite=invalid treated as Strict

[bugzilla-daemon at webkit.org]

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

--- Comment #42 from John Wilander <wilander at apple.com> ---
(In reply to Deniss Kozlovs from comment #41)
> The problem is, "None" should not be treated as "Strict" because they have
> opposite meanings. "Strict" means that cookie will not be transferred to
> third-party, and not be transferred back when returning from third-party
> domain.
> "None" means default behavior that existed since 1997.
> 
> This now requires a dirty hack (by using regex to parse user agent) to be
> made when setting session parameters in the backend, because Chrome now
> requires SameSite=None when using cross-domain redirects back and forth (for
> example, making payments).

Browsers are allowed to set a cookie policy, i.e. there is no mandate to have cookies be accepted in all cases. The default cookie policies of for example Safari, Firefox, and Chrome all differ.

The default cookie policy in Safari since 2003 has been to not allow third parties without pre-existing cookies to set new cookies. In 2017, Safari shipped Intelligent Tracking Prevention (ITP) which then blocked classified third parties from using cookies. In 2020, ITP was updated to block *all* third party cookies.

Other browsers built on WebKit may have other default cookie policies.

The SameSite=lax by default change was driven by the Chrome team and is not in effect in Safari. SameSite=none support was added to Safari in 2019. SameSite=none is not a way to unblock third party cookies in Safari. If you need access to cookies as a third party in Safari, you need to call 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/20200911/c7b5cb81/attachment.htm>