Supercookie: The Favicon Tracking Hack Browsers Can't Stop

Think you're safe in incognito mode? Think again.

Every developer who values user privacy needs to sit down for this one. We've all been there—confidently switching to private browsing, assuming our tracks are covered. VPN active? Check. Cookies cleared? Check. Ad blocker running? Check. But what if I told you that a tiny 16×16 pixel icon—the same favicon you barely notice in your browser tab—could blow your entire privacy setup wide open?

This isn't science fiction. This is Supercookie, a proof-of-concept by German security researcher Jonas Strehle that exploits the favicon cache (F-Cache) to create persistent, undeletable browser fingerprints. The technique works across Chrome, Firefox, Safari, and Edge. It survives cache clearing, browser restarts, OS reboots, VPN switches, and even incognito mode. Yes, you read that correctly—incognito mode is completely useless against this attack.

If you're building web applications, managing user privacy, or simply care about digital security, understanding Supercookie isn't optional anymore. It's essential. Let's dive into how this deceptively simple technique works, why it's so dangerous, and what the development community can do about it.

What is Supercookie?

Supercookie is an open-source proof-of-concept repository created by Jonas Strehle, a 25-year-old German student with a passion for software design and IT security. Published on GitHub at github.com/jonasstrehle/supercookie, this project demonstrates how browsers' favicon caching mechanisms can be weaponized for persistent user tracking.

The technique isn't entirely new—it builds upon academic research from scientists at the University of Illinois, Chicago, whose paper first identified the theoretical vulnerability. Strehle transformed that research into a working demonstration that sent shockwaves through the security community, earning coverage from Bruce Schneier, Vice, Gizmodo, and numerous international tech publications.

Why is it trending now? Because traditional tracking countermeasures have failed to address this attack vector. While the privacy world focused on cookies, localStorage, and fingerprinting canvas elements, the humble favicon cache remained completely overlooked. Supercookie exposes a fundamental design flaw in how all major browsers handle icon caching—a flaw that exists at the architectural level and cannot be patched with simple configuration changes.

The repository serves strictly educational and demonstration purposes. Strehle explicitly states his goal: drawing attention to tracking possibilities using favicons and pushing browser vendors toward proper fixes. The project includes a live demo at supercookie.me where visitors can witness their own browsers being fingerprinted in real-time.

Key Features: The Technical Breakdown

Supercookie's power lies in its elegant exploitation of standard browser behavior. Here's what makes this technique so insidiously effective:

100% Identification Accuracy

Unlike probabilistic fingerprinting that guesses based on browser characteristics, Supercookie delivers deterministic identification. Each user receives a mathematically unique identifier with zero collision probability when properly implemented.

Incognito/Private Mode Penetration

Here's where traditional privacy assumptions crumble. The favicon cache (F-Cache) operates independently of standard browsing data stores. When you enter incognito mode, browsers don't create a separate F-Cache—they share or inherit the existing one. Supercookie fingerprints created in normal mode persist seamlessly into private browsing.

Survives Aggressive Data Clearing

Flushing website cache? Deleting cookies? Clearing browsing history? None of these standard privacy actions touch the F-Cache. The favicon database lives in a separate system-level storage that remains untouched by routine cleanup procedures.

Cross-Session Persistence

Close the browser. Restart your computer. Boot into a different OS on the same machine. The F-Cache survives because it's stored in persistent local database files, not volatile memory.

VPN and Ad Blocker Immunity

Since the tracking mechanism operates entirely client-side through cache state inspection, network-level protections become irrelevant. Your traffic could route through Tor, and Supercookie would still function perfectly.

Multi-Window Tracking

The technique can distinguish between multiple browser windows or profiles on the same system, creating even more granular tracking possibilities than conventional cookies allow.

Scalable Bit-Depth Encoding

By varying redirect chains to favicon subpaths, the system can encode 2^N unique identifiers—where N represents the number of redirects. Need to track billions of users? Simply increase the redirect depth.

Use Cases: Where This Technique Shines (For Attackers)

Understanding real-world attack scenarios helps developers build proper defenses. Here are four concrete situations where Supercookie becomes devastating:

1. Cross-Session User Re-identification

E-commerce platforms and content publishers can track returning visitors even after complete cookie purges. A user who clears all tracking data, switches to incognito, and returns to the same site weeks later gets silently re-identified through their persistent favicon fingerprint.

2. Paywall and Metered Content Circumvention Detection

News sites offering limited free articles typically rely on cookies to track article counts. Supercookie enables more resilient metering that survives private browsing—frustrating users who believe they're accessing "fresh" sessions.

3. Multi-Account Detection and Linking

Platforms attempting to enforce single-account policies (social media, financial services, gaming) can use Supercookie to detect when the same physical user creates new accounts from "clean" browser sessions. The underlying hardware fingerprint remains consistent.

4. Tor and Privacy Tool User Deanonymization

The most chilling application: users employing maximum privacy protections—Tor Browser, VPNs, strict anti-fingerprinting extensions—remain trackable through this side channel. The attack completely bypasses the threat model these tools were designed to protect against.

