How a Supercookie Persists Across Browser Resets

A standard HTTP cookie is a small text file written to a designated folder on a device's file system. When a user clears cookies or closes a private browsing session, the browser deletes that file and the tracking state it carried. A supercookie operates on a different principle: it encodes an identifier into one or more storage locations that a standard cookie-clearing operation does not reach, allowing a tracking signal to survive resets that most users expect to be final.

The term "supercookie" is informal and covers several distinct technical mechanisms — HSTS-based tracking, ETag abuse, cached resource fingerprinting, and network-level identifiers injected by carriers — that share a single functional property: persistence beyond the browser's own storage management boundary. Understanding how each mechanism works requires examining where the browser stores state, which clearing operations touch which stores, and which stores are left intact.

How Supercookie Persistence Is Engineered Into Browser Storage

The most widely documented browser-side supercookie technique exploits HTTP Strict Transport Security (HSTS). When a server sends an HSTS header, the browser records a policy entry stating that the host must be contacted over HTTPS for a defined period. An attacker-controlled or analytics-controlled server can encode a unique identifier across a set of subdomains by selectively setting HSTS policies on some subdomains and not others. On a return visit, a script tests each subdomain: subdomains with an HSTS entry respond with a redirect, subdomains without one do not. The pattern of redirects and direct responses encodes a binary number — the identifier — without writing any data to the cookie store. Because HSTS entries live in the browser's security policy cache rather than its cookie jar, clearing cookies does not erase them.

A second mechanism uses HTTP ETags. When a browser requests a resource, the server may return an ETag header containing a unique string that represents that version of the resource. The browser stores this ETag and sends it back on subsequent requests in an If-None-Match header. A tracking server can issue a unique ETag per visitor and read it back on every subsequent request, reconstructing the visitor's identity from the browser's own cache validation mechanism. Clearing cookies does not clear the HTTP cache, so the ETag persists until the cache is explicitly flushed.

A third technique uses the browser's cache itself as a storage medium. A tracking script loads a uniquely named or uniquely parameterized resource — a 1×1 image, a JavaScript file, a font — and on a return visit checks whether the resource is already in cache by measuring load time or by using the Resource Timing API. A cache hit indicates a returning visitor; the cached resource's URL encodes the identifier. This is sometimes called a "cache cookie" and survives standard cookie deletion for the same reason as ETag abuse: the HTTP cache is a separate store.

At the network layer, some mobile carriers have historically injected a Unique Identifier Header (UIDH) into HTTP requests as they pass through the carrier's infrastructure. This header is invisible to the user and is added after the request leaves the device, meaning no browser-level clearing operation can remove it. The identifier persists at the carrier level and is attached to every unencrypted HTTP request the device makes. HTTPS connections prevent injection because the carrier cannot modify the encrypted payload, but the practice illustrated how persistence can be engineered entirely outside the browser environment.

These mechanisms are technically distinct from browser fingerprinting, which derives an identifier from device and browser attributes rather than from stored state. Fingerprinting requires no write operation at all; supercookies require at least one write but store that write in a location the user's clearing actions do not reach.

Storage Layers and Protocols Involved in Supercookie Techniques

HSTS policy cache. Defined in RFC 6797, the HSTS policy cache is maintained by the browser as a security mechanism to prevent SSL-stripping attacks. It is keyed by hostname and stores an expiry time and an includeSubDomains flag. Because it is a security store rather than a data store, browser UIs typically do not expose it in the same clearing dialog that handles cookies and cached images.

HTTP cache (disk cache). The HTTP cache stores responses to network requests, keyed by URL and request headers. Its purpose is performance: reducing redundant network requests. ETags and cached resources used for supercookie purposes exploit this performance infrastructure. The cache has its own expiry logic governed by Cache-Control and Expires headers, independent of cookie expiry.

IndexedDB, localStorage, and sessionStorage. These Web Storage APIs allow JavaScript running in a page to write structured data to the browser's storage subsystem. Unlike cookies, they are not sent to the server automatically; they must be read and transmitted by script. They are more easily cleared by standard browser controls than HSTS or HTTP cache entries, but they are often overlooked by users who clear only cookies. A tracker cookie that survives a browser restart typically relies on persistent cookie flags, but scripts can also mirror a cookie value into localStorage as a backup, recreating the cookie from localStorage if the cookie store is cleared.

Service Workers and Cache Storage API. A registered service worker can intercept network requests and serve responses from a programmatic cache it controls. A tracking identifier stored in the Cache Storage API via a service worker persists until the service worker registration is explicitly removed — an operation that requires more steps than clearing cookies.

Network-layer injection infrastructure. Carrier-level header injection operates on HTTP proxies within the carrier's network. It requires no browser API and leaves no trace in any browser storage. HTTPS prevents it because TLS encrypts the HTTP headers that the carrier would otherwise modify.

