The Randomization Lie: Every Canvas Defense Has Been Defeated

Sprinkling noise onto every pixel so trackers lose your scent sounds brilliant in the abstract. Like white noise drowning out a wiretap in a Cold War thriller. Nine Chrome and Firefox extensions got built on that premise. Brave welded it into the browser itself and branded it farbling. Elegant, gut-level right, and utterly useless.

In April 2025, Hoang Dai Nguyen and Phani Vadrevu from Louisiana State University brought their paper Breaking the Shield: Analyzing and Attacking Canvas Fingerprinting Defenses in the Wild to WWW'25. Eighteen extensions and five major browsers tested. Verdict, in their own words: unfortunately, no fully deployable defense against canvas fingerprinting attacks currently exists.

Every single one beaten. Not a solitary working shield. Zero out of twenty-three.

What you're reading pulls together evidence from eight academic papers, two CVEs, anti-fraud industry data, and live tests of commercial systems. Every strand confirms the same finding: canvas randomization doesn't just fail. Helps them find you. And fresh 2025 research showed the true scope of the problem is double what scientists reckoned.

In brief: WWW'25 proved it: all 18 extensions and 5 browsers defeated. Canvas noise isn't protection. It's a marker. Zero working defenses.

What Is Canvas Fingerprinting and Why You Should Care

Canvas fingerprinting is blunt in its simplicity. Browser gets a task: draw text in a specific font, a gradient with certain colours, an emoji of a given shape. Rendering outcome hinges on the GPU, drivers, operating system, installed fonts, and dozens of other variables. Two different machines will draw the same scene with tiny divergences. Hash that divergence, and you've got a fingerprint. No cookies. No accounts. No consent needed.

Per IMC 2025, canvas fingerprinting runs actively on a hefty share of the largest websites. Not some exotic lab curiosity. An industrial surveillance apparatus humming along right now, while you read this sentence.

Why people try to fight it. Why the fight doesn't work.

Beyond the Crawl: The Real Scale Is Twice as Bad

When a researcher wants to gauge how widespread fingerprinting is, they spin up a crawler. Bot hits thousands of sites, hoovers up scripts, picks through code. Reports get written. Policies get shaped. A picture of the world comes into focus.

Half that picture is missing.

In April 2025, Annamalai from UCL, De Cristofaro from UC Riverside, and Bilogrevic from Google Zurich brought Beyond the Crawl to ACM Web Conference. Automated crawling of 3,000 sites stacked against real browsing sessions from 30 users. Upshot: crawlers miss close to half of all fingerprinting scripts.

Three reasons. First: pages behind login walls. A crawler can't sign into your bank, your email, your personal dashboard. Fingerprinting scripts thrive there regardless. Second: bot detection. Plenty of sites sniff out crawlers and serve them a stripped-down page, shorn of tracking scripts. Flesh-and-blood visitors get the full version with the complete surveillance stack. Third: scripts that fire only on interaction. A click, a scroll, typing into a form field can trigger fingerprinting. Crawlers don't click. Don't scroll. Don't type.

Upshot is bracing: every academic estimate of fingerprinting prevalence built on crawl data is roughly half the real number. When a researcher writes that 34% of top-500 sites deploy fingerprinting, genuine figure sits closer to 60-70%. Surveillance industry runs at twice the size science can gauge. Science simply can't get past the login form.

One more unsettling nugget from Beyond the Crawl: scripts invisible to crawlers tend to be the most rapacious. Harvest more signals, wield more intricate techniques, including canvas fingerprinting with multiple renders and high-resolution audio fingerprinting. Logic is plain: if a script hides from researchers, its authors don't need to play nice. Polite scripts doing minimal signal collection sit out in the open. In that inchoate murk, aggressive ones run unfettered.

Breeds an illusion of progress, frankly. Researchers publish reports: fingerprinting prevalence has levelled off. Regulators nod. Browser vendors trumpet victories. Meanwhile true scope of surveillance swells in the half of the web that crawlers can't reach. Measuring the temperature in the foyer and concluding the house is cool, while the kitchen's been ablaze for years.

For context: per Web Almanac 2025, 75% of web pages harbour at least one tracker. Crawler number. Factor in the Beyond the Crawl correction, and the real percentage climbs higher still.

For canvas fingerprinting specifically, that effect bites hardest. Canvas scripts tucked behind login walls don't land in academic samples. They run on every site where you're logged in though. Your bank. Your social network. Your email. Everywhere the crawler halted at the login form, real canvas fingerprinting is just getting started.

