[PHP-DEV] [RFC] [Discussion] CHIPS

Dmitry_Derepko · July 15, 2025, 10:09am

Hi internals,

In collaboration with Niels Dossche I’d like to start the discussion for an RFC proposing a new Cookie option for use with CHIPS technology.

As Niels noted, today is the day when in 4 weeks there will be code freeze, so let’s try to fit into the lines and deliver the value to PHP 8.5.

RFC: https://wiki.php.net/rfc/chips
Implementation: https://github.com/php/php-src/pull/12652
Previous discussions: https://externals.io/message/127902, https://externals.io/message/122028

···

Best regards,

Dmitrii Derepko.
@xepozz

Derick_Rethans · July 16, 2025, 12:31pm

On Tue, 15 Jul 2025, Dmitry Derepko wrote:

In collaboration with Niels Dossche I'd like to start the discussion
for an RFC proposing a new Cookie option for use with CHIPS
technology.

As Niels noted, today is the day when in 4 weeks there will be code
freeze, so let's try to fit into the lines and deliver the value to
PHP 8.5.

I'm not so keen on trying to rush things before meeting a deadline, but
I think that this addition seems entirely reasonable.

cheers,
Derick

Tim_Dusterhus · July 16, 2025, 1:53pm

Hi

As Niels noted, today is the day when in 4 weeks there will be code
freeze, so let's try to fit into the lines and deliver the value to
PHP 8.5.

I'm not so keen on trying to rush things before meeting a deadline, but
I think that this addition seems entirely reasonable.

I agree on both of these points. The RFC appears well-researched (including the support for sessions, which I would likely not have thought of myself) and has a very straight forward implementation, since it's just extending an existing API based on an external standard, making it reasonably risk-less.

As to the RFC text itself, I like how carefully the “RFC Impact” section of the updated RFC template [1] has been filled in. I don't have any other remarks, except LGTM

Best regards
Tim Düsterhus

[1] RFC Template updates - Externals

Claude_Pache · July 18, 2025, 2:15pm

Le 15 juil. 2025 à 12:09, Dmitry Derepko xepozzd@gmail.com a écrit :

Hi internals,

In collaboration with Niels Dossche I’d like to start the discussion for an RFC proposing a new Cookie option for use with CHIPS technology.

As Niels noted, today is the day when in 4 weeks there will be code freeze, so let’s try to fit into the lines and deliver the value to PHP 8.5.

RFC: https://wiki.php.net/rfc/chips
Implementation: https://github.com/php/php-src/pull/12652
Previous discussions: https://externals.io/message/127902, https://externals.io/message/122028

Hi,

The RFC says: “CHIPS technology was introduced not so long ago, but still has “little” adoption (currently “only” available in Blink-based browsers).”

It might be useful to add the following precisions, so that we are more confident that it has good chance not to remain a Blink-only feature:

As of time of writing, there is an experimental implementation in Firefox.
The feature has also been implemented in Safari, but has been temporarily disabled because of an issue known by Apple only.

All examples in the RFC are variations on setcookie("name", "value", ["secure" => true, "partitioned" => true]);, without same-site attribute.

As partitioned cookies are only meaningful as third-party cookies, what is the behaviour when:

(a) the same-site attribute is set to anything different from “None”?
(b) the same-site attribute is omitted? (Although historically, omitting the same-site parameter is equivalent to setting it to “None”, browser vendors are willing to switch the default to “Lax”, and some browsers (including Blink-based ones) have already done the switch.)

In all examples I’ve seen on the web, an explicit samesite=None attribute is added to partitioned cookies, probably for some good reason?

—Claude

Niels_Dossche · July 20, 2025, 9:14am

On 18/07/2025 16:15, Claude Pache wrote:

Hi,

Hi Claude

1. The RFC says: “CHIPS technology was introduced not so long ago, but still has “little” adoption (currently “only” available in Blink-based browsers).”

It might be useful to add the following precisions, so that we are more confident that it has good chance not to remain a Blink-only feature:
* As of time of writing, there is an experimental implementation in Firefox.
* The feature has also been implemented in Safari, but has been temporarily disabled because of an issue known by Apple only.

Sure! Those are good points to clarify the introduction. Thanks!

2. All examples in the RFC are variations on `setcookie("name", "value", ["secure" => true, "partitioned" => true]);`, without same-site attribute.

As partitioned cookies are only meaningful as third-party cookies, what is the behaviour when:

(a) the same-site attribute is set to anything different from "None"?
(b) the same-site attribute is omitted? (Although historically, omitting the same-site parameter is equivalent to setting it to "None", browser vendors are willing to switch the default to "Lax", and some browsers (including Blink-based ones) have already done the switch.)

In all examples I’ve seen on the web, an explicit `samesite=None` attribute is added to partitioned cookies, probably for some good reason?

Yep, all examples use "samesite=None" because you need that to create a 3rd party cookie. So including "Partitioned" without "samesite=None" is useless in those cases.
Although if "samesite=Lax" is still the default for a particular browser, then it won't be useless, but I believe the goal is - as you said - to switch all browsers over to "samesite=None".
According to GitHub - privacycg/CHIPS: A proposal for a cookie attribute to partition cross-site cookies by top-level site, the following will happen:

(a) The cookie won't be sent to a 3rd party context and "Partitioned" won't have an effect. The cookie header is still interpreted correctly so it will have an effect on the origin site, just not in a 3rd party context.
(b) Depends on what the default is for a particular browser.

Kind regards
Niels