Implement proof-of-concept partitioned option for setcookie

[nielsdos]

No description provided.

[iluuu1994]

Partitioned cookies are marked as experimental by Mozilla (https://developer.mozilla.org/en-US/docs/Web/Privacy/Partitioned_cookies). Theoretically this means they are subject to change. It seems they're mostly pushed by Google.

I'm also unsure about the premise of the original issue:

As stated here (link), soon our cookies with SameSite=None; Secured, without the Partitioned parameter, will stop working.

I haven't tested this, but I think what this means is that Partitioned will essentially become the default, unless the domains are part of the same related website set. So I think this is essentially just an opt-in mechanism to ensure the cookies keep working? Related website sets are managed in a GitHub repository (https://github.com/GoogleChrome/related-website-sets). Thank you, Google, for that one. 😒

Maybe this warrants a short e-mail to the ML? I'm not a specialist in regards to cookies. Maybe other people have something to add.

[DustinAPI]

@nielsdos I am attempting to implement CHIPS for my app with an ugly workaround manually setting the cookie header so this PR would be very helpful but I think it should also include changes to the session cookie to truly allow developers to fix the problem.

session_set_cookie_params(['partitioned' => true])
['partitioned' => true]) = session_get_cookie_params()
ini_set('session.cookie_partitioned', 'on');

My use case is the most basic wherin my app (tool) is displayed in an iframe within a learning management system (LMS) and requires a session cookie for further interaction after the inital LTI launch.

[morsssss]

Partitioned cookies are marked as experimental by Mozilla (https://developer.mozilla.org/en-US/docs/Web/Privacy/Partitioned_cookies). Theoretically this means they are subject to change. It seems they're mostly pushed by Google.

AFAIK, Mozilla and Safari have experimented with similar ideas, but right now only Chrome supports the Partitioned attribute. Chrome's goal is to let developers opt in to partitioning, instead of doing it by default.

As stated here (link), soon our cookies with SameSite=None; Secured, without the Partitioned parameter, will stop working.

I haven't tested this, but I think what this means is that Partitioned will essentially become the default, unless the domains are part of the same related website set. So I think this is essentially just an opt-in mechanism to ensure the cookies keep working?

That's it indeed! Chrome just started an experiment, now active for 1% of users, in which it will block third-party cookies that lack the Partitioned attribute and that are not allowed by other means. When a third-party site sets a Partitioned cookie, Chrome allows that site to access the cookie when it's embedded on a page from the domain where it was set. Access from other domains is blocked.

If this experiment results in a launch down the road, I think plenty of developers will want to use Partitioned, even though right now it's only a Chrome thing.

[nielsdos]

@nielsdos I am attempting to implement CHIPS for my app with an ugly workaround manually setting the cookie header so this PR would be very helpful but I think it should also include changes to the session cookie to truly allow developers to fix the problem.

session_set_cookie_params(['partitioned' => true]) ['partitioned' => true]) = session_get_cookie_params() ini_set('session.cookie_partitioned', 'on');

My use case is the most basic wherin my app (tool) is displayed in an iframe within a learning management system (LMS) and requires a session cookie for further interaction after the inital LTI launch.

Yeah, I fear that the scope of this must be increased, and ini settings are probably necessary too.
That would mean this needs an RFC, which I can do, but I'm busy with other PHP work right now.

[bukka]

I think we should probably have RFC for this as the agreement is not clear (Derick raised some concerns on internals) so I don't think we can just merge this.