Four Types of Defense: The Postmortem

Nguyen and Vadrevu sorted every existing defense into four bins. Here they are, most popular to rarest:

Defense Type	How It Works	Who Uses It	Resilience
Pixel Randomization	Adds random noise to RGBA values	9 extensions and Brave	Weakest
Fixed Output	Returns the same value every time	Firefox Resist Fingerprinting	More resilient
Blocking	Completely forbids Canvas API access	Select extensions	Breaks sites
Permission-Based	Asks the user before each access	CanvasBlocker and others	Fatigues the user

Counterintuitive verdict: randomization, the crowd favourite, turned out weakest. Fixed output, where every Firefox user with Resist Fingerprinting on gets an identical hash, held up better. Your gut says the opposite. Math doesn't bluff.

How Exactly Randomization Gets Cracked

Nguyen and Vadrevu didn't just call it broken. Showed the precise mechanism per WWW'25 data. Pixel randomization typically works like so: a random number from a tight range, usually ±5, gets tacked onto every RGBA channel value. Some extensions apply noise on each toDataURL call. Others mint a seed once per session and use deterministic noise. A third group blends both.

Attack leaned on statistical analysis of multiple renders. When an extension throws random noise on every call, ten renders of the same canvas yield ten different hashes. Average those renders and the random component washes out, restoring the original image. Astrophotographers know this trick instinctively: stack a burst of night-sky frames, noise fades, signal stays. Where the noise is deterministic for the session, a single render gives a stable but shifted hash. Researchers probed the statistical spread of pixel values: in a genuine canvas the colours follow the designer's intent, while a noised canvas sprouts a telltale Gaussian tail that a rudimentary statistical test nabs instantly.

For three of the 18 extensions, the attack was even simpler: extensions only noised part of the canvas, leaving the rest untouched. Reading the quiet zone was enough to pull a clean fingerprint. Researchers wrote that seemingly non-deterministic behaviour can be predicted and exploited. Nine extensions plus Brave use randomization. All nine cracked. Brave cracked. An elegant idea dashed against statistics.

Now flip the premise. When all users hand back the same value, there's nothing to catch. No variation, no signal. True, only holds while everyone runs the same defense. Did 2% of users switch on Firefox Resist Fingerprinting? Congratulations: now you can be told apart from the other 98% precisely because you return a fixed value. Very act of hiding became an effluvium.

Irony runs deep: even the strongest defense only works inside a crowd. And there is no crowd.

Drawnapart: When Silicon Betrays You

Say you somehow cracked the pixel noise problem. Averaging fails, the seed is unpredictable, the noise is genuinely random. Safe?

No. Because your own GPU is the threat. Not what it draws, but how fast it draws it.

In 2022, at the NDSS conference, a team from Ben-Gurion University, Inria, and the University of Adelaide unveiled Drawnapart. Question nobody had bothered with before: can you tell apart two GPUs of the same model, from the same batch, from the same factory line? Answer: yes.

The Physics of Silicon Betrayal

Every GPU is built from Execution Units. Designed identically, but during wafer fabrication, microscopic variations creep in. Oxide layer thickness drifts by nanometres. Transistor channel length runs a hair above or below spec. All of it nudges the speed of each individual unit. Difference is imperceptible to a human. Diaphanous to an algorithm.

Drawnapart uses WebGL to render specific 3D points. Each point loads a particular Execution Unit. By timing the render for each unit, the algorithm builds a GPU trace. A series of traces gets fed through a neural network that spits out a fingerprint vector. Euclidean distance between vectors from two sessions tells you whether it's the same chip.

Scale of Results

Researchers tested the method on 2,500+ devices, including 1,605 unique GPUs:

Metric	Result
Tracking duration increase vs FP-Stalker	+67%
Distinguishing identical GPUs of the same model	Yes
Works on integrated GPUs	Yes
Works on dedicated GPUs	Yes
Three measurement methods	Onscreen, Offscreen, GPU timing

One co-author, Vitalii Diadiuk, ran a physical experiment: pulled processors with integrated graphics from two identical computers and swapped them. Drawnapart tracked the swap. Chip recognized itself in a different chassis, like a bloodhound catching its owner's scent through a fence.

Why Canvas Randomization Is Powerless Here

Here's the crux. Straight from the paper: existing countermeasures against Canvas Fingerprinting that add noise to the rendering cannot be applied against DrawnApart since it is based on measuring execution time rather than on comparing rendered images.

