Bug 278353 – Update remaining tests to conform to new SameSite=Lax by default cookie behavior

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Charlie Wolfe]

http/tests/privateClickMeasurement/send-attribution-conversion-request.html fails on iOS 18 and macOS Sequoia because it relies on SameSite=None cookies. Explicitly setting SameSite=None and Secure in `document.cookie` doesn't appear to work in the test runner, for an unknown reason.

[Charlie Wolfe]

http/tests/resourceLoadStatistics/do-not-remove-blocking-in-redirect.html and http/tests/resourceLoadStatistics/set-all-cookies-to-same-site-strict.html seem to have a similar issue.

[Radar WebKit Bug Importer]

<rdar://problem/134733247>

[Kate Chon]

Hi! Our customer's appear to be impacted by this issue and wanted to check-in to get a bit more clarity on if the "unknown reason" has been identified. 

The issue we're encountering on iOS 18 is our in-house mobile app is injecting 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.

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`. We had been suspecting and received confirmation iOS 18  includes a WebKit commit to change the default cookie behavior to be `SameSite=Lax` when the attribute is missing (aside: pure speculation we suspect this is w.r.t https://bugs.webkit.org/show_bug.cgi?id=198181#c4 and https://datatracker.ietf.org/doc/html/draft-west-cookie-incrementalism-00#section-1).

With debugging we have data-points WebKit is honoring the cookie's SameSite=None attribute when the cookie is set by server in this case the IdP. However, attempts to set this attribute from the client side (from the app interacting with the iOS cookie store) have been unsuccessful. There is a curious datapoint where using the Safari Web Inspector shows the option to set the cookie's SameSite attribute to None, it however, does not get honored either. 

I would be curious if there's any updates on this bug and if the issue would be related to the cookie behavior observed within an iOS application? thanks in advance!

[Charlie Wolfe]

(In reply to Kate Chon from comment #3)
> Hi! Our customer's appear to be impacted by this issue and wanted to
> check-in to get a bit more clarity on if the "unknown reason" has been
> identified. 
> 
> The issue we're encountering on iOS 18 is our in-house mobile app is
> injecting 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.
> 
> 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`. We had been suspecting and
> received confirmation iOS 18  includes a WebKit commit to change the default
> cookie behavior to be `SameSite=Lax` when the attribute is missing (aside:
> pure speculation we suspect this is w.r.t
> https://bugs.webkit.org/show_bug.cgi?id=198181#c4 and
> https://datatracker.ietf.org/doc/html/draft-west-cookie-incrementalism-
> 00#section-1).
> 
> With debugging we have data-points WebKit is honoring the cookie's
> SameSite=None attribute when the cookie is set by server in this case the
> IdP. However, attempts to set this attribute from the client side (from the
> app interacting with the iOS cookie store) have been unsuccessful. There is
> a curious datapoint where using the Safari Web Inspector shows the option to
> set the cookie's SameSite attribute to None, it however, does not get
> honored either. 
> 
> I would be curious if there's any updates on this bug and if the issue would
> be related to the cookie behavior observed within an iOS application? thanks
> in advance!

Hi. SameSite=Lax cookies by default is indeed an intentional change in iOS 18 and macOS Sequoia betas. This bugzilla is intended to track updating WebKit tests to conform to this new cookie behavior.

I am aware of an issue affecting `SameSite=None; Secure` cookies set through JavaScript, which has been identified in a system component outside of WebKit. If you believe you may be seeing another issue, please file a bug with steps to reproduce and CC me.

[Charlie Wolfe]

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

[Kate Chon]

Thanks for the update! I'll go ahead and create a separate bug report for the issue we're observing. Question on the below,

> which has been identified in a system component outside of WebKit.

do you know if there a link where we can follow up and track this?

[Kate Chon]

New bug report describing the issue with iOS apps has been created here https://bugs.webkit.org/show_bug.cgi?id=279153

[EWS]

Committed 283184@main (ff52f4cf8be7): <https://commits.webkit.org/283184@main>

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