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
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
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
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
Hi,
Hi Claude
- 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!
- 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=Noneattribute 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 https://github.com/privacycg/CHIPS, 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