You can noise every pixel, rotate the hash every second, heap randomness on top of randomness. Drawnapart doesn't flinch. Doesn't need your pixels. Needs the timing of your silicon. Canvas randomization against Drawnapart works roughly like an invisibility cloak against a bathroom scale: you still weigh the same.

WebGPU: The Next Frontier Is Already Open

WebGPU succeeds WebGL as the new graphics API for browsers. More powerful, lower-level, better suited to fingerprinting by a wide margin. Frankly an attacker's dream.

In June 2025, Hohentanner, Kemmerzell, and colleagues brought their paper to ACM WiSec 2025: Unveiling Privacy Risks in WebGPU. Five hundred devices tested. 70% re-identification through AtomicIncrement fingerprints. Seventy percent of five hundred random machines. Every third tech support caller claiming my computer is one-of-a-kind would be proven right.

How it works. Principle diverges from canvas fingerprinting at bedrock level. WebGPU opens access to compute shaders that run calculations on the GPU in parallel. Atomic operations like AtomicIncrement execute at varying speeds on different GPUs because of architectural quirks in execution units. Researchers metered GPU behaviour across thousands of atomic operations and built a profile unique to each device.

Critical takeaway: WebGPU sidesteps every defensive mechanism built for WebGL. Brave farbling doesn't touch WebGPU. Safari Advanced Fingerprinting Protection doesn't noise WebGPU rendering. Firefox Resist Fingerprinting doesn't standardize WebGPU output. No browser currently fields any defense against fingerprinting via WebGPU. Fresh attack surface: wide open, unmasked, waiting for mass exploitation.

A telling paradox already shows up in the wild: users who diligently block WebGL, oblivious to WebGPU. Old door bolted. New one swinging in the breeze.

WebGPU-SPY from AsiaCCS 2024 exposed a different vector: GPU cache side-channel attacks from inside the WebGPU sandbox, able to work out which sites are loaded in other tabs without touching their content. Not mere fingerprinting at that point. Espionage through a graphics processor. Researchers from TU Graz showed in parallel drive-by GPU cache attacks across 11 GPUs spanning five generations from two vendors. Attack time: under 15 minutes of regular browsing. Covert channel bandwidth: 10.9 kilobytes per second. No user interaction needed.

For the fingerprinting industry, WebGPU is a windfall. Canvas defenses took years to build, and while they don't work, at least they create the veneer of a fight. WebGPU shipped in stable Chrome, Edge, and Firefox builds with zero fingerprinting guardrails. W3C spec makes no provision for compute-shader privacy. WebGPU working group isn't discussing mitigations. Browser vendors stay mute. And researchers have already shown 70% re-identification. Between the publication of an attack and the arrival of a defense, years typically pass. For canvas that cycle kicked off in 2014. For WebGPU it starts now.

Canvas fingerprinting is no longer the sole graphics vector. WebGPU opens a second front. And browsers haven't even broken ground on defenses.

CVE-2024-27830: The Worker Thread Loophole

In 2024, researcher Joe Rutkowski found an elegant flaw in Safari 17.4. Canvas fingerprinting protection worked in the main thread and in regular workers. Not in SharedWorker though. Not in ServiceWorker. Two of the four doors locked. Two standing wide open.

Attack is trivial. Spin up a SharedWorker. Inside it, draw a canvas through OffscreenCanvas. Get a clean, unshielded fingerprint. Meanwhile the browser's main thread dutifully hands back a noised value, convinced everything's under control. Security guard checking IDs in the lobby while burglars stroll through the loading dock.

Apple was initially unconcerned. Their word. Reconsidered afterward and assigned CVE-2024-27830. Patched in Safari 17.5, June 2024.

Firefox was vulnerable too. Partially patched in Firefox 127. ServiceWorker stayed exposed until Firefox 131, August 2024.

Browser vulnerability, that one. With extensions, the picture is fundamentally different, and it's intractable.

The Architectural Dead End of Extensions

Browser extensions work like so: they inject JavaScript into the page and override functions such as toDataURL, getImageData, and other Canvas APIs. When a site calls those functions, it gets a substituted result with noise baked in. Tidy enough, right?

Here's the snag. A Web Worker runs in its own JavaScript context. Extension content scripts live in the main thread. API overrides don't propagate into workers. Can't propagate. Structural limitation of how browser extensions are wired.

Back in 2017, developers at AdguardTeam/FingerprintingBlocker documented the issue: OffscreenCanvas can be used in web workers, and that bypasses any fingerprinting defense mechanism based on browser API substitution.

