DOM exception wording matches the engine actually measured
A build measuring as V8 produces DOM exceptions carrying Blink's binding-layer prefix; one measuring as SpiderMonkey or JavaScriptCore produces none of them.
What a detector infers
Buried inside a deployed commercial agent's DataTransfer collector is a test that a caught TypeError's message contains a particular phrase describing a File type mismatch — phrasing that belongs to one engine and not to Blink, which words the same failure completely differently. The collector is not validating anything with that test.
It is using the wording of a DOM exception as an engine oracle, and it is a good one, because the DOM binding layer is a different codebase from the JavaScript engine and is not somewhere a build claiming another identity tends to look.
This audit had three related rows and none that did this: the error group compares an error's dialect across REALMS, which catches a page-world patch but says nothing about whose dialect it is; the engine rows compare a JavaScript-level oracle against the user-agent string. This is the binding layer, which is a third and independent source.
What makes it safe to score is that the discriminator is structural rather than a list of exact strings — Blink's code generator prefixes essentially every exception it produces with a fixed 'Failed to <verb> on <interface>' shape, and that shape is a property of the generator rather than of any individual message. Measured across seven unrelated failures on a stock Chrome, all seven carried it; neither Gecko nor WebKit produces anything of that form.
The comparison is against the MEASURED engine from the RangeError-length oracle, not against the claimed user agent, so the row cannot be satisfied by relabelling.
The Blink side is a majority rather than a unanimous test because individual messages get reworded between Chrome versions and a stricter row would go red on an ordinary browser the first time one changed; the absence side is unanimous, because a single occurrence of a prefix another engine never emits is a contradiction rather than drift.
How to resolve it
Exception wording is emitted by the binding layer's code generator, which ships with the engine — it is not a per-message string a profile can set. If an identity claims a different engine family, this is one of the surfaces that keeps answering from the real one.
Other checks in Error subsystem
- every realm speaks the same error dialect
error-dialect-realm-agreementAn engine's error messages are a dialect hiding in plain sight. - the stack notices how deep the call chain actually was
error-stack-depth-fidelityDataDome's bytecode VM does something small and sharp: new Error(), read .stack, fold a hash over the text — we can read the exact opcodes… - the structured and string renderings of one call chain name the same frames
structured-stack-vs-string-stackChrome describes one call chain twice. Once as the human-readable string on Error.stack, and once as structured CallSite objects, through a… - a stack trace names the function it was thrown in
error-stack-livenessA stack trace is not a string, it is a measurement of the present moment — a function of who called whom, from what URL, at what column… - stack serialisation matches the engine actually measured
error-stack-format-vs-engineCaptures of three real browsers on one machine pin this precisely: for the same collector, the serialised stack begins with the error name… - surfaces that must fail, fail in the specified way
collection-outcome-shapeA deployed agent records a status code beside every value it collects, and its own generated documentation maps each code to the places that…
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 Error subsystem 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 Error subsystem — the family dom-exception-wording-vs-engine belongs to.