a browser that implements EME can satisfy its mandatory ClearKey baseline
Check id eme-clearkey-baseline
What an ordinary browser yields
On a Chromium build, requestMediaKeySystemAccess either is absent (no EME at all) or resolves org.w3.clearkey — the baseline the spec makes mandatory for any browser that implements EME.
What a detector infers
Encrypted Media Extensions is the DRM entry point, and it has one part that cannot be missing. The spec designates org.w3.clearkey as the mandatory baseline key system: it is the only one with no proprietary content decryption module behind it, so any browser that implements EME at all must be able to satisfy it. That single fact turns a notoriously table-shaped surface into a clean invariant. The tempting version of this check — does a Chrome-identified browser support Widevine — is a rotting table and a false-positive machine: Widevine ships in branded Chrome but not in a bare Chromium build, Firefox downloads its CDM after install, enterprise policy can remove it, and Linux is simply inconsistent, all of them honest configurations. So Widevine is collected for the read-out and never scored. What IS scored is the narrow question the spec answers for us: a browser exposing navigator.requestMediaKeySystemAccess has declared that it implements EME, and an EME implementation that then rejects ClearKey is stubbed rather than real — the EME entry point was left exposed while the media pipeline underneath was compiled out, which is the shape a headless or docker build shows. The check is gated on the measured engine, not the user agent: on V8 the ClearKey guarantee holds, so a rejection is a genuine contradiction, while off V8 it declines outright because Safari's ClearKey history is uneven and asserting it there would be inventing a rule rather than reading one. It also declines when EME is absent entirely, since a build with no media-keys support is a legitimate configuration and not a stub.
How to resolve it
ClearKey needs no proprietary CDM, so a real EME stack cannot fail it. A rejection means the media pipeline was compiled out while the EME entry point was left exposed — the classic headless/docker shape. Run a build with the real media stack, or one that does not advertise EME at all; do not stub requestMediaKeySystemAccess.
Read in the wild by
Scrapfly
Its public browser-fingerprint tool lists EME / DRM capabilities among the software signals it collects, alongside codecs and media devices.
browser-fingerprint tool, Software section: "DRM: EME capabilities"
scrapfly.io/web-scraping-tools/browser-fingerprintCloakBrowser issues
A stealth-browser tracker records exactly this failure mode: under docker/xvfb the media DRM stack is absent while the browser otherwise presents as Chrome — the stubbed-EME shape this check reads.
CloakHQ/CloakBrowser #96 "Widevine CDM not present on docker/xvfb"
CloakHQ/CloakBrowser#96Every attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Render & GPU
- 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. - every extension WebGL advertises can actually be instantiated
webgl-extensions-vs-drivergetSupportedExtensions() returns a list a page can rewrite; getExtension(name) either hands back a real extension object or null, and that… - the clear path and the shader path paint opaque red to the same bytes
webgl-draw-path-invarianceOpaque red can be produced two ways: the fixed-function clear path, and a fragment shader emitting vec4(1,0,0,1). - a mediump claim of fp32 precision is delivered by the arithmetic
shader-mediump-claim-vs-arithmeticgetShaderPrecisionFormat is a claim about float precision; a shader that computes a value only fp32 can represent is the GPU keeping or… - silence renders as exact zero through the Web Audio graph
audio-render-silence-integrityThe other audio checks compare two renders of a sound; this one renders silence and asserts it stayed silent, which catches a different kind… - a constant signal renders at exactly the amplitude it was given
audio-render-dc-integrityThe companion to the silence check below, and the input that one structurally cannot see.
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 eme-clearkey-baseline belongs to.