DRM Fingerprinting: What EME and Widevine Queries Reveal

What Encrypted Media Extensions expose to a page

Encrypted Media Extensions, usually shortened to EME, is a W3C specification that lets a web page cooperate with a content decryption module, or CDM, to play protected audio and video. Streaming services use it so that a licensed stream can play in an ordinary tab without a plugin. The best known CDM is Widevine, which ships with Chrome and with most browsers built on Chromium. Other key systems exist for other platforms, and one of them, Clear Key, is defined by the specification itself so that every conforming browser can offer a baseline.

A page does not need to play anything to learn about this machinery. Before it asks for a license, a page asks the browser whether it can work with a given key system and a given set of media configurations. That question is a normal part of media playback, and the answer is a normal part of how a streaming player chooses between formats. The same question can also be asked by a script that has no player at all, with no permission prompt and no visible change on screen.

The call at the center of this is navigator.requestMediaKeySystemAccess. It takes a key system name and a list of requested configurations. If the browser can satisfy at least one configuration, the promise resolves with a MediaKeySystemAccess object. If it cannot, the promise rejects. Either outcome carries information, and a script can repeat the call with many different configurations in a few moments. The call is only available in secure contexts, which in practice means a normal HTTPS page.

That is why DRM capability data belongs in any serious discussion of browser fingerprinting. The result is not a stable identifier by itself. Many people run the same operating system and the same Chrome release, and they will report the same answers. What the result does provide is a set of platform and hardware facts that is hard to read through other APIs, and that set adds to the picture a site builds when it combines many signals.

The DRM signals a site can read without asking

Several different parts of the EME surface contribute to what a script can learn. They are worth separating, because each one changes for different reasons and each one needs its own check.

• Key system support. Widevine, Clear Key, PlayReady and FairPlay each identify themselves with a key system string. Which of these a browser accepts depends heavily on the operating system and the browser build. A browser that accepts a key system tied to one platform tells the page a great deal about where it runs.
• Robustness levels. For Widevine, a requested configuration can name a robustness level such as software crypto, software decode, hardware crypto, hardware decode or full hardware protection. Whether a level is accepted reflects how much hardware-backed protection the device and the CDM offer.
• The DRM codec matrix. The codecs a key system accepts inside a protected configuration are not always the same as the codecs the browser reports for ordinary playback. The combination of container, codec and robustness that succeeds forms its own small table.
• Session types and initialization data types. A configuration lists the session types it supports and the initialization data formats it accepts, such as the common encryption format used for MP4 content. Temporary and persistent sessions are different capabilities.
• Configuration objects. When a query succeeds, getConfiguration() returns the configuration the browser actually agreed to. The returned object includes the accepted capabilities and the distinctiveIdentifier and persistentState requirements. Details such as the order and the exact fields of that object can differ between platforms.

Each of these is easy to query and cheap to repeat. A script can ask for dozens of combinations and record which ones resolve. The MDN reference for requestMediaKeySystemAccess documents the parameters and the rejection behavior, and the W3C specification defines the configuration dictionary that a successful query returns.

Clear Key deserves a separate note. Because the specification defines it, every conforming browser can answer for it, so it works as a baseline and not as a platform marker. Its value in a consistency check is as a control: if Clear Key resolves normally while a platform-specific key system behaves oddly, the problem sits in the DRM layer and not in the page or the network. The details it returns, such as the supported initialization data types, can still differ slightly between browser builds.

The important point for a reader is the word silent. None of these queries shows a prompt, none requires a gesture, and none leaves a visible trace. A page can run them while it loads. The W3C specification includes privacy considerations about how exposed capabilities and identifiers can help recognize a user, which is the same concern that drives this article.

It is also worth being precise about what the signals do not do. DRM capability data does not name a person, and it does not by itself single out one device among millions. It narrows the field. A site that combines it with screen, font, audio, codec and network signals gets a much sharper picture than any one of them gives alone. That is the sense in which DRM queries contribute to identification, and it is the only sense in which this article uses the term.

Why VPNs, private windows and extensions leave these answers unchanged

People who care about privacy often reach for a VPN, a private window or a browser extension first. All three are reasonable tools for other problems, and none of them touches the signals described above.

A VPN changes the network route and the visible IP address. The EME capability query never uses the network. It asks the browser, and the browser asks the installed CDM, and the answer comes from software and hardware on the local machine. Switching the VPN on or off or moving to a different country changes nothing about which key systems are present or which robustness levels the device can honor.

A private window changes how the browser stores cookies, history and site data for the length of a session. It does not install or remove a CDM, and it does not change the hardware. Key system support, robustness levels and the codec matrix come out the same in a private window as in a normal one. Private browsing is good protection against cookie-based recognition, but DRM capability data is not stored state, so there is nothing for it to clear.

Extensions are the most tempting option and the weakest. An extension that blocks the API outright also breaks every service that relies on protected playback, and the missing API is itself a visible and unusual choice. An extension that rewrites return values in page scripts has to keep every answer consistent with every other answer, including the objects returned by getConfiguration(), and it cannot add or remove native CDM support. A script-level patch of this kind tends to produce a mixture that no real browser would report, which is more distinctive than the original answer.

For the same reason, replacing a single value is not enough. A configuration that claims hardware-backed protection on a platform that has none, or that lists a key system tied to a different operating system, is internally inconsistent. Consistency across the whole set of answers matters more than any one answer, and that applies equally to codec data. The related article on MIME and codec fingerprinting covers the codec side of this in more detail.

