Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

2024-03-12 Thread 'Aaron Selya' via blink-dev
>
> The first mitigation listed here is to migrate existing
> partitioned cookies to include the new bit, and the second mitigation is to
> have a flag that can disable this feature. Would disabling the feature also
> include migrating the existing cookies back to exclude the new bit?
>

Disabling the flag would not migrate the existing cookies back to exclude
the new bit. It would make it so that the new bit value is not considered
when checking equivalence. Not considering the value of the bit when is the
current behavior so we anticipate no issues ignoring the bit if the flag
needs to disable the feature.


> And somewhat related, but does the format of the cookie request developers
> make have to change too, or is this bit determination purely done within
> the browser?
>

In almost all cases this is set within the browser. The only circumstance
I've run into where the value could be set by a developer is with the chrome
.cookies.set api for extensions.  This API allows the developer to set the
site associated with the cookie partition key and with this change would
allow for the bit value to be set as well.

On Tue, Mar 12, 2024 at 2:53 PM Vladimir Levin  wrote:

>
>
> On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya  wrote:
>
>> Contact emails
>>
>> se...@chromium.org, dylancut...@chromium.org, kaustub...@chromium.org
>>
>>
>> Explainer
>>
>> Keying of "CHIPS" cookies should align with other state:
>> 
>>
>>
>> Specification
>>
>> Add cross-site ancestor chain bit to spec:
>> https://github.com/explainers-by-googlers/CHIPS-spec/pull/13
>>
>>
>>
>> Summary
>>
>> We are looking to align the partition key
>> 
>> in CHIPS (Cookies Having Independent Partitioned State, aka partitioned
>> cookies) with the existing implementation of StorageKey.
>>
>>
>> The only sites that would experience different behavior, would be when a
>> top-level site “A” embeds an iframe to a cross-site document on site “B”,
>> and then the iframe B embeds an iframe that loads a document from site “A”
>> (shorthand: A1->B->A2). Previously, partitioned cookies sent or received in
>> the inner iframe A2 would be the same partitioned cookies sent or received
>> in the outer frame A1. This is no longer true.
>>
>>
>> This change is privacy neutral, but will have improved security
>> characteristics, because it prevents cross-site iframes from embedding
>> arbitrary endpoints of the top-level site with credentials, without first
>> being granted permission to do so through the Storage Access API (SAA) or
>> Cross-Origin Resource Sharing (CORS).
>>
>>
>>
>> The impact of this change is expected to be small as our metrics indicate
>> that only 0.2% of CHIPS (partitioned cookies) set by the first party are
>> currently being used in A1->B->A2 contexts. This constitutes 0.032% of all
>> page loads (calculated using the usage of PartitionedCookie
>> ).
>> For websites that do need access to the same cookies across A1 and A2 (in
>> the A1->B->A2 configuration), we recommend using SameSite=None cookies
>> *without* the Partitioned attribute, and invoking the Storage Access API
>> (SAA) or using the Cross-Origin Resource Sharing (CORS).
>>
>>
>>
>> Blink component
>>
>> Internals>Network>Cookies>PartitionedCookies
>> 
>>
>>
>>
>>
>> TAG review
>>
>> Not requested, as this does not differ in any significant way from the
>> original CHIPS design that was already reviewed by TAG
>> .
>>
>>
>> TAG review status
>>
>> N/A
>>
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> The inclusion of a new element in the partition key will mean that
>> partitioned cookies (CHIPS) created after the launch of this change will
>> not be compatible with the partitioned cookies that already exist in users
>> cookie jars. To address this, existing partitioned cookies will be migrated
>> (without any need for developer action) to include the new cross-site
>> ancestor chain bit value, which will be set with a value of true if the
>> existing partition key does not match the host key (indicating a cross site
>> ancestor is present) and false if the partition key does match the host
>> key. This will ensure that most existing CHIPS have the same scope as they
>> did prior to the change.
>>
>>
>> Only 0.2% of partitioned cookies are utilized from within A1->B->A2
>> scenarios, but developers who need to be able to access cookies in
>> A1->B->A2 scenarios wi

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

2024-03-13 Thread 'Aaron Selya' via blink-dev
The flag is a base::features flag named
kAncestorChainBitEnabledInPartitionedCookies.

Updated the review gates on chromestatus.com