Nine years ago. Problem known. Fix: none. One can't physically exist within the current extension architecture. Manifest V3, Chrome's new extension spec, doesn't address the gap. Doesn't even acknowledge it.

Any detection system can leverage this. Compare the canvas hash from the main thread against the hash from a Web Worker. When the values disagree, the main thread is running a substitution. Extension can't hide from that comparison. Nowhere to hide.

Brave Farbling: Privacy in Name Only

Brave has earned its reputation as the private browser. Partly deserved: built-in ad blocker, tracker blocking, HTTPS by default. For canvas fingerprinting, Brave uses farbling, a term the Brave team coined for randomized interference.

How Farbling Works

For each site-plus-session combo, a deterministic seed gets generated. Based on that seed, noise gets folded into canvas pixels. One site sees one value per session. Different site sees a different value. Next session, both get a third. On paper it sounds airtight.

Brave offers three tiers. Off means protection disabled. Default means barely perceptible noise, different per site, no bother to the user. Maximum means fully random values, may break sites.

Chronicle of Failures

Brave's farbling bug history reads like a chronicle of retreat:

Date	Bug	What Happened
October 2020	#12069	Farbling hit only one RGBA channel
January 2021	#13690	Algorithm processed only part of the canvas, leaving original data exposed
2021	#14135	Noise so feeble the hash didn't budge
September 2021	#17850	Photopea users could see the noise with the naked eye

Every one of those bugs got squashed. Fixes themselves lay bare how brittle randomization is though. A bug where noise only lands on one channel out of four isn't a minor hiccup. Three quarters of the fingerprint sitting in the clear.

96% and Shattered Hopes

Even without those bugs, farbling doesn't save you. Analysis from Brside.com, December 2025 showed: fingerprint.com consistently re-identified Brave users after clearing data, swapping IPs, and connecting through VPN. Even with WebGL disabled, confidence hit 96%.

Now chew on a paradox that deserves a plaque on somebody's wall.

EFF's Cover Your Tracks rates Brave as randomized, meaning well-shielded. Rates Firefox as unique, meaning poorly shielded. In real commercial fingerprinting the picture inverts completely. Firefox with Resist Fingerprinting and Safari successfully block re-identification, while Brave loses.

Why Standardization Beats Randomization

Brave leans solely on randomization. Firefox leans on standardization: all users in Strict mode get the same audio fingerprint of roughly 35.75, per Brside.com tests. Safari leans on generalization: instead of Apple M1 Pro it reports simply Apple GPU.

Brave meanwhile honestly reports the exact GPU model, CPU core count, hardware audio signature. You can randomize canvas till you're blue in the face. When you've already broadcast your home address, dark sunglasses won't help.

Sole way to stay anonymous in Brave, per Brside.com data: a private window with Tor. At that point you're not really using Brave anymore.

Commercial Fingerprinting: 99.5% on Your Device

Fingerprint Pro runs a client-server architecture: client SDK gathers signals on the device, then ships them to Fingerprint's servers for machine-learning processing. Claimed accuracy of the commercial version: 99.5%. For comparison, the open-source FingerprintJS yields 40-60% accuracy.

Gap between 60% and 99.5% is the gap between maybe the same user and almost certainly the same user, confident to the fifth decimal. Commercial fingerprinting isn't experimental anymore. Mature product with SLAs, support contracts, and docs.

On-device computation cracks the bottleneck that stalled mass deployment: network latency and server processing cost. When the fingerprint is computed on the user's device and shipped as a ready-made hash, the server just compares. Less traffic, less lag, less infrastructure. More sites can afford fingerprinting.

Canvas randomization doesn't work against this. 99.5% accuracy means FingerprintJS already accounts for and routes around every existing defense. All 18 extensions from the WWW'25 study. All built-in browser mechanisms. Commercial incentive overpowers academic defense because commerce has more resources and sharper reasons to win.

For scale: FingerprintJS runs on thousands of sites per the company's own data. Behavioural biometrics market, which encompasses fingerprinting, is valued by analysts at $2.72 billion in 2025 and projected to hit $11.38 billion by 2031. Annual growth: 26.95%. Academic researchers ship defense papers once a year at conferences. Industry refreshes bypass methods every quarter. Arithmetic tilts hard against defense.

Question isn't whether you can be tracked. Question is whether you know it's happening. Tools like WHOX exist to show users what commercial systems prefer to keep tucked away: exactly how identifiable you are.

