Bug 279153 – iOS 18 does not allow a client application to specify SameSite=None

• Component: New Bugs
• Status: RESOLVED FIXED

[Kate Chon]

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?

[Charlie Wolfe]

Thank you for reporting this. I have been able to reproduce the issue and am looking into it.

[Radar WebKit Bug Importer]

<rdar://problem/135312438>

[Kate Chon]

Thanks!

[Charlie Wolfe]

Pull request: https://github.com/WebKit/WebKit/pull/33164

[Kate Chon]

!!!! THANK YOU SO MUCH!! 

Going through the commit, could you confirm the expectation is for app owners to add the new attribute with a string of "none" as shown below (swift)

```swift
let cookieProperties: [HTTPCookiePropertyKey: Any] = [
    .domain: "auth.organization.com",
    .path: "/",
    .name: "sampleCookie",
    .value: "sampleValue",
    .secure: "TRUE",
    .sameSitePolicy: "none",
]
```

If so, I can communicate this back to app owners so they can prepare an app build with the change.

[EWS]

Committed 283230@main (45ce92c14115): <https://commits.webkit.org/283230@main>

Reviewed commits have been landed. Closing PR #33164 and removing active labels.

[Charlie Wolfe]

(In reply to Kate Chon from comment #5)
> Going through the commit, could you confirm the expectation is for app
> owners to add the new attribute with a string of "none" as shown below

Correct.

[Kate Chon]

Thanks!!! 💜💜

[EWS]

Committed 280938.311@safari-7619-branch (3b7cd3b4db5a): <https://commits.webkit.org/280938.311@safari-7619-branch>

Reviewed commits have been landed. Closing PR #1700 and removing active labels.

[WebKit Commit Bot]

Re-opened since this is blocked by bug 280080

[Alexandre Côté]

When do we expect this fix to land?

If you open a Web console and try: 

```
document.cookie = "foo=bar;Path=/;SameSite=None;Secure"
```

Safari will not respect the `SameSite` attribute.

[Alexandre Côté]

Seems to be reverted here: https://github.com/WebKit/WebKit/commit/f30d4606699e8d9b5fbe2bb043c95bd8ff5fb9fa

[Kate Chon]

Hey Alexandre Côté our teams have been able to verify the issue is resolved on iOS 18.1 beta 5. Due to the re-opening of this ticket, it's unclear if we'll be able to expect this change to make it to general release.

[Gareth Shapiro]

Hi.  Like others here I am very interested in what will be possible regarding SameSite attribute in iOS 18.1

We are seeing significant customer impact and currently it's quite difficult to provide assurance where I need to that a resolution is being planned for.

Comment #4 here :

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

makes reference to a scripting engine bug.

Ask:
It would be very useful to know whether it will be possible to successfully set `SameSite=None;Secure` from an iOS app running on 18.1 on webkit using the scripting engine once 18.1 goes into production.

Having this information up front would be particularly useful given the time it takes to assemble and get enterprise apps out the door.

[[e-mail]]

Hi, We also having the same issue with the current 18.0 version across multiple clients, and it looks like it's resolved on 18.1 beta 5. Could we get confirmation on whether the current behavior will be the same as in the planned release version.

[Charlie Wolfe]

SameSite=None cookies by default have been restored in iOS 18.0.1. Please verify that your issues are resolved there.

[Kate Chon]

Hello Charlie! Thank you so much on the update! Our teams have been able to verify impact has been mitigated. I hope you have a beautiful and lovely rest of your day!