Heretic is a bot-detection service that tests browser claims against observed connection and device behavior. It helps signup, account-protection, and transaction teams return measured findings to their backend so application rules can decide whether to allow, refuse, compare, or challenge a session.
Heretic is a bot-detection service that checks browser claims against physical and protocol observations from the connection and device. It returns measured findings and a verdict for a server to evaluate, rather than requiring the application to rely on an opaque risk score alone.
The service is intended for signup, account-protection, and other protected actions where email, phone, IP, or browser-profile signals do not by themselves establish that an attempt comes from a new or legitimate customer. Heretic can report contradictions across TCP, TLS, HTTP/2, QUIC, timing, browser APIs, and available browser identifiers. The application remains responsible for deciding whether to allow, refuse, compare, log, or challenge the session.
Integration uses a client script and a backend verdict request. Application traffic continues to the application’s own server; the collector connects separately to the Heretic sensor. An optional phone ceremony provides an escalation path for selected sessions, but its measured device records and signature have documented limits and are not proof of a unique person.
Heretic compares browser claims with observed TCP signatures, TLS handshake fields, HTTP/2 construction, and session-specific QUIC reachability. It can expose contradictions such as a Linux connection behind a macOS claim or a browser reporting HTTP/3 without a corresponding QUIC packet reaching the sensor.
The service measures connection timing and evaluates whether a claimed location is consistent with physical limits such as the round-trip speed of light. It also reports concealment indicators alongside the verdict.
Checks can detect replaced getters, inconsistent plugin lookups, and stable values that differ across browser contexts. These findings add context when an anti-detect profile changes what a page reports.
Heretic returns a machine identifier, an instance identifier, and a separate rendering signature when available. Applications can store and compare them within the documented site or tenant scope, while treating matches as conditional evidence rather than proof of a unique device or person.
A server can retrieve the result, bind it to a pending action, and apply its own policy. When required, the widget can initiate a phone ceremony with measured movement, a timed workload, and passkey confirmation; the backend verifies the resulting token.
Run a probe on the registration page before creating an account. Review automation findings, connection observations, concealment indicators, and available identifiers, then allow a fresh uncontradicted attempt or escalate a contradicted, refused, repeated, or concealed session according to signup policy.
Compare identifiers and connection findings from a new registration with records for existing accounts. This supports decisions around repeat registrations, referral farming, trial cycling, and attempts following a ban while allowing the application to account for shared devices and household or carrier addresses.
Use a completed check before accepting an action such as checkout, a promotion, or another sensitive workflow. The backend can inspect the verdict and findings, log the session, refuse it, or request a phone challenge rather than applying a detector result automatically.
Apply session findings to traffic-access rules for automated or suspicious browsing. The use-case material supports checking browser claims against API behavior and observed connections; the application decides how those findings affect its scraping policy.
Add the Heretic collector script to the relevant page. The collector connects separately to the Heretic sensor, while your application traffic continues to your own server. Your backend retrieves the result from the verdict endpoint and should require a completed check before accepting the protected action.
Results can include a verdict, individual contradiction findings, connection observations, concealment indicators, and available scoped identifiers. The application can inspect those results and apply its own rules rather than treating the verdict as an automatic allow or block decision.
No. The ceremony records phone movement, a timed workload, and a fresh passkey signature, but the signature does not attest the motion sensor, passkeys can sync, and a QR code does not establish that the phone and desktop share a location. It is an additional policy signal, not proof of identity.
An opened session that does not complete required measurement returns refused. If collection is blocked before a session opens, no result exists. Neither outcome satisfies an application requirement for a completed probe.
Ordinary results are available for seven days. Optional zero-retention mode permits one authorized read within ten seconds and keeps no stored history. Finalized assessments retain their original verdict, findings, and versions.
Traffic data is for reference only.
