SIMD (Single Instruction, Multiple Data)
What SIMD means, how WebAssembly exposes it to the browser, and why the time a SIMD instruction takes to execute is one of the hardest signals for a bot to fake.
Bots claiming hardware they are not running on?
Prosopo checks the claim against the processor. Book a Bot Exposure Assessment.
What SIMD means
SIMD stands for Single Instruction, Multiple Data. It is a class of processor instruction that performs the same operation on several values at once, rather than one at a time.
Adding four pairs of numbers one pair at a time takes four instructions. A SIMD instruction adds all four pairs together in one. The processor has wide registers that hold several values side by side, and the instruction operates on the whole register.
Almost every modern processor supports SIMD, from server CPUs to the chips in mobile phones. It is what makes video decoding, image filtering, audio processing and machine-learning workloads fast enough to be usable.
How a browser reaches SIMD
WebAssembly SIMD is an extension to the WebAssembly standard that lets code running inside a browser use the processor's SIMD instructions. It was added so that browser applications could get close to native speed on the kinds of workloads that need it. Every current major browser supports it.
For bot detection that means a web page can measure something about the physical processor underneath, rather than only reading what the browser says about itself.
Why SIMD timings are useful for bot detection
Most browser fingerprinting reads properties the browser reports. The reported processor count, the platform string, the user agent. All of those are simply values, and a modified browser build can return whatever value its operator chooses. Changing the reported core count in a patched Chromium is a one-line change to the source, and once the modified binary is running there is no runtime patch left to catch.
A timing is different. How long the processor takes to complete a SIMD operation is a property of the silicon. It is not a value the browser holds and can rewrite. To change it, the operator has to intercept the measurement itself and return invented numbers.
The difficulty for them starts there. A convincing forgery has to hold across several different operations, stay plausible as system load varies, and reproduce the natural variation real hardware shows. Invented timings tend to be too stable, and consistency of that kind is itself a signal.
The hardware lie
The most common use is checking a device claim against the processor.
A session arrives claiming to be a particular phone. The user agent says so, the screen dimensions agree, and the reported hardware properties agree, because all of those are values the operator set. Then the SIMD timings come back matching a desktop server processor rather than a mobile one.
Nothing was spoofed badly. Every reported field was consistent. The processor underneath simply is not the one the session claims to be running on, and the timing shows it. Prosopo returns this as Inconsistent hardware readings for device.
This catches a category of automation that defeats most other checks: a virtual machine running a genuine mobile browser build, on rented server hardware. There is no fake browser to detect, because the browser is real. The mismatch is between the device being claimed and the processor doing the work.
What it does not catch on its own
A SIMD reading describes the class of processor. It does not say whether the person using it is behaving well.
Real hardware also produces a wide range of readings. A budget Android handset and a current desktop are both legitimate, and both produce very different numbers. So the useful comparison is not "is this processor fast", it is "does this processor match what the session claims to be". Detection also has to allow for the cases where a slow reading is entirely normal, such as an older device or an in-app browser on modest hardware.
SIMD timing is therefore one signal among many rather than a verdict on its own. It works alongside DNS resolution paths, behavioural analysis and device fingerprinting, each of which is difficult to fake for a different reason. A JA4 TLS fingerprint sits alongside them but does a narrower job: it identifies the TLS stack, and every Chrome install produces the same one, so it is decisive against a non-browser client and silent between two real browsers. An operator who defeats one signal still has to defeat the others at the same time.