Step-by-Step Installation & Setup Guide

Want to test Supercookie's capabilities in a controlled environment? The repository offers two deployment paths: Docker containerization or direct Node.js execution.

Prerequisites

Docker route: Docker daemon installed and running Local route: Node.js with experimental JSON modules support

Docker Deployment (Recommended)

# Step 1: Clone the repository
git clone https://github.com/jonasstrehle/supercookie

# Step 2: Navigate to server directory and configure environment
cd supercookie/server

Edit the .env file with your domain configuration:

# Main application server
HOST_MAIN=yourdomain.com      # Or localhost:10080 for local testing
PORT_MAIN=10080

# Demo/tracking subdomain
HOST_DEMO=demo.yourdomain.com # Or localhost:10081 for local testing
PORT_DEMO=10081

# Step 3: Launch with Docker Compose
docker-compose up

# Service will be available at https://yourdomain.com (production)
# Or http://localhost:10080 (local development)

Local Machine Deployment

# Step 1: Clone repository
git clone https://github.com/jonasstrehle/supercookie

# Step 2: Configure for local development
cd supercookie/server

Update .env for localhost:

HOST_MAIN=localhost:10080
PORT_MAIN=10080

HOST_DEMO=localhost:10081
PORT_DEMO=10081

# Step 3: Start with experimental JSON module support
node --experimental-json-modules main.js

# Webserver runs at http://localhost:10080

Critical configuration note: The dual-server architecture (main + demo) is essential for the cross-domain tracking demonstration. The HOST_DEMO subdomain handles redirect chains while HOST_MAIN serves the primary interface.

REAL Code Examples from the Repository

Let's examine the actual mechanisms that make Supercookie function, drawn directly from the repository's documentation and implementation patterns.

Example 1: Basic Favicon Link Injection

The foundation of the attack starts with standard HTML—nothing suspicious here:

<!-- Standard favicon declaration that triggers F-Cache behavior -->
<link rel="icon" href="/favicon.ico" type="image/x-icon">

This seemingly innocent tag is the entry point. When a browser encounters this element, it performs a cache lookup against the F-Cache database using the current URL as key. The critical insight: this lookup reveals whether the browser has previously visited this exact URL path, creating a binary state (cached/uncached) that serves as one bit of identifying information.

Example 2: Binary Encoding Through Redirect Chains

The repository implements sophisticated redirect logic to encode identifiers. Here's the conceptual pattern:

// Server-side redirect handler (conceptual implementation)
// Each path segment represents one bit of the fingerprint

// Example: Encoding user ID 5 (binary: 101) across 3 redirect hops
// Path pattern: /bit0/1/bit1/0/bit2/1/favicon.ico

app.get('/track/:bits*/favicon.ico', (req, res) => {
    const pathSegments = req.params.bits.split('/');
    const currentBitIndex = pathSegments.length / 2;
    
    // Check if this specific favicon variant exists in F-Cache
    // by observing whether browser makes subsequent requests
    
    if (currentBitIndex < totalBits) {
        // Redirect to next bit position with appropriate value
        const nextBit = extractBitFromUserId(userId, currentBitIndex);
        res.redirect(302, `/track/${pathSegments.join('/')}/${nextBit}/favicon.ico`);
    } else {
        // Final position: serve actual favicon
        res.sendFile('favicon.ico');
    }
});

What's happening here? The server constructs a unique redirect chain for each visitor. By later checking which specific favicon URLs trigger cache hits versus cache misses, the server reconstructs the binary identifier. A cache hit means "bit = 1" (favicon was previously loaded), a cache miss followed by request means "bit = 0".

Example 3: Fingerprint Reconstruction Logic

// Client-side (or server-side via request analysis) fingerprint reading
async function readFingerprint() {
    const bits = [];
    
    // Test each bit position by requesting corresponding favicon path
    for (let i = 0; i < BIT_DEPTH; i++) {
        const testUrl = `/probe/bit${i}/favicon.ico`;
        const startTime = performance.now();
        
        // Race condition: cached response returns instantly
        // uncached requires network round-trip
        const response = await fetch(testUrl, { 
            mode: 'no-cors',
            cache: 'default' // Forces cache behavior check
        });
        
        const elapsed = performance.now() - startTime;
        
        // Timing-based detection: < 10ms strongly suggests cache hit
        // Network requests typically take 50ms+ even on fast connections
        bits[i] = elapsed < CACHE_HIT_THRESHOLD ? 1 : 0;
    }
    
    // Reconstruct unique identifier from binary array
    return parseInt(bits.join(''), 2);
}

This example demonstrates the read phase of the attack. The server probes each bit position and observes whether the browser immediately serves from cache (bit = 1) or makes a network request (bit = 0). The timing differential provides reliable discrimination even without direct cache API access.

Example 4: Dynamic Bit-Depth Optimization

