> ## Documentation Index
> Fetch the complete documentation index at: https://docs.heretic.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Fingerprinting coverage

> What Heretic checks, what each observation establishes, and which gaps need different evidence.

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

| Check                        | Evidence                                                                                   | Availability                                                                 |
| ---------------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- |
| Declared automation          | WebDriver flags, explicit headless user agents and recognized driver globals               | Every probe                                                                  |
| Navigator integrity          | Own-property overrides, JavaScript getters, and getters accepting a non-Navigator receiver | Every probe, collector 0.2.2 or later                                        |
| Reflection integrity         | Whether the functions used to inspect browser properties were replaced                     | Every probe, collector 0.2.2 or later                                        |
| Plugin and MIME consistency  | Collection types, indexed and named lookup, and plugin references                          | Every probe, collector 0.2.2 or later                                        |
| Engine and claim consistency | Navigator constants, client hints, codec answers, error-stack format and repeated reads    | Available claims; detailed checks require `surface: true`                    |
| Realm consistency            | Stable declarations from the page, same-origin frame and worker                            | `surface: true`; blocked or failed realms abstain                            |
| Graphics integrity           | Native method properties, extension consistency, allocations and platform-specific drivers | Completed WebGL measurements                                                 |
| Connection consistency       | TCP, TLS, HTTP/2 and QUIC behavior against declarations and protocol constraints           | Captured connection evidence; sensor impairments are reported                |
| Device identifiers           | Site-scoped hashes of normalized hardware and rendering inputs                             | Required inputs must be present; `render: false` reduces identifier coverage |

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](/integration/writing-rules) provides the backend sequence. The [signal reference](/reference/signals) 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.


## Related topics

- [Collector options and result](/collector/options.md)
- [Signal reference](/reference/signals.md)
- [Verdicts and coverage](/concepts/verdicts-and-coverage.md)
- [How Heretic measures](/concepts/how-heretic-measures.md)
- [Verdict schema](/api/verdict-schema.md)
