SVG's screen matrix agrees with the element's client rect
Check id svg-ctm-vs-client-rect
What an ordinary browser yields
getScreenCTM's translation and getBoundingClientRect's top-left agree to within float noise — the same viewport position reported twice.
What a detector infers
Two independent routes to a single fact. getScreenCTM maps an SVG element's user space into viewport coordinates, and getBoundingClientRect reports that same element's border box in those same coordinates. For a rect authored at x=0, y=0 with no rotation, the user-space origin maps to exactly the matrix's (e, f) translation, and that point IS the top-left corner of the box — so the two APIs must return the same number, or one of them has stopped describing this element. No reference value is involved: the check is two answers held against each other, which is why it needs nothing known about the host, the font stack or the display. This is the general form of the origin check, and the pair is kept deliberately because they fail apart. The origin check compares one answer against zero and therefore only speaks at the viewport origin; this one compares two answers and holds wherever the element sits, which is the interesting case, because an offset chosen to perturb element geometry expects to be invisible precisely at arbitrary positions. A modification applied uniformly to every geometry API trips the origin check while this one passes. A modification applied to client rects alone trips this one at any position. Measured on a shipping stealth browser: the screen matrix reported the exact authored position while the client rect for the same element was displaced by a constant, identically at the origin and at an arbitrary coordinate, on every launch. Rotation and skew are not judged, because they legitimately separate a mapped corner from an axis-aligned bounding box; scale deliberately is not gated, because the user-space origin maps to (e, f) whatever the scale factors are, which keeps the check valid under page zoom and under a viewBox.
How to resolve it
The screen matrix and the client rect come out of one layout pass, so they cannot be set independently. A modification applied at the client-rect layer — the usual place, because DOMRect is what element-size and font fingerprinting actually reads — leaves SVG's matrix still reporting the untouched position, and subtracting one from the other recovers the modification exactly. This is not scored as a contradiction, since perturbing rects is a legitimate privacy technique. The lesson it carries is that such a technique has to cover every API that reports a position, not only the one being defended against, because the uncovered API becomes a free reference for the covered one. Controls measured for this row: Chrome 150, Edge 150, stock Brave 150 and Firefox 151 all return a difference of exactly zero between the two APIs — Gecko included, which is what establishes that the agreement is a property of the specification rather than a Blink coincidence.
Read in the wild by
CloakBrowser (measured)
getScreenCTM returned the exact authored position while getBoundingClientRect placed the same element a constant fraction of a pixel away — on all three launches measured, and by the identical amount whether the element sat at the viewport origin or at an arbitrary coordinate. Because the matrix is untouched, the offset applied to the rect can be read off directly by subtraction, which is a strictly better position for a detector than merely noticing that a number looks unusual.
at left:137px/top:41px the matrix gave e=137, f=41 while the client rect gave left=137.03125 — a constant difference of -0.03125 px, reproduced at left:0/top:0 in the same session and on 3/3 launches. Stock Chrome and Clearcote on the same machine: difference exactly 0 at both positions.
CloakBrowser (measured)Every attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Render & GPU
- main-thread metrics === Worker metrics
worker-vs-mainThe same five strings are measured at 12px Arial twice: once on a main-thread 2D canvas, and once inside a dedicated Worker on an… - getBoundingClientRect === Range client rects
bcr-vs-rangeTwo independent APIs are pointed at the same laid-out text: an absolutely-positioned div containing "WWWWWiiiii" is measured with… - clientWidth and offsetWidth equal the box the element itself reports
layout-box-arithmeticclientWidth and offsetWidth are not opinions the browser offers — CSSOM defines them as arithmetic over values the same element hands you… - a box placed at the viewport origin measures its origin as zero
client-rect-origin-vs-positionZero is scale-invariant, and that single property is the whole check. - IntersectionObserver's rect agrees with getBoundingClientRect
client-rect-vs-observerA third account of where one element sits, from the most ordinary API that has one. - WebGPU's build constants are identical in every realm
webgpu-sync-surface-vs-realmWebGPU's cheapest fingerprint is not the GPU at all. navigator.gpu.getPreferredCanvasFormat() and navigator.gpu.wgslLanguageFeatures are… - the GL limits the driver reports are limits the driver will actually honour
webgl-limits-vs-driverEvery other WebGL check on this page reads what getParameter SAYS. - ANGLE's translated shader is written in the dialect the renderer string implies
shader-backend-vs-rendererThe UNMASKED_RENDERER_WEBGL string is a label — a piece of text a page can rewrite to name any GPU and any graphics backend.
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 Render & GPU 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 Render & GPU — the family svg-ctm-vs-client-rect belongs to.