The Widevine device certificate is a privacy problem in any browser Google has not signed. Widevine, the DRM module Chrome uses for Netflix and Spotify, only encrypts its client identity for a browser that passes Verified Media Path. Ours cannot. So the first licence message our engine sent carried the device certificate in the clear, 1704 bytes where Google Chrome sent 2, and that certificate was the same for every profile on the machine.

The verdict we could not explain

IPHey called every desktop profile we made "Detected an inconsistent browser fingerprint (whale)". A branded Chrome on the same Mac and the same exit was Trustworthy. We spent days comparing the two surface by surface, about fifty of them, and they matched. The speech voice list was the one real gap we found that way, and fixing it did not move the verdict.

What found it was reading what the detector collects instead of what we thought it collected. IPHey runs a wasm-bindgen module, and wasm-bindgen names every import after the thing it reads. We wrapped the module's import table and logged every call, so the whole collection came out in plain text. One field stood out: {status: "usable", message: <1704 bytes>} from our engine, against two bytes from Chrome.

What the two browsers sent

Both browsers negotiated the identical EME configuration, with distinctiveIdentifier and persistentState both resolving to "not-allowed". Then each produced the first message of a MediaKeySession:

branded Chrome     2 bytes   SignedMessage.type=4   service certificate request
our engine      1704 bytes   SignedMessage.type=1   licence request

Chrome's two bytes ask the licence server for a service certificate. With that certificate, the CDM encrypts the client ID before sending it. Widevine calls this privacy mode. Our engine skipped the step and sent a licence request with the device certificate readable inside it.

Same machine, one exit, three runs:

our engine, unmodified          Unreliable    MX  90   payload 107,018
our engine, EME made to reject  Trustworthy   MX 100   payload  95,456
branded Chrome 153              Trustworthy   MX 100   payload  96,178

Take Widevine away and the verdict, the score and the size of what IPHey collected all line up with Chrome.

Every profile is drawn from one real computer, not from separate listsIn Mosaic: Machines that exist. GPU, screen, CPU and fonts from one real device. Free holds 3 profiles. Pro is $49 a month for any number.

How it works: Machines that exist

Why we cannot have privacy mode

The CDM uses privacy mode only for a host that passes Verified Media Path. VMP means two Google signatures shipped beside the binary: one over the CDM library and one over the browser. Chrome carries both. The second is Google's signature over Google's own build, and nothing we compile can carry it. Our app is not signed at all yet.

We tried three things that looked like fixes, and none of them changed the message:

  1. Forcing allow_distinctive_identifier to false where the browser hands settings to the CDM.
  2. Swapping our bundled CDM, 4.10.3050.0 from Chrome 152, for the exact 4.10.3112.0 that Chrome 153 loads. Worth doing on its own; it changed nothing here.
  3. Asking for every EME configuration in turn.

Why the Widevine device certificate is a privacy problem

Most of a fingerprint is a value that varies, and the job is to make it vary the way real machines do. This certificate is the opposite. It is stable per install, so every profile on the computer reports the same one. It survives every value the generator redraws. And a page needs no permission to start a media key session and read it.

That is a join key, not a weak signal. Two profiles with different GPUs, screens, exits and cookies would still carry the same certificate. Keeping accounts apart is the reason a profile exists at all, and how accounts get linked is mostly a list of values like this one.

Off unless a profile asks

So the CDM is off by default. Patch 0146 gates its registration on a launch switch, which means a profile without the switch has no Widevine at all rather than one that hides it. A page that asks for com.widevine.alpha is told it is not supported. That is a readable fact too, the same answer a Chromium built without Widevine gives, but it is not one that ties your profiles together.

A profile that needs Netflix, Prime Video or Spotify can turn it on: in the profile editor, Privacy › Leak protection › Allow Widevine DRM playback. The switch says what it costs, in the app's own words: "the CDM hands every site that asks its per-install device certificate — the same value for every profile on this machine". That trade is the profile owner's to make, knowingly, one profile at a time.

Settings, Engine: Tesseract Chrome installed and up to date
Tesseract Chrome, where the CDM is registered or not

What it cost

The search ran for a long time against bare launches of the engine. A bare launch is a browser Mosaic never ships: it leaves out --disable-field-trial-config, so a field trial cuts navigator.languages to one entry, and every reading described a browser nobody runs. The rule we kept is to measure the real launch path first. Why the fix had to live inside the engine, and not in page JavaScript, is in why we built our own Chromium, and how the rest of a profile is drawn is on real fingerprints.