a browser that implements EME can satisfy its mandatory ClearKey baseline
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
- 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. - the same audio render reproduces itself
audio-render-reproducibilityAn OfflineAudioContext render involves no output device and no clock. - one canvas encodes the same pixels through toBlob and toDataURL
canvas-toblob-vs-todataurlA canvas has three exits — getImageData, toDataURL and toBlob — and a build that perturbs canvas readback has to perturb all three… - the WebGL2 element-count limits are reported beside the renderer that claims them
webgl-max-elements-readoutMAX_ELEMENTS_INDICES and MAX_ELEMENTS_VERTICES are hints the driver publishes about how many indices and vertices it draws efficiently in… - the WebGPU preferred canvas format is reported beside the claimed platform
webgpu-canvas-format-readoutnavigator.gpu.getPreferredCanvasFormat() returns the texture byte order the platform's compositor wants to be handed — and that preference… - drawing the same scene twice produces the same pixels
canvas-repeat-render-determinismCanvas noise is usually reasoned about as a trade: give up a stable hash, gain an unlinkable one.
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.