AudioContext and Fonts: The Forgotten Detection Vectors for Multi-Accounting

Most discussions of browser fingerprinting focus on the obvious suspects: WebGL renderer strings, canvas hashes, and navigator properties. This focus is understandable — those vectors are well-documented and visually intuitive. But in 2026, the detection systems at major platforms have largely solved the obvious vectors. The battles now being fought are over the subtler surfaces: AudioContext characteristics and font enumeration — two fingerprinting vectors that many anti-detect implementations handle poorly or ignore entirely.

Why These Vectors Persist

AudioContext and font fingerprinting share a common property that makes them resilient to naive countermeasures: they expose information about the underlying hardware and system configuration that isn’t straightforward to spoof at the JavaScript layer.

Canvas fingerprinting probes the GPU rendering pipeline through a drawing API. AudioContext fingerprinting probes the audio processing hardware through a signal processing API. Both reveal hardware characteristics through the subtle numerical outputs of hardware-accelerated computation. Font fingerprinting reveals system configuration — what software is installed on the machine.

Critically, both vectors are underprotected by the major anti-detect tools on the market. Checking your anti-detect browser profile against sites like coveryourtracks.eff.org or amiunique.org will show canvas and WebGL coverage prominently displayed. AudioContext and font protection quality is rarely surfaced with the same clarity, making them easy to overlook — and easy for detection systems to exploit.

AudioContext Fingerprinting: The Mechanics

The Web Audio API was designed for sophisticated in-browser audio processing: mixing, filtering, spatialization. It exposes this processing power through a graph of audio nodes that transform input signals. The fingerprinting community discovered that this graph, when used to process a specific test signal, produces numerically different outputs on different hardware configurations.

The Basic Oscillator Test

The most common AudioContext fingerprint uses an oscillator connected to a compressor connected to an analyser:

function getAudioFingerprint() {
  return new Promise((resolve) => {
    const context = new OfflineAudioContext(1, 44100, 44100);
    
    // Oscillator: generate a specific waveform
    const oscillator = context.createOscillator();
    oscillator.type = 'triangle';
    oscillator.frequency.setValueAtTime(10000, context.currentTime);
    
    // Compressor: apply dynamic range compression
    const compressor = context.createDynamicsCompressor();
    compressor.threshold.setValueAtTime(-50, context.currentTime);
    compressor.knee.setValueAtTime(40, context.currentTime);
    compressor.ratio.setValueAtTime(12, context.currentTime);
    compressor.attack.setValueAtTime(0, context.currentTime);
    compressor.release.setValueAtTime(0.25, context.currentTime);
    
    oscillator.connect(compressor);
    compressor.connect(context.destination);
    oscillator.start(0);
    
    context.startRendering().then(buffer => {
      const data = buffer.getChannelData(0);
      
      // Sum a sample of the audio data
      let fingerprint = 0;
      for (let i = 4500; i < 5000; i++) {
        fingerprint += Math.abs(data[i]);
      }
      
      resolve(fingerprint);
    });
  });
}

The output of this function — a single floating-point number — differs between hardware configurations due to:

1. DSP implementation differences. The dynamics compressor algorithm involves floating-point arithmetic. Different audio processing hardware and drivers implement this arithmetic at different precision levels and with different optimization paths.

2. Sample rate conversion. If the requested sample rate (44100 Hz) differs from the hardware’s native sample rate, the browser applies sample rate conversion. Different conversion algorithms produce different numerical outputs.

3. Audio processing path. Some systems route audio through hardware DSP (dedicated audio chips), others through software implementation on the main CPU. The numerical outputs differ.

4. Floating-point rounding. The compressor’s attack and release parameters involve exponential calculations. Rounding at different stages produces different final values.

AudioContext Hardware Parameters

Beyond the oscillator test, AudioContext exposes several hardware parameters directly:

const ctx = new AudioContext();

// Hardware-dependent properties
console.log(ctx.sampleRate);           // 44100, 48000, 96000, 192000...
console.log(ctx.baseLatency);          // Hardware buffer latency
console.log(ctx.outputLatency);        // Total output latency

// Audio worklet processing chunk size (hardware-dependent)
// Typically 128 or 256 samples, varies by hardware/OS

The sampleRate is particularly significant: it reflects the native sample rate of the audio hardware. Consumer audio chips typically use 44100 Hz (CD quality). Professional audio interfaces often use 48000 Hz or higher. Some systems auto-detect based on the connected output device. A user with studio monitors connected might have a different sample rate than a user with headphones.

The baseLatency and outputLatency values encode audio hardware buffer sizes, which are hardware-specific. A system using a high-end audio interface with ASIO drivers might have latency of 3ms; a system with integrated Intel audio might have 46ms.

Identifying the Sound Card Through API Behavior

Detection scripts can infer specific audio hardware by combining multiple AudioContext probes:

async function getAudioHardwareProfile() {
  const ctx = new AudioContext();
  
  return {
    sampleRate: ctx.sampleRate,
    maxChannelCount: ctx.destination.maxChannelCount,
    channelCount: ctx.destination.channelCount,
    channelCountMode: ctx.destination.channelCountMode,
    channelInterpretation: ctx.destination.channelInterpretation,
    baseLatency: ctx.baseLatency,
    outputLatency: ctx.outputLatency,
    // Fingerprint hash from oscillator test
    hash: await getAudioFingerprint()
  };
}

The maxChannelCount reveals whether the audio hardware supports stereo (2), 5.1 surround (6), 7.1 surround (8), or professional multi-channel audio. This, combined with the sample rate and latency values, creates a signature that correlates with specific audio hardware classes.

Font Fingerprinting: Enumerating What’s Installed

Font fingerprinting exploits a simple fact: different computers have different fonts installed. The OS provides a base set; applications add more. A designer’s machine might have hundreds of licensed typefaces. A corporate machine might have only the Microsoft Office font pack. A developer machine might have Google Fonts, Nerd Fonts, and various other open-source typefaces.

The Classic Measurement Method

The traditional font enumeration method renders text in candidate fonts and measures the rendered width:

function isFontAvailable(fontName) {
  const testString = 'mmmmmmmmmmlli';
  const testSize = '72px';
  const canvas = document.createElement('canvas');
  const ctx = canvas.getContext('2d');
  
  // Measure with a known fallback font
  ctx.font = `${testSize} monospace`;
  const fallbackWidth = ctx.measureText(testString).width;
  
  // Measure with the candidate font
  ctx.font = `${testSize} '${fontName}', monospace`;
  const candidateWidth = ctx.measureText(testString).width;
  
  // If widths differ, the candidate font is installed
  return fallbackWidth !== candidateWidth;
}

// Check a list of candidate fonts
const candidateFonts = [
  'Arial', 'Arial Black', 'Calibri', 'Cambria', 'Candara',
  'Comic Sans MS', 'Consolas', 'Constantia', 'Corbel', 'Courier New',
  'Fira Code', 'Georgia', 'Helvetica', 'Impact', 'Lato',
  'Meiryo', 'Microsoft Sans Serif', 'Osaka', 'Palatino',
  'Roboto', 'Segoe UI', 'Tahoma', 'Times New Roman', 'Trebuchet MS',
  'Verdana', 'Wingdings', /* ... 200+ more ... */
];

The Local Font Access API

The newer window.queryLocalFonts() API (available in Chrome 103+) provides direct programmatic access to the full list of installed fonts, requiring only a user permission prompt:

async function getInstalledFonts() {
  const fonts = await window.queryLocalFonts();
  return fonts.map(f => ({
    family: f.family,
    style: f.style,
    fullName: f.fullName,
    postscriptName: f.postscriptName
  }));
}

While this requires permission, detection scripts can still use the output to create a highly unique fingerprint. A set of 847 installed fonts is a stronger identifier than any single technical parameter.

What Font Sets Reveal

Font analysis reveals more than just which machine this is — it reveals usage context:

Operating system and region. Windows installs different base font sets than macOS or Linux. Localized versions of Windows include region-specific fonts. A system with Japanese system fonts (Meiryo, MS Gothic, Yu Gothic) almost certainly has Japanese locale configured.

Installed software. Microsoft Office installs Calibri, Cambria, Candara, Consolas, Constantia, Corbel. Adobe products install Myriad Pro, Minion Pro, and dozens of others. Developer tools sometimes install technical fonts.

User profile persistence. Font sets change slowly. A user who installs a font in January still has it in December. This makes font fingerprints highly stable across browser updates, OS reinstalls (if the user restores their files), and even device changes.

Account linking. Two accounts that share an unusual font (a rare commercial typeface, a specialized technical font) are correlated. The more unusual the fonts, the stronger the link.

How Detection Systems Use These Vectors

AudioContext Linking

Detection systems at major advertising and e-commerce platforms compute AudioContext fingerprints for every session and compare them against the fingerprint history for the associated account. When two accounts share the same AudioContext fingerprint, it’s strong evidence they originate from the same physical machine.

The key insight: AudioContext fingerprints are highly stable. Unlike IP addresses (which change with VPN or residential proxy rotation), the AudioContext fingerprint reflects physical hardware that doesn’t change. An operator running 50 accounts on the same physical machine — even with different proxies, different browser profiles, different User-Agent strings — will expose them all through a shared AudioContext fingerprint if the anti-detect solution doesn’t address this vector.

Font Intersection Analysis

Rather than using the full font set as a fingerprint (which would be too noisy across accounts), detection systems use rare font presence as a linking signal. The algorithm:

