# audio-ctx — VALIDATION RESULTS

## Signal hypothesis

Real hardware audio produces deterministic-but-unique fingerprints based on
the audio stack's float precision. Headless without real audio returns
defaults. Sample rate itself is a signal: real=44100/48000, headless=8000/22050.

## 3-condition results

| Condition | sampleRate | audioSum | audioSumHash | verdict |
|---|---|---|---|---|
| Vanilla headless | 48000 | 172.67165096 | `1333771d` | ✅ Real Chrome |
| CDP-attached | 48000 | 172.67165096 | `1333771d` | ✅ Real Chrome |
| Headful (Xvfb) | 48000 | 172.67165096 | `1333771d` | ✅ Real Chrome |

**All 3 conditions IDENTICAL**: same sample rate, same audio sum, same hash.
Chrome's audio stack is identical in headless and headful modes.

## Verdict: ❌ REJECTED — no discriminator on this server

The audio fingerprint is **deterministic per Chrome version, not per
hardware**. The same hash on all 3 conditions means:
- Chrome 148 audio stack produces `audioSum=172.67` regardless of mode
- The fingerprint is a **Chrome-version fingerprint**, not a hardware fingerprint
- Server has no real audio hardware, but Chrome emulates the audio stack
  with the same numerical behavior

**Real desktop implication:** A real Mac's audio stack will produce a
DIFFERENT fingerprint than a Linux server. But the same Mac running
headless Chrome will produce the same fingerprint as headful. So this
signal discriminates **OS/platform**, not headless-vs-headful.

## Recommendation

DO NOT SHIP as a headless detector. Could ship as a **stealth-platform
detector**: a Windows user-agent with a Linux/Mac audio fingerprint is
suspicious. But that's a composite check, not a Phase 1 finding.

## Alternative use case (not pursued)

The audio fingerprint is useful for **tracking returning visitors** (CreepJS
style) — same browser returns same fingerprint. Not a bot-detection signal.

## Files

- `demo.html`