Each of these layers represents a separate namespace for stored state. Standard cookie-clearing operations in most browsers address the cookie store and, optionally, the HTTP cache and Web Storage APIs, but they do not uniformly address all of the above in a single action.

Where Supercookie Techniques Fail or Produce Unexpected Results

HSTS-based supercookies depend on the browser maintaining per-subdomain HSTS entries. Browsers that partition their HSTS cache by top-level site — a technique called state partitioning — prevent cross-site HSTS probing because the HSTS entry recorded in the context of one site is not visible when checked from another site's context. State partitioning was introduced specifically to address this class of attack, and browsers that implement it fully break the HSTS supercookie mechanism without requiring any user action.

ETag-based tracking fails when the browser's HTTP cache is cleared, when the cache size limit is exceeded and the entry is evicted, or when the server sets a very short cache lifetime. It also fails across different browsers on the same device, because each browser maintains its own HTTP cache. A tracker relying on ETag persistence cannot correlate a visit in one browser with a visit in another.

Cache-timing attacks depend on measurable differences in load time between a cache hit and a cache miss. Browsers that add noise to timing APIs, or that restrict the resolution of the Resource Timing API, reduce the reliability of this detection method. The technique is also sensitive to network conditions: a fast network connection can make a cache miss indistinguishable from a cache hit in timing.

Service worker-based persistence fails if the origin is visited for the first time in a context where service workers are not permitted — certain private browsing implementations do not persist service worker registrations across sessions. It also fails if the user explicitly clears site data rather than only cookies, because site data clearing removes service worker registrations.

Carrier-level UIDH injection is neutralized by HTTPS, which has become the dominant protocol for web traffic. The FTC took action against carrier UIDH injection in 2016, resulting in consent orders requiring opt-in consent before such identifiers could be shared with third parties. The practice is now far less common on major carrier networks in the United States, though the technical capability remains present in some network infrastructure globally.

None of these failure modes is is not assured to apply uniformly. Browser implementation details, version differences, and the specific combination of storage techniques used by a tracker all affect whether any given clearing action actually removes the persistent identifier.

What Browser Privacy Audits and Standards Actually Measure Here

The W3C's Privacy Interest Group (PING) and the browser vendors' own privacy review processes evaluate new web platform features for supercookie potential — specifically, whether a proposed API creates a new persistent storage channel that could be exploited for cross-site tracking. This review process does not retroactively audit existing deployments; it applies to new specifications before they are standardized.

The FTC's 2012 report on consumer privacy, and its subsequent enforcement actions, established that persistent tracking identifiers that survive user opt-out or clearing actions are a deceptive practice when the user has been told that clearing data removes tracking. The FTC's action against carrier UIDH injection is the most direct regulatory record of supercookie enforcement in the United States. The FTC does not certify browsers or browser versions as supercookie-resistant; enforcement is reactive rather than prospective.

Browser privacy modes — commonly called "private" or "incognito" modes — are documented by browser vendors as preventing the writing of new history, cookies, and site data to persistent storage. They are not documented as preventing all supercookie techniques during an active session. An HSTS policy set during a private session in some browser implementations is written to the shared HSTS cache, meaning it persists after the private window closes. This is a documented behavior, not a defect, because HSTS exists to protect security; the side effect is that it can be exploited for tracking.

The Privacy Sandbox initiative, developed within the web standards process, includes proposals specifically aimed at replacing cross-site tracking mechanisms — including supercookie-adjacent techniques — with APIs that provide aggregate measurement without per-user persistent identifiers. These proposals are in varying stages of standardization and browser implementation; they represent an intended future state of the platform rather than a current audit result.

What audits and standards do not measure is the actual prevalence of supercookie techniques in deployed tracking scripts. Academic research — notably studies published by university security groups — has periodically surveyed the top websites for HSTS and ETag tracking, finding it present but less common than standard third-party cookies. Those studies reflect a snapshot in time and do not constitute continuous monitoring. The relationship between supercookies and other persistent identifiers, such as the kind of stable device signal used in browser fingerprinting, is that they can be used in combination: a fingerprint can reconstitute a supercookie identifier if it is cleared, and a supercookie can anchor a fingerprint across device configuration changes.

Supercookies are less a single technology than a category defined by a shared property: the use of browser infrastructure built for purposes other than tracking — security policy caches, performance caches, service worker registrations — as a side channel for persistent identification. The gap between what users expect a "clear data" operation to accomplish and what it actually touches in the browser's storage architecture is the space in which supercookie persistence operates.

Note: This explains how digital privacy and security tools work technically. It is not legal or cybersecurity advice, and it is not a substitute for a reader's own judgment about a real security concern. Check the cited sources for current guidance.