WebGPU + QUIC + eBPF: Fingerprinting in 2027

Nobody in the fingerprinting game has clocked out since somebody first timed a canvas draw call. W3C keeps scribbling mitigation guidelines. Users keep swapping privacy add-ons like worn brake pads. And researchers keep hammering home one verdict, year after relentless year: fresh web standards crack the attack surface open wider. Not tighter. Wider.

2025 shoved three technologies under the klieg lights: WebGPU, QUIC, and eBPF. Each was forged for profoundly humdrum work. Faster graphics rendering. Snappier network handshakes. Leaner packet wrangling inside the kernel. Zero blueprints for surveillance. Yet surveillance is precisely what they've spawned, and by 2027 these three strands will, in all likelihood, redraw the full cartography of digital identification.

In brief: WebGPU hits 70% re-ID from silicon alone, VisQUIC reaches 97% through encrypted QUIC, and eBPF fingerprints TCP before your page loads.

Part I. WebGPU: When Silicon Betrays Its Owner

From Drawnapart to WiSec'25

GPU-based hardware fingerprinting didn't hatch last Tuesday. Way back in 2022, a crew from Ben-Gurion University, the University of Adelaide, and Inria unveiled Drawnapart at the NDSS conference. Core gambit: clock how long a GPU takes to shade specific points in a 3D scene via WebGL, then wield those timings to split devices apart. Not device models. Physical, hold-in-your-hand, one-of-a-kind units.

Silicon is never immaculate. Every GPU rolling off the fab line carries microscopic quirks etched into its die, fingerprints baked into crystalline lattice. Invisible to the naked eye, imperceptible to the user, yet they surface as measurable speed deltas when certain shader ops run. Drawnapart stretched device-tracking time by 67% over legacy methods. Just the overture.

Fast-forward to 2025. At ACM WiSec'25, Konrad Hohentanner's team from Fraunhofer Aisec dropped fresh findings: Unveiling Privacy Risks in WebGPU through Hardware-based Device Fingerprinting. Not WebGL this time. WebGL's heir: WebGPU.

Numbers worth tattooing on a whiteboard: 70% re-identification accuracy across a pool of 500 devices. Key vector: fingerprinting via AtomicIncrement. A compute shader fires off a burst of atomic increments on shared memory, clocks the timings, and stitches together an execution profile. Every GPU carries out atomic operations with tiny yet rock-steady throughput quirks and completion-order deviations. Those deviations hold up between sessions and shrug off software changes the way a duck shrugs off rain.

Hohentanner, Kemmerzell, and Florschütz, working across Fraunhofer Aisec and FAU Erlangen-Nürnberg, proved that shields built for WebGL are toothless here. WebGPU slips past every standing mitigation because it talks to hardware at a fundamentally deeper stratum. No elevated privileges. Stock web browser. Standard API.

Sit with the scale for a beat. Five hundred devices, seven out of ten nailed on a return visit. A fingerprint that outlasts browser updates, OS swaps, and most privacy countermeasures. Because nobody's lifting the print from software. It's hauled straight from the physics of a semiconductor, like trying to mask your voice when someone's reading your vocal cords with a spectrograph.

Compute Shaders as Recon Tools

WebGPU landed as the industry's answer to WebGL's cramped ceilings. Straight access to compute shaders, general-purpose parallel work, native-speed 3D and machine learning right inside the browser. Sounds wonderful until you reckon with the collateral wreckage.

A foundational gulf separates predecessor from heir. WebGL was a drawing API. WebGPU is a computing API. Ship arbitrary programs written in Wgsl, run them on the graphics chip with full dominion over buffers, textures, and pipelines. Each GPU implementation can expose dozens of adapter limits in the spec: max binding groups, workgroup size, storage buffer caps, peak texture dimensions. Every one of those parameters shifts between vendors, chip generations, and individual driver builds.

WebGPU compute shaders hand web pages capabilities once locked behind native-app walls. Along with that access comes the power to gauge exactly how your particular GPU runs particular operations. Atomic increments, memory barriers, parallel writes. All of it sculpts a profile tethered to one specific chip instance.

WiSec'25 flagged another, less obvious wrinkle: WebGPU fingerprinting sails right through the browser sandbox. No elevated privileges, no device-access dialogs. A web page calls navigator.gpu.requestAdapter(), kicks off a compute shader, and reads the result. Mechanically identical to rendering a game scene. Only the intent differs.