On Wed, Mar 13, 2024 at 11:25 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> Also, can you flip on the relevant review gates in chromestatus.com?
>
> On Wed, Mar 13, 2024 at 11:24 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> The first mitigation listed here is to migrate existing
>>>> partitioned cookies to include the new bit, and the second mitigation is to
>>>> have a flag that can disable this feature. Would disabling the feature also
>>>> include migrating the existing cookies back to exclude the new bit?
>>>>
>>>
>>> Disabling the flag would not migrate the existing cookies back to
>>> exclude the new bit. It would make it so that the new bit value is not
>>> considered when checking equivalence. Not considering the value of the bit
>>> when is the current behavior so we anticipate no issues ignoring the bit if
>>> the flag needs to disable the feature.
>>>
>>
>> Can you clarify what kind of flag are we talking about? Is this a Finch
>> flag we expect to turn off if we encounter lots of breakage? An enterprise
>> policy flag? A flag we expect users to use? (I doubt it's the latter, but
>> clarifications would help :D)
>>
>>
>>>
>>>
>>>> And somewhat related, but does the format of the cookie request
>>>> developers make have to change too, or is this bit determination purely
>>>> done within the browser?
>>>>
>>>
>>> In almost all cases this is set within the browser. The only
>>> circumstance I've run into where the value could be set by a developer is
>>> with the chrome.cookies.set api for extensions.  This API allows the
>>> developer to set the site associated with the cookie partition key and with
>>> this change would allow for the bit value to be set as well.
>>>
>>> On Tue, Mar 12, 2024 at 2:53 PM Vladimir Levin 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya  wrote:
>>>>
>>>>> Contact emails
>>>>>
>>>>> se...@chromium.org, dylancut...@chromium.org, kaustub...@chromium.org
>>>>>
>>>>>
>>>>> Explainer
>>>>>
>>>>> Keying of "CHIPS" cookies should align with other state:
>>>>> <https://github.com/privacycg/CHIPS/issues/40#issuecomment-1883726735>
>>>>>
>>>>>
>>>>> Specification
>>>>>
>>>>> Add cross-site ancestor chain bit to spec:
>>>>> https://github.com/explainers-by-googlers/CHIPS-spec/pull/13
>>>>>
>>>>>
>>>>>
>>>>> Summary
>>>>>
>>>>> We are looking to align the partition key
>>>>> <https://developers.google.com/privacy-sandbox/3pcd/chips#:~:text=A%20cookie%27s%20partition%20key%20is%20the%20site%20(scheme%20and%20registrable%20domain)%20of%20the%20top%2Dlevel%20URL%20the%20browser%20was%20visiting%20at%20the%20start%20of%20the%20request%20to%20the%20endpoint%20that%20set%20the%20cookie.>
>>>>> in CHIPS (Cookies Having Independent Partitioned State, aka partitioned
>>>>> cookies) with the existing implementation of StorageKey.
>>>>>
>>>>>
>>>>> The only sites that would experience different behavior, would be when
>>>>> a top-level site “A” embeds an iframe to a cross-site document on site 
>>>>> “B”,
>>>>> and then the iframe B embeds an iframe that loads a document from site “A”
>>>>> (shorthand: A1->B->A2). Previously, partitioned cookies sent or received 
>>>>> in
>>>>> the inner iframe A2 would be the same partitioned cookies sent or received
>>>>> in the outer frame A1. This is no longer true.
>>>>>
>>>>>
>>>>> This change is privacy neutral, but will have improved security
>>>>> characteristics, because it prevents cross-site iframes from embedding
>>>>> arbitrary endpoints of the top-level site with credentials, without first
>>>>> being granted permission to do so through the Storage Access API (SAA) or
>>>&

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

2024-03-19 Thread &#x27;Aaron Selya&#x27; via blink-dev
Yoav, your understanding is correct.

I'm still in the process of finalizing the implementation. Once that is
done, I'll audit some sites that metrics have indicated will
experience breakage and report back my findings.

On Tue, Mar 19, 2024 at 8:52 AM Mike Taylor  wrote:

