Partitioned Does Not Mean Cookie-Free: What CHIPS Actually Changes for Embedded Services

An embedded chat remembers a conversation, a payment widget keeps the checkout step, and a map stores a preference. Some third-party services genuinely need state. The problem begins when the same cookie can be reused across many unrelated websites.

CHIPS – Cookies Having Independent Partitioned State – gives browsers a narrower boundary. A cookie with Partitioned is stored not only by its cookie host but also by the top-level site. The same embedded service can therefore receive separate cookie state on two different websites.

That is useful. It does not mean “cookie-free,” and it does not automatically mean “privacy compliant.”

What Partitioned changes in practice

Google and PrivacyCG describe CHIPS as double-keying: cookie host plus the top-level site's partition key. For common cross-site embeds, the cookie is set with Partitioned, Secure, and usually SameSite=None. Google also recommends the __Host- prefix when the cookie should remain bound to one host.

The important effect is simple: a cookie created by widget.example while embedded on shop-a.example is not automatically available as the same state when the widget appears on shop-b.example.

That makes CHIPS a good fit for chat, maps, embedded payments, or SaaS widgets that need local state without requiring one global browser identity across unrelated sites.

Three audit questions that expose most problems

1. Does the service need local state or global recognition?

If a widget only needs settings or a session inside your website, a globally reusable third-party identifier is difficult to justify technically. Audit the purpose of each cookie, not merely its name.

A cookie called session might contain local UI state – or it might represent a global account identity. The header alone does not tell you.

2. What happens when CHIPS is unavailable?

MDN now lists CHIPS as a Baseline feature while still warning about older browsers. WebKit shipped CHIPS again in Safari 26.2 after it had been temporarily removed. Browser storage behavior remains a compatibility concern.

More importantly, Google's documentation notes that SameSite=None can let the cookie behave as an unpartitioned third-party cookie in a client that does not support Partitioned, provided third-party cookies are otherwise allowed.

A configuration can therefore be narrowly partitioned in current browsers while falling back to broader behavior in older clients. That fallback belongs in the audit.

3. Does the backend understand the new identity model?

CHIPS is not only a browser flag. If a backend previously treated the cookie as a global browser identifier, partitioning can change login, logout, support history, rate limits, fraud signals, or basket state.

That can be exactly the desired outcome. It still needs to be intentional.

The practical two-site test

Use two different top-level sites with the same embedded provider:

1. Open site A in a fresh browser profile and create a visible state.
2. Open site B with the same third-party embed.
3. Check whether B sees A's state.
4. Return to A and verify that A still has its own state.
5. Repeat with a client or configuration where Partitioned is unsupported or ineffective.

With correctly partitioned state, A should retain its own state while B receives a separate partition.

Red flags

Investigate these patterns:

• The same cookie name exists in both partitioned and unpartitioned forms.
• Logout removes only one variant and stale sessions survive.
• The widget works only because an old global third-party cookie already exists.
• Documentation treats Partitioned as a synonym for “anonymous” or “tracking impossible.”
• The provider combines the partitioned cookie with global account or device identifiers on the server.
• Nobody has tested behavior before consent, after rejection, after acceptance, and after later withdrawal.

Partitioning reduces the reach of one cookie state. It does not automatically prevent other recognition or server-side correlation.

CHIPS or Storage Access API?

CHIPS is useful when state should remain isolated per top-level site. If a service genuinely needs the same unpartitioned account state across several sites, CHIPS is intentionally the wrong mechanism. Google points to the Storage Access API and related approaches for those scenarios.

The architecture question comes first: should this state be shared, or should it stay separate?

What Website-Pflichtencheck would inspect

A technical cookie and embed review can establish:

• which third parties are actually embedded,
• which cookies they set in production,
• whether Partitioned, Secure, SameSite, and host scope fit together,
• whether state really remains separated across two unrelated sites,
• how older browsers and fallbacks behave,
• whether session, logout, and deletion logic handle partitions correctly,
• how consent changes affect requests and stored state,
• whether technical documentation matches real browser behavior.

The goal is not to add a fashionable attribute everywhere. The goal is a clear statement for every embed: what state must exist, where may it be reused, and what happens outside the ideal browser path?

Note: This article is a technical overview and not legal advice. Whether a particular cookie or data flow requires consent or is subject to other legal requirements depends on its actual purpose, the information processed, and the specific context.