Systems like WHOX already reckon with this new terrain: checks F04 and F05 gather the bitmask of supported WebGPU features and a shader-compilation signature, while C54 catches mismatches between the WebNN backend and the software renderer. Three tiers of identification through a single technology.

GPU as a Side Channel: Keyboards and AES Under Fire

If 70% re-identification feels abstract, the next batch of studies makes it visceral.

ACM Asia CCS 2024 saw two papers land that should give pause to anyone who's ever typed a password in a browser.

First up: Generic and Automated Drive-by GPU Cache Attacks from the Browser by Lukas Giner and colleagues pulled off the first-ever attack on GPU cache from inside a browser via WebGPU. Ran across 11 desktop GPUs spanning two vendors and five generations. Three proof-of-concept scenarios yielded gnarly results:

Keystroke interception with F1-scores between 82% and 98% on Nvidia cards. Measured inter-keystroke timings through the GPU cache side channel. Reconstructed which keys got hit.

Full AES key recovery in 6 minutes. Six minutes flat. All it took to extract a cryptographic key from a GPU-resident encryption service by watching cache access patterns.

A covert data channel running at 10.9 kB/s between a native application and the browser. Plenty for steady data exfiltration.

Every bit of it works as a drive-by attack. Zero user interaction. No plugins. No downloads. An ordinary web page, quietly reading keystrokes the way a seismograph reads tremors through bedrock.

Second: WebGPU-SPY by Ethan Ferguson and colleagues at the same conference showed that GPU cache attacks can finger visited websites from the top 100 with 90% accuracy. Different pages force different GPU cache-access patterns. WebGPU-SPY watches those patterns from a separate tab, through the side channel, and fingers which site sits in the neighboring tab. No permission prompts. No activity spinners. A page silently reading what you're doing next door.

Your graphics card, the one drawing cat videos on YouTube right now, simultaneously tells any web page what you're typing. With up to 98% accuracy. Let that marinate.

Here's the crux that makes browser-level timer mitigations useless: these attacks lean on a clock built from GPU hardware resources, not JavaScript's performance.now() or Date.now(). Timer-precision caps brought in after Spectre and Meltdown don't touch this vector. GPUs ship their own high-precision time source, and you can't hobble it without gutting compute shader functionality.

Giner's team put it bluntly: Browser vendors need to treat access to the GPU similar to other security- and privacy-related resources. As of early 2026, no browser has heeded that call.

W3C and the WebGPU Dilemma

W3C's Privacy Working Group isn't sleepwalking. As early as 2022 a ticket got filed about the fingerprinting surface in the WebGPU spec, kicked off by a Ping review. In December 2024, Privacy Working Group members sat down with the WebGPU team to chew over permission prompts as a mitigation path.

Here's the snag: the industry needs WebGPU. 3D visualization, in-browser AI inference, scientific computing, games. Forcing users to approve GPU access on every site leads straight to the click-through reflex, people rubber-stamping Allow without reading. Same autopilot as notifications. Same as cookies.

April 2025's W3C fingerprinting mitigation guidance lays out three strategies: shrink the surface, gate access, standardize output. For WebGPU, none of them land clean. Shrinking the surface kills functionality. Gating access breeds trained helplessness. And standardizing hardware output is physically impossible when the differences dwell in the crystal structure of the chip.

A classic Procrustean trap: usefulness vs. privacy. W3C finds itself refereeing a bout where it must grow the web platform and shield users from that same platform, all at once. So far, usefulness is winning.

Part II. QUIC: Encrypted, Not Anonymous

38.1% of the Web on New Rails

QUIC outgrew its lab-experiment larval stage long ago. Per W3Techs data for February 2026, 38.1% of all websites run HTTP/3, which rides atop QUIC. Google, Facebook, YouTube, Instagram, Amazon, LinkedIn. Every heavyweight. QUIC is a fait accompli nobody can wave away.

QUIC's architects promised better speed, baked-in TLS 1.3 encryption, and sturdiness against interception. All true. Also true: QUIC ripped open an entirely fresh fingerprinting surface that never existed in TCP/TLS territory.

Anatomy of a QUIC Fingerprint

Every QUIC implementation hauls around a unique bundle of parameters legible at the wire level. Main vectors:

Transport parameters. Values for max_idle_timeout, max_udp_payload_size, initial_max_streams_bidi, and active_connection_id_limit diverge between browsers and versions. Chrome, Firefox, and Safari each pick different defaults. Even Grease fields, dreamt up to stave off protocol ossification, themselves turn into a signal.

Connection ID format. Length swings from 0 to 20 bytes depending on the implementation. Generation algorithms are idiosyncratic to each client library. Rotation patterns for connection identifiers betray the specific software stack.

HTTP/3 SETTINGS frame. Values of QPACK_MAX_TABLE_CAPACITY, QPACK_BLOCKED_STREAMS, and MAX_FIELD_SECTION_SIZE splinter across Chromium, neqo, and Safari.

Timing patterns. Initial packet sizes, congestion-control algorithm quirks, ACK cadence. Each parameter, utterly invisible to the person in the chair, becomes a telltale trait.

In WHOX, check A69 grabs the QUIC Initial Fingerprint in a format akin to JA4Q. A server-side check that trips before the web page loads, before JavaScript stirs. User opened a site. Their QUIC handshake already became a fingerprint.

99.79%: Machine Learning on QUIC Traffic

Academic numbers here read like a sentencing document.

In 2021, Smith et al. published a PoPETs paper on QUIC website fingerprinting and showed that classifiers trained on TCP lose 96% of their accuracy when thrown at QUIC traffic. Models trained on QUIC data from scratch, though, work with unnerving efficiency. By 2023 an AutoML-based approach hit an F1-score of 99.79% at identifying visited websites from QUIC traffic. Near-perfect. Moving the web to HTTP/3 didn't make website fingerprinting harder. Just demanded fresh training data.

That same ETH Zurich study, titled Website Fingerprinting in the Age of QUIC, also revealed that QUIC is more susceptible to fingerprinting during early connection phases than HTTPS. Stream multiplexing inside a single UDP connection, one of QUIC's speed wins, carves characteristic packet-size and timing signatures unique to each site. A sommelier tells the grape from how wine clings to the glass, even with the label torn off. Same principle with QUIC traces and their telltale silhouettes.

VisQUIC: 100,000 Traces, 97% Accuracy

Most sweeping contribution to QUIC fingerprinting belongs to the VisQUIC project. In 2025, Barak Gahtan and colleagues published a dataset of over 100,000 labeled QUIC traces from 44,000 websites, gathered across four months.

VisQUIC's trick is distinctive: researchers convert packet traces into images, then sic convolutional neural networks on them. Benchmark yielded 97% accuracy at gauging the count of HTTP/3 responses in fully encrypted QUIC traffic, meaning the system tallies how many resources a page fetched without cracking the encryption at all. 92% accuracy on traces the model had never seen.

Encryption doesn't cloak patterns. Packet sizes, time gaps, stream architecture, all of it stays legible from outside, even when the payload is locked tight. A bedrock limitation of any transport-layer encryption: you can hide the data, not the metadata. Sealed envelope hides the letter, yet anyone with a kitchen scale can still weigh it.

VisQUIC ships SSL keys for controlled decryption and covers multiple stacks: Chromium QUIC, Facebook mvfst, Cloudflare quiche. Open dataset. Anyone can train their own QUIC fingerprinting model.

JA4+ and the Standardization of QUIC Fingerprinting

QUIC fingerprinting already lives inside the JA4+ specification from FoxIO, deployed by major CDNs and security outfits. Just as JA3 became the lingua franca of TLS fingerprinting, JA4Q is becoming the standard for QUIC. Moving from labs into production at speed.

Big CDN providers like Cloudflare, Akamai, and Fastly carry a hefty share of global HTTP/3 traffic. Every one of them has the technical wherewithal to grab a QUIC fingerprint at the front door. Nobody's asking whether they do it. Real question is who sees the results.

Connection Migration: Tracking Across Network Switches

One of QUIC's flagship perks, a feature sold as an unalloyed good, turned into yet another attack vector. Connection migration lets a QUIC session survive a network hop. Step off WiFi onto cellular. Connection keeps breathing. Handy for you. Windfall for trackers: the server shadows a device across IP changes.

