Incorrect blocked reason for lazy third-party cookies.

[lcrespilho]

Describe the bug
When blocked, the cookie NID at .google.com is not classified as third-party. His blocked reason is just "ExcludeThirdPartyPhaseout", but it should also be "ThirdPartyPhaseout". The apparent reason is that this cookie is set too late after the page loads: about 30 seconds.

To Reproduce
Steps to reproduce the behavior:

1. Open Chrome via helper chrome-3pcd-ps.
2. Open the page https://domain-aaa.com/embedded-video.
3. Wait for about 32 seconds (don't need to interact with the video) until the POST request https://play.google.com/log?format=json&hasfast=true&authuser=0 is made. This request brings the Set-Cookie NID=[hash]; expires=[date]; path=/; domain=.google.com; Secure; HttpOnly; SameSite=none header to set the NID cookie.

Expected behavior
The NID cookie is blocked and the PSAT extension should classify this blockage as ThidPartyPhaseout and ExcludeThirdPartyPhaseout, but is classifying only as ExcludeThirdPartyPhaseout.

Screenshots

Desktop (please complete the following information):

• OS: MacOS Sonoma 14.4.1
• Browser: Chrome
• Version: 124.0.6367.80 (Official Build) (arm64)

Additional context
PSAT System Information:
Open Tabs: 1
Active Extensions:
Google Docs Offline: ghbmnnjooekpmoecnnnilnnbdlolhkhi
Privacy Sandbox Analysis Tool: ikodlagpencphdljdpelmcajjlloiomb
Chrome Version: Version 124.0.0.0 (arm64)
PSAT Version: 0.7.0
OS - System Architecture: MacOS (arm64)

[milindmore22]

Hello @lcrespilho,

Thanks for reaching out! That's a very intriguing point about the NID cookie. It is used to serve Google Ads to signed-out users.

Here's what, we think, might be happening. It's possible the NID cookie is being categorized as ExcludeThirdPartyPhaseout because its creation might be delayed by Google services. This delay could cause the cookie to be classified differently than intended.

We'll definitely investigate this further and see why it's being categorized in this way. We'll get back to you soon with an update.

[milindmore22]

Hello @lcrespilho

The ThirdPartyPhaseout and ExcludeThirdPartyPhaseout achieve similar goals, there’s a key difference in how they’re filtered out. To understand this better, let’s explore how Audits and the Network API handle cookie information:

Audits: They might flag entries with an “exclude” status. This typically indicates an event that was filtered out for specific reasons during the auditing process. Audits wouldn’t necessarily provide details on the reason for exclusion.

Network API: This API focuses on providing details about network requests and responses. It might return a “reason” field that explains why a request was blocked or failed. There wouldn’t be an “exclude” flag in this context.

To streamline the process, we’re proposing to unify the blocking reason for these scenarios. We’ll actively address this in an upcoming version by implementing the necessary changes.