Fontleak: When JavaScript Isn't Even Needed

Up to here, every attack leaned on JavaScript. Kill JS and fingerprinting ought to be impossible, right? Tor Browser blocks it by default. Email clients block it too. Surely safe.

Dragos Albastroiu proved otherwise. His tool Fontleak uses nothing but CSS to siphon data. Character by character.

How CSS Exfiltration Works

Attacker crafts a custom font with ligature substitutions in OpenType GSUB format. Every character in the font has zero width except for special leak glyphs. Ligature rules use chained substitutions to isolate the character at a given position. Leak glyph for each character carries a unique, known width. Through CSS mechanisms like font-size-adjust, media queries, or scrollbar tricks, the glyph width gets relayed to the attacker's server.

Sounds like a heist film where the thief cracks a vault with a stethoscope. Except the vault is your browser, and the stethoscope is a font file.

Outcome: full extraction of text content from DOM elements. Contents of <script> tags with API keys and CSRF tokens. Works in the latest builds of Chrome, Firefox, and Safari. DOMPurify passes <style> tags by default, so CSS injection through user-generated content is entirely viable.

For fingerprinting: blocking JS won't save you. CSS has grown potent enough to fill the gap. Vector sails past every canvas defense, every JavaScript interceptor, the entire infrastructure browsers have built over the past decade. Fontleak is a reminder that canvas is just one surface. Not the most vulnerable one.

Cascading Spy Sheets: 98% Accuracy Without a Single Line of JS

Fontleak siphons data. Researchers from CISPA went further and built a full identification system on pure CSS. Paper titled Cascading Spy Sheets, presented at NDSS 2025, pushed CSS fingerprinting to industrial scale.

Three vectors:

CSS properties as fingerprint. Different browsers and versions support different CSS properties. Checking each property via @supports pins down the browser. In the full scenario, accuracy reached 98%.

Extension detection. Ad blockers reshape the DOM by stripping elements. CSS selectors tied to those elements stop matching. Pattern of what's stripped versus what's left pinpoints the specific extension. Researchers tested 10 Chrome extensions.

Font fingerprinting through CSS. Presence of specific fonts gets checked without JavaScript. Leelawadee signals an MS Office install. Mix of present and absent fonts, determined purely through CSS, yields a fingerprint of the OS and installed software.

All of it works in email clients that render HTML but block JS. Which is virtually every email client out there.

Disabling JavaScript used to seem like a drastic but watertight measure. Now it's about as effective as bolting the front door while every window hangs open.

How They Catch Noise: 5 Techniques from Castle.io

Randomization doesn't shield the user. So how precisely do they catch it? Castle.io blog laid out five techniques the anti-fraud industry deploys. All of them live right now.

Technique 1: Pixel Verification. Draw a canvas with known colours, say rgba(0, 127, 255, 1). Read every pixel value back. When R isn't 0 or G isn't 127, noise was injected. Extensions adding ±5 to each channel fail on contact. Like watering down wine and hoping the sommelier won't notice.

Technique 2: Function Consistency Check. Call toString() on toDataURL. A native function returns function toDataURL() { [native code] }. An overridden one likely won't. Check Object.setPrototypeOf(): native functions throw a Cyclic error, Proxy objects behave differently. Peek at the error stack trace: when chrome-extension:// surfaces, the extension outed itself along with its ID.

Technique 3: Multiple Renders. Draw the same canvas twice in one session. Hash shifted? Per-call randomization. Stable within a session but shifts between sessions? Brave-style farbling.

Technique 4: Contextual Interpretation. Castle.io recommends distinguishing normal from abnormal randomization. Brave, Firefox, Samsung Browser add noise by design, and their patterns are catalogued. A Chrome user showing noise: that's an extension, grounds to jack up the risk score. Noise pattern not matching the claimed browser? Spoofing.

Technique 5: Beyond Hashing. Key insight from Castle.io: hashing is effective, but that effectiveness carries a tradeoff. When canvas is randomized, the hash itself loses all context. Instead of hashes, Castle.io proposes sampling specific pixels at deterministic positions, computing aggregate metrics like average colour, and clocking canvas operation timing. Spoofing and emulation inject delays that a hash won't catch, but timing will.

Google runs a kindred approach called Picasso: bucketing devices into families by their rendering quirks. Not individual uniqueness, but device class. Weathers noise better than any hash.

How Modern Detection Catches Noise

Techniques Castle.io described aren't theoretical musings. They've been folded into detection systems running against every visitor. For canvas specifically, four mechanisms seal the main attack vectors.