Old-school TCP severs the link on an IP swap. New IP, new connection, new identity window. QUIC connection migration blows that convention to rubble. Server knows the client showing up from a fresh IP is the same client who started the session on the old one. Seamless handoff for the user. Identity correlation across network switches for anyone watching, with zero extra legwork.

Every QUIC implementation carries a characteristic parameter profile that holds steady between sessions, between networks, between IP addresses. Pair that with browser-side signals and you've got cross-session binding that no VPN toggle can break.

Part III. eBPF: Fingerprints at the Kernel Level

TCP SYN: Your First Packet Gives You Away

Say you're the paranoid type. You block JavaScript. Fire up Tor. Spoof the User-Agent. Nuke every cookie. You feel invisible.

Bad news: your very first TCP SYN packet already told the server which operating system you run.

Every OS crafts TCP SYN packets its own way. Parameters woven into the opening handshake form a unique signature:

Window Size. Linux defaults to one value, Windows to another, macOS to a third.

MSS, Maximum Segment Size. Textbook number for an Ethernet link is 1460 bytes. Connect through a VPN, though, and that number shrinks from tunneling overhead. One parameter, and your VPN is blown.

TCP Options order. Windows, Linux, and macOS line up options differently: window scale, Sack, timestamps. Ordering stays stable for a given OS and version.

Window Scaling Factor. Varies by OS.

TTL, Time to Live. Linux and macOS ship 64, Windows ships 128. Even stripped of everything else, that lone datum splits all visitors into three camps.

Don't Fragment bit. Behavior hinges on the OS.

Lash these six together and you get a string unique to the OS, its version, and network-stack config. Windows 10 and Windows 11 look different. Ubuntu 22.04 and Fedora 39 look different. macOS Sonoma and macOS Ventura look different. All different in predictable, replicable ways, like how a seasoned mail carrier knows which printer spit out a letter by the toner smudge.

None of it sits under the browser's thumb. JavaScript can't touch a TCP packet's TTL. A privacy extension can't overwrite the Window Size. Parameters dwell in the OS network stack. Below every privacy tool most folks have ever heard of.

p0f Is Dead, Long Live JA4T

TCP fingerprinting isn't new. p0f was doing this in the early 2000s. Bottleneck was scale. p0f ran in userspace, snagged packets through libpcap, and on busy servers ate noticeable overhead. A researcher's toy, not a production weapon.

eBPF rewrote the playbook.

In 2025, Alberto Ventafridda published a series on Implementing fast TCP fingerprinting with eBPF, backed by open-source code on GitHub. In parallel a JA4T implementation on eBPF landed for nftables.

JA4T is the modern TCP fingerprint format, part of FoxIO's JA4+ family. Packs Window Size, TCP Options, MSS, and Window Scale into a terse string. Each unique combo pins down the OS, its version, and the network setup.

Why eBPF Changes the Scale

eBPF, extended Berkeley Packet Filter, lets you run programs straight inside the Linux kernel without patching it. For TCP fingerprinting, that unlocks several things at once:

In-kernel processing. Zero-copy, no packet-capture overhead. Fingerprint gets taken the instant the SYN arrives, within the kernel's own network-stack context.

Real time. Print is ready before HTTP processing kicks off. Before HTML loads. Before JavaScript wakes up. Before the browser itself knows which site it went to.

Scale. Millions of connections per second with no performance sag. Not a lab curiosity. A production-grade weapon.

No userspace chokepoint. Old-fashioned packet capture needs to copy data from kernel to userspace. eBPF skips that step entirely.

For anyone running a web service, the upshot is blunt: bolting TCP fingerprinting onto existing infrastructure takes no app-code changes, no web-server mods, and zero performance hit. Load the eBPF program into the kernel, wire up data export, done. Every incoming connection's fingerprint sits there in real time.

A September 2025 analysis from eBPF Chirp laid out how eBPF fingerprinting is already weaponized for blocking automation at internet scale. Anti-bot stacks wield TCP fingerprints to spot Puppeteer, Playwright, and Selenium. Automation tools mimic browser behavior flawlessly at the JavaScript layer but forget to mimic the OS network stack. Headless Chrome in a Docker container on Linux fires a SYN with TTL=64 and a Linux-flavor TCP Options order, even while its User-Agent swears it's Windows 10. A dead giveaway, like wearing a tuxedo with muddy work boots.

