[Webkit-unassigned] [Bug 279153] New: iOS 18 does not allow a client application to specify SameSite=None
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Sep 4 16:04:45 PDT 2024
https://bugs.webkit.org/show_bug.cgi?id=279153
Bug ID: 279153
Summary: iOS 18 does not allow a client application to specify
SameSite=None
Product: WebKit
Version: Other
Hardware: iPhone / iPad
OS: iOS 18
Status: NEW
Severity: Blocker
Priority: P2
Component: New Bugs
Assignee: webkit-unassigned at lists.webkit.org
Reporter: chonkate at amazon.com
Context: Our organization distributes an in-house iOS application that injects an auth cookie into https://developer.apple.com/documentation/foundation/httpcookiestorage intended for our IdP (e.g. `auth.organization.com`), when the end-user navigates to (e.g. `service.alternate-domain.dev`), the service will redirect to the IdP and the expected cookie is not included in the request. This issue was first encountered with iOS 14 due to Intelligent Tracking Protection and we worked around the issue by enabling `NSCrossWebsiteTrackingUsageDescription` to allow our customers to opt-in to cross-domain cookies only within the application. Additionally, since iOS https://developer.apple.com/documentation/foundation/httpcookiestringpolicy has historically only allowed the "Lax" and "Strict" values, our application has been relying on the default behavior, when SameSite is omitted for WebKit to consider it to be `SameSite=None`.
Issue and data:
On iOS 18 beta 8 we observed the same behavior of IdP cookie no longer being included in the request and observed the below behavior (with ITP disabled):
- WebKit is honoring the cookie's SameSite=None attribute when the cookie is set by server in this case the IdP
- Attempts to set this attribute from the client side (from the app interacting with the iOS cookie store) have been unsuccessful. For example, by setting `.sameSitePolicy = "none"`
- Safari Web Inspector shows the option to set the cookie's SameSite attribute to None, it however, does not get honored either, and is immediately reverted.
Analysis:
With the data collected so far it seems there is a gap between iOS default behavior to assume WebKit is using `SameSite=None` and the new WebKit change that breaks this assumption to now use `SameSite=Lax` as the default. Because of this gap, the iOS application is no longer able to set SameSite=None breaking existing web flows.
Ask:
Our internal teams are evaluating multiple options for mitigating impact before iOS 18 release. As such we're looking to get a bit more data and opening up possible mitigation options:
- What is the purpose of introducing the backwards incompatible change for stricter cookie behavior (default SameSite=Lax) in WebKit?
- Why is the `SameSite=None` only honored when a server specifies the cookie attribute and not when the client specifies it?
- Is it feasible for WebKit to implement any of the below as a workaround
- Add `none` as an expected cookie policy in https://developer.apple.com/documentation/foundation/httpcookiestringpolicy
- Is there an alternate mechanism that would maintain the pre-existing cookie behavior for a specific application (e.g. through an Info.plist flag)
- Can the `NSCrossWebsiteTrackingUsageDescription` be updated to maintain the pre-existing default cookie behavior when SameSite attribute is omitted, in addition to disabling 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/20240904/cb7fa504/attachment-0001.htm>
More information about the webkit-unassigned
mailing list