Re: [blink-dev] Intent to Experiment: Cookies Having Independent Partitioned State (CHIPS)

['Dylan Cutler' via blink-dev]

Hey Jingesh,

The --partitioned-cookies flag enables the partitioned cookies feature on a 
Chrome client, however only sites that are participating in the OT can use 
this feature if only this flag is enabled.

The --partitioned-cookies-bypass-origin-trial flag allows any site to use 
partitioned cookies regardless of OT participation and is meant for local 
testing. You still need to use the first flag (--partitioned-cookies) to 
enable the feature at all.

Upon inspecting the network activity of the page you linked, 
https://dim-connect.herokuapp.com/tile, I see the problem. If you wish to 
participate in the OT, then *every* network response must contain the 
Origin-Trial and Accept-CH: Sec-CH-Partitioned cookies header. If you do 
not include these headers, Chrome will revert the cookies to unpartitioned 
behavior.

Let me know if you have any additional questions,
Dylan

On Friday, April 1, 2022 at 12:48:47 PM UTC-4 Jignesh Malkan wrote:

> Hi Dylan,
>
> I am working along with Marcelo on this POC.
> We have been able to make progress.
>
> I see 2 options on chrome://flags
> partitioned-cookies & partitioned-cookies-bypass-origin-trial
> Which flag am I supposed to use?
>
> One thing I have noticed that seemed odd and wanted to see if thats an 
> expected behavior.
> We have a small dummy app that just creates a cookie foo-bar and print the 
> value in UI https://dim-connect.herokuapp.com/tile
> We embed this in iFrame in our Enterprise App.
>
> From Tab 1 - I go to https://dim-connect.herokuapp.com/tile, a cookie 
> fooBar-1 is created with Partition Key of 
> https://dim-connect.herokuapp.com
> From Tab 1 - I log in to Our Enterprise App I see a cookie fooBar-2 is 
> created with Partition Key of http://.com
>
> So far so good.
>
> Now if I go to the Tab 1 and delete cookie fooBar-1, It also seem to 
> delete cookie fooBar-2
>
> Is this expected?
>
> On Thursday, March 31, 2022 at 5:21:13 PM UTC-4 Dylan Cutler wrote:
>
>> Hey Marcelo,
>>
>> M100 is when we are starting the origin trial 
>>  for CHIPS. In order 
>> to use partitioned cookies. You must register for the trial 
>> ,
>>  
>> and have your server send the Origin-Trial and Accept-CH: 
>> Sec-CH-Partitioned-Cookies response headers to participate in the trial.
>>
>> If you wish to bypass the OT opt-in mechanism for local testing, you can 
>> enable the --partitioned-cookies-bypass-origin-trial flag in addition to 
>> the --partitioned-cookies flag. This configuration will allow partitioned 
>> cookies from any site regardless of their origin trial status.
>>
>> All of this is documented in more detail on 
>> https://chromium.org/updates/chips.
>>
>> Best,
>> Dylan
>>
>> On Thu, Mar 31, 2022 at 4:41 PM Marcelo Portugal  
>> wrote:
>>
>>> Hi,
>>>
>>> So I updated Chrome today to version 100.0.4896.60, and now, even when I 
>>> turn on the partitioned cookie flag, my cookie is not populating the 
>>> partitionKey as expected. Furthermore, when I was previously playing with 
>>> it earlier this week on version ~99, although I could see the partition key 
>>> and behavior working, the partitioned cookies would be blocked once I 
>>> changed my settings to block third party cookies. So I am unsure on whether 
>>> I am doing something wrong or if there is a defect with partitioned cookies 
>>> right now. I was trying with the following url:
>>> https://dim-connect.herokuapp.com/tile
>>>
>>> Any help would be appreciated.
>>>
>>> Regards,
>>>
>>> Marcelo
>>>
>>> On Wednesday, February 2, 2022 at 12:07:55 PM UTC-5 Daniel Bratell wrote:
>>>
 Thanks for your answers. I hope it works out fine. (You already have 
 Chris' LGTM so your experiment is ready to go)

 /Daniel
 On 2022-02-02 17:37, Dylan Cutler wrote:

 Will this be run as a third-party Origin Trial? As a Finch experiment? 
> Other?
>
 This experiment will be run as a 3P Origin Trial, 

 So, when the experiment finishes, sites that opted-in to that mode will 
> lose their cookies and their users will e.g. be logged out, etc?
> That seems like a deterrent. Is there a way around that? (e.g. migrate 
> the cookies to the default 3P behavior when the experiment is done. Not 
> sure how feasible that is..)

 The reasoning behind why we didn't do that is that partitioned cookies 
 allow the existence of multiple cookies with the same host key, name, and 
 path to exist in separate partitions. Rather than coalescing these into 
 one 
 cookie (which one is the right one to keep, after all?), we decided to 
 just 
 remove partitioned cookies from clients' machines when the feature is 
 disabled to provide deterministic behavior.

  The long term plan is to get rid of "tracking" cookies, or more 
> specifically third party cookies shared between multiple first parties.

Re: [blink-dev] Intent to Experiment: Cookies Having Independent Partitioned State (CHIPS)

[Jignesh Malkan]

Hi Dylan,

I am working along with Marcelo on this POC.
We have been able to make progress.

I see 2 options on chrome://flags
partitioned-cookies & partitioned-cookies-bypass-origin-trial
Which flag am I supposed to use?

One thing I have noticed that seemed odd and wanted to see if thats an 
expected behavior.
We have a small dummy app that just creates a cookie foo-bar and print the 
value in UI https://dim-connect.herokuapp.com/tile
We embed this in iFrame in our Enterprise App.

>From Tab 1 - I go to https://dim-connect.herokuapp.com/tile, a cookie 
fooBar-1 is created with Partition Key of https://dim-connect.herokuapp.com
>From Tab 1 - I log in to Our Enterprise App I see a cookie fooBar-2 is 
created with Partition Key of http://.com

So far so good.

Now if I go to the Tab 1 and delete cookie fooBar-1, It also seem to delete 
cookie fooBar-2

Is this expected?

On Thursday, March 31, 2022 at 5:21:13 PM UTC-4 Dylan Cutler wrote:

> Hey Marcelo,
>
> M100 is when we are starting the origin trial 
>  for CHIPS. In order to 
> use partitioned cookies. You must register for the trial 
> , 
> and have your server send the Origin-Trial and Accept-CH: 
> Sec-CH-Partitioned-Cookies response headers to participate in the trial.
>
> If you wish to bypass the OT opt-in mechanism for local testing, you can 
> enable the --partitioned-cookies-bypass-origin-trial flag in addition to 
> the --partitioned-cookies flag. This configuration will allow partitioned 
> cookies from any site regardless of their origin trial status.
>
> All of this is documented in more detail on 
> https://chromium.org/updates/chips.
>
> Best,
> Dylan
>
> On Thu, Mar 31, 2022 at 4:41 PM Marcelo Portugal  
> wrote:
>
>> Hi,
>>
>> So I updated Chrome today to version 100.0.4896.60, and now, even when I 
>> turn on the partitioned cookie flag, my cookie is not populating the 
>> partitionKey as expected. Furthermore, when I was previously playing with 
>> it earlier this week on version ~99, although I could see the partition key 
>> and behavior working, the partitioned cookies would be blocked once I 
>> changed my settings to block third party cookies. So I am unsure on whether 
>> I am doing something wrong or if there is a defect with partitioned cookies 
>> right now. I was trying with the following url:
>> https://dim-connect.herokuapp.com/tile
>>
>> Any help would be appreciated.
>>
>> Regards,
>>
>> Marcelo
>>
>> On Wednesday, February 2, 2022 at 12:07:55 PM UTC-5 Daniel Bratell wrote:
>>
>>> Thanks for your answers. I hope it works out fine. (You already have 
>>> Chris' LGTM so your experiment is ready to go)
>>>
>>> /Daniel
>>> On 2022-02-02 17:37, Dylan Cutler wrote:
>>>
>>> Will this be run as a third-party Origin Trial? As a Finch experiment? 
 Other?

>>> This experiment will be run as a 3P Origin Trial, 
>>>
>>> So, when the experiment finishes, sites that opted-in to that mode will 
 lose their cookies and their users will e.g. be logged out, etc?
 That seems like a deterrent. Is there a way around that? (e.g. migrate 
 the cookies to the default 3P behavior when the experiment is done. Not 
 sure how feasible that is..)
>>>
>>> The reasoning behind why we didn't do that is that partitioned cookies 
>>> allow the existence of multiple cookies with the same host key, name, and 
>>> path to exist in separate partitions. Rather than coalescing these into one 
>>> cookie (which one is the right one to keep, after all?), we decided to just 
>>> remove partitioned cookies from clients' machines when the feature is 
>>> disabled to provide deterministic behavior.
>>>
>>>  The long term plan is to get rid of "tracking" cookies, or more 
 specifically third party cookies shared between multiple first parties.
>>>
>>> Correct 
>>> 
>>> .
>>>
>>>  This will not change anything unless a site explicitly asks for their 
 cookies to stop tracking people.
>>>
>>> In the short term, yes, clients with partitioned cookies enabled will 
>>> support both partitioned and unpartitioned cross-site cookies. Once 3PCs 
>>> are removed (see link above) then only partitioned cookies will be allowed 
>>> in cross-party contexts.
>>>
>>> Eventually the default might change to "Partioned" and another flag will 
 have to be used to keep tracking users cross sites... In step 4 I assume 
 "Partitioned" becomes a no-op since that is the only available stage?
>>>
>>> I imagine when we first turn off 3PC that third parties will still need 
>>> to explicitly opt into using partitioned state using the 
>>> Partitioned attribute. If third parties do not opt into this behavior then 
>>> they will be unable to use cookies at all. But, in the long term, we may 
>>> have the Partitioned behavior be the default for 

Re: [blink-dev] Intent to Experiment: Cookies Having Independent Partitioned State (CHIPS)

['Dylan Cutler' via blink-dev]

Hey Marcelo,

M100 is when we are starting the origin trial
 for CHIPS. In order to
use partitioned cookies. You must register for the trial
,
and have your server send the Origin-Trial and Accept-CH:
Sec-CH-Partitioned-Cookies response headers to participate in the trial.

If you wish to bypass the OT opt-in mechanism for local testing, you can
enable the --partitioned-cookies-bypass-origin-trial flag in addition to
the --partitioned-cookies flag. This configuration will allow partitioned
cookies from any site regardless of their origin trial status.

All of this is documented in more detail on
https://chromium.org/updates/chips.

Best,
Dylan

On Thu, Mar 31, 2022 at 4:41 PM Marcelo Portugal 
wrote:

> Hi,
>
> So I updated Chrome today to version 100.0.4896.60, and now, even when I
> turn on the partitioned cookie flag, my cookie is not populating the
> partitionKey as expected. Furthermore, when I was previously playing with
> it earlier this week on version ~99, although I could see the partition key
> and behavior working, the partitioned cookies would be blocked once I
> changed my settings to block third party cookies. So I am unsure on whether
> I am doing something wrong or if there is a defect with partitioned cookies
> right now. I was trying with the following url:
> https://dim-connect.herokuapp.com/tile
>
> Any help would be appreciated.
>
> Regards,
>
> Marcelo
>
> On Wednesday, February 2, 2022 at 12:07:55 PM UTC-5 Daniel Bratell wrote:
>
>> Thanks for your answers. I hope it works out fine. (You already have
>> Chris' LGTM so your experiment is ready to go)
>>
>> /Daniel
>> On 2022-02-02 17:37, Dylan Cutler wrote:
>>
>> Will this be run as a third-party Origin Trial? As a Finch experiment?
>>> Other?
>>>
>> This experiment will be run as a 3P Origin Trial,
>>
>> So, when the experiment finishes, sites that opted-in to that mode will
>>> lose their cookies and their users will e.g. be logged out, etc?
>>> That seems like a deterrent. Is there a way around that? (e.g. migrate
>>> the cookies to the default 3P behavior when the experiment is done. Not
>>> sure how feasible that is..)
>>
>> The reasoning behind why we didn't do that is that partitioned cookies
>> allow the existence of multiple cookies with the same host key, name, and
>> path to exist in separate partitions. Rather than coalescing these into one
>> cookie (which one is the right one to keep, after all?), we decided to just
>> remove partitioned cookies from clients' machines when the feature is
>> disabled to provide deterministic behavior.
>>
>>  The long term plan is to get rid of "tracking" cookies, or more
>>> specifically third party cookies shared between multiple first parties.
>>
>> Correct
>> 
>> .
>>
>>  This will not change anything unless a site explicitly asks for their
>>> cookies to stop tracking people.
>>
>> In the short term, yes, clients with partitioned cookies enabled will
>> support both partitioned and unpartitioned cross-site cookies. Once 3PCs
>> are removed (see link above) then only partitioned cookies will be allowed
>> in cross-party contexts.
>>
>> Eventually the default might change to "Partioned" and another flag will
>>> have to be used to keep tracking users cross sites... In step 4 I assume
>>> "Partitioned" becomes a no-op since that is the only available stage?
>>
>> I imagine when we first turn off 3PC that third parties will still need
>> to explicitly opt into using partitioned state using the
>> Partitioned attribute. If third parties do not opt into this behavior then
>> they will be unable to use cookies at all. But, in the long term, we may
>> have the Partitioned behavior be the default for cross-site cookies. In
>> that case, the Partitioned attribute could just be ignored and eventually
>> deprecated.
>>
>>
>>> If that is right, should this prepare the syntax to allow for step 3,
>>> like having "Partitioned=Absolutely" and "Partitioned=Nope" instead of just
>>> partitioned?
>>>
>> I don't think we need the Partitioned attribute to have any other
>> semantic meaning other than a flag saying "I am opting into receiving
>> partitioned 3P state", so we decided to design it like the Secure and
>> HttpOnly attributes (i.e. its presence in the cookie line being "true",
>> it's absence being "false").
>>
>> Do you have partners ready to start testing this?
>>>
>> Yes, there are a couple partners I know offhand who are interested in
>> testing this.
>>
>> On Wed, Feb 2, 2022 at 8:50 AM Daniel Bratell  wrote:
>>
>>> Can you verify that I am getting this right.
>>>
>>> 1. The long term plan is to get rid of "tracking" cookies, or more
>>> specifically third party cookies shared between multiple first parties.
>>>
>>> 2. This will not change anything unless a site explicitly asks for 

Re: [blink-dev] Intent to Experiment: Cookies Having Independent Partitioned State (CHIPS)

[Marcelo Portugal]

Hi,

So I updated Chrome today to version 100.0.4896.60, and now, even when I 
turn on the partitioned cookie flag, my cookie is not populating the 
partitionKey as expected. Furthermore, when I was previously playing with 
it earlier this week on version ~99, although I could see the partition key 
and behavior working, the partitioned cookies would be blocked once I 
changed my settings to block third party cookies. So I am unsure on whether 
I am doing something wrong or if there is a defect with partitioned cookies 
right now. I was trying with the following url:
https://dim-connect.herokuapp.com/tile

Any help would be appreciated.

Regards,

Marcelo

On Wednesday, February 2, 2022 at 12:07:55 PM UTC-5 Daniel Bratell wrote:

> Thanks for your answers. I hope it works out fine. (You already have 
> Chris' LGTM so your experiment is ready to go)
>
> /Daniel
> On 2022-02-02 17:37, Dylan Cutler wrote:
>
> Will this be run as a third-party Origin Trial? As a Finch experiment? 
>> Other?
>>
> This experiment will be run as a 3P Origin Trial, 
>
> So, when the experiment finishes, sites that opted-in to that mode will 
>> lose their cookies and their users will e.g. be logged out, etc?
>> That seems like a deterrent. Is there a way around that? (e.g. migrate 
>> the cookies to the default 3P behavior when the experiment is done. Not 
>> sure how feasible that is..)
>
> The reasoning behind why we didn't do that is that partitioned cookies 
> allow the existence of multiple cookies with the same host key, name, and 
> path to exist in separate partitions. Rather than coalescing these into one 
> cookie (which one is the right one to keep, after all?), we decided to just 
> remove partitioned cookies from clients' machines when the feature is 
> disabled to provide deterministic behavior.
>
>  The long term plan is to get rid of "tracking" cookies, or more 
>> specifically third party cookies shared between multiple first parties.
>
> Correct 
> 
> .
>
>  This will not change anything unless a site explicitly asks for their 
>> cookies to stop tracking people.
>
> In the short term, yes, clients with partitioned cookies enabled will 
> support both partitioned and unpartitioned cross-site cookies. Once 3PCs 
> are removed (see link above) then only partitioned cookies will be allowed 
> in cross-party contexts.
>
> Eventually the default might change to "Partioned" and another flag will 
>> have to be used to keep tracking users cross sites... In step 4 I assume 
>> "Partitioned" becomes a no-op since that is the only available stage?
>
> I imagine when we first turn off 3PC that third parties will still need to 
> explicitly opt into using partitioned state using the 
> Partitioned attribute. If third parties do not opt into this behavior then 
> they will be unable to use cookies at all. But, in the long term, we may 
> have the Partitioned behavior be the default for cross-site cookies. In 
> that case, the Partitioned attribute could just be ignored and eventually 
> deprecated.
>  
>
>> If that is right, should this prepare the syntax to allow for step 3, 
>> like having "Partitioned=Absolutely" and "Partitioned=Nope" instead of just 
>> partitioned?
>>
> I don't think we need the Partitioned attribute to have any other semantic 
> meaning other than a flag saying "I am opting into receiving partitioned 3P 
> state", so we decided to design it like the Secure and HttpOnly attributes 
> (i.e. its presence in the cookie line being "true", it's absence being 
> "false").
>
> Do you have partners ready to start testing this?
>>
> Yes, there are a couple partners I know offhand who are interested in 
> testing this.
>
> On Wed, Feb 2, 2022 at 8:50 AM Daniel Bratell  wrote:
>
>> Can you verify that I am getting this right.
>>
>> 1. The long term plan is to get rid of "tracking" cookies, or more 
>> specifically third party cookies shared between multiple first parties.
>>
>> 2. This will not change anything unless a site explicitly asks for their 
>> cookies to stop tracking people.
>>
>> 3. (outside this experiment) Eventually the default might change to 
>> "Partioned" and another flag will have to be used to keep tracking users 
>> cross sites.
>>
>> 4. (outside this experiment) Finally tracking cookies are disabled 
>> completely (similar to what Safari has done).
>>
>> If that is right, should this prepare the syntax to allow for step 3, 
>> like having "Partitioned=Absolutely" and "Partitioned=Nope" instead of just 
>> partitioned?
>>
>> In step 4 I assume "Partitioned" becomes a no-op since that is the only 
>> available stage?
>>
>> Another question: Do you have partners ready to start testing this?
>>
>> /Daniel
>> On 2022-02-01 20:14, 'Dylan Cutler' via blink-dev wrote:
>>
>> Contact emails
>>
>> dylan...@google.com, kaust...@google.com 
>>
>> Spec
>>
>> https://github.com/WICG/CHIPS
>>
>> Summary
>>
>> Given that 

Re: [blink-dev] Intent to Experiment: Cookies Having Independent Partitioned State (CHIPS)

[Daniel Bratell]

Thanks for your answers. I hope it works out fine. (You already have 
Chris' LGTM so your experiment is ready to go)


/Daniel

On 2022-02-02 17:37, Dylan Cutler wrote:


Will this be run as a third-party Origin Trial? As a Finch
experiment? Other?

This experiment will be run as a 3P Origin Trial,

So, when the experiment finishes, sites that opted-in to that mode
will lose their cookies and their users will e.g. be logged out, etc?
That seems like a deterrent. Is there a way around that? (e.g.
migrate the cookies to the default 3P behavior when the experiment
is done. Not sure how feasible that is..)

The reasoning behind why we didn't do that is that partitioned cookies 
allow the existence of multiple cookies with the same host key, name, 
and path to exist in separate partitions. Rather than coalescing these 
into one cookie (which one is the right one to keep, after all?), we 
decided to just remove partitioned cookies from clients' machines when 
the feature is disabled to provide deterministic behavior.


 The long term plan is to get rid of "tracking" cookies, or more
specifically third party cookies shared between multiple first
parties.

Correct 
.


 This will not change anything unless a site explicitly asks for
their cookies to stop tracking people.

In the short term, yes, clients with partitioned cookies enabled will 
support both partitioned and unpartitioned cross-site cookies. Once 
3PCs are removed (see link above) then only partitioned cookies will 
be allowed in cross-party contexts.


Eventually the default might change to "Partioned" and another
flag will have to be used to keep tracking users cross sites... In
step 4 I assume "Partitioned" becomes a no-op since that is the
only available stage?

I imagine when we first turn off 3PC that third parties will still 
need to explicitly opt into using partitioned state using the 
Partitioned attribute. If third parties do not opt into this behavior 
then they will be unable to use cookies at all. But, in the long term, 
we may have the Partitioned behavior be the default for cross-site 
cookies. In that case, the Partitioned attribute could just be ignored 
and eventually deprecated.


If that is right, should this prepare the syntax to allow for step
3, like having "Partitioned=Absolutely" and "Partitioned=Nope"
instead of just partitioned?

I don't think we need the Partitioned attribute to have any other 
semantic meaning other than a flag saying "I am opting into receiving 
partitioned 3P state", so we decided to design it like the Secure and 
HttpOnly attributes (i.e. its presence in the cookie line being 
"true", it's absence being "false").


Do you have partners ready to start testing this?

Yes, there are a couple partners I know offhand who are interested in 
testing this.


On Wed, Feb 2, 2022 at 8:50 AM Daniel Bratell  wrote:

Can you verify that I am getting this right.

1. The long term plan is to get rid of "tracking" cookies, or more
specifically third party cookies shared between multiple first
parties.

2. This will not change anything unless a site explicitly asks for
their cookies to stop tracking people.

3. (outside this experiment) Eventually the default might change
to "Partioned" and another flag will have to be used to keep
tracking users cross sites.

4. (outside this experiment) Finally tracking cookies are disabled
completely (similar to what Safari has done).

If that is right, should this prepare the syntax to allow for step
3, like having "Partitioned=Absolutely" and "Partitioned=Nope"
instead of just partitioned?

In step 4 I assume "Partitioned" becomes a no-op since that is the
only available stage?

Another question: Do you have partners ready to start testing this?

/Daniel

On 2022-02-01 20:14, 'Dylan Cutler' via blink-dev wrote:


Contact emails

dylancut...@google.com ,
kaustub...@google.com 


Spec

https://github.com/WICG/CHIPS 


Summary

Given that Chrome plans on obsoleting unpartitioned third-party
cookies, we want to give developers the ability to use cookies in
cross-site contexts that are partitioned by top-level site (or
First-Party Set, where the site uses that feature) to meet use
cases that are not cross-site tracking related (e.g. SaaS embeds,
headless CMS, sandbox domains, etc.). In order to do so, we
introduce a mechanism to opt-in to having their third-party
cookies partitioned by top-level site using a new cookie
attribute, Partitioned.


Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/hvMJ33kqHRo

Re: [blink-dev] Intent to Experiment: Cookies Having Independent Partitioned State (CHIPS)

[Yoav Weiss]

On Wednesday, February 2, 2022 at 5:37:49 PM UTC+1 Dylan Cutler wrote:

> Will this be run as a third-party Origin Trial? As a Finch experiment? 
>> Other?
>>
> This experiment will be run as a 3P Origin Trial, 
>
> So, when the experiment finishes, sites that opted-in to that mode will 
>> lose their cookies and their users will e.g. be logged out, etc?
>> That seems like a deterrent. Is there a way around that? (e.g. migrate 
>> the cookies to the default 3P behavior when the experiment is done. Not 
>> sure how feasible that is..)
>
> The reasoning behind why we didn't do that is that partitioned cookies 
> allow the existence of multiple cookies with the same host key, name, and 
> path to exist in separate partitions. Rather than coalescing these into one 
> cookie (which one is the right one to keep, after all?), we decided to just 
> remove partitioned cookies from clients' machines when the feature is 
> disabled to provide deterministic behavior.
>

OK, that makes sense. Given that the breakage at the end of the trial would 
at worst be equivalent to a cookie clearing, no further concerns on my end.
Happy experimentation!!
 

>
>  The long term plan is to get rid of "tracking" cookies, or more 
>> specifically third party cookies shared between multiple first parties.
>
> Correct 
> 
> .
>
>  This will not change anything unless a site explicitly asks for their 
>> cookies to stop tracking people.
>
> In the short term, yes, clients with partitioned cookies enabled will 
> support both partitioned and unpartitioned cross-site cookies. Once 3PCs 
> are removed (see link above) then only partitioned cookies will be allowed 
> in cross-party contexts.
>
> Eventually the default might change to "Partioned" and another flag will 
>> have to be used to keep tracking users cross sites... In step 4 I assume 
>> "Partitioned" becomes a no-op since that is the only available stage?
>
> I imagine when we first turn off 3PC that third parties will still need to 
> explicitly opt into using partitioned state using the 
> Partitioned attribute. If third parties do not opt into this behavior then 
> they will be unable to use cookies at all. But, in the long term, we may 
> have the Partitioned behavior be the default for cross-site cookies. In 
> that case, the Partitioned attribute could just be ignored and eventually 
> deprecated.
>  
>
>> If that is right, should this prepare the syntax to allow for step 3, 
>> like having "Partitioned=Absolutely" and "Partitioned=Nope" instead of just 
>> partitioned?
>>
> I don't think we need the Partitioned attribute to have any other semantic 
> meaning other than a flag saying "I am opting into receiving partitioned 3P 
> state", so we decided to design it like the Secure and HttpOnly attributes 
> (i.e. its presence in the cookie line being "true", it's absence being 
> "false").
>
> Do you have partners ready to start testing this?
>>
> Yes, there are a couple partners I know offhand who are interested in 
> testing this.
>
> On Wed, Feb 2, 2022 at 8:50 AM Daniel Bratell  wrote:
>
>> Can you verify that I am getting this right.
>>
>> 1. The long term plan is to get rid of "tracking" cookies, or more 
>> specifically third party cookies shared between multiple first parties.
>>
>> 2. This will not change anything unless a site explicitly asks for their 
>> cookies to stop tracking people.
>>
>> 3. (outside this experiment) Eventually the default might change to 
>> "Partioned" and another flag will have to be used to keep tracking users 
>> cross sites.
>>
>> 4. (outside this experiment) Finally tracking cookies are disabled 
>> completely (similar to what Safari has done).
>>
>> If that is right, should this prepare the syntax to allow for step 3, 
>> like having "Partitioned=Absolutely" and "Partitioned=Nope" instead of just 
>> partitioned?
>>
>> In step 4 I assume "Partitioned" becomes a no-op since that is the only 
>> available stage?
>>
>> Another question: Do you have partners ready to start testing this?
>>
>> /Daniel
>> On 2022-02-01 20:14, 'Dylan Cutler' via blink-dev wrote:
>>
>> Contact emails
>>
>> dylancut...@google.com, kaustub...@google.com 
>>
>> Spec
>>
>> https://github.com/WICG/CHIPS
>>
>> Summary
>>
>> Given that Chrome plans on obsoleting unpartitioned third-party cookies, 
>> we want to give developers the ability to use cookies in cross-site 
>> contexts that are partitioned by top-level site (or First-Party Set, where 
>> the site uses that feature) to meet use cases that are not cross-site 
>> tracking related (e.g. SaaS embeds, headless CMS, sandbox domains, etc.). 
>> In order to do so, we introduce a mechanism to opt-in to having their 
>> third-party cookies partitioned by top-level site using a new cookie 
>> attribute, Partitioned.
>>
>> Link to “Intent to Prototype” blink-dev discussion
>>
>> 

Re: [blink-dev] Intent to Experiment: Cookies Having Independent Partitioned State (CHIPS)

['Dylan Cutler' via blink-dev]

>
> Will this be run as a third-party Origin Trial? As a Finch experiment?
> Other?
>
This experiment will be run as a 3P Origin Trial,

So, when the experiment finishes, sites that opted-in to that mode will
> lose their cookies and their users will e.g. be logged out, etc?
> That seems like a deterrent. Is there a way around that? (e.g. migrate the
> cookies to the default 3P behavior when the experiment is done. Not sure
> how feasible that is..)

The reasoning behind why we didn't do that is that partitioned cookies
allow the existence of multiple cookies with the same host key, name, and
path to exist in separate partitions. Rather than coalescing these into one
cookie (which one is the right one to keep, after all?), we decided to just
remove partitioned cookies from clients' machines when the feature is
disabled to provide deterministic behavior.

 The long term plan is to get rid of "tracking" cookies, or more
> specifically third party cookies shared between multiple first parties.

Correct

.

 This will not change anything unless a site explicitly asks for their
> cookies to stop tracking people.

In the short term, yes, clients with partitioned cookies enabled will
support both partitioned and unpartitioned cross-site cookies. Once 3PCs
are removed (see link above) then only partitioned cookies will be allowed
in cross-party contexts.

Eventually the default might change to "Partioned" and another flag will
> have to be used to keep tracking users cross sites... In step 4 I assume
> "Partitioned" becomes a no-op since that is the only available stage?

I imagine when we first turn off 3PC that third parties will still need to
explicitly opt into using partitioned state using the
Partitioned attribute. If third parties do not opt into this behavior then
they will be unable to use cookies at all. But, in the long term, we may
have the Partitioned behavior be the default for cross-site cookies. In
that case, the Partitioned attribute could just be ignored and eventually
deprecated.


> If that is right, should this prepare the syntax to allow for step 3, like
> having "Partitioned=Absolutely" and "Partitioned=Nope" instead of just
> partitioned?
>
I don't think we need the Partitioned attribute to have any other semantic
meaning other than a flag saying "I am opting into receiving partitioned 3P
state", so we decided to design it like the Secure and HttpOnly attributes
(i.e. its presence in the cookie line being "true", it's absence being
"false").

Do you have partners ready to start testing this?
>
Yes, there are a couple partners I know offhand who are interested in
testing this.

On Wed, Feb 2, 2022 at 8:50 AM Daniel Bratell  wrote:

> Can you verify that I am getting this right.
>
> 1. The long term plan is to get rid of "tracking" cookies, or more
> specifically third party cookies shared between multiple first parties.
>
> 2. This will not change anything unless a site explicitly asks for their
> cookies to stop tracking people.
>
> 3. (outside this experiment) Eventually the default might change to
> "Partioned" and another flag will have to be used to keep tracking users
> cross sites.
>
> 4. (outside this experiment) Finally tracking cookies are disabled
> completely (similar to what Safari has done).
>
> If that is right, should this prepare the syntax to allow for step 3, like
> having "Partitioned=Absolutely" and "Partitioned=Nope" instead of just
> partitioned?
>
> In step 4 I assume "Partitioned" becomes a no-op since that is the only
> available stage?
>
> Another question: Do you have partners ready to start testing this?
>
> /Daniel
> On 2022-02-01 20:14, 'Dylan Cutler' via blink-dev wrote:
>
> Contact emails
>
> dylancut...@google.com, kaustub...@google.com
>
> Spec
>
> https://github.com/WICG/CHIPS
>
> Summary
>
> Given that Chrome plans on obsoleting unpartitioned third-party cookies,
> we want to give developers the ability to use cookies in cross-site
> contexts that are partitioned by top-level site (or First-Party Set, where
> the site uses that feature) to meet use cases that are not cross-site
> tracking related (e.g. SaaS embeds, headless CMS, sandbox domains, etc.).
> In order to do so, we introduce a mechanism to opt-in to having their
> third-party cookies partitioned by top-level site using a new cookie
> attribute, Partitioned.
>
> Link to “Intent to Prototype” blink-dev discussion
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/hvMJ33kqHRo
>
> Goals for experimentation
>
> CHIPS is a new, opt-in technology meant to preserve a set of use cases
> (e.g. third-party embeds) that may break once third-party cookies are
> phased out while preventing cross-site tracking. We need to validate
> whether the proposed syntax and semantics solve these use cases prior to
> third-party cookie obsoletion by giving developers a way to test it in a
> scaled manner and provide early 

Re: [blink-dev] Intent to Experiment: Cookies Having Independent Partitioned State (CHIPS)

[Daniel Bratell]

Can you verify that I am getting this right.

1. The long term plan is to get rid of "tracking" cookies, or more 
specifically third party cookies shared between multiple first parties.


2. This will not change anything unless a site explicitly asks for their 
cookies to stop tracking people.


3. (outside this experiment) Eventually the default might change to 
"Partioned" and another flag will have to be used to keep tracking users 
cross sites.


4. (outside this experiment) Finally tracking cookies are disabled 
completely (similar to what Safari has done).


If that is right, should this prepare the syntax to allow for step 3, 
like having "Partitioned=Absolutely" and "Partitioned=Nope" instead of 
just partitioned?


In step 4 I assume "Partitioned" becomes a no-op since that is the only 
available stage?


Another question: Do you have partners ready to start testing this?

/Daniel

On 2022-02-01 20:14, 'Dylan Cutler' via blink-dev wrote:


Contact emails

dylancut...@google.com , 
kaustub...@google.com 



Spec

https://github.com/WICG/CHIPS 


Summary

Given that Chrome plans on obsoleting unpartitioned third-party 
cookies, we want to give developers the ability to use cookies in 
cross-site contexts that are partitioned by top-level site (or 
First-Party Set, where the site uses that feature) to meet use cases 
that are not cross-site tracking related (e.g. SaaS embeds, headless 
CMS, sandbox domains, etc.). In order to do so, we introduce a 
mechanism to opt-in to having their third-party cookies partitioned by 
top-level site using a new cookie attribute, Partitioned.



Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/hvMJ33kqHRo 




Goals for experimentation

CHIPS is a new, opt-in technology meant to preserve a set of use cases 
(e.g. third-party embeds) that may break once third-party cookies are 
phased out while preventing cross-site tracking. We need to validate 
whether the proposed syntax and semantics solve these use cases prior 
to third-party cookie obsoletion by giving developers a way to test it 
in a scaled manner and provide early feedback. We hope to validate 
ergonomics, deployability, and backward compatibility.


Experimental timeline

The experiment will start in M100 and run from March 31st, 2022 until 
June 30, 2022.



Any risks when the experiment finishes?

Since Chrome will not send and may delete partitioned cookies when it 
is started with the feature disabled, sites that set cookies with the 
Partitioned attribute during the experiment will no longer have those 
cookies available on clients' machines.



Reason this experiment is being extended

N/A


Ongoing technical constraints

None.


Debuggability

We have coordinated with the DevTools team to surface cookie partition 
keys to developers in DevTools. We have added a new cookie inclusion 
reason with a debug string when sites set Partitioned cookies 
incorrectly. We may also support surfacing partitioned cookies that 
are not included in requests because their partition key did not match 
the top-level site in DevTools.



Will this feature be supported on all five Blink platforms supported 
by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?


Yes.


Link to entry on the feature dashboard 

https://www.chromestatus.com/feature/5179189105786880 




--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFRxpqxLUXAEfFqcACt-S7A8Y_6Q9is%3DCZJskiYuby0qJA%40mail.gmail.com 
.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3338ebe5-7ce6-2f3c-d9ba-e79f9b52996e%40gmail.com.

Re: [blink-dev] Intent to Experiment: Cookies Having Independent Partitioned State (CHIPS)

[Yoav Weiss]

On Tue, Feb 1, 2022 at 8:14 PM 'Dylan Cutler' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> dylancut...@google.com, kaustub...@google.com
>
> Spec
>
> https://github.com/WICG/CHIPS
>
> Summary
>
> Given that Chrome plans on obsoleting unpartitioned third-party cookies,
> we want to give developers the ability to use cookies in cross-site
> contexts that are partitioned by top-level site (or First-Party Set, where
> the site uses that feature) to meet use cases that are not cross-site
> tracking related (e.g. SaaS embeds, headless CMS, sandbox domains, etc.).
> In order to do so, we introduce a mechanism to opt-in to having their
> third-party cookies partitioned by top-level site using a new cookie
> attribute, Partitioned.
>

Will this be run as a third-party Origin Trial? As a Finch experiment?
Other?


>
> Link to “Intent to Prototype” blink-dev discussion
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/hvMJ33kqHRo
>
> Goals for experimentation
>
> CHIPS is a new, opt-in technology meant to preserve a set of use cases
> (e.g. third-party embeds) that may break once third-party cookies are
> phased out while preventing cross-site tracking. We need to validate
> whether the proposed syntax and semantics solve these use cases prior to
> third-party cookie obsoletion by giving developers a way to test it in a
> scaled manner and provide early feedback. We hope to validate ergonomics,
> deployability, and backward compatibility.
>
> Experimental timeline
>
> The experiment will start in M100 and run from March 31st, 2022 until June
> 30, 2022.
>
> Any risks when the experiment finishes?
>
> Since Chrome will not send and may delete partitioned cookies when it is
> started with the feature disabled, sites that set cookies with the
> Partitioned attribute during the experiment will no longer have those
> cookies available on clients' machines.
>

So, when the experiment finishes, sites that opted-in to that mode will
lose their cookies and their users will e.g. be logged out, etc?
That seems like a deterrent. Is there a way around that? (e.g. migrate the
cookies to the default 3P behavior when the experiment is done. Not sure
how feasible that is..)


> Reason this experiment is being extended
>
> N/A
>
> Ongoing technical constraints
>
> None.
>
> Debuggability
>
> We have coordinated with the DevTools team to surface cookie partition
> keys to developers in DevTools. We have added a new cookie inclusion reason
> with a debug string when sites set Partitioned cookies incorrectly. We may
> also support surfacing partitioned cookies that are not included in
> requests because their partition key did not match the top-level site in
> DevTools.
>
> Will this feature be supported on all five Blink platforms supported by
> Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
>
> Yes.
>
> Link to entry on the feature dashboard 
>
> https://www.chromestatus.com/feature/5179189105786880
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFRxpqxLUXAEfFqcACt-S7A8Y_6Q9is%3DCZJskiYuby0qJA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXPJgQNQRa6fEV8qS3cDHQfwR0NXG7rBuvuh6eL73FdHg%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Cookies Having Independent Partitioned State (CHIPS)

[Chris Harrelson]

LGTM

On Tue, Feb 1, 2022 at 11:14 AM 'Dylan Cutler' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> dylancut...@google.com, kaustub...@google.com
>
> Spec
>
> https://github.com/WICG/CHIPS
>
> Summary
>
> Given that Chrome plans on obsoleting unpartitioned third-party cookies,
> we want to give developers the ability to use cookies in cross-site
> contexts that are partitioned by top-level site (or First-Party Set, where
> the site uses that feature) to meet use cases that are not cross-site
> tracking related (e.g. SaaS embeds, headless CMS, sandbox domains, etc.).
> In order to do so, we introduce a mechanism to opt-in to having their
> third-party cookies partitioned by top-level site using a new cookie
> attribute, Partitioned.
>
> Link to “Intent to Prototype” blink-dev discussion
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/hvMJ33kqHRo
>
> Goals for experimentation
>
> CHIPS is a new, opt-in technology meant to preserve a set of use cases
> (e.g. third-party embeds) that may break once third-party cookies are
> phased out while preventing cross-site tracking. We need to validate
> whether the proposed syntax and semantics solve these use cases prior to
> third-party cookie obsoletion by giving developers a way to test it in a
> scaled manner and provide early feedback. We hope to validate ergonomics,
> deployability, and backward compatibility.
>
> Experimental timeline
>
> The experiment will start in M100 and run from March 31st, 2022 until June
> 30, 2022.
>
> Any risks when the experiment finishes?
>
> Since Chrome will not send and may delete partitioned cookies when it is
> started with the feature disabled, sites that set cookies with the
> Partitioned attribute during the experiment will no longer have those
> cookies available on clients' machines.
>
> Reason this experiment is being extended
>
> N/A
>
> Ongoing technical constraints
>
> None.
>
> Debuggability
>
> We have coordinated with the DevTools team to surface cookie partition
> keys to developers in DevTools. We have added a new cookie inclusion reason
> with a debug string when sites set Partitioned cookies incorrectly. We may
> also support surfacing partitioned cookies that are not included in
> requests because their partition key did not match the top-level site in
> DevTools.
>
> Will this feature be supported on all five Blink platforms supported by
> Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
>
> Yes.
>
> Link to entry on the feature dashboard 
>
> https://www.chromestatus.com/feature/5179189105786880
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFRxpqxLUXAEfFqcACt-S7A8Y_6Q9is%3DCZJskiYuby0qJA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8cBibgfzXa_r%2B_yfGG-sdnBba%3DyLO3NNEbKQ_JWEEBbA%40mail.gmail.com.

[blink-dev] Intent to Experiment: Cookies Having Independent Partitioned State (CHIPS)

['Dylan Cutler' via blink-dev]

Contact emails

dylancut...@google.com, kaustub...@google.com

Spec

https://github.com/WICG/CHIPS

Summary

Given that Chrome plans on obsoleting unpartitioned third-party cookies, we
want to give developers the ability to use cookies in cross-site contexts
that are partitioned by top-level site (or First-Party Set, where the site
uses that feature) to meet use cases that are not cross-site tracking
related (e.g. SaaS embeds, headless CMS, sandbox domains, etc.). In order
to do so, we introduce a mechanism to opt-in to having their third-party
cookies partitioned by top-level site using a new cookie attribute,
Partitioned.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/hvMJ33kqHRo

Goals for experimentation

CHIPS is a new, opt-in technology meant to preserve a set of use cases
(e.g. third-party embeds) that may break once third-party cookies are
phased out while preventing cross-site tracking. We need to validate
whether the proposed syntax and semantics solve these use cases prior to
third-party cookie obsoletion by giving developers a way to test it in a
scaled manner and provide early feedback. We hope to validate ergonomics,
deployability, and backward compatibility.

Experimental timeline

The experiment will start in M100 and run from March 31st, 2022 until June
30, 2022.

Any risks when the experiment finishes?

Since Chrome will not send and may delete partitioned cookies when it is
started with the feature disabled, sites that set cookies with the
Partitioned attribute during the experiment will no longer have those
cookies available on clients' machines.

Reason this experiment is being extended

N/A

Ongoing technical constraints

None.

Debuggability

We have coordinated with the DevTools team to surface cookie partition keys
to developers in DevTools. We have added a new cookie inclusion reason with
a debug string when sites set Partitioned cookies incorrectly. We may also
support surfacing partitioned cookies that are not included in requests
because their partition key did not match the top-level site in DevTools.

Will this feature be supported on all five Blink platforms supported by
Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard 

https://www.chromestatus.com/feature/5179189105786880

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFRxpqxLUXAEfFqcACt-S7A8Y_6Q9is%3DCZJskiYuby0qJA%40mail.gmail.com.