WHOX chains several network checks for exactly this purpose. Check C09 aggregates TTL, MTU, and RTT anomalies into a single consistency signal. If the claimed OS is Windows yet the SYN packet carries TTL=64, that contradiction gets flagged. Combine it with JA4 and JA4H fingerprints plus a VPN-tunnel MTU/TTL pattern detector and you've got a multilayered network-identification system humming along well before browser-signal collection begins.

Part IV. Three Technologies, One System

Identity Stack of the Future

Taken as separate research topics, WebGPU, QUIC, and eBPF look impressive. Taken as a single coordinated system, they're terrifying.

Picture the identification stack circa 2027:

Layer 1: eBPF. Fingerprint drawn during the TCP handshake. OS pinned down. VPN spotted via MSS. Gap between claimed and actual environment logged. All of it milliseconds before the page loads.

Layer 2: QUIC. HTTP/3 transport parameters sharpen the identification. Specific browser and version read from the SETTINGS frame. Packet patterns cross-referenced with visit history. Accuracy with a trained model: 97% and above.

Layer 3: WebGPU. Compute shaders harvest a hardware fingerprint from the GPU. Silicon-level variations pin down the exact physical device. Print survives browser swaps, OS reinstalls, IP changes. Hardware binding. Permanent. A serial number etched into bone.

Three layers. Network, transport, hardware. Each works on its own. Each needs no special privileges. Together they forge an identification system that software alone can't dodge.

Quantitative Perspective

Numbers in one table:

Technology	Metric	Source
WebGPU re-ID	70% out of 500 devices	WiSec'25
GPU keystrokes	82-98% F1-score	Asia CCS '24
AES key recovery	6 minutes	Asia CCS '24
Drawnapart tracking	+67% tracking duration	NDSS'22
QUIC website FP	99.79% F1-score	AutoML, ScienceDirect 2023
VisQUIC encrypted	97% accuracy, 100K traces	arXiv 2025
HTTP/3 adoption	38.1% of sites	W3Techs, Feb 2026
eBPF TCP FP	real-time, in-kernel	halb.it 2025

Every row is a separate academic paper, a separate conference, a separate research team. Stitched together they tell one story: room for anonymity on the web is shrinking from three directions at once.

What Means for WHOX

WHOX scores signals along three axes: Fingerprint, Consistency, and Anonymizer. Each technology beefs up one or more of those axes.

WebGPU injects hardware signals that can't be faked in software. Feature bitmask, adapter-limit signature, shader-compilation fingerprint. Uniqueness driven all the way down to physics.

QUIC injects a transport fingerprint harvested server-side. QUIC Initial parameters, Connection ID format, SETTINGS frame. Environment-spoofing detection stretched to the protocol tier.

eBPF injects pre-JavaScript identification. TTL, MSS, TCP Options order. A consistency check that starts humming before the first HTTP request leaves the wire.

Network signals carry roughly 40% of the weight in cross-session binding. Deep hardware signals, GPU timing and WebGPU shader hashes among them, carry around 30%. As WebGPU and QUIC mature, both buckets will swell. Hardware prints will grow steadier. Network prints will grow sharper.

When every visit leaves a hardware GPU print, a QUIC transport print, and a TCP network print, the payoff of cross-session linking climbs. And with it, the user's digital shadow lengthens.

Part V. What to Do, and Why It's Hard

Defenses That Don't Work

WWW'25's study Breaking the Shield by Hoang Dai Nguyen tore apart fingerprinting defenses in 18 Chrome and Firefox extensions and built-in protections of five browsers. Verdict: no fully deployable defense against canvas fingerprinting attacks exists currently. For WebGPU the picture is bleaker still, because hardware-level variations simply can't be papered over in software.

Against QUIC fingerprinting the user is helpless. Transport parameters are chosen by the browser, not the person at the keyboard. You could flip HTTP/3 off, sure, yet with 38.1% of the web leaning on it, that means hobbling a third of the internet. And the sheer act of turning HTTP/3 off becomes its own signal: the absence of an expected protocol registers as an anomaly.

Against eBPF TCP fingerprinting there's no defense at all. Users don't govern how their OS assembles TCP SYN packets. Only lever: kernel modification. In practice that translates to: no lever.

Tor: Last Bastion and Its Price