// Adaptive fingerprinting: adjust precision based on user pool size
function calculateRequiredBits(estimatedUserPool) {
    // Solve 2^N >= poolSize for minimum N
    return Math.ceil(Math.log2(estimatedUserPool * SAFETY_MARGIN));
}

// For 1 million users: ~20 bits
// For 1 billion users: ~30 bits
// Each bit = one redirect = ~50-100ms additional load time

async function generateTrackingChain(userId, userPoolEstimate) {
    const bitDepth = calculateRequiredBits(userPoolEstimate);
    const binaryId = userId.toString(2).padStart(bitDepth, '0');
    
    // Construct redirect URL that encodes each bit as path presence
    const redirectChain = binaryId
        .split('')
        .map((bit, index) => `b${index}/${bit}`)
        .join('/');
    
    return `/track/${redirectChain}/favicon.ico`;
}

Performance consideration: Each redirect adds latency. The repository documents that dynamic bit-depth adjustment keeps redirects minimal—most deployments use 20-25 bits for practical balance between uniqueness and user experience.

Advanced Usage & Best Practices

For security researchers and developers studying this vulnerability, several optimization strategies emerge from the repository documentation:

Timing Attack Refinement

The basic implementation uses simple timing thresholds. Advanced deployments should implement statistical analysis across multiple measurements, accounting for network jitter and system load variations.

Cross-Origin F-Cache Probing

Creative attackers can leverage CORS misconfigurations or DNS rebinding to probe F-Cache state across origins, though modern browsers increasingly isolate cache stores per top-level site.

Fingerprint Salting for Multi-Site Tracking

By varying the "salt" (base URL pattern) per collaborating site, trackers can link user identities across domains without traditional third-party cookies—creating a decentralized tracking network.

Defense Testing Methodology

When evaluating privacy tools, verify they specifically clear F-Cache databases. Brave browser's partial mitigation (shown as ❌ in current versions) demonstrates that general "cache clearing" often misses this specialized store.

Comparison with Alternatives

Why Supercookie dominates: It combines the persistence of HSTS tracking with the accuracy of active fingerprinting, while adding incognito penetration that no other method achieves. The trade-off is slightly higher implementation complexity and visible redirect latency.

FAQ

Is Supercookie illegal to use?

The repository is explicitly for educational purposes. Using this technique for actual user tracking without consent likely violates GDPR, CCPA, and similar privacy regulations. The code demonstrates vulnerability—exploiting it commercially carries legal risk.

Does Supercookie work on mobile browsers?

Yes. The repository's compatibility table confirms vulnerability across Chrome Android, Safari iOS, and other mobile browsers. Mobile F-Cache implementations follow the same architectural patterns as desktop versions.

Can browser extensions block this?

Currently, no popular extension specifically targets F-Cache manipulation. uBlock Origin and Privacy Badger don't intercept favicon requests at the necessary level. The most effective mitigation is manually clearing F-Cache files (documented in the repository).

Why haven't browser vendors fixed this?

The vulnerability stems from legitimate performance optimization—favicons must cache aggressively to avoid repeated requests. Proper fixes require architectural changes to cache isolation that may impact performance. Some vendors (Brave) have implemented partial mitigations.

Is the live demo safe to visit?

The supercookie.me demonstration is designed for transparency. It shows your generated fingerprint and explains the mechanism. However, visiting any proof-of-concept involves trusting the operator—use isolated browser profiles for security research.

How can developers protect their users?

Avoid implementing this technique. For protection against third-party deployment: advocate for browser F-Cache isolation, implement strict Content Security Policies, and educate users about manual F-Cache clearing procedures.

What's the performance impact of detection?

Each bit requires one potential redirect. A 24-bit fingerprint needs ~24 sequential network round-trips during the "write" phase—roughly 1-2 seconds on typical connections. The "read" phase can use parallel requests for faster detection.

Conclusion

Supercookie represents a paradigm shift in how we understand browser privacy boundaries. Jonas Strehle's proof-of-concept doesn't just expose a vulnerability—it demolishes foundational assumptions about what "private browsing" actually means. When a 16×16 pixel icon can pierce through VPNs, incognito mode, and aggressive data clearing, we must fundamentally reconsider our security models.

For developers, this repository is essential study material. Whether you're building privacy-preserving applications, auditing existing systems, or simply staying current on attack vectors, understanding favicon cache exploitation belongs in your security toolkit. The implementation is elegant, the impact is severe, and the mitigation requires vendor-level changes that remain largely unimplemented.

My assessment? This technique will evolve. As cookies crumble and fingerprinting faces countermeasures, side-channel attacks like Supercookie become increasingly attractive to trackers. The development community must pressure browser vendors for proper F-Cache isolation—and until then, manually clear those favicon databases.

Ready to explore the code yourself? Visit the official repository at github.com/jonasstrehle/supercookie, test the live demonstration, and join the critical conversation about next-generation web privacy. Star the project, share the knowledge, and help push for real security improvements.

Have you encountered similar side-channel tracking techniques? What mitigation strategies are you implementing? Drop your thoughts below and let's build a more private web together.