Fingerprinting coverage

Heretic combines connection measurements with browser observations. A detector can report a concrete inconsistency without knowing how common it is. It cannot establish device uniqueness or a hardware model from an unusual value alone.

​

What runs on a customer page

Basic integrity inspection does not modify browser globals, request permissions, render a canvas, or contact another service. It runs after timing-sensitive measurements and is independent of their budget. Optional surface collection still adds useful comparisons; turn it off only when you accept that loss of coverage. The probe page also runs active driver traps. Those traps modify its owned document and do not run on arbitrary customer pages. Do not infer that a quiet customer probe tested those traps.

​

What a finding establishes

An own navigator override reports a replaced property. A WebDriver flag reports the browser’s declared automation state. A plugin inconsistency reports an actual disagreement inside the browser’s object graph. Extensions and application instrumentation can produce some of these findings; the returned ID describes the observation, and your backend chooses the policy. The checks do not make client JavaScript trustworthy. A modified browser or coordinated script can rewrite every observed value, including the detector’s output. Agreement means the implemented checks found no contradiction. It does not prove a human, an unmodified browser, or a unique physical device.

​

Performance observations have limits

Schema 12 retains CPU/GPU throughput comparisons, core-count estimates and cross-realm GPU differences as conditional findings. Slow execution does not establish a fake CPU. A throughput plateau does not count installed processors. Different graphics contexts can be created across an adapter switch. These observations remain available to your policy, but do not set contradicted by themselves. The fibre RTT comparison is also conditional: the sensor does not establish that the path propagated entirely through fibre. The vacuum comparison still checks the location implied by the declared timezone; it does not authenticate the browser’s physical location. The minimum/median and work/duration arithmetic checks remain conclusive: they compare a result with its own inputs. Confirmed browser overrides, explicit automation and protocol contradictions also remain conclusive. No rule treats zero plugins, missing chrome.runtime, an unusual font list, or a low benchmark result alone as proof of automation. Browser updates and permission settings change those surfaces.

​

Integrate the result

1. Load the current collector and bind a probe to a pending action in your application.
2. Fetch the result on your backend and check site, freshness and action binding.
3. Handle refused separately. A required measurement that silently disappeared is not a completed probe.
4. Inspect the returned signal IDs and tiers. Use families[].coverage and sensor admissions to see what was available; family coverage is not a guarantee that every browser API was tested.
5. Compare identifiers only within the documented site or tenant scope and identity version. A matching hash establishes matching normalized inputs, not one person.
6. Apply your policy and consume the proof once when you complete the protected action.

Writing application rules provides the backend sequence. The signal reference lists IDs and their current tiers.

​

What additional data would and would not solve

More labelled devices can validate compatibility and measure collisions, stability and detection rates. Those claims need that evidence. The deterministic checks above do not need a population baseline. A larger dataset alone would not authenticate JavaScript telemetry, prove that one fingerprint means one person, or turn a short benchmark into a physical core count. Stronger guarantees would require different measurements or a protocol that supplies the missing assurance.