Skip to content
All fingerprint checks
Navigator identity

the content-protection modules present belong to the platform being claimed

Pim· Clearcote Research 2 min readCheck id drm-key-systems-vs-claimed-os

Whatever modules are present belong to the platform being claimed. Missing modules are reported and never judged — a Chromium without the proprietary decryption module is an ordinary browser.

What a detector infers

A deployed commercial agent probes six content-protection families and ships one bit for each — Widevine twice, once with a stricter robustness configuration, plus PlayReady, ClearKey, Adobe PrimeTime and FairPlay. Those bits are unusually well anchored, because a key system is not a browser feature that travels with the build. It is a decryption module licensed to a PLATFORM: FairPlay is Apple's and is reached through Apple's media stack, PlayReady is Microsoft's.

Support therefore implies a platform in a way a user-agent string never can, which is what makes the pairing checkable. Only the presence direction is scored, and that limit comes from the single most useful thing measured while writing the row: the browser it was developed against — an ordinary, entirely legitimate Chromium — supports no Widevine, no PlayReady, no FairPlay and no PrimeTime whatsoever. Only ClearKey, which the specification requires of everyone.

A missing decryption module is the normal state for a large and growing population of builds: Chromium without the proprietary module, distribution packages, testing builds, anything not shipped by a vendor holding the licences. A row that scored absence would convict every one of them, and would convict the machine this audit was written on.

Presence is the direction that carries information, because a module cannot be present by accident — claiming one operating system while the platform hands the page another vendor's decryption stack is not a configuration difference, it is two layers describing different machines.

One further arm reads the engine rather than the platform: the WebKit-prefixed alias for ClearKey resolves only on WebKit, and a current Chromium answers only to the unprefixed name, so the prefixed one resolving under a non-WebKit engine is the same class of contradiction.

How to resolve it

Do not add key-system support the underlying platform lacks, and do not present a platform whose decryption stack the machine is actually carrying. Unlike most of a fingerprint, these cannot be added or removed from the page — they keep answering from the real system.

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

Nearby checks in Navigator identity

See all 36 checks in Navigator identity
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 Navigator identity 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 Navigator identity — the family drm-key-systems-vs-claimed-os belongs to.