Keystrokes have dwell and flight time
Check id keystroke-timing-distribution
What an ordinary browser yields
Contextual only: dwell and flight are both above zero and vary between keys, consistent with a hand rather than a timer.
What a detector infers
The probe records only two timings per key: dwell, from keydown to keyup, and flight, from one key's release to the next key's press. No characters are stored. Playwright's Keyboard.type() reads (options && options.delay) || undefined and emits with no pause when the option is unset, so both collapse to approximately zero — keys that go down and up in the same instant were not pressed by a finger. A configured constant delay produces the inverse signature: flight times that barely vary. The check is informational and never scored, for a reason worth stating plainly: fifteen keystrokes cannot support a claim about the shape of a distribution, and asserting otherwise would be exactly the overclaiming this page exists to criticise. It also has many innocent silent cases — clipboard paste, password managers and input method editors all decouple keystrokes from characters and legitimately produce no per-key timing at all.
How to resolve it
Nothing to fix if you are a human typing. If input is synthesised, note that both an absent delay and a fixed delay are visible — the first as zero-length dwell, the second as flight times with almost no variance. This cell is unscored, and a short or empty sample is reported as such rather than counted against anything.
Read in the wild by
Akamai
Lists key codes and inter-keystroke timing as behavioural signals.
signal_categories.md - 4. Behavioural - Keyboard events: Key codes, timing between keystrokes
Edioff/akamai-analysis — signal_categories.mdEvery attribution traces to a published artifact. See the sources and their limits.
Other checks in Input & behaviour
- Pointer path curves the way a hand moves
pointer-path-linearityThe check captures the pointer path across the pad and measures two things about its geometry: the RMS perpendicular distance of every… - Pointer velocity and acceleration vary physically
pointer-kinematicsVelocity, acceleration reversals, direction changes, and timestamp quantisation catch constant-speed curved automation missed by linearity. - Pointer events arrive on hardware time
pointer-event-cadenceWhere the linearity check reads the path's shape, this one reads its clock. - Movement deltas agree with the coordinates they were derived from
pointer-movement-delta-coherenceEvery pointer event carries two independent accounts of the same displacement. screenX and screenY are where the pointer is; movementX and… - Event.isTrusted separates page script from the input pipeline
event-istrusted-provenanceThis row exists to debunk a check rather than to run one, which is why it can never fail.
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Input & behaviour checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Input & behaviour — the family keystroke-timing-distribution belongs to.