Most Internet users believe that opening an incognito tab or private browsing window wipes away surveillance. In standard threat models, closing a private session purges session cookies, local storage records, and IndexedDB databases. Yet commercial surveillance firms and advertising brokers have moved far beyond standard HTTP state storage. By exploiting the foundational network caching mechanisms defined in core Internet standards, trackers construct persistent cross-session identifiers known as supercookies.

Two of the most durable vectors for stateful tracking operate through protocol-level caching: HTTP Strict Transport Security (HSTS) state vectors and favicon cache redirection trees. These techniques exploit performance and security features built into modern browsers to write persistent identification numbers directly onto client storage without relying on standard cookies.

[Browser Client]
  │
  ├─ Standard Cookie Storage  ──> [Purged on Incognito Exit]
  ├─ LocalStorage / IndexedDB ──> [Purged on Incognito Exit]
  │
  ├─ HSTS Protocol State Map  ──> [Persists in Network Profile]
  └─ Favicon SQLite Cache     ──> [Shared Across Windows & Tabs]

The Architecture of HSTS Supercookies

HTTP Strict Transport Security (HSTS), standardized in RFC 6797, instructs browsers to communicate with a domain exclusively over encrypted HTTPS connections. When an application server delivers the response header Strict-Transport-Security: max-age=31536000; includeSubDomains, the client records a local security policy. For the next 365 days, any attempt to access that hostname via unencrypted HTTP is upgraded locally to HTTPS before packets leave the network adapter.

While designed to prevent man-in-the-middle downgrade attacks, this mechanism introduces a single bit of persistent state: either a specific hostname is registered in the client HSTS table (value 1), or it is absent (value 0).

Tracking Server Array (tracker-network.example)
  ├── bit00.tracker-network.example (HSTS Set   = 1)
  ├── bit01.tracker-network.example (HSTS Unset = 0)
  ├── bit02.tracker-network.example (HSTS Set   = 1)
  └── ... (32 to 64 distinct subdomains)

