PerformanceEntry timestamps land on the same grid performance.now() exhibits
Check id perf-clock-grid-coherence
What an ordinary browser yields
Every PerformanceEntry timestamp lands on the same grid performance.now() itself exhibits — they share one clock.
What a detector infers
A timestamp's low bits are a fingerprint. DataDome ships its performance floats unrounded — 2253.7000000029802 rather than 2253.7 — and that is not sloppiness: the residue is the exact double round-off of a clock floored to a 100-microsecond grid, and shipping it raw is how the grid survives to the server. This check reads the same thing from the other side. It measures the smallest tick performance.now() will actually resolve, by spinning until the value changes, then checks that every PerformanceEntry timestamp the browser exposes lands on that same grid. They are one clock: an entry cannot resolve time more finely than now() itself does. Landing on a coarser grid is fine and never flagged — that is consistent, not contradictory. What it catches is that you cannot patch one clock. Coarsening or jittering performance.now() to blunt timing attacks leaves PerformanceEntry.startTime testifying against it, because the tool patched the function everybody reads and not the timestamps the engine had already written. That is also precisely why this is a warning and not a contradiction, and why its wording says a clock has been modified rather than anything about bots: the honest and common cause is a privacy extension doing exactly what its user asked. Two implementation notes carry the check. The grid is measured every run and never tabled, so a future change to the browser's clamp makes it go quiet rather than wrong. And the measured tick is refined against the data's own quotients before use — dividing large timestamps by a raw measured float accumulates enough error to flag a stock browser, which is not a hypothetical: the first version of this check reported 61 of 62 entries off-grid on a clean Chrome.
How to resolve it
If you did not change a clock here, nothing needs fixing and this row is not scored. If you did — or a privacy extension did on your behalf — the lesson is that the browser exposes the same tick through performance.now() and through every entry it timestamps, so blunting one leaves the other describing the original. Coarsening both together is coherent; coarsening one is louder than not coarsening at all.
Read in the wild by
DataDome
Ships its performance floats UNROUNDED, and that is the point: the residue encodes the clamp grid the browser applies, so shipping it raw carries the grid all the way to the server. Every value verified to be an exact multiple of 2^-27 and to sit on the 100-microsecond decimal grid.
payload fields jNp5AR=2253.7000000029802, bh4R1L=-2263.2999999970198, P5iRwT=46.29999999701977, zNtWdL=0.09999999403953552, N4qYlY=0.10000000149011612 (exactly one 0.1ms tick) — a contiguous block alongside uKVCRV="http/1.1" (nextHopProtocol) and SYMmJy="navigation" (entryType), both readable only off PerformanceNavigationTiming
glizzykingdreko/datadome-encryption — a real 232-field captured payloadEvery attribution traces to a published artifact. See the sources and their limits.
Other checks in Clocks & ledgers
- the monotonic clock and the wall clock name the same instant
epoch-vs-monotonic-clockA browser carries two physically different clocks: a monotonic counter anchored at performance.timeOrigin, and the wall clock behind… - both generations of the navigation timing API describe the same page load
navigation-timing-dual-apiThe platform kept two generations of one API alive. performance.timing speaks Unix epoch; PerformanceNavigationTiming speaks milliseconds… - a stylesheet that provably loaded appears in the performance timeline
resource-timing-vs-cssomFetching a resource writes two records: the DOM object you can see, and an immutable entry in the performance timeline. - wall-clock and monotonic time advance at the same rate
wallclock-vs-monotonic-rateA browser owns two clocks and they are not the same clock. Date.now() is wall time: it can be wrong, it can be corrected, it can jump… - every surface that reports when this document started agrees
navigation-origin-consensusOne document has one navigation start, and Chrome exposes it through four different doors: performance.timeOrigin, the legacy…
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 Clocks & ledgers 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 Clocks & ledgers — the family perf-clock-grid-coherence belongs to.