1. Compute the population frequency of each installed font across all observed sessions
2. Identify low-frequency fonts (installed by fewer than 1% of users)
3. When two accounts share two or more rare fonts, flag them for review

This is a probabilistic approach but highly effective. Rare fonts like custom typefaces purchased from type foundries, proprietary corporate fonts, or obscure open-source fonts are strong linking signals even with noisy data.

Effective Protection Methods

AudioContext: Deterministic Seed-Based Noise

The effective protection for AudioContext fingerprinting is not to block the API (which is itself a detectable anomaly) but to inject deterministic, profile-specific noise into the audio output:

// Conceptual: per-profile seeded noise for AudioContext
// Real implementation requires native browser modification

const profileSeed = 0x8f3c2a91; // Derived from profile identifier

function seededRandom(seed) {
  // LCG pseudo-random number generator
  return ((seed * 1664525) + 1013904223) & 0xffffffff;
}

// Applied to audio output buffers at the native level
// Produces consistent output per profile, different across profiles

The critical requirement: the noise must be:

• Deterministic per profile — the same profile always produces the same AudioContext fingerprint
• Unique per profile — different profiles produce different fingerprints
• Realistic in magnitude — noise amplitude must be within the range of real hardware variation, not obviously artificial
• Statistically plausible — the modified output must pass statistical tests for real audio hardware output

Font Sets: OS-Consistent Profiles

Font protection requires restricting the reported font list to an OS-appropriate set:

// The anti-detect browser intercepts font measurement at the native level
// JavaScript sees only the declared font set, not the real installed fonts

// Windows 11 base font set (what's installed by default)
const windowsBaseFonts = [
  'Arial', 'Arial Black', 'Calibri', 'Cambria', 'Comic Sans MS',
  'Consolas', 'Constantia', 'Courier New', 'Georgia', 'Impact',
  'Microsoft Sans Serif', 'Segoe UI', 'Tahoma', 'Times New Roman',
  'Trebuchet MS', 'Verdana', 'Wingdings'
];

// Optional additions: MS Office pack
const officeAdditions = [
  'Candara', 'Corbel', 'Franklin Gothic Medium', 'Palatino Linotype'
];

The important nuance: a font profile must be consistent with the claimed OS and the claimed use-case profile. A “corporate Windows user” profile should have the Office font pack. A “home user” might not. A macOS profile should not include Windows-exclusive fonts.

The window.queryLocalFonts() API must be blocked or return a filtered list consistent with the profile. Blocking the API entirely is detectable — it’s better to return a realistic, OS-appropriate list.

Sound Card Emulation: Matching the Hardware Profile

When an anti-detect profile claims specific hardware (e.g., “Dell laptop with Intel Core i7”), the AudioContext parameters must match what that hardware actually produces:

Hardware Type	Typical Sample Rate	Typical Base Latency	Max Channels
Intel integrated audio (laptop)	44100 or 48000 Hz	40-50ms	2
Realtek HD Audio (desktop)	44100 or 48000 Hz	20-30ms	8
Apple Silicon (M-series)	48000 Hz	10-15ms	2
Professional USB audio interface	44100, 48000, or 96000 Hz	3-10ms	2-32

A profile claiming to be a standard Windows laptop should not have the AudioContext characteristics of a professional studio workstation with a high-end audio interface. The cross-signal consistency between claimed hardware and AudioContext parameters is what modern detection systems verify.

The Combined Attack Surface

The power of these vectors for detection systems lies in their combination. A detection system that observes:

• Canvas hash matches profile A
• WebGL renderer matches profile A
• AudioContext fingerprint matches profile A
• Font set overlaps significantly with profile A

…has extremely high confidence that the current session originates from the same physical machine as profile A, regardless of proxy IP, User-Agent string, or any other manipulated parameter.

The math is straightforward: if each signal has a 1% false positive rate (independent signals that happen to match by coincidence), combining four such signals produces a false positive rate of 0.01% — high enough confidence to trigger account review in an automated system.

Practical Implementation Gaps

The most common failure mode in production anti-detect setups is partial implementation. AudioContext protection is applied but with incorrect parameters (wrong sample rate for the claimed hardware). Fonts are restricted but to a list that doesn’t match the claimed OS (macOS fonts appearing in a Windows profile).

These partial implementations are often worse than no implementation: they create internally inconsistent profiles that combine some spoofed signals with some real signals. The inconsistency is itself a fingerprint — it marks the session as using an anti-detect tool without doing it correctly.

Santiago Browser addresses this by treating AudioContext parameters and font sets as derived properties of the hardware profile, not independent configuration options. When you select hardware parameters for a profile, the AudioContext sample rate, latency values, and audio noise seed are automatically set to values consistent with that hardware class. Font sets are selected from OS-appropriate distributions. The result is internal consistency across all vectors — which is the only approach that resists detection systems designed to probe consistency rather than individual parameter values.