How would you use CHIPS to isolate sessions for an embedded cross-site widget?

Question and scenario

The widget is served by support.example and embedded by top-level sites such as shop-a.example and shop-b.example. It should retain a session across product, checkout, and help pages under shop-a.example, while shop-b.example receives isolated state. The design must account for restricted third-party cookies, older browsers, logout, agent handoff, and multiple tabs.

What the interviewer is testing

• Does the candidate understand that CHIPS keys a cookie by both the top-level site and embedded origin?
• Can they distinguish per-site persistent state from unpartitioned third-party state that requires user permission?
• Can they connect cookie design, server sessions, CSRF, replay protection, and logout into one data flow?
• Do they cover capability detection, legacy fallback, cache keys, and observability?

Clarifying questions to ask first

Confirm HTTPS, whether the widget must identify one person across top-level sites, whether subdomains share a session, and whether a top-level login page is acceptable. Clarify data sensitivity, session lifetime, server push, and target browsers. If the business truly needs cross-site identity, CHIPS alone is not the mechanism; use explicit login or authorization.

A 30-second answer framework

I would define the session as belonging to one top-level site. The widget sets a secure cookie with Partitioned, and the server resolves state using the top-level site and widget session; subdomains of one site share that partition, while another site gets a different one. The cookie is not a cross-site identity credential. Cross-site login uses a top-level authorization flow. When CHIPS is unavailable, run without persistent state or ask the user to authorize explicitly. Verify logout, CSRF, cache isolation, and multi-tab behavior end to end.

Step-by-step deep dive

1. Define the trust boundary. Treat the embedding site as partition context, not as an authorization decision derived from an Origin string. Keep an allowlist and validate message origin, tenant, and session state.
2. Set a partitioned cookie. Use Secure, an appropriate SameSite value, and Partitioned; prefer the __Host prefix when binding to the current host. The logical cookie key includes the embedded origin and top-level site, so the same widget cannot read one cookie across two top-level sites.
3. Design the server session. Store only a random opaque identifier in the cookie. The server session records tenant, top-level site, creation time, expiry, and revocation version. Recheck the binding on every request instead of trusting browser partitioning alone.
4. Handle subdomains and caches. Subdomains can reuse one top-level partition, but HTML, script, and API cache keys must include tenant or session variation. Use private caching or an explicit Vary policy for personalized responses; never let a CDN serve one site's state to another.
5. Design login and authorization. When the same person must be recognized, open a top-level login page and return a short-lived, one-time authorization code. Never put a long-lived token in a URL, postMessage, or an unpartitioned cookie.
6. Provide fallback and observability. Run in a no-session mode or request explicit authorization when support is missing; do not silently restore a global third-party cookie. Track partition-cookie hit rate, authorization success, and session creation or revocation reasons without logging cookie values or tokens.

High-quality sample answer

I would use CHIPS for the boundary of preserving widget state within one top-level site. support.example sets a cookie with Secure, SameSite=None, and Partitioned; it stores only an opaque session identifier. The server session binds tenant, top-level site, expiry, and revocation version. Subdomains under shop-a.example reuse one partition, while shop-b.example naturally receives another state.

Cross-site identity does not rely on that cookie. The widget opens a top-level page for login, obtains a one-time authorization code after user action, and exchanges it for a short-lived session in the current partition through a validated message channel. If an older browser or policy blocks partitioned cookies, the widget offers a no-session experience or explicit authorization instead of falling back to a global third-party cookie. Test two top-level sites, subdomains, logout, expiry, concurrent tabs, caching, CSRF, forged messages, and privacy settings. Primary references are MDN's CHIPS and Storage Access API documentation and Privacy Sandbox's CHIPS explanation.

Common mistakes

• Treating a Partitioned cookie as a cross-site single-sign-on credential, defeating isolation.
• Authorizing from Origin alone while ignoring tenant binding, revocation, CSRF, and replay.
• Silently using an unpartitioned third-party cookie when CHIPS is unavailable, causing leakage or blocking.
• Omitting CDN, Service Worker, or proxy cache variation and serving one site's personalized response to another.
• Putting long-lived tokens in URLs, postMessage, or frontend-readable cookies.

Follow-up questions and responses

When would you use CHIPS versus the Storage Access API?

Use CHIPS for independent embedded state per top-level site. Use Storage Access API when there is a justified need for unpartitioned third-party state and the user can grant permission, such as explicit sign-in. Their privacy boundaries differ, so one is not a silent substitute for the other.

How do you prove two top-level sites cannot share a session?

Embed the widget in both sites in the same browser and record session identifiers, server tenant bindings, and cache hits. Clearing one site's cookie, logging out, opening a new tab, and switching subdomains must never change the other site's state.

What if the product insists on recognizing one person across sites?

Upgrade the requirement to explicit identity authorization: top-level login, a short-lived one-time code, server exchange, and revocable sessions. Record consent and failures instead of creating a hidden cross-site tracking channel.