Skip to content
All fingerprint checksCapability surfaces

the CSS feature surface is identical in a fresh realm

Check id css-surface-vs-realm

What an ordinary browser yields

All fifty-odd answers identical in both realms — the surface is a property of the binary, and both realms run the same binary.

What a detector infers

Which CSS properties, values and selectors an engine understands is decided when the browser is compiled. The check asks CSS.supports() around fifty questions — modern layout (grid, container queries, :has()), engine-owned prefixes (-webkit-app-region, -moz-orient), and recent additions (anchor positioning, view transitions, field-sizing) — then asks the identical fifty inside a fresh same-origin iframe and compares every answer. There is no legitimate way for one realm of a browser to support a CSS property another realm does not: both are served by the same compiled style engine. So a disagreement does not mean the browser is unusual, it means the answers are being generated rather than reported, by something that reaches the page world but not a realm the browser builds fresh from its own binary. Note what this deliberately does not do: it never compares the feature set against a table of which Chrome version shipped what. Such tables are exactly the kind of hand-maintained corpus that goes stale and then starts accusing ordinary browsers of being fake — a failure this audit has already made once. Comparing a realm against another realm cannot rot, because both sides are measured live. This is the biggest single family in Kasada's deployed script after property enumeration: roughly forty-nine of its four hundred and twenty-seven probes are individual CSS.supports questions, asked in both realms.

How to resolve it

Do not rewrite CSS.supports or the style surface from page script. A fresh realm is constructed straight from the browser binary and will keep answering honestly, so patching the page world converts a capability into a contradiction. If a different feature set is genuinely required, it has to come from a different build.

Anatomy of a browser fingerprint: every signal, and why they must agree

Read in the wild by

Kasada

Roughly 49 of its 427 probes are individual CSS.supports questions, asked in both realms.

css_align, css_grid, css_shape, css_mask, css_moz, css_webkit, css_epub, … (49 total)

Kasada ips.js teardown — the full 427-probe list

Every attribution traces to a published artifact. See the sources and their limits.

Other checks in Capability surfaces

Who builds this test

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 Capability surfaces 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 Capability surfaces — the family css-surface-vs-realm belongs to.