write · read · delete tens of thousands of small records · timing pattern is stable enough to identify your storage stack · runs locally
how it works
indexeddb is implemented differently on every browser, os, and storage hardware stack. chrome on an nvme ssd will produce different per-operation timings than safari on a hard drive, or android chrome on emmc flash. by running write, read, and delete benchmarks and observing the ratio between them we can derive a stable hardware+browser fingerprint that doesn’t need canvas or webgl.
benchmark
why this matters
- storage timing is hardware-revealing. the relative speeds of random read vs sequential write vs delete operations change dramatically between ssd classes, emmc, and spinning rust.
- no visual permissions needed. indexeddb is available to any first-party context without user prompts, making storage timing a silent fingerprinting vector.
- partition key isolation (the modern browser mitigation) separates storage between top-level sites but doesn’t change the per-operation timing profile.