Surveillance engines assemble these single-bit flags into an arbitrary binary integer:

  1. State Injection (The Write Phase): When a user visits a publisher site embedded with a tracking snippet, the script initiates a sequence of hidden resource requests across 32 unique subdomains (bit01.tracker-network.example through bit32.tracker-network.example). For each bit in a calculated 32-bit user ID (such as 11010010...), the server serves an HTTPS response containing an HSTS header only for the subdomains corresponding to 1. Subdomains corresponding to 0 either return no HSTS header or remain uncontacted over HTTPS.
  2. State Recovery (The Read Phase): On subsequent visits or across different publisher domains, the tracking script generates HTTP image requests (http://bitXX.tracker-network.example/pixel.png) to all 32 subdomains. If a subdomain was previously primed with HSTS, the browser upgrades the request to https:// internally. If no policy exists, the request transmits as raw http://.
  3. Identifier Reconstruction: The server observes which requests hit the HTTPS port (443) versus the plain HTTP port (80). By mapping port 443 hits to 1 and port 80 hits to 0, the tracker reconstructs the exact 32-bit identifier in under 300 milliseconds.

Because standard browser clearing dialogs traditionally separated "Cookies and Site Data" from "Security Settings and Protocol Cache," HSTS state tables frequently survived cache purges.

Favicon Cache Fingerprinting

Favicon caching introduces an even more evasive tracking surface. Modern web browsers store website icons in a dedicated disk-backed SQLite database (such as Chromium's Favicons table) to render bookmarks, history menus, and tab strips instantly without introducing render-blocking network round trips.

Unlike standard HTTP caching, which adheres to Cache-Control directives and standard expiration headers, favicon retrieval has historically executed outside the document sandbox:

[Browser Navigation Engine]
  │
  ├─ Step 1: Request Top-Level Document (example.com)
  │
  ├─ Step 2: Parser Discovers <link rel="icon" href="/favicon-node-A.ico">
  │
  ├─ Step 3: Browser Queries Dedicated Favicon SQLite Database
  │     ├── Cache Hit:  Use cached icon (No Network Request Sent)
  │     └── Cache Miss: Issue HTTP GET to Server
  │
  └─ Tracking Matrix: Server observes network requests to determine bit sequence

Researchers demonstrated at the USENIX Security Symposium that a tracking origin can construct an adaptive redirection tree. The server issues a sequence of HTTP 302 redirects through a cascade of unique favicon URLs. If the client has already visited that branch of the tree, the browser detects a local cache hit and terminates the network request. If the icon is missing, the browser issues a network request to retrieve it.

By recording which icon endpoints trigger network requests versus which ones are satisfied by the internal disk cache, the server maps the user into a unique branch of an $N$-bit decision tree, yielding an immutable hardware-bound identifier.

The Breakdown of Client-Side Defenses

Browser vendors have implemented substantial engineering defenses against these stateful vectors over recent years:

  • Client-Side State Partitioning: Major modern engines implement double-keying (such as Firefox Total Cookie Protection and Chromium Network State Partitioning). Under state partitioning, cache keys are formed by combining the top-level site origin with the resource origin: (top_level_site, resource_site). A bit set on tracker.com while visiting site-a.com is segregated from requests made while visiting site-b.com.
  • Ephemeral HSTS Tables: Incognito windows in updated browsers maintain an isolated, ephemeral HSTS storage bucket that discards newly written policies upon window destruction.

However, state partitioning does not eliminate the underlying telemetry threat:

  1. First-Party CNAME Cloaking: When publishers delegate subdomains (e.g., analytics.site-a.com) to tracking platforms via DNS CNAME records, the tracker operates under the first-party partition key, circumventing cross-site partitioning.
  2. Cross-Application Shared WebViews: On mobile platforms (Android and iOS), third-party apps frequently render content via system WebViews that do not consistently enforce private window sandboxing across independent application runtimes.
  3. Telemetry Stitching via Network Metadata: Even if a browser isolates the cache partition, tracking servers link disparate partitions together using static Layer-3 and Layer-4 identifiers: the client's public IPv4/IPv6 address, ISP Autonomous System Number (ASN), and TLS fingerprint.

Neutralizing Stateful Tracking with RiceGuard

Browser-level defenses isolate local disk storage, but they cannot hide the network-level correlation that trackers rely upon to tie partitions to your identity. When an advertising server receives requests across isolated partitions, it queries database records matching your public IP address and ISP routing path.

VPNRice delivers structural defense against stateful cache profiling through its core Layer-3 architecture:

[Device Browser & Local Apps]
  │
  │ (HSTS Queries / Subdomain Probes / Favicon Requests)
  ▼
[RiceGuard Virtual Network Interface]
  │
  ├─ Chacha20-Poly1305 Cryptographic Tunnel (RFC 8439)
  ├─ Zero-Leak Encrypted DNS Proxy (Port 53 / 853 Intercept)
  │
  ▼
[VPNRice High-Throughput Egress Cluster]
  │
  ├─ Masked Ephemeral Public IP (Shared Across High-Density Pool)
  ├─ Decoupled ASN Telemetry (Eliminates Residential ISP Fingerprint)
  │
  ▼
[Target Web Servers & Tracking Networks]
  1. Severing Identity Anchors: RiceGuard routes all device traffic through hardened WireGuard tunnels. When a tracker observes HSTS upgrade probes or favicon redirection callbacks, the source IP resolves to high-capacity VPNRice datacenter egress nodes. The tracker cannot correlate the cache state with your home network, physical location, or real ISP account.
  2. Encrypted DNS Isolation: Stateful HSTS enumeration requires dozens of rapid DNS lookups against tracking subdomains (bit01 through bit32). RiceGuard forces all DNS resolution through private, zero-logging resolvers situated directly inside the VPN tunnel. Local network snoops and upstream telecom providers cannot log the subdomain lookup bursts that characterize HSTS fingerprinting.
  3. Dynamic Egress Rotation: By redistributing outbound connections across geographically diverse endpoints, VPNRice prevents surveillance engines from maintaining persistent longitudinal profiles, rendering cross-partition cache stitching ineffective.

Hardening Checklist for Persistent Cache Vectors

To establish defense-in-depth against stateful protocol tracking, apply these practical configuration measures:

  • Clear Protocol Caches Periodically: In Chromium-based browsers, clear HSTS entries manually by navigating to chrome://net-internals/#hsts, entering the suspect domain in "Delete domain security policies," and confirming removal.
  • Enforce Strict Isolation in Firefox: Set privacy.partition.network_state to true in about:config to verify that network connections, socket pools, and protocol caches remain strictly partitioned by top-level document origin.
  • Disable Automatic Favicon Fetching on Metered Connections: In security-focused browser distributions (such as LibreWolf), verify that out-of-band icon requests are restricted to first-party origins.
  • Maintain Continuous Layer-3 VPN Protection: Run VPNRice continuously across mobile and desktop endpoints. Encrypting all network traffic ensures that protocol quirks and stateful caching exploits never betray your real network location or persistent device identity.