Leakuidator++: When Your Browser's Cache Becomes a Tracking Beacon

Hook

A simple webpage visit can reveal your identity—not through cookies or fingerprinting, but by measuring how fast your CPU cache responds when loading a private YouTube video you've watched.

Context

Traditional web tracking relies on cookies, browser fingerprinting, or cross-site information leaks. But what if an attacker could identify you purely by observing how your browser's CPU cache behaves? This is the premise of cache-based side-channel attacks, a class of vulnerabilities that exploit the performance characteristics of hardware to infer private information.

The leakuidatorplusteam/artifacts repository contains the research implementation of Leakuidator++, presented at USENIX Security '22. This work advances previous deanonymization techniques by demonstrating that attackers can identify specific individuals visiting their website using only client-side JavaScript measurements of cache timing patterns. Unlike traditional attacks that require exploiting cross-site scripting vulnerabilities or browser bugs, this technique works through ordinary web pages that embed third-party resources—like private YouTube videos or authenticated social media content—and measure subtle differences in how the browser's cache responds based on the visitor's authentication state.

Technical Insight

The attack architecture consists of three primary components: the attack webpage, the trace collection system, and the machine learning classification pipeline. The attack begins when a victim visits a malicious site that embeds state-dependent resources in iframes or popunders. These resources—typically private YouTube videos the attacker has shared with specific target users—load differently depending on whether the visitor is authenticated and authorized to view them.

The core technical innovation lies in the JavaScript-based cache timing measurement. The attack page uses performance timing APIs to measure cache access patterns by repeatedly accessing memory addresses and observing latency differences. Here's a simplified example of the cache probing mechanism:

function probeCacheLine(offset, iterations) {
  const probeArray = new Uint8Array(256 * 4096);
  const times = [];
  
  for (let i = 0; i < iterations; i++) {
    // Flush the cache line
    for (let j = 0; j < 256; j++) {
      probeArray[j * 4096] = 1;
    }
    
    // Trigger target resource load
    const iframe = document.getElementById('target-resource');
    iframe.contentWindow.postMessage('probe', '*');
    
    // Measure cache access time
    const start = performance.now();
    const value = probeArray[offset * 4096];
    const end = performance.now();
    
    times.push(end - start);
  }
  
  return times;
}

The trace collection system automates gathering hundreds of timing measurements from each victim visit. The repository includes platform-specific configurations for different browsers and operating systems, adjusting parameters like cache set sizes and sampling periods. For example, Windows Chrome requires monitoring 64 cache sets with 1-second sampling intervals, while Mac Safari needs different tuning due to architectural differences in Apple Silicon versus x86 processors.

What makes this attack particularly powerful is the classification pipeline. The collected timing traces are processed through multiple machine learning models—Logistic Regression for binary classification, Mean Squared Error (MSE) for distance-based matching, and FastDTW for temporal alignment of variable-length traces. The Jupyter notebooks in the repository demonstrate how these classifiers achieve high accuracy even with noisy timing data:

import numpy as np
from sklearn.linear_model import LogisticRegression
from fastdtw import fastdtw

def classify_victim(trace, known_traces, labels):
    # Normalize timing measurements
    normalized = (trace - np.mean(trace)) / np.std(trace)
    
    # DTW-based similarity matching
    distances = []
    for known_trace in known_traces:
        distance, _ = fastdtw(normalized, known_trace)
        distances.append(distance)
    
    # Find closest match
    min_idx = np.argmin(distances)
    confidence = 1.0 / (1.0 + distances[min_idx])
    
    return labels[min_idx], confidence

The repository provides pre-collected datasets showing authentication-dependent cache behavior across different scenarios. The single-target attack achieves over 90% accuracy in distinguishing whether a specific individual visited the page, while the multi-target scenario can identify which of thousands of users accessed the site. The attack requires no special browser permissions, no network-level access, and leaves minimal forensic traces beyond normal webpage analytics.

Critically, the attack exploits fundamental properties of CPU cache architectures rather than specific browser bugs. Modern processors use cache hierarchies (L1, L2, L3) to improve performance, and these caches store data based on memory addresses. When authenticated resources load, they populate cache lines differently than unauthenticated requests. By carefully crafted memory access patterns, JavaScript code can infer which cache lines are populated, revealing the authentication state without directly accessing cross-origin data.

Gotcha

The primary limitation is practical deployment complexity. The attack requires collecting 100+ timing traces to achieve reliable classification, meaning victims must remain on the attacker's page for extended periods—typically several minutes. This creates obvious detection opportunities: users will notice their browser becoming sluggish or battery draining as the JavaScript hammers the CPU with cache probing operations. Modern browser extensions or developer tools would easily identify the suspicious activity patterns.

Platform-specific tuning presents another significant barrier. The repository includes configurations for Windows Chrome, Mac Safari, Mac M1 Chrome, and Android, but each requires careful calibration of cache set sizes, sampling periods, and timing thresholds. What works on Intel x86 processors fails on ARM architectures, and browser updates frequently change performance characteristics that break the attack. The attack also fundamentally requires state-dependent resources on third-party services—you need private YouTube videos, authenticated social media content, or similar differentially-loading resources. This limits attack scope and requires significant setup (creating accounts, sharing videos with targets, maintaining the infrastructure). As browser vendors implement stricter timing API restrictions and cache partitioning schemes, the attack surface continues to shrink.

Verdict

Use if: you're a security researcher investigating browser privacy vulnerabilities, reproducing academic results from USENIX Security '22, evaluating browser defense mechanisms against side-channel attacks, or building threat models for web privacy. The repository provides well-documented artifacts with complete reproducibility—from attack pages to analysis notebooks—making it valuable for understanding modern deanonymization techniques and testing countermeasures. Skip if: you're looking for production security tools, practical offensive capabilities, or deployment-ready code. This is strictly an academic proof-of-concept demonstrating vulnerabilities that require browser-level fixes. The attack's complexity, time requirements, and platform dependencies make it impractical for real-world adversaries when simpler tracking methods (fingerprinting, cookies) exist. It's also ethically inappropriate for anything beyond controlled research environments with proper consent and IRB approval.