Perceptual hashing. Instead of a cryptographic hash that flips from a single altered pixel, perceptual hashing grabs the visual structure of an image. Extension jitters individual pixels, but the overall picture stays intact, and the perceptual hash holds steady or close to the original. Castle.io's fifth technique taken to its logical terminus: going past raw hashing.

Main thread vs. worker comparison. Draw a canvas in the main thread and in parallel inside a Web Worker. Extensions can't override APIs inside workers. Hashes disagree? Main thread is running a substitution. Same principle that confirmed CVE-2024-27830, and that AdGuard developers documented back in 2017. Known architectural weakness of extensions, repurposed as a detection tool.

Noise detection. Pixel verification and multiple renders catch noise head-on. Detecting noise is itself a signal. Adding noise broadcasts about you no less loudly than running with defaults.

Native function integrity. Have toDataURL, getImageData, and other APIs been overridden? Are they Proxy objects? Does their toString() match expectations? Castle.io's technique 2, automated and running at scale.

Four mechanisms don't succeed because they're cleverer than randomization. Succeed because randomization, as Nguyen and Vadrevu proved, isn't a problem that needs solving. Solves itself. Noise gets nabbed trivially. Absence of noise shows up in the fingerprint. Any choice the user makes, defend or don't, carries information. Information theory has a name for this: there is no null message. In practice it means: you cannot not leave traces.

And canvas is a single signal among hundreds. WebGL, audio, fonts, TLS fingerprints, mouse behaviour, DNS, GPU timing, WASM. You can fool one signal, even ten. Cross-check hundreds for consistency, and the math turns merciless.

What Comes Next

Front is widening. WebGPU already delivers 70% re-identification with zero browser defenses in place. CSS fingerprinting stretches beyond the browser into email clients. Commercial solutions like Fingerprint Pro have hit 99.5% accuracy using client-server ML pipelines. And Beyond the Crawl showed the real scope of surveillance is twice what academic science can gauge.

Canvas isn't even the main battlefield anymore. One front among many. Canvas randomization was a good idea. A lock that works only while nobody tries to open it. WWW'25 showed everybody tries. Everybody succeeds.

Eighteen extensions. Five browsers. Zero working defenses. Not a forecast. A final tally.

FAQ

What is canvas fingerprinting? Canvas fingerprinting is an identification technique where the browser draws a test scene: text, gradient, emoji. Rendering result depends on the GPU, drivers, OS, and fonts. Hash of the result is unique to each device. Per IMC 2025, canvas fingerprinting is actively deployed on a significant share of major websites. Works without cookies, without consent, without notification.

Why doesn't canvas randomization work? WWW'25 from Nguyen and Vadrevu proved it: all 18 extensions and 5 browsers were beaten. Random noise gets wiped out by statistically averaging multiple renders. Deterministic noise gets spotted by the Gaussian tail in pixel value distributions. Castle.io described 5 specific noise detection techniques. Sheer presence of noise is a marker: canvas.noise_detected: true splits you from 96% of users. CVE-2024-27830 showed Safari's protection failed in SharedWorker and ServiceWorker contexts.

What is Drawnapart and why does it ignore canvas defenses? Drawnapart from NDSS 2022 fingerprints through GPU timing, not pixels. Measures how fast each GPU Execution Unit renders specific points. Manufacturing-level silicon variations make each chip unique. Boosts tracking duration by 67%. From the paper: existing countermeasures against Canvas Fingerprinting that add noise to the rendering cannot be applied against DrawnApart since it is based on measuring execution time rather than on comparing rendered images.

Can you fingerprint without JavaScript, using only CSS? Yes. Cascading Spy Sheets from NDSS 2025 hits 98% browser identification accuracy using only CSS: @supports checks properties, CSS selectors detect extensions, font fingerprinting identifies the OS. Fontleak extracts DOM text content through CSS ligatures. Works in email clients that block JS. CVE-2024-27830 showed even Safari was vulnerable through SharedWorker and ServiceWorker.

What actually works against canvas fingerprinting? Standardization, where all users return identical values, works better than randomization. Firefox Resist Fingerprinting and Tor/Mullvad Browser use that approach. Crowd is thin though: only 0.48% of Firefox users flip on RFP. Against Drawnapart and WebGPU with its 70% re-identification, only completely disabling WebGL helps. Against CSS fingerprinting, no defense exists. Honest answer: no fully deployable defense against canvas fingerprinting currently exists, per WWW'25.