pointer samples arrive batched the way a hardware device delivers them
A readout: samples per move, the share of batched moves, and raw updates per move. Never scored (severity: info).
What a detector infers
Chrome delivers pointermove once per display frame and folds every hardware report that arrived in between into getCoalescedEvents(); pointerrawupdate fires once per report, not per frame. A mouse polled faster than the display refreshes therefore delivers several samples per move and more raw updates than moves.
Input dispatched through the DevTools protocol has no device behind it: measured on stock Chromium in a secure context, headed and headless, getCoalescedEvents() holds exactly one sample on every move and pointerrawupdate fires one-for-one with pointermove. That is a clean automation shape — but a 125 Hz office mouse on a 144 Hz monitor delivers about one sample per frame too, and so does a 60 Hz trackpad.
Because an ordinary setup can match the automated one, this row reports the distribution and scores nothing.
How to resolve it
Nothing to fix from this row alone. If every move carries exactly one sample on a machine with a fast mouse, the input is not coming from the mouse.
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… - Keystrokes have dwell and flight time
keystroke-timing-distributionThe 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. - 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 input-coalescing-vs-hardware belongs to.