Movement deltas agree with the coordinates they were derived from
Check id pointer-movement-delta-coherence
What an ordinary browser yields
Contextual only: the movement deltas track the screen-coordinate deltas at one constant factor across the sample. That factor is commonly 1.0, and commonly the devicePixelRatio instead; both are coherent.
What a detector infers
Every pointer event carries two independent accounts of the same displacement. screenX and screenY are where the pointer is; movementX and movementY are how far the user agent says it travelled since the last mousemove — a number the browser computes for itself rather than one this page derives from the coordinates. Comparing them is a self-referential test in the purest form this audit deals in: two ledgers, one event, no population to consult and no reference table to go stale. The check walks consecutive dispatched samples, divides the movement magnitude by the screen-coordinate magnitude, and asks whether that ratio is a single constant. It does not ask whether the constant is 1. Browser zoom rescales the CSS pixel screenX is counted in, display scaling does the same through devicePixelRatio, and Chrome has long reported movement in physical device pixels while reporting coordinates in CSS pixels — each produces a constant factor, and mistaking any of them for incoherence would accuse a HiDPI laptop of automation. It reads screen coordinates rather than client ones because a scroll mid-gesture moves clientX without the pointer moving; it ignores coalesced samples, whose movement values are not chained to the previous dispatched event; and it declines outright under pointer lock, where movement becomes a raw device delta while the coordinates stop changing altogether. This row is contextual and never scored, and the reason is more interesting than the check: the specification DEFINES movementX as the difference between this event's screenX and the previous event's, so in a conforming engine the two accounts agree by construction, and agreement is therefore not evidence of a hand. Nor is the converse available — CDP's Input.dispatchMouseEvent injects above the renderer, so the browser computes movement for injected input exactly as it does for a mouse, and Playwright and Puppeteer satisfy this trivially. What it can genuinely see is narrower: an event stream whose coordinates were written but whose movement was not, which is what a page-script replay through dispatchEvent produces, leaving movementX at its default of zero while clientX and screenX carry whatever the script set. Those events also report isTrusted=false, so this is a second and independent view of the same fact rather than a new capability — which is precisely why it is presented as a description and not as a charge.
How to resolve it
Nothing to fix, and very little to read into a pass — a browser is expected to agree with itself here, and input injected through the browser's own pipeline inherits that agreement. If you are synthesising events from page script, note that dispatchEvent lets you set coordinates while leaving movementX at zero, which is visible; but the same events already announce themselves through isTrusted, so this is not the check that will catch you. It is included because the comparison is sound and costs nothing, and because the scale factor it reports is real information about how this browser counts pixels.
Read in the wild by
Akamai
Collects the raw mouse-coordinate stream this row cross-checks against the browser's own movement deltas. Stated precisely, because the distinction matters: the inventory names coordinates, velocity and acceleration — it does not name this comparison, and no source here is claimed to run it.
signal_categories.md - 4. Behavioural - Mouse movements: Coordinates, velocity, acceleration patterns
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. - 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 pointer-movement-delta-coherence belongs to.