> It would also be helpful to discuss what breakage looks like in this case.
> Would it be a one-time loss of state (i.e., have to log in again), or
> something different?
> On 3/19/24 5:08 AM, Yoav Weiss (@Shopify) wrote:
>
> OK, so just to summarize my understanding:
>
>- We expect this to have some impact on 0.032% of page views
>- We have a Finch flag that can be used as a kill switch in case we
>see lots of breakage in the wild
>- Developers can get around this deprecation by changing their cookies
>to be "same-site: none" *and* requesting SAA from users
>
> Is the above correct?
>
> If so, 0.032% sounds like a lot. Would it be possible for y'all to same
> pages that trigger that use counter and see how many of them break and what
> does breakage look like?
>
> On Wed, Mar 13, 2024 at 8:23 PM Aaron Selya  wrote:
>
>> The flag is a base::features flag named
>> kAncestorChainBitEnabledInPartitionedCookies.
>>
>> Updated the review gates on chromestatus.com
>>
>> On Wed, Mar 13, 2024 at 11:25 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> Also, can you flip on the relevant review gates in chromestatus.com?
>>>
>>> On Wed, Mar 13, 2024 at 11:24 AM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via blink-dev <
>>>> blink-dev@chromium.org> wrote:
>>>>
>>>>> The first mitigation listed here is to migrate existing
>>>>>> partitioned cookies to include the new bit, and the second mitigation is 
>>>>>> to
>>>>>> have a flag that can disable this feature. Would disabling the feature 
>>>>>> also
>>>>>> include migrating the existing cookies back to exclude the new bit?
>>>>>>
>>>>>
>>>>> Disabling the flag would not migrate the existing cookies back to
>>>>> exclude the new bit. It would make it so that the new bit value is not
>>>>> considered when checking equivalence. Not considering the value of the bit
>>>>> when is the current behavior so we anticipate no issues ignoring the bit 
>>>>> if
>>>>> the flag needs to disable the feature.
>>>>>
>>>>
>>>> Can you clarify what kind of flag are we talking about? Is this a Finch
>>>> flag we expect to turn off if we encounter lots of breakage? An enterprise
>>>> policy flag? A flag we expect users to use? (I doubt it's the latter, but
>>>> clarifications would help :D)
>>>>
>>>>
>>>>>
>>>>>
>>>>>> And somewhat related, but does the format of the cookie request
>>>>>> developers make have to change too, or is this bit determination purely
>>>>>> done within the browser?
>>>>>>
>>>>>
>>>>> In almost all cases this is set within the browser. The only
>>>>> circumstance I've run into where the value could be set by a developer is
>>>>> with the chrome.cookies.set api for extensions.  This API allows the
>>>>> developer to set the site associated with the cookie partition key and 
>>>>> with
>>>>> this change would allow for the bit value to be set as well.
>>>>>
>>>>> On Tue, Mar 12, 2024 at 2:53 PM Vladimir Levin 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya 
>>>>>> wrote:
>>>>>>
>>>>>>> Contact emails
>>>>>>>
>>>>>>> se...@chromium.org, dylancut...@chromium.org,
>>>>>>> kaustub...@chromium.org
>>>>>>>
>>>>>>>
>>>>>>> Explainer
>>>>>>>
>>>>>>> Keying of "CHIPS" cookies should align with other state:
>>>>>>> <https://github.com/privacycg/CHIPS/issues/40#issuecomment-1883726735>
>>>>>>>
>>>>>>>
>>>>>>> Specificati

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

2024-05-01 Thread &#x27;Aaron Selya&#x27; via blink-dev
My apologies for the delay in following up on this.

When I finished my initial implementation and got to the point where I
could begin testing, I found that my metrics were being flooded with a
cookie named, "receive-cookie-deprication". After doing some research and
testing I learned that this cookie is used by sites for testing the
potential impact of third party cookie depreciation but doesn't have any
impact on website functionality. To get a better sense of potential
breakage, I landed updated metrics that filtered out that cookie. I then
conducted a manual audit on 10 (of the 104) sites that indicated a possible
impact with a build of chromium that had the finch flag turned on.

I've summarized my findings in this slide deck
<https://docs.google.com/presentation/d/1S2N2vyGDaKAwP-5W5pVYqRNQ1RQndjlq4yVTny6hEIY/edit?usp=sharing>
but I was unable to find a breakage that caused a site to not perform as
expected from the user's perspective. To be clear, this doesn't mean that
there won't be breakage that occurs if/when this feature goes live, only
that I was unable to find an example where the website was unable to
perform as expected.

Additionally, with the filtering out of the "receive-cookie-deprication"
cookie from the metrics, the occurrences of an A1->B-A2 cookie which this
change would impact drops from 0.032% of overall page loads to 0.0012% of
overall page loads.

On Tue, Mar 19, 2024 at 12:05 PM Aaron Selya  wrote:

