About Treasure AI and Cookie Tracking

Safari, Chrome, Firefox, and Edge each enforce their own rules for how long a cookie survives, whether a third-party cookie is allowed at all, and whether values written with JavaScript (localStorage, IndexedDB) persist without user interaction. Apple calls its version Intelligent Tracking Prevention (ITP); Firefox calls its version Enhanced Tracking Protection (ETP) and Total Cookie Protection (TCP); Chrome and Edge apply no such interaction-based restriction by default as of 2026, though both still cap every cookie's maximum lifetime to 400 days regardless of the value requested (see below). These rules directly govern how long td_client_id, td_global_id, and td_ssc_id — the identifiers the Treasure Data JavaScript SDK uses to recognize a returning visitor — survive on a given browser, and whether an identifier can be shared across domains at all. Read this page before you decide how to configure client-side tracking, server-side cookies, or cross-domain tracking.

Cookies remain central to how Treasure AI recognizes a returning visitor and delivers personalization on your website, so a browser tightening its cookie rules is a business problem for your personalization program, not only a technical detail. Treasure AI continues to monitor how each browser's restrictions evolve and works with you to find options that support both your organization's privacy obligations and its personalization goals.

Five mechanisms account for nearly every cookie behavior difference between browsers:

• Third-party cookie blocking. A cookie whose domain differs from the site in the address bar is a third-party cookie. Safari blocks these outright, with no exceptions, since Safari 13.1 (March 2020). Firefox does not block them outright but isolates them (see Total Cookie Protection, below). Chrome and Edge allow them by default.
• Client-side (JavaScript) cookie expiration caps. A cookie written with document.cookie is treated differently from one set by an HTTP Set-Cookie response header, because a browser can distinguish script-writable storage from server-controlled storage. Safari caps script-set cookies, localStorage, and IndexedDB to 7 days without user interaction with the site.
• Server-side cookie caps and cloaking detection. A cookie set by an HTTP response header from a genuine first-party server persists far longer than a script-set cookie, close to its full configured lifetime. Safari has detected CNAME cloaking since Safari 14 (November 2020), and added IP-address cloaking detection in Safari 16.4 (April 2023): when a subdomain's DNS record or the IP address serving it doesn't correspond to the site's own infrastructure, Safari treats the cookie as if it were set by a disguised third party and caps it to the same 7 days as a script-set cookie. This is why delegating a subdomain's DNS to a tracking vendor — the exact pattern behind server-side first-party cookies — is capped rather than exempt.
• Absolute cookie lifetime cap in Chrome and Edge. Independent of any ITP-style interaction requirement, Chrome and Edge enforce the updated cookie specification (RFC 6265bis): since Chrome 104 (August 2022), any cookie's Expires/Max-Age — whether set with document.cookie or an HTTP Set-Cookie header, first-party or third-party — is silently clamped to a maximum of 400 days from when it's set. A cookie configured for a longer lifetime, such as two years, still expires after 400 days unless the visitor returns before then and the cookie gets refreshed. Firefox has not adopted this cap for ordinary website cookies as of 2026, and Safari's own caps (above) are stricter than 400 days in every case they apply to.
• Link-decoration caps. When a visitor lands on a page from a URL containing a known tracker's click-ID parameter (gclid, fbclid, and similar), Safari drops the script-set cookie cap on that landing page from 7 days to 24 hours.

td_client_id is a first-party cookie the JavaScript SDK writes with document.cookie by default. Firefox imposes no cap at all on a genuine first-party cookie, so it persists for its full configured expiration (2 years by default — see config.storage.expires) or until the visitor clears cookies. Chrome and Edge impose no ITP-style cap either, but silently clamp that same configured expiration to a maximum of 400 days under the updated cookie specification (RFC 6265bis). Safari caps it to 7 days without a return visit — the reason a server-side cookie exists as an alternative.

td_global_id only serves its purpose — the same ID on every domain a customer owns — if the browser allows a shared third-party cookie. Chrome and Edge allow it, since both still permit third-party cookies by default. Safari never allows it: third-party cookies have been fully blocked since Safari 13.1, with no configuration that restores them. Firefox sets the cookie, but Total Cookie Protection isolates it per top-level site, so the value is not actually shared across the customer's domains — see Enabling Cross-Domain Tracking for how this affects the feature.

td_ssc_id is designed to outlive Safari's 7-day document.cookie cap by having a server set the cookie in an HTTP response header instead of JavaScript. Because Treasure Data's server-side cookie service answers on a subdomain your DNS delegates to it, Safari has classified this pattern as CNAME cloaking and capped it to 7 days since Safari 14 (November 2020). See the known limitation on that page before you plan around a longer lifetime. In Chrome and Edge, td_ssc_id isn't subject to cloaking detection, but it's still clamped to a maximum of 400 days under RFC 6265bis regardless of its configured expiration.

Segments activated through third-party cookies can be affected, depending on how the destination classifies the cookie. Work with your activation partner to evaluate the impact for each destination.

Attribution becomes harder on Safari because the identifiers used to connect an ad impression to a later conversion are more fragmented — a td_global_id set on an ad partner's domain can't be read back on your site.

Consent is typically stored as a client-side cookie, which means it inherits the same caps described above. The JavaScript SDK also supports storing consent in localStorage instead — see Specifying the Consent Record Location.

td_client_id persists across subdomains of the same top-level domain regardless of these restrictions, because that persistence depends on the cookie's domain scope, not on ITP, ETP, or TCP.

• Tracking Server-Side First-Party Cookies on Your Website
• Enabling Cross-Domain Tracking With JavaScript SDK
• Anonymous Visitor IDs With JavaScript SDK
• Browsers That Support 3rd Party Cookies and TD JavaScript SDK