Scope of phasing out of third-party cookies

[vishparshav]

Hi, I would like to understand the scope of the cookies covered in third-party cookie deprecation based on my testing with enabling the flag to test for breakage as described in https://developer.chrome.com/docs/privacy-sandbox/third-party-cookie-phase-out/#test on multiple websites that we own.

Background

We have a cookie X on domain Y set by a fetch POST call to origin Y from first party website domain A. The cookie is set with SameSite=None and Secure flag. The cookie is also set with HttpOnly flag to make sure that it is not accessible by Javascript on website.

Observation

Even though X being a third-party cookie I am still able to see the cookie X sent in fetch POST request to origin Y from website A. We have no iframe or embedded content on website A that would try to access the cookie which will anyway be not possible as the cookie is set with HttpOnly flag.

Query

• Is cookie X going to be treated as third-party cookie and supposed to be blocked?

  • As mentioned in https://developer.chrome.com/docs/privacy-sandbox/third-party-cookie-phase-out/#understand-your-third-party-cookies Cookies that are sent in cross-site contexts, like iframes or subresource requests, are generally referred to as third-party cookies. but this cookie is not sent in any embedded context so is exempted from third-party cookie block?

• Similarly on https://developer.chrome.com/docs/privacy-sandbox/third-party-cookie-phase-out/#understand-your-third-party-cookies If the cookie you're setting is not used across sites, for example, it's used to manage sessions on your site and it's never used in a cross-site iframe, that cookie is always used in a first-party context., can a third party cookie be used in First party context? Is there a distinction between third party cookie and third party context?

[johannhof]

From how you're describing this it feels like the cookie should be blocked, but what you'll observe really depends on how you observe it. For example, the Set-Cookie response header will not be stripped from the request and will be visible e.g. in DevTools, however, the cookie will not be stored in the browser.

If you're not hosting an iframe or any other means of reading the cookie, how do you know it is not blocked?

[vishparshav]

I can see the cookie being set in the browser on domain Y. We are also able to read the cookie on service side when a fetch API call is made to origin Y which also matches with the cookie being sent in request header.

On Thu, Nov 30, 2023 at 6:05 AM Johann Hofmann @.***> wrote:

From how you're describing this it feels like the cookie should be blocked, but what you'll observe really depends on how you observe it. For example, the Set-Cookie response header will not be stripped from the request and will be visible e.g. in DevTools, however, the cookie will not be stored in the browser.

If you're not hosting an iframe or any other means of reading the cookie, how do you know it is not blocked?

— Reply to this email directly, view it on GitHub https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues/191#issuecomment-1833846179, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCVDQOWVBJPYSVYLQS4XETYHCHEBAVCNFSM6AAAAABAAMB3XKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZTHA2DMMJXHE . You are receiving this because you authored the thread.Message ID: @.*** .com>

[johannhof]

Hmm, could you host a simple example, for example on glitch.com, of how you're trying to read / write this cookie? Also, to confirm, you're using the test-third-party-cookie-phaseout flag?

[vishparshav]

yes, test-third-party-cookie-phaseout is enabled in this testing.

[clementsimon]

Hi @vishparshav, bumping this to check if you'd be able to share an example?

[vishparshav]

Hi, Thanks for following up on this. I had setup an example https://classy-oasis-estimate.glitch.me/ to simulate this behavior. On the page load this page will send a request to another domain https://gold-uncovered-headline.glitch.me/set-cookie to set a third party cookie. But I am seeing the cookie being blocked and not able to simulate the behavior seen on our end.

Is there a way I can sync with you offline on this?

[whitehatguy]

@vishparshav - In your example, both domains share an eTLD+1 and are thus considered to be "samesite". For purposes of third-party cookie phaseout, "third-party" means domains that are not "samesite".

If the second domain in your example were to be gold-uncovered-headline.glitch2.me, then I would expect the cookie to be blocked.

[vishparshav]

I am seeing the cookies being blocked when a call to https://gold-uncovered-headline.glitch.me/set-cookie is made from https://classy-oasis-estimate.glitch.me

