Everything

php

[RFC] [Discussion] CHIPS

php.internals

Dmitry Derepko

1 year ago

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

1 year ago

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 Düsterhus

1 year ago

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] https://externals.io/message/127834

Claude Pache

1 year ago

> 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,

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.

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?

—Claude

Niels Dossche

1 year ago

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 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