A useful way to keep the division in mind: network tools change where a session appears to come from, storage controls change what a session remembers, and neither changes what the machine and the browser build can do. DRM capability data describes what the machine and the build can do. Only a change to the platform identity that the browser reports, applied to every surface together, moves it.

Where DRM signals sit among other platform signals

A browser presents one coherent environment to a page, and DRM data is one of the places where that environment can fail to be coherent. The user agent string, the platform string, the reported fonts, the audio stack, the WebGL renderer and the DRM capability set all describe the same machine. When they describe different machines, a site has a simple reason to treat the session as unusual.

Consider a session that reports a desktop Windows identity but runs on a Linux host. If only the visible strings are changed, the DRM surface can still reflect the host. The key systems, the robustness levels and the session types may follow the host platform, while everything else points to Windows. Nothing in the page has to be clever to notice that. It only has to compare two answers.

The same reasoning applies across browser versions. Widevine and the browser ship updates, and the set of supported robustness levels and codecs can change with them. A reported browser version and a reported DRM capability set should therefore belong to the same period. Mixing a recent browser identity with the DRM answers of an older build produces another mismatch that is easy to detect.

Audio is a useful comparison. The article on audio fingerprinting describes how the same routine gives different results on different audio stacks. DRM works in a similar way: the same question gets different answers on different platforms, and the answers are stable on any one platform. Stability is what makes a signal useful for recognition, and it is also what makes a consistency check meaningful.

This is also why DRM data should be treated as part of the platform identity and not as a separate setting. A profile that describes a platform should describe its DRM behavior as one of its parts. Editing individual capability answers by hand, one at a time, leaves too many places where the picture can disagree with itself.

Mobile platforms add another layer. A profile for an Android device describes a platform where hardware-backed protection is common, while many desktop and virtual environments cannot honor the highest robustness levels. A DRM surface that claims hardware-backed decode on a host that plainly has no such support is a mismatch that a single query reveals. When you choose a profile, compare its platform with the hardware you actually run on, and treat any large gap as something to verify instead of assuming it will resolve itself.

How to verify DRM signals against a chosen profile

Verification starts with a written list of what the loaded profile claims. The platform, the browser major version and the profile source are the three facts that every later check depends on. With those recorded, the DRM surface can be compared against them in a repeatable way.

1. Name the profile platform first. Note the operating system the profile describes and the key systems you would expect on that platform. A key system tied to a different operating system should not appear, and a key system that every browser on that platform offers should not be missing.
2. Run capability queries for each key system. Query Widevine and Clear Key with a small set of configurations and record which ones resolve and which reject. Keep the configurations identical from run to run so that differences in the output are real differences.
3. Compare robustness levels. Ask for each Widevine robustness level in turn and record which are accepted. The accepted set should fit the hardware tier the profile describes and should not exceed what that platform can plausibly offer.
4. Read the configuration objects. For each successful query, read what getConfiguration() returns and record the initialization data types, the audio and video capabilities, the session types, and the distinctiveIdentifier and persistentState values. These should look like the output of the platform the profile describes.
5. Repeat across reloads and restarts. Reload the page, close the browser, start it again with the same profile and run the same queries. The results should be identical every time. A result that changes between runs points to a configuration problem and not to a property of the platform.
6. Compare headed and headless runs. If you use both modes, run the same queries in each and compare them. Differences are worth investigating, because a CDM that is present in one mode and missing in the other is visible to any page that asks.

Keep the outputs in a short table next to the profile name. When a later change to the profile, the browser version or the host environment alters a result, the table shows which answer moved. Review it again after each browser update, because the DRM surface can change with a new release.

Read failures by category. A key system that is missing on a platform where it should exist usually means the CDM was not installed or was not found. A key system that exists where it should not points to a mismatch between the profile and the host. A robustness level that is accepted on one run and rejected on the next suggests that the environment changed between runs, for example a different CDM version or a different launch mode. Recording which category a failure falls into makes the next step obvious and keeps the investigation short.

This check only compares DRM answers with the profile. It does not test whether a particular streaming service will play content. Playback depends on a CDM, a license server and the policy of the site, and none of those are part of a capability comparison. A clean result here means the signals are consistent, nothing more.

What BotBrowser covers and what stays outside it

BotBrowser supports profile-driven DRM capability reporting, so the EME key systems, robustness levels, session types and DRM codec support that a page can query are reported consistently with the loaded profile's platform identity, and the BotBrowser DRM documentation notes that no separate CLI flag is needed for this. That gives you a defined baseline to verify against, using the checks above, without editing individual answers by hand. BotBrowser cannot supply or bundle the Widevine CDM, decrypt protected content, guarantee playback or license approval, or control a site's own DRM policy and detection decisions.

Playback is a separate task from consistency. To play protected content you need a Widevine CDM that you obtain through official channels and the licensing that goes with it, and none of that comes from the browser. The Widevine DRM setup guide covers the setup side, and the BotBrowser documentation on DRM fingerprint consistency describes how the capability reporting follows the profile.

Keep two questions apart when you plan a test. The first is whether the DRM surface matches the profile, which the checklist above answers. The second is whether a given service plays content for a given account, which depends on the service. A session can pass the first and still fail the second for reasons that have nothing to do with the browser.

In a test plan, write down which of the two questions each test answers and keep the evidence for each separately. A consistency report lists key systems, robustness levels, configuration fields and how many runs matched. A playback report lists the service, the account type and the source of the CDM. Mixing the two makes failures hard to assign to the right cause.

Public sources

• W3C: Encrypted Media Extensions
• MDN: Navigator.requestMediaKeySystemAccess()
• BotBrowser docs: DRM fingerprint consistency