This is an example similar to what we have on our side where you can consider call being made to https://gold-uncovered-headline.glitch2.me metaphorically and I am seeing the cookies being passed with no issues whatsoever.

[whitehatguy]

This is an example similar to what we have on our side where you can consider call being made to https://gold-uncovered-headline.glitch2.me/ metaphorically and I am seeing the cookies being passed with no issues whatsoever.

glitch2.me is not in the same eTLD+1 as glitch.me, hence the difference. Here's a great blog post that explains the difference.

[johannhof]

Somewhat confusingly, classy-oasis-estimate.glitch.me and gold-uncovered-headline.glitch.me are actually not same site, because glitch.me is on the PSL. So, those cookies are expected to be blocked, yes. And yeah, I can see them being blocked when I try this as well.

So, @vishparshav, it sounds like there's something off with your specific setup, maybe you are actually using two same-site domains (like you would be here if it wasn't for the PSL)? It would be great if you could share additional details, if you want to go into full detail on your breakage you can also file a new breakage tracking bug at https://goo.gle/report-3pc-broken and we can take a look.

[samdutton]

FWIW I built a tool to help work out what constitutes "site": url-parts.glitch.me

This is included in the article web.dev/articles/url-parts

[shuranhuang]

• Is cookie X going to be treated as third-party cookie and supposed to be blocked?

This cookie X is sent by subresource request, and is considered a third-party cookie if domain Y and domain A are cross-site to each other, thus should be blocked with test-third-party-cookie-phaseout flag enabled.

There could be some user settings that unblock a third-party cookie that should have been blocked. To tell whether this is the case, starting M123, in the DevTools Network panel cookie table, there will be an info label indicating why the third-party cookie is unblocked. E.g. https://developer.chrome.com/blog/new-in-devtools-123/?utm_source=devtools

• ... can a third party cookie be used in First party context? Is there a distinction between third party cookie and third party context?

"Third-party context" is another way to describe "cross-site context." Cookies with the SameSite=None; Secure and not Partitioned attributes that operate in cross-site contexts are third-party cookies.

[vishparshav]

@shuranhuang

Thanks for the update.

I see "This cookie is allowed by user preference" as the exception reason. I have test-third-party-cookie-phaseout flag enabled and "Block all third party cookie" option also enabled in Tracking Protection but still this is allowed due to user preference. Also tested this on a different machine to verify.

The link shared does not explain about user preference. Can you please comment what preference could be allowing the 3P cookie here or if I am missing something here?

Attaching screenshots for the configurations and message

[shuranhuang]

Glad to know the information is helpful in some degree:) @samdutton do you know if there is any short link / material we can use to explain the "user preference" for 3PCD?

@vishparshav with 3PCD enabled, there are currently a few ways to unblock third-party cookies for certain use cases (more can be found in https://developers.google.com/privacy-sandbox/3pcd/temporary-exceptions/preserving-critical-user-experiences). The "user preference" reason means the cookie is unblocked by user with exception settings explicitly. To find those settings, you can take a look at the "sites allowed to use third-party cookies" section under chrome://settings/trackingProtection and see if there is an exception for your testing domain.

[vishparshav]

@shuranhuang I dont see any domain allowed in my "sites allowed to use third-party cookies" section. Here is the attached screenshot.

[shuranhuang]

Thanks for providing the screenshot.

It's possible that this is due to your enterprise policy setup that's using CookiesAllowedForUrls to unblock 3p cookies. To verify, could you take a look at chrome://policy and see if CookiesAllowedForUrls is listed and has your testing domain listed in the value field?

The reason you see "This cookie is allowed by user preference" as the exception reason in the DevTools could be due to a bug we found out recently - differentiating 3p cookies unblocked by "enterprise policy" from "user preference" does not work properly.

[vishparshav]

@shuranhuang Thanks for guidance on this. I was able to find the enterprise policy on my machine which was allowing the 3P cookie to be set. When tested on non-enterprise machine I could see the cookie being blocked. Thanks for the help!

[samdutton]

Closing this as completed, since no further comment in more than four months, but feel free to reopen if necessary.