> Yoav, your understanding is correct.
>
> I'm still in the process of finalizing the implementation. Once that is
> done, I'll audit some sites that metrics have indicated will
> experience breakage and report back my findings.
>
> On Tue, Mar 19, 2024 at 8:52 AM Mike Taylor 
> wrote:
>
>> It would also be helpful to discuss what breakage looks like in this
>> case. Would it be a one-time loss of state (i.e., have to log in again), or
>> something different?
>> On 3/19/24 5:08 AM, Yoav Weiss (@Shopify) wrote:
>>
>> OK, so just to summarize my understanding:
>>
>>- We expect this to have some impact on 0.032% of page views
>>- We have a Finch flag that can be used as a kill switch in case we
>>see lots of breakage in the wild
>>- Developers can get around this deprecation by changing their
>>cookies to be "same-site: none" *and* requesting SAA from users
>>
>> Is the above correct?
>>
>> If so, 0.032% sounds like a lot. Would it be possible for y'all to same
>> pages that trigger that use counter and see how many of them break and what
>> does breakage look like?
>>
>> On Wed, Mar 13, 2024 at 8:23 PM Aaron Selya  wrote:
>>
>>> The flag is a base::features flag named
>>> kAncestorChainBitEnabledInPartitionedCookies.
>>>
>>> Updated the review gates on chromestatus.com
>>>
>>> On Wed, Mar 13, 2024 at 11:25 AM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>
>>>> Also, can you flip on the relevant review gates in chromestatus.com?
>>>>
>>>> On Wed, Mar 13, 2024 at 11:24 AM Yoav Weiss (@Shopify) <
>>>> yoavwe...@chromium.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via blink-dev <
>>>>> blink-dev@chromium.org> wrote:
>>>>>
>>>>>> The first mitigation listed here is to migrate existing
>>>>>>> partitioned cookies to include the new bit, and the second mitigation 
>>>>>>> is to
>>>>>>> have a flag that can disable this feature. Would disabling the feature 
>>>>>>> also
>>>>>>> include migrating the existing cookies back to exclude the new bit?
>>>>>>>
>>>>>>
>>>>>> Disabling the flag would not migrate the existing cookies back to
>>>>>> exclude the new bit. It would make it so that the new bit value is not
>>>>>> considered when checking equivalence. Not considering the value of the 
>>>>>> bit
>>>>>> when is the current behavior so we anticipate no issues ignoring the bit 
>>>>>> if
>>>>>> the flag needs to disable the feature.
>>>>>>
>>>>>
>>>>> Can you clarify what kind of flag are we talking about? Is this a
>>>>> Finch flag we expect to turn off if we encounter lots of breakage? An
>>>>> enterprise policy flag? A flag we expect users to use? (I doubt it's the
>>>>&g

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

2024-05-03 Thread &#x27;Aaron Selya&#x27; via blink-dev
Thank you for suggesting a deeper dive into this Yoav as I might not have
discovered the significant impact that the "receive-cookie-deprication"
cookies were having on my metrics without your prompting.

I've reached out to some engineers at Paypal and hopefully they'll get back
to me sometime next week.

On Fri, May 3, 2024 at 8:50 AM Yoav Weiss (@Shopify) 
wrote:

> Thanks for diving into this!!
>
> I guess the scariest bit here would be paypal losing a cookie in the
> redirect. Even if you didn't find a visible impact in your testing, they
> may not be exhaustive, and breakage there feels riskier than in other
> mentioned domains.
>
> Have you tried to reach out to Paypal folks and see what they say?
>
> On Wed, May 1, 2024 at 8:05 PM Aaron Selya  wrote:
>
>> My apologies for the delay in following up on this.
>>
>> When I finished my initial implementation and got to the point where I
>> could begin testing, I found that my metrics were being flooded with a
>> cookie named, "receive-cookie-deprication". After doing some research and
>> testing I learned that this cookie is used by sites for testing the
>> potential impact of third party cookie depreciation but doesn't have any
>> impact on website functionality. To get a better sense of potential
>> breakage, I landed updated metrics that filtered out that cookie. I then
>> conducted a manual audit on 10 (of the 104) sites that indicated a possible
>> impact with a build of chromium that had the finch flag turned on.
>>
>> I've summarized my findings in this slide deck
>> <https://docs.google.com/presentation/d/1S2N2vyGDaKAwP-5W5pVYqRNQ1RQndjlq4yVTny6hEIY/edit?usp=sharing>
>> but I was unable to find a breakage that caused a site to not perform as
>> expected from the user's perspective. To be clear, this doesn't mean that
>> there won't be breakage that occurs if/when this feature goes live, only
>> that I was unable to find an example where the website was unable to
>> perform as expected.
>>
>> Additionally, with the filtering out of the "receive-cookie-deprication"
>> cookie from the metrics, the occurrences of an A1->B-A2 cookie which this
>> change would impact drops from 0.032% of overall page loads to 0.0012% of
>> overall page loads.
>>
>
> That's extremely reassuring!
>
>
>>
>> On Tue, Mar 19, 2024 at 12:05 PM Aaron Selya  wrote:
>>
>>> Yoav, your understanding is correct.
>>>
>>> I'm still in the process of finalizing the implementation. Once that is
>>> done, I'll audit some sites that metrics have indicated will
>>> experience breakage and report back my findings.
>>>
>>> On Tue, Mar 19, 2024 at 8:52 AM Mike Taylor 
>>> wrote:
>>>
>>>> It would also be helpful to discuss what breakage looks like in this
>>>> case. Would it be a one-time loss of state (i.e., have to log in again), or
>>>> something different?
>>>> On 3/19/24 5:08 AM, Yoav Weiss (@Shopify) wrote:
>>>>
>>>> OK, so just to summarize my understanding:
>>>>
>>>>- We expect this to have some impact on 0.032% of page views
>>>>- We have a Finch flag that can be used as a kill switch in case we
>>>>see lots of breakage in the wild
>>>>- Developers can get around this deprecation by changing their
>>>>cookies to be "same-site: none" *and* requesting SAA from users
>>>>
>>>> Is the above correct?
>>>>
>>>> If so, 0.032% sounds like a lot. Would it be possible for y'all to same
>>>> pages that trigger that use counter and see how many of them break and what
>>>> does breakage look like?
>>>>
>>>> On Wed, Mar 13, 2024 at 8:23 PM Aaron Selya  wrote:
>>>>
>>>>> The flag is a base::features flag named
>>>>> kAncestorChainBitEnabledInPartitionedCookies.
>>>>>
>>>>> Updated the review gates on chromestatus.com
>>>>>
>>>>> On Wed, Mar 13, 2024 at 11:25 AM Yoav Weiss (@Shopify) <
>>>>> yoavwe...@chromium.org> wrote:
>>>>>
>>>>>> Also, can you flip on the relevant review gates in chromestatus.com?
>>>>>>
>>>>>> On Wed, Mar 13, 2024 at 11:24 AM Yoav Weiss (@Shopify) <
>>>>>> yoavwe...@chromium.org> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue,

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

2024-05-22 Thread &#x27;Aaron Selya&#x27; via blink-dev
Had a good initial conversation with them on Monday letting them know about
the issue. They're going to do some testing with the feature enabled to try
and gauge the impact the feature will have on their backend. I'm hopeful
that they'll give us an update by early next week.

On Wed, May 22, 2024 at 10:21 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> Any news from Paypal?
>
> On Friday, May 3, 2024 at 7:15:58 PM UTC+2 Aaron Selya wrote:
>
>> Thank you for suggesting a deeper dive into this Yoav as I might not have
>> discovered the significant impact that the "receive-cookie-deprication"
>> cookies were having on my metrics without your prompting.
>>
>> I've reached out to some engineers at Paypal and hopefully they'll get
>> back to me sometime next week.
>>
>> On Fri, May 3, 2024 at 8:50 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> Thanks for diving into this!!
>>>
>>> I guess the scariest bit here would be paypal losing a cookie in the
>>> redirect. Even if you didn't find a visible impact in your testing, they
>>> may not be exhaustive, and breakage there feels riskier than in other
>>> mentioned domains.
>>>
>>> Have you tried to reach out to Paypal folks and see what they say?
>>>
>>> On Wed, May 1, 2024 at 8:05 PM Aaron Selya  wrote:
>>>
>>>> My apologies for the delay in following up on this.
>>>>
>>>> When I finished my initial implementation and got to the point where I
>>>> could begin testing, I found that my metrics were being flooded with a
>>>> cookie named, "receive-cookie-deprication". After doing some research and
>>>> testing I learned that this cookie is used by sites for testing the
>>>> potential impact of third party cookie depreciation but doesn't have any
>>>> impact on website functionality. To get a better sense of potential
>>>> breakage, I landed updated metrics that filtered out that cookie. I then
>>>> conducted a manual audit on 10 (of the 104) sites that indicated a possible
>>>> impact with a build of chromium that had the finch flag turned on.
>>>>
>>>> I've summarized my findings in this slide deck
>>>> <https://docs.google.com/presentation/d/1S2N2vyGDaKAwP-5W5pVYqRNQ1RQndjlq4yVTny6hEIY/edit?usp=sharing>
>>>> but I was unable to find a breakage that caused a site to not perform as
>>>> expected from the user's perspective. To be clear, this doesn't mean that
>>>> there won't be breakage that occurs if/when this feature goes live, only
>>>> that I was unable to find an example where the website was unable to
>>>> perform as expected.
>>>>
>>>> Additionally, with the filtering out of the
>>>> "receive-cookie-deprication" cookie from the metrics, the occurrences of an
>>>> A1->B-A2 cookie which this change would impact drops from 0.032% of overall
>>>> page loads to 0.0012% of overall page loads.
>>>>
>>>
>>> That's extremely reassuring!
>>>
>>>
>>>>
>>>> On Tue, Mar 19, 2024 at 12:05 PM Aaron Selya  wrote:
>>>>
>>>>> Yoav, your understanding is correct.
>>>>>
>>>>> I'm still in the process of finalizing the implementation. Once that
>>>>> is done, I'll audit some sites that metrics have indicated will
>>>>> experience breakage and report back my findings.
>>>>>
>>>>> On Tue, Mar 19, 2024 at 8:52 AM Mike Taylor 
>>>>> wrote:
>>>>>
>>>>>> It would also be helpful to discuss what breakage looks like in this
>>>>>> case. Would it be a one-time loss of state (i.e., have to log in again), 
>>>>>> or
>>>>>> something different?
>>>>>> On 3/19/24 5:08 AM, Yoav Weiss (@Shopify) wrote:
>>>>>>
>>>>>> OK, so just to summarize my understanding:
>>>>>>
>>>>>>- We expect this to have some impact on 0.032% of page views
>>>>>>- We have a Finch flag that can be used as a kill switch in case
>>>>>>we see lots of breakage in the wild
>>>>>>    - Developers can get around this deprecation by changing their
>>>>>>cookies to be "same-site: none" *and* requesting SAA from users
>>>>>>
>>>&g

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

2024-05-30 Thread &#x27;Aaron Selya&#x27; via blink-dev
@Chris, completed the testing section as requested.

@Yoav, paypal requested a test site they could use for determining
independently if the feature was activated for their testing. I provided
them with a glitch.me <https://splashy-broadleaf-carp.glitch.me/> site that
shows if an A1->B->A2 embed is receiving cookies set in the top level site.
If I don't hear back from them by the middle of next week, I'll reach out
for a status update from them.



On Wed, May 22, 2024 at 11:39 AM Chris Harrelson 
wrote:

> Please also fill out the Testing section on chromestatus.com.
>
> On Wed, May 22, 2024 at 7:50 AM 'Aaron Selya' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Had a good initial conversation with them on Monday letting them know
>> about the issue. They're going to do some testing with the feature enabled
>> to try and gauge the impact the feature will have on their backend. I'm
>> hopeful that they'll give us an update by early next week.
>>
>> On Wed, May 22, 2024 at 10:21 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> Any news from Paypal?
>>>
>>> On Friday, May 3, 2024 at 7:15:58 PM UTC+2 Aaron Selya wrote:
>>>
>>>> Thank you for suggesting a deeper dive into this Yoav as I might not
>>>> have discovered the significant impact that the
>>>> "receive-cookie-deprication" cookies were having on my metrics without your
>>>> prompting.
>>>>
>>>> I've reached out to some engineers at Paypal and hopefully they'll get
>>>> back to me sometime next week.
>>>>
>>>> On Fri, May 3, 2024 at 8:50 AM Yoav Weiss (@Shopify) <
>>>> yoavwe...@chromium.org> wrote:
>>>>
>>>>> Thanks for diving into this!!
>>>>>
>>>>> I guess the scariest bit here would be paypal losing a cookie in the
>>>>> redirect. Even if you didn't find a visible impact in your testing, they
>>>>> may not be exhaustive, and breakage there feels riskier than in other
>>>>> mentioned domains.
>>>>>
>>>>> Have you tried to reach out to Paypal folks and see what they say?
>>>>>
>>>>> On Wed, May 1, 2024 at 8:05 PM Aaron Selya  wrote:
>>>>>
>>>>>> My apologies for the delay in following up on this.
>>>>>>
>>>>>> When I finished my initial implementation and got to the point where
>>>>>> I could begin testing, I found that my metrics were being flooded with a
>>>>>> cookie named, "receive-cookie-deprication". After doing some research and
>>>>>> testing I learned that this cookie is used by sites for testing the
>>>>>> potential impact of third party cookie depreciation but doesn't have any
>>>>>> impact on website functionality. To get a better sense of potential
>>>>>> breakage, I landed updated metrics that filtered out that cookie. I then
>>>>>> conducted a manual audit on 10 (of the 104) sites that indicated a 
>>>>>> possible
>>>>>> impact with a build of chromium that had the finch flag turned on.
>>>>>>
>>>>>> I've summarized my findings in this slide deck
>>>>>> <https://docs.google.com/presentation/d/1S2N2vyGDaKAwP-5W5pVYqRNQ1RQndjlq4yVTny6hEIY/edit?usp=sharing>
>>>>>> but I was unable to find a breakage that caused a site to not perform as
>>>>>> expected from the user's perspective. To be clear, this doesn't mean that
>>>>>> there won't be breakage that occurs if/when this feature goes live, only
>>>>>> that I was unable to find an example where the website was unable to
>>>>>> perform as expected.
>>>>>>
>>>>>> Additionally, with the filtering out of the
>>>>>> "receive-cookie-deprication" cookie from the metrics, the occurrences of 
>>>>>> an
>>>>>> A1->B-A2 cookie which this change would impact drops from 0.032% of 
>>>>>> overall
>>>>>> page loads to 0.0012% of overall page loads.
>>>>>>
>>>>>
>>>>> That's extremely reassuring!
>>>>>
>>>>>
>>>>>>
>>>>>> On Tue, Mar 19, 2024 at 12:05 PM Aaron Selya 
>>>>>> wrote:
>>>>>>
>>>>>>> Yo

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

2024-06-06 Thread &#x27;Aaron Selya&#x27; via blink-dev
I haven't heard back from Paypal yet, I'm planning on following up with
them today to see if they have any updates on their testing.

Besides hearing back from them, is there any other information that's
holding up LGTM?

On Thu, May 30, 2024 at 1:53 PM Aaron Selya  wrote:

> @Chris, completed the testing section as requested.
>
> @Yoav, paypal requested a test site they could use for determining
> independently if the feature was activated for their testing. I provided
> them with a glitch.me <https://splashy-broadleaf-carp.glitch.me/> site
> that shows if an A1->B->A2 embed is receiving cookies set in the top level
> site. If I don't hear back from them by the middle of next week, I'll reach
> out for a status update from them.
>
>
>
> On Wed, May 22, 2024 at 11:39 AM Chris Harrelson 
> wrote:
>
>> Please also fill out the Testing section on chromestatus.com.
>>
>> On Wed, May 22, 2024 at 7:50 AM 'Aaron Selya' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Had a good initial conversation with them on Monday letting them know
>>> about the issue. They're going to do some testing with the feature enabled
>>> to try and gauge the impact the feature will have on their backend. I'm
>>> hopeful that they'll give us an update by early next week.
>>>
>>> On Wed, May 22, 2024 at 10:21 AM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>
>>>> Any news from Paypal?
>>>>
>>>> On Friday, May 3, 2024 at 7:15:58 PM UTC+2 Aaron Selya wrote:
>>>>
>>>>> Thank you for suggesting a deeper dive into this Yoav as I might not
>>>>> have discovered the significant impact that the
>>>>> "receive-cookie-deprication" cookies were having on my metrics without 
>>>>> your
>>>>> prompting.
>>>>>
>>>>> I've reached out to some engineers at Paypal and hopefully they'll get
>>>>> back to me sometime next week.
>>>>>
>>>>> On Fri, May 3, 2024 at 8:50 AM Yoav Weiss (@Shopify) <
>>>>> yoavwe...@chromium.org> wrote:
>>>>>
>>>>>> Thanks for diving into this!!
>>>>>>
>>>>>> I guess the scariest bit here would be paypal losing a cookie in the
>>>>>> redirect. Even if you didn't find a visible impact in your testing, they
>>>>>> may not be exhaustive, and breakage there feels riskier than in other
>>>>>> mentioned domains.
>>>>>>
>>>>>> Have you tried to reach out to Paypal folks and see what they say?
>>>>>>
>>>>>> On Wed, May 1, 2024 at 8:05 PM Aaron Selya  wrote:
>>>>>>
>>>>>>> My apologies for the delay in following up on this.
>>>>>>>
>>>>>>> When I finished my initial implementation and got to the point where
>>>>>>> I could begin testing, I found that my metrics were being flooded with a
>>>>>>> cookie named, "receive-cookie-deprication". After doing some research 
>>>>>>> and
>>>>>>> testing I learned that this cookie is used by sites for testing the
>>>>>>> potential impact of third party cookie depreciation but doesn't have any
>>>>>>> impact on website functionality. To get a better sense of potential
>>>>>>> breakage, I landed updated metrics that filtered out that cookie. I then
>>>>>>> conducted a manual audit on 10 (of the 104) sites that indicated a 
>>>>>>> possible
>>>>>>> impact with a build of chromium that had the finch flag turned on.
>>>>>>>
>>>>>>> I've summarized my findings in this slide deck
>>>>>>> <https://docs.google.com/presentation/d/1S2N2vyGDaKAwP-5W5pVYqRNQ1RQndjlq4yVTny6hEIY/edit?usp=sharing>
>>>>>>> but I was unable to find a breakage that caused a site to not perform as
>>>>>>> expected from the user's perspective. To be clear, this doesn't mean 
>>>>>>> that
>>>>>>> there won't be breakage that occurs if/when this feature goes live, only
>>>>>>> that I was unable to find an example where the website was unable to
>>>>>>> perform as expected.
>>>>>>>
>>>>>>> Additionally, with the filter

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

2024-06-12 Thread &#x27;Aaron Selya&#x27; via blink-dev
Daniel,
My initial metrics were significantly higher due to the presence of a
cookie named “receive-cookie-deprication”. This is a cookie
<https://developers.google.com/privacy-sandbox/relevance/setup/web/chrome-facilitated-testing#access_the_sec-cookie-deprecation_http_header>,
Google is using to help sites prepare for third-party cookie depreciation.
It does not actually impact site functionality or cause site breakage,
which is what the metrics were designed to try and identify. After
filtering those cookies from the metrics, the usage rate dropped down to
0.0012% of page loads. This figure was shared as a part of my update on May
1st.

My intention with the statement regarding excluding cases from the count,
was to handle a situation where the metrics were being significantly
impacted by a single identifiable case. In which the cookie that triggered
the metrics could be proven to not have an impact on site behavior or cause
breakage. This exact scenario occurred with the
“receive-cookie-deprication” and was part of my justification for filtering
that cookie from the metrics.

On Wed, Jun 12, 2024 at 7:55 AM Daniel Bratell  wrote:

> From my point of view, the only concern is web compatibility. We need to
> prove to ourselves that this is web compatible enough to ship and
> unfortunately the use counters are a bit high (0.032%) . You have done
> further analysis so we know that the actual risk is lower than that but is
> it low enough?
>
> You have mentioned that the counter would be lower if certain cases are
> excluded, but I am not sure I understand if that was just informative or if
> you consider giving those sites an exemption?
>
> Since this thread has been going a while I might have misunderstood parts,
> so maybe you can give an update or summary of the web compatibility risk?
>
> /Daniel
>
>
> On 2024-06-07 21:44, 'Aaron Selya' via blink-dev wrote:
>
> Devtools updates have landed (see attached screenshot) and are available
> in Canary.
>
> On Thu, Jun 6, 2024 at 9:44 AM Aaron Selya  wrote:
>
>> I haven't heard back from Paypal yet, I'm planning on following up with
>> them today to see if they have any updates on their testing.
>>
>> Besides hearing back from them, is there any other information that's
>> holding up LGTM?
>>
>> On Thu, May 30, 2024 at 1:53 PM Aaron Selya  wrote:
>>
>>> @Chris, completed the testing section as requested.
>>>
>>> @Yoav, paypal requested a test site they could use for determining
>>> independently if the feature was activated for their testing. I provided
>>> them with a glitch.me <https://splashy-broadleaf-carp.glitch.me/> site
>>> that shows if an A1->B->A2 embed is receiving cookies set in the top level
>>> site. If I don't hear back from them by the middle of next week, I'll reach
>>> out for a status update from them.
>>>
>>>
>>>
>>> On Wed, May 22, 2024 at 11:39 AM Chris Harrelson 
>>> wrote:
>>>
>>>> Please also fill out the Testing section on chromestatus.com.
>>>>
>>>> On Wed, May 22, 2024 at 7:50 AM 'Aaron Selya' via blink-dev <
>>>> blink-dev@chromium.org> wrote:
>>>>
>>>>> Had a good initial conversation with them on Monday letting them know
>>>>> about the issue. They're going to do some testing with the feature enabled
>>>>> to try and gauge the impact the feature will have on their backend. I'm
>>>>> hopeful that they'll give us an update by early next week.
>>>>>
>>>>> On Wed, May 22, 2024 at 10:21 AM Yoav Weiss (@Shopify) <
>>>>> yoavwe...@chromium.org> wrote:
>>>>>
>>>>>> Any news from Paypal?
>>>>>>
>>>>>> On Friday, May 3, 2024 at 7:15:58 PM UTC+2 Aaron Selya wrote:
>>>>>>
>>>>>>> Thank you for suggesting a deeper dive into this Yoav as I might not
>>>>>>> have discovered the significant impact that the
>>>>>>> "receive-cookie-deprication" cookies were having on my metrics without 
>>>>>>> your
>>>>>>> prompting.
>>>>>>>
>>>>>>> I've reached out to some engineers at Paypal and hopefully they'll
>>>>>>> get back to me sometime next week.
>>>>>>>
>>>>>>> On Fri, May 3, 2024 at 8:50 AM Yoav Weiss (@Shopify) <
>>>>>>> yoavwe...@chromium.org> wrote:
>>>>>>>
>>>>>>>