Inspiration

Modern tracking no longer relies on cookies alone. Research in cache side-channel attacks as well as website fingerprinting shows that high-resolution timers like performance.now in JS can be exploited to extract behavior like website browsing from a victim's browser.

We wanted to explore a simple but powerful idea:

If attackers rely on high-frequency timing behavior, can we detect that behavior in real time and defend against it from within the browser itself?

What it does

Counting Fish is a Chrome extension that detects and mitigates high-frequency timing behavior associated with cache-based fingerprinting and side-channel attacks.

It monitors:

-Excessive performance.now() calls -High-frequency burst patterns -Suspicious WebAssembly execution -Worker spawning activity -requestAnimationFrame abuse

The extension computes a dynamic risk score per origin and explains why a page is considered suspicious. This is a unique take on this part of cybersecurity, which typically uses large blacklists which may not update real time.

How we built it

Counting Fish is built using: -Chrome Extensions API (Manifest V3) -A service worker for background aggregation -A content script injected at document_start -Runtime instrumentation of timing APIs -A per-origin risk scoring engine -A real-time popup UI

Challenges we ran into

  1. Training the attacker model

One of our biggest challenges was building and training the attacker model used in our presentation demo.

To simulate realistic fingerprinting behavior, we needed a custom dataset of timing traces. We built automation scripts to collect and extract traces, but this introduced a major problem: when crashes occurred during long collection runs, entire datasets were wiped. This cost us hours of lost data and retraining time.

To solve this, we redesigned our pipeline to incrementally cache traces as they were extracted rather than storing everything in memory until the end. By persisting partial results during collection, we made the dataset resilient to crashes and eliminated catastrophic data loss.

This forced us to think about data durability and fault tolerance, even in a hackathon setting.

  1. Worker-based attacks

On the extension side, one of the hardest technical challenges was handling worker-based attacks.

Fingerprinting logic can execute inside Web Workers, which isolates execution from the main thread. Early detection strategies that instrumented only main-thread timing APIs were insufficient.

This created a race condition between our instrumentation and Chrome’s execution model. If worker code initialized before we instrumented or monitored it, detection signals could be missed.

We addressed this by expanding our monitoring strategy to account for worker spawning behavior and suspicious execution patterns rather than relying solely on main-thread hooks.

This challenge highlighted how modern browser security is often a race between defensive instrumentation and attacker execution timing.

Accomplishments that we're proud of

What we learned

-Timing side-channels are subtle but measurable. -Even replacing cache sweeps with tight loops can produce detectable timing signatures. -Behavioral detection can be more flexible than static timer clamping. -Security tooling is most powerful when it is transparent and explainable.

What's next for Counting Fish

-Machine learning–assisted anomaly detection

-Adaptive quantization based on threat level- -Worker-level deeper instrumentation -Firefox and cross-browser support -Expanded detection for additional side-channel patterns -Long-term, Counting Fish could evolve into a general-purpose client-side behavioral defense layer for browser-based attacks.

Share this project:

Updates