Tor Browser stands alone as the tool that systematically tackles all three vectors. WebGPU off. QUIC off. TCP parameters standardized through the Tor network. Toll is savage, though: radical loss of functionality and speed. Even Tor doesn't block everything. Traffic fingerprinting at exit nodes stays an active research front.

For the everyday user Tor isn't a realistic option. Telling someone to commute by hot-air balloon because cars pollute doesn't really solve anything.

Firefox in Strict ETP mode with letterboxing flattens some parameters: CPU=2, Memory=2GB, UTC timezone. Brave sprinkles randomization over canvas and WebGL. Yet no mainstream browser standardizes TCP parameters, kills WebGPU compute shaders, or masks QUIC transport parameters. Doing so would bleed performance and features, and in the arms race for users no vendor will volunteer for that handicap.

Regulators and Industry

In December 2024 the ICO branded fingerprinting irresponsible after Google lifted its fingerprinting ban for advertisers. Five grounds: can't consent, can't erase, can't block, opaque, privacy-minded users still exposed.

All five apply cleanly to WebGPU, QUIC, and eBPF fingerprinting. With one twist: for these technologies, even theoretical fixes don't exist yet.

Google, holding 65% of the browser market, in April 2025 walked back its pledge to kill third-party cookies. Cookies stayed. Fingerprinting got the green light. WebGPU on by default. HTTP/3 on by default. Industry landed maximum identification tools with minimum guardrails.

Conclusion: A Race Nobody Can Win

By 2027 WebGPU will be a standard API in every major browser. HTTP/3 will cross the 50% mark of web traffic. eBPF-based fingerprinting will be standard practice for anti-fraud and anti-bot systems.

Each of these technologies mints a new fingerprint sitting below the floor where existing privacy tools operate. Browser extensions can't rewire GPU behavior. Privacy toggles don't steer QUIC parameters. Clearing your data does nothing against a TCP fingerprint.

Research from WiSec'25, Asia CCS '24, VisQUIC, and the eBPF fingerprinting papers all point one way. Identification is going hardware, going protocol, going kernel. Drifting out of the user's reach, like a kite whose string just snapped.

Your GPU ratted you out before the page loaded. QUIC handshake confirmed it. SYN packet named your operating system before TLS even began. Three identification layers. None visible. None optional. None yours to switch off.

FAQ

What is WebGPU fingerprinting? WebGPU is the new graphics API for browsers, heir to WebGL. Compute shaders let it run arbitrary calculations on the GPU. Research from WiSec'25 showed 70% device re-identification accuracy from a pool of 500 devices via AtomicIncrement fingerprints. Manufacturing-level silicon variations make each chip unique. No browser currently has protection against WebGPU fingerprinting.

What are GPU cache attacks and how dangerous are they? Researchers at ACM Asia CCS 2024 showed keystroke interception via the GPU cache side channel with 82-98% F1-score on Nvidia, full AES key recovery in 6 minutes, and a covert data channel at 10.9 kB/s. WebGPU-SPY identifies websites loaded in other tabs with 90% accuracy. Everything works as a drive-by attack, no user interaction required.

What is QUIC fingerprinting and how accurate is it? QUIC is the protocol underneath HTTP/3, used by 38.1% of websites per W3Techs, February 2026. Each QUIC implementation has unique transport parameters. VisQUIC achieves 97% accuracy estimating HTTP/3 response counts in fully encrypted traffic from a dataset of 100,000+ traces. An AutoML method reached 99.79% F1-score. Encryption hides content, not metadata.

How does eBPF fingerprint before the page loads? eBPF allows programs to run inside the Linux kernel to analyze every TCP SYN packet. Parameters like TTL, where Windows sets 128 and Linux sets 64, Window Size, MSS, and TCP Options order create a unique OS signature. JA4T encodes these parameters. Fingerprint is ready before HTML loads, before JavaScript executes. MSS below 1460 reveals a VPN tunnel. JavaScript cannot modify these parameters.

Can fingerprinting work without JavaScript, using only CSS? Yes. Cascading Spy Sheets from NDSS 2025 hits 98% browser identification accuracy via CSS: @supports checks properties, CSS selectors detect extensions, and font fingerprinting identifies the OS. Fontleak extracts DOM text content through CSS ligatures. Works in email clients that block JS. Blocking JavaScript is like locking the door while leaving every window wide open.

WebGPU, QUIC, eBPF: Three Technologies That Will Reshape Fingerprinting by 2027